Non, c’est que si tu l’utilise avec l’application tuya
tout ce qui est possible est dans la doc
Non, c’est que si tu l’utilise avec l’application tuya
tout ce qui est possible est dans la doc
Et l’alarme est pas gérée par le capteur c’est une notification de l’appli.
justement cet attribut n’apparait pas dans la liste…
beh tu peu pas alors. A moins qui soit dans un autre cluster?
Vaut mieux éviter de toucher si tu c’est pas trop ce que tu fais avec les clusters.
ok.
mais du coup, en natif, on est sur du 5’ c’est ça (apparemment ce n’est pas précisé dans cette doc…)
C’est ce qui est indiqué toutes les cinq minutes ou si un changement de 0.6 ou 6% intervient.
A pas utiliser pour un thermostat virtuel
As-tu essayé le service homeassistant.update_entity ?
https://www.home-assistant.io/integrations/homeassistant#service-homeassistantupdate_entity
Je ne promet rien, mais ça a l’air prometteur non ?
oui je l’ai fait… et ça marche super bien
je vais regarder ça… néanmoins si rien n’est publié sur le broker, je ne vois pas comment il va aller le chercher à part avec un get()… mais je ne comprends pas alors comment ça envoie l’info… je vais tester…
@titoumimi : tu as déjà essayé toi ?
Jamais pour une entité Zigbee, seulement pour mes clims mais wifi… ^^
hummm…
tu as fait une automation ?
Oui, pour test j’avais fait quelque chose comme ça dans node red, et je trouvais ça pas mal
Mon premier bloc ne testait rien du tout, c’était juste pour m’assurer un déclenchement toutes les 30 secondes
Sinon, je suis tombé là dessus (en anglais), qui semble permettre de modifier la configuration de fréquence d’un device zigbee :
en node red donc… non ?
Oui, mais c’est faisable dans les automatisations classiques normalement :
alias: sandbox
description: ""
trigger:
- platform: time_pattern
minutes: /30
condition: []
action:
- service: homeassistant.update_entity
data: {}
target:
entity_id: climate.salon
mode: single
je vais essayer mais je pense que cela va juste aller lire la valeur du broker, pas aller chercher la valeur via mqtt