The constructor expects file-like objects to be passed as the reader/writer, so you should be able to pass in a pyserial object.
Thanks for your reply. That was what I was thinking. Just wondered if it had been done already.
I am watching to see what develops here.
I finally purchased a USR-W610 and got the AquaLogic integration working with my Hayward ProLogic. For anyone else reading, since my variable speed pump plugged into the Remote Comm port, I plugged into the the bottom accessory comm port (ports labeled “P” in the Hayward documents). Pin 1 is RS485 A, Pin 2 is +11V, Pin 3 is RS485 B, and Pin 4 is ground. I used Pin 2 and Pin 4 to power the USR-W610 so a single 4 conductor cable is providing power and RS485 communication.
I have the same problem that many other people have reported where I have to send on/off command many times to get it to register. I’ll be watching to see if anything comes of this discussion and will gladly help test.
1 Like
So I added some additional debugging. The display messages are not restricted to every 2s; they can occur at any point, so I’m not sure that will help mitigate the issue.
As near as I can figure, Goldline implemented collision avoidance by dividing the interval between the keep-alive messages into 10ms slots and assigning the various messages to different slots. The display messages always seem to get sent ~50ms after the keep-alive, pump speed request messages are ~20ms after the keep-alive, and key messages immediately follow the keep-alive. Here’s an example of what occurs when I press a button on the physical controller:
DEBUG:core:5.04: KA
DEBUG:core:5.04: Key: b’04000400’
DEBUG:core:5.09: LEDs: b’0800000000000000’
DEBUG:core:5.09: Display update: [‘Heater1’, ‘Auto’, ‘Control’, ‘\x00’]
DEBUG:core:5.13: KA
DEBUG:core:5.19: Display update: [‘Salt’, ‘Level’, ‘3.4’, ‘g/L’, ‘\x00’]
Keep in mind I’m running this on a PC connected via WiFi to a router connected to an Ethernet-RS485 converter, so there is lots of opportunity for latency. But I’m not sure there is a better strategy for sending the key events than what the code is currently doing (sending them immediately after seeing a keep-alive).
Would be interested to see this debugging from someone using a simpler hardware setup (e.g. PC->RS232-to-RS485). You’ll need to pull GitHub - swilson/aqualogic: A python library to interface with a Hayward/Goldline AquaLogic/ProLogic pool controller. and then modify cli.py to connect using serial instead of a socket.
Well so much for that theory. I hooked up an RS232-to-RS485 board to get a better look at the timing, and the messages do not seem to adhere to 10ms slots. Even the keep-alive messages have a fair bit of drift to them:
DEBUG:core:0.838: KA
DEBUG:core:0.934: KA
DEBUG:core:1.029: KA
DEBUG:core:1.141: KA
DEBUG:core:1.237: KA
Here is an interesting example. The key event gets sent 1ms after the keep-alive and no other messages occur until the next keep-alive. Yet the key event still got either ignored or stomped on (the library did re-queue it and it eventually did succeed).
DEBUG:core:97.237: KA
INFO:core:97.238: Sent: b'100200030002000200191003'
DEBUG:core:97.333: KA
DEBUG:core:97.433: KA
DEBUG:core:97.533: KA
All of this seems to indicate the only way to get 100% reliable transmitting is a hardware bit-level solution.
Thanks for continuing to work on this interface.
Based on what you are saying, likely the only way to make this reliable is to use the Aqua Connect Serial adapter and have a new HA integration for it. Unfortunately, the Aqua Connect costs around $280 and someone would still have to figure out the HA integration, probably by reverse engineering it.
https://www.hayward-pool.com/shop/en/pools/aquaconnect-home-automation-serial-interface-aq-co-serial
Probably. No need to reverse engineer the Aqua Connect though, its interface is documented here: https://images.inyopools.com/cloud/documents/goldline-aqcserial-owners-manual.pdf
Interestingly it says:
The Aqua Logic PS/Pro Logic PS is the
master of the bus, and devices only transmit when queried. For example, to
receive a keypress from any one of the remote controls, the Aqua Logic PS/Pro
Logic PS requests pending keys every 100 ms, and then listens for an answer.
If any remote control has a pending keypress, it is immediately sent back to
the Aqua Logic PS/Pro Logic PS.
Which is exactly what we are attempting to do.
Coincidentally one of my wired remotes has stopped transmitting, so perhaps I’ll learn something more while I’m attempting to debug it.
Hello,
I’ve been unsuccessfully searching for a picture or a diagram showing the proper connection of the RS485 device to the Prologic board. I have a PS-4 but I suspect that others are similar. Can anyone share something showing the position of the “A” and “B” lines on the board.
Thanks
When they say “If any remote control has a pending keypress, it is immediately sent back”, they mean IMMEDIATELY. The remote doesn’t even wait for a full byte cycle before responding (which confuses my logic decoder):
Is there any difference with connecting to the bus at the main panel vs. connecting using the ‘wired remote’ header?
I have the same issue as others, where I can read all values but not set any (even which I click, say, lights 30 times) when connected via the wired remote header, just trying to identify if that is my issue or if it’s the same thing other people are seeing.
1 Like
on Prologic. Just looking for the heather1 switch variable.
On the GLX-PCB-MAIN there are two connectors; one marked ‘remote display’ and one marked ‘local display’. They are both connected to the RS-485 bus. The GLX-PCB-PRO is probably similar.
1 Like
Hi swilson,
Thank you for the information and your work on this!
I have a usb->rs485 coming in the mail today, I’ll do some more troubleshooting.
I’ve updated the component to use the wireless remote button protocol. Hopefully this fixes some issues.
2 Likes
Between your new files and some helpful tidbits from stoehrmark regarding adding them as a custom component, it is now working perfectly for me. Thank you again for all of your work on this.
Any suggestions for adding in a pool mode/spa mode switch? I have seen it done in other threads and I don’t even know where to begin.
There is a key to toggle Pool/Spa, but the validation code will require adding some additional logic because Pool and Spa are separate LEDs. I’ll add it to the issues list.
1 Like
For those that cannot send back commands to the Hayward panel but can see the output. Maybe the following will help fix the problem. It worked for me and others.
I started with the current files on github (June 2020)
https://github.com/swilson/aqualogic/tree/master/aqualogic
I then added a custom component as follows.
I made an aqualogic folder in the same folder as the configuration.yaml file
I added the core.py and __ init __.py into that folder
Then I changed the following in the core.py file
##############################################
FRAME_TYPE_WIRED_KEY_EVENT = b'\x00\x02'
#FRAME_TYPE_WIRED_KEY_EVENT = b'\x00\x03'
##############################################
It now seems to work ok.
Just a note sometimes there is a bit of delay (a few seconds) between clicking the button in HA and the Hayward device responding.
Thanks to @swilson for all the work on this!!
1 Like
Note that as of release 2.2 the code no longer uses FRAME_TYPE_WIRED_KEY_EVENT to send events; it uses the wireless variant instead. Hopefully this works better for everyone.
Yup tested and working with my Hayward control panel
I still made a custom component using the most current GitHub files.
But did not edit the core.py file
In the past, I had to edit that KEY_EVENT to make it work
Thanks @swilson