Zigate : pertes de device Xiaomi

[Deufo]

Petite question connexe, je commence à avoir un peu de recul sur mon installation et j'ai pu remarquer quelques pertes de devices notamment sur des capteurs de portes un peu éloignés de la zigate.
J'ai depuis installé des équipements type ampoules et prise connectée de chez ikea, je ne sais pas dire si le mesh fonctionne, je n'ai pas encore cherché à comprendre ce qui se passe de ce côté là mais ça à l'air mieux.
Tout ça pour dire que je peux voir dans les logs que certains devices communiquent sans changement d'état :
- capteur d'ouverture xiaomi aqara : toutes les 50min
- ampoules ikea : toutes les 5 minutes

Cependant, vu qu'il n'y a pas de changement d'état, l'information de dernier contact n'évolue pas, on ne sait donc pas que le capteur est bien "vivant".
Sur une porte qui ne bouge que très rarement, impossible de faire un test représentatif alors que finalement l'information existe.

[pipiche]

Petite question connexe, je commence à avoir un peu de recul sur mon installation et j'ai pu remarquer quelques pertes de devices notamment sur des capteurs de portes un peu éloignés de la zigate.
J'ai depuis installé des équipements type ampoules et prise connectée de chez ikea, je ne sais pas dire si le mesh fonctionne, je n'ai pas encore cherché à comprendre ce qui se passe de ce côté là mais ça à l'air mieux.
Tout ça pour dire que je peux voir dans les logs que certains devices communiquent sans changement d'état :
- capteur d'ouverture xiaomi aqara : toutes les 50min
- ampoules ikea : toutes les 5 minutes

Cependant, vu qu'il n'y a pas de changement d'état, l'information de dernier contact n'évolue pas, on ne sait donc pas que le capteur est bien "vivant".
Sur une porte qui ne bouge que très rarement, impossible de faire un test représentatif alors que finalement l'information existe.

L'information est disponible dans la base du plugin, Il y a un TimeStamp qui doit être mis-à-jour.
Le problème principal est que chaque update d'un device génère un événement qui peut déclencher un scripts LUA/dzVents, et par conséquent il n'y a pas d'update des devices, si il n'y a pas de changement de données importantes.

Le jour où nous aurons un interface Admin de plugin, on pourra alors avoir ce type d'information.

Par contre tu est le bienvenu pour soumettre des changements , n'hésites pas ...

[Deufo]

Ok, merci pour ton retour.
Il faudrait en réalité 2 champs côté domoticz, un correspondant au dernier moment où il y a eu un échange avec le capteur et un autre pour indiquer un changement d'état pour l'exécution des scripts.

A l'inverse des capteurs, je remarque que le temps est mis à jour sur une ampoule même si elle est non connectée au réseau et que la zigate n'arrive pas à la joindre malgré les différentes tentatives.

[Deufo]

Par hasard, en écrivant un script, je tombe là dessus, ce n'est pas dispo côté plugin ?

Added .silent() option to commands like switchOn().afterSec(4).silent() causing no follow-up events to be triggered. This also works when updating non-switch-like devices, scenes, groups and user variables. If you do not call `silent()``, a follow-up event is always triggered (for devices, scenes, groups and user variables).

Ça pourrait être une option.

[pipiche]

Ok, merci pour ton retour.
Il faudrait en réalité 2 champs côté domoticz, un correspondant au dernier moment où il y a eu un échange avec le capteur et un autre pour indiquer un changement d'état pour l'exécution des scripts.

A l'inverse des capteurs, je remarque que le temps est mis à jour sur une ampoule même si elle est non connectée au réseau et que la zigate n'arrive pas à la joindre malgré les différentes tentatives.

Pour la 1ere remarque, c'est hors de notre contrôle. Il est claire qu'il serait utile de pouvoir mettre à jour la base de donnée sans créer une notification, mais à ce jour cette demande est restée vaine ...

Pour la 2eme remarque, je ne ne comprends. Donc si tu peux mettre un exemple, un screen shot, des logs . Car j'ai du mal à imaginer une mise-à-jour d'un objet quand celui-ci n'est pas présent sur le réseau

[pipiche]

Par hasard, en écrivant un script, je tombe là dessus, ce n'est pas dispo côté plugin ?

Added .silent() option to commands like switchOn().afterSec(4).silent() causing no follow-up events to be triggered. This also works when updating non-switch-like devices, scenes, groups and user variables. If you do not call `silent()``, a follow-up event is always triggered (for devices, scenes, groups and user variables).

Ça pourrait être une option.

Je ne sais pas ce que fait cette option dans les scripts, mais dans le Python Framework il y a un equivalent 'SuppressTriggers' qui a une consequence, c'est que rien n'est mis à jour dans la base de données! Du coup rien est visible !

https://www.domoticz.com/wiki/Developin ... hon_plugin

SuppressTriggers Optional

Default: False Boolean flag that allows device attributes to be updated without notifications, scene or MQTT, event triggers. nValue and sValue are not written to the database and will be overwritten with current database values.

[Deufo]

allows device attributes to be updated without notifications

A voir quels sont les attributs mis à jour, ça pourrait être ça.
Je vais essayer de voir ce que ça fait si je trouve du temps.

[pipiche]

si tu es en pre-4.1 , fait un git pull et regarde si ca fonctionne mieux.

[Deufo]

Je ne suis pas encore en pre-4.1 mais j'ai modifié mon plugin localement pour intégrer ta modif.
Par contre, le commentaire juste au dessus n'est pas rassurant :

# SO far, SuppressTrigger is not enforced due to the fact that Domoticz doesn't behave correctly.
# Issue will be reported to Domoticz as if SuppressTriggers is set to True, then there is no update of the Database at all!
# Devices[Unit].Update(nValue=int(nValue), sValue=str(sValue) , SignalLevel=int(rssi), BatteryLevel=int(BatteryLvl), SuppressTriggers=SuppTrigger_ )

Je laisse tourner le temps d'un refresh.

[pipiche]

Je ne suis pas encore en pre-4.1 mais j'ai modifié mon plugin localement pour intégrer ta modif.
Par contre, le commentaire juste au dessus n'est pas rassurant :

# SO far, SuppressTrigger is not enforced due to the fact that Domoticz doesn't behave correctly.
# Issue will be reported to Domoticz as if SuppressTriggers is set to True, then there is no update of the Database at all!
# Devices[Unit].Update(nValue=int(nValue), sValue=str(sValue) , SignalLevel=int(rssi), BatteryLevel=int(BatteryLvl), SuppressTriggers=SuppTrigger_ )

Je laisse tourner le temps d'un refresh.

Oui, c'est la vie avec Domoticz, pas toujours aisé d'avoir ce que l'on veut ou ce qu'on aimerait.
Bon dans le cas présent, il n'y a pas péril car la seul chose qu'on se contente de mettre à jour c'est le niveau de batterie et le niveau du Signal, qui sont eux également dans la base du plugin.
La version précédente comme tu as du le voir vérifiée qu eces deux derniers paramètres aient également changés. Ce qui n'est pas forcément le cas.
Mais j'y crois pas trop, quand j'avais regardé le code coté Domoticz nValue, sValue, SignalLevel et BatteryLvl sont traités de la meme façon.