Ok,
I solved the problem.
Entity id was still old even I change the name in configuration.yaml.
Adam
Ok,
I solved the problem.
Entity id was still old even I change the name in configuration.yaml.
Adam
Hi,
I would like to ask you to help me how to modify this script to control two way of domoticz Thermostat setpoint based on HA climate. Sync from HA to domoticz.
I dont need control of turning on/off valve, I just need to be able to set and read target temperature.
Adam
To DZ, you need to add in trigger climates entities attribute temperature that you want to send. In variables set the corresponding DZ idx, and in payload template add this condition
{% elif trigger.to_state.domain == 'climate' %}
I did that for the pid attributes, here the complete automation, you’ll have to modify it in order to include the temperature attribute
- id: your own
alias: Publish to DZ (switch, sensor, input_boolean, counter, proximity, climate attributes)
description: ''
variables:
entities:
# 2023/03/21 : ai ajouté un index supplémentaire pour caractériser l'entity
# si = 0, alors l'entity est traitée comme telle
# si = 1, alors l'entity est traitée de façon alernative
# exemple : dans DZ binary_sensor peut-être représenté par un switch ou par une alerte
switch.pressostat: [644,0]
sensor.pressostat_power: [647,0]
sensor.pressostat_voltage: [653,0]
binary_sensor.pressostat_overpowering: [652,1] # c'est une alerte au sens de dz
switch.alimentation_electrovannes: [645,0]
sensor.alimentation_electrovannes_power: [648,0]
switch.fil_chauffant: [646,0]
switch.radiateur_buanderie_kfe_f: [703,0]
sensor.fil_chauffant_power: [649,0]
switch.shellypro4pm_083af27c0770_switch_3: [631,0]
sensor.shellypro4pm_083af27c0770_switch_3_power: [632,0]
input_boolean.arrosage_master: [659,0]
counter.eau: [666,0]
climate.device_pid_id3: [698,0]
climate.device_pid_id5: [693,0]
input_boolean.pressostat_power_auto: [704,0]
binary_sensor.fenetre_chambre_amis : [642,0] # c'est un switch au sens de dz
binary_sensor.fenetre_chambre : [540,0] # c'est un switch au sens de dz
binary_sensor.velux_atelier_peinture : [544,0] # c'est un switch au sens de dz
binary_sensor.velux_chambre : [542,0] # c'est un switch au sens de dz
binary_sensor.velux_chambre_amis : [543,0] # c'est un switch au sens de dz
cover.circulateur_cover_1: [709,0] # Position circulateur
index: '{{ entities.get(trigger.entity_id)[0] }}'
type: '{{ entities.get(trigger.entity_id)[1] }}'
alert:
'off': 1
'on': 4
alert_level: '{{ alert.get(trigger.to_state.state, 0) }}'
alert_value:
'off': Dépassement de puissance résolu
'on': Dépassement de puissance
alert_text: '{{ alert_value.get(trigger.to_state.state, 0) }}'
trigger:
- platform: state
entity_id:
- switch.pressostat
- sensor.pressostat_power
- sensor.pressostat_voltage
- binary_sensor.pressostat_overpowering
- switch.alimentation_electrovannes
- sensor.alimentation_electrovannes_power
- switch.fil_chauffant
- switch.radiateur_buanderie_kfe_f
- sensor.fil_chauffant_power
- switch.shellypro4pm_083af27c0770_switch_3
- sensor.shellypro4pm_083af27c0770_switch_3_power
- input_boolean.arrosage_master
- input_boolean.arrosage_ev_atelier
- input_boolean.arrosage_ev_maison_journalier
- input_boolean.arrosage_ev_jardin_devant
- counter.eau
- input_boolean.pressostat_power_auto
- binary_sensor.fenetre_chambre_amis
- binary_sensor.fenetre_chambre
- binary_sensor.velux_atelier_peinture
- binary_sensor.velux_chambre
- binary_sensor.velux_chambre_amis
- cover.circulateur_cover_1
- platform: state
id: pid_p
entity_id:
- climate.device_pid_id3
- climate.device_pid_id5
attribute: pid_p
- platform: state
id: pid_d
entity_id:
- climate.device_pid_id3
- climate.device_pid_id5
attribute: pid_d
- platform: state
id: pid_i
entity_id:
- climate.device_pid_id3
- climate.device_pid_id5
attribute: pid_i
- platform: state
id: pid_dt
entity_id:
- climate.device_pid_id3
- climate.device_pid_id5
attribute: pid_dt
- platform: state
id: pid_e
entity_id:
- climate.device_pid_id3
- climate.device_pid_id5
attribute: pid_e
condition: >
{% if trigger.to_state.domain == 'cover'%}
{{ index != 0 and (trigger.to_state.state == "open" or trigger.to_state.state == "opened" or trigger.to_state.state == "close" or trigger.to_state.state == "closed") }}
{% else %}
{{ index != 0 }}
{% endif %}
action:
- service: mqtt.publish
data:
topic: domoticz/in
payload_template: >
{% if trigger.to_state.domain == 'switch' or trigger.to_state.domain == 'input_boolean'%}
{"command": "switchlight", "idx": {{ index }}, "switchcmd": "{{ trigger.to_state.state | title }}"}
{% elif trigger.to_state.domain == 'sensor' %}
{"command": "udevice", "idx": {{ index }}, "nvalue": 0, "svalue": "{{ trigger.to_state.state }}"}
{% elif trigger.to_state.domain == 'proximity' %}
{"command": "udevice", "idx": {{ index }}, "nvalue": 0, "svalue": "{{ trigger.to_state.state | multiply(100) }} "}
{% elif trigger.to_state.domain == 'binary_sensor' %}
{% if type == 1 %}
{"command": "udevice", "idx": {{ index }}, "nvalue": {{ alert_level }}, "svalue": "{{ alert_text }}"}
{% elif type == 0 %}
{"command": "switchlight", "idx": {{ index }}, "switchcmd": "{{ trigger.to_state.state | title }}"}
{% endif %}
{% elif trigger.to_state.domain == 'counter' %}
{"command": "udevice", "idx": {{ index }}, "nvalue": 0, "svalue": "{{trigger.to_state.state | int + state_attr('counter.eau', 'initial') }}"}
{% elif trigger.to_state.domain == 'cover' %}
{"command": "switchlight", "idx": {{ index }} , "switchcmd": "Set Level", "level" : {{ state_attr(trigger.to_state.entity_id, "current_position") | round(0)}} }
{% elif trigger.to_state.domain == 'climate' %}
{% if trigger.id == "pid_p" %}
{"command": "udevice", "idx": {{ index }}, "nvalue": 0, "svalue": "{{state_attr(trigger.entity_id, 'pid_p')}}"}
{% elif trigger.id == "pid_d" %}
{"command": "udevice", "idx": {{ index | int + 1 }}, "nvalue": 0, "svalue": "{{state_attr(trigger.entity_id, 'pid_d')}}"}
{% elif trigger.id == "pid_i" %}
{"command": "udevice", "idx": {{ index | int + 2 }}, "nvalue": 0, "svalue": "{{state_attr(trigger.entity_id, 'pid_i')}}"}
{% elif trigger.id == "pid_dt" %}
{"command": "udevice", "idx": {{ index | int + 3 }}, "nvalue": 0, "svalue": "{{state_attr(trigger.entity_id, 'pid_dt')}}"}
{% elif trigger.id == "pid_e" %}
{"command": "udevice", "idx": {{ index | int + 4 }}, "nvalue": 0, "svalue": "{{state_attr(trigger.entity_id, 'pid_e')}}"}
{% endif %}
{% endif %}
qos: '0'
retain: true
mode: queued
max: 30
As for the opposite, I haven’t done it, but I have a similar automation for other values, again you’ll have to adapt it, test_condition and choose conditions
- id: your own
alias: Store DZ input values
variables:
indexes:
44: input_number.idx44
256: input_number.idx256
377: input_number.idx377
387: input_number.idx387
388: input_number.idx388
389: input_number.idx389
393: input_text.idx393 # Etat du puisard texte
467: input_text.idx467
584: input_text.idx584
630: input_text.idx630
656: input_text.idx656
entity: '{{ indexes.get(trigger.payload_json.idx, "unknown") }}'
input_type: '{{ entity.split(".")[0] }}'
alert_type: '{{ trigger.payload_json.stype == "Alert" }}'
test_condition: |
{% if input_type == "input_number" %}
{{ trigger.payload_json.nvalue !=0 and entity != "unknown" }}
{% else %}
{{ entity != "unknown" }}
{% endif %}
trigger:
- platform: mqtt
# topic: domoticz/out/#
topic: dz/mqttFloorPlan/mqttDevices
condition: '{{ test_condition }}'
action:
- choose:
- conditions:
- condition: template
value_template: >
{{ trigger.payload_json.stype != "Alert" }}
sequence:
- service: '{{ input_type }}.set_value'
target:
entity_id: '{{ entity }}'
data:
value: '{{trigger.payload_json.svalue1 }}'
- conditions:
- condition: template
value_template: >
{{ trigger.payload_json.stype == "Alert" }}
sequence:
- service: '{{ input_type }}.set_value'
target:
entity_id: '{{ entity }}'
data:
value: '{{trigger.payload_json.svalue1 }}'
- service: input_number.set_value
target:
entity_id: '{{ "input_number." ~ entity.split(".")[1] }}'
data:
value: '{{trigger.payload_json.nvalue }}'
mode: queued
max: 25
You may notice that originally the script listened to domoticz/out/# which means it was triggered all the time even if it had nothing to process. In order to avoid that, I setup a second MQTT client on DZ side, using the floor option. Every idx that is pushed to HA is included in a specific room that is called mqttdevices.
It may seem rather complex, but I can tell you it is rock solid.
Hi @kolia - thanks for the detailed explanations here, very informative
I would like to improve my current setup and for this I’d like to clarify a couple of things. First of all, about the mqtt hardware setup in Domoticz. In my case I need to publish to the flat domoticz/out topic in order to sync with Homekit/Homebridge so I need to keep that one in place. Then I see you are using the index option for domoticz/out/[idx] for creating mqtt entities in HA as displayed here: Help with mqtt templating (from Domoticz) - #68 by kolia
If I undestand correct, this allows two-way communication as such with Domoticz (state coming to HA from state_topic, commands going to Domoticz via command_topic ). So if the device is created only in Domoticz, this would be the preferred way to integate it into HA?
But then you also have the mqtt setup with floorplan and I assume this is for entities created originally in HA that you want to see in Domoticz? And if you change the status in Dz, you update it to HA via the mqtt floorplan option and vice versa if you change it in HA, you update the status to Domoticz via domoticz/in? So this is why several mqtt hardware is needed? In my case three as I also need the flat domoticz/out…
Have you considered using the index option (domoticz/out/[idx]) to update statuses to Dz - or it does not work so easily? Or you want to be able to filter entities differently for both? As you may know, there is option to include only certain entities for the mqtt as such (through setup in Hardware section) without floorplan? Just thinking for myself at least that I would like to avoid additional mqtt hardware is possible…
And finally, for integrating climate devices created in HA to Domoticz, I was a bit puzzled with this pid approach. Could you elaborate it a little more? I noticed in the trigger you have e.g.
- platform: state
id: pid_p
entity_id:
- climate.device_pid_id3
- climate.device_pid_id5
attribute: pid_p
But where is this id: pid_p coming from? Is there really this kind of attributes there in your device? Because if I look at one of my climate devices, I see these attributes:
I would want the update trigger whenever there is change in hvac_mode, current_temperature or temperature. In Domoticz I think there would be one setpoint device (temperature), one temp sensor (current_temperature) and one selector switch (hvac_mode) to be controlled and to be sent back from Domoticz if they change. Could you give a small example how this would look like in your approach?