Read RS485 bus from ESP32

[maniscalcojohn]

Is it possible to install the Aqualinkd on a server and then use an esp32 at the pool panel to read/relay commands to the aqualinkd service?

[ballle98]

This is similar to #203 it would be much easier to use a Pi Zero W or run cat5 from your panel to the server. RS485 can be several 100 ft.

[sfeakes]

You can install on server, (I even put a docker image out due to a request). but no using an esp (or anything else) at the RS485 to use as an IP bridge for the serial connection. It would introduce way too much latency.

I’ve played with AqualinkD on ESP devices, and if you strip out all functionality that requires multiple threads it works well, but at that point AqualinkD looses all the functionality people like and it simply becomes a proxy for on/off commands. Cost of pi zero W (or equiv) is only a few $ more than a capable ESP device that it doesn’t seem worth the effort to peruse. And for one off it’s cheaper and easier to use a pi zero as no usb programmer or development knowledge is needed to get a pi up and running.

[maniscalcojohn]

Ok. Understood. I’ve got an esp32 at my pool controller for reading ph/orp and dosing. Thought maybe I could incorporate this, but as you mentioned, probably not worth the effort.

[sfeakes]

Be best to simply add a pi zero and move the esp functionality to that if you only want one device.
But I’m very interested in your whole esp32 setup for reading ph/orp, can you post details or link?

[maniscalcojohn]

Sure. Here is a writeup I did on it a while back https://community.home-assistant.io/t/swimming-pool-chemical-dispenser/205561/112?u=jm123. It has changed a bit since--I dont use the Atlas Scientific pumps anymore (they didnt last). I use this probe from Atlas Scientific https://atlas-scientific.com/kits/ph-kit/ for pH and this probe for ORP https://atlas-scientific.com/kits/orp-kit/. They communicate on the i2c bus with an esp32 currently running tasmota which sends the data to Home Assistant via MQTT (planning to switch over to ESP Home eventually). The pH probe works great, very accurate. I calibrate it about once a year at the beginning of pool season. The ORP probe is not perfect--it is mostly useful for telling me when my water has a good level of chlorine, and the readings will start to drop off when the chlorine levels get low (usually because my chlorine tank runs empty). I am told the ORP probe also wont work well if you have high CYA. I keep mine around 40-50.

I also have a couple of stenner peristaltic pumps which I use to dose acid and chlorine. These pumps are 24v attached to a relay, also run with the esp32. For acid, I bought the pentair intellichem acid tank already with the pump. I'm sure there is a cheaper way to do this one, but it works well, and has a way to vent the tank away from your pad so you dont have any corrosion. For the chlorine, I bought the same pump on the intellichem but put it in a seperate housing and it feeds from 2.5G chlorine tanks I buy from the pool store,

[sfeakes]

@maniscalcojohn Thanks for posting that. I'm going to build something similar. Since AqualinkD already supports the Jandy Chemlink and in preparation, I made a quick change in V2.3.0f where you can post your own pH / ORP values to AqualinkD, that way they show up on the webUI / HomeKit / any hub you have configured. You can post with MQTT or HTTP, just change pH to ORP in the below example.

Using curl to do http
curl -X PUT -d '{"value":"7.2"}'  "localhost/api/CHEM/pH/set"

Using mosquitto_pub to post MQTT message
mosquitto_pub -t aqualinkd/CHEM/pH/set -m 7.2

[maniscalcojohn]

Nice--I'll give this a go. My dosing logic is a bit rudimentary, but it seems to keep things balanced. I've thought about implementing the NodeJS Pool Controller just to take advantage of the chem controller he built.

[maniscalcojohn]

Any experience with these RS485 to wifi adapters?
https://www.amazon.com/ARAIERD-Converter-Adapter-Support-Protocol/dp/B0B764B3LY/ref=sr_1_3?crid=35BMUA16B7HPF
https://www.amazon.com/gp/product/B07DNWM62H/ref=ox_sc_saved_title_1?smid=A2LNZEPI7X9Y44&psc=1

[sfeakes]

I have not.
While the Jandy and Pentair protocols are MODBUS based, I don’t think they are 100% compliant (but I’m not Modbus expert). Since that unit converts the protocol from standard MODBUS RTU(RS485) to MODBUS TCP, it would be interesting to see how it would handle the non-complient messages.
The other thing that happens frequently is since the Jandy and Pentair protocols are not compatible, you often get message overlap/conflict if you have a Pentair VSP with Jandy control panel, I’m sure that would create for a lot of lost messages on a device not specifically designed to handle it.
But in saying all that, it’s worth a shot to see if it works.

[niharmehta]

