NEWS
Zigbee Geräte schalten verzögert
-
Steige hier mal mit ein :(
Seit ich vom cc2531 umgestiegen bin auf CC2538+CC2592 (weil ich mir vom NUC im Keller damit bessere Verbindungen erhoffte) habe ich auch dieses Problem.Netz: einige (keine 10) Osram Plugs: zwei davon nur als "repeater" verteilt, zwei andere wirklich "in use"; weitere ausgestöpselt im Keller, werden dann bspw. zu Xmas wieder aktiviert, sind aber "angelernt"; und drei Osram Leuchtmittel, eine Osram Surface light. That's it.
Hardware: Core-i5-8259U NUC mit 4(8) Kernen und 32GB RAM, darauf Proxmox.
Load Average 1.0x; ~18/32GB RAM durch System und 3 VMs belegt.
=> "Nicht viel los auf der Kiste"PVE-VM für den IOB: Ubuntu 18.04.4 Server, 2 Kerne, 4GB RAM => CPU-Auslastung ~="0,2%"; 0.8/4GB RAM, "Load Average 0.02". 12GB "Platte", davon ~10GB belegt.
=> "Auch nix los", ausreichend Reserven denke ichAus dem Log beim (Neu)Start der Adapter-Instanz:
Coordinator firmware version: {"type":"zStack30x","meta":{"transportrev":2,"product":2,"majorrel":2,"minorrel":7,"maintrel":2,"revision":20200211}} Version 1.3.0 in /opt/iobroker/node_modules/iobroker.zigbee, node: v14.6.0, js-controller: 3.1.6Gedanke 1: Vermisste Plugs => tote Pings?
Kann es an den "nicht erreichbaren" (offline, weg gepackt) Plugs liegen? Er versucht die ja zu pingen, erreicht sie aber nie.
Andererseits scheint er im Log auch nicht bei einem Ping 10sek zu hängen, denn die Meldungen der Art
"Error: Command 0x84182600000c8d2e/3 genOnOff.off({}, {"timeout":10000,"disableResponse":false,...."
erscheinen "mitten drin" im Log, und es hängt davor nicht 10sek. Teils kommen dann auch 5 davon direkt nacheinander, aber da hat er davor keine 50sek gehangen.Gedanke 2: Fehler im Log
Ansonsten habe ich im Log immer wieder sowas:2020-11-19 21:50:45.897 error at fulfilled (/opt/iobroker/node_modules/zigbee-herdsman/dist/adapter/z-stack/adapter/zStackAdapter.js:24:58) 2020-11-19 21:50:45.897 error at Generator.next (<anonymous>) 2020-11-19 21:50:45.897 error at ZStackAdapter.<anonymous> (/opt/iobroker/node_modules/zigbee-herdsman/dist/adapter/z-stack/adapter/zStackAdapter.js:319:27) 2020-11-19 21:50:45.897 error (1148) Error on send command to 0x7cb03eaa00ac3a41. Error: Error: Command 0x7cb03eaa00ac3a41/3 genOnOff.on({}, {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse 2020-11-19 21:50:34.346 error at fulfilled (/opt/iobroker/node_modules/zigbee-herdsman/dist/adapter/z-stack/adapter/zStackAdapter.js:24:58) 2020-11-19 21:50:34.346 error at Generator.next (<anonymous>) 2020-11-19 21:50:34.346 error at ZStackAdapter.<anonymous> (/opt/iobroker/node_modules/zigbee-herdsman/dist/adapter/z-stack/adapter/zStackAdapter.js:319:27) 2020-11-19 21:50:34.346 error (1148) Error on send command to 0x84182600000d877e. Error: Error: Command 0x84182600000d877e/3 genOnOff.on({}, {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponseund sowas
2020-11-19 22:03:46.870 error (7838) No state available for 'AB3257001NJ' with key 'link_quality'
wobei ich denke, dass gehört zu den "Pings" die ins Leere laufen, weil die Plugs im Keller rumliegen. Hier wäre es ja toll wenn er neben dem Gerätetyp auch die "stumme" Adresse ausgäbe, dann wüsste man, welchen Plug er da vermisst hat.Gedanke 3: habe heute keinen mehr.
N8 :)@fiddle wenn du Router(hier Plugs) aus dem neutz nimmst ist das immer ein Problem...
die die nicht gebraucht werden sollten am besten wieder gelöscht werden..sonst versucht der Coordinator diese zu erreichen ..immer wieder ..
-
@fiddle wenn du Router(hier Plugs) aus dem neutz nimmst ist das immer ein Problem...
die die nicht gebraucht werden sollten am besten wieder gelöscht werden..sonst versucht der Coordinator diese zu erreichen ..immer wieder ..
Danke für die Antwort arteck.
Habe jetzt alle Plugs in der Instanz "hart" gelöscht ("vergessene Geräte").
Die Leuchtmittel und die SurfaceLight schalten wir über die Wandschalter wie normale Birnen. Nur wenn wir länger nicht da sind schalten wir sie an und lassen den broki eine Anwesenheitssimulation mit ihnen machen. Will sagen: die sind also auch nur "unregelmäßig" im Netzwerk, mal lang, mal kurz. Aber die sind soweit ich weiß nur "Clients", keine "Repeater" oder "Router", das können nur die Plugs (und die Surface-Light denke ich, aber die ist maximal weit vom Coordinator weg, sollte also eher nicht den "Router" bilden, der andere versorgt.Signalstärke... hat jemand einen Screenshot von einem CC2538+CC2592 mit externer Antenne und einem Osram Plug in ~2m Entfernung? Was sollte man da für eine LQ haben? Ich hab' da sowas wie "18/40" als Wert. Hat mein Stick einen "weg"? Habe eine ~20cm Antenne dran, die ich vorher auch am 2531 hatte. Da waren die Werte nie viel besser... da vielleicht ein Problem?
Mal beobachten...
-
Danke für die Antwort arteck.
Habe jetzt alle Plugs in der Instanz "hart" gelöscht ("vergessene Geräte").
Die Leuchtmittel und die SurfaceLight schalten wir über die Wandschalter wie normale Birnen. Nur wenn wir länger nicht da sind schalten wir sie an und lassen den broki eine Anwesenheitssimulation mit ihnen machen. Will sagen: die sind also auch nur "unregelmäßig" im Netzwerk, mal lang, mal kurz. Aber die sind soweit ich weiß nur "Clients", keine "Repeater" oder "Router", das können nur die Plugs (und die Surface-Light denke ich, aber die ist maximal weit vom Coordinator weg, sollte also eher nicht den "Router" bilden, der andere versorgt.Signalstärke... hat jemand einen Screenshot von einem CC2538+CC2592 mit externer Antenne und einem Osram Plug in ~2m Entfernung? Was sollte man da für eine LQ haben? Ich hab' da sowas wie "18/40" als Wert. Hat mein Stick einen "weg"? Habe eine ~20cm Antenne dran, die ich vorher auch am 2531 hatte. Da waren die Werte nie viel besser... da vielleicht ein Problem?
Mal beobachten...
@fiddle sagte in Zigbee Geräte schalten verzögert:
Die Leuchtmittel und die SurfaceLight schalten wir über die Wandschalter wie normale Birnen. Nur wenn wir länger nicht da sind schalten wir sie an und lassen den broki eine Anwesenheitssimulation mit ihnen machen. Will sagen: die sind also auch nur "unregelmäßig" im Netzwerk, mal lang, mal kurz. Aber die sind soweit ich weiß nur "Clients", keine "Repeater" oder "Router", das können nur die Plugs (und die Surface-Light denke ich, aber die ist maximal weit vom Coordinator weg, sollte also eher nicht den "Router" bilden, der andere versorgt.
Das ist nicht korrekt. Du musst davon ausgehen das jedes Gerät welches fest am Strom ist als Router fungiert. Du kannst das auch im ioBroker sehen:
Wenn du bei einem Gerät im Adapter auf das blaue "i" gehst, dann bekommst du die Geräteinformation. Wenn da "type: router" steht dann Routen die Lampen.
Generell gilt:
Das Zigbee Netz kann es nicht gut ab wenn ständig umorganisiert wird, sprich wenn Geräte die eigentlich da sein sollen für längere Zeit abwesend sind. Das dann Auffälligkeiten auftreten, insbesondere verzögertes Schalten und ggf. vergessene Endgeräte (batteriebetrieben) ist da nicht verwunderlich.A.
-
@fiddle sagte in Zigbee Geräte schalten verzögert:
Die Leuchtmittel und die SurfaceLight schalten wir über die Wandschalter wie normale Birnen. Nur wenn wir länger nicht da sind schalten wir sie an und lassen den broki eine Anwesenheitssimulation mit ihnen machen. Will sagen: die sind also auch nur "unregelmäßig" im Netzwerk, mal lang, mal kurz. Aber die sind soweit ich weiß nur "Clients", keine "Repeater" oder "Router", das können nur die Plugs (und die Surface-Light denke ich, aber die ist maximal weit vom Coordinator weg, sollte also eher nicht den "Router" bilden, der andere versorgt.
Das ist nicht korrekt. Du musst davon ausgehen das jedes Gerät welches fest am Strom ist als Router fungiert. Du kannst das auch im ioBroker sehen:
Wenn du bei einem Gerät im Adapter auf das blaue "i" gehst, dann bekommst du die Geräteinformation. Wenn da "type: router" steht dann Routen die Lampen.
Generell gilt:
Das Zigbee Netz kann es nicht gut ab wenn ständig umorganisiert wird, sprich wenn Geräte die eigentlich da sein sollen für längere Zeit abwesend sind. Das dann Auffälligkeiten auftreten, insbesondere verzögertes Schalten und ggf. vergessene Endgeräte (batteriebetrieben) ist da nicht verwunderlich.A.
Danke, das wusste ich nicht, das "i" habe ich glaube ich noch nie genutzt, "lief ja alles" (zumindest waren diese "Lags" nie so gewaltig). Stimmt, tatsächlich sind auch die Osram LM und die SL wie auch alle Plugs "Router". Mhhh, doof. Ich will die Schalter nicht alle rauswerfen und dort Zigbee-Taster einbauen. Wäre ja hilfreich, wenn man da irgendwie eingreifen könnte... Firmware hacken, "Router" Eigenschaft ersetzen, die Bulbs "dumm" machen... hat vermutlich noch keiner "gewollt" außer mir :-)
Kann man das Netzwerk irgendwie beeinflussen damit es "regelmäßig" lernt? Mit node red was bauen, damit er alle 10 min oder so alle abfragt ohne dabei zu hängen, damit er immer "aktuell" weiß, wer überhaupt erreichbar ist? Oder dem Coordinator eine "Default first hob strategy" vorgeben? Würde ja in meinem (und vermutlich vielen anderen Fällen auch) funktionieren. Es ist bei mir eigentlich immer ein bestimmter Plug, der dann verteilt, und der hat stärkere Links zu seinen Brüdern als der Coordinator. Also "Wirf's zu Plug 1, der macht immer den Rest". Die Devices kann man dann natürlich nicht "belehren", aber zumindest würde der Coord. nicht versuchen am ersten Plug vorbei einen schlechteren Link zu nutzen. ... (macht vermutlich alles keinen Sinn ;-) )...
-
Danke, das wusste ich nicht, das "i" habe ich glaube ich noch nie genutzt, "lief ja alles" (zumindest waren diese "Lags" nie so gewaltig). Stimmt, tatsächlich sind auch die Osram LM und die SL wie auch alle Plugs "Router". Mhhh, doof. Ich will die Schalter nicht alle rauswerfen und dort Zigbee-Taster einbauen. Wäre ja hilfreich, wenn man da irgendwie eingreifen könnte... Firmware hacken, "Router" Eigenschaft ersetzen, die Bulbs "dumm" machen... hat vermutlich noch keiner "gewollt" außer mir :-)
Kann man das Netzwerk irgendwie beeinflussen damit es "regelmäßig" lernt? Mit node red was bauen, damit er alle 10 min oder so alle abfragt ohne dabei zu hängen, damit er immer "aktuell" weiß, wer überhaupt erreichbar ist? Oder dem Coordinator eine "Default first hob strategy" vorgeben? Würde ja in meinem (und vermutlich vielen anderen Fällen auch) funktionieren. Es ist bei mir eigentlich immer ein bestimmter Plug, der dann verteilt, und der hat stärkere Links zu seinen Brüdern als der Coordinator. Also "Wirf's zu Plug 1, der macht immer den Rest". Die Devices kann man dann natürlich nicht "belehren", aber zumindest würde der Coord. nicht versuchen am ersten Plug vorbei einen schlechteren Link zu nutzen. ... (macht vermutlich alles keinen Sinn ;-) )...
(Wie) Kann man die Signalstärken (die in der NW-Karte angezeigt werden) "loggen"? Die steckt in den Logs, klar, bspw. <"linkquality":28>, aber die Zeilen, in denen das steckt, sind "Monster". Bin kein Experte in "sed" um das mal eben jeweils mit der ID der Geräte "auszuschneiden" aus 50.000 Zeilen in 24 Stunden :) Gibt's da was? Ich hab' das Gefühl, dass er nach einer gewissen Zeit "schwach wird", das würde ich gern mal "beobachten".
-
(Wie) Kann man die Signalstärken (die in der NW-Karte angezeigt werden) "loggen"? Die steckt in den Logs, klar, bspw. <"linkquality":28>, aber die Zeilen, in denen das steckt, sind "Monster". Bin kein Experte in "sed" um das mal eben jeweils mit der ID der Geräte "auszuschneiden" aus 50.000 Zeilen in 24 Stunden :) Gibt's da was? Ich hab' das Gefühl, dass er nach einer gewissen Zeit "schwach wird", das würde ich gern mal "beobachten".
@fiddle sagte in Zigbee Geräte schalten verzögert:
(Wie) Kann man die Signalstärken (die in der NW-Karte angezeigt werden) "loggen"? Die steckt in den Logs, klar, bspw. <"linkquality":28>, aber die Zeilen, in denen das steckt, sind "Monster". Bin kein Experte in "sed" um das mal eben jeweils mit der ID der Geräte "auszuschneiden" aus 50.000 Zeilen in 24 Stunden :) Gibt's da was? Ich hab' das Gefühl, dass er nach einer gewissen Zeit "schwach wird", das würde ich gern mal "beobachten".
ähm - "link_quality" im jeweiligen Geräteobjekt? :) da kannst du auch mit 3,5 Klicks ein Flot-Diagramm bauen...
-
@fiddle sagte in Zigbee Geräte schalten verzögert:
(Wie) Kann man die Signalstärken (die in der NW-Karte angezeigt werden) "loggen"? Die steckt in den Logs, klar, bspw. <"linkquality":28>, aber die Zeilen, in denen das steckt, sind "Monster". Bin kein Experte in "sed" um das mal eben jeweils mit der ID der Geräte "auszuschneiden" aus 50.000 Zeilen in 24 Stunden :) Gibt's da was? Ich hab' das Gefühl, dass er nach einer gewissen Zeit "schwach wird", das würde ich gern mal "beobachten".
ähm - "link_quality" im jeweiligen Geräteobjekt? :) da kannst du auch mit 3,5 Klicks ein Flot-Diagramm bauen...
-
Danke, das wusste ich nicht, das "i" habe ich glaube ich noch nie genutzt, "lief ja alles" (zumindest waren diese "Lags" nie so gewaltig). Stimmt, tatsächlich sind auch die Osram LM und die SL wie auch alle Plugs "Router". Mhhh, doof. Ich will die Schalter nicht alle rauswerfen und dort Zigbee-Taster einbauen. Wäre ja hilfreich, wenn man da irgendwie eingreifen könnte... Firmware hacken, "Router" Eigenschaft ersetzen, die Bulbs "dumm" machen... hat vermutlich noch keiner "gewollt" außer mir :-)
Kann man das Netzwerk irgendwie beeinflussen damit es "regelmäßig" lernt? Mit node red was bauen, damit er alle 10 min oder so alle abfragt ohne dabei zu hängen, damit er immer "aktuell" weiß, wer überhaupt erreichbar ist? Oder dem Coordinator eine "Default first hob strategy" vorgeben? Würde ja in meinem (und vermutlich vielen anderen Fällen auch) funktionieren. Es ist bei mir eigentlich immer ein bestimmter Plug, der dann verteilt, und der hat stärkere Links zu seinen Brüdern als der Coordinator. Also "Wirf's zu Plug 1, der macht immer den Rest". Die Devices kann man dann natürlich nicht "belehren", aber zumindest würde der Coord. nicht versuchen am ersten Plug vorbei einen schlechteren Link zu nutzen. ... (macht vermutlich alles keinen Sinn ;-) )...
@fiddle sagte in Zigbee Geräte schalten verzögert:
Danke, das wusste ich nicht, das "i" habe ich glaube ich noch nie genutzt, "lief ja alles" (zumindest waren diese "Lags" nie so gewaltig). Stimmt, tatsächlich sind auch die Osram LM und die SL wie auch alle Plugs "Router". Mhhh, doof. Ich will die Schalter nicht alle rauswerfen und dort Zigbee-Taster einbauen. Wäre ja hilfreich, wenn man da irgendwie eingreifen könnte... Firmware hacken, "Router" Eigenschaft ersetzen, die Bulbs "dumm" machen... hat vermutlich noch keiner "gewollt" außer mir :-)
Kann man das Netzwerk irgendwie beeinflussen damit es "regelmäßig" lernt? Mit node red was bauen, damit er alle 10 min oder so alle abfragt ohne dabei zu hängen, damit er immer "aktuell" weiß, wer überhaupt erreichbar ist? Oder dem Coordinator eine "Default first hob strategy" vorgeben? Würde ja in meinem (und vermutlich vielen anderen Fällen auch) funktionieren. Es ist bei mir eigentlich immer ein bestimmter Plug, der dann verteilt, und der hat stärkere Links zu seinen Brüdern als der Coordinator. Also "Wirf's zu Plug 1, der macht immer den Rest". Die Devices kann man dann natürlich nicht "belehren", aber zumindest würde der Coord. nicht versuchen am ersten Plug vorbei einen schlechteren Link zu nutzen. ... (macht vermutlich alles keinen Sinn ;-) )...
Vielleicht geht da was, aber:
- du musst eine eigene Firmware für den Zigbee-Koordinator schreiben
- Es ist fraglich ob damit alle Geräte arbeiten können, da sie Zigbee Konformes Verhalten erwarten
- Alternativ - Die Firmware der Birnen hacken. Die geben die Hersteller aber nicht heraus, und der Upload ist meines Wissens abgesichert.
Insgesamt gilt hat:
Das Zigbee Netz ist auf eigenständige Organisation und auf Ausfallsicherheit ausgelegt. Deswegen sind die Optionen da manuell einzugreifen gewusst begrenzt geblieben. Das was Du machst (bestimmte Geräte "nur ab und zu" per Zigbee zu Nutzen ist so nicht vorgesehen.
Es gibt aber eine Lösung die gehen kann:
- Du machst ein 2. Zigbee Netz auf
- Das Netz läuft auf einem anderen Kanal und mit anderer ID / PANID
- In diesem Netz sind nur die Leuchtmittel die du nur bei Abwesenheit nutzen willst.
Auf die Art stören diese Lampen dein restliches Netz nicht und sind aber bei längerer Abwesenheit (hoffentlich) verfügbar.
A.
-
@fiddle sagte in Zigbee Geräte schalten verzögert:
Danke, das wusste ich nicht, das "i" habe ich glaube ich noch nie genutzt, "lief ja alles" (zumindest waren diese "Lags" nie so gewaltig). Stimmt, tatsächlich sind auch die Osram LM und die SL wie auch alle Plugs "Router". Mhhh, doof. Ich will die Schalter nicht alle rauswerfen und dort Zigbee-Taster einbauen. Wäre ja hilfreich, wenn man da irgendwie eingreifen könnte... Firmware hacken, "Router" Eigenschaft ersetzen, die Bulbs "dumm" machen... hat vermutlich noch keiner "gewollt" außer mir :-)
Kann man das Netzwerk irgendwie beeinflussen damit es "regelmäßig" lernt? Mit node red was bauen, damit er alle 10 min oder so alle abfragt ohne dabei zu hängen, damit er immer "aktuell" weiß, wer überhaupt erreichbar ist? Oder dem Coordinator eine "Default first hob strategy" vorgeben? Würde ja in meinem (und vermutlich vielen anderen Fällen auch) funktionieren. Es ist bei mir eigentlich immer ein bestimmter Plug, der dann verteilt, und der hat stärkere Links zu seinen Brüdern als der Coordinator. Also "Wirf's zu Plug 1, der macht immer den Rest". Die Devices kann man dann natürlich nicht "belehren", aber zumindest würde der Coord. nicht versuchen am ersten Plug vorbei einen schlechteren Link zu nutzen. ... (macht vermutlich alles keinen Sinn ;-) )...
Vielleicht geht da was, aber:
- du musst eine eigene Firmware für den Zigbee-Koordinator schreiben
- Es ist fraglich ob damit alle Geräte arbeiten können, da sie Zigbee Konformes Verhalten erwarten
- Alternativ - Die Firmware der Birnen hacken. Die geben die Hersteller aber nicht heraus, und der Upload ist meines Wissens abgesichert.
Insgesamt gilt hat:
Das Zigbee Netz ist auf eigenständige Organisation und auf Ausfallsicherheit ausgelegt. Deswegen sind die Optionen da manuell einzugreifen gewusst begrenzt geblieben. Das was Du machst (bestimmte Geräte "nur ab und zu" per Zigbee zu Nutzen ist so nicht vorgesehen.
Es gibt aber eine Lösung die gehen kann:
- Du machst ein 2. Zigbee Netz auf
- Das Netz läuft auf einem anderen Kanal und mit anderer ID / PANID
- In diesem Netz sind nur die Leuchtmittel die du nur bei Abwesenheit nutzen willst.
Auf die Art stören diese Lampen dein restliches Netz nicht und sind aber bei längerer Abwesenheit (hoffentlich) verfügbar.
A.
@Asgothian danke für deine Antwort.
Wie ich mir dachte, deine Bullet Points 1 bis 3 sind (vermutlich mindestens wegen "abgesichert") "prohibitiv". Ich hack ja gern, aber das wird wohl am Ende nichts werden.
Die Idee mit dem 2. Netz ist gut! Geht aber nicht mit nur einem Coordinator, oder? Dann müsste ich den 2531 zusätzlich wieder anklemmen und eine 2. Instanz vom Adapter aufsetzen, richtig?
Jetzt beobachte ich erstmal die LQ... waren zwar ein paar mehr als 3,5 Klicks ;-) bis zum Diagramm, und schön ist anders, aber immerhin.
Zwischenstand, Werte werden alle ~5sek aufgezeichnet.
- Der "wichtige" Plug schwankt zwischen 25 und 45;
- Ein zweiter, zum Vergleich, der nur ~2m Luftlinie vom Stick weg ist, zwischen 5 und 25... und dann sprang er gegen 20:00 und ist seither zwischen 25 und 40 unterwegs.
- Die Werte springen ziemlich genau alle 2 Minuten. Seltsam. Das Zeug "hat Puls"...
- In der ganzen Zeit seit heute Nachmittag habe ich beide alle 180sek. per node red umschalten lassen, damit da "was los ist" auf'm Funk. Hab' ich jetzt abgeklemmt, mal sehen was sie über Nacht ohne Aktionen machen.
"Zickenbienenvolk" sag' ich immer...
Schönen Abend erstmal.
-
@Asgothian danke für deine Antwort.
Wie ich mir dachte, deine Bullet Points 1 bis 3 sind (vermutlich mindestens wegen "abgesichert") "prohibitiv". Ich hack ja gern, aber das wird wohl am Ende nichts werden.
Die Idee mit dem 2. Netz ist gut! Geht aber nicht mit nur einem Coordinator, oder? Dann müsste ich den 2531 zusätzlich wieder anklemmen und eine 2. Instanz vom Adapter aufsetzen, richtig?
Jetzt beobachte ich erstmal die LQ... waren zwar ein paar mehr als 3,5 Klicks ;-) bis zum Diagramm, und schön ist anders, aber immerhin.
Zwischenstand, Werte werden alle ~5sek aufgezeichnet.
- Der "wichtige" Plug schwankt zwischen 25 und 45;
- Ein zweiter, zum Vergleich, der nur ~2m Luftlinie vom Stick weg ist, zwischen 5 und 25... und dann sprang er gegen 20:00 und ist seither zwischen 25 und 40 unterwegs.
- Die Werte springen ziemlich genau alle 2 Minuten. Seltsam. Das Zeug "hat Puls"...
- In der ganzen Zeit seit heute Nachmittag habe ich beide alle 180sek. per node red umschalten lassen, damit da "was los ist" auf'm Funk. Hab' ich jetzt abgeklemmt, mal sehen was sie über Nacht ohne Aktionen machen.
"Zickenbienenvolk" sag' ich immer...
Schönen Abend erstmal.
Nachtrag: gerade nochmal das Log genauer betrachtet.
Mir scheint, dass er tatsächlich immer diese 10sek hängt wenn er ein Gerät nicht "pingen" kann. Habe immer wieder ziemlich genau 10sek Lücken im Log, davor pingt er einen Plug der gerade neben mir auf dem Tisch liegt. Hatte das vorhin wieder: über's dashboard zwei Plugs geschaltet, nichts passiert, mehrfach die Schalter im Dashboard hin und her... und nach ein paar Sekunden machten beide dann "klick-klack-klick-klack". Das im Log abgepasst - genau da "hing" das Log 10 sek, in denen hatte ich die Schalter im dashboard "hin und her geschubst". Kein Zufall würde ich sagen.
Wenn die "Hänger" also von fehlenden Geräten kommen... kann man den "timeout" von 10sek irgendwie auf 1 oder 2 sek runter setzen?
So, nu aber... Feierabend :)
-
Nachtrag: gerade nochmal das Log genauer betrachtet.
Mir scheint, dass er tatsächlich immer diese 10sek hängt wenn er ein Gerät nicht "pingen" kann. Habe immer wieder ziemlich genau 10sek Lücken im Log, davor pingt er einen Plug der gerade neben mir auf dem Tisch liegt. Hatte das vorhin wieder: über's dashboard zwei Plugs geschaltet, nichts passiert, mehrfach die Schalter im Dashboard hin und her... und nach ein paar Sekunden machten beide dann "klick-klack-klick-klack". Das im Log abgepasst - genau da "hing" das Log 10 sek, in denen hatte ich die Schalter im dashboard "hin und her geschubst". Kein Zufall würde ich sagen.
Wenn die "Hänger" also von fehlenden Geräten kommen... kann man den "timeout" von 10sek irgendwie auf 1 oder 2 sek runter setzen?
So, nu aber... Feierabend :)
@fiddle Jein
Der Timeout ist tief im Zigbee-Herdsman-converters vorgegeben.
Es ist denkbar in der Routine die die Geräte pingt das Absetzen und Erwarten der Pings voneinander zu trennen. Allerdings kann das unerwünschte Nebenwirkungen haben.
Ich schau mir das morgen einmal an.
A.
ioBroker auf RPi4 - Hardware soweit wie möglich via Zigbee.
"Shit don't work" ist keine Fehlermeldung, sondern ein Fluch. -
@fiddle Jein
Der Timeout ist tief im Zigbee-Herdsman-converters vorgegeben.
Es ist denkbar in der Routine die die Geräte pingt das Absetzen und Erwarten der Pings voneinander zu trennen. Allerdings kann das unerwünschte Nebenwirkungen haben.
Ich schau mir das morgen einmal an.
A.
@Asgothian said in Zigbee Geräte schalten verzögert:
Ich schau mir das morgen einmal an.
Hat deine Recherche was gebracht? Ich hab das Phänomen auch und mein zigbee Netz ist sehr übersichtlich (nur 7 Devices, davon ein CC2530 als Router).
Problem ist, dass ich mit IKEA Tradfri Fernbedienung Lampen (Sonoff und shelly Switches) steuern will. Mal geht es sofort, mal dauert es ewig bis geschaltet wird. Die sind auch an Alexa gekoppelt und da funktionierts ohne irgendwelche Probleme. Ich denke mal dass es mit Erreichbarkeitsproblemen (ping) zusammenhängen kann.iobroker auf proxmox container
-
@Asgothian said in Zigbee Geräte schalten verzögert:
Ich schau mir das morgen einmal an.
Hat deine Recherche was gebracht? Ich hab das Phänomen auch und mein zigbee Netz ist sehr übersichtlich (nur 7 Devices, davon ein CC2530 als Router).
Problem ist, dass ich mit IKEA Tradfri Fernbedienung Lampen (Sonoff und shelly Switches) steuern will. Mal geht es sofort, mal dauert es ewig bis geschaltet wird. Die sind auch an Alexa gekoppelt und da funktionierts ohne irgendwelche Probleme. Ich denke mal dass es mit Erreichbarkeitsproblemen (ping) zusammenhängen kann.@amg_666
Meine Recherche hat erbracht das das Ping zwar verzögert abgesetzt wird, dieses aber zeitlich nicht gekoppelt ist an das Absenden anderer Zigbee Befehle. Eine Entkoppelung ist denkbar, aber ich bin mir nicht Sicher wie sinnvoll das ist, da damit ggf. das Netz mit Meldungen zugeworfen wird.A.
-
@amg_666
Meine Recherche hat erbracht das das Ping zwar verzögert abgesetzt wird, dieses aber zeitlich nicht gekoppelt ist an das Absenden anderer Zigbee Befehle. Eine Entkoppelung ist denkbar, aber ich bin mir nicht Sicher wie sinnvoll das ist, da damit ggf. das Netz mit Meldungen zugeworfen wird.A.
@Asgothian Danke für deine Mühe.
Wenn's also nicht wegen der Pings hakt, wie kommen wir der Ursache dann auf die Spur? Wenn ich Amg_666 richtig verstehe hat er ja keine "unregelmäßig abwesenden" Devices wie ich mit meinen per Wandschalter hart vom Strom getrennten Leuchtmitteln (sprich bei ihm sind alle eigentlich immer "an" /erreichbar) und dennoch hat er auch Hänger. -
@Asgothian Danke für deine Mühe.
Wenn's also nicht wegen der Pings hakt, wie kommen wir der Ursache dann auf die Spur? Wenn ich Amg_666 richtig verstehe hat er ja keine "unregelmäßig abwesenden" Devices wie ich mit meinen per Wandschalter hart vom Strom getrennten Leuchtmitteln (sprich bei ihm sind alle eigentlich immer "an" /erreichbar) und dennoch hat er auch Hänger. -
Gibt es hier vielleicht schon ein paar neue Erkenntnisse?
Ich werde aktuell auch vom verzögerten Schalten geplagt. Es wird aber auch nichts ins Log geschrieben.
Teilweise sind die Verzögerungen bis zu 30 Sekunden. Irgendwie habe ich die Vermutung, dass dies durch "Alexa" ausgelöst werden. Wenn aber durch Alexa nicht geschaltet wird, dann kann ich auch direkt über iobroker nicht schalten.
Nachdem der "Knoten" gelöst ist, werden dann alle bis dahin getätigten Schaltvorgänge abgearbeitet und es ist für einen kurzen Moment Party im Raum. -
Gibt es hier vielleicht schon ein paar neue Erkenntnisse?
Ich werde aktuell auch vom verzögerten Schalten geplagt. Es wird aber auch nichts ins Log geschrieben.
Teilweise sind die Verzögerungen bis zu 30 Sekunden. Irgendwie habe ich die Vermutung, dass dies durch "Alexa" ausgelöst werden. Wenn aber durch Alexa nicht geschaltet wird, dann kann ich auch direkt über iobroker nicht schalten.
Nachdem der "Knoten" gelöst ist, werden dann alle bis dahin getätigten Schaltvorgänge abgearbeitet und es ist für einen kurzen Moment Party im Raum. -
@Asgothian
Vielen Dank für die schnelle Antwort.
Seltsam ist es, dass es nicht immer auftritt. Was auch seltsam ist, dass diesmal nichts im Log steht.
Könnte ich denn noch irgendwie zur Lösung des Problem beitragen?Je nach dem wie häufig es auftritt könntest Du den Adapter im Debug laufen lassen, incl. zigbee-herdsman-debug Info, um dann wenn es passiert die vorhandenen Nachrichten aneinander setzen zu können.
Allerdings macht das nur in einem bestimmten Szenario Sinn. Um da genauer schauen zu können benötige ich
- ein Log von einer Schaltsituation die sauber gelaufen ist
- ein Log von einer Verzögerten Schaltsituation.
Wichtig ist dabei das die beiden Situationen soweit wie möglich identisch sein müssen, sprich das die gleichen Leuchtmittel angesprochen werden.
A.
-
Je nach dem wie häufig es auftritt könntest Du den Adapter im Debug laufen lassen, incl. zigbee-herdsman-debug Info, um dann wenn es passiert die vorhandenen Nachrichten aneinander setzen zu können.
Allerdings macht das nur in einem bestimmten Szenario Sinn. Um da genauer schauen zu können benötige ich
- ein Log von einer Schaltsituation die sauber gelaufen ist
- ein Log von einer Verzögerten Schaltsituation.
Wichtig ist dabei das die beiden Situationen soweit wie möglich identisch sein müssen, sprich das die gleichen Leuchtmittel angesprochen werden.
A.
@Asgothian
Debug Ausgabe hatte ich wohl irgendwann wieder deaktiviert. Nun ist sie wieder aktiv und auch der zigbee-herdman-debug info. Hoffe ich bekomme da eine Diskrepanz raus.
Support us
688
Online32.7k
Benutzer82.4k
Themen1.3m
Beiträge