ZigBee neue Version 1.4.4

[klassisch]

@asgothian sagte in ZigBee neue Version 1.4.4:

Aus diesem Grund hat es eine Anpassung gegeben das der BWM immer dann wenn der Wert für die Helligkeit aktualisiert wird auch eine Bewegung auslöst.

Bedeutet das, daß bei aktualisierter Helligkeit jetzt das Licht angeht, weil "Bewegung erkannt" vorgetäuscht wird?

[Asgothian]

@ilovegym sagte in ZigBee neue Version 1.4.4:

@klassisch stimmt, der andere Adapter ist die nächste Instanz, also stimmen die Pfade nicht mehr..

Gut, dann kommt Plan B dran

Ich clone den Raspi, lass den zweiten ausgeschaltet mit absolut gleicher Config wie der erste, wenn der erste ausfällt, dann wird beim ersten das Netzteil vom Strom getrennt, und beim zweiten das Netzteil mit Strom versorgt.
Somit startet der zweite dann mit gleichem Namen ( ok die Mac und IP ist anders..) und mit der gleichen instanz.

Klar, die beiden sollten dann nebeneinander stehen, das ist von den Örtlichkeiten kein Problem.

Sorry das ich darauf erst jetzt antworte. Ich hatte viel um die Ohren weswegen das so lange gedauert hat.

Leider wirst Du mit deinem Plan B wahrscheinlich keinen Erfolg haben es sei denn du schiebst den Zigbee-Stick vom einen zum anderen System.

Hintergrund:

• Alle Teilnehmer im Zigbee Netzwerk kennen "ihren" Koordinator.
• In jedem Zigbee Netz darf es nur einen Koordinator geben
• in der shepherd.db ist die IEEE Addresses des Koordinators mit hinterlegt. Ich bin unsicher was passiert wenn ein baugleicher Koordinator mit einer anderen IEEE Adresse und dieser shepherd.db verwendet wird.
• Ein "neuer" Koordinator der versucht ein Zigbee Netz aufzumachen welches die gleiche Verschlüsselung wie ein bestehendes Netzwerk besitzt sollte die Kollision bemerken und das aufmachen des Netzes unterbinden. Das ist soweit ich das erinnere bei der Firmware für die "grossen" TI chips (CC2538, CC1352-P2 CC26X2R1) der Fall. Der CC2531 verifiziert das nachweislich NICHT. In einigen Fällen ist es gelungen das Netz wieder aufzubauen, allerdings war dabei die Hardware-ID des "neuen" Koordinators die gleiche wie die des alten - die identische hardware war neu geflasht worden.
• Ein Gerät welches das Zigbee Protokoll sauber implementiert wird den Austausch des Koordinators im bestehenden Netz nicht akzeptieren. Das ist zumindest bei den Hue Lampen die ich habe der Fall.
• Geräte die per "configure" an einen bestehenden Koordinator gebunden wurden und nicht bei jedem Start neu konfiguriert werden werden ihre Meldungen an die IEEE des alten Koordinators senden.

Insgesamt stellt sich das Thema "failover" bei Zigbee (leider) deutlich komplexer dar. Es reicht halt nicht die im ioBroker hinterlegte Konfiguration zu duplizieren.

A.

[Neuschwansteini]

@asgothian Dankeschön!

Kein Thema, ist ja nix kritisches, sondern nur Gedankengänge, wie ich mein Produktives System mit bald mehr als 140 Zigbee devices irgendwie absichern könnte. Das zeigt, dass so ein Netzwerk doch ganz gut abgesichert ist.

[crunchip]

@asgothian habe das soeben mal durchgeführt, jedoch finde ich keine "warn" Meldungen "ELEVATED ..."

[Asgothian]

@crunchip
Zeig mal wie du das in info.debugmessages eingetragen hast

[crunchip]

@asgothian

0x00158d0002fd50

oder muss ich das "0x"weglassen?

Edit: ohne "0x" funktioniert es