I have a similar version the 2nd adapter listed above for tapping in to my PV systems Inverter communication to the cloud monitoring box I have to use. LOTS of great information not unusually provided to customers.

The devices above can be used in a couple of different ways. As Modbus RTU to IP , as well as RS485 Client/Server via UDP and TCP. I use the RS485 UDP client/server functions as my older inverters were not strict Modbus. This works well where I have 2 inverters behind the 'server mode device' which I run a UDP server that I poll from a docker container running the app.

For aqualinkd, you will need to run a virtual serial driver on your host running the aqualinkd application and connect that to the device, or you will need to get two devices and use the USB-RS485 cable to a local device acting as the client, and the remote device on the bus acting as a server.

What I think will be need to be tested regarding making it work with AqualinkD is if some sort of multi-host functionality may be needed if you also have iAqualink or other controllers. I am not sure if this is required in Jandy world, but when I get to this project I had planned to test just moving my iAqualink and the AqualinkD devices behind the serial converter device and hoping it would work.

sfeakes has mentioned several times there are strict timing dependencies with Aqualink, which if the device adds does weird stuff with the protocol conversion it could add a few ms to the data path. Still a lot faster than the RS485 serialization delay, but something to consider. Also I would avoid the Wifi serial devices if you need something close to real time continuous control like AqualinkD/RS requires.

[sfeakes]

I think the main problem with this approach and any Jandy device is the timing. RS485 protocol is basically the master sends a message with an specific device ID in it, then expect an acknowledgment reply from that device, then send another message to a different ID (and again expect a reply). If the device doesn't reply, it assumes it's dead. So if the device reply's too late, ie the master has already sent the next message, the device is basically replying to the wrong message, and this can cause havoc.
Pentair protocol has a TO and FROM ID's in each message, I assume to overcome this problem, so if a message is out of order, the master can figure it out. Jandy protocol only has a TO ID in the message, so has no way to tell the message was delivered late.

Depending on many things, I think you have about 60 milliseconds to reply to a Jandy message, I try to keep it under 20ms. So in the above consider

(master sends message) -> (RS485 adapter receives then re-sends over ICP/IP) -> ( RS 485 adapter receives TCP/IP then resends RS485) -> (virtual comport) -> (linux kernel device driver) -> Aqualinkd. 

Then Aqualinkd passes message and creates reply. That then has to go back over that convoluted path. All that happening in under 60ms, (from master send to master receives reply) is a tall order.

Since AqualinkD has a whole host of ways to interface, your best bet would be to modify the source to receive and send the TCP/IP message directly and cut out the second adapter. But over wifi, I'm still not sure you can guarantee latency wouldn't effect the timing.

[niharmehta]

With the PVS solution I mentioned (Yasdi2Mqtt) the option I am using basically loads a driver that encodes serial calls in a generic udp packet (and opens a udp socket for the return) that seems compatible with exactly what the rs485 gateways expect. No serial driver needed.
Probably too niche for you to consider putting in code, but later this summer I may actually it a try to see if using a gateway devices in the middle with something like 'socat' can successfully bridge to a gateway or try to get a virtual serial working and see what it does.

[johntdyer]

@niharmehta did you ever get anywhere with this ? I would love to figure out a way to connect to get virtual serial working :)

[niharmehta]

