Simuler des changements d'états de devices

[fjum]

Bonjour

Le sujet est confus sans explication associée.

Voilà mon sujet :

Dans un script dzvents, j'ai une liste de devices de tous types servant de triggers.

Sur réception d'un autre trigger, j'aimerais "retriggeriser" les devices ci-dessus.

Exemple :
J'ai mes premiers triggers : device 1, device 2, ... Si changement d'état de l'un ou l'autre de ces devices, j'envoie des données par MQTT.

Je voudrais mettre en place un switch qui, s'il est activé, permet de retriggeriser tous mes devices (device 1, device 2, ...) comme si leurs états avaient changés (sauf qu'en réalité leurs états n'ont pas changé), afin de renvoyer toutes les données via MQTT.

Mon problème 1 : je ne sais pas comment balayer tous les triggers de ma liste devices = {device 1, device 2, ...}
Mon problème 2 : je ne sais pas comment simuler des changements d'états de ces devices
Afin de faire : for "tous mes devices de ma liste de devices" -> simuler un changement d'état qui n'en est pas un pour chacun de ces devices.

Je suis preneur de toute idée.

Merci d'avance

[fjum]

Bonjour

Je relance le groupe sur mon sujet.

Je vais le reformuler autrement.

J'ai développé une passerelle bi-directionnelle entre Domoticz et HA, via MQTT.

Côté DM, j'ai un script dont les triggers sont les devices dont je souhaite communiquer l'état à HA.

Dès que l'un de ces devices change d'état, son nouvel état est envoyé vers HA. Cet envoi se fait en deux temps : autodiscover puis payload de mis à jour d'état. Si le device n'existe pas dans HA, il y est ainsi créé. Mon device DM devient donc une entité dans HA. Pour le moment, ma passerelle gère les devices de types ou sous-types Temp, Humidity, General/text, P1 smart meter / Energy, Light/Switch / Switch, Light/Switch / Selector Switch, Color Switch / WW, Temp+Humidity,

Dans le sens inverse, j'ai un dispositif similaire, qui prend la forme d'automatisations sous HA, envoyant des mises à jour d'état d'entité vers DM.

Dans mon système, DM est la tête pensante. Et HA n'est là que pour afficher (en projet, tablette en mode kiosk) et pour intégrer des matériels dont l'intégration n'existe pas dans DM (exemple chaudière frisquet).

Sur les raisons de ce choix et pour faire court : je n'ai pas trouvé dans HA de possibilité de codage aussi poussée que dans DM (dzvents) et je n'ai pas trouvé dans DM de possibilité d'affichage aussi intéressante que dans HA.

Mon problème :

Dans HA, toutes modifications de scripts ou d'automatisations doivent passer par un redémarrage du logiciel pour que leurs prises en compte se fassent. Lorsque HA redémarre, les états de mes entités issues de DM sont inconnues. Je dois donc ré-interroger DM pour qu'il les ré-envoie à HA sans que pour autant il n'y ait eu de changement d'état.

Sous DM, à réception du flag qui m'indique que HA a redémarré, j'aimerais donc simuler un changement d'état de mes devices afin de pouvoir simplement réutiliser le même développement que celui qui permet d'envoyer les vrais changements d'états à HA.

Si quelqu'un a une idée, je suis preneur.

Merci d'avance

[Keros]

Tu ne peux pas boucler sur tous les objets que tu souhaites et faire un déclenchement de l'état dans lequel ils se trouvent ?

Regarde éventuellement la fonction .silent en DzVents.

[fjum]

Prenons l'exemple d'un switch. Si je te suis bien, je reçois mon flag m'indiquant que HA s'est relancé. Je regarde alors l'état de mon device, et je constate qu'il est à "On". Si je fais un .switchOn().silent(), je ne vais pas récupérer l'évènement dans mon on = {device} puisque le switchOn sera fait en silence justement. Et si je fais un .switchOn() tout court, vu que le switch est déjà sur "On", je ne suis pas sûr que DM interprète ça comme un changement d'état et que je puisse le récupérer dans mon on = {device} puisqu'il n'y aura pas de changement d'état. Mais pour en être sûr, je vais essayer quand même.

[Flying Domotic]

Et avec le flag "retain" sur les messages MQTT envoyés à HA, ça le ferait pas ?

[fjum]

Bonjour

