Comportement Ampoule IKEA

[Deufo]

Suite à des petits ratés sur mes scripts et à notre discussion d'hier sur la mise à jour des capteurs, j'ai regardé de plus près les logs de mes ampoules et c'est catastrophique !
L'ampoule envoie toutes les 5 minutes son état en 2 envois. Un premier contenant l'état LvlControl puis un second de type Switch qui suit dans la minute.
En Off, le sVal contient Off dans les 2 cas, tout va bien.
En On, le premier envoi contient l’intensité en % (et Off pour 0, On pour 100%), le second seulement On ou Off.

Si j'utilise mon ampoule à 50%, sur le LvlControl tout va bien, puis je reçois le Switch qui change le sVal à On (avec trigger et log) puis 5 minutes plus tard, le LvlControl indique 50%, j'ai une demande de changement d'état du sVal à 50, et ainsi de suite.

Vous imaginez donc mes logs de la database qui se remplissent de 2 lignes toutes les 5 minutes par ampoule allumée.
J'ai essayé d'être clair mais pas simple, faudrait un chronogramme

[pipiche]

Suite à des petits ratés sur mes scripts et à notre discussion d'hier sur la mise à jour des capteurs, j'ai regardé de plus près les logs de mes ampoules et c'est catastrophique !
L'ampoule envoie toutes les 5 minutes son état en 2 envois. Un premier contenant l'état LvlControl puis un second de type Switch qui suit dans la minute.
En Off, le sVal contient Off dans les 2 cas, tout va bien.
En On, le premier envoi contient l’intensité en % (et Off pour 0, On pour 100%), le second seulement On ou Off.

Si j'utilise mon ampoule à 50%, sur le LvlControl tout va bien, puis je reçois le Switch qui change le sVal à On (avec trigger et log) puis 5 minutes plus tard, le LvlControl indique 50%, j'ai une demande de changement d'état du sVal à 50, et ainsi de suite.

Vous imaginez donc mes logs de la database qui se remplissent de 2 lignes toutes les 5 minutes par ampoule allumée.
J'ai essayé d'être clair mais pas simple, faudrait un chronogramme

J'ai effectivement du mal à suivre. Est-ce avec le plugin Domoticz-Zigate ? Si oui quelle version ?
Quel est le rapport entre log et database ?

[Deufo]

Je suis en 4.0.7, pas encore pris le temps de changer.

Voici un exemple de ce qui se produit :

2019-03-06 15:53:05.864 [75702430] (zigate) MajDomoDevice - Device ID : x- Device EP : 01 - Type : 0008 - Value : f2 - Hue :
2019-03-06 15:53:05.864 [75702430] (zigate) MajDomoDevice - Type = LvlControl
2019-03-06 15:53:05.864 [75702430] (zigate) MajDomoDevice - NWKID = 1a45 IEEE = x Unit = 23
2019-03-06 15:53:05.865 [75702430] (zigate) MajDomoDevice - {'0005': {}, '1000': {}, '0b05': {}, '0008': {}, '0006': '01', 'Type': 'LvlControl', '0019': {}, '0003': {}, '0020': {}, '0004': {}, '0000': {}, 'ClusterType': {'23': 'LvlControl'}}
2019-03-06 15:53:05.865 [75702430] (zigate) MajDomoDevice - We have 1 EPs with ClusterType
2019-03-06 15:53:05.865 [75702430] (zigate) MajDomoDevice - NWKID: 1a45 SwitchType: 7, DeviceType: LvlControl, ClusterType: LvlControl, old_nVal: 1 , old_sVal: On
2019-03-06 15:53:05.865 [75702430] (zigate) UpdateDevice_v2 for : 21 Battery Level = {} Signal Level = 78
2019-03-06 15:53:05.865 [75702430] (zigate) UpdateDevice_v2 for : 21 RSSI = 4
2019-03-06 15:53:05.866 [75702430] (zigate) Update v2 Values 2:'95:' (Ampoule SaM2)
2019-03-06 15:53:05.866 [75702430] (Ampoule SaM2) Updating device from 1:'On' to have values 2:'95'.

