tagyoureit / nodejs-poolController

An application to control pool equipment from various manufacturers.
GNU Affero General Public License v3.0
323 stars 94 forks source link

Documenting Pentair Intellivalve communications #363

Open jeffegg opened 2 years ago

jeffegg commented 2 years ago

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]

bluemantwo commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago
  1. 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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

@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 commented 11 months ago

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 commented 11 months ago

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 commented 6 months ago

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