HA NeoPool MQTT: integration of Tasmota NeoPool (for Sugar Valley, Hayward/Aquarite, Bayrol devices)

Hello,

I am planning to use ESP32 Ethernet Unit with PoE together with RS485 to TTL Converter Unit to add this intergration for my pool.
My Hayward controller is in the basement and there is almost no wifi, but I have Ethernet cable there.

Before ordering those devices maybe someone can confirm that this setup can be used for this purpose.

At the moment I am using Hayward AquaRite cloud based integration, but I would like to switch to local setup. Also, it sounds like a fun project to do (I am not afraid to compile and flash firmware myself).

I presume by this, that the auto schedule times are not exposed by this development, and that it should use the standard Home Assistant automations to schedule the pump, instead of using the native ā€œautoā€ mode that the Sugar Valley unit provides?

Unfortunately, I personaly donā€™t know someone who has exactly this combination in operation.

But the most important thing would be to get Tasmota running on the PoEsp32, which should work according to the Tasmota discussion M5Stack PoEsp32.

You would finally have to configure the corresponding GPIOs of M5Stack RS485 to NeoPool Rx/Tx within Tasmota ā€œConfigure ā†’ Configure Moduleā€, thatā€™s it.

Correct. And, IMHO, the scheduling and automation level you can achieve in HA cannot be even compared to the Auto mode. The Smart mode is better, but you can do many more things with HA.

In general, if you have Home Automation in your house, I always recommend to centralize every automation and configure devices as pure slaves with no fancy logic.

But thatā€™s just my personal preferenceā€¦

@alexdelprete first of all, A-W-E-S-O-M-E job. this is exactly what i was looking for to enahnce my new installation with Oxilife!

when it comes to connections ,
I was expecting to do the same with a waveshare device which embeds MQTT, i tend to prefer wired connection to wireless.
But iā€™m starting to think this is not going to be a seamless integration. I assumed that i can feed modbus directly to Raspberry pi , but iā€™m wondering can this thing work without tasmota in between ?

waveshare device looks also interesting, I have also a din rail enclosure next to the hayward controller, this the setup would look cleaner actually, no additional enclosure is needed. But regarding integration I suspect that it is not that easy without tasmota, but maybe I am wrong here, no idea actually.

Nope. The magic behind this integration is Tasmotaā€™s Neopool driver. Thatā€™s the great work @curzon01 made. :slight_smile:

You can use any ESP32 device supported by Tasmota then you need to integrate RS485 hw support. You are not obliged to use the recommended devices. If you want to use an ethernet ESP32 device you can do it, but you have to add RS485 to it so that Neopool can communicate with the controller.

I think we have different opinion about ā€œcleaner setupā€, this is the first device I used, the Atom with the Tail485, and itā€™s so small that I closed it inside the controller, so you wonā€™t see anything from the outside.

Then I switched to the Atomic RS485 base + Atom because itā€™s more compact, but less flexible (you canā€™t use the additional GPIO pins).

I think being invisible and embedded in the controller is the cleanest setup. :

So I think the waveshare device is not an esp32 device will not be an out of the box solution ā€¦
what about the m5stack POE esp32 device ?

waveshare devices are only bridges that allow you to receive data from the rs485 interface to usb or tcp (depends on the model). they are not smart devices with a fw like Tasmota and the Neopool driver that can actually communicate with the system, because they know the protocol.

in other terms: waveshare only works at lower ISO/OSI layers, Tasmota+Neopool span to the upper layers.

See my answer to tarvi 5 posts before

thank you sorry iā€™ve missed it. good there are probably other devices out there with Eth to be tested out ā€¦Quinled could be another one to test , iā€™ll have one for the led setup i will perhaps tryā€¦

@curzon01 I wanted to resolve this issue in the ā€œcleanestā€ way possible, since Iā€™m having spikes again (in pH readings this time). Reading MQTT Sensor docs and this excellent post by @Troon I think the availability_template could be used to skip out of range payload values.

image

Something like this for each sensor should work (needs some testing obviously):

pH sensor:

availability_template: "{{ 'Online' if (6 <= value|float(0) <= 9) else 'Offline' }}"

In NeoPool docs do we have ranges documented for all sensors? Didnā€™t check yet.

Please let me know your feedback then Iā€™ll start updating all sensors with range checks.

