Détecter coupure et arrêt de l'alimentation électrique via Lixee.Zlinky

[Henri]

@MaGoo

lorsqu’il y a une coupure de courant, l’onduleur déclenche un scenario (via NUT et une API sur Jeedom).

Bonjour,
Il y a des onduleurs qui peuvent envoyer une commande API ?
Ils sont donc sur le reseau ethernet !
Une marque / modèle à soumettre ?

[MaGoo]

N’importe quel onduleur avec un port USB, raccordé à un PI Zero ou PI3 et le logiciel NUT fourni de base dans la distribution.
Une ligne dans un fichier de configuration et tu déclenche un scenario à la coupure de courant et au retour.

[JC38]

Attention aux confusions sur les lastcommunication, comme je l’ai écrit au début du post, Jeedom nomme de manière identique (Dernière communication) 2 champs d’horodatages différents.
https://community.jeedom.com/t/info-dernieres-communication/70981/13

D’où le plugin https://market.jeedom.com/index.php?v=d&p=market_display&id=4207

[Phpvarious]

Sa change rien au comportement, a partir du moment ou une commande est mise à jour le lastCommunication et le timeout de l’équipement sont normalement MàJ aussi.

le champs disponible dans le « reseaux zigbee » est une autre méthode qui consiste a questionner directement le controleur sur la dernière fois ou il a vu l’équipement.

cette info semble être disponible exclusivement dans le log (error) et avec un CRON15 ou alors en visu sur la page « reseaux zigbee »

[JC38]

Bonsoir,
Pour info, ce soir le scenario a remonté cela :

Sans qu’il y ait de coupure.
Dans le log du contrôleur, filtré sur le Zlinky, j’ai ça :

	Ligne 1882: [2022-06-28 21:45:03][INFO] : [00:15:8d:00:05:d2:85:70][zdevices.serialize] Serialize device with attributes : 1
	Ligne 1979: [2022-06-28 21:46:37][INFO] : [00:15:8d:00:05:d2:85:70][listener.cluster_command] Cluster: <zigpy.zcl.clusters.general.Ota object at 0x7f6c6e0b7438> ClusterId: 0x0019 tsn: 151 args: (1, query_next_image(field_control=<FieldControl.0: 0>, manufacturer_code=4151, image_type=1, current_file_version=5))
	Ligne 1980: [2022-06-28 21:46:37][INFO] : [00:15:8d:00:05:d2:85:70][listener.cluster_command] Use specific decode funtion of cluster id 25
	Ligne 1981: [2022-06-28 21:46:37][INFO] : [00:15:8d:00:05:d2:85:70][chanels.general.Ota.cluster_command] Received command query_next_image
	Ligne 2156: [2022-06-28 21:51:14][INFO] : [00:15:8d:00:05:d2:85:70][listener.cluster_command] Cluster: <zigpy.zcl.clusters.general.Ota object at 0x7f6c6e0b7438> ClusterId: 0x0019 tsn: 12 args: (1, query_next_image(field_control=<FieldControl.0: 0>, manufacturer_code=4151, image_type=1, current_file_version=5))
	Ligne 2157: [2022-06-28 21:51:14][INFO] : [00:15:8d:00:05:d2:85:70][listener.cluster_command] Use specific decode funtion of cluster id 25
	Ligne 2158: [2022-06-28 21:51:14][INFO] : [00:15:8d:00:05:d2:85:70][chanels.general.Ota.cluster_command] Received command query_next_image
	Ligne 2406: [2022-06-28 21:55:29][INFO] : [00:15:8d:00:05:d2:85:70][listener.cluster_command] Cluster: <zigpy.zcl.clusters.general.Ota object at 0x7f6c6e0b7438> ClusterId: 0x0019 tsn: 107 args: (1, query_next_image(field_control=<FieldControl.0: 0>, manufacturer_code=4151, image_type=1, current_file_version=5))
	Ligne 2407: [2022-06-28 21:55:29][INFO] : [00:15:8d:00:05:d2:85:70][listener.cluster_command] Use specific decode funtion of cluster id 25

Le Zlinky a donc arrêté de causer pendant un peu plus de 4 min (lignes 2158 à 2406).
Dans le centre de messages, j’ai eu une alerte du core qui a disparu quand le timeout a cessé.
Le timeout du Zlinky est réglé à 2 min, et le scenario tourne toutes les 5 min.
Voici le log du scenario sur la période

