NEWS
[Aufruf] ZigBee CC253x Adapter
-
Im Moment nirgends, aber immer mal wieder…
https://www.mydealz.de/search?q=Osram+Smart+Plug
Gesendet von meinem Redmi 5 Plus mit Tapatalk
-
Ist der Dimmer vielleicht nicht als solcher erkannt worden? Undefined heißt das dann, glaube ich. Ansonsten einfach nochmal versuchen
Gesendet von meinem Redmi 5 Plus mit Tapatalk `
Nein also scheint schon so als wäre das Gerät prinzipiell erkannt worden.
In den Datenpunkten ändert sich nur nichts wenn ich dran drehe…
9152_unbenannt.jpg -
hi zusammen,
kurz mal ne frage zum dem CC2531 Stick und den angegebenen link states bei den angeschlossenen geräte.
kurze vorgeschichte.
ich habe mir den stick gekauft und vorgehabt, damit den xiaomi cube zu nutzen.
leider befinden sich stick und cube jeweils am anderen ende der wohnung.
nach kurzer recherche habe ich mich entscheiden, die reichweite mit osram smart+ plugs zu erweitern.
wenn ich mir jetzt aber die link_quality werte der beiden osram smart+ plugs unter den objekten anschau, dann zeigt der erste plug state 0 und der zweite state 26 an..
wie aussagekräftig sind die werte unter den objekten?
oder sollte man zur bewertung der reichweite die werte aus den eigenschaften der instanz unter netzwerkkarte betrachten? dort stehen nämlich werte von 23 und 72…
-
mal zu Klärung (klugscheiss Modus an)
das was du unter state verstehst ist eigentlich der link_quality Objekt..da setht eine Zahl diese besagt ..eigentlich die Qualität der Verbindung.
der eigentliche state ist der schaltzustand der Dose bzw. des Devices da eine Lampe auch ei state hat an/aus - true/false
(klugscheiss Modus aus)
und ja das ist mir auch schon aufgefallen dass die Werte nicht korrespondieren.. hab mich aber noch nicht drum gekümmert warum das so ist..
-
mal zu Klärung (klugscheiss Modus an)
das was du unter state verstehst ist eigentlich der link_quality Objekt..da setht eine Zahl diese besagt ..eigentlich die Qualität der Verbindung.
der eigentliche state ist der schaltzustand der Dose bzw. des Devices da eine Lampe auch ei state hat an/aus - true/false
(klugscheiss Modus aus)
und ja das ist mir auch schon aufgefallen dass die Werte nicht korrespondieren.. hab mich aber noch nicht drum gekümmert warum das so ist.. `
stimmt.. hab beides vermischt
meinte natürlich link_quality.
ah super danke.. dann weis ich bescheid, dass es scheinbar ein allgemeines problem zu sein scheint.
-
Meine Installation hat nun einen Umfang angenommen, der weitergehende Tests hinsichtlich Zuverlässigkeit und Reichweite zulässt:
Die Sensoren sind alle Xiaomi Aqara und waren zuerst angelernt. Die drei Steckdosen sind Osram Smart+ und sind nachträglich dazu gekommen.
Meine Tests haben nun einige Fragen aufgeworfen. Ich numeriere sie nachfolgend mal durch - sie betreffen verschiedene Themen und so spart ihr euch evtl. das Zitieren, wenn ihr auf einen bestimmten Punkt antwortet:
1. Den Fühler Temp_Terrasse habe ich nach dem Anlernen an Ort und Stelle gebracht. Dort hatte er drei Tage lang keine Verbindung. Die Plugs mit ihrer Repeaterfunktion waren noch nicht da.
Jetzt gibt es aber die Plugs, eine davon ca. 1 m entfernt vom Fühler. Der Fühler weigert sich aber, seine Daten über die Plug zu senden - er bleibt tot. Bringe ich ihn in Reichweite des Stick, geht er aber.
Auch ein Neuanlernen des Sensors nach Installation der Plugs hat daran nichts geändert.
Sieht so aus, als ob der Sensor die Plugs nicht mag - oder umgekehrt.
2. Die Stabilität / Qualität (???) der Verbiudungen erscheint mir mangelhaft. Möglicherweise habe ich aber irgednwas falsch gemacht oder nicht gemacht…:
Ohne erkennbares Muster weigert sich manchmal eine Plug, Schaltbefehle anzunehmen (bei oben gezeigter Netzwerkstruktur und -qualität). Manchmal ist es sporadisch, dass Befehle gar nicht oder mit bis zu 15 Sekunden Verzögerung ankommen. Manchmal verweigert eine Plug auch kategorisch ihren Dienst, bis ich sie einmal so örtlich verändere, dass sie sich eine andere Route sucht.
Logauszug:
!
2018-11-28 14:18:22.529 - error: zigbee.0 Zigbee publish to '0x84182600000fa3fa', genOnOff - read - [{"attrId":0}] - 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. 2018-11-28 14:18:41.410 - error: zigbee.0 Zigbee publish to '0x84182600000fb1c7', genOnOff - on - {} - 3 failed with error Error: AF data request fails, status code: 233\. MAC no ack. 2018-11-28 14:18:42.078 - error: zigbee.0 Zigbee publish to '0x84182600000fb1c7', genOnOff - read - [{"attrId":0}] - 3 failed with error Error: AF data request fails, status code: 233\. MAC no ack. 2018-11-28 14:20:07.516 - error: zigbee.0 Zigbee publish to '0x84182600000fa3fa', genOnOff - read - [{"attrId":0}] - 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. 2018-11-28 14:20:29.491 - error: zigbee.0 Zigbee publish to '0x84182600000fa3fa', genOnOff - on - {} - 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. 2018-11-28 14:20:30.196 - error: zigbee.0 Zigbee publish to '0x84182600000fa3fa', genOnOff - read - [{"attrId":0}] - 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. 2018-11-28 14:20:55.040 - error: zigbee.0 Zigbee publish to '0x84182600000fb1c7', genOnOff - on - {} - 3 failed with error Error: AF data request fails, status code: 233\. MAC no ack. 2018-11-28 14:20:55.735 - error: zigbee.0 Zigbee publish to '0x84182600000fb1c7', genOnOff - read - [{"attrId":0}] - 3 failed with error Error: AF data request fails, status code: 233\. MAC no ack. !3. Die Reichweite ist klar geringer als bei Homematic. Dennoch scheint mir das bei mir (im Vergleich zu anderen Schilderungen hier) ziemlich schlecht.
Könnte es sein, dass WLAN da stört. Wo ich die meisten Probleme habe, ist ein UBIQUITY AccessPoint nur 3 m entfernt.
Kann man da was mit Kanaländerung erreichen? Sind die Kanäle analog zum WLAN 2,4 GHz?
4. Lokales Schalten der Plugs (scheinbar insbesondere das Ausschalten) wird erst nach Minuten in den Objekten angezeigt. Ist das normal?
5. Erfolgloses Schalten (also ein "true" ins State-Objekt schreiben) wird nicht erkannt. Das "true" bleibt im Objekt stehen.
Ist die Kommunikation nicht bidirektional?
Erfährt der Stick / Adapter nicht, dass ein Schaltbefehl angekommen und verarbeitet ist?
Falls er es erfährt, warum bleibt dann der State auf "true"?
Vielleicht könnte man (wo es sinnvoll ist) ein Objekt hinzufügen "LastActionResponse", so das man erkennen kann, ob der letzte Befehl vom Aktor bestätigt wurde.
Zuletzt: Liebe Entwickler, bitte versteht meine Ergüsse nicht als Nörgeln. Ich habe höchsten Respekt vor eurer Arbeit. Zudem ist der Adapter ja noch in Entwicklung und Beta. Ich möchte konstruktiv an der Weiterentwicklung mitarbeiten - soweit mir das als "nur" Anwender mögluich ist.
Gruß
Manfred
-
4. Lokales Schalten der Plugs (scheinbar insbesondere das Ausschalten) wird erst nach Minuten in den Objekten angezeigt. Ist das normal? `
Hast du noch irgendetwas anderes zum Testen (Hue-Lampen, Tradfri o.ä.)?
Ich habe meinen kompletten Osram-Teile (Gateway, Plugs, Lampen) mittlerweile alle verkauft. Warum?
Der "normale" Osram-Aufbau (Gateway + Plug (5m Entfernung)) hat schon nicht berauschend funktioniert. Teilweise lange Schaltzeiten, Disconnects o.ä.
Im Anschluss habe ich die Plugs und Lampen mal testweise an der HUE-Bridge angelernt. Damit wurde es etwas besser, jedoch waren die HUE deutlich schneller beim Umschalten, Dimmen oder was auch immer - egal über welchen Weg (HUE-App, FHEM, …).
Kurzum, ich war von den Osram-Teilen nicht wirklich begeistert. Vllt waren es alles Montagsgeräte - vllt musste das auch so sein.
Wer weiß. Wenn du hast, teste mal was anderes.
Gruß
oetti
-
@oetti: nein, habe leider nur die Aqara Teile und die drei Osram Plugs.
Zu den anderen Themen bin ich jedoch ein Stück weiter gekommen. Der AccessPoint hat tatsächlich im gleichen Frequenzband gesendet, wie das ZigBee.
Hier mal zwei Links, die mir da immens weiter geholfen haben:
https://www.digitalzimmer.de/artikel/wi … alwechsel/
https://www.elektronik-kompendium.de/si … 712061.htm
Zusammenfassend kann man folgendes sagen (betrifft das 2,4 GHz Band):
Die WLAN Kanäle 1 bis 13 liegen fast deckungsgleich auf den ZigBee Kanälen 11 bis 24. Kanalabstand jeweils 5 MHz.
Die ZigBee Kanäle haben eine Bandbreite von 5 MHz. Das heißt, dass die Sende-/Empfangsfrequenz dort aufhört, wo der Nachbarkanal anfängt.
Die WLAN Kanäle haben eine Bandbreite von 20 oder 40 MHz. Damit funken sie also über 4 oder gar 8 Kanäle. Sie belegen also jeweils nach oben und unten 2 bzw. 4 Nachbarkanäle.
Ich habe den ZigBee Kanal auf 11 gelassen. Der kann von den WLAN Kanälen 4 und kleiner gestört werden. Ich habe also das WLAN fest auf Kanal 11 (das ist bei ZigBee der Kanal 22) eingestellt - also möglichst weit weg. Dass es schwache Netze aus der Nachbarschaft gibt, die auch Kanal 11 benutzen halte ich für unkritisch.
Das Ergebnis war eine massive Verbesserung der beschriebenen Symptome. Allerdings gibt es immer noch manchmal erhebliche Lags bzgl. Schaltbefehlen oder Statusmeldungen.
Was nun noch offen ist, packe ich jetzt mal in einzelne Beiträge.
Gruß
Manfred
-
Hier noch mal mein momentan drängendstes Problem:
Der Aqara Temperatursensor (das quadratische Teil von XIAOMI) weigert sich beharrlich, einen Osram smart+ Plug als Router anzuerkennen. Sobald er außer Reichweite des Sticks und in sichere Reichweite eines (oder gar mehrerer) Plugs gebracht wird, bleibt er aus Sicht des Adapters stumm. Auch nachdem er gelöscht und neu (in Reichweite des Sticks) angelernt wurde.
Ist es denn so, dass das Anlernen in Reichweite des zu benutzenden Routers geschehen muss?
Gibt es hier jemanden, der diesen Sensor erfolgreich über einen Osram Plug (oder wenigstens über ein anderes Gerät) geroutet bekommt?
-
Hi, bei mir sieht die Karte anders aus, aber ja, ich habe es über ein Osram Plug schon geschafft, die Aquara Sensoren anzulernen. Braucht halt Mal Post mehr Versuche, ab und zu beim Sensor 1x das Köpfchen drücken…
Gesendet von meinem HUAWEI RIO-L01 mit Tapatalk
-
@Homer1976:Hallo Arteck,
Hab heut auf Node.js v8.14.0 ein update gemacht seitdem bleibt der Adapter rot.
Hab den Adapter nochmal vollständig gelöscht und wollte Ihn neu Installieren geht aber nicht mehr.
Grüße Steffen `
hast du ein reinstall des iobroker gemacht nach dem update. ?? es werden alle Adapter neu installiert.. das dauert muss aber sein
-
@Homer1976:Hallo Arteck,
Hab heut auf Node.js v8.14.0 ein update gemacht seitdem bleibt der Adapter rot.
Hab den Adapter nochmal vollständig gelöscht und wollte Ihn neu Installieren geht aber nicht mehr.
Grüße Steffen `
hast du ein reinstall des iobroker gemacht nach dem update. ?? es werden alle Adapter neu installiert.. das dauert muss aber sein `
Hab ich gemacht kann natürlich sein das er noch nicht ganz durch gelaufen ist warte mal noch.
-
Hi Arteck,
ich habe neue Fehler entdeckt:
No state available for '4052899926110' with key 'transition_time'
Vor paar Tagen hat noch funktioniert.
Danke. `
bissel mehr infos muss du mir schon geben.. was ist das für ein Device ?? Adapter Version ??
-
Hi Arteck,
ich habe neue Fehler entdeckt:
No state available for '4052899926110' with key 'transition_time'
Vor paar Tagen hat noch funktioniert.
Danke. `
bissel mehr infos muss du mir schon geben.. was ist das für ein Device ?? Adapter Version ?? `
Device: LIGHTIFY Indoor Flex RGBW
7cb03eaa00adea74
Adapter: 0.8.0b, aktuelste aus deinem repo.
P.S.: habe gerade über dein repo aktualisiert, und ist ganz kaputt gegangen:
! 018-11-28 21:25:08.084 info Restart adapter system.adapter.zigbee.0 because enabled
! host.raspberrypi 2018-11-28 21:25:08.084 error instance system.adapter.zigbee.0 terminated with code 6 (uncaught exception)
! Caught 2018-11-28 21:25:08.084 error by controller[7]: 2018-11-28T20:25:07.084Z zigbee:controller info zigbee-shepherd stopped undefined
! Caught 2018-11-28 21:25:08.084 error by controller[6]: Wed, 28 Nov 2018 20:25:07 GMT zigbee-shepherd zigbee-shepherd is stopped.
! Caught 2018-11-28 21:25:08.084 error by controller[5]: Wed, 28 Nov 2018 20:25:07 GMT cc-znp The serialport /dev/serial/by-id/usb-Texas_Instruments_TI_CC2531_USB_CDC___0X00124B000E896DEE-if00 is closed.
! Caught 2018-11-28 21:25:08.083 error by controller[4]: Wed, 28 Nov 2018 20:25:07 GMT cc-znp:SREQ –> ZDO:mgmtPermitJoinReq, { addrmode: 15, dstaddr: 65532, duration: 0, tcsignificance: 0 }
! Caught 2018-11-28 21:25:08.083 error by controller[3]: Wed, 28 Nov 2018 20:25:07 GMT zigbee-shepherd:request REQ –> ZDO:mgmtPermitJoinReq
! Caught 2018-11-28 21:25:08.083 error by controller[2]: Wed, 28 Nov 2018 20:25:07 GMT zigbee-shepherd zigbee-shepherd is stopping.
! Caught 2018-11-28 21:25:08.083 error by controller[1]: at Manager.Emitter.emit (/opt/iobroker/node_modules/socket.io-client/node_modules/component-emitter/index.js:133:20)
! Caught 2018-11-28 21:25:08.083 error by controller[1]: at Manager. <anonymous>(/opt/iobroker/node_modules/component-bind/index.js:21:15)
! Caught 2018-11-28 21:25:08.083 error by controller[1]: at Socket.onpacket (/opt/iobroker/node_modules/socket.io-client/lib/socket.js:236:12)
! Caught 2018-11-28 21:25:08.082 error by controller[1]: at Socket.onack (/opt/iobroker/node_modules/socket.io-client/lib/socket.js:312:9)
! Caught 2018-11-28 21:25:08.082 error by controller[1]: at Socket.adapter.getState (/opt/iobroker/node_modules/iobroker.zigbee/main.js:727:17)
! Caught 2018-11-28 21:25:08.082 error by controller[1]: at options (/opt/iobroker/node_modules/iobroker.zigbee/main.js:87:21)
! Caught 2018-11-28 21:25:08.082 error by controller[1]: at publishFromState (/opt/iobroker/node_modules/iobroker.zigbee/main.js:576:15)
! Caught 2018-11-28 21:25:08.082 error by controller[1]: at Array.forEach (<anonymous>)
! Caught 2018-11-28 21:25:08.082 error by controller[1]: at stateList.forEach (/opt/iobroker/node_modules/iobroker.zigbee/main.js:593:35)
! Caught 2018-11-28 21:25:08.081 error by controller[1]: at Object.convert (/opt/iobroker/node_modules/zigbee-shepherd-converters/converters/toZigbee.js:65:27)
! Caught 2018-11-28 21:25:08.081 error by controller[1]: TypeError: value.includes is not a function
! zigbee.0 2018-11-28 21:25:07.085 info zigbee-shepherd stopped
! zigbee.0 2018-11-28 21:25:07.050 error at Manager.Emitter.emit (/opt/iobroker/node_modules/socket.io-client/node_modules/component-emitter/index.js:133:20)
! zigbee.0 2018-11-28 21:25:07.050 error at Manager. <anonymous>(/opt/iobroker/node_modules/component-bind/index.js:21:15)
! zigbee.0 2018-11-28 21:25:07.050 error at Socket.onpacket (/opt/iobroker/node_modules/socket.io-client/lib/socket.js:236:12)
! zigbee.0 2018-11-28 21:25:07.050 error at Socket.onack (/opt/iobroker/node_modules/socket.io-client/lib/socket.js:312:9)
! zigbee.0 2018-11-28 21:25:07.050 error at Socket.adapter.getState (/opt/iobroker/node_modules/iobroker.zigbee/main.js:727:17)
! zigbee.0 2018-11-28 21:25:07.050 error at options (/opt/iobroker/node_modules/iobroker.zigbee/main.js:87:21)
! zigbee.0 2018-11-28 21:25:07.050 error at publishFromState (/opt/iobroker/node_modules/iobroker.zigbee/main.js:576:15)
! zigbee.0 2018-11-28 21:25:07.050 error at Array.forEach (<anonymous>)
! zigbee.0 2018-11-28 21:25:07.050 error at stateList.forEach (/opt/iobroker/node_modules/iobroker.zigbee/main.js:593:35)
! zigbee.0 2018-11-28 21:25:07.050 error at Object.convert (/opt/iobroker/node_modules/zigbee-shepherd-converters/converters/toZigbee.js:65:27)
! zigbee.0 2018-11-28 21:25:07.050 error TypeError: value.includes is not a function
! zigbee.0 2018-11-28 21:25:07.048 error uncaught exception: value.includes is not a function</anonymous></anonymous></anonymous></anonymous> -
Ich habe auch eine Merkwürdigkeit entdeckt.
Ich weiß allerdings nicht, ob es am Zigbee Adapter oder am USB-Stick CC2531 liegt.
Ich habe mehere Xiaomi Aqara Fenstersensoren eingesetzt.
Alle zur gleichen Zeit eingebaut. Batterie sollte also einigermaßen gleich stark sein.
Mit meinem bisherigen Xiaomi MiHome-Adapter und einem Original Gateway haben alle Adapter so +/- ähnliche Batteriewerte gehabt.
Nun schwanken die Werte zwischen 55% und 100%. Meist 99%. Das kann ja nicht stimmen. Zumindest Werte über 95% sind merkwürdig.
Vor dem Umstieg auf Zigbee Stick und Adapter waren noch Werte um die 79% zu lesen.
Ich setze den Zigbee-Adapter 0.8.0b ein.
Support us
755
Online32.4k
Benutzer81.4k
Themen1.3m
Beiträge