Ampoule qui clignote

[Wolfen38]

Salut,

La semaine passée pendant que j'étais en vacances, pas chez moi, une de mes ampoules xiaomi s'est mis à clignoter, enfin passer de on en off en on en continue.

N'étant pas chez moi et avec un accès restreint, j'ai juste renommé mon ampoule pour arrêter ce phénomène.

Samedi je rentre, je renomme mon ampoule comme avant, et plus de clignotement, mais le soir, je me suis rendu compte que c'était un sonoff basic flashé qui avait ce même comportement de clignotement.

Et je ne comprends pas pourquoi car le problème est apparu quand je n'étais pas chez moi, et donc aucune modif n'avait été faites.

Dans les log, ca me dit que c'est mon script inter qui actionne le sonoff, mais je ne vois pas de raison.

UN bout du log :

Code : Tout sélectionner

2024-08-19 08:45:30.334 Status: EventSystem: Script event triggered: /home/pi/domoticz/scripts/lua/script_device_inter.lua
2024-08-19 08:45:30.384 Virtualsensor: Light/Switch (Sonoff-Frank)
2024-08-19 08:45:35.311 Status: EventSystem: Script event triggered: /home/pi/domoticz/scripts/lua/script_device_inter.lua
2024-08-19 08:45:35.342 Virtualsensor: Light/Switch (Sonoff-Frank)
2024-08-19 08:45:40.341 Status: EventSystem: Script event triggered: /home/pi/domoticz/scripts/lua/script_device_inter.lua
2024-08-19 08:45:40.378 Virtualsensor: Light/Switch (Sonoff-Frank)
2024-08-19 08:45:45.357 Status: EventSystem: Script event triggered: /home/pi/domoticz/scripts/lua/script_device_inter.lua
2024-08-19 08:45:45.377 Virtualsensor: Light/Switch (Sonoff-Frank)
2024-08-19 08:45:50.316 Status: EventSystem: Script event triggered: /home/pi/domoticz/scripts/lua/script_device_inter.lua
2024-08-19 08:45:50.355 Virtualsensor: Light/Switch (Sonoff-Frank)

Et mon script lua sur ce sonoff (enfin la partie qui concerne le sonoff) :

Code : Tout sélectionner

elseif devicechanged['Interrupteur Frank'] == '1 Click' then
if otherdevices['Sonoff-Frank'] == 'Off' then
    commandArray['Sonoff-Frank']='On'
	else
	commandArray['Sonoff-Frank']='Off'
	end

Mon inter est un xiaomi connecté via zigate, et coté dz je tourne sur un rpi3b+ et dz est en version 2024-7

[gaston]

Elo,

Moi aussi, ça arrive de temps en temps, sur un Sonoff R2 flashé Espeasy sur un des 6 volets roulants (toujours le même, jamais les autres). Exemple qui date d'hier soir, un de mes volets ne se ferme pas, il n'est plus visible sur mon réseau. Je décide de couper l'alimentation des Sonoff de la zone concernée (mon Sonoff clignotant n'en faisait pas parti). A la remise du courant, mon volet retrouve bien son réseau mais je constate que le volet clignotant fait des siennes. Un appui sur le bouton du sonoff et il s’arrête.

Autre problème, mon éclairage, certes un peu particulier et fait maison fait la même chose...
Pour expliquer, l’éclairage est composé d'une platine 8 relais, un ESP 8266 et un multiplexeur I/O, le tout relié aux interrupteurs (poussoirs) de la maison alimentés en 5V. Si je fais une action rapide (appui à la limite ou on entend que ça grésille)sur le seul interrupteur qui N'EST PAS sur la platine (éclairage des WC en directe sur le 230v)à coup sur, les différentes lumières de la maison s'allument et s'éteignent de façon complètement aléatoire. Pour rétablir le tout, je dois faire un reset de l'ESP.

J'en conclue donc qu'une perturbation électrique vienne embêter les ESP (le pire, pas tous).

Ça me rassure, je me sens moins seul, je pensais avoir un poltergeist à la maison

[Wolfen38]

Ça me rassure, je me sens moins seul, je pensais avoir un poltergeist à la maison

Oui c'est tout a fait ça.

Et niveau économie d'énergie, c'est pas trop top....


Envoyé de mon Mi 9T Pro en utilisant Tapatalk

[lost]

La semaine passée pendant que j'étais en vacances, pas chez moi, une de mes ampoules xiaomi s'est mis à clignoter...

Si le script était du même genre que le sonoff qui a eu ensuite les mêmes problèmes que cette ampoule zigbee, je dirais qu'il est probable qu'il y ait des problèmes de communication: Probable que le retour d'état ne vienne pas et domoticz pense que la commande a échoué et re-bascule le switch dans l'état opposé... ce qui trig le script qui voit "off" et renvoie un "on" que domoticz remets à "off" faute d’acquittement etc etc...

Ca ressemblerait à un bilan radio TX/RX pas équilibré: Coordinateur -> Objet, l'ordre est bien reçu vu que l'ampoule réagi. Mais l'acquittement dans le sens inverse n'est pas reçu. Le coordinateur est une "grande gueule" mais hélas "sourdingue", en résumé.

C'est un problème que j'ai parfois sur une prise commandée zigbee, la plus éloignée, que j'entends parfois bagotter quand le trig d'un PIR dans la pièce devrait juste la passer, si état actuel "off", à "on".

J'avais jusque là surtout du zwave (intégration open-zwave dépréciée mais nativement intégrée dans Domoticz) et les retry/timeout semblaient mieux gérés en accord avec la façon dont Domoticz remets dans le dernier état connu ce qui n'a pas acquitté, pour les protocoles qui acquittent. Ce qu'il est toujours plus facile d'assurer en intégration native vs plugin sans doute.

[Wolfen38]

En effet l'ampoule et le sonoff sont contrôlés par un même script lua.

Et le seul autre point commun entre les 2, c'est qu'ils sont situés cote a cote dans la même pièce.

Donc on peut en effet imaginer un problème de com sur le retour d'état.

[lost]

C'est quoi l'intégration utilisée? Z4D? Auquel cas cela vaudrait peut-être le coup de voir s'il n'y a rien de réglable côté timeout/retry via Pipiche.

Quand je dis que je n'ai pas eu ce type de pb en zwave, c'est pas totalement exact: 1 seul truc (un smart-meter Qubino installé en tête d'installation électrique mais intégrant également une commande relais directe et/ou sur délestage autonome programmable) m'a posé ce type de problème.

Dans les 2s après un passage à on du relais, Domoticz signalait un timeout (intégration native) et le remettait off. En réalité, c'est le module qui était un peu lent à prendre en compte puis acquitter une première commande mais manuellement, remettre à on dans la seconde du repassage à off non souhaité donnait ensuite un état acquitté/stable à on.

Au final j'avais fait un petit script Lua utilisant l'état du switch et le last_update, reproduisant la manip manuelle et ses délais, afin de le faire "tomber en marche" automatiquement. Un ticket au fabricant n'ayant rien donné pour modifier le firmware du bidule.

Mais je ne pense pas que tu tombes dans un cas similaire (pb de lenteur d'un truc bien chargé en fonctionnalité en fait et peut-être à la limite des possibilités d'un chip zwave+ basé sur un 8051), vu que 2 trucs touchés et co-localisés.

Mais bon, facile de voir en bidouillant manuellement s'il y a moyen de ruser...