zigbee.0	2021-03-02 19:01:22.821	warn	(7934) ELEVATED publishToState: value generated 'true' from device 00158d0002fd50c5 for 'Time from last motion'
zigbee.0	2021-03-02 19:01:22.821	warn	(7934) ELEVATED publishToState: value generated 'true' from device 00158d0002fd50c5 for 'Occupancy'
zigbee.0	2021-03-02 19:01:22.820	warn	(7934) ELEVATED publishToState: message received '{"occupancy":true}' from device 00158d0002fd50c5 type 'RTCGQ11LM'
zigbee.0	2021-03-02 19:01:22.811	warn	(7934) ELEVATED publishToState: value generated '49' from device 00158d0002fd50c5 for 'Link quality'
zigbee.0	2021-03-02 19:01:22.811	warn	(7934) ELEVATED publishToState: message received '{"linkquality":49}' from device 00158d0002fd50c5 type 'RTCGQ11LM'
zigbee.0	2021-03-02 19:01:22.803	warn	(7934) ELEVATED publishToState: value generated '79' from device 00158d0002fd50c5 for 'Illuminance'
zigbee.0	2021-03-02 19:01:22.802	warn	(7934) ELEVATED publishToState: value generated 'true' from device 00158d0002fd50c5 for 'Time from last motion'
zigbee.0	2021-03-02 19:01:22.801	warn	(7934) ELEVATED publishToState: value generated 'true' from device 00158d0002fd50c5 for 'Occupancy'
zigbee.0	2021-03-02 19:01:22.800	warn	(7934) ELEVATED publishToState: message received '{"occupancy":true,"illuminance":79,"illuminance_lux":79}' from device 00158d0002fd50c5 type 'RTCGQ11LM'
zigbee.0	2021-03-02 19:01:22.796	warn	(7934) ELEVATED publishToState: value generated '47' from device 00158d0002fd50c5 for 'Link quality'
zigbee.0	2021-03-02 19:01:22.795	warn	(7934) ELEVATED publishToState: message received '{"linkquality":47}' from device 00158d0002fd50c5 type 'RTCGQ11LM'

[crunchip]

@asgothian sagte in ZigBee neue Version 1.4.4:

Nachtrag: Wenn dieses Verhalten für die Rules zu einem Problem wird kann darüber nachgedacht werden eine Entstellung im Zigbee-Adapter vorzusehen, bei der States nur dann aktualisiert werden wenn die letzte Aktualisierung mehr als x ms zurück liegt oder der Wert sich geändert hat.

Problem ist nicht speziell bei Rules, habe soeben auch mal mit nem Blockly getestet, da erfolgt ebenfalls die Ausgabe doppelt.

letzteres "oder der Wert sich geändert hat." ist ja eher contraproduktiv

[klassisch]

Hatte heute einen seltsamen Effekt: Beim Betrachten der Vernetzungskarte binkte ein Synfonisk rotary encoder ständig Dauerfeuer. Wie ein bubbling idiot.
Auch die Objekte wurden ständig aktualisiert.
Drehen am encode hat nichts geändert.
Nach Neustart des Adapters war Ruhe.
Im log habe ich nichts Verdächtiges gefunden.

[Asgothian]

@crunchip sagte in ZigBee neue Version 1.4.4:

letzteres "oder der Wert sich geändert hat." ist ja eher contraproduktiv

Nein, das ist notwendig. Es gibt durchaus zigbee Geräte die auf einem State mehrere Unterschiedliche Informationen ablegen, so das wenn überhaupt nur "gleiche" Meldungen nicht wiederholt werden sollten.

A.

Und ja, das 0x musste weg

A.

[david83]

Hallo zusammen, ich hätte da vielleicht für den einen oder anderen eine merkwürdige Anfrage, ist es möglich die Farben der offline Geräte oder der Online Geräte auf der Netzwerkkarte zu ändern?

Hintergrund ist dabei das ich Farbenblind bin vor allem bei Grün und Rot. Ich sehe somit keine Unterschiede zwischen den Geräten die verfügbar und Geräte die nicht verfügbar sind.

Mfg
David

[Asgothian]

@david83 Machst du damit bitte einen Issue auf Github auf ?

https://github.com/ioBroker/ioBroker.zigbee/issues

[nama*rian]

Hallo!
ist es möglich folgenden Bewegungsmelder aufzunehmen:


mein Koordinator:

