Thanks for your kind words, but most of the real work is the Tasmota NeoPool “driver”, developed by @curzon01. The only thing I did was contact him, asked him for some changes (breaking his b***s too much sometimes), and also showing him how good HA was, and he also migrated to this platform. So now we have a Tasmota expert developer that is also an HA user. I could only hope this would be the final outcome.
So 70% of the credit goes to Norbert, I’ll take only 30%.
As you can see he’s the one fully answering your specific question, not me. Let’s say we created a good team.
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.
@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.
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.
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.
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.
Something like this for each sensor should work (needs some testing obviously):
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 ), 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.
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.
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.