[2022-06-27 21:50:01][SCENARIO] Start : Scenario execute automatiquement sur programmation.
[2022-06-27 21:50:01][SCENARIO] Exécution du sous-élément de type [action] : code
[2022-06-27 21:50:01][SCENARIO] Exécution d'un bloc code
[2022-06-27 21:50:01][SCENARIO] ┌─────────────────── [ DEBUT BLOC CODE ] ───────────────────
[2022-06-27 21:50:01][SCENARIO] | Verification de Timeout pour l'équipement : [Maison][LiXee.ZLinky] (id = 1509)
[2022-06-27 21:50:01][SCENARIO] | L'équipement n'est pas en timeout (0) mais il a déja été notifié lors d'un précédent lancement du scénario.
[2022-06-27 21:50:01][SCENARIO] └─────────────────── [ FIN BLOC CODE ]  ───────────────────
[2022-06-27 21:50:01][SCENARIO] Exécution du sous-élément de type [condition] : if tag(timeout,-1)=0
[2022-06-27 21:50:01][SCENARIO] Evaluation de la condition : [-1=0] = Faux
[2022-06-27 21:50:01][SCENARIO] Exécution du sous-élément de type [action] : else
[2022-06-27 21:50:01][SCENARIO] Exécution du sous-élément de type [condition] : if tag(timeout,-1)=1
[2022-06-27 21:50:01][SCENARIO] Evaluation de la condition : [-1=1] = Faux
[2022-06-27 21:50:01][SCENARIO] Exécution du sous-élément de type [action] : else
[2022-06-27 21:50:01][SCENARIO] Fin correcte du scénario
------------------------------------
[2022-06-27 21:55:01][SCENARIO] Start : Scenario execute automatiquement sur programmation.
[2022-06-27 21:55:01][SCENARIO] Exécution du sous-élément de type [action] : code
[2022-06-27 21:55:01][SCENARIO] Exécution d'un bloc code
[2022-06-27 21:55:01][SCENARIO] ┌─────────────────── [ DEBUT BLOC CODE ] ───────────────────
[2022-06-27 21:55:01][SCENARIO] | Verification de Timeout pour l'équipement : [Maison][LiXee.ZLinky] (id = 1509)
[2022-06-27 21:55:01][SCENARIO] | L'équipement n'est pas en timeout (0) mais il a déja été notifié lors d'un précédent lancement du scénario.
[2022-06-27 21:55:01][SCENARIO] └─────────────────── [ FIN BLOC CODE ]  ───────────────────
[2022-06-27 21:55:01][SCENARIO] Exécution du sous-élément de type [condition] : if tag(timeout,-1)=0
[2022-06-27 21:55:01][SCENARIO] Evaluation de la condition : [-1=0] = Faux
[2022-06-27 21:55:01][SCENARIO] Exécution du sous-élément de type [action] : else
[2022-06-27 21:55:01][SCENARIO] Exécution du sous-élément de type [condition] : if tag(timeout,-1)=1
[2022-06-27 21:55:01][SCENARIO] Evaluation de la condition : [-1=1] = Faux
[2022-06-27 21:55:01][SCENARIO] Exécution du sous-élément de type [action] : else
[2022-06-27 21:55:01][SCENARIO] Fin correcte du scénario
------------------------------------
[2022-06-27 22:00:01][SCENARIO] Start : Scenario execute automatiquement sur programmation.
[2022-06-27 22:00:01][SCENARIO] Exécution du sous-élément de type [action] : code
[2022-06-27 22:00:01][SCENARIO] Exécution d'un bloc code
[2022-06-27 22:00:01][SCENARIO] ┌─────────────────── [ DEBUT BLOC CODE ] ───────────────────
[2022-06-27 22:00:01][SCENARIO] | Verification de Timeout pour l'équipement : [Maison][LiXee.ZLinky] (id = 1509)
[2022-06-27 22:00:01][SCENARIO] | L'équipement n'est pas en timeout (0) mais il a déja été notifié lors d'un précédent lancement du scénario.
[2022-06-27 22:00:01][SCENARIO] └─────────────────── [ FIN BLOC CODE ]  ───────────────────
[2022-06-27 22:00:01][SCENARIO] Exécution du sous-élément de type [condition] : if tag(timeout,-1)=0
[2022-06-27 22:00:01][SCENARIO] Evaluation de la condition : [-1=0] = Faux
[2022-06-27 22:00:01][SCENARIO] Exécution du sous-élément de type [action] : else
[2022-06-27 22:00:01][SCENARIO] Exécution du sous-élément de type [condition] : if tag(timeout,-1)=1
[2022-06-27 22:00:01][SCENARIO] Evaluation de la condition : [-1=1] = Faux
[2022-06-27 22:00:01][SCENARIO] Exécution du sous-élément de type [action] : else
[2022-06-27 22:00:01][SCENARIO] Fin correcte du scénario
------------------------------------
[2022-06-27 22:05:01][SCENARIO] Start : Scenario execute automatiquement sur programmation.
[2022-06-27 22:05:01][SCENARIO] Exécution du sous-élément de type [action] : code
[2022-06-27 22:05:01][SCENARIO] Exécution d'un bloc code
[2022-06-27 22:05:01][SCENARIO] ┌─────────────────── [ DEBUT BLOC CODE ] ───────────────────
[2022-06-27 22:05:01][SCENARIO] | Verification de Timeout pour l'équipement : [Maison][LiXee.ZLinky] (id = 1509)
[2022-06-27 22:05:01][SCENARIO] | L'équipement n'est pas en timeout (0) mais il a déja été notifié lors d'un précédent lancement du scénario.
[2022-06-27 22:05:01][SCENARIO] └─────────────────── [ FIN BLOC CODE ]  ───────────────────
[2022-06-27 22:05:01][SCENARIO] Exécution du sous-élément de type [condition] : if tag(timeout,-1)=0
[2022-06-27 22:05:01][SCENARIO] Evaluation de la condition : [-1=0] = Faux
[2022-06-27 22:05:01][SCENARIO] Exécution du sous-élément de type [action] : else
[2022-06-27 22:05:01][SCENARIO] Exécution du sous-élément de type [condition] : if tag(timeout,-1)=1
[2022-06-27 22:05:01][SCENARIO] Evaluation de la condition : [-1=1] = Faux
[2022-06-27 22:05:01][SCENARIO] Exécution du sous-élément de type [action] : else
[2022-06-27 22:05:01][SCENARIO] Fin correcte du scénario

