Ca reste une seconde, l’état dans MQTT Explorer est bien sur 1, l’ampoule est allumée et ca redevient gris et j’ai beau recliquer sur le bouton, il ne se passe plus rien.
Qu’est-ce que j’ai oublié ?
Pour savoir sur quelle entité se baser pour la valeur, va dans Outils de développement → Onglet ETATS et cherche plutôt sensor.etat ou binary_sensor.etat.
Mais je pense qur ça va être sensor et donc il faut mettre 0 et non on.
En résumé, comme se nomme ton entité de l’état de la prise mqtt ?
j’ai relancé HA
l’état de ma prise est sur 1
pourtant ma prise est grisée, je clique c’est à nouveau bleu 1s et ça redevient gris.
Si j’éteins avec jeedom, le voyant devient bleu, je clique ça devient gris puis redevient bleu mais la prise est toujours éteinte.
Il doit y avoir une inversion quelque part mais je ne sais pas où
Il y a une dernière chose qui me fait bloquer, c’est la lecture de l’état de la prise.
Avec MQTT, ça ne se met à jour qu’en cas d’action sur la prise (du coup je peux très bien éteindre sans le vouloir)
J’ai une URL directe pour lire la valeur 0 ou 1.
Comment je peux l’attribuer dans cette ligne : value_template: « {{ is_state(‹ sensor.etat ›, ‹ 0 ›) }} »
C’est encore une url du type https://xxxxxxxxxxxxx.eu.jeedom.link/core/api/jeeApi.php?apikey=xxxxxxxxxxxxxxxxxx&type=cmd&id=5052
Merci je vais tester ça.
J’avais trouvé un biais avec Jeedom avec une scénario qui se répète toutes les minutes et qui force l’envoi des données MQTT (mais j’ai un peur peur que ça surcharge le système)
Le « problème » avec ces solutions, c’est que la mise à jour de l’état jeedom ne sera reflétée que par polling (soit la minute du scenario, soit le scan_interval) et donc, tu auras l’impression que le « on » envoyé par HA ne se reflète pas dans le binary_sensor.etat immédiatement.
Il faudrait soit passer par l’url de push global de jeedom, ou avoir un scenario dans jeedom qui réagit sur le changement d’état et qui pousse l’état en mqtt ou autrement. Comme ça, ça sera vraiment immédiat.
Avec l’utilisation de Rest pour récupérer un état, si la commande est du côté de HA, le mieux est d’ajouter une automatisation qui aura comme déclencheur la commande et comme action le service homeassistant.update_entity (ajouter un delay si pendant la mise au point la requête est trop tôt et que le changement côté Jeedom n’est pas encore effectué).
SI la commande n’est pas dû coté de HA, oui, il y aura un délai certain mais minime.
Dis toi que depuis 2 ans, sur un RPi2, j’ai une automatisation qui se déclenche toutes les 30 secondes H24 et que je n’ai constaté aucun ralentissement (autre que déjà présent dû au Pi lui même, je conseille un RP4 c’est sûr) ni aucune charge processeur qui n’est que 900MHz.
Le RPI2 est dédié HA en version Core sur un Raspbian Lite.
Moi, c’est sur un NUC i3 avec VMWare (2 machines virtuelles - une avec jeedom 4 - une avec home assistant) Au moins, c’est « secure » et ça permet de faire des snapshots avec les grosses modifs
?