@johntdyer . I did do some initial testing using 'socat' with an RS485 to Ethernet adapter. With some work, I was able to get serial_logger to successfully scan and report on the bus. However, I was not able to get commands successfully reliably sent without the SWG and the rest of the system going a bit nuts. I only had a few of hours to test , so although I got close, it was not successful . I am not sure where the issue lies. Possibly a timing issue maybe even the server is 'too quick' to respond since there is no serialization delay on both sides. (#259) .

I may do some testing again when I have some time over the next couple of months. However for now, I was able to get ethernet to my pool equipment and moved my PI to an enclosure near the Jandy RS.

Here is an example of the 'socat' command I was trying to use:
socat -d -d -d pty,raw,waitslave,ignoreeof tcp:192.168.12.73:5555 with .73 being the RS485 adapter.
I was using https://www.amazon.com/gp/product/B07BC77L8K/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&psc=1 as my test RS485 to Ethernet device. This one seemed more limited in serial control options than others i used such as the Waveshare devices, however it is all I had on hand. Maybe one of the others will work better, the fix for the above issue i linked may help.

[maniscalcojohn]

I gave up trying to make this more complicated than necessary and just used a pi zero as you recommended...

[johnwillyn]

I am going to write this up separately, but I have an esp32 that I use for my "digital pool filler", which talks to a "hub" running on a Raspberry Pi 4. They have always used mqtt to communicate, as there are not that many concerns with timing or latency. The Arduino device has a couple of water level sensors attached, and has logic to control a (soft open/close) valve, so the whole thing can be autonomous.

I have just done an interface to aqualinkd to tap into the mqtt messages and forward them to the hub described above (so as not to burden the Pi 4 running aqualinkd).

I have web and mobile access to my hub through a framework I have developed (details to come). I wanted to have the Pool Filler and the other pool devices all reporting on a single page on my app, and the mqtt bridge (forwarding) worked very well for this.

I have no real need at this point, but it is entirely feasible (IMO) to hook up basic aqualinkd commands (like Filter Pump on/off), and send these back through the aqualinkd mqtt message processor. The bridge software would just need to have a "return lane" added as it is only one way right now (with aqualinkd as the source and pool filler hub as the destination).

All is working well so far, and I even have some notifications going to my iPhone for potential error or (SWG) fault conditions.

[maniscalcojohn]

What do you use to read the water level? I've been wanting to automate my pool fill, but cannot find a good solution for this.

[johnwillyn]

I have two sensors currently installed, but I am going to abandon one, and improve the other. I have been monitoring and recording the readings for over a month, and have a pretty good idea of the path forward.

I tried this one:

https://www.amazon.com/Sensor-Module-Detection-Surface-Arduino/dp/B01N058HS6/ref=asc_df_B01N058HS6/?tag=hyprod-20&linkCode=df0&hvadid=198091640568&hvpos=&hvnetw=g&hvrand=383278406909237442&hvpone=&hvptwo=&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=9011882&hvtargid=pla-350450658191&psc=1

but it is very unreliable, and gives false readings even when the water level falls below the tip of the sensor board. There are well known issues with electrolysis and short life span, and the salt concentration (in my salt water pool) seems to have a big impact.

I have (an expensive) Jandy/Levolor K1100 pool fill system on our vacation rental home pool (because it has an infinity edge and the basin has to be at a certain level to operate properly), so I "borrowed" an idea from that system, and fashioned my own water level probe like this one:

https://www.getpoolparts.com/product/25604/levelor-auto-fill-sensor-slip-style-2-contact-sensor?gclid=Cj0KCQjw4s-kBhDqARIsAN-ipH2qwdA_kPLb-zES4jTZSik-Ujm3alKrRarzFXoQaW9fDc_TK2GU7Z4aAtnuEALw_wcB

I just could not justify the lofty Jandy markup on such a simple device (sells for over $100 everywhere), so I bought a bag of these (for about $2 each):

https://www.amazon.com/Liquid-Electrode-Accessory-Detector-Sensor/dp/B085B24LVL/ref=sr_1_5?crid=6ZIPJ8A9N3S7&keywords=water+probe&qid=1687443320&sprefix=water+prob%2Caps%2C157&sr=8-5

I basically did a mod to these and hooked wire to the terminal screws and filled the little plastic bracket with epoxy and left it long enough (about 15') to reach back to my esp32. It runs on the same principal as the red circuit board listed above, and the expensive Jandy/Levolor one, which is to send a 3V current to the one side, and read the "level" on a data pin.

So far, it has been very accurate at detecting "low water" and notifying me of this condition. This happens when the water level drops off the ends of the pins, and therefore there is no voltage detected. My pool at home has very limited "free board" between the level at which the skimmer will suck air, and this water level probe is set just above this point on the side of the pool.

Sorry for the long response, but I have been through a lot of trial-and-error on this, and as far as I can tell, there are no good off-the-shelf sensors for this type of application.

I will post more details on another thread if desired, but I am not at home to take pics so that will have to wait.

[chipguyhere]

I came to this thread through the lens of viewing the microcontroller as an asset and not a liability.

I recently implemented a Raspberry Pi interface to a security panel that had some pretty bad timing-related consequences if you didn't get the timing right. But microcontrollers -- especially ones dedicated to the task -- have excellent timing properties if they aren't having to multitask.

Bottom line -- by moving the entire serial interface code onto the microcontroller, and having that be aware of the entire state of the other device, while treating the Raspberry Pi as a "slow" client that could talk at its own pace -- I was able to achieve EXCELLENCE in the timing that was absolutely unmatchable with the Raspberry Pi -- consistently complying with response timing requirements to the single millisecond.

If we viewed an ESP32 as the low-level serial interface with the responsibility for managing timing, the entire solution gets more reliable.

(Trivia item: for my other interface, I used a different microcontroller with no wireless capabilities, just multiple serial ports, so I never had any concern that a network stack I didn't write or control could have any influence on my timing. The analogous setup would be to have an ESP32 talk to the network, and some dumber dedicated microcontroller go between the ESP32 and RS485)