NeoPool - Home Assistant integration

[alexdelprete]

Hi Norbert/@curzon01, since you're the NeoPool driver's dev, I have a question: in Home Assistant I see all the sensors related to the driver, but I see no "controls" (that is, the switches that toggle relays, filtration, etc.). My friend, @CosminFRC, told me that with ESP82xx device, he sees those controls in HA. I'm not convinced it depends on the cpu type, but maybe the driver is different between the two so also the Home Assistant integration leads to different results? Or it could depend on the fact that on the ESP32 we use Berry scripts vs fake GPIO relays on the ESP82xx?

This is what I see with M5 Atom in Home Assistant:

And he showed me what he sees with ESP82xx device (he has Controls section in addition to the Sensors):

Thanks for your help.

[curzon01]

The simple controls could be solved via the ESP82xx definition (using dummy relays and rules) - no berry scripting neccessary.

If you also use user defined NeoPool commands (for the NPAux cmnd), the configuration e. g. for Atom Lite look like this:
(Relay 1-4 = Aux1-4, Relay 5 = Filtration, Relay 6 = Light)

Configure dummy relay

Backlog GPIO12 224;GPIO13 225;GPIO14 226;GPIO15 227;GPIO18 228;GPIO20 229

Label WebUI buttons

Backlog WebButton1 Aux1;WebButton2 Aux2;WebButton3 Aux3;;WebButton4 Aux4;WebButton5 Filtration;WebButton6 Light

Define rule1

Rule1
  ON Power1#State==0 DO NPAux1 %value% ENDON
  ON Power1#State==1 DO NPAux1 %value% ENDON
  ON NeoPool#Relay#Aux[1]#State==0 DO Power1 %value% ENDON
  ON NeoPool#Relay#Aux[1]#State==1 DO Power1 %value% ENDON

  ON Power2#State==0 DO NPAux2 %value% ENDON
  ON Power2#State==1 DO NPAux2 %value% ENDON
  ON NeoPool#Relay#Aux[2]#State==0 DO Power2 %value% ENDON
  ON NeoPool#Relay#Aux[2]#State==1 DO Power2 %value% ENDON

  ON Power3#State==0 DO NPAux3 %value% ENDON
  ON Power3#State==1 DO NPAux3 %value% ENDON
  ON NeoPool#Relay#Aux[3]#State==0 DO Power3 %value% ENDON
  ON NeoPool#Relay#Aux[3]#State==1 DO Power3 %value% ENDON

  ON Power4#State==0 DO NPAux4 %value% ENDON
  ON Power4#State==1 DO NPAux4 %value% ENDON
  ON NeoPool#Relay#Aux[4]#State==0 DO Power4 %value% ENDON
  ON NeoPool#Relay#Aux[4]#State==1 DO Power5 %value% ENDON

Rule1+
  ON Power5#State==0 DO NPFiltration %value% ENDON
  ON Power5#State==1 DO NPFiltration %value% ENDON
  ON NeoPool#Filtration#State==0 DO Power5 %value% ENDON
  ON NeoPool#Filtration#State==1 DO Power5 %value% ENDON

  ON Power6#State==0 DO NPLight %value% ENDON
  ON Power6#State==1 DO NPLight %value% ENDON
  ON NeoPool#Light==0 DO Power6 %value% ENDON
  ON NeoPool#Light==1 DO Power6 %value% ENDON

Enable rule1

Backlog Rule1 5;Rule1 1

(important to use one-shot rule for this as described)

Result in Tasmota UI

[alexdelprete]

So, if I understood correctly, in order to have switches entities in Home Assistant, I need to define dummy relays and the rule managing their logic, both on ESP82xx and ESP32. The berry script is just a way to define the NPAux and NPBoost commands and the UI elements on ESP32. Correct?

Having said that, since I'd like to have switches on HA for everything possible, I can always add more dummy relays, for example if I want a switch for boost mode, correct? Even though, boost mode like pump speed are not actually switches but selects because they have more than 2 possible states. I wonder how the HA integration module in Tasmota works on these things, so we can better configure NeoPool.

Curiosities: why did you skip GPIO19 in the dummy relay example above?

Also: is there a way to rename the system model? I have an Hayward Aquarite+, and it comes out as "Generic" I wonder if there's an option somewhere to change/customize it. I know that it probably comes out of the register map itself, maybe there's a way to define that somewhere. Thanks.

Thank you very much for the help.

[curzon01]

The berry script is just a way to define the NPAux and NPBoost commands and the UI elements on ESP32. Correct?

Not quite, only script neopoolcmd.be is responsible for the command extension.
Script neopoolgui.be creates the buttons ("Filtration", "Light", "Aux"...) and also the dropdowns with the associated functions which you now have partially duplicated by the ESP82xx dummy relays.
But the buttons/dropdowns from neopoolgui.be are not usable with HA without further implementation, because there are no relays behind them.

It would be a much better way to implement all this in HA without dummy relays, but as mentioned in the other discussion, I don't have the necessary HA knowledge.

