search

jackbrown1993 / Jacuzzi-RS485

Python Module for Jacuzzi Hot Tubs
Apache License 2.0
8 stars 2 forks source link

[feature] Add support for users with ProLink #33

Open jackbrown1993 opened 1 year ago

jackbrown1993 commented 1 year ago

This should be fairly easy as we believe the channel is static, we need some flags on the application run to decide what input parameters are required / should be used.

dhmsjs commented 1 year ago

My assumption is that Prolink is doing similar channel negotiation, it's just handled internally so not visible on the TCP side. Monitoring the RS485 bus with Prolink installed would probably tell us a lot.

jackbrown1993 commented 1 year ago

The current channel negotiation was the work of @HyperActiveJ, looking at the code it listens for 'clear to send' messages and what channel they were received on channel = data[2]. It stores these channels in discoveredChannels, it also looks at any CC_REQ messages and what channel they are received on and stores them in activeChannels.

The module waits 'DETECT_CHANNEL_STATE_CHANNEL_NOT_FOUND' which is 5 by default, clear to send cycles before deciding what channel is available to use.

@HyperActiveJ is this about correct?

dhmsjs commented 1 year ago

That is helpful - thanks.

So do I understand this to mean that:

Not clear to me whether the lists are necessary for the negotiation or whether they are just there to help understand how the system works.

I've seen the DETECT... cycle counter but what exactly it is for is still a bit murky to me. I would think that a new device would ask the controller for an address to use, and wait for the controller to provide one. This sounds to me like the device is looking for a channel that is unused (because nobody replies to the CTS) and then chooses to use that channel address.

When I get a chance I will study that code a bit more carefully.

HyperActiveJ commented 1 year ago

It tries to find if the controller is asking for a device that isn't there and reuses that address if it is. This covers the case if you restart the client so it doesn't ask for a new address.

On Sat, Jun 17, 2023, 14:54 David Holland-Moritz @.***> wrote:

That is helpful - thanks.

So do I understand this to mean that:

  • The controller sends out "clear to send" messages to devices it believes are attached. Each is an invitation from the controller to the device to send any pending messages it might have.
  • The device can also request a "clear to send" by sending the controller a CC_REQ message and then wait for a CTS invitation.
  • @HyperActiveJ https://github.com/HyperActiveJ's code monitors this traffic and uses it to maintain discoveredChannels and activeChannels lists.

Not clear to me whether the lists are necessary for the negotiation or whether they are just there to help understand how the system works.

I've seen the DETECT... cycle counter but what exactly it is for is still a bit murky to me. I would think that a new device would ask the controller for an address to use, and wait for the controller to provide one. This sounds to me like the device is looking for a channel that is unused (because nobody replies to the CTS) and then chooses to use that channel address.

When I get a chance I will study that code a bit more carefully.

— Reply to this email directly, view it on GitHub https://github.com/jackbrown1993/Jacuzzi-RS485/issues/33#issuecomment-1595870209, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABQBVPMHJ3UBZOLBYXG6IF3XLYRQLANCNFSM6AAAAAAZJEID24 . You are receiving this because you were mentioned.Message ID: @.***>

dhmsjs commented 1 year ago

That makes sense.

Followup question: after connecting, how often does your WiFi-to-RS485 bridge lose the connection? Is it only occasionally, or fairly often?

The reason I ask is because my Prolink connection gets dropped regularly (on the order of every few minutes) but usually reconnects right away. And then periodically the Prolink seems to "go to sleep" in the sense that it suddenly just flat out ignores any and all TCP connection requests.

Then after some random period of time it wakes up again. It seems the wake up may be associated with the hot tub controller doing a timed task -- like a filter cycle for instance -- or possibly being manually triggered by activity on the topside panel.

BTW I have seen similar behavior with the SmartTub cell network connection too (though I don't try to use that much anymore).

HyperActiveJ commented 1 year ago

Sorry I've been unavailable to help its busy at home at the moment. I do not seem to experience any bridge drop outs. The issue I do have is that if the commands get buffered in the server, network, or rs485 bridge then the spas host controller on the spa gives up waiting for a response and stsrts to make the next request to the next device, then the message from the server gets put on to the bus 485 causing a corrupted message and neigher device is understood by the host. The only solution I've found is to ensure priority for the application on the server, and to ensure there is not to much traffic on the network. Running the app on a embedded computer in the spa with a usb 485 adapter instead of over a network to serial bridge is the only way I've found to completely solve the problem.