UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[ccbuddy]

@Thomas-Braun, da hast Du einen Punkt. Aber ich denke, wenn /dev/ttyUSB0 in diesem Moment richtig ist, sollte es keine Unterschied machen bzgl. des genannten Problems

[ccbuddy]

was hat es denn mit dem nvbackup.json zu tun?
Das klingt ja schon wie ein Speicher im Stick

[Thomas Braun]

@ccbuddy sagte in [Zigbee] Empfangen geht; Senden geht nicht:

in diesem Moment richtig ist

Stell es halt richtig, dann ist es auch in späteren Momenten richtig.

[ccbuddy]

die Serial Port Einstellung ist schon erledigt

Meine Frage bleibt aber immer noch, warum das Senden von Zigbee nicht geht.

Könnte das mit dem nvram zu zu tun haben?

Kann man das nvbackup.json löschen ohne alle Geräte neu pairen zu müssen?

[Thomas Braun]

@ccbuddy

Schau in die entsprechenden Logs.

[Asgothian]

@ccbuddy sagte in [Zigbee] Empfangen geht; Senden geht nicht:

die Serial Port Einstellung ist schon erledigt

Meine Frage bleibt aber immer noch, warum das Senden von Zigbee nicht geht.

Könnte das mit dem nvram zu zu tun haben?

Nein, da der Empfang geht

Kann man das nvbackup.json löschen ohne alle Geräte neu pairen zu müssen?
Nur bei veralteten Koordinatoren (cc2531)

Frage: bekommst du Meldungen im Log wenn du versuchst etwas zu steuern und es geht nicht ?

A.

[ccbuddy]

es kommen keine Fehlermeldungen beim Senden. Alle sieht relativ normal aus

[Asgothian]

@ccbuddy Bitte versuch das folgende:

• Adapter anhalten
• Aktuelle Version des Adapters von Github installieren
• Adapter starten
• Ein Gerät des Adapters auswählen, und seine ID (16-stellige Hex zahl) in den Datenpunkt zigbee.0.info.debugmessages eintragen
• versuchen das Gerät zu schalten
• Im log nach Warn-Meldungen mit dem Schlüsselwort 'ELEVATED' schauen - diese hier posten (als text, in code tags, und mit Kontext (was du getan hast um die Meldung zu bekommen)

[ccbuddy]

gute Idee mit dem Trace eines Devices. Kommt morgen, wenn ich vor Ort bin

Noch eine kleine Auffälligkeit: Wenn ich auf Pairing gehe, kommt normalerweise der Countdown; in dem Fehlerfall, kommt auch dieser Countdown nicht. Ein testweise Pairing findet das Gerät aber. Es lässt sich danach aber auch nicht schalten.
Ich weiß nicht ob es hilfreich ist, ist mir aber noch so aufgefallen

[Ritter]

@ccbuddy Hallo, Version 1.10.3 installieren, dann könnte es wieder gehen.

[ccbuddy]

downgrade? Ich habe die 1.10.15 drauf.
Denkst Du das hilft gegen das Countdown Problem oder auch gegen das Nicht-Senden Problem.

Das Seltsame ist ja, dass es vorher Monate lang ohne Probleme funktioniert hat

[Ritter]

@ccbuddy Ich habe genau das gleiche Verhalten.

[Asgothian]

@ritter sagte in [Zigbee] Empfangen geht; Senden geht nicht:

@ccbuddy Ich habe genau das gleiche Verhalten.

Nach aussage von @ccbuddy hast du das nicht:

• es geht zwischendurch - ohne das es einen erkennbaren Grund gibt
• das Pairing geht prinzipiell - nur ohne countdown

A.

[ccbuddy]

Hier ist der Output, wenn ich eine Lidl Steckdose ein und auszuschalten versuche in dem Fall, dass ich sie nicht ansteuern kann. Ganz oben kam noch eine Statusmeldung; leider habe ich kein Log aus dem Moment, wenn ich den Schalter an der Steckdose drücke

ELEVATED I0: Zigbee Event of Type attributeReport from device "0xa4c138d620daf73a", incoming event: {"type":"attributeReport","device":"0xa4c138d620daf73a","endpoint":1,"data":{"65506":53,"65508":0,"appVersion":68},"linkquality":108,"groupID":0,"cluster":"genBasic"}

ELEVATED O4: convert state, "ON", {} for device 0xa4c138d620daf73a with Endpoint state
ELEVATED O4.1: Setting' converter to converter with key(s)'["state","on_time","off_wait_time"]}
ELEVATED O03: Publishing to 0xa4c138d620daf73a of model HG08673
ELEVATED O02: Change state 'state' at device 0xa4c138d620daf73a type 'HG08673'
ELEVATED O01: User state change of state zigbee.0.a4c138d620daf73a.state with value true (ack: false) from system.adapter.admin.0