Having said that, since I'd like to have switches on HA for everything possible, I can always add more dummy relays, for example if I want a switch for boost mode, correct?

Yes, this is not an elegant solution, but it works for simple on/off functions.

Even though, boost mode like pump speed are not actually switches but selects because they have more than 2 possible states. I wonder how the HA integration module in Tasmota works on these things, so we can better configure NeoPool.

As I wrote in my first answer "The simple controls could be solved..." the way via dummy relays is only suitable for simple functions. This principle no longer works for selection lists such as Boost Mode with more than on/off or for e. g. selecting the filtration speed, filtration mode nor for value setting like NPpHMax, NPHydrolysis and so on....

Curiosities: why did you skip GPIO19 in the dummy relay example above?

The example was for the M5Stack Atom Lite and I only used Atom Lite physical inaccessible GPIOs for the dummy relays. GPIO19 is out and a dummy relay on this would block this for real functionality on GPIO19.

The orign Atom Lite + Tail485 template for Sugar Valley is

{"NAME":"Sugar Valley","GPIO":[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0,1,1,1,0,0,6976,0,0,0,0,0,7008,1,0,0,0,0,0,0],"FLAG":0,"BASE":1}

Also: is there a way to rename the system model?

No, unfortunately not.

The system model text depends on the content of register MBF_PAR_UICFG_MACHINE, use cmnd "NPRead 0x600" to see which value your device delivers).
This value is firmware hardcoded and fixed assigned by Sugar Valley - so your device returns 9 for "Generic" - this is the case for all unlisted device like your Aquarite+

[alexdelprete]

The system model text depends on the content of register MBF_PAR_UICFG_MACHINE, use cmnd "NPRead 0x600" to see which value your device delivers).
This value is firmware hardcoded and fixed assigned by Sugar Valley - so your device returns 9 for "Generic" - this is the case for all unlisted device like your Aquarite+

I see in the source you linked there's value 11 for Hayward systems, is it normal that NPRead 0x600 gives me value 9 instead?

  MBV_PAR_MACH_HAY                        = 11,     // Hay

[curzon01]

The 9 has been predefined by Sugar Valley as machine code for your reseller model.

You can change it, but I don't know if this only affects the appearance or also internal functionalities (NeoPool was created by an incomplete Sugar Valley register list published on the Internet and a lot of re-engineering. But I did not decompile the firmware for this purpose :-))

Backlog NPWrite 0x600,11;NPExec;NPSave will do the change - may be you need to restart your device after that.

You can also change such things after activating the "Factory" menu on your device by set bit MBMSK_SHOW_FACTORY_MENU (bit 15) in register MBF_PAR_UICFG_VISUAL_OPTIONS (0x605): Backlog NPBit 0x605,15,1;NPExec;NPSave - restart of the device may also be necessary here.

In this then appearing menu "Factory" you can make some additonal settings and internal information queries. It's a bit easier than fiddling around with bits in various Modbus registers. Very useful, but you should know to some extent what you are setting. The machine code can be found under "Style".

[alexdelprete]

It worked, at least in the UI. I'll check if something changed at functional level. Thanks. :)

[curzon01]

I'll check if something changed at functional level.

You really can't :-)
You can only check this very very rudimentary, but not whether internal functionalities and/or control values have been changed by this.

[alexdelprete]

It would be a much better way to implement all this in HA without dummy relays, but as mentioned in the other discussion, I don't have the necessary HA knowledge.

I have some HA knowledge, and since I don't like the dummy relays config, what would be the best way to integrate HA with NeoPool driver on Tasmota? MQTT? I'm thinking about the integration at protocol level.

A custom component could be created in HA, that interfaces NeoPool. I created a modbus custom component for my solar inverter (ABB), but the use case is different here, since NeoPool driver already takes care of the modbus register map, etc.

Please tell me how you would think doing it, so I can think about the HA side (python based).

[curzon01]

I have some HA knowledge, and since I don't like the dummy relays config, what would be the best way to integrate HA with NeoPool driver on Tasmota? MQTT?

Yes absolutely, this is Tasmota standard

I'm thinking about the integration at protocol level.

What do you mean with 'at protocol level'? Some functions like filtration control are not based on single modbus register write, controlling Sugar Valley is somtetimes depending on status of other register bits. And why you want to rewrite the most of Sugar Valley register control logic?

Please tell me how you would think doing it, so I can think about the HA side (python based).

As I understood it after a short research, the most functionalities of NeoPool can be mapped with MQTT from HA yaml (MQTT Sensor, MQTT Number, MQTT Switch, MQTT Button etc.). The receive topic will be a JSON part of Tasmota SENSOR, the command topics will be the NeoPool commands. Search for "home assistant mqtt control values", there I found a lot - and of course Tasmota Home Assistant Integration

I have no HA system and also unfortunately not the time for it, otherwise I would have tried that even briefly.

[alexdelprete]

