HA NeoPool MQTT: integration of Tasmota NeoPool (for Sugar Valley, Hayward/Aquarite, Bayrol devices)

Dear Alessandro, in my installation, I do not have the light color change capability, like what does appear in your 1st post picture (on my laptop); Could you direct me to a solution ?

I’ve been working with @alexdelprete sensors config and managed to get the filtration schedule slots. I’ve been able to define two sensors for the first slot (start_time and duration for now, but has more data like frequency) like this (inside ha_neopool_mqtt_package.yml package):

  number:
    [...]

    # Schedule 1 - Start Time
    - unique_id: "neopool_mqtt_filtration_schedule_1_start_time"
      name: "NeoPool MQTT Filtration Schedule 1 Start Time"
      min: 0
      max: 86400
      state_topic: "stat/SmartPool/RESULT"
      value_template: >-
        {%if value_json.NPReadL and value_json.NPReadL.Address == 1077 %}
          {{value_json.NPReadL.Data[0] / 3600 }}
        {% endif %}
      command_topic: "cmnd/SmartPool/NPWriteL"
      command_template: "{{ value|string + ' %' }}"
      optimistic: false
      retain: true

    # Schedule 1 - Duration
    - unique_id: "neopool_mqtt_filtration_schedule_1_duration"
      name: "NeoPool MQTT Filtration Schedule 1 Duration"
      min: 0
      max: 24
      state_topic: "stat/SmartPool/RESULT"
      value_template: >-
        {%if value_json.NPReadL and value_json.NPReadL.Address == 1077 %}
          {{value_json.NPReadL.Data[3] / 3600 }}
        {% endif %}
      command_topic: "cmnd/SmartPool/NPWriteL"
      command_template: "{{ value|string + ' %' }}"
      optimistic: false
      retain: true

This results in two sensors having number values like this ones:

That means filtration starts at 10:30 (10.5) and has a duration of 8.5 hours.

PROBLEMS/caveats I’ve found so far:

  • I haven’t been able to make the start_time sensor a time sensor. I guess that’s not supported for mqtt as I got related errors.
  • This data are NOT periodically published you have to send a command to had them published.

The command appears in Tasmota docs, but basically you need to publish in cmnd/SmartPool/Backlog this raw payload:

NPResult 0;NPRead 0x434;NPReadL 0x435,7;NPRead 0x443;NPReadL 0x444,7;NPRead 0x452;NPReadL 0x0453,7

I’ve shortened it to this:

NPReadL 0x435,7;NPReadL 0x444,7;NPReadL 0x0453,7

or this if you only want the first schedule (each block separated by ;):

NPReadL 0x435,7;

Thing is, Âżis there any way (other than an automation) that handles updating mqtt messages like this?

Do you know (using an ESP32) you don’t need to ‘poke’ the register directly? There already exists an NPTimer command using NeoPool Berry extension, which is able to handle all the timers.

1 Like

yes, but no long-term values yet (had very few transmission errors anyway), so I’ll have to wait and see if there are any significant changes.

@alexdelprete HA integration is based solely on the data that comes in periodically via the Teleperiod SENSOR topic.

I implement the NPTimer command with Berry as a first step to have a base to handle the timers easier. One consideration would be to append the timer values to the SENSOR topic, but we are reaching the limits of the Tasmota limits here. The SENSOR JSON with NeoPool module is currently already so large (we currently have a string length of more than 1.5 kB with the connection statistic, I don’t even know where the limit is for the ESP82xx Tasmota at the moment).

Another possibility would be to simply send a separate NPTIMER topic whenever SENSOR is sent. This is easy to implement, e.g. using a Tasmota Rule:

Rule1 ON Tele-NeoPool#Time DO Backlog NPTimer1;NPTimer2;NPTimer3 ENDON

and enable it using Backlog Rule1 4;Rule1 1

This sends the topics NPTIMER three times whenever SENSOR is sent:

stat/SmartPool/NPTIMER = {"NPTimer1":{"Mode":"Timer","State":"ON","Allocation":"Filtration","Start":"09:00","End":"21:10","Period":"1d"}}
stat/SmartPool/NPTIMER = {"NPTimer2":{"Mode":"Timer","State":"OFF","Allocation":"Filtration","Start":"00:00","End":"00:00","Period":"1d"}}
stat/SmartPool/NPTIMER = {"NPTimer3":{"Mode":"Timer","State":"OFF","Allocation":"Filtration","Start":"00:00","End":"00:00","Period":"1d"}}

to eval check the json keys “NPTimerx” for existence (e.g. value_json['NPTimer1'] is defined)

1 Like

Yes, I was playing arond and thiking about making a PR adding timers support.

The more I play, the more I think this needs a proper HA integration :joy:

At first I thought timers weren’t implemented as Tasmota NeoPool page talks about timer records BEFORE saying it’s already implemented using Berry. Didn’t got to the enhancements sections and started to play around.

NPTimer works flawlessly, great work :slight_smile:

Guessed that timers info wasn’t published in SENSOR due to memory/performance.

Why not using 3 different topics? Having a “hardcoded” limit of 3 timers gives sense (imho) to have three fixed topics like /stat/SmartPool/NPTIMER/1, /stat/SmartPool/NPTIMER/2 and /stat/SmartPool/NPTIMER/3.