J'ai tenté avec le flag retain dans les messages envoyés par DZ, mais HA ne semble pas les recevoir de mosquitto au redémarrage.

Côté HA, je fais 2 choses : avec une automatisation, j'envoie un flag "redémarrage HA" en MQTT que je récupère dans DZ ; Et j'ai paramétré HA pour qu'il envoie un message MQTT de naissance (topic "homeassistant/status", payload "online") que je capte également dans DZ.

Côté DZ, j'ai fait un test : quand le flag "redémarrage HA" est à "On" ou quand le message de naissance de HA est reçu, je fais un updatequiet d'un device en lui mettant comme arguments le nvalue et le svalue du device. Donc, artificiellement, ça fait comme si le device avait changé d'état, mais en conservant le même état ... Et ça marche, je reçois bien l'Event de mise à jour du device et je traite l'envoie de son état à HA via MQTT.

Mais lorsque HA redémarre, les devices précédemment créés sont tous placés d'office en "unavailable" (cf doc HA). Pour devenir "available", ils doivent recevoir un nouveau message MQTT discovery, même s'ils sont déjà créés. Autrement dit, côté DZ, je dois envoyer 2 messages (un pour les remettre "available", un pour renvoyer les états).

Si j'envoie ces 2 messages, ça fonctionne bien. Et cette partie là du projet est réglée.

Mais la deuxième partie du projet est la suivante : je veux renvoyer les "available" et les états de tous les devices que DZ partage avec HA.

Pour cela, je boucle sur une liste de devices en envoyant les 2 messages précédemment cités.

Mais j'aimerais bien ne pas avoir à mettre la liste des devices à 2 endroits : dans mon on { devices = }} et dans un tableau à part (le devices = {} pour déclencher les envois de changement d'états individuels et le tableau pour réaliser avec une boucle pour l'opération globale "available"+états). J'aurais aimé coller ma liste à un seul endroit. Mais apparemment, on ne peut pas mettre de tableau dans devices={}. J'ai bien tenté de définir une variable en local "tabdev" en y définissant les valeurs {device1, device2, ...} puis cette variable dans ma définition d'évènements on {devices={tabdev}} :

Code : Tout sélectionner

local tabdev =       {
                                'Température Rez de Chaussée',
		                'Température étage',
		                'Température SdB',
		                'Zigbee - TempHum mobile',
		                'Humidité Rez de Chaussée',
		                'Humidité étage',
		                'Humidité SdB',
		                'Zigbee - Lumière cuisine',
		                'Température extérieure',
		                'Compteurs Linky - Haubourdin',
		                'Zigbee - Prise cuisine',
		                'Zigbee - Prise salon',
		                'Zigbee - Petite lampe',
		                'Zigbee - Prise sam',
		                'Saison',
		                'Eclairage couloir 1er',
		                'Eclairage couloir rdc',
		                'Eclairage extérieur',
		                'Eclairage buanderie',
		                'nodeID_8_switch_1'
		                }

return {
	on = {
		devices =       { tabdev }
	   },

Mais ça ne fonctionne pas ... ça aurait été trop beau.

Donc je suis obligé de retaper la même liste dans devices = {}. En soi, c'est pas grave, mais ça oblige à maintenir la liste des devices à 2 endroits et je trouve que c'est pas propre.

Des idées ?

[boum]

narmol, essaie plutôt :

Code : Tout sélectionner

return {
	on = {
		devices = tabdev, -- pas { tabdev }
	   },

ou alors devices = { 'autre_dispo', table.unpack(tabdev)} si tu veux des triggers supplémentaires

[fjum]

ça m'en bouche un coin ! je vais essayer ça très rapidement. Si ça fonctionne ça m'ouvre même d'autres perspectives. Un grand merci

[fjum]

Je confirme que ça fonctionne (devices = tabdev).

Encore merci !

Donc :
- ma liste de devices n'est qu'à un endroit donc parfait pour maintenir et ça fait propre
- Si HA redémarre, je parcours ma liste de devices avec un while tabdev avec i+1 tant que tabdev est différent de nil
- dans ma boucle, je fais 2 domoticz.devices(tabdev).updateQuiet(domoticz.devices(tabdev).nValue, idem pour sValue)
- ça déclenche artificiellement le trigger de tabdev, qui ravive le sensor dans HA puis le met à jour

Je suis un homme heureux