Et le scenario

Faut donc trouver aussi le bon réglage du timeout pour pouvoir conclure si perte EDF ou pas de discussion entre Zlinky et le contrôleur.

[Phpvarious]

Hello.

Détecter coupure et arrêt de l'alimentation électrique via Lixee.Zlinky

Merci @Bad pour ce retour , effectivement un simple virtuel pourrait suffire. . @JC38 Faux positif ! j’ai un doute car le scénario se charge juste de récupérer l’info existante getStatus('timeout') et de faire une comparaison avec la variable jeedom, si tu as eu un message du scénario c’est que celle-ci a bien changé d’état. Attention a bien adapter la valeur « Alertes Communications » dans la configuration de ton équipement, ne pas mettre une valeur trop basse. Se qui semble étonnant…

comme j’ai dis, si « alerte timeout » est trop bas, tu aura un équipement en timeout mais cela ne veut pas dire que tu as perdu le secteur !

Edit : Je pense que la solution de @Bad est plus viable, car elle s’appuie sur 2 protocoles différent et plusieurs équipements.
On est jamais a l’abris d’un protocole qui tombe (demon hs, équipement out …) et dans ce cas le last communication ne sera pas mis a jour.

[JC38]

Oui, il faut trouver le bon réglage pour le timeout pour éviter des fausses alertes. Je vais attendre encore et je l’augmenterai progressivement. Je veux voir à quelle fréquence ces « fausses alertes » arrivent avec les valeurs en cours.
Je vais regarder la solution de Bad, en //, j’avais travaillé sur une solution de surveillance de l’onduleur. J’ai galéré mais je suis arrivé à mettre NUT sur mon serveur Windows et à configurer la connexion avec le plugin NUT_Free. Maintenant, faut que je trouve comme ce plugin gère l’évènement de coupure du secteur sur l’onduleur pour pouvoir le monitorer et l’exploiter dans un scenario.

[JC38]

J’ai fait un 1er test de on/off de l’alimentation de mon onduleur devant mon serveur Windows. L’info est remontée relativement rapidement dans Jeedom.
J’ai trouvé un autre onduleur avec une prise USB, je vais le mettre devant mon seveur Jeedom cette fois et créer un équipement de plus dans Nut_Free.
Si tout ok, un scenario qui teste si les 2 onduleurs sont ou ne sont plus sur secteur devrait permettre de trouver l’état de l’alim générale sans trop de risque.
Merci à tous et à Phpvarious dont j’ai adopté le scenario