And why you want to rewrite the most of Sugar Valley register control logic?

I don't want to do it, since there's a good driver you developed for Tasmota. But there's obviously a missing area regarding the integration: relays (and other entities) have to be created manually in the automation platform, and that is another thing to maintain etc. One of the benefits of choosing Tasmota is the automatic integration in HA.

Question: can the driver create the relays etc. in Tasmota so they would automatically be available in HA?

As I understood it after a short research, the most functionalities of NeoPool can be mapped with MQTT from HA

Correct, and that's how I integrated most things. But trust me, for the average user it's not really easy to implement/maintain. My goal was coming up with a really easy way to integrate it (and maintain it), but that's not the case right now.

I will complete the MQTT integration with most of the needed entities, but I will also look at HACO that is the replacement of HCT.

Right now I only have 5 entities, 2 switches and 3 selects, I'll complete this with the rest:

mqtt:
  switch:
    - unique_id: "smartpool_neopool_filtration_switch"
      name: "SmartPool Neopool Filtration Switch"
      device_class: switch
      command_topic: "cmnd/SmartPool/NPFiltration"
      state_topic: "tele/SmartPool/SENSOR"
      value_template:  >-
        {{ value_json.NeoPool.Filtration.State }}
      state_on: "1"
      state_off: "0"
      payload_on: "1"
      payload_off: "0"
      availability_topic: "tele/SmartPool/LWT"
      payload_available: "Online"
      payload_not_available: "Offline"

    - unique_id: "smartpool_neopool_lights"
      name: "SmartPool Neopool Lights"
      device_class: switch
      command_topic: "cmnd/SmartPool/NPLight"
      state_topic: "tele/SmartPool/SENSOR"
      value_template: >-
        {{ value_json.NeoPool.Light }}
      state_on: "1"
      state_off: "0"
      payload_on: "1"
      payload_off: "0"
      availability_topic: "tele/SmartPool/LWT"
      payload_available: "Online"
      payload_not_available: "Offline"

  select:
    - unique_id: "smartpool_neopool_filtration_mode"
      name: "SmartPool Neopool Filtration Mode"
      command_topic: "cmnd/SmartPool/NPFiltrationMode"
      state_topic: "tele/SmartPool/SENSOR"
      command_template: >-
        {% set values = { 'Manual':'0', 'Auto':'1', 'Heating':'2', 'Smart':'3', 'Intelligent':'4', 'Backwash':'13' } %}
        {{ values[value] if value in values.keys() }}
      value_template: >-
        {% set values = { 0:'Manual', 1:'Auto', 2:'Heating', 3:'Smart', 4:'Intelligent', 13:'Backwash' } %}
        {{ values[value_json.NeoPool.Filtration.Mode] if value_json.NeoPool.Filtration.Mode in values.keys() }}
      # options: ["0", "1", "2", "3", "4", "13"]
      options: ["Manual", "Auto", "Heating", "Smart", "Intelligent", "Backwash"]

    - unique_id: "smartpool_neopool_filtration_speed"
      name: "SmartPool Neopool Filtration Speed"
      command_topic: "cmnd/SmartPool/NPFiltration"
      state_topic: "tele/SmartPool/SENSOR"
      command_template: >-
        {% set values = { 'Slow':'1', 'Medium':'2', 'Fast':'3' } %}
        {% if is_state('sensor.smartpool_neopool_filtration_state', '1') %}
          {{ '1 ' + values[value] if value in values.keys() }}
        {% elif is_state('sensor.smartpool_neopool_filtration_state', '0') %}
          {{ '0 ' + values[value] if value in values.keys() }}
        {% endif %}
      value_template: >-
        {% set values = { 1:'Slow', 2:'Medium', 3:'Fast' } %}
        {{ values[value_json.NeoPool.Filtration.Speed] if value_json.NeoPool.Filtration.Speed in values.keys() }}
      options: ["Slow", "Medium", "Fast"]

    - unique_id: "smartpool_neopool_boost_mode"
      name: "SmartPool Neopool Boost Mode"
      command_topic: "cmnd/SmartPool/NPBoost"
      state_topic: "tele/SmartPool/SENSOR"
      command_template: >-
        {% set values = { 'Off':'0', 'On':'1', 'On (Redox)':'2' } %}
        {% if is_state('sensor.smartpool_neopool_filtration_state', '1') %}
          {{ values[value] if value in values.keys() else '99' }}
        {% endif %}
      value_template: >-
        {% set values = { 0:'Off', 1:'On', 2:'On (Redox)' } %}
        {{ values[value_json.NeoPool.Hydrolysis.Boost] if value_json.NeoPool.Hydrolysis.Boost in values.keys() }}
      options: ["Off", "On", "On (Redox)"]

[curzon01]

Question: can the driver create the relays etc. in Tasmota so they would automatically be available in HA?

I can only repeat myself, I have too little knowledge about HA so without further experience with HA I can't answer this.

I would have to look at how the HA integration is structured. I'll take a look using an HA VM, but please don't expect Amazon delivery times, that can take 1-x /days/weeks.

[alexdelprete]

I can only repeat myself, I have too little knowledge about HA so without further experience with HA I can't answer this.

I'm sorry if I'm not being clear: I'm not talking about you having to integrate NeoPool in HA (I will complete the manual MQTT integration). What I'm trying to say is: since Tasmota entities are directly discoverable and integrated in HA via internal Tasmota functionality (SetOption19 0). Tasmota sensors/switches/relays would then be automatically discovered/configured in HA.

In the case of NeoPool entities, only sensors are being picked up, because (I suppose) switches/relays are not configured in Tasmota by the driver. So my question was if the driver can actually create, at Tasmota level, the switches/relays like it does for sensors. Obviously some manual integration will still be required for number entities (pHMin, phMax, Redox setpoint, etc.).

If this is not feasible, the only way I see is using HACO, that from what I read was created specifically for these kind of use cases.

I appreciate all the help and support Norbert.

[curzon01]

I'm not talking about you having to integrate NeoPool in HA (I will complete the manual MQTT integration). What I'm trying to say is: since Tasmota entities are directly discoverable and integrated in HA via internal Tasmota functionality (SetOption19 0). Tasmota sensors/switches/relays would then be automatically discovered/configured in HA.

I know your point but also, answering these questions requires rudimentary knowledge in HA, isn't it? I don't have HA and haven't had any so far. I'm still using my 16 year old FHEM because I haven't looked into any of the newer systems (what's it going to be, Home Assistant, ioBroker, openHAB, Domoticz, IP-Symcon...?)

[alexdelprete]

I haven't looked into any of the newer systems (what's it going to be, Home Assistant, ioBroker, openHAB, Domoticz, IP-Symcon...?)

I tested 3 of them in a 2y time-frame: Hubitat, openHAB and then Home Assistant. I chose HA in the end, and I'm satisfied. Hope you'll be a HA user soon. :)

[alexdelprete]

@curzon01 Norbert, there is some data in the JSON that I'm not 100% sure how to manage because I'm not sure of what it represents. Below you can find an example of my Aquarite+ json data, I added comments with sensor type (switch, binary_switch, sensor, binary_sensor, number, select) based on my understanding, and the description.

switch/binary_switch/number/select are all configurable/actionable, sensors aren't.

I added ??? where I'm not really sure about the meaning. Could you double-check it and eventually correct/integrate it? So I can complete the MQTT configuration in HA. The goal is to have ALL MQTT sensors and not rely on anything else, not even the sensors already present due to the automatic tasmota-HA integration.

Data that doesn't have a comment means I don't think it's valuable to integrate it in HA, but let me know if you think I overlooked anything.

Thanks for the help.

{
    "Time": "2023-10-23T21:31:38",
    "NeoPool": {
        "Time": "2023-10-23T21:31:37",
        "Type": "Generic", // SENSOR - System Type/Model
        "Modules": {
            "pH": 1, // BINARY_SENSOR - Module Presence
            "Redox": 1, // BINARY_SENSOR - Module Presence
            "Hydrolysis": 1, // BINARY_SENSOR - Module Presence
            "Chlorine": 0, // BINARY_SENSOR - Module Presence
            "Conductivity": 0, // BINARY_SENSOR - Module Presence
            "Ionization": 0 // BINARY_SENSOR - Module Presence
        },
        "Temperature": 20.1,  // SENSOR - Water Temperature
        "Power": {
            "Version": "V5.0",      // SENSOR - ???
            "NodeID": "XXXX  0051 XXXX XXXX YYYY XXXX", // SENSOR - ???
            "5V": 5,            // SENSOR - ???
            "12V": 14,          // SENSOR - ???
            "24-30V": 34,       // SENSOR - ???
            "4-20mA": 0.070     // SENSOR - ???
        },
        "pH": {
            "Data": 7.4,   // SENSOR - pH Measurement
            "Min": 7.2,   // NUMBER - pH Min Value (0-14)
            "Max": 7.4,  // NUMBER - pH Max Value (0-14)
            "State": 0,  // BINARY_SENSOR - ???
            "Pump": 0,  // BINARY_SENSOR - Pump Activation State
            "FL1": 0,   // BINARY_SENSOR - ???
            "Tank": 1   // BINARY_SENSOR - Empty Acid Tank
        },
        "Redox": {
            "Data": 540,  // Sensor - Redox Measurement
            "Setpoint": 730  // NUMBER - Redox Setpoint (0-100)
        },
        "Hydrolysis": {
            "Data": 0,   // NUMBER - Chlorine Production Value (0-100)
            "Unit": "g/h",
            "Runtime": {
                "Total": "44T23:55:26",  // SENSOR - Cell Total Runtime (format ???)
                "Part": "44T23:55:26",   // SENSOR - ???
                "Pol1": "22T18:44:42",   // SENSOR - Cell Total Runtime at Pol1
                "Pol2": "22T05:10:44",   // SENSOR - Cell Total Runtime at Pol2
                "Changes": 386           // SENSOR - Cell Total Polarity Switches (???)
            },
            "State": "Flow",  // SENSOR - Cell Production State (Flow/Pol1/Pol2/OFF)
            "Cover": 0,      // BINARY_SENSOR - Cover State (Open/Closed)
            "Boost": 0,      // SELECT - Cell Boost State (On/On+Redox/Off)
            "Low": 0         // BINARY_SENSOR - Low Production Alarm
        },
        "Filtration": {
            "State": 0,   // SWITCH - Filtration Activation
            "Speed": 1,   // SELECT - Filtration Speed (Multiple values)
            "Mode": 0     // SELECT - Filtration Speed (Multiple values)
        },
        "Light": 0,      // SWITCH - Light Relay Activation
        "Relay": {
            "State": [
                0,      // BINARY_SENSOR - pH Relay State
                0,      // BINARY_SENSOR - Filtering Relay State
                0,      // BINARY_SENSOR - Lights Relay State
                0,      // BINARY_SENSOR - AUX1 Relay State
                0,      // BINARY_SENSOR - AUX2 Relay State
                0,      // BINARY_SENSOR - AUX3 Relay State
                0      // BINARY_SENSOR - AUX4 Relay State
            ],
            "Aux": [
                0,      // BINARY_SENSOR - AUX1 Relay State
                0,      // BINARY_SENSOR - AUX2 Relay State
                0,      // BINARY_SENSOR - AUX3 Relay State
                0      // BINARY_SENSOR - AUX4 Relay State
            ],
            "Acid": 0      // BINARY_SENSOR - Acid Pump Relay State
        }
    },
    "TempUnit": "C"
}

[curzon01]

@alexdelprete Alessandro, I have now taken a rough look at three alternate systems and HA in more detail and must say that a lot has happened in the last three years with HA. I had researched it three or four years ago but never looked more closely or tried it out because the systems were still very much 'in development' in my opinion. Meanwhile, a HA test system is running here to see if and how I can adopt the FHEM implementation on HA. You're right, I like HA the best of the systems I've looked at so far, especially because of the good Tasmota integration.

On topic: I saw in the HA logs that in NeoPool the JSON key for the power supply "Power" is unfortunate chosen, HA tries to interpret that as a power control. I am inclined to adjust the key "Power" and rename it (e. g. "Powersupply" or "Powerunit"), the sub key values are all fixed values or sensors. BTW, I'd like to remove or hide the "NodeID" as it's not for public use (best you annonymize this one too, edit your post!).

Thanks for your input regarding JSON values, I'll take a look today or tomorrow, expand the info and also write the necessary commands to control it.

[alexdelprete]

@curzon01 Dear Norbert, I finally have the first working and mostly complete version of the MQTT integration of all entities, and it's working pretty well. This is the first dashboard with most of the entities (not all) and it's all based on MQTT integration with Tasmota, hope you like it. :)

The only entities missing are the duration entries of Hydrolysis because I can't understand the format. HA recognizes timestamps and ISO formats but I need to test better to have it digest them.

I'm very happy about your choice regarding Home Assistant, I feel that for a developer like you, it's the best platform, very flexible and powerful so you will be able to do everything you need to automate things. Plus, we will have a great dev for Tasmota and NeoPool onboard, so we can improve things. :)

While working on the integration, I found out some issues regarding NeoPool:

1. Hydrolysis can be controlled via NPHydrolysis command, but there's no setpoint json entry for it, as there is for Redox, pH Min and pH Max. It's needed because the runtime value is different vs the setpoint.

2. The NPHydrolysis command in your docs says that the payload is the % of cell production, but in my case it is actually the g/h production, and the min-max value of the payload depend on the cell model. In your driver's code I read that id can be % or g/h and it depends on the module configuration, but I haven't found that setting on my Aquarite+. Also, it says DO NOT WRITE, but I guess the NPHydrolysis commands does write it, right? The risk is having a max value higher than real cell max value. So how do we manage this? Is there a register that tells us what's the max production value of the cell?

MBF_PAR_HIDRO_NOM = 0x0306,             // 0x0306*        Hydrolysis maximum production level. (DO NOT WRITE!) If the hydrolysis is set to work in percent mode, this value will be 100. If the hydrolysis module is set to work in g/h production, this module will contain the maximum amount of production in g/h units. (DO NOT WRITE!)

3. The Power in the json works perfectly fine here with MQTT integration, no issues whatsoever. I found out that for these 4 entities, the sensors created by the native Tasmota-HA integration have a wrong unit of measurement (Watts), while they're all V except for 5-20mA which is current, so mA, even though I think the resolution is not correct. I see 0.07mA and I think it's low. I need to compare it with the value provided by the Aquarite+ on the display diagnostics. You might want to check the resolution of that in the driver.

4. It would be really helpful if we had an NPFiltrationSpeed separate command, to configure the pump speed. The two parameters of the NPFiltration command requires some weird trickery in HA's MQTT integration code because I have to check the state of another entity (the filtration state) before sending the command (since it has two parameters and the first is mandatory to set the speed).

I'm going to test the mqtt integration and optimize things and when I feel it's sufficiently good I will share it so you can give it a try. :)

Looking forward to your comments on the above points. Thanks a lot for your support.

Alessandro

[curzon01]

Looks good, very nice. Do you want to share the result when you are done?

Regarding to your points:

duration entries of Hydrolysis

this is the default Tasmota format for runtimes with format [d]T[hh]:[mm]:[ss] (where d=number of days), also used e. g. for Tasmota uptime.

NPHydrolysis command, but there's no setpoint json entry for it,

hydrolysis setpoint is missing - good point

The NPHydrolysis command in your docs says that the payload is the % of cell production, but in my case it is actually the g/h production

This depends on your device setup. If your system works with g/h then this command writes g/h, otherwise %. So only the documentation is incomplete here.

min-max value of the payload depend on the cell model.

max only, there is no min value for NPHydrolysis, min is always 0

Also, it says DO NOT WRITE, but I guess the NPHydrolysis commands does write it, right?

comment READ ONLY applies to register MBF_PAR_HIDRO_NOM. This is set by factory default and fix and therefore should not be written, so I only read this to check the user parameter. Level itself is set by writing MBF_PAR_HIDRO

The risk is having a max value higher than real cell max value.

NPHydrolysis accepts only value between 0 and MBF_PAR_HIDRO_NOM, so that's save

Is there a register that tells us what's the max production value of the cell?

MBF_PAR_HIDRO_NOM, I will add it to "Hydrolysis"

The Power in the json works perfectly fine here with MQTT integration, no issues whatsoever.

Don't know what's your HA setup, I installed on core level and discover my devices by the Tasmota integration. Each Teleperiod SENSOR time I got these errors in OS system logs:

Traceback (most recent call last):
  File "/srv/homeassistant/lib/python3.11/site-packages/homeassistant/components/sensor/__init__.py", line 593, in state
    numerical_value = float(value)  # type:ignore[arg-type]
                      ^^^^^^^^^^^^
ValueError: could not convert string to float: 'V3.57'
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
...

ValueError: Sensor sensor.ga_po_io_oxilife_neopool_power_version has device class 'power', state class 'measurement' unit 'W' and suggested precision 'None' thus indicating it has a numeric value; however, it has the non-numeric value: 'V3.57' (<class 'str'>)

Sure you can override that with manual entries in the YAML, it just doesn't make sense going this way.

except for 5-20mA which is current, so mA, even though I think the resolution is not correct. I see 0.07mA and I think it's low

This value comes from the register MBF_AMP_4_20_MICRO (2-40mA line in µA * 10). This is what I found out by comparing the running value display on the LCD with this register values. Maybe you come to other results, let me know.

0.xx are measurement tolerances and is identical with 0.

helpful if we had an NPFiltrationSpeed separate command, to configure the pump speed. The two parameters of the NPFiltration command requires some weird trickery in HA's MQTT integration

makes sense

So what's currently missing in NeoPool:

• add hydrolysis max level and setpoint
• add separate cmnd NPFiltrationSpeed
• possible change the "Power" key for the power module unit

Regarding the questionmarks within your JSON above

• The "Power" (might be renamed in future) is the power module, "Version" is the version number of the power module firmware, "NodeID" is neccessary to create an account for the Sugar Valley cloud and therefore should be hidden.
• pH.State contains the alarm states for pH dosing as dfescribed in NeoPoolConstAndBitMask MBV_PH_ACID_BASE_ALARM*

0 no alarm
1 pH too high; the pH value is 0.8 points higher than the setpoint (PH1 on acid systems, PH2 on base systems, PH1 on acid+base systems)
2 pH too low: the pH value is 0.8 points lower than the set point value set in (PH1 on acid systems, PH2 on base systems, PH2 on acid+base systems)
3 pH pump has exceeded the working time
4 pH higher than the set point (PH1 + 0.1 on acid systems, PH2 + 0.1 on base systems, PH1 on acid+base systems)
5 pH lower than the set point  (PH1 - 0.3 on acid systems, PH2 - 0.3 on base systems, PH2 on acid+base systems)
6 tank level alarm

• "Runtime" format is [d]T[hh]:[mm]:[ss] as described above. The difference between "Total" and "Part" I can only guess: In case of a cell exchange, the runtime should be reset in the menu. Presumably this sets "Part" to 0 and "Total" is preserved (that would make sense, because I also want to know how long the power supply is running).

[curzon01]

I added comments with sensor type (switch, binary_switch, sensor, binary_sensor, number, select)

I have updated the documentation for this

[alexdelprete]

I have updated the documentation for this

the relays descriptions needs to be checked. and I don't see the pH relay. I have 7 relays (3 system relays + 4 AUX) plus the Acid one, for a total of 8. Correct?

[alexdelprete]

this is the default Tasmota format for runtimes with format [d]T[hh]:[mm]:[ss] (where d=number of days), also used e. g. for Tasmota uptime.

I have to check if HA can digest that format, otherwise I'll need to use a template that converts it first.

This depends on your device setup. If your system works with g/h then this command writes g/h, otherwise %. So only the documentation is incomplete here.

Indeed, it depends on the device configuration, but I haven't found a setting on the Aquarite+ display to change g/h in % mode. Documentation says it should be possible, but I don't know how. Actually % makes more sense so users won't have to bother about checking the max cell production value.

Don't know what's your HA setup, I installed on core level and discover my devices by the Tasmota integration. Each Teleperiod SENSOR time I got these errors in OS system logs:

I use HA Core (in a Proxmox LXC with Docker installed). Indeed, the native tasmota-HA integration sensors throw those errors on those two entities: I disabled them. Actually, once my MQTT integration is complete, I want to disable the integration of that tasmota device completely. Is there a way to disable HA integration on tasmota?

This value comes from the register MBF_AMP_4_20_MICRO (2-40mA line in µA * 10). This is what I found out by comparing the running value display on the LCD with this register values. Maybe you come to other results, let me know.

I confirm the resolution of the mA sensor is fine, I double-checked with the value on Aquarite+ display. Initially it seemed off, my bad.

So what's currently missing in NeoPool:

• add hydrolysis max level and setpoint
• add separate cmnd NPFiltrationSpeed
• possible change the "Power" key for the power module unit

Agreed.

Regarding my MQTT integration, I'd prefer not to share it publicly right now because it's not 100% tested, tell me how I can send it to you privately. I'm available on Discord and Telegram as @alexdelprete if you use one of those services. Or tell me how I can send it to you. :)

[curzon01]

Indeed, it depends on the device configuration, but I haven't found a setting on the Aquarite+ display to change g/h in % mode. Documentation says it should be possible, but I don't know how. Actually % makes more sense so users won't have to bother about checking the max cell production value.

There is no way changing this using display, the mode is predefined by reseller. Some using %, some g/h because you also need to know the cell power delivered with the system to get the max g/h and other internal parameters. You can't easily switch to both.

Is there a way to disable HA integration on tasmota?

SetOption19 1 or Discover 0

tell me how I can send it to you privately.

NeoPool driver header or click on my github avatar, there you will find my mail .

[alexdelprete]

There is no way changing this using display, the mode is predefined by reseller.

Understood now.

SetOption19 1 or Discover 0

I knew about SO19, but that only changes how it's discovered (native vs MQTT autodiscovery).

Discover command was unknown to me. I can't find it in the Commands section of Tasmota docs. I guess that totally disables discovery, right? I wonder if it has an impact also for other tasmota tools I use (TDM, etc.).

NeoPool driver header or click on my github avatar, there you will find my mail .

Will send you an email.

[curzon01]

I knew about SO19, but that only changes how it's discovered (native vs MQTT autodiscovery).

this is only the case when you compiled your bin expliciet defining USE_HOME_ASSISTANT, the standard bins and defines are without, see BUILDS.md.
Default is USE_TASMOTA_DISCOVERY and this undefines the legacy USE_HOME_ASSISTANT, see xdrv_12_discovery driver.

[alexdelprete]

Now it's clear. Documentation should be updated though.

And the Discover command, disables ALL kinds of discovery?

BTW: I sent you an invitation. Made the repo public: https://github.com/alexdelprete/HA-NeoPool-MQTT

I also opened a new thread in HA forums: https://community.home-assistant.io/t/ha-neopool-mqtt-integration-of-tasmota-neopool-for-sugar-valley-hayward-aquarite-bayrol-devices/632517/2

[curzon01]

And the Discover command, disables ALL kinds of discovery?

for this single device, yes.
It stops sending the two discover topics tasmota/discovery/<Mac>/sensors and tasmota/discovery/<Mac>/config - observe the topic tasmota/discovery/# of your mqtt server (Mac is the tasmota device mac without the colons)

[alexdelprete]

While SO19 0 stops only the integration for HA (if not compiled with USE_HOME_ASSISTANT)? What topics does SO19 send?

Thanks for clearing this out for me.

[curzon01]

I can't help you with those details, what I wrote was a quick shot inside the source.
The prefered way is described under Removing devices

BTW: NeoPool adds/changes #19857 merged, so you can further test with the current tasmota dev.

[alexdelprete]

The prefered way is described under Removing devices

I know how to remove the device from HA, but if you don't disable discovery on tasmota, it will be rediscovered. Since Discover 0 is a little bit too drastic, and we want only HA discovery to be disabled when using the MQTT integration, I have to specify in the notes to build the neopool tasmota fw without USE_HOME_ASSISTANT and then disable HA discovery with SO19 0. If I understood correctly...:)

NeoPool adds/changes #19857 merged, so you can further test with the current tasmota dev.

