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.
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?
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.