Thanks.

I had been thinking about this problem for a while, but due to a lack of time weeks ago I didnā€™t really try any of the solutions.

I can also see that post-processing on the HA side has some disadvantages:

First, for a value such as the current hydrolysis level, you would have to take into account what the value range is - unfortunately, this is system-dependent (0-100% is known for HA but not x for 0-x g/h).

Secondly I also donā€™t really like the solution of handling nul (nan/nil) values using the availability status of an entity. Here we are misusing a functionality (and its status) for something for which it is not intended.

Unfortunately (for me :slight_smile:), I also come to the conclusion that the values in the data chain should be checked beforehand (NeoPool), even if this means a small ratā€™s tail of additional implementation (error counting and publishing) and even this solution would not be possible for all possible data (only for the most important measured values) and only for values that are outside a valid range - we do not eliminte spikes within valid ranges. Spikes within the min/max of a sensor are also present and cannot be eliminated using this method. I have not really found a working solution for this problem. All the ones I know must be able to change one or two past dates, which is not possible. But we only know one or two measurements later whether a measured value was a spike within valid range or a valid value.

I am thinking about implementing a check within NeoPool - may be limited (default) to ESP32.

Well, % sensor is available on both systems, IIRC. If a system doesnā€™t have g/h, then that sensor wonā€™t be used so itā€™s not a problem from my point of view.

I agree, but since HA doesnā€™t provide a range-limit functionality for sensors, that seems like a way to implement it. Not clean, but it seems to be working.

Thatā€™s why I like collaborating with you: you are intellectually honest and open to change your mind. It already happened in the past, and Iā€™m glad you came to my same conclusion. :slight_smile:

I think thatā€™s more than enough.

we could try to detect those anomalies: by checking the delta variations in time, but itā€™s up to you how far you want to go with this. It is technically possible, but it seems overkill to me. I only saw out of scale spikes, but thatā€™s just my personal experience.

Iā€™m open to discuss about this if you decide to pursue it.

I can understand why. With time, even if you said in the past you donā€™t want to maintain two NeoPool versions, I think it will be inevitable. Also because ESP32 is now widely spread and having more functionalities in the ESP32 vs ESP82xx seems reasonable to me. The only problem is having to maintain both, but you could decide to freeze developement for ESP82xx and only add new features to ESP32.

Let me know how I can be of help for you. :slight_smile:

Pls check implementation having some sensor data range validation and communication statistic - see Tasmota PR #21721 for details.

For testing:
The development branch in your repo contains firmware including PR #21721.

Note: The ESP8266 binary also contains these functions as an exception (unlike to the default), but has not been tested. There may be stability problems on ESP8266 (depends on other usage), but ESP8266 + data validation/statistic has no priority for me. But I will not include this in any release binaries. If someone wants to have the validation/statistics in the ESP8266, they have to compile their binary themselves (how, that is described in the PR above).

Seems like a good compromise. Will you support people that will compile it themselves? If not, I would not include those features for ESP8266. But itā€™s your decisionā€¦

I will add these to the sensors package, in the diagnostic category, so we can understand better whatā€™s going on, in case of issues:

  • MBRequests is the total number of system request
  • MBNoError is the total number of system responses without error
  • MBNoResponse is the number of MBRequests having no repsonse
  • DataOutOfRange is the total number of values outside the valid range

I will test the dev firmware as soon as possible and will give you feedback. Thanks.

In which case? Compiling in general or adding this function to ESP8266 with NeoPool? The latter is already described in the PR.

If there are users who are not able to compile Tasmota themselves and loading binaries from a development branch onto their ESP, they have done something wrong anyway. Developer branch binaries are for testing purposes only, in general end users should not use material from such a branch.
As I wrote, the ESP8266 binary within main branch will never have this functionality included.

Do you intend to remain backwards compatible by checking the existence of these json keys?

Edit: Typo

The latter: since you said there might be stability issues, in case of problems will you support them? In case you will, I donā€™t understand the choice of not publishing pre-compiled firmware files. But itā€™s just my curiosity. I thought you wanted to discourage the use of ESP8266 with these latest firmwares.

this is what led me to ask the question: if itā€™s not a main branch feature for ESP8266, I guessed there would also be no support for it.

I will try to.

:point_up_2: