Documenting Pentair Intellivalve communications

[jeffegg]

Describe the bug
Not really a bug, more of a feature enhancement. And maybe this isn't the correct place for this, maybe the wiki would be better. Let me know
Currently (as I understand) the intellivalve is minimally supported in nodejs-PoolController. In my copious extra time, between family and work, I decided to see what I can do to help improve support. So I ordered an extra intellivalve when adding some to my pool in hopes that I can help this out. Seems I am able, looking at the hardware, there is a PIC16F1718 inside (Yay), as well as a ICSP port, so using MPLABX and an ICD4, I dumped the FW. I'm currently in the process of dissembling the FW from using MPLAB, and Ghidra (thanks NSA :)) I don't know what will be supported, but since I actually made the valve do something from message Center based on the FW (reset) maybe I can figure out something useful, like setting new endstops, etc. Else, I've reverse engineered a partial schematic for the valve and I'll write my own FW. Both efforts will probably take a few weeks, depending on work schedule.
FYI I use Pool controller in Nixie single body mode, and I don't have a Pentair panel to reverse engineer communications (assuming the panels have some interesting support.) This would be easier to capture packets and reverse engineer, but I'm not interested in the panel, so don't want to spend the money on it.

Commands I know (as of 10/31/21)

SW reset of valve:
Action: 0xF7 (247)

