I just re-read my original post. I am not actually using the remote comm port since my variable speed pump uses it. Instead I am using the accessory port. I get good readings, but I am unable to reliably turn the pump on and off. When it cools down, I may try another port, or try to find the proper size plugs to use the pins on the back of the display.
Does anyone know what size the pins on the display are? They are huge compared to other pins I have worked with…
Went over my USR-W610 configuration again, and realized I didn’t have the data transfer mode set to “transparency”. That causes some big skews in the data output, so now that I have fixed that it looks like I’m able to read in data no problem. Still working on figuring out how to send data to the device.
My attempts with cli.py to send button push information have been unsuccessful. An attempt to toggle the lights proceeded as follows:
I’ve been messing around with my own socket client and did some logging to track how the hex codes mapped to each button press. Seems like there’s some discrepancies in the data.
-- START FRAME [Sun, 22 Aug 2021 21:03:16 GMT] --
HEX: 100201024c0000000000000000611003
-- END FRAME --
-- START FRAME [Sun, 22 Aug 2021 21:03:17 GMT] --
HEX: 10020103202020202020204c69676874732020202020202020202020205475726e6564204f6e2020202020200008fd1003
ASCII: Lights Turned On ��
-- END FRAME --
-- START FRAME [Sun, 22 Aug 2021 21:03:18 GMT] --
HEX: 100201024c000000000000000061100310020103202020202020204c69676874732020202020202020202020205475726e6564204f6e2020202020200008fd1003
ASCII: L��������a Lights Turned On ��
-- END FRAME --
-- START FRAME [Sun, 22 Aug 2021 21:03:19 GMT] --
HEX: 100201020c0000000000000000211003
-- END FRAME --
-- START FRAME [Sun, 22 Aug 2021 21:03:19 GMT] --
HEX: 10020103202020202020204c69676874732020202020202020202020205475726e6564204f6666202020202000092e1003
ASCII: Lights Turned Off � .
-- END FRAME --
...
The code for lights on seems to be: (edit, realized these were the LED frames, not button press frames)
10 02 01 02 4c 00 00 00 00 00 00 00 00 61 10 03
Lights off:
10 02 01 02 0c 00 00 00 00 00 00 00 00 21 10 03
This doesn’t really follow the pattern that was described previously by others. I’m wondering why my data is formatted this way in comparison to other posts.
Attempting to send this data also does nothing from both my code and the CLI. I frequently have issues decoding with ‘utf-8’ in the CLI for some reason as well. The USR-W610 is definitely receiving the data as I can see the TXD light blink on the interval I have set to write the socket. Any direction would be appreciated! I’m going to keep going back to read this thread in the meantime.
Edit: Forgot to update. I fixed the decoding issue. When the display update is sending the frame for the date and time, the “:” character is encoded strangely, so I had to replace it with ‘\x3a’ and then decode. No errors now.
Ran the CLI provided by Sean, and was able to receive the Local Wired Keypress information. I was hoping maybe this information would be a bit telling to someone who has more experience with this since I don’t have as much time to play with it today.
Here’s the output of me manually toggling the button on and then off.
WARNING:core:1080326.328: Local Wired Key: b'0001000000010000'
WARNING:core:1080326.328: LEDs: b'6c00000000000000'
Pool Temp: 88
Air Temp: 90
Pump Speed: None
Pump Power: None
States: [<States.CHECK_SYSTEM: 4>, <States.POOL: 8>, <States.FILTER: 32>, <States.LIGHTS: 64>]
Check System: Very Low Salt
WARNING:core:1080326.437: Display update: ['Lights', 'Turned', 'On', '\x00']
WARNING:core:1080327.187: Local Wired Key: b'0001000000010000'
WARNING:core:1080327.265: LEDs: b'2c00000000000000'
Pool Temp: 88
Air Temp: 90
Pump Speed: None
Pump Power: None
States: [<States.CHECK_SYSTEM: 4>, <States.POOL: 8>, <States.FILTER: 32>]
Check System: Very Low Salt
WARNING:core:1080327.265: Display update: ['Lights', 'Turned', 'On', '\x00']
WARNING:core:1080327.375: Display update: ['Lights', 'Turned', 'Off', '\x00']
WARNING:core:1080329.250: LEDs: b'2c00000000000000'
WARNING:core:1080329.250: Display update: ['Lights', 'Turned', 'Off', '\x00']
WARNING:core:1080331.234: LEDs: b'2c00000000000000'
WARNING:core:1080331.250: Display update: ['Lights', 'Turned', 'Off', '\x00']
WARNING:core:1080333.250: LEDs: b'2c00000000000000'
WARNING:core:1080333.265: Display update: ['Lights', 'Turned', 'Off', '\x00']
If I’m not mistaken, the light toggle should look like:
bytearray(b'\x10\x02\x00\x02\x00\x01\x00\x00\x00\x01\x00\x00\x10\x03')
Edit again:
Also seeing another format from an older log of mine and also when I let the CLI calculate the button code:
bytearray(b'\x10\x02\x00\x02\x00\x01\x00\x00\x00\x01\x00\x00\x00\x16\x10\x03')
Hi. Is there a way to monitor the state of Valve 3 (Solar diverter in my case)? My EcoStar VS pump just died and I replace the driver/motor with a Century V-Green 270. It’s controllable via a separate Automation Adapter with 4 low voltage relay inputs as well as (proprietary, I guess) RS485.
I’d like to know when Aqualogic Valve 3 turns the solar on so I can override present pump speed to high and then revert to the preset speed when Valve 3 and solar turn off. I plan on using another ESP device to control the relays using ESPHome and Node-Red, unless I can add that to my current NodeMCU.
Any ideas appreciated.
After a little more trial and error, I re-visited the blog that this HA component was originally based on:
Don’t mind my crazy debugging code here, but it seems that this packet format worked perfectly for turning on and off my lights. I’ll need to require a custom version of the aqualogic dependency to support my device’s codes (since they differ from the ones implemented by Sean) in HASS. I’m using a PS-4 with the “Remote Display” pinouts as I previously posted.
Managed to crunch through these if you’re using the remote display port on a PS-4, still working on Pool/Spa buttons:
Filter: 0x10, 0x02, 0x00, 0x83, 0x01, 0x80, 0x00, 0x00, 0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x01, 0x96, 0x10, 0x03
Lights: 0x10, 0x02, 0x00, 0x83, 0x01, 0x00, 0x01, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x00, 0x98, 0x10, 0x03
Aux 1: 0x10, 0x02, 0x00, 0x83, 0x01, 0x00, 0x02, 0x00, 0x00, 0x00, 0x02, 0x00, 0x00, 0x00, 0x00, 0x9A, 0x10, 0x03
Aux 2: 0x10, 0x02, 0x00, 0x83, 0x01, 0x00, 0x04, 0x00, 0x00, 0x00, 0x04, 0x00, 0x00, 0x00, 0x00, 0x9E, 0x10, 0x03
Valve 3: 0x10, 0x02, 0x00, 0x83, 0x01, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x98, 0x10, 0x03
Heater: 0x10, 0x02, 0x00, 0x83, 0x01, 0x00, 0x00, 0x04, 0x00, 0x00, 0x00, 0x04, 0x00, 0x00, 0x00, 0x9E, 0x10, 0x03
Pool/Spa/Spillover: 0x10, 0x02, 0x00, 0x83, 0x01, 0x40, 0x00, 0x00, 0x00, 0x40, 0x00, 0x00, 0x00, 0x00, 0x01, 0x16, 0x10, 0x03
If someone could help me understand the checksum for the Filter code that would be awesome! I’m trying to figure that out since the Pool/Spa/Spillover button will use a similar calculation method for the 1-byte code. The others are linear and easy to follow, but I’m not following why we have: 01 96, when the sum should be 256 for the filter.
After further review, Sean’s checksum calculation was correct, it was just a matter of changing the keys.py to be 4 bytes to support the “wireless” protocol. Is there an easy way to force the HA integration to use the wireless protocol?
As an example, these were my modifications for testing:
POOL_SPA = 0x40000000
FILTER = 0x80000000
I asked this some time ago and did not see any replies or others experiencing the same issue so I’ll wanted to ask again.
My readings will update after booting the HA core but will stop updating almost immediately after initial readings until I reboot my home assistant core. Any thoughts on what might be causing this? I am using an esp8266 flashed with ESP-link and an inexpensive rs-485 converter. I have a stable wifi connection to esp-link so I do not think that is the problem. The ESP-LINK console looks like:
Is that normal or is the communication being “garbled” as indicated by all the extra characters?
TIA for any ideas or assistance the community can provide.
I would verify that your networking mode is set correctly. I had a similar problem with the USR-W610 (which you aren’t using, but maybe translates). I was using some TCP<==>Modbus networking mode, when I should have been using transparent mode. Things were more garbled than usual like you’re explaining and would stop transmitting shortly after starting.
Thanks for the feedback, but the ESP-link setup is not quite like yours. I do not have a similar setting. My configuration is much like this:
I power my esp8266 dev board slightly differently but use a very similar RS485 convertor if not the same one. I am not inclined to believe it is a noise issue as the “useful” data is never garbled or interrupted. I am wondering if the block-like characters are just padding or framing characters.
I get a lot of junk with NodeMCU(ESP8266) too. Perhaps this has something to do with it?
From the ESPHome UART Bus page:
“ Note
On the ESP32, this component uses the hardware UART units and is thus very accurate. On the ESP8266 however, ESPHome has to use a software implementation as there are no other hardware UART units available other than the ones used for logging. Therefore the UART data on the ESP8266 can have occasional data glitches especially with higher baud rates…”
I am not sure that has anything to do with it as I am not using ESPHome. ESP-Link may have the same limitation since your citation references hardware differences. 19200 is not a particularly high baud rate relatively speaking so I am not sure what to think. I recently stumbled upon so talk of ESP-Link being ported to ESP-32 so I may check it out and see if it helps.
Awesome work. This seems to be working on my controller as well. Perhaps can pass in some variable into the plugin to use these different values instead.
Yep, that’s my next step. I might fork the project and setup a custom component and write up a README to make instructions clear on how to use it. There’s a few things I wanted to tweak to make it more suitable for the PS-4 and/or wireless remote compatible terminals for people who have network latency issues.
Let me know when you have your repo setup and I can try to help contribute.
For now I’m just going to fork the aqualogic library and get this working with wireless controls on a PS-4. I also wanted to document how people can use the updated states without the config flow in HA (Pool/Spa, Heater, etc). Having them labeled as Aux 1-7 makes things more difficult, and since the gatekeepers want a new config flow it’s probably better to set it up as a custom component in the meantime.
Ron,
I came across some more info related to your comments and found conflicting information. While I2C is implemented in software on the ESP8266, it does have 2 hardware UART channels. However, as I understand it, on the ESP8266, one is tied to the serial flashing interface leaving one available. ESP-HOME uses that for logging so it has to use a software implementation on the ESP8266 for any other applications. I do not think that is the case for ESP-LINK. None-the-less, I am currently looking to use an ESP-32 serial to wifi bridge solution but the best option I have found does not seem to be as polished as ESP-LINK so will like take some tinkering to get working.
Great troubleshooting, hopefully when implemented this will help me with my problem too.
I don’t suppose you have an RGB LED pool light? One of the things this integration is missing is the ability to set the RGB LED pool light color. On the ProLogic Controller itself, you just need to keep turning the light on and off to toggle through the colors and patterns. However, there is a remote (there is a wired and wireless version, the wired version must be RS485) that can be purchased that allows you to directly set a color or pattern, which means there has to be a value that can be passed to the light to pick a color, and HA should be able to do it if someone is able to figure out how to set the value…
Unfortunately no RGB lighting here, so I wouldn’t be able to test this. You’re more than welcome to come up with a solution and I can look at your pull requests if you figure something out 
Unfortunately, I wouldn’t even know where or how to start.
I believe you need an additional controller to manage the color selection without power cycling and I am sure it has an undocumented comms protocol. Would be nice to see though!
It looks like you are essentially correct. The older RGB LEDs can be directly controlled, but it is only through a 2-wire power feed through the relay, there is no separate data feed. The wired controller must somehow send a data signal over the power wires and the LED unit itself is able to interpret this signal. This means there is no way to control this directly through the AquaLogic/ProLogic interface. It also appears that there are newer “networked” RGB lights that can be directly controlled through Hayward OmniLogic controllers. Of course that is not relevant to this library since OmniLogic has a different component.
Manual for the wired colorlogic controller:
