Tester für Zigbee Adapter 2.0.x gesucht

[Asgothian]

@bommel_030 sagte in Tester für Zigbee Adapter 2.0.x gesucht:

Der Teil data:image/png; base64, geht scheinbar beim umbenennen verloren ?!? Wenn ich den in der Entwicklerkonsole hinzufüge erscheint das Bild.

wieviele Zeichen hat das was in "src" drin steht ?

A.

[bommel_030]

@asgothian
Beim innr ca. 38.852 Zeichen, Trektakt 100.536 Zeichen.
"Mein" altes Trektat Bild funktioniert auch, wenn ich die base64 codierung davor setze....

[Asgothian]

@bommel_030 sagte in Tester für Zigbee Adapter 2.0.x gesucht:

@asgothian
Beim innr ca. 38.852 Zeichen, Trektakt 100.536 Zeichen.
"Mein" altes Trektat Bild funktioniert auch, wenn ich die base64 codierung davor setze....

ich bin irritiert - die base64 Notierung wird vor den String gesetzt wenn dieser länger ist als 50 Zeichen.

[bommel_030]

@asgothian
So, um mich vollends zu verwirren, ich habe heute früh Admin und web auf die neueste Version aus dem latest gebracht. Seitdem ist es egal ob ich per Konsole oder FTP kopiere und umbenennen, die Bilder werden immer richtig dargestellt. Kann das damit zusammenhängen?

Bzgl. der kleinen IKEA Fernbedienung, die habe ich vor deinen Post noch einmal neu angelernt. Seitdem scheint sie zu funktionieren. Sollte sie wieder zicken probiere ich das mit dem Debug. Irgendwo hab ich auch nicht eine weitere rumliegen und könnte damit debuggen wenn es von Interesse ist.

Das einzige was nicht klappt sind die Firmware Updates, da stürzt er immer ab. Kann ich da außer den Logs oben noch mehr liefern?

[Asgothian]

@bommel_030 sagte in Tester für Zigbee Adapter 2.0.x gesucht:

Das einzige was nicht klappt sind die Firmware Updates, da stürzt er immer ab. Kann ich da außer den Logs oben noch mehr liefern?

Bedingt - da scheint etwas in einer externen Bibliothek schief zu gehen. Das ist eigentlich alles per try/catch abgefangen, weswegen ich da maximal irritiert bin. Es findet sich in deinem Log auch kein Hinweis auf den Code der da betroffen ist.

Was du mal tun kannst:

• die Sentry integration ausschalten (Bild: obere Instanz: Sentry aktiv, untere Instanz: Sentry inaktiv)
  
