1488 °C temperature and 11,3V redox are within spec range? I don’t think so.
It is a functional bridge implemented as a Tasmota driver. Bridges can be transparent or not, it depends on the implementation. But let’s not start a “philosophical” discussion.
NeoPool sees the data before bridging it, so it can check for validity vs specs ranges. I think it is reliable to check at that level, but you have a different opinion and I respect that.
This means I will modify the package implementing validation with value_templates, at least for some of the values. It’s not my preferred solution, but I have to adapt to the situation.
yeah, but pls, that’s not the only case so range check is a workaround and for an ESP8266 it is slowly all too much for what you suggested (“don’t want to simply “hide” them. I want to raise an error”):
If the problem is that it’s too much for ESP8266, I can understand, since you don’t want to have different fw. Even though checking for a range on X values (not all of them) doesn’t seem a big issue to me, but I can understand your position.
When I said I don’t want to “hide” the errors, I was replying to your statement regarding how these wrong values should be handled. So if having an MQTT topic for each of the wrong values (redox, temp, etc.) that represents a counter of “bad values” is too much for ESP8266 (just an example) then we need to move the checks in another layer.
We could also ignore them if it’s ESP8266 and process them if it’s ESP32. But you decide…maybe with time people will start using only ESP32 and we could improve things.
Regarding the range check: for me if the value is more than 100% different vs the previous value, it’s wrong. But let’s discuss about the X%.
Hello, I did the installation as presented above, I am with a ESP8266 and an RS485 3.3v,5v converter.
However I have a problem, it is that by plugging the whole thing into the Sugar Valley, the Sugar Valley sends a voltage of 2.57v to the converter, but the converter sends 0.25v back to the ESP8266 which is not enough to power it.
Has anyone ever had this problem? Is it coming from my converter?
P.S:Thanks a lot @alexdelprete for that incredible works and explainations
Hello!
Great work what you did there! The integration is going perfectly.
Is there a way that the temperature and redox values only change when the pump is in operation? Outside the filter runtime, the values are not correct.
Thanks!
Daniel
No, and that has nothing to do with the Sugar Valley, NeoPool or this intergration.
This is normal and is the case with every system. In idle state, the probes are not flushed, so where should the current measured values come from? The water around the temperature sensor slowly takes on the ambient temperature and the redox value usually drops, as the water around the probe is no longer refreshed from the pool.
So the values are not correct on the system display either, right? You wanto to tell Sugar Valley to fix the firmware or rethink a little bit more about the question?
Jokes apart, the provided values come from the system, we’re not manipulating anything. Water flow is essential for the sensors to provide realistic values.
Reading it a second time, I realized that you may only want to disable data collection outside the filtration times.
This can be done with the help of Tasmota Rules, but only for the entire system data, not for individual selected data like temp and redox only.
I don’t yet know exactly how this interface should be integrated into the overall solution.
For this solution you need Tasmota + NeoPool connected to a Sugar Valley System RS485, which makes the system data then available via MQTT. The solution from Alessandro here then integrates this into HA.
It might work if you manage to connect the Atom Lite to the HF2211 appropriately, but I don’t think you can do it. The NeoPool driver runs on Tasmota, it expects the A/B rs485 connections on the Tasmota device pins (bridged to TTL). But the beauty of this solution is that the Atom Lite + Tail485 or the Atom Lite + Atomic RS485 base, which I’m currently using. It costs much less than the HF2211.
With this solution, everything is read LOCALLY. In the thread you mentioned the solution is based on a script that scrapes data from the cloud. I don’t use the cloud for almost anything related to my home automations. When I buy something, I first make sure I can control it locally.
I use the HF2211 to read the Oxilife through modbus. So no cloud involved either.
That’s why I was thinking about using it.
But I ordered the Atom + tail earlier today. Nice to play around with and I’ll be able the cut the cloud by not needing to use the apps again for pump speeds etc.
Hello!
Yes, exactly. I created a rule in openHAB where the redox and temperature values only change when the pump is in operation. Is this option also available in Home Assistant? I don’t want to do this via Tasmota because I also have a room temperature sensor connected.
Yes, but the idea here is to leverage NeoPool driver to get MQTT data into HA. And NeoPool is a Tasmota driver, so it requires tasmota on the device that interfaces your Oxilife.
You’ll have lots of fun with the Atom+Tail. I recently switched to the RS485 Atomic base because it’s more compact, but less flexible if you neex extra pins.
I do have 1 question however: when you select “Auto” mode, in the Da-gen (or Vistapool) app, you can specify some start/end times. Can we replicate that through HA as well?
EDIT
Hang on, after I changed some settings in the GPIO’s, I have everything back:
You can’t break Tasmota using such way, the reason is your RS485 connection
“Error” as a result of a NeoPool Tasmota command means your Tasmota is compiled with NEOPOOL module, GPIOs are assigned but your device does not respond to Modbus commands via RS485. Reason can be wrong or poor wiring, wrong GPIO assignment or not working RS485 interface.
As long as you don’t see any NeoPool data on Tasmota WebUI as described onTasmota NeoPool page, the integration can not work.
This results also in no visible values on main Tasmota WebUI
Indeed, “wrong GPIO assignment” was causing this. All good now!
But I still have that one request: when you select “Auto” mode, in the Da-gen (or Vistapool) app, you can specify some start/end times. Can we replicate that through HA as well?
In HA you can create powerful automations, powerful scheduling, you just need to leverage all the entities that the integration provides. It’s just about being “creative”, you have all the tools you need.
