[Aufruf] ZigBee CC253x Adapter
-
hi,
ich häng mich mal hier ran.
Habe ebenfalls vom Raspberry zum Intel Nuc mit Proxmox gewechselt.
Bei mir funktioniert das durchreichen des cc2531 zig nur sporadisch. Mal geht es dann wieder nicht , dann geht es. Woran liegt das?
Wo ist das Problem?
Anbei mal ein Auszug von diversen Parametern:
ein lsusb vom Proxmos Server gibt:
root@pve:~# lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 8087:0a2b Intel Corp.
Bus 001 Device 004: ID 0451:16a8 Texas Instruments, Inc.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
ok, dann per gui aber auch per console usb stick durchgereicht, mit Befehl:
qm set 100 -usb0 host=0451:16a8 (die iobroker vm ist id 100)
so steht dann in der vm conf (100.conf) unter anderem folgende zeile
usb0: host=0451:16a8
auch gut, denke ich.
ein lsusb in der iobroker vm ergibt:
root@iobroker:/opt/iobroker/log# lsusb
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 002: ID 0451:16a8 Texas Instruments, Inc.
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 002: ID 0627:0001 Adomax Technology Co., Ltd
Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
auch hier der Texax Instrumment gelistet.
zuguter letzt ein Auszug aus iobroker log
2018-12-31 10:03:36.085 - info: zigbee.0 States connected to redis: 127.0.0.1:6379
2018-12-31 10:03:36.204 - info: zigbee.0 starting. Version 0.8.1-a in /opt/iobroker/node_modules/iobroker.zigbee, node: v8.15.0
2018-12-31 10:03:36.206 - info: zigbee.0 Start on port: /dev/ttyACM0 with panID 6754 channel 11
2018-12-31 10:04:39.245 - info: zigbee.0 Starting zigbee-shepherd
2018-12-31 10:04:42.256 - error: zigbee.0 Error while starting zigbee-shepherd!. Error: request timeout
wie gesagt, ab und zu geht es auch was ist hier los?
nachtrag,
ein usb-stick raus reinstecken scheint derzeit ein funktionierendes Workaround zu sein, danach gehts dann auch siehe log:
2018-12-31 10:26:35.897 - info: zigbee.0 Start on port: /dev/ttyACM0 with panID 6754 channel 11
2018-12-31 10:26:37.205 - info: zigbee.0 zigbee-shepherd started!
2018-12-31 10:26:37.209 - info: zigbee.0 zigbee-shepherd ready. version: 2.6.3 rev 20181024
gruss
-
hi,
ich häng mich mal hier ran.
Habe ebenfalls vom Raspberry zum Intel Nuc mit Proxmox gewechselt.
Bei mir funktioniert das durchreichen des cc2531 zig nur sporadisch. Mal geht es dann wieder nicht , dann geht es. Woran liegt das?
Wo ist das Problem?
Anbei mal ein Auszug von diversen Parametern:
ein lsusb vom Proxmos Server gibt:
root@pve:~# lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 8087:0a2b Intel Corp.
Bus 001 Device 004: ID 0451:16a8 Texas Instruments, Inc.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
! ok, dann per gui aber auch per console usb stick durchgereicht, mit Befehl:
! qm set 100 -usb0 host=0451:16a8 (die iobroker vm ist id 100)
! so steht dann in der vm conf (100.conf) unter anderem folgende zeile
! usb0: host=0451:16a8
! auch gut, denke ich.
! ein lsusb in der iobroker vm ergibt:
! root@iobroker:/opt/iobroker/log# lsusb
! Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
! Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
! Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
! Bus 003 Device 002: ID 0451:16a8 Texas Instruments, Inc.
! Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
! Bus 001 Device 002: ID 0627:0001 Adomax Technology Co., Ltd
! Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
! auch hier der Texax Instrumment gelistet.
! zuguter letzt ein Auszug aus iobroker log
! 2018-12-31 10:03:36.085 - info: zigbee.0 States connected to redis: 127.0.0.1:6379
! 2018-12-31 10:03:36.204 - info: zigbee.0 starting. Version 0.8.1-a in /opt/iobroker/node_modules/iobroker.zigbee, node: v8.15.0
! 2018-12-31 10:03:36.206 - info: zigbee.0 Start on port: /dev/ttyACM0 with panID 6754 channel 11
! 2018-12-31 10:04:39.245 - info: zigbee.0 Starting zigbee-shepherd
! 2018-12-31 10:04:42.256 - error: zigbee.0 Error while starting zigbee-shepherd!. Error: request timeout
! wie gesagt, ab und zu geht es auch was ist hier los?
! nachtrag,
! ein usb-stick raus reinstecken scheint derzeit ein funktionierendes Workaround zu sein, danach gehts dann auch siehe log:
! 2018-12-31 10:26:35.897 - info: zigbee.0 Start on port: /dev/ttyACM0 with panID 6754 channel 11
! 2018-12-31 10:26:37.205 - info: zigbee.0 zigbee-shepherd started!
! 2018-12-31 10:26:37.209 - info: zigbee.0 zigbee-shepherd ready. version: 2.6.3 rev 20181024gruss `
ich würde dich bitten einen neuen Thread aufzumachen… das hat nichts mit dem Adapter zu tun sonder mit der Hardware.. bzw Systemeinrichtung...das wird dann hier zu unübersichtilich
-
Ich hatte ja eigentlich vor meine Hue-Bridge abzuschalten und alles über den Zigbee-Stick zu realisieren,
aber gerade mit Osram-Lampen und dazu noch in Farbe funktioniert das alles nicht zuverlässig.
Hab daher mit dem aktuellen iobroker.zigbee, dem dev-zigbee und dem zigbee-Adapter von arteck (der
ein paar neue Geräte und ein paar Kleinigkeiten mehr hat) den Tag über experimentiert und es lief nicht wie gewünscht.
Mein Aufbau: 2 CC2530 (Coordinator und Router) sowie ein Osram Plug+ … pro Etage im Haus einer.
Xiaomi-Endgeräte (Kontalkte, Buttons, Temperatur) funktioniert alles. Der Plug auch.
Nur die Classic A60 RGBW und auch Surface Light TW und LED Stripe von Osram wollen einfach nicht so richtig gut mitspielen
in dem Orchester.
Jetzt zu den Problemen:
1.) Das die Fehlermeldung " No converter available for 'CC2530.ROUTER' with cid 'genOnOff' and type 'devChange'" auftritt ist war irgendwie blöd. aber nicht weiter wild .. das Rote irritiert nur, da es eher eine Warning ist, als ein Fehler ... wieso muß der Router auch nen State haben, den man eh nicht schalten kann???
2.) Egal ob mit Queue oder ohen Queue: Irgendwann erwischen einen die "No Ack"-Fehler:
Zigbee publish to '0x8418260000ca7660', genOnOff - on - {} - 3 failed with error Error: AF data request fails, status code: 233\. MAC no ack.oder auch gerne die "No network route Fehler"
Zigbee publish to '0x8418260000ca7660', genOnOff - off - {} - 3 failed with error Error: AF data request fails, status code: 205\. No network route. Please confirm that the device has (re)joined the network.Wobei der zweite Fehler ein Soda-Fehler ist .. der ist wohl nur "so da" … denn aussagekräftig ist der nicht gerade; da man nicht die Lampe vom Strom nehmen muß und wieder einstecken ... ist halt nur temporär mal nicht erreichbar.
Die beiden Fehler passieren vermehrt, wenn man die Queue nutzt. Dort insbesondere beim zweiten Publish.
Wie bei "puslishFromState" bei "mit Queue" 2 Publish an den Zigbee-Adapter sendet bleibt mir noch verborgen; denn dieser zweite Publish sorgt für die Fehler im Zigbee-Adapter, wodurch die Lampen dann auch nicht schalten oder halt temporär nicht erreichbar erscheinen.
Durch die 2 Zigbee-Publish soll wohl der Status zwischen ioBroker und Zigbee-Gerät synchronisiert werden; aber hier dauert es ca. 2-3 Sekunde im Netzwerk, bis der Befehl endgültig abgearbeitet ist.
3.) Die Lampen haben meisten einen "combinedState": Wenn Heilligekit auf 0 oder >0 gesetzt wird, dann wird der State auch auf "false" bzw. "true" geschaltet. Jedoch klappt das nur in ca. 60% der Fälle ... weil meist ein Fehler aus Punkt 2 dazwischen haut und dann die Helligkeit auf 0 ist und der state aber noch auf true, oder andersrum .. Helligkeit>0 aber State noch auf false. Manchmal auch einfach so nicht ...
Könnte man hier dem Zigbee-Adapter beibringen, daß bei 0 immer auch gleichzeit der "state" auf "false" gesetzt wird und andersrum? Anscheinend wird aktuell der State aber nur dann gesetzt, wenn die Antwort vom Zigbee-Stick mit Erfolg kam .. bei Fehler aus 2.) sind Helligkeit und state nicht mehr synchron.
4.) Bei Verwendung von "transition_time" kommt es zu dem Phänomen, daß die Helligkeit auf einmal andere Werte hat, als man eingestellt hat.
Angenommen die Helligkeit liegt bei 90 und man setzt sie auf 10, dann war nach ein paar Sekunden die Helligkeit auf einmal irgendwo zwischen 30 und 39 ... ich denke, daß hier die Osram-Lampe selber schon einen Event schickt, wenn sich die Helligkeit ändert,. aber noch bevor die Transition-Time wirklich zu Ende ist, sondern zwischen Anfang und Ende des Helligkeitsübergangs ... so daß es zu solchen Werten kommt.
Fazit also: Für einfache Endgeräte ist der Stick samt Zigbee-Adapter sehr gut zu gebrauchen.
Bei Lampen ist der Stick etwas träge und liefert des öfteren kein korrektes Ergebnis ... entweder hat mein Netzwerk ne lange Leitung oder
das asynchrone Verhalten von Antwort und Response ist nicht immer gleich.
Ich denke daß Zigbee-Light-Link (entweder über Osram-Hub oder Hue-Bridge) hier noch immer zuverlässiger funktioniert.
MfG Markus
-
mehr und mehr kotzen mich die Osram Devices an.. ich kann es nicht zuordnen ob es an der Hardeware oder der Firmware der Teile liegt..
ich hab auch die Bridge hier von Osram.. aber die läuft ja auch wie ein nasser sack.. verliert ständig die WLAN verbindung…
ich gebe dir recht irgendwas stimmt da nicht.. wobei mit der Queue solche Fehler nicht passieren sollten..da hier die Befehle hinterienander angereiht werden und eigentlich erst verschickt werden wenn der davorige Befehl bestätigt wurde.. was eben die Trägheit erklärt...
aber ..
die Osram Devices lassen sich zeit mit der Bestätigung.. und das wird das Problem sein. bei meinen Hue Lampen hatte ich noch nie solche Probleme
, genOnOff - on - {} - 3 failed with error Error: AF data request fails, status code: 233\. MAC no ack.das ein Devie nicht ereichbar ist.. kommt schon mal vor.. aber das hängt nicht mit dem Adapter sondern mit dem Device direkt.. wenn da was hängt ist halt nicht ereichbar.. passier immer nur bei der einen E14 von Osram..
ich wüsste jetzt auch nicht wie man das verhindern kann.. wenn die Dinger sich selbst aufhängen oder mal bissel länger Brauchen.. da kann man mache nix
-
Das Problem hab ich auch mit den E14 von Osram. Aber auch mit den gu10-wobei ich mir hier nicht sicher bin, ob es an der Fassung aus Aluminium bei der Lampe liegt…
Gesendet von meinem HUAWEI RIO-L01 mit Tapatalk
-
Lieber Arthur, was mir aufgefallen ist, mein zigbee Netz ist ja überschaubar wie du weißt. Ich habe jetzt einen weiteren Osram Plug eingebaut. Und wollte zwei Devices darauf anlernen. Habe dann über den neuen Plug die Anmeldefunktion genutzt aber dort keinerlei Rückmeldung bekommen, Fenster war auch länger als 60 Sekunden offen. Aber da kam einfach gar nichts. Dann habe ich über den grünen Button oben rechts angemeldet, sofort da und auch sauber erkannt UND dem Plug zugeordnet wo ich die Anmeldung zu erst durchführen wollte.
-
Lieber Arthur, was mir aufgefallen ist, mein zigbee Netz ist ja überschaubar wie du weißt. Ich habe jetzt einen weiteren Osram Plug eingebaut. Und wollte zwei Devices darauf anlernen. Habe dann über den neuen Plug die Anmeldefunktion genutzt aber dort keinerlei Rückmeldung bekommen, Fenster war auch länger als 60 Sekunden offen. Aber da kam einfach gar nichts. Dann habe ich über den grünen Button oben rechts angemeldet, sofort da und auch sauber erkannt UND dem Plug zugeordnet wo ich die Anmeldung zu erst durchführen wollte. `
Hallo Markus.. scheiss Technik sag ich dir… :lol: :lol:
-
Lieber Arthur, was mir aufgefallen ist, mein zigbee Netz ist ja überschaubar wie du weißt. Ich habe jetzt einen weiteren Osram Plug eingebaut. Und wollte zwei Devices darauf anlernen. Habe dann über den neuen Plug die Anmeldefunktion genutzt aber dort keinerlei Rückmeldung bekommen, Fenster war auch länger als 60 Sekunden offen. Aber da kam einfach gar nichts. Dann habe ich über den grünen Button oben rechts angemeldet, sofort da und auch sauber erkannt UND dem Plug zugeordnet wo ich die Anmeldung zu erst durchführen wollte.
Hallo Markus.. scheiss Technik sag ich dir… :lol: :lol:
MarCus mit C bitte, soviel Zeit muss sein :lol: :lol:Osram oder Adapter schuld? :lol:
-
ohh ohhh mit C ok..
da ich Hues ohne Probleme betreibe .. tipp ich auf die Osrams die sich nicht an den Standard halten
-
Mal eine Frage zu dem tollen Adapter. Leider geht hier bei den Xiaomi Tastern die Doppelklick oder longklick Funktion nicht. Ist es möglich diese „nachzurüsten“?
Gesendet von iPhone mit Tapatalk
-
ohh ohhh mit C ok..
da ich Hues ohne Probleme betreibe .. tipp ich auf die Osrams die sich nicht an den Standard halten `
Also der Anmeldevorgang einfach einmal am gewünschten Plug starten, dann beenden und am Zigbee Adapter anmelden = Anmeldung am gewünschten PlugHatte bei mir tatsächlich einen Sensor der nicht genug Link Quality hatte, daher hab ich den umgemeldet und nun läuft.
-
hier bei den Xiaomi Tastern `
ahhhhhhhhhhh bei den .. joain.. aber bei anderen gehts.. also
-
ohh ohhh mit C ok..
da ich Hues ohne Probleme betreibe .. tipp ich auf die Osrams die sich nicht an den Standard halten `
Also der Anmeldevorgang einfach einmal am gewünschten Plug starten, dann beenden und am Zigbee Adapter anmelden = Anmeldung am gewünschten PlugHatte bei mir tatsächlich einen Sensor der nicht genug Link Quality hatte, daher hab ich den umgemeldet und nun läuft. `
wartmal das heisst direkt am Plug gings nicht aber mit dem Umweg zuerst am Stick dann am Plug gings ??
-
ahhhhhhhhhhh bei den .. joain.. aber bei anderen gehts.. also `
Bedeutet, dass da es diese Funktion nicht geben wird?
-
ohh ohhh mit C ok..
da ich Hues ohne Probleme betreibe .. tipp ich auf die Osrams die sich nicht an den Standard halten `
Also der Anmeldevorgang einfach einmal am gewünschten Plug starten, dann beenden und am Zigbee Adapter anmelden = Anmeldung am gewünschten PlugHatte bei mir tatsächlich einen Sensor der nicht genug Link Quality hatte, daher hab ich den umgemeldet und nun läuft. `
wartmal das heisst direkt am Plug gings nicht aber mit dem Umweg zuerst am Stick dann am Plug gings ?? `
Also Reihenfolge wie es bei mir funktioniert hat:1. Anmeldevorgang am Wunsch-Plug gestartet (grünes Icon)
2. versucht den Sensor anzulernen (kein Erfolg)
3. Fenster vom Anmeldevorgang am Plug geschlossen
4. Anmeldevorgang am Stick (grünes Icon)
5. Sensor erfolgreich angemeldet
6. Fenster geschlossen
7. Sensoren benannt etc.
8. Sensor wurde dann dem Plug zugeordnet den ich zu erst ausgewählt hatte in Schritt 1.
Das Spiel kann ich wiederholen wie ich möchte, die gezielte Anmeldung (in Verbindung mit den Osram Dingern) funktioniert nur so in dieser Reihenfolge. Der Anlernvorgang scheint ins leere zu greifen wenn ich den Plug gezielt zur Anmeldung auswähle, da kommen gar keine Meldungen. Bei der Anmeldung über den Adapter sofort (auch bei flatschneuen Sensoren). Daher dachte ich das es vielleicht am Adapter liegen könnte das dort einfach keine Meldungen laufen oder die Funktion dort nicht arbeitet zum anlernen.
-
wie kann man denn das Device (Plug) gezielt zum Anlernen auswählen? Ich drücke immer oben rechts auf die grüne Schaltfläche bei der Instanz
-
wie kann man denn das Device (Plug) gezielt zum Anlernen auswählen? Ich drücke immer oben rechts auf die grüne Schaltfläche bei der Instanz `
ich musste anfangs auch erst suchen..
wenn du mal schaust, hat jedes gerät, welches als repeater dienen kann, auch solch ein grünes symbol.
einfach auf dieses statt auf dem oben rechts (welches für den usb stick / coordinator ist) klicken.
-
oh. Das hatte ich eher als eine Möglichkeit interpretiert, dieses Gerät gezielt noch einmal zu pairen
-
-
Er meint wohl den Xiaomi Aquara Button …
So kleines Kästchen, das allerdings nur single_click und double_click kann. Die anzeigten 3fach und 4fach-Clicks sind nutzlos,
da sie der Button wohl nicht unterstützt bzw. keine Reaktion zeigen ...
Und ein langer Klick geht da auch nicht ....
Listen and Repeat ...
@arteck:hier bei den Xiaomi Tastern `
ahhhhhhhhhhh bei den .. joain.. aber bei anderen gehts.. also `
MfG Markus
P.S.: Editiert weil MfG vergessen …