Thanks Norbert. I use benzino77/tasmocompiler to produce the custom firmware, I have to check how to configure it to use dev branch.

[alexdelprete]

UPDATE: I updated to dev version, everything's working as expected, the only thing that doesn't seem to have effect on json sensor output is SO157, I thought it would've masked the NodeID but I still see it in clear.

I updated package/lovelace files accordingly: https://github.com/alexdelprete/HA-NeoPool-MQTT

What version of Tasmota stable will contain #19857 ? I'd like to point out in the pre-requirement notes the minimum Tasmota version.

Thanks.

[curzon01]

Forget the discover state and compiling special versions, the easy solution is using different sensor naming in your manual yaml not matching the discovered one, that's what I did

[curzon01]

doesn't seem to have effect on json sensor output is SO157

wrong way used. SO157 1 displays nodeid, SI157 0 hides it, default is 0.

What version of Tasmota stable will contain #19857 ?

PRs like #19857 are always only available in development branch until next release.
User has to use the latest dev until next release.

[alexdelprete]

Forget the discover state and compiling special versions, the easy solution is using different sensor naming in your manual yaml not matching the discovered one, that's what I did

yes, I already made sure to pick a different sensor name (neopool_mqtt prefix). it makes sense not to disable HA discovery, also to compare sensors in case of issues.

wrong way used. SO157 1 displays nodeid, SI157 0 hides it, default is 0.

my bad, thanks for the explanation.

User has to use the latest dev until next release.

Right now stable is v13.2.0.1. Is it safe to say that stable > 13.2.0.1 will contain #19857?

[alexdelprete]

this is the default Tasmota format for runtimes with format [d]T[hh]:[mm]:[ss] (where d=number of days), also used e. g. for Tasmota uptime.

I finally managed to add the Hydrolysis Runtime entities, I converted the format and created MQTT Sensors with device_class: duration. The format is h:m:s. Updated files on the repo.

I also found out a major problem for the MQTT switch entities (and possibly, all modifiable/actionable MQTT entities, well described in HA documentation:

This is the configuration of a MQTT Switch:

  switch:
    - unique_id: "neopool_mqtt_light"
      name: "NeoPool MQTT Light"
      device_class: switch
      command_topic: "cmnd/SmartPool/NPLight"
      state_topic: "tele/SmartPool/SENSOR"
      retain: true
      optimistic: false
      value_template: >-
        {{ value_json.NeoPool.Light }}
      payload_on: 1
      payload_off: 0
      state_on: 1
      state_off: 0
      availability_topic: "tele/SmartPool/LWT"
      payload_available: "Online"
      payload_not_available: "Offline"

When you start HA, or reload the config, these entities are reinitialized. I'm using tele/SmartPool/SENSOR to determine the state of the switch. Problem is that if the SENSOR topic is not retained, all the entities are unavailable until the TelePeriod timer expires and the data is refreshed. So in the readme I'm recommending a configuration with TelePeriod 10 and SensorRetain 1. With this config, when you restart/reload HA the NeoPool entities are immediately available. The only minor issue is that if you change the switch state by clicking it, HA sends the command, but it has to wait another TelePeriod cycle to reflect the state change of the switch.

One solution (cleanest one) is to use SO4 1 and state_topic: stat/SmartPool/NPLIGHT, that contains the immediate result of the command. This works, and it's immediate when you click the switch, but it has one major issue I wasn't able to solve: when you restart/reload HA, the stat/SmartPool/NPLIGHT topic is not available, since it doesn't have the retain flag, and I found no Tasmota config to enable retain on the result of a command.

If you have any suggestion regarding this last main issue, I'd be very happy to hear it.

Thanks,

Alessandro

[curzon01]

Did some fixes, pull your repo

The only minor issue is that if you change the switch state by clicking it, HA sends the command, but it has to wait another TelePeriod cycle to reflect the state change of the switch.

use the backlog trick with an appended Teleperiod (without parameter) cmnd:

  switch:
    - unique_id: "neopool_mqtt_light"
      name: "NeoPool MQTT Light"
      device_class: switch
      command_topic: "cmnd/SmartPool/Backlog"
      state_topic: "tele/SmartPool/SENSOR"
      retain: true
      optimistic: false
      value_template: >-
        {{ value_json.NeoPool.Light }}
      payload_on: "NPLight 1;Teleperiod"
      payload_off: "NPLight 0;Teleperiod"
      state_on: 1
      state_off: 0
      availability_topic: "tele/SmartPool/LWT"
      payload_available: "Online"
      payload_not_available: "Offline"

use this everywhere might solve your major issue.

[alexdelprete]

I already tried that trick when I posted, but unfortunately it doesn't work. I think because value_template is parsed before sending the commands, so we still wait the TelePeriod cycle when activating the switch. :(

The only real solution would be to have stat/SmartPool/%command% retainable. Like with the SensorRetain command. But that is a Tasmota FR because I didn't find a way to do that in the documentation.

[alexdelprete]

New UI: hope you like it.