ELEVATED O4: convert state, "OFF", {} for device 0xa4c138d620daf73a with Endpoint state
ELEVATED O4.1: Setting' converter to converter with key(s)'["state","on_time","off_wait_time"]}
ELEVATED O03: Publishing to 0xa4c138d620daf73a of model HG08673
ELEVATED O02: Change state 'state' at device 0xa4c138d620daf73a type 'HG08673'
ELEVATED O01: User state change of state zigbee.0.a4c138d620daf73a.state with value false (ack: false) from system.adapter.javascript.0

Meine Vermutung des Fehlers liegt schon fast auf der Funkstrecke. Der Stick ist genau an der gleichen Position platziert wie schon lange auch ein Umbau und Neuaufbau am Schreibtisch hat nichts gebracht.
Ggf. ist auch die Sendeeinrichtung im Stick defekt

Ich organisiere mir mal einen Ersatzstick und probiere es damit
Kann ich einen neuen Stick einfach einstecken und er wird für mein Zigbee Netzwerk konfiguriert? (aus den nvbackup?)
oder muss ich etwas manuell machen?

[Asgothian]

@ccbuddy sagte in [Zigbee] Empfangen geht; Senden geht nicht:

Ich organisiere mir mal einen Ersatzstick und probiere es damit
Kann ich einen neuen Stick einfach einstecken und er wird für mein Zigbee Netzwerk konfiguriert? (aus den nvbackup?)
oder muss ich etwas manuell machen?

Das sollte einfach so gehen. Nur die serielle Schnittstelle muss angepasst werden.
Die Tatsache das die Meldungen O4.1 und O4 kommen deutet darauf hin das das System die Nachrichten durchaus schickt. Es ist aber trotzdemauffällig das die Ende-Mitteilung halt nicht kommt - am Ende müsste eine Meldung kommen das erfolgreich verschickt wurde. Hier ist also etwas nicht ganz koscher.

Eine Ursache in der Funkstrecke ist durchaus denkbar. Hat sich durch den Stromausfall an der Belastung der Funknetze etwas geändert ?

A.

[ccbuddy]

Kurzer Update
alles möglich Probieren mit anderen Verlängerungskabel auch mit einem USB Hub dazwischen hat keine Änderung gebracht.

Erst ein strammes Klopfen des Sonoff Sticks gegen die Wand hat es plötzlich zum Spielen gebracht

nun kommen auch die Input Messages:

zigbee.0
2025-02-05 20:07:42.726	warn	ELEVATED I1: message received '{"linkquality":132}' from device a4c1382d7bb4ba2d type 'HG08673'

zigbee.0
2025-02-05 20:07:42.714	warn	ELEVATED O05: convert result {"state":{"state":"OFF"}} sent to device 0xa4c1382d7bb4ba2d

zigbee.0
2025-02-05 20:07:42.713	warn	ELEVATED I0: Zigbee Event of Type attributeReport from device "0xa4c1382d7bb4ba2d", incoming event: {"type":"attributeReport","device":"0xa4c1382d7bb4ba2d","endpoint":1,"data":{"onOff":0},"linkquality":132,"groupID":0,"cluster":"genOnOff"}

zigbee.0
2025-02-05 20:07:42.712	warn	ELEVATED I0: Zigbee Event of Type attributeReport from device "0xa4c1382d7bb4ba2d", incoming event: {"type":"attributeReport","device":"0xa4c1382d7bb4ba2d","endpoint":1,"data":{"onOff":0},"linkquality":132,"groupID":0,"cluster":"genOnOff"}

zigbee.0
2025-02-05 20:07:42.710	warn	ELEVATED I0: Zigbee Event of Type attributeReport from device "0xa4c1382d7bb4ba2d", incoming event: {"type":"attributeReport","device":"0xa4c1382d7bb4ba2d","endpoint":1,"data":{"onOff":0},"linkquality":132,"groupID":0,"cluster":"genOnOff"}

zigbee.0
2025-02-05 20:07:42.657	warn	ELEVATED O4: convert state, "OFF", {} for device 0xa4c1382d7bb4ba2d with Endpoint state

zigbee.0
2025-02-05 20:07:42.656	warn	ELEVATED O4.1: Setting' converter to converter with key(s)'["state","on_time","off_wait_time"]}

