Impossible de modifier le 'min time report' d'un équipement zigbee

Bonjour,

Je suis en dernière version de jeedom et de jeezigbee. La version de z2m est 1.42.0

Je rencontre un problème avec jeezigbee, et z2m
Je souhaite modifier le « min report time » d’un équipement zigbee, et je n’y arrive pas.

Par exemple, une prise de courant NOUS A1Z.
Voici une copie d’écran de l’onglet ‹ Reporting › de jeezigbee et celui de z2m


Dans jeezigbee, pour l’attribut rmsvoltage, je change le « min report time » de 5 à 60, puis je clique sur OK ; tout semble OK dans page Reporting de jeedom.
Mais si je raffaichis la page, j’obtiens 2 lignes contenant l’attribut rmsvoltage : une avec la valeur 5, et une autre avec la valeur 60. Même chose dans l’interface de z2m
Voici les copies d’écran


Depuis l’interface z2m, je supprime (disable) la ligne rmsvoltage en double, ayant la valeur 5 ; si je raffraichis, je reviens à la situation initiale : une seule ligne avec l’attribut rmsvoltage, mais c’est celle qui contient la valeur 5 !

Je précise que l’équipement NOUS fonctionne parfaitement, et remonte correctement ses informations ; trop souvent à mon gout, d’ou mon souhait de modifier le « min report time »

Je rencontre le même problème avec les autres attributs du NOUS, et aussi avec d’autres équipements zigbee (Zlinky par exemple).
Si je modifie plusieurs attributs, tous ceux modifiés se retrouvent en double.
Je suis quasiment certains que ca fonctionnait avant, au moins avec le Zlinky

Voici la log z2m lors des manips :

### changement de la valeur de 5 à 60 ###
info 2025-01-27 13:34:25z2m: Configured reporting for 'prise NOUS_01/1', 'haElectricalMeasurement.rmsVoltage'
info 2025-01-27 13:34:25z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/bridge/response/device/configure_reporting', payload '{"data":{"attribute":"rmsVoltage","cluster":"haElectricalMeasurement","id":"prise NOUS_01/1","maximum_report_interval":3600,"minimum_report_interval":60,"reportable_change":5},"status":"ok","transaction":"1zy2m-9"}'

### suppression de la ligne contenant la valeur 5 ###
info 2025-01-27 13:37:57z2m: Configured reporting for 'prise NOUS_01/1', 'haElectricalMeasurement.rmsVoltage'
info 2025-01-27 13:37:57z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/bridge/response/device/configure_reporting', payload '{"data":{"attribute":"rmsVoltage","cluster":"haElectricalMeasurement","id":"prise NOUS_01/1","maximum_report_interval":65535,"minimum_report_interval":5,"reportable_change":5},"status":"ok","transaction":"1zy2m-10"}'

J’ai également recherché dans le filesystème à quel endroit z2m conservcait ce paramètre ; je n’ai pas trouvé. en tout cas, pas dans configuration.yaml.
Je suppose que c’est directement écrit dans l’équipement ; mais alors, ce doublon est incompréhensible

Je n’arrive pas à m’en sortir. J’ai fait pas mal de recherches, sans trouver de solution.
Si vous avez des pistes de recherche, je suis preneur

Je vous joins à tout hasard mon fichier configuration.yaml

permit_join: false
mqtt:
  server: mqtt://127.0.0.1:1883
  user: xxxx
  password: xxxx
  base_topic: zigbee2mqtt
  include_device_information: true
serial:
  port: /dev/ttyUSB-zbee-zzh
  adapter: zstack
frontend:
  port: 8080
  host: 0.0.0.0
  auth_token: xxxx
advanced:
  last_seen: ISO_8601
  channel: 20
  network_key: xxxx
  pan_id: xxxx
  log_level: warning
  homeassistant_legacy_entity_attributes: false
  legacy_api: false
  legacy_availability_payload: false
external_converters:
  - /var/www/html/plugins/z2m/core/class/../config/converters/Danfoss/icon.js
device_options:
  legacy: false
devices:
...
  '0x00158d0005bea951':
    friendly_name: Zlinky
    linky_mode: standard
    energy_phase: single_phase
    production: auto
    tarif: Standard - BASE
    kWh_precision: 0
    tic_command_whitelist: DATE,EASF01,EAST,SINSTS,IRMS1,URMS1,SMAXN
    measurement_poll_interval: 300
    measurement_poll_chunk: 4
    friendly_name: prise NOUS_01
  '0xa4c138b63f8db009':
    friendly_name: switch tuya TS0001
  '0x001788010673fe8b':
