Forgot to put User and Password as MQTT broker configuration…
Thank you!
HA NeoPool MQTT: integration of Tasmota NeoPool (for Sugar Valley, Hayward/Aquarite, Bayrol devices)
1 Like
That’s a good solution, why not. This way you can switch to Display if required and have the Tasmota with HA integration.
1 Like
The simple solution seems to work.
I put a switch on the positive to select whether to activate the display or the Tasmota.
I’ll add a photo, maybe it will help someone else with the same problem.
thanks for the work. i have everything now up and running 
maybe the documentation can be improved a bit for less experienced users but besides that i think everything is in a good shape. perfect. happy swimming
you’re right, docs need some love for HA newcomers, it’s my fault, I have been very busy lately and couldn’t provide support nor contribute to other stuff.
if anyone wants to contribute helping on documentation (how to create the package with screenshots, etc., how to modify lovelace UI with screenshots), please create a PR or write it in a separate document and I will integrate it.
that is a cool solution, when you need the display you switch and it works. repeaters should have something like that embedded.
1 Like
Hi, thanks for your great work! Currently I have the problem that no switches or selects are exposed. I only have sensors. I have no clue what went wrong. Maybe someone can give me advice
Currently it looks like this:
My device is a Bayrol Salt Relay Pro mit redox and pH. Also the poolpump is controlled via relay.
I have no clue what to do 
Your screenshot shows the Tasmota integration of your Tasmota device and if you read the original post carefully, it says that the Tasmota integration does not support the special entities of Neopool (see Tasmota Supported Entities). This is why Alessandro wrote this MQTT integration.
However, Alessandros MQTT integration does not create a device but only entities.
If you have setup “ha_neopool_mqtt_package.yaml” as described in the instructions, you will find all entities under “Entities” - search for “neopool_mqtt”
1 Like
faceplam Thanks a lot. Now I get it. I misunderstood this. It’s working now - You are my hero - also Alessandro
I have just replaced the outdated “mobile” layout on HA-NeoPool-MQTT with a “responsive” layout (ha_neopool_mqtt_lovelace_responsive.yaml) because unlike other users, I use HA on various different devices (especially my mobile) where the notebook/PC layout is not very clear.
1 Like
Norbert is Batman…I’m more like Alfred.
It looks very good. Excellent job.
@curzon01 Norbert, I had a strange spike in Temperature and Redox values, it already happened some time ago. It causes HA graphs to go out of scale for some time. I think a range validity for each sensor is needed, but unfortunately it’s not supported by MQTT Sensor entity. Would it be possible to manage it at fw level?
The first question would of course be where these errors come from. An RS485 error can be ruled out, the Modbus data has CRC. The incorrect values can therefore only come from your system or from outside Tasmota (e.g. mqtt). A test within Tasmota would only cover the first case.
Also remember, these simple tests only cover transmission error values that are outside the valid sensor range, they doesn’t eliminate the actual problem.
Would be e.g. for redox
value_template: "{{ value_json.NeoPool.Redox.Data if value_json.NeoPool.Redox.Data is defined and value_json.NeoPool.Redox.Data >= 0 and value_json.NeoPool.Redox.Data <= 1000 else this.state }}"
a solution?
I don’t know where it comes from…I suspect the Aquarite can send some strange values in some conditions? Just guessing. I don’t understand why you say MQTT, the broker is pretty solid (I use EMQX) and it’s a TCP connection, so delivery/consistency is checked and guaranteed.
I see it more as a workaround, but certainly doable. The way I see it, validation of data received should be done at the driver level, e.g. the firmware that receives data from the chlorinator should validate data before sending it to MQTT. For example, throwing an out of range exception if it receives a weird value, and ignore the value, not even sending it to MQTT.
If the driver doesn’t validate data, we will never know where the problem is originated. The MQTT package is the last bit of the chain, validating data there helps with the presentation of data, but doesn’t help debugging potential issues in the chain.
I don’t know that either, so my suggestion was to find out first (see below, everything else are workaorunds).
That was just a quick example of a Sunday evening 
without substance, you can forget it
The way I see it, validation of data received should be done at the driver level, e.g. the firmware that receives data from
…
should validate data before sending it…
…via RS485? 
You see, I can have the same argument from the Tasmota point of view in relation to your system. In Tasmota it is a workaround, contact the manufacturer. 
You understand where this is going: In terms of a correcting such faulty sources, it doesn’t matter whether it’s Tasmota or an underlying system - it’s still a workaround on any place:
Seriously, the real problem with such a woraround (and this is exactly what a check of incorrectly delivered Auqarite values is) is that they only see absolute outliers and only for data that provide sufficiently large value ranges. What about erroneous binary data (flags)? What about erroneous data that is within the permitted value range? Using such a workaround on Tasmota side then I only use it to remove absolutely invalid data but not see other incorrect values, e.g. if the redox is 750 and there is a 900 in between.
I’m not against a simple absolute range check for pH, temperature and ORP, but what about the other values in the system? Which specific values should the test concern too? And what do I do with binary values that are wrong? We can’t detect it using this simpe way.
If it is a measurement error by Aquarite, it only affects the mentioned three values. If it is an error in the Aquarite fw, it can affect all possible values. I think that the cause should always be eliminated.
Before we start with worarounds (whether in Tasmota or HA) we should first find out where these errors come from, because I do not know such erroneous values, you are the first case I know (which does not mean that there are others ). It could also be faulty amplifiers or a faulty Aquarite (power supply).
On the Tasmota side, use syslog with a syslog server, MqttLog (perhaps in combination with mqtt2sql which provides history logging) or EMQX Log Trace and record these Tasmota console logs to confirm that the erroneous values are coming from your system. Possibly even use a binary with activated DEBUG_TASMOTA_SENSOR and Weblog 4 to record the data transmission at Modbus level too.
Edit:
Such incorrect values from a system indicate an error of some kind. The disadvantage of hiding such incorrect values on any chain level is that such errors are no longer visible and faulty systems are not recognized.
@alexdelprete Alessandro, I asked via another channel and got from another user a console log (via MQTT history, unfortunately without SENSOR DEBUG) with a few peek values, all 3-6 month ago. Pls can you give me the exact values for the peeks shown above (temperature with 2 decimal places)?
if the driver gets data via RS485, yes. Then once it gets data, it gets validated. Would be the same for other kind of communication interfaces. Don’t know what’s funny about this.
I don’t agree, it’s not a workaround: the driver communicates with the device, if the device throws wrong values, not adhering to specs, the driver should skip the value and raise an alert to the upper layers. It’s common practice in other systems. RS485 and those tiny cables I believe can cause any kind of strange issues, there are collissions too on that bus, potentially.
It’s not a workaround, drivers do check data consistency and adherence to specs, when necessary. A driver shouldn’t trust the system, it should check the system works/communicates as documented by the specs.
I agree with your approach in general: either we check everything, or we check nothing. But I never noticed any other problem except these two spikes, for two times in last 10 months. So let’s wait for it to happen again, and if it’s only the same two values, I guess there’s something going on with the device fw, so it would make sense to check range for those main values. I expect the device fw to do these kind of checks before communicating these values via RS485, but maybe it does and the problem is the communication layer, but I’m just speculating. Every component shouldn’t trust any other component, in my view. So the driver should indeed check ranges, adherence to specs.
I perfectly agree with you on this. But right now I think two cases are not enough for me to start that kind of debugging (I have zero free time lately), if it happens again I’ll do it obviously so we can nail the problem.
I don’t want to simply “hide” them. I want to raise an error. Maybe also a counter representing how many times it happened.
I love brainstorming with you about these things.
Some history data I have received shows few peeks - also even within valid ranges. These are also erroneous and would not be recognized or counted. NeoPool cannot detect these with a simple range check as they are within the valid range. NeoPool is a bridge, not a driver.
Reliable detection of incorrect values in the chain would only be possible with other methods.