I’m going to give it a try with the Rules. I had never really touched Tasmota before, this has been like a two days intensive course :rofl:

Thanks!

Yes, I would like that too.
But I already had enough to do with the NeoPool programming in Tasmota, especially as I had to find out many of the functionalitys and dependents by time-consuming reverse-engineering, somehow I don’t have the time to familiarise myself with real HA integrations.

exact

As these topics are the default result of a Tasmota command, they are Tasmota rules.
BTW: The system also has a total of 12 timers, not only three.

This makes also querying the registers in some functions complex because not all hardware is shipped with the same configuration. Solutions should work for all systems based on the Sugar Valley platform, not just for one Oxilife.
Sugar Valley systems can be very different in set up, just as an example: The default relay assignments in these systems are not hard coded but can be reconfigured for each system without changing the hardware.

I guess some limits must be added somewhere :joy:

I’ve got like a 2.5k ÂșC temperature:

image

and a value of 0 for ph:

image

Second case is not so important, first one is because totally breaks the chart.

Use Tasmota from current development branch or if you didn’t self-compile a pre-compiled bin from this Integration development branch, it contains data validation since Tasmota v14.1.0.3

1 Like

this has already been discussed and requested a long time ago (this long thread has a lot of useful info and discussions between me and Norbert) and finally @curzon01 agreed and implemented it in latest dev branch version of the fw. not only limits are enforced at tasmota level, but also connection diagnostic sensors are provided and I expose them in my integration.

It’s in the to-do list, I’ve already developed 3 custom components (2 modbus based and one for a device with a custom protocol) so I have the foundation ready, I just need to find the time and with my new job I have very little unfortunately.

Feel free to start the “proper” integration, if you have time and will. :slight_smile:

1 Like

@alexdelprete thanks a lot for this, it works well but I had some hard times and recommend to add the following clarifications into your guide for less experienced users:

  1. Add a step that you need in the tasmota web ui (when connected via usb) or under the ip (after adding wifi) the MQTT login details
  • MQTT server ip
  • MQTT user
  • MQTT password
  1. Clarify the step what needs to be exactly copy pasted into configuation.yaml and where which of tour yamls needs to be stored (eg packages folder).

  2. maybe directly in your guide copy paste the pin order from top to bottom statting with 12v, empty space, A, B, G

All of above is in the thread already as replies but will help others to get it done easier instantly :slight_smile:

Great job and thanks for tour work!

1 Like

Anybody could help me on this matter ???

Probably the “Light Color” dropdown comes from one of the first attempts, don’t know.

In general: You do not have the color change capability because your Sugar Valley system does not have this either. You can’t control specific colors via Tasmota NeoPool → Sugar Valley (and so also not with this integration), because your SV is technically not capable to to this.
SV systems can only control color lamp types that change their color scheme by switching on and off with a specific delay. This type of lamp changes from one color pattern to the next and the color content and sequence vary from manufacturer to manufacturer.

Perhaps there are lamps with the manufacturer’s own RGB controller for which there is HA integration, unfortunately I don’t know.

That’s a customization of my setup. It’s not part of the project. I have radio controlled lights, and I included the integration in my pool lovelace interface. :slight_smile:

It’s not included in the yaml because it only works in my setup. But when I make screenshots I forget that. :slight_smile:

Thanks for your answer. My system is the Ayward Aquarite+ which is able to change color as you can see in the screenshot of the standard Ayward wifi interface.
I will try to play with the NPLight 4 command
may be I could get it to work


A color change is possible, but not a change to a specific color, as you can see in the 1st picture - not even via the vistapool portal.

The solution, as you have already recognized, is NPLIGHT 4, but your lighting must support this light change function via ON/OFF. The vistapool portal does nothing more than NPLIGHT 4.

I have just tested it, and it does work like planned when I send the command “cmnd/SmartPool/NPLight 4” in the cpnsole. (ie: change color one by one). Now I have to figure how to add this in HA
 and I have no clue !

EDIT: Works like a charm ! Simply duplicate the light on/off button and link it to a new switch in the yaml section :slight_smile: - unique_id: “neopool_mqtt_light_color”
name: “NeoPool MQTT Light Color”
device_class: switch
command_topic: “cmnd/SmartPool/NPLight”
state_topic: “tele/SmartPool/SENSOR”
optimistic: false
retain: false
value_template: “{{ value_json.NeoPool.Light }}”
payload_on: “4”
payload_off: “4”
state_on: “1”
state_off: “0”
availability_topic: “tele/SmartPool/LWT”
payload_available: “Online”
payload_not_available: “Offline”

exact, you can also solve such simple things quickly in lovelace itself, here a button for example:

  - type: button
    name: Light Color
    icon: mdi:palette
    show_name: true
    show_icon: true
    tap_action:
      action: perform-action
      perform_action: mqtt.publish
      target: {}
      data:
        topic: cmnd/SmartPool/NPLight
        payload: '4'
        qos: '0'

I’ve never done an integration before, only a couple of custom cards. I don’t feel like having tasmota knowledge enough.

I’ll make a PR to your repo with some of the info I missed :slight_smile:

Thanks!

PS: hope the word “proper” didn’t upset you, I’m really thankfull for the work you’ve done.

Thank you very much.

No worries. I understood what you meant: a full custom component.

Thanks for the kind words, and for your future contributions.