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 ?
HA NeoPool MQTT: integration of Tasmota NeoPool (for Sugar Valley, Hayward/Aquarite, Bayrol devices)
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 atime
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.
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
)
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
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
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
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
Iâve got like a 2.5k ÂșC temperature:
and a value of 0 for ph:
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
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.
@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:
- 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
-
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).
-
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
Great job and thanks for tour work!
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.
Itâs not included in the yaml because it only works in my setup. But when I make screenshots I forget that.
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 - 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
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.