NEWS
Test Adapter zigbee2mqtt
-
@aragon Konnte den Fehler eingrenzen...
Dieser neuen State mach mir Probleme weil er eine Objekt in einen Objekt ist und das gab es meines Wissens vorher nicht. da muss ich nun mal grübeln wie ich das umsetzte.
{ "access": 2, "description": "Definition of a new region to be added (or replace existing one). Creating or modifying a region requires you to define which zones of a 7x4 detection grid should be active for that zone. Regions can overlap, meaning that a zone can be defined in more than one region (eg. \"zone x = 1 & y = 1\" can be added to region 1 & 2). \"Zone x = 1 & y = 1\" is the nearest zone on the right (from sensor's perspective, along the detection path).", "features": [ { "access": 2, "name": "region_id", "property": "region_id", "type": "numeric", "value_max": 10, "value_min": 1 }, { "access": 2, "item_type": { "features": [ { "access": 2, "name": "x", "property": "x", "type": "numeric", "value_max": 4, "value_min": 1 }, { "access": 2, "name": "y", "property": "y", "type": "numeric", "value_max": 7, "value_min": 1 } ], "name": "zone_position", "type": "composite" }, "name": "zones", "property": "zones", "type": "list" } ], "name": "region_upsert", "property": "region_upsert", "type": "composite" }, -
@aragon Konnte den Fehler eingrenzen...
Dieser neuen State mach mir Probleme weil er eine Objekt in einen Objekt ist und das gab es meines Wissens vorher nicht. da muss ich nun mal grübeln wie ich das umsetzte.
{ "access": 2, "description": "Definition of a new region to be added (or replace existing one). Creating or modifying a region requires you to define which zones of a 7x4 detection grid should be active for that zone. Regions can overlap, meaning that a zone can be defined in more than one region (eg. \"zone x = 1 & y = 1\" can be added to region 1 & 2). \"Zone x = 1 & y = 1\" is the nearest zone on the right (from sensor's perspective, along the detection path).", "features": [ { "access": 2, "name": "region_id", "property": "region_id", "type": "numeric", "value_max": 10, "value_min": 1 }, { "access": 2, "item_type": { "features": [ { "access": 2, "name": "x", "property": "x", "type": "numeric", "value_max": 4, "value_min": 1 }, { "access": 2, "name": "y", "property": "y", "type": "numeric", "value_max": 7, "value_min": 1 } ], "name": "zone_position", "type": "composite" }, "name": "zones", "property": "zones", "type": "list" } ], "name": "region_upsert", "property": "region_upsert", "type": "composite" }, -
Testet jetzt mal von git, jetzt sollten die wieder angelegt werden allerdings erstmal ohne diesen neuen State.
-
Testet jetzt mal von git, jetzt sollten die wieder angelegt werden allerdings erstmal ohne diesen neuen State.
-
Guten Morgen zusammen,
Kann mir einer vielleicht sagen, warum mir im ioBroker nicht der state available angezeigt wird. In den z2m Einstellungen habe ich es aktiviert, aber ich erhalte nur false als Wert.
Gruß und schönen Sonntag
-
@meerkat schon mal hier geschaut ob alles in der Config vorhanden ist?
https://github.com/o0shojo0o/ioBroker.zigbee2mqtt/blob/main/docs/DE/DE_get-started.md -
@idlebit ja, bis auf
device_options: legacy: falseHabe ich die anderen Sachen auch drin stehen.
Availability ist auf true -
@arteck moin, fehler habe ich gefunden. In der Oberfläche habe ich die Option "Legacy availability payload" deaktiviert und nun erhalte ich die availability
-
Hallo @idlebit
zuerst einmal meinen Dank für diesen Adapter. Er funktioniert bei mir wunderbar.
Ein Punkt beschäftigt mich jedoch im Moment.
Ich habe eine Art Alive-Skript, was mir Geräte (nicht nur Zigbee) anhand des Zeitstempels überwacht. Wenn der state z.B. Temperatur oder Batterie oder oder (je gerät hab ich das individuell gewählt) nicht innerhalb z.B. 1h aktualisiert wird, meldet es mir das Skript.
Ich hatte zuvor den Zigbee-Adapter verwendet. Dort war es so, dass die Zeitstempel der States von "geändert" und "aktualisiert" so erzeugt werden wie es wohl auch sein sollte.
Beim z2m-Adapter sind jedoch die Zeitstempel für aktualisiert und geändert immer gleich. Ist das so gewollt bzw. könnte man das Verhalten hier noch anpassen?
Ich hoffe ich hab mich nicht zu umständlich ausgedrückt :)
Danke und Grüße
Daniel -
Hallo @idlebit
zuerst einmal meinen Dank für diesen Adapter. Er funktioniert bei mir wunderbar.
Ein Punkt beschäftigt mich jedoch im Moment.
Ich habe eine Art Alive-Skript, was mir Geräte (nicht nur Zigbee) anhand des Zeitstempels überwacht. Wenn der state z.B. Temperatur oder Batterie oder oder (je gerät hab ich das individuell gewählt) nicht innerhalb z.B. 1h aktualisiert wird, meldet es mir das Skript.
Ich hatte zuvor den Zigbee-Adapter verwendet. Dort war es so, dass die Zeitstempel der States von "geändert" und "aktualisiert" so erzeugt werden wie es wohl auch sein sollte.
Beim z2m-Adapter sind jedoch die Zeitstempel für aktualisiert und geändert immer gleich. Ist das so gewollt bzw. könnte man das Verhalten hier noch anpassen?
Ich hoffe ich hab mich nicht zu umständlich ausgedrückt :)
Danke und Grüße
Daniel@friesenjung Bei den Adapter werden Datenpunkte nur unter zwei Bedingungen neu gesetzt, die erste wäre wenn sich ein Wert ändert und die zweite ist wenn es sich um ein Event handelt.
Ein Event wird von zigbee2mqtt vorgeben und ist z.B. ein Taster oder der gleichen.
Hier wurde schon mal darüber diskutiert -> https://github.com/o0shojo0o/ioBroker.zigbee2mqtt/issues/119Die Alive Logik kann man das auch wunderbar anpassen wenn die ein im Default nicht gefällt.
-
@friesenjung Bei den Adapter werden Datenpunkte nur unter zwei Bedingungen neu gesetzt, die erste wäre wenn sich ein Wert ändert und die zweite ist wenn es sich um ein Event handelt.
Ein Event wird von zigbee2mqtt vorgeben und ist z.B. ein Taster oder der gleichen.
Hier wurde schon mal darüber diskutiert -> https://github.com/o0shojo0o/ioBroker.zigbee2mqtt/issues/119Die Alive Logik kann man das auch wunderbar anpassen wenn die ein im Default nicht gefällt.
Hi @IdleBit
danke für die Rückmeldung und die Info mit der Availability in z2m. Hatte ich nicht so auf dem Schirm, jedoch nachdem ich mir es angeschaut habe, ist es eher nicht das was ich suche.
Hier kann man nur einen globalen Wert für z.B. batteriebetriebene Sensoren angeben. Da sich die vielen Geräte aber im Verhalten sehr stark voneinander unterscheiden (also wie oft und wann sie Dinge senden bzw. sich melden) ist hier auch sinnvollerweise ein recht hoher Wert angegeben (1500 Min. alsoe etwas länger als ein Tag) den ich auch nicht global ändern möchte.Es gab hier auch mal den Wunsch den "last_seen-Datenpunkt" zu übertragen: https://github.com/o0shojo0o/ioBroker.zigbee2mqtt/issues/131
Das würde vielleicht schon eher meinen Fall (zugegebenermaßen vielleicht Einzelfall :) ) "lösen" können.Wenn ich Dich richtig verstanden habe, liegt es aber in erster Linie ja daran, dass z2m nur Werteänderungen und Events weitergibt. richtig?
Also kann der (andere) Zigbee-Adapter den Zeitstempel für aktualisierte Werte (gleicher Wert aber neu gesendet) wohl nur angeben, weil dieser die Payloads der Geräte selber "auswertet" > richtig?
Ich wills nur verstehen :)VG
Daniel -
Hi @IdleBit
danke für die Rückmeldung und die Info mit der Availability in z2m. Hatte ich nicht so auf dem Schirm, jedoch nachdem ich mir es angeschaut habe, ist es eher nicht das was ich suche.
Hier kann man nur einen globalen Wert für z.B. batteriebetriebene Sensoren angeben. Da sich die vielen Geräte aber im Verhalten sehr stark voneinander unterscheiden (also wie oft und wann sie Dinge senden bzw. sich melden) ist hier auch sinnvollerweise ein recht hoher Wert angegeben (1500 Min. alsoe etwas länger als ein Tag) den ich auch nicht global ändern möchte.Es gab hier auch mal den Wunsch den "last_seen-Datenpunkt" zu übertragen: https://github.com/o0shojo0o/ioBroker.zigbee2mqtt/issues/131
Das würde vielleicht schon eher meinen Fall (zugegebenermaßen vielleicht Einzelfall :) ) "lösen" können.Wenn ich Dich richtig verstanden habe, liegt es aber in erster Linie ja daran, dass z2m nur Werteänderungen und Events weitergibt. richtig?
Also kann der (andere) Zigbee-Adapter den Zeitstempel für aktualisierte Werte (gleicher Wert aber neu gesendet) wohl nur angeben, weil dieser die Payloads der Geräte selber "auswertet" > richtig?
Ich wills nur verstehen :)VG
Daniel@friesenjung sagte in Test Adapter zigbee2mqtt:
Also kann der (andere) Zigbee-Adapter den Zeitstempel für aktualisierte Werte (gleicher Wert aber neu gesendet) wohl nur angeben, weil dieser die Payloads der Geräte selber "auswertet" > richtig?
jo genau so ist es
zigbee hab ich, zwave auch, nuc's genauso und HA auch
-
@friesenjung sagte in Test Adapter zigbee2mqtt:
Also kann der (andere) Zigbee-Adapter den Zeitstempel für aktualisierte Werte (gleicher Wert aber neu gesendet) wohl nur angeben, weil dieser die Payloads der Geräte selber "auswertet" > richtig?
jo genau so ist es
@arteck sagte in Test Adapter zigbee2mqtt:
@friesenjung sagte in Test Adapter zigbee2mqtt:
Also kann der (andere) Zigbee-Adapter den Zeitstempel für aktualisierte Werte (gleicher Wert aber neu gesendet) wohl nur angeben, weil dieser die Payloads der Geräte selber "auswertet" > richtig?
jo genau so ist es
Ne nicht ganz, auch dieser Adapter wertet die Payloads selbst aus.
Bloß ich habe mich dazu entscheiden nicht unsinnig alles in die StatesDB zu knallen, so setzte ich im Adapter nur Werte die sich ändern, außer diese stammen von "Zigbee-Event". -
@arteck sagte in Test Adapter zigbee2mqtt:
@friesenjung sagte in Test Adapter zigbee2mqtt:
Also kann der (andere) Zigbee-Adapter den Zeitstempel für aktualisierte Werte (gleicher Wert aber neu gesendet) wohl nur angeben, weil dieser die Payloads der Geräte selber "auswertet" > richtig?
jo genau so ist es
Ne nicht ganz, auch dieser Adapter wertet die Payloads selbst aus.
Bloß ich habe mich dazu entscheiden nicht unsinnig alles in die StatesDB zu knallen, so setzte ich im Adapter nur Werte die sich ändern, außer diese stammen von "Zigbee-Event".hi @IdleBit
bitte nicht falsch verstehen, ist vielleicht nur ein kläglicher Versuch dich umzustimmen :)
aber ich dachte genau dafür gibt es in ioB die 2 Zeitstempel.
Die Daten sind ja tatsächlich übermittelt worden und wenn es der gleiche Wert ist, dann eben nur aktualisiert.
Grüße
-
hi @IdleBit
bitte nicht falsch verstehen, ist vielleicht nur ein kläglicher Versuch dich umzustimmen :)
aber ich dachte genau dafür gibt es in ioB die 2 Zeitstempel.
Die Daten sind ja tatsächlich übermittelt worden und wenn es der gleiche Wert ist, dann eben nur aktualisiert.
Grüße
-
Hallo,
nur zur Info: Bin heute von deconz (conbee2) gewechselt und folgende Konfigurationsoption in der Anleitung hat mich den halben Tag gekostet.
transmit_power: 20Damit startet zigbee2mqtt nicht und gibt keine hilfreiche Fehlerausgabe. Vielleicht aus der Vorlage entfernen oder ne Anmerkung hinzufügen.
Support us
805
Online32.6k
Users82.1k
Topics1.3m
Posts