r,Hey all, I am going to chime in here on a couple of topics.
I noticed a couple of posts back the notion of the unidentified lists of circuits on the webapp. These are virtual circuits that fall outside of the common aux circuits, features, and groups. Command level states like Pump Speed +/-, All Lights On/Off, and Heat Boost/Enable that lurk around in the menus like this are really there as selections for remotes. Unfortunately, they aren't filtered out in some of the webapp. The others like Pool Heater, Spa Heater, Freeze, and Solar are only set based upon conditions of the other equipment in the pool. They are calculated states and the OCP (Outdoor Control Panel) sets these whenever specific conditions are met. In the end these are used to trigger things like valves, pump speeds and even covers. I can only speculate but the most likely reason they show up in inappropriate places is because the the ids for these are all mixed together and haven't been filtered appropriately in the web app. That means there should be a separate list for groups, pumps, remotes, and valves.
I am going full on techie here so bear with me. The IntelliValve protocol continues to be elusive. While there is much talk about the stubborn "I am Groot" message, here is an example of one.
[255, 0, 255][165, 1, 16, 12, 82, 8][0, 128, 216, 128, 57, 64, 25, 166][4, 44]
The brackets from the left to the right are as follows [255, 0, 255] is an RS485 preamble and is nothing of note. This simply notifies the communications that a message is about to follow. The bytes in the next set of brackets [165, 1, 16, 12, 82, 8] are the header for the message. 165 is a controller code, 1 is a channel code, 16 is the destination address of which 16 is broadcast and 12 is a source address. 82 indicates an action or command and 8 is the length of the next set of bytes which happen to be the data payload. This header is constant for all "I am Groot" messages sent and the last two bytes [4, 44] is simply a checksum so that those reading the data can know that the message is complete.
The most important part of this message is the payload. Here is what we know about the payload. As of today, it always starts with 0, 128. This could be simply a placeholder but it could make sense that this is the minimum and maximum setpoints capable for the valve in question (although 0, 180 would seem to make more sense but 128 is also -0). We know it is not the current status nor does it represent the current endpoints of the valve. No matter what you do on the valve, the message is always the same...I am Groot. That being said it could also change once we have addressed the valve. The following 6 bytes are unique to each valve we have witnessed in the wild. Interestingly anyone familiar with network adapter addresses could draw the conclusion that 6 bytes = MAC address. While these aren't NICs this very well could be the hardware address of the valve. We have noticed that valves manufactured around the same time seem to have similar 4 byte values from the start of the suspected address. Heck 0, 128 could be the OUI for all we know (for those of you familiar with MACs). The ones below are manufactured in 2019 and the one above in 2016.
[255, 0, 255][165, 1, 16, 12, 82, 8][0, 128, 128, 31, 18, 75, 154, 185][3, 235]
[255, 0, 255][165, 1, 16, 12, 82, 8][0, 128, 128, 31, 18, 76, 39, 119][3, 55]
[255, 0, 255][165, 1, 16, 12, 82, 8][0, 128, 128 31, 18, 79, 209, 34][3, 143]
This is why we believe it to be an address for the valve. Ok, so if this is an address we now need to determine what might trigger the valve to pick up what we are laying down. I suspect that the destination address will not be 12 when we send it back. The reason is that the kids on the RS485 bus seem to be addressed as follows.
12 = Hail (I am Groot) iChlor also sends a notification on 12 and we have heard of this address being anecdotally reported for unidentified equipment.
15 = OCP (Outdoor Control Panel)
16 = Broadcast (To whom it may concern)
32-35 Aux Control Panels (32 = Spa Command, 33 = Slaves, 34 = ScreenLogic, 35 = iLink)
96-111 = Pumps
113-128 = Heaters/Heatpumps
144-159 = Chem Controllers
The way this works can be illustrated by how you talk to a pump on the RS485 bus. First you send it a request from one of the addresses to the address of the pump. For instance 16 to 96 and the pump will respond from 96 to 16. This will talk to pump #1. Pump #2 will be 97... etc. Perhaps somewhere in the values 0-255 with the aforementioned excluded the address of the valve can be set. Addresses prior to 12 are probably not it (primarily because you need 26 spaces). So this leaves something in the range of 36-95 or 160-255. If each valve eventually gets its own RS485 address then there needs to be 26 potential addresses for the range. This is assuming that the valve is addressed to the system.
The primary reason for doing this is so that the valve can be identified by a single byte rather than carrying around 6 bytes for the internal functions of the valve. Any equipment monitoring the status from the valve or commands to the valve don't have to process every byte on the bus. It can simply stop reading on the 3rd byte in and wait for the next preamble. There are a lot of messages on this bus and if the valve had to pick each one of them up to determine if the 6 bytes exist then yikes. This will also likely map the valve ids as they are for non-IntelliValve CV24s in the controller. If this follows the Pentair protocol habits the action will be 82, 210, or 81 but even that byte is suspect.
I am pretty sure the valve does not store more than one set of setpoints. That would be illogical and groot does not contain anything regarding the current state of the valve although 0, 128 could have some meaning once it is controlled. As I said above this could also be an OUI if the tech gets licensed to someone else. Who knows Jandy has that goofy Smart JVA and Hayward has that manly looking automated ball valve (I guess if it's on a ball valve).
So who's up for solving a puzzle that is a conundrum wrapped in an enigma?
1. Thanks for taking care of that big question mark going around in my brain regarding the "virtual circuit" entries that show up when attempting to create a feature circuit in the web client. Makes total sense now after your explanation.
2. Great summary on the IntelliValve status at this point. I had to read it about 4 times and only wish that I could say that it makes complete sense to me. But it does make a little more sense than what I got after the first read lol... Hey, you warned us you were going "full on techie". No doubt there lol....
BTW, message received over on the other side regarding what specifically to ask for regarding the IntelliValve. I, just like yourself and others, are not giving my effort a "snow balls" chance, but I've drafted my response and am preparing to send (along with the attachments that show that they are willing to provide the API's that @guinness, so timely reminded me of). I might as well take advantage of my current dialogue with management there while it still exists (for how much longer it will exist after this next email, I'm not sure lol....)
Anyway, thanks for all of the fine efforts!
I'll try to get that download and schedule edit test done tomorrow.