...

Bonjour,

Je pense que c’est un pb avec zigbee2mqtt plutôt que Jeedom.
Il faut donc ouvrir un ticket de ce coté là : Koenkk/zigbee2mqtt · Discussions · GitHub

Norbert

juste une « idée » , ce n’est pas plutôt le report change que tu devrais modifier et non pas les bornes(intervalles) dans lequel fonctionne le report ? de plus un report tous les 5 avec un minimum à 60 cela ne devrait pas fonctionner

Merci pour vos réponses.

@ngrataloup : oui, ca semble un problème zigbee2mqtt ; mais j’ai de grosses difficultés avec la langue anglaise ; décrire cela sur un github …

@Oliflo : Le Min rep change : ce n’est pas un minimum de temps, mais un minimum de valeur.
Avec les valeurs saisies : 60 - 3600 - 5, ca devrait donner une remontée d’info si il y a une différence de plus de 5mV (je crois), à condition qu’il n’y ait pas eu de remontée dans les 60s précédente. Et dans tous les cas, une remontée s’il n’y en a pas eu depuis 1h.
C’est comme cela que j’interprete ces valeurs.

Sinon, j’ai un peu cherché coté filesystème : on retrouve des infos relatives à chaque équipement dans /var/www/html/plugins/z2m/data/devices

Pour mon équipement NOUS, c’est le fichier devices/a4:c1:38:f6:87:bc:8e:5c.json
Lorsque je modifie le « Min rep interval » pour rmsvoltage, je retrouve bien les infos dédoublées dans le fichier json :