et dans la foulée :

2019-03-06 15:54:04.799 [75702430] (zigate) MajDomoDevice - Device ID : x- Device EP : 01 - Type : 0006 - Value : 01 - Hue :
2019-03-06 15:54:04.800 [75702430] (zigate) MajDomoDevice - Type = Switch
2019-03-06 15:54:04.800 [75702430] (zigate) MajDomoDevice - NWKID = 1a45 IEEE = x Unit = 23
2019-03-06 15:54:04.800 [75702430] (zigate) MajDomoDevice - {'0005': {}, '1000': {}, '0b05': {}, '0008': {}, '0006': '01', 'Type': 'LvlControl', '0019': {}, '0003': {}, '0020': {}, '0004': {}, '0000': {}, 'ClusterType': {'23': 'LvlControl'}}
2019-03-06 15:54:04.800 [75702430] (zigate) MajDomoDevice - We have 1 EPs with ClusterType
2019-03-06 15:54:04.800 [75702430] (zigate) MajDomoDevice - NWKID: 1a45 SwitchType: 7, DeviceType: LvlControl, ClusterType: Switch, old_nVal: 2 , old_sVal: 95
2019-03-06 15:54:04.800 [75702430] (zigate) UpdateDevice_v2 for : 21 Battery Level = {} Signal Level = 75
2019-03-06 15:54:04.800 [75702430] (zigate) UpdateDevice_v2 for : 21 RSSI = 4
2019-03-06 15:54:04.800 [75702430] (zigate) Update v2 Values 1:'On:' (Ampoule SaM2)
2019-03-06 15:54:04.800 [75702430] (Ampoule SaM2) Updating device from 2:'95' to have values 1:'On'.

Cela a pour impact de gonfler l'historique du switch (qui est aussi un log mais tu l'appelles comment ?), plus de 1000 entrées en quelques jours :

2019-03-06 15:54:04 On
2019-03-06 15:53:05 Set Level: 95 %

Conservant par défaut 30j, ça en fait des lignes.


Concernant le pourquoi, c'est lié à la façon dont fonctionne cette ampoule qui ayant plusieurs attributs, envoie sur plusieurs clusters, un premier sur l'intensité , un second sur l'état (On/Off). Il doit y avoir aussi pour les couleurs ou chaleurs mais je n'en possède pas.

De ce que je comprends de la fonction MajDomoDevice, on arrive dans ce bout de code ligne 733 du ClusterType == "Switch":

Code : Tout sélectionner

               elif DeviceType == "LvlControl" or DeviceType == "ColorControl":
                    if Devices[x].SwitchType == 16:
                        if value == "00":
                            UpdateDevice_v2(Devices, x, 0, '0', BatteryLevel, SignalLevel)
                        else:
                            # We are in the case of a Shutter/Blind inverse. If we receieve a Read Attribute telling it is On, great
                            # We only update if the shutter was off before, otherwise we will keep its Level.
                            if Devices[x].nValue == 0 and Devices[x].sValue == 'Off':
                                UpdateDevice_v2(Devices, x, 1, '100', BatteryLevel, SignalLevel)
                    [b]else[/b]:
                        if value == "00":
                            UpdateDevice_v2(Devices, x, 0, 'Off', BatteryLevel, SignalLevel)
                        else:
                            UpdateDevice_v2(Devices, x, 1, 'On', BatteryLevel, SignalLevel)

Le SwitchType du device est 7 (Dimmer), je suis donc dans le else qui demande uniquement 'On' ou 'Off'.
La fonction UpdateDevice_v2 voyant un sVal différent, le device est mis à jour.

Seul les volets roulants/stores (16) ont le droit à un test spécifique, je vais essayer de coder une correction dans cette partie.
J'espère que c'est plus clair cette fois ci et que vous pourrez confirmer mon analyse.
Je ne sais pas comment fonctionne les autres ampoules comme les Hue à ce niveau là et si c'est spécifique à Ikea.