Zigbee Version: 1.4.5
Herstellerlink:
https://climax-deutschland.com/product/ir-9zbs/

Besten Dank im voraus.

[david83]

@asgothian
Wird gemacht

[arteck]

@nama-rian selektiere den bitte unter "Ausschliessen" Tab.. dann adapter neu starten

[nama*rian]

@arteck
Danke für die Unterstützung!

[klassisch]

@klassisch sagte in ZigBee neue Version 1.4.4:

Hatte heute einen seltsamen Effekt: Beim Betrachten der Vernetzungskarte binkte ein Synfonisk rotary encoder ständig Dauerfeuer. Wie ein bubbling idiot.
Auch die Objekte wurden ständig aktualisiert.
Drehen am encode hat nichts geändert.
Nach Neustart des Adapters war Ruhe.
Im log habe ich nichts Verdächtiges gefunden.

Heute Nacht wieder, aber diesmal pwer History aufgezeichnet.

Etwa zwischen 20:00 und 04:00 freie Oszillation. Nach Adapter Restart war Ruhe. Dennoch war das Netz noch nicht in Ordnung. Der Opple Schalter neben dem rotary encoder für dieses Panel funktionierte nicht mehr.
Das zugehörige Panel auch nur sporadisch erreichbar.

Nach Neuinstallation Adapter war wieder alles in Ordnung.

Wollte probeweise die Version 1.3 installieren. Aber die scheint es nicht mehr zu geben?

Das zu diesem encoder gehörige history file hat für gestern 18 MByte
Hier mal ein kleiner Auszug aus dem History file:

{
    "val": true,
    "ack": 1,
    "ts": 1614806839486,
    "q": 0,
    "from": "system.adapter.zigbee.0",
    "user": "system.user.admin"
  },
  {
    "val": false,
    "ack": 1,
    "ts": 1614806839581,
    "q": 0,
    "from": "system.adapter.zigbee.0",
    "user": "system.user.admin"
  },
  {
    "val": true,
    "ack": 1,
    "ts": 1614806839690,
    "q": 0,
    "from": "system.adapter.zigbee.0",
    "user": "system.user.admin"
  },
  {
    "val": false,
    "ack": 1,
    "ts": 1614806839795,
    "q": 0,
    "from": "system.adapter.zigbee.0",
    "user": "system.user.admin"
  },
  {
    "val": true,
    "ack": 1,
    "ts": 1614806839894,
    "q": 0,
    "from": "system.adapter.zigbee.0",
    "user": "system.user.admin"
  },

Oszillator mit Periode von ca. 0.2 Sekunden.

In diesem Zeibereich keine Warnmeldungen oder Fehlermeldungen des zigbee Adapters im log.

[Asgothian]

@klassisch sagte in ZigBee neue Version 1.4.4:

In diesem Zeibereich keine Warnmeldungen oder Fehlermeldungen des zigbee Adapters im log.

Bitte versuch das folgende:

• Installiere die 1.4.5 von Github
• Trage die IEEE des Controllers (Ohne "0x") in den neu vorhandenen State "zigbee.0.info.debugmessages" ein
• lass es laufen.

Wenn der Controller wieder dieses Verhalten zeigt prüf das Log auf "warn" Meldungen mit dem Schlüsselwort "ELEVATED"

Ich gehe im Moment davon aus das

• der Controller eine Macke hat die das Verhalten auslöst
• beim Start des Adapters der Controller eine "configure" Meldung bekommt die dieses Verhalten zunächst einmal beendet.

A.

[klassisch]

@asgothian sagte in ZigBee neue Version 1.4.4:

• Installiere die 1.4.5 von Github

gemacht

• Trage die IEEE des Controllers (Ohne "0x") in den neu vorhandenen State "zigbee.0.info.debugmessages" ein

das ist die Nummer, die bei mousover über den Controller bei der Kartenansicht erscheint?

• lass es laufen.

gemacht. Ohne Adapter-Neustart?

VielenDank!

[Asgothian]

@klassisch Ohne Neustart ist gut. Bitte bei der ieee Addresse kein 0x mit angeben.

A.

[klassisch]

@asgothian Danke, 0x ist nicht davor, aber führende Nullen. Format:

00124B0008c12345