• versuchen die einzelnen Geräte zu deaktivieren um heraus zu bekommen welches Gerät den Absturz hervorruft.
• die 2.0.3 RC3 von meinem Repository (https://github.com/asgothian/ioBroker.zigbee/tarball/1.11) installieren und schauen ob der Fehler da auch noch auftritt.

A.
p.s. mit der 2.0.3 RC3 (die intern noch als 2.0.2 angezeigt wird) bekommst du dann auch das debug-interface

[bommel_030]

@asgothian
Treffer, versenkt...
Sentry abschalten und der Check läuft durch.
Mangels verfügbarem Update kann ich allerdings nicht testen ob das laufen würde.

[Asgothian]

@bommel_030 sagte in Tester für Zigbee Adapter 2.0.x gesucht:

Mangels verfügbarem Update kann ich allerdings nicht testen ob das laufen würde.

Was meinst Du damit ?

[deta]

Seit Version 2, wird beim
model:RTCGQ11LM
description:Motion sensor

Nicht mehr der Punkt "no_motion" ausgelesen.

Unter Version 1.10.14 funktionierte es noch.

Adapter version
2.0.2

Coordinator firmware version
2-1.2.7.1

Coordinator
Sonoff zStack3x0

Setup
Mini PC

Antwort bei Issues: (https://github.com/ioBroker/ioBroker.zigbee/issues/2400)

Wie soll ich das verstehen? Warum Aufgegeben? Es ist doch ein wichtiger Punkt, wann
die letzte Reaktion war!

cu Deta

detafun created this issue in ioBroker/ioBroker.zigbee

closed Problem mit Xiaomi Menschlicher Körpersensor Zigbee #2400

[Asgothian]

@deta so wie es da steht. Der Punkt wird von den zigbee-herdsman-converters nicht weiter unterstützt. Deswegen ist er im zigbee-Adapter ab 2.0 nicht mehr vorhanden.

A.

[bommel_030]

@asgothian
Ohne Sentry kann ich wieder nach Updates suchen, aber da für keins meiner Geräte ein Update verfügbar ist kann ich keins starten.

[deta]

@asgothian sagte in Tester für Zigbee Adapter 2.0.x gesucht:

@deta so wie es da steht. Der Punkt wird von den zigbee-herdsman-converters nicht weiter unterstützt. Deswegen ist er im zigbee-Adapter ab 2.0 nicht mehr vorhanden.

A.

Ich hatte den Punkt benutz um nach einer bestimmten Zeit das Licht wieder abzuschalten. Wenn keine Bewegung mehr nach einer weile im Raum war.
Gibt es eine andere Lösung?

[Asgothian]

@bommel_030 ah.. ok.

[Asgothian]

@deta sagte in Tester für Zigbee Adapter 2.0.x gesucht:

@asgothian sagte in Tester für Zigbee Adapter 2.0.x gesucht:

@deta so wie es da steht. Der Punkt wird von den zigbee-herdsman-converters nicht weiter unterstützt. Deswegen ist er im zigbee-Adapter ab 2.0 nicht mehr vorhanden.

A.

Ich hatte den Punkt benutz um nach einer bestimmten Zeit das Licht wieder abzuschalten. Wenn keine Bewegung mehr nach einer weile im Raum war.
Gibt es eine andere Lösung?

der standard weg ist:

let timeout = null;
on({ID:'...occupancy', change: ne}. function(obj) {
   if (obj.val) {
  // light on
    clearTimeout(timeout);
  }
  else
  {
     timeout = setTimeout(function() { 
        // light off 
      },time)
  }
});

oder das Äquivalent in einer anderen Logik-Maschine.

A.

[Duffy]

@asgothian

Hallo,

mir ist etwas aufgefallen was den Zigbee Adapter v2.02 betrifft.

Da ich nicht weis ob es an mir oder dem Adapter liegt schreibe ich es hier einfach mal nieder.

Also, ich habe auf meine Testsystem den o.g. Adapter installiert.
Nun hat ein Tuya Fingerbot im Aktivsystem nicht mehr funktioniert was mich dazu veranlasste diesen im Aktivsystem zu löschen.

Dann habe ich ihn im Testsystem über den Zigbee 2.02 Adapter installiert und er hat funktioniert.
(Also muß ich ihn erst mal nicht entsorgen)

Dann wollte ich ihn wieder aus dem Testsystem löschen was aber nicht mehr gelang. Er ist hartnäckig gekoppelt geblieben. (Löschen über die Kachel, Mülleimer, dann gelöscht bzw auch das Häkchen gesetzt und gelöscht)

Erst als ich den Zigbee Adapter 2.02 deaktiviert hatte konnte ich den Fingerbot erneut im Aktivsysten mit Zigbee 1.10.14 erneut koppeln.

Kann das ein Bug sein?
Wenn nein, einfach meinen Post löschen.

VG Duffy

[Asgothian]

@duffy das kenne ich von bestimmten “dummen” Geräten, die sich nicht einfach so vollständig zurück setzen lassen.

Ob das bei den fingerbots der Fall ist weiss ich nicht - was passiert ist das die Geräte nicht sauber ins pairing gehen solange sie ein “altes” Netzwerk kontaktieren können.

A.

[Duffy]

@asgothian

Ok, dann ist der Fehler also bekannt.
Danke für dein Rückmeldung.

Gruß Duffy

[Neuschwansteini]

@duffy

mir ist gestern auch sowas aufgefallen, da ich ein aehnliches Phaenomen hatte.. eine Paulmann E27 war auf einmal nicht mehr erreichbar, konnte sie nicht zurueck setzen, erst als ich den Adapter deaktiviert habe, war sie dann resettet.

Habe auch 2 Instanzen, da eine mit 220 Devices anscheinend so voll ist, dass ich da nichts mehr anlernen kann. Hab da schon einige Devices raus, waren mal 240 drin, hilft aber auch nicht. Evtl sollte ich mal meine Firmware auf dem Coordinator updaten..

Das ganze kann ja auch am Netzwerk / Fremdeinfluss liegen.. muss ja nicht immer der iobroker-Adapter sein
von daher schwer nachzuvollziehen.. aber gut, dass du es geschrieben hast.. vielleicht haengt da ja ab und zu mal was..

Mein Environment besteht aus 4 Zigbee Netzwerken, 2x openepaperlink auf Kanal 20, einmal iobroker Kanal 11 und Kanal 25.

[Duffy]

@neuschwansteini

Nur für die als Info.
Ich habe auf meinem Koordinator:

CC1352P2_CC2652P_launchpad_coordinator_20240710.hex

Aber die Anmerkung nur weil du geschrieben hast das du evtl die Firmware beim Koordinator updaten willst.

Gruß Duffy

[Asgothian]

Es gibt eine neue Version im Latest - 2.0.3.

Diese beinhaltet primär bugfixes, wie z.Bsp. die Spannung bei batteriebetriebenen Geräten, die jetzt die korrekte Einheit (mV) meldet. Ich habe mich dagegen entschieden den Zahlenwert anzupassen, da dieses die Werte bei allen Sensoren geändert hatte. Parallel dazu wurde auf die neueren Zigbee-Herdsman-Converters (23.1.1) gewechselt.

Des Weiteren gibt es eine Anpassung bei der Gerätekonfiguration. Diese wird auf der einen Seite jetzt korrekt in der Geräteinformation angezeigt - wobei die Anzeige nur zeigen kann ob der Adapter der Meinung ist das das Gerät konfiguriert wurde. Der Adapter bekommt es weiterhin nicht mit wenn ein Gerät die Konfiguration verliert. Zum anderen wird die Konfiguration unter Umständen automatisch wiederholt. Wenn bei der Konfiguration eine Zeitüberschreitung auftritt geht der Adapter davon aus das das Gerät nicht wach war und deswegen nicht geantwortet hat. Sobald ein Event vom Gerät empfangen wurde wird die Konfiguration erneut gestartet. Dadurch sollte es einfacher sein batteriebetriebene Geräte zu konfigurieren.

Die letzte grosse Anpassung betrifft den Debug-Tab, der inzwischen aktiv ist. Dieser ist zusammen mit dem von der Gerätekachel einzustellenden Debug Modus für Geräte zu nutzen. Eine detaillierte Beschreibung ist in Arbeit.

Der Tab zeigt die eingehenden und ausgehenden Meldungen je Gerät untereinander an. Dabei werden nicht alle Nachrichten aus dem Log angezeigt - man kann aber an Hand der Anzeige erkennen an welcher Stelle eine Kommunikation abgebrochen wurde. Siehe als Beispiel die beiden folgenden Screenshots:

Eingehende Meldungen

Ausgehende Meldungen

Die Darstellung aktualisiert sich nicht automatisch damit während der Analyse keine neuen Nachrichten erscheinen. Eine manuelle Aktualisierung ist über den grünen Button möglich. Dabei aktualisieren alle grünen Buttons immer alle nachrichten.

Die blauen Buttons dienen der Anpassung der Anzeige. Dabei wirken die Buttons oben auf der Seite auf alle Nachrichten, während die an den Eingehenden / Ausgehenden Nachrichten verankerten Buttons sich nur auf die jeweilige Sektion auswirken.

Mit diesem Button lassen sich Meldungen ein/ausblenden.Dabei wird jeweils der gesamte Block ausgeblendet (Alle eingehenden oder ausgehenden Nachrichten eines Gerätes)

Mit diesem button lassen sich die Meldungen filtern. Dabei versucht das System automatisch gleichartige Nachrichten zu erkennen und auf jeweils eine dargestellte Zeile zu reduzieren.

A.

[Shadowhunter23]

@asgothian

Kann man zu dieser Meldung was sagen? War auch schon in der 2.0.2 so.

zigbee.3
2025-03-07 15:30:07.937	error	Failed to open the network: Error: --> 'SREQ: AF - dataRequestExt - {"dstaddrmode":2,"dstaddr":"0x000000000000fffd","destendpoint":242,"dstpanid":0,"srcendpoint":242,"clusterid":33,"transid":1,"options":0,"radius":30,"len":6,"data":{"type":"Buffer","data":[25,2,2,10,0,0]}}' failed with status '(0x11: BUFFER_FULL)' (expected '(0x00: SUCCESS)') at /opt/iobroker/node_modules/zigbee-herdsman/src/adapter/z-stack/znp/znp.ts:258:27 at processTicksAndRejections (node:internal/process/task_queues:95:5) at Queue.execute (/opt/iobroker/node_modules/zigbee-herdsman/src/utils/queue.ts:36:20) at ZStackAdapter.dataRequestExtended (/opt/iobroker/node_modules/zigbee-herdsman/src/adapter/z-stack/adapter/zStackAdapter.ts:1100:9) at /opt/iobroker/node_modules/zigbee-herdsman/src/adapter/z-stack/adapter/zStackAdapter.ts:746:13 at Queue.execute (/opt/iobroker/node_modules/zigbee-herdsman/src/utils/queue.ts:36:20) at ZStackAdapter.sendZclFrameToAll (/opt/iobroker/node_modules/zigbee-herdsman/src/adapter/z-stack/adapter/zStackAdapter.ts:744:16) at GreenPower.permitJoin (/opt/iobroker/node_modules/zigbee-herdsman/src/controller/greenPower.ts:277:13) at Controller.permitJoin (/opt/iobroker/node_modules/zigbee-herdsman/src/controller/controller.ts:317:13) at ZigbeeController.permitJoin (/opt/iobroker/node_modules/iobroker.zigbee/lib/zigbeecontroller.js:668:13)