[Deufo]

Je viens de voir qu'en pre-4.1 le code a changé :

Code : Tout sélectionner

                elif DeviceType == "LvlControl" or DeviceType in ( 'ColorControlRGB', 'ColorControlWW', 'ColorControlRGBWW', 'ColorControlFull', 'ColorControl'):
                    if Devices[x].SwitchType == 16:
                        if value == "00":
                            UpdateDevice_v2(Devices, x, 0, '0', BatteryLevel, SignalLevel)
                        else:
                            # We are in the case of a Shutter/Blind inverse. If we receieve a Read Attribute telling it is On, great
                            # We only update if the shutter was off before, otherwise we will keep its Level.
                            if Devices[x].nValue == 0 and Devices[x].sValue == 'Off':
                                UpdateDevice_v2(Devices, x, 1, '100', BatteryLevel, SignalLevel)
                    else:
                        if value == "00":
                            UpdateDevice_v2(Devices, x, 0, 'Off', BatteryLevel, SignalLevel)
                        else:
                            if Devices[x].sValue == "Off":
                                # We do update only if this is a On/off
                                UpdateDevice_v2(Devices, x, 1, 'On', BatteryLevel, SignalLevel)

Le dernier else me parait bizarre, allez, je passe en pre-4.1 pour tester !

[pipiche]

Attention au passage en pre-4.1 , il y a une petit migration (déplacement de fichier à faire).

Maintenant je comprends mieux ton problème. Effectivement c'est un peu galère entre les retour cluster 0x0006 et 0x0008

Pas mal d'évolution en pre-4.1

- plus de readattribute régulier qui alourdissent la charge sur la zigate et viennent en surcharge des configurereporting. Donc du coup tu devrais déjà voir une réduction des messages

- N’hésites pas à suggérer des modifs , c'est comme-ça que le plugin évolua .

[Deufo]

C'est effectivement mieux au niveau des appels !

Je remarque cependant encore 2 petites choses :
- la calcul du sVal a changé, l'arrondi a été enlevé, l'impact chez moi, je demande 50% via une scène, l'état devient 1:'50', le plugin relis 0x7f et ça se transforme en 2:'49'
- je ne sais pas pourquoi domoticz applique 1:'50' sur ma scene, cela a pour effet d'avoir une mise à jour pour passer en 2:'50'

[Deufo]

Autre bizarrerie, quand on passe dans les lignes à partir de 1323 avec le SuppressTriggers=True, j'ai ceci qui se produit :

2019-03-07 11:57:32.564 [757d3430] (Ampoule SaM2) Updating device from 2:'49' to have values 0:'49'.

Ce sujet SuppressTriggers semble poser problème, il faudrait probablement revenir à l'ancien code.

[pipiche]

Je t’ai envoyé un MP

Je problème est la transformation d’un % en valeur et ensuite valeur en %

[pipiche]

Le suppresstriggers edt correct et ne fait pas de mise à jour de la base.
Je bosse actuellement pour le remplacer par quelque chose de plus efficace (branche beta)

[pipiche]

C'est effectivement mieux au niveau des appels !

Je remarque cependant encore 2 petites choses :
- la calcul du sVal a changé, l'arrondi a été enlevé, l'impact chez moi, je demande 50% via une scène, l'état devient 1:'50', le plugin relis 0x7f et ça se transforme en 2:'49'
- je ne sais pas pourquoi domoticz applique 1:'50' sur ma scene, cela a pour effet d'avoir une mise à jour pour passer en 2:'50'

Pour etre plus précise:

Via Scene to demandes 50%. Ce 50% est transformé en une valeur de 127.5 -> qui va etre envoyé à l'ampoule en 127 (soit 7f)

Il est possible qu'il y ait un manque de consistance entre les conversion % -> analogie et analogie -> %


Les commandes sont gérées depuis Modules/command.py
les update sont gérés depuis Modules/domoticz.py