{
	"endpoints": {
		"1": {
			"configured_reportings": [
				{
					"attribute": "rmsVoltage",
					"cluster": "haElectricalMeasurement",
					"maximum_report_interval": 3600,
					"minimum_report_interval": 5,
					"reportable_change": 5
				},
...
				{
					"attribute": "rmsVoltage",
					"cluster": "haElectricalMeasurement",
					"maximum_report_interval": 3600,
					"minimum_report_interval": 60,
					"reportable_change": 5
				},
...

Du coup, vu les logs, j’ai l’impression que l’envoi de la bonne info à l’équipement s’est fait, et qu’un cache de z2m se met mal à jour.

Je pense que le problème est général :
j’ai un accès à distance au jeedom de mon fils (pas à l’interface web z2m). Concernant le Zlinky, j’ai passé le min time du currentSummDelivered de 60 à 80, et l’information s’est retrouvée dédoublée dans jeedom.

Je ne l’avais pas lu ni exploité ainsi… tu m’ouvres des perspectives :slight_smile:

Pour info j’ai saisi comme toi et n’ai pas eu de doublon (Luna/Z2m)

C’est bizarre que je reproduise le même problème chez mon fils, et pas toi.

On est en dernières versions : jeedom 4.4.19, jeezigbee du 15/01/2025 et zigbee2mqtt en 1.42.0
Tu as les mêmes versions ?

Bonjour,

Peut-être une version du firmware de la prise différent ?
Vous pouvez le mettre à jour sur la page web de Z2M

oui
4.4.19 pour jeedom
2025-01-15 01:01:47 pour Jeezigbee
1.42.0 pour zigbee2mqtt

voici l’extrait de Zigbee2MQTT

Version de Zigbee2MQTT
1.42.0 commit: 861cba63
Type de coordinateur
EZSP v8

Révision du coordinateur
6.10.3.0 build 297

Adresse IEEE du Coordinateur
0x70c59cfffe61536e

Version de l’interface
0.7.6

Version Zigbee-herdsman-converters
20.58.0

Version Zigbee-herdsman
2.1.9

bonjour,

Mes équipements zigbee sont à jour coté firmware.
J’avais constaté le problème sur 2 équipements : la prise NOUS et le Zlinky.
Par curiosité, je viens de regarder une prise Legrand ; je n’ai pas souvenir d’avoir touché au ‹ reporting › de cet équipement. En tout cas, je n’ai pas mis le nez dedans depuis des lustres, en dehors de la MaJ du firmware (la dernière récente).

Pour cette prise legrand, les 3 attributs du reporting sont doublonnés, dans jeezigbee et dans z2m, avec les mêmes valeurs :
OnOff : 0 - 3600 - 0
activePower : 5 - 3600 - 1
apparentPower : 5 - 3600 - 1

Par curiosité, j’ai été voir le fichier json correspondant dans /var/www/html/plugins/z2m/data/devices ; les infos sont bien doublonnées dedans.

Bref, j’ai un gros b…l dans mon install, et je ne suis probablement pas le seul.
Je n’ai pas trouvé dans les issues du github zigbee2mqtt de problème similaire.
Est-ce qui ne pourrait pas y avoir quand même un lien avec le plugin jeezigbee ?

Merci pour l’info. Mêmes versions que moi

voici les infos de la prise Nous

{
    "child_lock": "UNLOCK",
    "countdown": 0,
    "current": 0,
    "energy": 0,
    "indicator_mode": "off/on",
    "last_seen": "2025-01-29T19:24:44.225Z",
    "linkquality": 200,
    "power": 0,
    "power_outage_memory": "restore",
    "state": "ON",
    "update": {
        "installed_version": 192,
        "latest_version": 192,
        "state": "idle"
    },
    "voltage": 230,
    "device": {
        "applicationVersion": 192,
        "dateCode": "",
        "friendlyName": "0xa4c138f13bfd400c",
        "hardwareVersion": 1,
        "ieeeAddr": "0xa4c138f13bfd400c",
        "manufacturerID": 4417,
        "manufacturerName": "_TZ3000_2putqrmw",
        "model": "A1Z",
        "networkAddress": 48890,
        "powerSource": "Mains (single phase)",
        "stackVersion": 0,
        "type": "Router",
        "zclVersion": 3
    }
}

bon résultat des courses !! :slight_smile:

j’ai paramétré en tenant compte de tes informations 60/3600 avec 5000 de report change (pour n’avoir rien en dehors d’une variation de 5 volts:

Voici les résultats dans les logs -Ils ne sont pas conformes à l’attendu- et surtout ne donnent pas vraiment de pistes :frowning: :

[2025-01-29 19:19:24] INFO: Evènement sur la commande [Voltage] valeur : 231V
[2025-01-29 19:24:33] INFO: Evènement sur la commande [Voltage] valeur : 228V
[2025-01-29 19:29:48] INFO: Evènement sur la commande [Voltage] valeur : 230V
[2025-01-29 19:40:20] INFO: Evènement sur la commande [Voltage] valeur : 233V
[2025-01-29 19:45:36] INFO: Evènement sur la commande [Voltage] valeur : 231V
[2025-01-29 19:51:01] INFO: Evènement sur la commande [Voltage] valeur : 230V
[2025-01-29 19:56:14] INFO: Evènement sur la commande [Voltage] valeur : 231V
[2025-01-29 20:01:41] INFO: Evènement sur la commande [Voltage] valeur : 230V
[2025-01-29 20:17:15] INFO: Evènement sur la commande [Voltage] valeur : 231V
[2025-01-29 20:22:30] INFO: Evènement sur la commande [Voltage] valeur : 230V
[2025-01-29 20:27:37] INFO: Evènement sur la commande [Voltage] valeur : 231V

J’ai les mêmes infos que toi ; il manque juste l’info countdown, mais ce n’est pas ca qui explique mon problème

On est un peu en dehors du sujet.
En effet, c’est compliqué à suivre les changements fait dans le reporting.
D’une part, c’est géré par l’équipement ; plus ou moins bien.
D’autre part, z2m garde les infos en cache. Quand il remonte les infos par MQTT, il remonte tout ce qu’il a en cache ; on le voit bien dans les infos que tu as envoyé.

Une explication possible de la divergence que tu constates : supposons que le NOUS veuille envoyer une notification parce que le courant (rmsCourant) a varié de plus de 50 mA ; il est possible qu’il transmette en même temps d’autres infos, comme la tension (rmsVoltage) : ca ne coute pas beaucoup plus cher. Et donc tu as plus de notifications sur rmsVoltage que paramétré.

Je ne garanti pas que la divergence que tu constates vient de la, mais ca pourrait être une piste.

1 « J'aime »

Je pense avoir réglé mon problème ; et j’ai des pistes pour en comprendre l’origine.

Résolution du problème

Je me suis apercu que les infos de reporting sont présentes dans le fichier /var/www/html/plugins/z2m/data/database.db
Dans ce fichier, il y a une ligne par équipement zigbee ; et chaque ligne contient les informations relatives à un équipement, en format json

Voici un extrait de ce fichier, pour un équipement sur lequel je constate le problème, et pour une commande en double ; ici activePower (cluster 2820 et attrib 1291) :

...
{
	"endpoints": {
		"1": {
			"configuredReportings": [
				{
					"cluster": 2820,
					"attrId": 1291,
					"minRepIntval": 5,
					"maxRepIntval": 3600,
					"repChange": 1,
					"manufacturerCode": null
				},
				...
				{
					"cluster": 2820,
					"attrId": 1291,
					"minRepIntval": 10,
					"maxRepIntval": 3600,
					"repChange": 1
				},
			...
			],
		},
	},
}

On voit bien que le même attribut est doublonnné. L’un a un champ manufacturerCode à null, l’autre n’a pas ce champ. Celui qui n’a pas ce champs est celui pour lequel j’ai changé une valeur ; ici, c’est minRepIntval, que j’ai passé de 5 à 10.

Pour retrouver un fonctionnement normal, il suffit de supprimer dans le json l’enregistrement en double qui contient le champ manufacturerCode à la valeur nulle.

Voici comment j’ai procédé :

  1. Arret du démon z2m, depuis la configuration du plugin. Vérifier que z2m n’est plus en exécution.
  2. sauvegarde de précaution du fichier database.db . C’est TRES IMPORTANT
  3. rechercher les occurences de "manufacturerCode":null dans le fichier database.db : grep '"manufacturerCode":null' /var/www/html/plugins/z2m/data/database.db
  4. editer le fichier database.db
    . pour chaque ligne comportant au moins une occurence de "manufacturerCode":null :
    si l’attribut est dupliqué dans la ligne, supprimer l’occurence comportant "manufacturerCode":null
    sinon, supprimer uniquement la partie ',"manufacturerCode":null'
  5. redémarrer le démon z2m, et vérifier
    . que tout fonctionne bien
    . qu’on peut maintenant modifier une valeur de reporting sans créer de doublons

La manip n’est pas simple à faire ; il faut être rigoureux. D’ou l’importance de sauvegarder le fichier database.db avant modification, pour revenir en arrière si problème.
Je n’ai pas beaucoup d’équipements zigbee ; une vingtaine. Et la plupart n’ont pas d’attributs en reporting : équipements sans fil genre inter, sondes de température, …
Dans le cas contraire, ca devient vite fastidieux.

J’ai procédé de manière empirique, mais ca fonctionne correctement maintenant.
A savoir que les modifs de reporting que je faisaient étaient bien prises en compte par les équipements (si j’en crois la log) ; c’est la présentation qui montrait des doublons.

Origine du problème
Je me suis demandé pourquoi j’avais ce problème, mon fils également, et pas les personnes qui m’on répondu dans ce fil.
J’ai une piste qui me semble assez sérieuse : dans les 2 cas, j’ai procédé, il y a plus d’un an, à une migration de zigbeeLinker vers jeeZigbee en suivant cette procédure :

C’est la seule chose un peu bidouilleuse que j’ai pu faire sur les 2 installations, concernant z2m …

@Oliflo : pour la partie fonctionnement du reporting : min rep interval , max rep interval , min rep change
j’ai créé un nouveau sujet : Limiter le nombre de messages zigbee avec zigbee2mqtt

1 « J'aime »

Merci @vmath54 pour tout ce travail d’investigation.
J’ai constaté le même problème de doublon sur mon installation (jeezigbee, z2m 1.42) en voulant modifier le réglage de mes sondes sonoff SNZB-02D dont les piles s’usent.

J’ai commencé par faire les manips dans l’interface de zigbee2mqtt et constaté le même problème que toi.
j’ai seulement ensuite essayé dans le plugin, sans plus de succès.

Pour info, je n’ai jamais eu zigbeelinker donc peu probable que ce soit ta migration qui pose problème.

Le problème est documenté ici chez zigbee2mqtt: Doubled Reporting Line for the same Attribute / Interval values do not change properly · Issue #23933 · Koenkk/zigbee2mqtt · GitHub

Et la bonne nouvelle c’est qu’il semble qu’il y a un workaround en supprimant et réappairant le device.
Le pb est bien dû à

"manufacturerCode": null

qui n’est plus écrit dans les nouvelles versions de z2m ; en supprimant l’entrée tu supprimes le problème de cette ligne

un autre moyen de corriger le problème est de supprimer ces lignes dans le fichier .db
vous pouvez le faire sur toutes les lignes avec la méthode suivante: Doubled Reporting Line for the same Attribute / Interval values do not change properly · Issue #23933 · Koenkk/zigbee2mqtt · GitHub

1 « J'aime »

Merci pour ces infos :grinning:

Je crois qu’on peut considérer ce sujet comme résolu, coté jeedom.

Ce sujet a été automatiquement fermé après 24 heures suivant le dernier commentaire. Aucune réponse n’est permise dorénavant.