zigbee.0
2025-02-05 20:07:42.656	warn	ELEVATED O03: Publishing to 0xa4c1382d7bb4ba2d of model HG08673

zigbee.0
2025-02-05 20:07:42.652	warn	ELEVATED O02: Change state 'state' at device 0xa4c1382d7bb4ba2d type 'HG08673'

zigbee.0
2025-02-05 20:07:42.605	warn	ELEVATED O01: User state change of state zigbee.0.a4c1382d7bb4ba2d.state with value false (ack: false) from system.adapter.web.0

nach dem Sendes des OFF Kommandos

naja, sieht sehr stark nach einem Wackler im Stick aus, der wohl für lange Zeit unauffällig blieb und erst durch das Ausbauen der SD Karte nach dem Stromausfall zur Geltung kam.

Morgen bekomme ich den Ersatzstick geliefert; dann wir es nochmal spannend...

[ccbuddy]

so, neuer Stick ist eingetroffen. Port entsprechend angepasst und eingesteckt.
Erst mal wird er erkannt und nach einiger Zeit konnte ich auch wieder die Zustände empfangen

ABER, zunächst wieder das gleiche Problem wie vorher. Ich kann nichts senden.

Erst wieder nach einigem Herumspielen geht es wieder.

Jetzt bleibt m. E. nur noch die Funkverbindung. da vielleicht der Stick in irgendeiner glücklichen Lage ist.
Wenn es aber mal geht, dann schaut es auch relativ stabil aus. Erst nach einem Neueinstecken und Neustart geht das Problem wieder los.

Ich habe zwar einen Zigbee Sniffer Stick mal eingerichtet, aber das wird ein bisschen Aufwand mit dem auf die Suche zu gehen, da mein Raspi+Sender Stick im Keller ist und ich dort den Sniffer nicht so einfach hinbekomme.

Hat noch jemand eine kluge Idee was hier faul sein könnte?

[ccbuddy]

@ccbuddy Nochmal ein Update.
Ich habe nun fast alles durchprobiert; Stromversorgung, Kabel; neuer Stick, alle strombetriebenen Geräte für 10min ausgeschaltet.
Auch ein vereinfachter Aufbau des Raspi und nur des Zigbee Sticks am Schreibtisch bringt keine Änderung

Auch ein paralleler Zigbee Sniffer zeigt, dass es keine Aktion auf der Funkstrecke gibt, wenn ich versuche eine Steckdose zu schalten

Während dieser zeit ist es aber immer möglich den Status aller Zigbee Geräte, und eben auch dieser einen Steckdose wenn ich dort am Knopf drücke, im iobroker zu sehen
Die Reports sind alle im Sniffer zu sehen

[ccbuddy]

gibt es evtl. ein Logging welches zeigt, dass Daten zum Senden über Zigbee auf den UART geschrieben werden?
Ich könnte mir auch mal den Source Code anschauen; ein kleiner Hinweis wo dies zu finden wäre, könnte hilfreich sein

[ccbuddy]

@Ritter , @Asgothian
Da ist schon was dran mit der 1.10.3. Wenn ich ein komplettes iobroker backup zurückspiele, geht alles komplett wieder. Auch der Countdown beim Pairing ist wieder da.

Mache ich dann wieder einen Update auf 1.10.14, geht alles beim ersten Starten. Danach habe ich testweise den Stick abgezogen und das Problem war wieder da

Also muss irgendwetwas in meiner Konfiguration sein, was nicht mit der aktuellen 1.10.14 harmoniert

Ich hab emir den Source Code angeschaut

try {
          if (permitTime && !this.herdsman.getPermitJoin()) {
              clearInterval(this._permitJoinInterval);
              this._permitJoinTime = permitTime;
              await this.herdsman.permitJoin(true, permitDev, this._permitJoinTime);
              this._permitJoinInterval = setInterval(async () => {
                  this.emit('pairing', 'Pairing time left', this._permitJoinTime);
                  if (this._permitJoinTime === 0) {
                      this.info('Zigbee: stop joining');
                      clearInterval(this._permitJoinInterval);
                      await this.herdsman.permitJoin(false);
                  }
                  this._permitJoinTime -= 1;
              }, 1000);

so wie ich es einschätzen würde, kehrt er aus permitJoin() nicht zurück. Es könnte sich etwas im herdsman verklemmt haben, was auch dazu führt, dass keine Steuerkommandos mehr rausgehen

Im Detail kenn ich mich darin nicht aus. Falls Ihr aber Loggings zum Nachstellen braucht, könnte ich den Fall nochmal versuchen zu provozieren