Sent Packet: FF00FF A5 3F 0C 10 F7 04 01 01 F9

 Dissasmbled FW:           
          if (((RX_BUFF_OTHER?[7] == 0xf7) && (RX_BUFF_OTHER?[5] == DAT_DATA_006b)) && (RX_BUFF_OTHER?[9] == 1)) {
                      FUN_CODE_32aa(1); // Not sure what this does yet
                      reset();
_DAT_DATA_006b // Looks to be the valve address, I'm guessing with multiple valves we probably can address, mine is set to 0xC(12) by default._ 

Response Packet: Source: 12 (Valve); Dest: 16(OCP), Action: 1, Data Length 1: 247, Header [165,1,16,12,1,1] Term: [0,167]

[tagyoureit]

Hi and welcome. Interestingly enough, there are no Pentair outdoor control panels (OCP's) that communicate with the Intellivalve via RS485 yet. The valves work exactly like the Jandy valves in that they operate on a +/- DC voltage. The valves are more accurate (less drift over time) but for whatever reason Pentair has not released this functionality to the world yet. @rstrouse started a project over 1 year ago, valve-Grooter, to try and brute force it. There are a number of packets (245, 247, 240/241) that do things but we were never able to put them together in any sequence that would set or move the valves. We did brick a number of them and after sending 10's of millions of messages we eventually gave up. If you continue to find more in the FW, we can triangulate, but it will take someone with your skills or Pentair to help un-stuck us from our progress so far.

Check out the repo above and see if it matches up with your findings and/or if it helps you figure anything else out.

[jeffegg]

Thanks! I knew there was an effort before to brute force it, saw it on some forum. But I was unable to re google it.
I just started on the 240 command :). Good news is I have the original FW saved, before even hooking up the RS485, so if I brick something I should be able to recover assuming I don't wear out the flash (doubtful). I could remove the unit if I did this, but this part is on a 6 month to 1 year lead time it seems. Thanks for the link will see what I can do.

[rstrouse]

Good luck. I am not so sure that flash isn't the failure point. Maybe we hit something that trashes the firmware but it didn't seem that a byte sequence sent the valve south. It appeared to be based on how long the valve was having 245 and 247 messages written, We never did see anything that would tell us what the current status of the valve is.

Btw the voltage on the pins is 24vac not dc.

[jeffegg]

Hmm, well thankfully this valve is dedicated to science, worst case I have an emulator I can solder in till I get some new PICs. I can definitely see places where buffer overflow could overwrite something important.

Commands I can see in the source code:
Read Destination = 0xC(12) with a command of 0xf0 (240)
This returns a serial number (read from the flash chip and assuming it is unique) plus some other fixed and variable data
Valve returns command 0xF1 and an 18 byte payload (here is what mine read): 0080 801F124FD63E 0102FFFF 305B2001 0040
0080 is constant
801F124FD63E look to be the serial number read from flash at valve poweron or reset, also the periodic hail has this
0102FFFF is constant
305B2001 these are variables, but I don't see where these come from yet.
0040 is constant

0x50 (80)
This command seems to set the Valves Address. After the valve address is set, we no longer see the hails (at least I think that is what they are.)

Header [165, 63,12,15,80,8]
It is important to have the source as broadcast (15 or something else), when it is set to 16 (Panel) the address is reset (not sure if this is because I'm missing something else or just the way it is

Payload [ADDRESS, *(don't care it seems), serial number from hail or the reading 0xF0] so in my case I set the valve address to 0 with 0x801F124FD63E as my serial number
[4,0,128,31,18,79,214,62]

Upon sending that I get back a broadcast packet from the valve with Source as address above (0x4) destination Panel(16), Action of 1, and payload of 80

0x51 (81)
I don't know what this does, but it only works when the valve address is 0xC. I haven't really dug into it yet.

I'm still not seeing output when I do anything to the valve, but I suspect there is something else I need to set, will take some more time to continue to disassemble

[jeffegg]

Still haven't done anything useful, but wanted to document this in case anyone tries.
There are some commands that can be run at valve startup when the mode light is blinking blue:
If you write an action of 245 (0xF5) with payload bytes 2 or bytes 3 not equal to 0, the valve is put into some odd mode (only sends the Hail command, keeps resetting, and buttons don't work.) This command writes the eeprom address 0x41 to 0xFE. Not sure what this command is for yet, but if you see the mode lights blinking blue and valve is useless, you can send something like below to recover (the rest of the payload may or may not matter, mainly sending bytes 2 and 3, to change the EEPROM address 0x41 0xFD, and get out of the odd mode

[rstrouse]

Yes you have found the blinky blue mode. Originally I thought this might be the valve waiting for input from the master but never could get anything else out of it. I have a one valve stuck in blinky blue and another in modified watermelon mode. I'll see if I can break those out of their respective mode this week using the command above.

Here is some background on our results.

Action 82

This message is referred to as "I am Groot" simply because when we were initially sending messages to the valve this is the only response we got from the valve. It is broadcast from the valve periodically, regardless of whether it is asked for by the master. So it is not a response to a request from the RS485 master. There is one other device that does this and it is iChlor. Both of these appear to fire this off to address 12.

All groot message payloads are unique to the valve and there are similarities for the first several bytes of the payload if the valve is manufactured around the same time. We spent quite a bit of effort to try making sense of this output by comparing it to the label on the valve. Nothing meaningful was gleaned from that other than it looked like you could determine whether one valve was older or younger than another and byte(5) was sequential for valves purchased about the same time.

Action 80

Action 80 appears to set the address by sending the desired address in the first byte followed by the valve key. The valve key is the last 6 bytes of the groot payload. Upon successfully setting the address the valve will respond with an ACK (action 1) payload 80 from the address you assigned.

Action 240

This is an interesting message. When you send an action 240 to the valve using the address it will respond with a 241 message that contains the unique valve key followed by an additional 10 bytes tacked to the end of it which was identical for all valves found in the wild.

So if you have multiple valves on the bus and send an action 240 to 12 then all valves that have not been addressed will respond with a 241 containing the unique key and some sort of status bytes. If the valve loses power and is not stuck in a reboot cycle from 245 or 247 then it will revert to address 12. Address 12 appears to be a general broadcast address for several Pentair equipment items in the wild.

Action 241

Action 241 is a response message. This is a message that is sent from the valve when requested by an action 240. It never shows up unless it is asked for (like a good RS485 citizen). It also honors the proper addressing once you set an address with action 80. The payload for this message has been identical for all valves in the wild and has not changed unless the valve is in a mode where it no longer responds to the buttons on the valve.

This payload is in the form with constant data between all valves witnessed as follows
[0, 0, <6 bytes for the valve key>, 1, 2, 255, 255, 48, 91, 32, 1, 0, 64]. This is true unless the valve is stuck in blinky blue then the payload changes to [0, 0, <6 bytes for the valve key>, 255, 255, 1, 0, 48, 91, 32, 1, 0, 64].

Action 247

Action 247 will cause the valve to start the blue light on the valve blinking (blinky blue). When this message is sent to the addressed valve with a payload staring with [1, 2, ...] it will respond with an ACK[247].

If you send enough of these to the valve then it will stay that way and continue rebooting. The human interface on the valve will no longer respond but the valve will continue to respond to messages. Like mom used to say if you keep making that face it will be stuck that way. That is what happens after you have beat the valve up with 247s. However, one of the tests I am going to perform is to send the 245 message again to see if I can break free from the blinky blue on one of the valves stuck there.

Action 245

Action 245 seems to create light shows on the red segment leds for the valve positions. By sending different combinations in the payload we seem to be able to get different lights illuminated on the valve. This message responds with an ACK[245] when a combination it seems to like is sent.

For instance, what was identified as watermelon mode could be attained by sending [0, x, x, x, x, x, x, x, x, x]. Beating up the valve with these messages eventually gets you into carrot mode. Where it doesn't carrot all what you send it and it doesn't carrot all which buttons you press on the valve.

We also hooked the valve up to a relay to cycle the valve after different responses, sending action 240 to see if there was a different response (241) from the valve but never got beyond the aforementioned byte changes and the position never seemed to report anywhere.

In the end we gave up after several valves in the wild stopped responding to the buttons on the valve but never got to the point where the RS485 responses stopped. The only thing I can surmise from it is that the valve either is gets stuck with bad data on it or we simply wore out the flash by writing several hundred million messages to the same locations. There has to be some persistent storage on this valve or it would not remember endpoints or the current mode selected when power is lost.

Bear in mind we hammered this with a brute force method since the firmware code was not available from the valve itself.

[jeffegg]

"There has to be some persistent storage on this valve or it would not remember endpoints or the current mode selected when power is lost."
There is persistent storage in 2 places:

1. I only see this being read, never written to, but still disassembling (this will take some time, not friendly to go from hex to pic assembly to c code without context. There are a few spots in the code where values are pulled from the code binary. I'm guessing these are some const values.
2. There is a 5 pin i2c eeprom onboard I missed it at first, I was expecting 6 pins and mistook it for something like a linear voltage regulator. I cannot decode the package marking, but soldering down some probes and hooking up an oscilloscope, plus what I see from the dissembled code this seems to be some 24xxx eeprom. I need to pull this image in case I mess something.

On a good note I was able to get some rs485 traffic to emit when the valve changes position, I can only do this by writing a data value (inside the pic) when in a debugger and the output on the bus is missing the standard 0xff 0x0 0xff message header. Also good news is that each step and direction seem to have different values. I'm trying to trace the writing for this variable but not seeing this, yet. I think the dissembler is messing up bank selects somewhere but will take some time to trace. It is also possible that this is some type of manufacturing mode for ADC calibration (the valve uses a pot to set the position).

Blinky blue mode reminds me of a firmware update mode, but I haven't found proof of that yet. It could also be a mode where the rs485 gets exclusive access to the valve...

Also to note there are 2 different rs485 handlers (I call them early handler and main handler) and they are a bit different from each other. When the valve is powered on, or reset the early handler is used it hands off to the main handler after the valve blinks blue a few times and before the red position and green mode light come on.
Based on this I'm wondering if there is some flow expected by the valve for a handshake:

1. Look for the hails from the valve (action 82)
2. Set valve address (action 80)
3. Reset the valve (action 247 with payload = 1)
4. listen for hail on reboot(action 82)
5. reconfigure valve address (action 80)
6. send action 245 mode to put into remote/rs485 exclusive mode. This action only seems to be available in the early handler, but again could be missing somethibg
7. then send some commands to program valve.
8. move to the main flow with updated and saved info.
   I'm really speculating here, I don't know the normal pentair handshakes, etc. Was trying to think how I would do it if I were to rewrite the firmware

[rstrouse]

It is interesting that if you send a 240 out to address 12 all valves will respond with a 241. However, if you have a bit of RS485 understanding the notion of multiple slaves responding to a single master message is very messy and unreliable in that every valve responding at once can destroy the response from all of them. I suspect the default address is simply set to 12 and it blindly responds when it sees that address.

Since there is no selector to identify a valve address, perhaps our groot message (82) is the only viable option. So it is likely that the OCP will take however long to listen for groot messages on the bus for all unassigned valves addresses but only after it has assigned the ones already defined in the current definition. The valve does appear to inspect all 80 messages for the 6 byte key to determine if it is the intended recipient. The only way to get this key is by listening for the valve to broadcast it. To verify whether the address has been properly assigned you can send a 240 to the assigned address and it should return the valve key.

I suspect that there is a specific address range that Pentair has in mind for these with the most likely address range that starts at 160 and ends at 180. This puts the equipment identifiers outside of other equipment on the bus and provides a contiguous 20 address range that covers all potential valves available with 3 power centers. It could go as high as 24 with reserved addresses for specific valves such as intake, return, and heater bypass.

So a likely sequence would be set all the addresses already assigned by sending action 80 on OCP boot verifying each one by calling 240 for verification using the newly assigned address. This 241 result will match the valve key to the assigned address. The address is critical since the address can only a single byte and the valve key is 6 bytes. This is also critical for the OCP configuration since the valve configuration on the OCP needs to map to a single byte ordinal on one of the 15 valve messages output by the OCP. This too is speculation but it does match up to how Pentair addresses and manages other equipment on the RS485 bus.

Rumors are that there will be 5 slots in the Pentair programming so the valve would have 5 potential endpoint pairs. What is weird is how they would expect to engage these given the current 1 to 1 nature of the assignments where 1 circuit is assigned to each valve. If the circuit/feature is on then the valve is moved to the diverted position. This is done by simply applying power to either the red or white wire via an SPDT relay. The motor simply rotates until the valve reaches the assigned endpoint.

So it is assumed that turning on a circuit or feature will look at all running features associated to the valve and perhaps re-program the endpoints on the valve before engaging it using the relay. How it determines which endpoint slot to use is a mystery. As I look at the operation of the valve the endpoints seem to come in pairs but the only thing that would seem to matter would be the diverted position on the valve. No matter how you slice it if all the associated circuits are off then the un-diverted position would always be the same.

To make this really useful you would want a scenario where the valve endpoint is dependent upon multiple circuits being engaged. For instance, if the waterfall and the fountain are on divert more water to the feature plumbing. I could see a scenario where the max diverted position is calculated by identifying all circuits/features that are currently on and picking the largest diverted position value. This is in line with the way VS/VF pumps work.

[jeffegg]

Documenting a bit more on action 241 (response to 240) in normal mode:
Here is what is written by the FW, I have figured out all the info there.
My valve returns the following in hex: 0080 801F124FD63E 0102FFFF 305B2001 0040
0080 is constant in code
801F124FD63E look to be the unique ID of the valve read from flash at valve poweron or reset
0102FFFF is constant in code
305B This is the Device ID of the PIC chip (305B is a PIC16F1718 for reference)
2001 This is the Device Revision ID of the PIC chip
0040 is constant in code

Slow going trying to disassemble and fixup code, and try to infer behavior. Unfortunately not seeing anything in code for control of the valve, but I still have about 60% of the code as unknow behavior. Best I was able to do was to get some RS485 traffic to be sent when changing valve locations and modes, etc. I suspect this is a factory test mode, it can be entered by pressing and holding the Mode and Red button through a power on. Then you need to send a certain RS485 packet to enter the mode. After that the valve basically operates as normal, but sends out RS485 messages on valve change (though buttons) but they dont have the typical Pentair header (255 00 255). Still working on it, but dont hold your breaths this is going to take awhile.

[jeffegg]

DANGER DANGER DANGER!!!! For those playing around with sending codes to the valve
Blinky blue mode entered by sending action 245 with Bytes 0 and 1 non zero is a Firmware update mode.
FW update packet looks like:
DATA (values are in HEX):
01 02 - What I choose to enter blinky mode
2A 00 - This writes the microcontroller program memory at 0x1500 (PIC use a fixed 16 bit opcode, so 0x2A00 / 2 => 0x1500)
xx xx - Not sure if these matter yet, I wrote 0x1 0x2 and didnt see anything happen, I suspect these are just "filler"
Bytes after this are written to memory, will use 0 if these bytes are not sent, expecting 64 bytes in total

Please note PIC architecture enforces a whole row (all 64 bytes) to be cleared, so if there is an unalinged write, bytes not written will fill with 0xFF3F (default memory values in erased memory)

I think there is some protection in FW update mode to prevent some overwrite memory I'm guessing for the boot loader. Code for this protection is a bit confusing, trying to understand.

So if the boot loader is protected, we should be able to recover bad valves through the RS485 port. If someone is interested I can probably write a small program to reflash the firmware(FW).

Also this means another option that can be discussed is to write a custom FW for njsPC to control the valves, if I continue to find the valve doesn't allow SW control. It is possible Pentair didn't finish the code and decided that if they want this control later they can upload a new FW.

[rstrouse]

Well that certainly jives with our experiences. I have 2 valves that are inop after beating it with 245s.

[jeffegg]

Got stalled on this update with my day job (that oddly is also a night job as well most days) and family.
I don't think Pentair finished the code for remotely controlling the value (doesn't mean it doesn't exist and I'm missing it.) I've gone through the FW a few times, and there is a basis there for remote control but missing some of the actual code to send and receive the data.
I'm moving towards writing my own firmware(FW), there is a bootloader on the valves to do FW updates via the RS485 lines, and I have some rough python code here: https://github.com/jeffegg/IntelliValveFWUpdater to do updates. If people need to revive their dead valves this could potentially help.
Unfortunately I'll have to rewrite most of the code for the valve, I'm considering to see if I can just hack in the support with what is there. But I think this will restrict the implementation too much; but still in the back of my head

I'll probably stage the features out like this:

1. Get basic "remote" access using red and white wires. (Full swing, i.e. 1 side open the other closed); buttons on valve would not work
2. Report changes in valve status, and ability to poll status
3. Remote access via RS485 to override red/white wire selections (still full swing)
4. Support "set mode" to allow setting non full swing via buttons (both relay driven and RS485 would respect these points)
5. Support more of Intellivalve feature set
6. ...

If people are interested in this alternative, I can open to the community on what features, how things are implemented, etc. And to obviously share.

[tagyoureit]

If you could make this happen, there would quite a few happy folks out there. I have two manual valves right now that I would never bother to replace with a traditional JVA24 but would do it in a heartbeat with a remotely controlled, variable diverter. One is my spa bypass and the other is the diverter between the floor returns and the wall returns.

My ideal would be to remotely set a fully open/fully closed position. And then being able to send it commands to open a certain amount. Doing this by absolute value would be good (maybe degrees, maybe abs value depending on what you find). Everything that operates based on % just seems hokey (chlorinators, hayward pumps). I should be able to send an RS485 command and have the return diverter fully open (floor returns) when my heater is on full blast, fully closed when my cleaner is running, and somewhere in the middle for just the filter pump running.

[johnny2678]

This would be huge - as @tag said, not having remote control is what's keeping me from replacing all my valves with iValves

[rstrouse]

I have 8 IntelliValves currently installed. Happy to help where I can.

[mguinness]

Posted on TFP and thought it would be worth sharing here.

However, the 5-position feature of the IntelliValves will NOT function until Pentair releases the applicable firmware update.

That firmware update is reported now to occur in two phases (Phase I - adding RS-485 support on both the actuator side and IntelliCenter side and Phase II. - more advanced valve controls added to IntelliCenter features.)

Completion of Phase I should occur sometime after this next IntelliCenter firmware update (coming soon) and Phase II completion around Q4 of 2023. It's reported that IntelliValve support is the next major project for the software dev team after this next update.

[tagyoureit]

"I'm sure Pentair will 100% hold themselves to those dates/commitments" - No one, ever.

lol. Will believe it when I see it, but interesting to see some chatter about it anyway.

[bluemantwo]

I was able to buy several Intellivalves on eBay used. The issue with these valves is that they are not made to be repairable. Case is glued shut. Even worse, the internals (gear section) is also glued shut. But I was able to carefully open up 2 of them that had gear problems. The gears are metal, but the shafts are plastic and rather poor quality. Not sure why Pentair designed such expensive actuators that are so poorly made.

@jeffegg , one of the intellivalves had a motherboard that somehow got beat up really bad. Lost most of it's LEDs and push switches, and even a capacitor. But I was able to solder on the capacitor and it appears to operate OK. Just most of the LEDs missing. But if you need a board to mess with and not worry about bricking, I can send it to you.

[rock-crusher]

bluemantwo, think maybe you could post some pictures of the dissected Intellivalves?
I think we all would like to see the inside of them.
Thank You

[tagyoureit]

@bluemantwo Wow, it's been a few minutes! Glad to see you back here.

[jeffegg]

Sorry I've been super slammed at work for past 9 months. I do have a working firmware I wrote that will actually control the valve and set to a discrete locations via rs485 commands. Local control (buttons and wires with relays) are not implemented. I'm not using in my production environment yet. But on my desk seems stable when I can run once a month or so. I have my code on my local gitlab, but I can upload to the GitHub if there is interest. I also have a python script to upload the FW without using a programmer but this is really not well tested still and have not run in an environment where there are more than 1 device on the rs485 bus.

Here is my setup for debug:

Bunch of pictures of the valve I took:

[bluemantwo]

@bluemantwo Wow, it's been a few minutes! Glad to see you back here.

@tagyoureit LOL. Many, many minutes! How are you doing? I cannot thank you enough for the great work you have done supporting pool automation. I am still using a very old version of your software as my daily driver to run my pool. Only change I have been considering is getting it to update Home Assistant rather than my ISY. Have you done an interface to Home Assistant yet? I should try installing your latest software and give it a test drive. Though I do have a fondness for the initial pre-beta software you did so many years ago.

[bluemantwo]

@jeffegg Please let us know how we can load your firmware. It would be fun to play with.

When you say no local control, does that mean the red/white wires for selecting the 2 valve positions do not work? That would be a bummer since that is what all my existing devices expect. But HUGE thanks for doing this and sharing with us. If we can set the end points using RS485, and then select the end points using red/white wires, we would be golden!

[rstrouse]

njsPC is capable of isolating the valve control to a dedicated RS485 bus if you didn't follow the Pentair preamble sequence.

@bluemantwo - @Crewski has created an integration to Home Assistant that uses sockets and I am working on some pulls for him to add chemistry controller functionality to it as well as schedules.

[jeffegg]

@bluemantwo currently the FW does not support setting valve via the relay interface (red and white wires). Good news is this is completely a FW flow so its possible to add. I plan to make the end stops programmable via RS485 in the future and then have an option to enable/disable the relay interface also via RS485. Basically thinking there will be 3 modes the valve would operate at:

1. "Maintenance Mode" - when in this mode all RS485 control is dropped - valve will still respond to inquires and send out status but not able to remotely move. Good for when you don't want any automation to make your day bad. This mode can be entered via the mode button (actually this is supported today) or via RS485 command. Can only leave via mode button (safety feature)
2. "Relay Mode" - emulate what is there today, but have programmable endstops, status updates, etc via RS485.
3. "Full Automation Mode" - no relays needed; just power via black and either red or white. RS485 can fully control the valve (set current valve position) - this is mostly implemented

I need to start spending some time again on this as work is getting a bit "quieter" and I should have a free evening on the weekends coming up. I need to package up the FW to be loadable via the Pentair booloader. And verify the python code to invoke and use the bootloader. I don't develop this way and usually just write with the programmer

@rstrouse I followed the Pentair packet layout; actually using MessageCenter to send the commands to the valve before I dig into any of the Webcode.

    transmitBuffer[0] = 0xFF;
    transmitBuffer[1] = 0x00;
    transmitBuffer[2] = 0xFF;
    transmitBuffer[3] = 0xA5;
    transmitBuffer[4] = newCommand->protocal;
    transmitBuffer[5] = newCommand->destination;
    transmitBuffer[6] = newCommand->source;
    transmitBuffer[7] = newCommand->command;
    transmitBuffer[8] = newCommand->data_length;
    //DATA
    //CHECKSUM 

Command will be completely of my own creation; this is current "API". Not all command supported yet, and I need to fully document how this works. Here are my proposed commands

// Commands sent by the Valve
typedef enum
{
    VALVE_STATE             = 0x02, // Sent periodically
    VALVE_STATE_CHANGED     = 0x04, // Will Emit when state change finished
    VALVE_DEGREES           = 0x06, // Returns Byte(next position), Byte(0 - moving, 1 not moving), WORD(raw ADC)
    VALVE_DEBUG_DEGREES     = 0x08, // Returns Byte(next position), Byte(0 - moving, 1 not moving), WORD(raw ADC read twice), WORD(neededValue);
    VALVE_STARTING_UP       = 0xE0, // Valve is starting up - Done when 1st VALVE_STATE is sent
    VALVE_RESET_START       = 0xE2, // Valve will emit before resetting if reset command sent
    VALVE_SETTINGS          = 0xE4, // These are the valve settings
    VALVE_SETTINGS_DONE     = 0xE6, // Valve settings have been set and acknowledged
    VALVE_ADDR              = 0xEA, // My address
    VALVE_EEPROM            = 0xEC, // Valve EEPROM Data (For backup)
    VALVE_EEPROM_SET_DONE   = 0xEE  // Valve EEPROM Data (For backup
} rs485_send_commands;

// Commands received by the Valve
typedef enum
{
    //When any change takes place all commands dropped until job finished
    VALVE_GOTO_0_POSITION           = 0x10, // PORT at 0 position is closed
    VALVE_GOTO_24_POSITION          = 0x12, // PORT at 24 position is closed
    VALVE_GOTO_MIDDLE_POSITION      = 0x14, // Move valve to middle position (all open)
    VALVE_SET_DEGREES               = 0x16, // Set a specific value (This between 0 and 0x30, so step size is 180/48=> 3.75)
    VALVE_GET_DEGREES               = 0x17,
    VALVE_SET_DEGREES_FROM_CURRENT  = 0x18,
    
    VALVE_REMOTE_CONTROL            = 0x20, // Valve will enter remote control mode and accept commands if 1st packet is 1; else exit remote mode
            
    VALVE_ENTER_MAINTENACE_MODE     = 0x40, // Valve will move to Yellow Led mode and not respond to remote commands that change state/settings
                                            // !!! No way out remotely - for safety/security, need to exit at pad !!! Can also be set at Pad
                                            // Should still emit VALVE_STATE messages periodically with indication of this mode
    VALVE_DEBUG                     = 0xE0, // Enter a debug mode that outputs lots of data -- Use with caution;
    VALVE_RESET                     = 0xF1, // Forces valve to reset; used for FW Update
    VALVE_FW_UPDATE                 = 0xF3, // Enter FW update on next boot
    VALVE_GET_SETTINGS              = 0xF5, // Returns current valve settings (no state)
    VALVE_SET_SETTINGS              = 0xF6, // Sets valve settings (not state)
    VALVE_GET_ADDR                  = 0xF7, // Gets the valves UUID and address (Part of settings but added shortcut)
    VALVE_SET_ADDR                  = 0xF8, // Sets the valves address, need to pass data as UUID (6 bytes), 0x0, newAddr
    VALVE_GET_EEPROM                = 0xF9, // Gets the EEPROM for backup
    VALVE_SET_EEPROM                = 0xFA, // Use with extreme caution - will overwrite EEPROM      
            
} rs485_receive_commands;

[bluemantwo]

Fan-freakin-tastic! Can't wait. Well, actually, I can. No real rush on this but this is a function I have been wanting for years. Even before the Pentair IntelliValves were released I envisioned something like this. Very cool.

For those who want to plunge into this, there is a guy selling these valves on eBay for about $40 each (try Make an Offer) but sells them as broken. I bought 3 and was able to cobble 2 working ones out of it. Downside is that these are some of the most cheaply made and unreliable devices I have yet seen from Pentair. And I have seen a lot.

[rstrouse]

Awesome! So there are a couple of things that will help let this play nicely on the Pentair bus. First, once the addressing takes place there is no need for a slave to emit anything unless asked. In fact chlorinators can be tardy sometimes when they are polled so they are collision monsters. The software (master) should send a request to the slave (valve) and it should return the expected bytes.

There are a couple of posts on TFP where folks have hooked up 5+ IntelliValves to RS485 and the groot messages appear to degrade their RS485 network. Once the valve is addressed (the one thing we figured out how to do) it stops sending groot messages until asked. It only does this because it is very likely that a broadcast with many valves is likely to end in missing valves. These addresses seemed to persist until you reset them to the broadcast and it would then start grooting again.

I do know what Pentair was going to do wrt the programming. The rumor mill said that there would be 5 sets of position that could be selected by the mode operation on the pool and each would have 2 endpoints. I do not know whether the valve itself stored this information or it was set only by the master. Likely, it stored at least one active endpoint set.

The reason for this is so the valves home to the default position if RS485 is interrupted. The OCP has sort of a halt state that moves everything to an idle state when power is still on and the comms fail. This is also how the service mode operation works.

All of the equipment items do this. So if the watchdog on the pump, heater, or chlorinator doesn't get a message after a specified period of time it will stop. For valves this is currently done in the OCP where it will simply cut coil power to the relay and the valve will move to the home position.

Not that this is the only way to skin this cat but I suspect the flow was going to go like this from Pentair.

1. Onboard the valve by assigning it an address. Currently (1-16 = System/Controllers, 80-84=Chlorinators, 95-111 = Pumps, 112-127=Heaters, 144-158 = IntelliChem)
2. Send a position marker at regular intervals to the valve with both endpoints.
3. Valve responds with the current position
4. If the position does not match what the OCP expects, continue to poll until the valve matches its expected position.
5. When the position is reached continue operation and cancel valve delays.

Although I cannot be sure, I suspect that the relay on the OCP is still in play. It simply energizes which leg it wants to match the valve position and the endpoint stop then determines where it should land. There is a thing in the valve programming to reverse it but this is only to accommodate installing the valve 180 degrees either direction.

My belief is that they expect to send in an endpoint pair then energize the diverted or undiverted state depending on the current operation of equipment.

[tagyoureit]

@tagyoureit LOL. Many, many minutes! How are you doing? I cannot thank you enough for the great work you have done supporting pool automation. I am still using a very old version of your software as my daily driver to run my pool. Only change I have been considering is getting it to update Home Assistant rather than my ISY. Have you done an interface to Home Assistant yet? I should try installing your latest software and give it a test drive. Though I do have a fondness for the initial pre-beta software you did so many years ago.

The software has come SOOOO far since those early days. It's almost embarrassing how many times I had to go back and forth to get it right. The software is just amazing now and much of that is due to @rstrouse. We've re-written it since those early days.

There is a Home Assistant plugin but there is an even better one from @Crewski https://github.com/Crewski/njsPC-HA and the associated discussion and it can be installed from the HACS repo.

You'll be happy with where we are and never look back at that ancient code again!

[bluemantwo]

@jeffegg , you able to make any more progress?

[jeffegg]

Ok I can generate a new FW uploader tonight that dumps more info. Did hitting the buttons help?
Did you try njsPC? The fw uploader is very basic and doesn't have many features.

[bluemantwo]

Hitting the buttons on the existing 2 valves that I tried to flash does not generate any activity on the bus. It does on the 3rd valve that was not flashed yet. But rather than jump to conclusions, I need to slow down and take a more methodical approach to this. I might have done something else wrong. Would not be the first time!

[bluemantwo]

Well, I was finally able to get the valve that originally was on 0.2.1 to 0.3.1. It now shows up reliably in the updater tool and shows it is on the new firmware.

The other valve that I had tried to flash with 0.3.0 is in a state where the Red/Blue/Yellow lights are all flashing on and off repeatedly. Not sure if bricked or just in an odd mode. No communications over the bus, even when save/red buttons pressed. Appears inert.

3rd factory valve also shows up reliably, but is still on factory firmware.

[jeffegg]

We should be able to recover any valve. The bootloader is pretty protected from damage. It sounds like that valve didn't get a full FW download or maybe the EEPROM is corrupted. You can try updating the FW by power cycling it. I can update the fw uploader to better walk through the process. But good to see at least 1 is working

[bluemantwo]

@jeffegg , I am not too worried about the valve that is locked up. But if there is an easy way to reload a new firmware, let me know. But low priority to me. I am going to update a few more to 3.1 just to see how things go.

[MaxVonEvil]

I've been following this thread with interest. That said I do not have any itellivalves, instead I have some, ahem.. ratherStupidValves ;) i.e. regular Jandy-valves with standard dual-position 24VAC valve actuators. Just wanted to chip in how I made those variable. It's rather simple and rather low-tech, compared to the Intellivalve hacking.

Full disclosure, I currently only use NJSPC for my pump, as all the rest including the house was already run by Homeassistant/NodeRed, with an ESP32 running Tasmota at the poolgear. I've adjusted the camber wheels inside my valve actuators so they can travel the range I need.

I'm using two relays per valve; one for direction, another to cut actuator power after x seconds of travel. Initially measured by stopwatch, I know it takes about 36 seconds for my actuators to turn a valve 180 degrees. So say I want maindrain vs. skimmer flow at say 25/75%, and since I know the state of the 1st relay, I know which direction the actuator will be traveling. Depending of direction I cut the power to the actuator after either 9 seconds or 27 seconds and it stops where I want it. If the timing gets out of whack (like after multiple relative moves, as my setup has about 20-50ms lag) and I eventually need to resync the position actuator, I can power the actuator on for 36 seconds and I know it will be at the endpoint which the first relay controls.

Again super interesting work on the alternate firmware, just wanted to share an alternative for those who do not have these valves.

[bluemantwo]

@jeffegg , still having problems reliably talking to valves for firmware update. I run the firmware updater (0.3.2), and it puts my valve (firmware 0.3.1) into all red lights blinking mode. So it is talking to it. But it never finds the valve in the list, always giving "Valve Not Found". I did get it to find it once out of about 20 tries, but it failed in updating to 0.3.2. Tried power cycling but no joy there either. Very strange.

I tried using another RS485 adapter just in case that was the issue, but same result.

Now have 2 valves stuck in red/green/blue flashy mode and not responding to anything. I might stand down for a bit to see if anyone else is having issues or if it might be unique to my setup. If you do have instructions for restoring bricked valve, let me know and I will try it.

Also, I see that on 0.3.1, the valve rotate buttons are working in Service mode, but the directions are reversed.

[jeffegg]

V0.3.2, I released last night fixes a communication issue on the transmit path that could be your problem. After this I reliably see all my valves working. I also have this working in my production environment now.
Ok I'm not sure what is happening to your valves. I'm flashing 4 valves in my setup without seeing failures. Can you describe your setup, cable lengths, how you do connections, cable types, etc? I do recognize my setup is a best case on my desk with minimal EMI.
Can you describe the stuck valves? Does it flash blue for like 30 seconds, then turn to auto mode (green led) and then show all the red position LEDs.
I'm recommend maybe keeping it to 1 valve right now connected to the rs485.
The valve updater is something I've spent only a little time on, let me make it a bit better with some logging for me, and better prompts, etc.

Did your write the UUID of your valves down? If not I recommend this in the future it may help.

[bluemantwo]

The bricked valves both flash blue (set) light 4 times (about 2-3 seconds total) and then go into all 3 mode lights flashing at same time (Auto, Set, Service). I am pretty sure I know the UUID of each valve from log files I kept.

My set up is on my bench indoors (not connected to any other pool equipment). Raspberry Pi 3+, latest bulleye update, python 3.9.2. 24VAC transformer to valves (black, red, with white no connection), green to negative, yellow to positive of RS485 USB stick. No other programs starting (REM, njsPC, etc are disabled).

[bluemantwo]

For the Valve with 0.3.1 firmware on it, when I try to connect, all the RED LEDS that show position flash at once (0-24 positions) indicating that the valve is getting communications, but it never shows up in the list. Here is what I get when I try:

pi@pool3 ~/fwupdate/EggysIVFW-0.3.2/SW/IntelliValveFWUpdater $ python
Python 3.9.2 (default, Mar 12 2021, 04:06:34)
[GCC 10.2.1 20210110] on linux
Type "help", "copyright", "credits" or "license" for more information.

import main
fwu = main.FWUpdater()
fwu.fw_updater()
Index Device Product Serial # HW ID

---

  1  /dev/ttyUSB0  USB2.0-Serial              USB VID:PID=1A86:7523 LOCATION=1-1.4
  2  /dev/ttyAMA0                             3f201000.serial

Default RS485 device is (hit enter to select): /dev/ttyUSB1
Please select the index of your RS485 device: 1
Device /dev/ttyUSB1 was selected.
Opening serial port: /dev/ttyUSB0
Forcing all address reset on all Pentair FW Valves
Waiting 5 seconds for message to send and valves to quiet a bit
Sending ID valves packet to Valves with Eggy's Intellivalve Firmware
Waiting 5 seconds for message to send and valves to quiet a bit
Listening to /dev/ttyUSB0 for 30 seconds.
Closing Serial Port: /dev/ttyUSB0

Index ID Tag Name Prerelease Publish Date Has FW release

---

  1  0x6f1bd70  v0.3.2  Version 0.3.2 - alpha release              False         2023-08-12T09:32:25Z  True
  2  0x6e8471f  v0.3.1  Version 0.3.1 - alpha release              False         2023-08-10T08:44:49Z  True
  3  0x6e143a2  v0.3.0  Version 0.3.0 - alpha release              False         2023-08-07T08:35:13Z  True
  4  0x6e061ac  v0.2.5  Version 0.2.5 - alpha release              False         2023-08-06T08:52:58Z  True
  5  0x6d4d280  v0.2.4  Version 0.2.4 - alpha release              False         2023-08-01T08:05:07Z  True
  6  0x6d24623  v0.2.3  Version 0.2.3 - alpha release              False         2023-07-31T07:37:27Z  True
  7  0x6d17d0f  v0.2.2  Version 0.2.2 - alpha release - test only  True          2023-07-30T08:29:35Z  True
  8  0x6bf8208  v0.2.1  Version 0.2.1 - alpha release              False         2023-07-23T07:46:43Z  True
  9  0x6bf0a14  v0.2.0  Version 0.2.0 - alpha release              True          2023-07-22T08:25:46Z  True
 10  0x6a53e25  v0.1.1  Version 0.1.1 - Pre-Alpha Release          True          2023-07-08T09:17:30Z  True
 11  0x6a5364e  v0.1.0  Version 0.1.0 - Pre-Alpha Release          True          2023-07-08T07:48:16Z  True
 12  0x68b86f1  v0.0.1  DirtyUnsupportedFW                         True          2023-06-25T09:15:16Z  False
 13  0x5966af9  v0.0.0                                             True          2023-02-27T06:05:59Z  False

Please select the fw release: 1
Index Address UUID Git Hash Git Date Branch Tag DID RID

---

  1             Valve Not found  N/A

Please select the index of the Valve for FW update:

[bluemantwo]

I am trying to manual flash a firmware using the known UUID, but it is unclear if I am doing this correctly. See below:

Listening to /dev/ttyUSB0 for 30 seconds.
Closing Serial Port: /dev/ttyUSB0

Index ID Tag Name Prerelease Publish Date Has FW release

---

  1  0x6f1bd70  v0.3.2  Version 0.3.2 - alpha release              False         2023-08-12T09:32:25Z  True
  2  0x6e8471f  v0.3.1  Version 0.3.1 - alpha release              False         2023-08-10T08:44:49Z  True
  3  0x6e143a2  v0.3.0  Version 0.3.0 - alpha release              False         2023-08-07T08:35:13Z  True
  4  0x6e061ac  v0.2.5  Version 0.2.5 - alpha release              False         2023-08-06T08:52:58Z  True
  5  0x6d4d280  v0.2.4  Version 0.2.4 - alpha release              False         2023-08-01T08:05:07Z  True
  6  0x6d24623  v0.2.3  Version 0.2.3 - alpha release              False         2023-07-31T07:37:27Z  True
  7  0x6d17d0f  v0.2.2  Version 0.2.2 - alpha release - test only  True          2023-07-30T08:29:35Z  True
  8  0x6bf8208  v0.2.1  Version 0.2.1 - alpha release              False         2023-07-23T07:46:43Z  True
  9  0x6bf0a14  v0.2.0  Version 0.2.0 - alpha release              True          2023-07-22T08:25:46Z  True
 10  0x6a53e25  v0.1.1  Version 0.1.1 - Pre-Alpha Release          True          2023-07-08T09:17:30Z  True
 11  0x6a5364e  v0.1.0  Version 0.1.0 - Pre-Alpha Release          True          2023-07-08T07:48:16Z  True
 12  0x68b86f1  v0.0.1  DirtyUnsupportedFW                         True          2023-06-25T09:15:16Z  False
 13  0x5966af9  v0.0.0                                             True          2023-02-27T06:05:59Z  False

Please select the fw release: 1
Index Address UUID Git Hash Git Date Branch Tag DID RID

---

  1             Valve Not found  N/A

Please select the index of the Valve for FW update: 1
Please enter the valve UUID in format xx-yy-zz-uu-tt-ss: 80-34-28-28-21-59
Enter Eggy's FW for new valve FW or Pentairs's FW for pentair FW: ????What do I put here?????
Enter Address in Hex format (i.e. 0xA0): 0xB3
Valve 80-34-28-28-21-59 was selected.
Reallocated Valve Address if needed

I was not sure what to put for the "Enter Firmware" question.

[jeffegg]

Enter either of the two:
Eggy's FW
Pentairs's FW

If you don't see the valves enter FW update mode move to blue blinking mode light when commanded you will need to do this manually by power cycling the valve.

[bluemantwo]

OK, that is what I was doing. Here is what happens:

The valve goes into all red lights flashing mode after "lease select the index of your RS485 device: 1"

It then goes into the mode where it is trying to flash the firmware, after entering "Enter Address in Hex format (i.e. 0xA0): 0xA0"

I then power cycle the valve, and it goes into blinky blue mode, with the 0 LED lit, indicating it is ready for programming. Then nothing happens. It just tries then quits. See terminal log below:

fwu.fw_updater()
Index Device Product Serial # HW ID

---

  1  /dev/ttyUSB0  USB2.0-Serial              USB VID:PID=1A86:7523 LOCATION=1-1.2
  2  /dev/ttyAMA0                             3f201000.serial

Default RS485 device is (hit enter to select): /dev/ttyUSB0
Please select the index of your RS485 device: 1
Device /dev/ttyUSB0 was selected.
Opening serial port: /dev/ttyUSB0
Forcing all address reset on all Pentair FW Valves
Waiting 5 seconds for message to send and valves to quiet a bit
Sending ID valves packet to Valves with Eggy's Intellivalve Firmware
Waiting 5 seconds for message to send and valves to quiet a bit
Listening to /dev/ttyUSB0 for 30 seconds.
Closing Serial Port: /dev/ttyUSB0

Index ID Tag Name Prerelease Publish Date Has FW release

---

  1  0x6f1bd70  v0.3.2  Version 0.3.2 - alpha release              False         2023-08-12T09:32:25Z  True
  2  0x6e8471f  v0.3.1  Version 0.3.1 - alpha release              False         2023-08-10T08:44:49Z  True
  3  0x6e143a2  v0.3.0  Version 0.3.0 - alpha release              False         2023-08-07T08:35:13Z  True
  4  0x6e061ac  v0.2.5  Version 0.2.5 - alpha release              False         2023-08-06T08:52:58Z  True
  5  0x6d4d280  v0.2.4  Version 0.2.4 - alpha release              False         2023-08-01T08:05:07Z  True
  6  0x6d24623  v0.2.3  Version 0.2.3 - alpha release              False         2023-07-31T07:37:27Z  True
  7  0x6d17d0f  v0.2.2  Version 0.2.2 - alpha release - test only  True          2023-07-30T08:29:35Z  True
  8  0x6bf8208  v0.2.1  Version 0.2.1 - alpha release              False         2023-07-23T07:46:43Z  True
  9  0x6bf0a14  v0.2.0  Version 0.2.0 - alpha release              True          2023-07-22T08:25:46Z  True
 10  0x6a53e25  v0.1.1  Version 0.1.1 - Pre-Alpha Release          True          2023-07-08T09:17:30Z  True
 11  0x6a5364e  v0.1.0  Version 0.1.0 - Pre-Alpha Release          True          2023-07-08T07:48:16Z  True
 12  0x68b86f1  v0.0.1  DirtyUnsupportedFW                         True          2023-06-25T09:15:16Z  False
 13  0x5966af9  v0.0.0                                             True          2023-02-27T06:05:59Z  False

Please select the fw release: 1
Index Address UUID Git Hash Git Date Branch Tag DID RID

---

  1             Valve Not found  N/A

Please select the index of the Valve for FW update: 1
Please enter the valve UUID in format xx-yy-zz-uu-tt-ss: 80-34-28-28-21-59
Enter Eggy's FW for new valve FW or Pentairs's FW for pentair FW: Eggy's FW
Enter Address in Hex format (i.e. 0xA0): 0xA0
Valve 80-34-28-28-21-59 was selected.
Reallocated Valve Address if needed

Opening serial port: /dev/ttyUSB0
Forcing valve address: 0xa0 uuid: 80-34-28-28-21-59 to reset
Closing Port
Setting valve 80-34-28-28-21-59 to 0xa0
Setting valve 80-34-28-28-21-59 to 0xa0
Opening serial port: /dev/ttyUSB0
programming 0x0F80
Unexpected packet read: vs ff-00-ff-a5-01-10-a0-01-01-f5 on line {'byte_count': 64, 'address': '0F80', 'data': '8731CB2FFF34FF347E148731AF313C2787317E10090020000308A0008F317B2F2200B9002200BA01F62F22003A082200B700B801370822003407860022003808', 'checksum': None}
retry 0 of 10 and retry of retry 0
Setting valve 80-34-28-28-21-59 to 0xa0
Setting valve 80-34-28-28-21-59 to 0xa0
programming 0x0F80
Unexpected packet read: vs ff-00-ff-a5-01-10-a0-01-01-f5 on line {'byte_count': 64, 'address': '0F80', 'data': '8731CB2FFF34FF347E148731AF313C2787317E10090020000308A0008F317B2F2200B9002200BA01F62F22003A082200B700B801370822003407860022003808', 'checksum': None}
retry 1 of 10 and retry of retry 1
Setting valve 80-34-28-28-21-59 to 0xa0
Setting valve 80-34-28-28-21-59 to 0xa0
programming 0x0F80
Unexpected packet read: vs ff-00-ff-a5-01-10-a0-01-01-f5 on line {'byte_count': 64, 'address': '0F80', 'data': '8731CB2FFF34FF347E148731AF313C2787317E10090020000308A0008F317B2F2200B9002200BA01F62F22003A082200B700B801370822003407860022003808', 'checksum': None}
retry 2 of 10 and retry of retry 2
Setting valve 80-34-28-28-21-59 to 0xa0
Setting valve 80-34-28-28-21-59 to 0xa0
programming 0x0F80
Unexpected packet read: vs ff-00-ff-a5-01-10-a0-01-01-f5 on line {'byte_count': 64, 'address': '0F80', 'data': '8731CB2FFF34FF347E148731AF313C2787317E10090020000308A0008F317B2F2200B9002200BA01F62F22003A082200B700B801370822003407860022003808', 'checksum': None}
retry 3 of 10 and retry of retry 3
Setting valve 80-34-28-28-21-59 to 0xa0
Setting valve 80-34-28-28-21-59 to 0xa0
programming 0x0F80
Unexpected packet read: vs ff-00-ff-a5-01-10-a0-01-01-f5 on line {'byte_count': 64, 'address': '0F80', 'data': '8731CB2FFF34FF347E148731AF313C2787317E10090020000308A0008F317B2F2200B9002200BA01F62F22003A082200B700B801370822003407860022003808', 'checksum': None}
retry 4 of 10 and retry of retry 4
Setting valve 80-34-28-28-21-59 to 0xa0
Setting valve 80-34-28-28-21-59 to 0xa0
programming 0x0F80
Unexpected packet read: vs ff-00-ff-a5-01-10-a0-01-01-f5 on line {'byte_count': 64, 'address': '0F80', 'data': '8731CB2FFF34FF347E148731AF313C2787317E10090020000308A0008F317B2F2200B9002200BA01F62F22003A082200B700B801370822003407860022003808', 'checksum': None}
retry 5 of 10 and retry of retry 5
Setting valve 80-34-28-28-21-59 to 0xa0
Setting valve 80-34-28-28-21-59 to 0xa0
programming 0x0F80
Unexpected packet read: vs ff-00-ff-a5-01-10-a0-01-01-f5 on line {'byte_count': 64, 'address': '0F80', 'data': '8731CB2FFF34FF347E148731AF313C2787317E10090020000308A0008F317B2F2200B9002200BA01F62F22003A082200B700B801370822003407860022003808', 'checksum': None}
retry 6 of 10 and retry of retry 6
Setting valve 80-34-28-28-21-59 to 0xa0
Setting valve 80-34-28-28-21-59 to 0xa0
programming 0x0F80
Unexpected packet read: vs ff-00-ff-a5-01-10-a0-01-01-f5 on line {'byte_count': 64, 'address': '0F80', 'data': '8731CB2FFF34FF347E148731AF313C2787317E10090020000308A0008F317B2F2200B9002200BA01F62F22003A082200B700B801370822003407860022003808', 'checksum': None}
retry 7 of 10 and retry of retry 7
Setting valve 80-34-28-28-21-59 to 0xa0
Setting valve 80-34-28-28-21-59 to 0xa0
programming 0x0F80
Unexpected packet read: vs ff-00-ff-a5-01-10-a0-01-01-f5 on line {'byte_count': 64, 'address': '0F80', 'data': '8731CB2FFF34FF347E148731AF313C2787317E10090020000308A0008F317B2F2200B9002200BA01F62F22003A082200B700B801370822003407860022003808', 'checksum': None}
retry 8 of 10 and retry of retry 8
Setting valve 80-34-28-28-21-59 to 0xa0
Setting valve 80-34-28-28-21-59 to 0xa0
programming 0x0F80
Unexpected packet read: vs ff-00-ff-a5-01-10-a0-01-01-f5 on line {'byte_count': 64, 'address': '0F80', 'data': '8731CB2FFF34FF347E148731AF313C2787317E10090020000308A0008F317B2F2200B9002200BA01F62F22003A082200B700B801370822003407860022003808', 'checksum': None}
retry 9 of 10 and retry of retry 9
Setting valve 80-34-28-28-21-59 to 0xa0
Setting valve 80-34-28-28-21-59 to 0xa0
programming 0x0F80
Unexpected packet read: vs ff-00-ff-a5-01-10-a0-01-01-f5 on line {'byte_count': 64, 'address': '0F80', 'data': '8731CB2FFF34FF347E148731AF313C2787317E10090020000308A0008F317B2F2200B9002200BA01F62F22003A082200B700B801370822003407860022003808', 'checksum': None}
Packet never sent after 10 retries exiting. Valve will be in a bad state.Please try to quiet RS485 and/or increase retries
Trying to force exit FW mode, sleeping for 20 seconds
Sleeping another 5 seconds

At this point it exist blinky blue mode and returns to normal Auto mode.

[jeffegg]

I can see this being an issue, can you try with address 0xC instead? When the valve resets in the bootloader 0xc is the address I suspect this could be the issue there.
I'm working on a better flashing routine to work though any of these issues but will take some time.

[bluemantwo]

Tried 0xc but same result

Originally, after flashing 0.2.1, it was 0xB3. Tried that as well and no joy.

Again, no rush on this. I just had some spare cycles and was trying different things with it. This does not impact my production environment in any way.

[jeffegg]

Hmm this is really odd, its like the valve isn't talking at all but the bootloader should be talking, this is code that I don't/cannot change. But something odd is happening,
Last experiment I can think of, I just tried this and it works, I've attached the updater FW as I have it now.

1. Remove power from valves (best to only use the valve you want to program if possible)
2. Start the FW updater
3. Do the valve not found routine
4. Enter the following
   Valves UUID
   Eggy's FW
   0xA0 address is fine:
5. Give power to valve when you see
   Waiting to see valve with uuid: xx-xx-xx-xx-xx-xx reset
6. You should see
   Valve looks to have reset
   Sending Packet to address: 0xa0 uuid: 44-b7-d0-c9-cf-f4 to keed device in bootloader mode

Then it should flash
IntelliValveFWUpdater.zip

[bluemantwo]

Bingo! Good flash (only took 30 seconds or so!) and now identifies just fine. Yes!!!

I might give a try with the Valve that is bricked to see if that procedure works on it. THANKS!!!

[bluemantwo]

No luck with the valve that has flashing bottom 3 LEDS (Auto/off, Set, Service). It does flash SET blue led 4 times when powering it up, but I cannot get it to enter firmware flash mode.

[jeffegg]

@bluemantwo I'm willing to trade you a good valve for that one, so I can see what is going on there. I can get the logic analyzer on there to see what is happening and pull/debug the FW. The only thing I can think of is that the EEPROM was corrupted.There is 1 more possibility, I need to look at the bootloader tonight, there is an override if I remember when you hold the save button on valve power up. I cannot remember what it does but maybe still a recovery path available

[bluemantwo]

I have more valves than I need, so would be happy to just send the logic board from this one if we cannot recover it. No worries. If we cannot fix in the next week or so, PM me your mail address and I will send it over.

[jeffegg]

If I corrupt the EEPROM with write 0 or 1's, I can definitely make some weird stuff happen like skipping the bootloader code.
I saw 2 things that were able to get in the bootloader:

1. There is a single byte in EEPROM that will cause the bootloader to be skipped unless the user holds down the SAVE button on a reset or power up. At this point the valve will enter bootloader mode temporarily and go right to the Valve FW without sending any RS485 messages or waiting on any.
2. Empirically I saw a case where I had to power down the valve and remove the USB RS485 dongle to get anything working. I think the EEPROM entered a bad state and wouldn't release one of the I2C lines until voltage was gone, including it seems leakage.

My recommendation to try is to run the Update FW and point it to the bad valve like you did the others and hold the save button when you see the message:
Waiting to see valve with uuid: xx-xx-xx-xx-xx-xx reset
You may need to hold for some time to get it for some time, the new FW above does a setup, reset, and look for the valve hail message from the bootloader, before I continue, it will try 10 times with 15 seconds of wait time between cycles. I was able to flash a valve that was skipping the FW this way. Hopefully you will see similar behavior

If you can get the valve to flash, let me know. I will get a new FW out that looks for EEPROM corruption of certain critical regions and tries to fix (I know of about 6 entries I need, and the bootloader now needs).

[bluemantwo]

2. Empirically I saw a case where I had to power down the valve and remove the USB RS485 dongle to get anything working. I think the EEPROM entered a bad state and wouldn't release one of the I2C lines until voltage was gone, including it seems leakage.

THIS. I also have found this to be true. Could not get response from valve until pulling the USB R485 AND powering down the valve. Several times. I came to same conclusion that leakage current from RS485 was keeping something alive on the valve.

[bluemantwo]

Not able to make any progress on the valve with blinky 3 lights. Pressing Save during power up did not seem to make any difference. I did get it to once self identify by constantly glitching the power to the valve, it still would not flash. I will just set that valve aside for now. Maybe we can come back to it later or I can send you the controller board from it if you wish to evaluate. No need to return it afterwards.

BTW, I am noticing that the valve does Hail when first powered up, so it is not totally inert. I provides its UUID and address:

[8/14/2023, 9:10:47 AM] info: Serial port: /dev/ttyUSB0 request to open successful 9600b 8-none-1
[8/14/2023, 9:10:52 AM] info: Hail Seen(82) from valve with Pentair FW: 12, with data: 0,128,4,145,98,214,72,221
[8/14/2023, 9:10:52 AM] info: Valve UUID: 4,145,98,214,72,221

from njsPC log when running njsPC (of course, normally I have this process stopped).

[bluemantwo]

Also, now that I can see the valve hailing, I can confirm that it is the same valve that the log taken several days ago (attached) shows was updated to Firmware 0.3.0, but in reality a different valve was updated to 0.3.0 (a valve that is now working after using your new procedure). So somehow having multiple valves connected to RS485 during flashing resulted in the wrong valve being updated even though the log shows it was targeting the correct valve (the valve that is now bricked). Very odd.
log.txt

[jamestalmage]

Making some plans here w/ regard to my own systems wiring (don't own any intellivalves yet)... Will I need RS485 AND Relay outputs? Or will be able to fully control it via RS485 and just send the valves constant power?

[jeffegg]

@jamestalmage - Technically no need for relays you should be able to connect 1 leg of the valve to +24VAC and other to common and your valve would work without. I have code now that allows the endpoint selection without using the relays

[jamestalmage]

@jeffegg Amazing! Do we know if that's the plan for the official Pentair firmware, or just the hacked version? Either way, cool. I'm just a few weeks from closing for the season, so hoping I've got good options for spring.

[tagyoureit]

Pentair has been threatening planning intellivalve software and functionality for years. If they ever release it, I'll be looking for flying unicorns, pots of gold at the end of rainbows, and mermaids. But you won't need both relay and rs485 control.

[mguinness]

But you won't need both relay and rs485 control.

Indeed, it would open the possibility that the entry level IntelliConnect system could control valves for water features. But in reality it would never come to pass.

[mguinness]

Apparently Pentair are planning updated firmware, see IntelliValve Upgrade Update for details.