NEWS
[Aufruf] ZigBee CC253x Adapter 0.9
-
Hallo, ich habe aktuell den Adapter in Version 0.9.1 in Verwendung. Also Coordinator nutze ich einen CC2531 USB Stick im ersten OG. I'm EG ist eine Osram Smart Plug und diverse Xiaomi Sensoren. Im Keller ist nochmals ein Osram Smart Plug und weitere geplante Sensoren.
Mein Plan: Ich will den ersten Osram vom EG am Coordinator angemeldet haben, die Sensoren im EG sollen an diesem Osram angemeldet werden. Der Osram im Keller soll an dem im EG angemeldet werden. Die Sensoren im Kaller dementsprechend am Osram im Keller.
Mein Problem: Obwohl ich immer auf dem grünen Anmeldebutton im Zigbee Adapter unser Osram Smart Plug anmelde, verbinden sich die Sensoren und der zweite Plug immer direkt an den CC2531. Ich sehe das auf der Mappe und kann das auch anhand der schlechterwerdenden Link quality ablesen.
Versuche: ich habe Geräte im Adapter gelöscht und auch die Osram Plugs ein Reset gemacht. Immer selber Ergebnis.
Hat einer eine Idee?
LG Phil82 -
Das Zigbee-netz baut sich seine Topologie selber zusammen. Es gibt meines Wissens keine direkte Möglichkeit in einem Netz die verschiedenen Knoten den einzelnen Routern zuzuweisen.
Die einzige mir bekannte Möglichkeit das Netz wie du es beschrieben hast zu trennen wäre ein eigener Coordinator im Keller, an dem du nur die Sensoren im Keller anmeldest. Das könntest Du mit einem weiteren Raspberry pi mit ioBroker (ggf. im Multihost modus um alle Datenpunkte an einer Stelle nutzbar zu habe) machen.
A.
-
@Asgothian sagte in [Aufruf] ZigBee CC253x Adapter 0.9:
Das Zigbee-netz baut sich seine Topologie selber zusammen. Es gibt meines Wissens keine direkte Möglichkeit in einem Netz die verschiedenen Knoten den einzelnen Routern zuzuweisen.
Die einzige mir bekannte Möglichkeit das Netz wie du es beschrieben hast zu trennen wäre ein eigener Coordinator im Keller, an dem du nur die Sensoren im Keller anmeldest. Das könntest Du mit einem weiteren Raspberry pi mit ioBroker (ggf. im Multihost modus um alle Datenpunkte an einer Stelle nutzbar zu habe) machen.
A.
da gibts nix um die devices slebst zuzuordnen.. ist halt ein Netzwerk..
@Phil82 aber wo ist das Problem.. reine Kosmetik -
Danke fürs schnelle Antworten. Problem liegt an der schlechten Link quality der Sensoren unten. Auch wenn ich die länger direkt neben den Osram Stelle wird es nicht besser. Die sind so zwischen 1 und 20. Gehe ich nach oben zum Coordinator habe ich 100+ Deshalb habe ich ja die Vermutung, daß die Sensoren sich wie auf der Map nur am Coordinator anmelden.
-
@Phil82 Ich kann das nicht 100% bestätigen, habe keine OSRAM Smurt Plug, dafür ein Xiaomi Plug, der auch ein "Pairing-Button" hat, aber ich konnte kein Endgerät an Plug anmelden. Zuerst war das auch meine Idee, den ins Wohnzimmer zu patzieren und 3-4 Endgeräte mit ihm zu verbinden. Jetzt habe ich in jeden Zimmer ein CC2530 als Router und ein CC2530 mit CC2591 als Coordinator. Meine Meinung nach die bessere Lösung.
Seit gestern gibt es eine neue FW für CC2530 als Router. Es wurde eine Reset-Möglichkeit mit 3x Ein/Ausschalten integriert. D.h. um ein CC2530 in Pairingmodus zu versetzten muss mann jetzt nicht neu flashen.
-
Ich habe jetzt testweise einen CC2531 also Router geflasht. So funktioniert es tatsächlich wie gewünscht. Aber warum funktioniert das mit den Osram nicht? Ich hab da irgendwie ein Verständnis Problem. LG
-
Habe ich es richtig verstanden, daß es sinnvoll ist meinen Stick neu zu flashen, damit meine Osram Plugs besser funktionieren?
-
@LJSven sagte in [Aufruf] ZigBee CC253x Adapter 0.9:
Habe ich es richtig verstanden, daß es sinnvoll ist meinen Stick neu zu flashen, damit meine Osram Plugs besser funktionieren?
nein hast du nicht.. wenn du gruppen bei Osram nutze nwillst dan musst du neu flashen
-
Wenn ich den iobroker neu starte, kommt ständig die Meldung "Zigbee-Shepperd" failed - 60 Sekunden warten. Was bedeutet das?
-
her doktor herr doktor wenn ich hier drauf drücke tuts wehh.....:-)
welche Version ??
-
@arteck said in [Aufruf] ZigBee CC253x Adapter 0.9:
her doktor herr doktor wenn ich hier drauf drücke tuts wehh.....:-)
welche Version ??
Die Version vom Adapter ist 0.9.1
-
hi,
ich war gerade mal bei meiner iobroker installation auf debian im /var/log unterwegs.
Dort ist ja auch die syslog. HIer wird extrem viel vom iobroker.zigbee adapter gelogt.
Ist das normal? Da kommt alles an, habe aber nix auf debug stehen sondern auf info.
warum ist das so?
gruss -
Bei mir ist das auch so.. aktuelle Version von Github. Alle Meldungen kommen vom Zigbee controller (bzw. zigbee shepherd.)
das gleiche im übrigen nicht nur im syslog sondern auch im daemon.log.
Anbei mal ein Beispiel (nur ausschnitt)
Feb 18 19:55:59 localhost node[1488]: 2019-02-18T18:55:59.081Z zigbee:controller debug handleMessage { type: 'devChange', Feb 18 19:55:59 localhost node[1488]: endpoints: Feb 18 19:55:59 localhost node[1488]: [ Endpoint { Feb 18 19:55:59 localhost node[1488]: isLocal: [Function], Feb 18 19:55:59 localhost node[1488]: device: [Object], Feb 18 19:55:59 localhost node[1488]: profId: 260, Feb 18 19:55:59 localhost node[1488]: epId: 1, Feb 18 19:55:59 localhost node[1488]: devId: 9, Feb 18 19:55:59 localhost node[1488]: inClusterList: [Array], Feb 18 19:55:59 localhost node[1488]: outClusterList: [], Feb 18 19:55:59 localhost node[1488]: clusters: [Object], Feb 18 19:55:59 localhost node[1488]: onAfDataConfirm: null, Feb 18 19:55:59 localhost node[1488]: onAfReflectError: null, Feb 18 19:55:59 localhost node[1488]: onAfIncomingMsg: null, Feb 18 19:55:59 localhost node[1488]: onAfIncomingMsgExt: null, Feb 18 19:55:59 localhost node[1488]: onZclFoundation: null, Feb 18 19:55:59 localhost node[1488]: onZclFunctional: null, Feb 18 19:55:59 localhost node[1488]: foundation: [Function], Feb 18 19:55:59 localhost node[1488]: functional: [Function], Feb 18 19:55:59 localhost node[1488]: bind: [Function], Feb 18 19:55:59 localhost node[1488]: unbind: [Function], Feb 18 19:55:59 localhost node[1488]: read: [Function], Feb 18 19:55:59 localhost node[1488]: write: [Function], Feb 18 19:55:59 localhost node[1488]: report: [Function] } ], Feb 18 19:55:59 localhost node[1488]: data: Feb 18 19:55:59 localhost node[1488]: { cid: 'seMetering', Feb 18 19:55:59 localhost node[1488]: data: { '57344': 8, '57345': 225, '57346': 1 } } } Feb 18 19:55:59 localhost node[1488]: 2019-02-18T18:55:59.083Z zigbee:controller event devChange { type: 'devChange', Feb 18 19:55:59 localhost node[1488]: endpoints: Feb 18 19:55:59 localhost node[1488]: [ Endpoint { Feb 18 19:55:59 localhost node[1488]: isLocal: [Function], Feb 18 19:55:59 localhost node[1488]: device: [Object], Feb 18 19:55:59 localhost node[1488]: profId: 260, Feb 18 19:55:59 localhost node[1488]: epId: 1, Feb 18 19:55:59 localhost node[1488]: devId: 9, Feb 18 19:55:59 localhost node[1488]: inClusterList: [Array], Feb 18 19:55:59 localhost node[1488]: outClusterList: [], Feb 18 19:55:59 localhost node[1488]: clusters: [Object], Feb 18 19:55:59 localhost node[1488]: onAfDataConfirm: null, Feb 18 19:55:59 localhost node[1488]: onAfReflectError: null, Feb 18 19:55:59 localhost node[1488]: onAfIncomingMsg: null, Feb 18 19:55:59 localhost node[1488]: onAfIncomingMsgExt: null, Feb 18 19:55:59 localhost node[1488]: onZclFoundation: null, Feb 18 19:55:59 localhost node[1488]: onZclFunctional: null, Feb 18 19:55:59 localhost node[1488]: foundation: [Function], Feb 18 19:55:59 localhost node[1488]: functional: [Function], Feb 18 19:55:59 localhost node[1488]: bind: [Function], Feb 18 19:55:59 localhost node[1488]: unbind: [Function], Feb 18 19:55:59 localhost node[1488]: read: [Function], Feb 18 19:55:59 localhost node[1488]: write: [Function], Feb 18 19:55:59 localhost node[1488]: report: [Function] } ], Feb 18 19:55:59 localhost node[1488]: data: Feb 18 19:55:59 localhost node[1488]: { cid: 'seMetering', Feb 18 19:55:59 localhost node[1488]: data: { '57344': 8, '57345': 225, '57346': 1 } } } { cid: 'seMetering', modelId: 'Ninja Smart plug' } Feb 18 19:55:59 localhost node[1488]: Mon, 18 Feb 2019 18:55:59 GMT cc-znp:AREQ <-- ZDO:srcRtgInd, { dstaddr: 57999, relaycount: 0, relaylist: <Buffer > } Feb 18 19:55:59 localhost node[1488]: 2019-02-18T18:55:59.766Z zigbee-shepherd:msgHdlr IND <-- ZDO:srcRtgInd Feb 18 19:55:59 localhost node[1488]: Mon, 18 Feb 2019 18:55:59 GMT cc-znp:AREQ <-- AF:incomingMsg, { groupid: 0, clusterid: 1794, srcaddr: 57999, srcendpoint: 1, dstendpoint: 1, wasbroadcast: 0, linkquality: 2, securityuse: 0, timestamp: 1080662, transseqnumber: 0, len: 27, data: <Buffer 0c 9f 10 32 0a 00 e0 21 7d 00 01 e0 21 e1 00 02 e0 21 03 00 03 e0 23 df 02 00 00> } Feb 18 19:55:59 localhost node[1488]: 2019-02-18T18:55:59.822Z zigbee-shepherd:af dispatchIncomingMsg(): type: incomingMsg, msg: [object Object] Feb 18 19:55:59 localhost node[1488]: 2019-02-18T18:55:59.826Z zigbee-shepherd:msgHdlr IND <-- AF:incomingMsg, transId: 0 Feb 18 19:55:59 localhost node[1488]: 2019-02-18T18:55:59.826Z zigbee:controller event msg { groupid: 0, Feb 18 19:55:59 localhost node[1488]: clusterid: 1794, Feb 18 19:55:59 localhost node[1488]: srcaddr: 57999, Feb 18 19:55:59 localhost node[1488]: srcendpoint: 1, Feb 18 19:55:59 localhost node[1488]: dstendpoint: 1, Feb 18 19:55:59 localhost node[1488]: wasbroadcast: 0, Feb 18 19:55:59 localhost node[1488]: linkquality: 2, Feb 18 19:55:59 localhost node[1488]: securityuse: 0, Feb 18 19:55:59 localhost node[1488]: timestamp: 1080662, Feb 18 19:55:59 localhost node[1488]: transseqnumber: 0, Feb 18 19:55:59 localhost node[1488]: len: 27, Feb 18 19:55:59 localhost node[1488]: data: Feb 18 19:55:59 localhost node[1488]: { '0': 12, Feb 18 19:55:59 localhost node[1488]: '1': 159, Feb 18 19:55:59 localhost node[1488]: '2': 16, Feb 18 19:55:59 localhost node[1488]: '3': 50, Feb 18 19:55:59 localhost node[1488]: '4': 10, Feb 18 19:55:59 localhost node[1488]: '5': 0, Feb 18 19:55:59 localhost node[1488]: '6': 224, Feb 18 19:55:59 localhost node[1488]: '7': 33, Feb 18 19:55:59 localhost node[1488]: '8': 125, Feb 18 19:55:59 localhost node[1488]: '9': 0, Feb 18 19:55:59 localhost node[1488]: '10': 1, Feb 18 19:55:59 localhost node[1488]: '11': 224, Feb 18 19:55:59 localhost node[1488]: '12': 33, Feb 18 19:55:59 localhost node[1488]: '13': 225, Feb 18 19:55:59 localhost node[1488]: '14': 0, Feb 18 19:55:59 localhost node[1488]: '15': 2, Feb 18 19:55:59 localhost node[1488]: '16': 224, Feb 18 19:55:59 localhost node[1488]: '17': 33, Feb 18 19:55:59 localhost node[1488]: '18': 3, Feb 18 19:55:59 localhost node[1488]: '19': 0, Feb 18 19:55:59 localhost node[1488]: '20': 3, Feb 18 19:55:59 localhost node[1488]: '21': 224, Feb 18 19:55:59 localhost node[1488]: '22': 35, Feb 18 19:55:59 localhost node[1488]: '23': 223, Feb 18 19:55:59 localhost node[1488]: '24': 2, Feb 18 19:55:59 localhost node[1488]: '25': 0, Feb 18 19:55:59 localhost node[1488]: '26': 0 }, Feb 18 19:55:59 localhost node[1488]: zclMsg: Feb 18 19:55:59 localhost node[1488]: { frameCntl: { frameType: 0, manufSpec: 1, direction: 1, disDefaultRsp: 0 }, Feb 18 19:55:59 localhost node[1488]: manufCode: 4255, Feb 18 19:55:59 localhost node[1488]: seqNum: 50, Feb 18 19:55:59 localhost node[1488]: cmdId: 'report', Feb 18 19:55:59 localhost node[1488]: payload: [ [Object], [Object], [Object], [Object] ] } } { modelId: 'Ninja Smart plug' } Feb 18 19:55:59 localhost node[1488]: 2019-02-18T18:55:59.827Z zigbee-shepherd:af dispatchIncomingMsg(): type: zclIncomingMsg, msg: [object Object]
-
Nachtrag: Ich konnte das Problem bei meiner Installation beheben, allerdings nicht ohne Nebenwirkungen:
nach Auskommentieren der Zeile
process.env.DEBUG = 'zigbee*,cc-znp*';
in main.js hören die Meldungen in den Log-Dateien auf. In wie weit dieser Eintrag dazu führt das weniger Log-Einträge im ioBroker Log auftauchen wenn debug oder silly loglevel gesetzt wird weiss ich nicht.
Da ich nicht zu 100 % verstehe was dahinter steht werde ich dafuer aktuell erst einmal keinen pull-request auslösen - ich kann die Nebenwirkungen nicht gut genug abschätzen.
A.
-
Hallo, ich nutze auch die Version 0.9.1 - gestern habe ich diverse Xiaomi Sensoren neu angelernt - hat auch alles funktioniert, allerdings funken die XIAOMI Temp Sensoren keine Werte. Angelernt habe ich die an einen OSRAM Plug. Bewegungsmelder hingegen funktionieren. Gibt es dafür eine Erklärung?
-
@Asgothian sagte in [Aufruf] ZigBee CC253x Adapter 0.9:
Nachtrag: Ich konnte das Problem bei meiner Installation beheben, allerdings nicht ohne Nebenwirkungen:
nach Auskommentieren der Zeile
process.env.DEBUG = 'zigbee*,cc-znp*';
in main.js hören die Meldungen in den Log-Dateien auf. In wie weit dieser Eintrag dazu führt das weniger Log-Einträge im ioBroker Log auftauchen wenn debug oder silly loglevel gesetzt wird weiss ich nicht.
Da ich nicht zu 100 % verstehe was dahinter steht werde ich dafuer aktuell erst einmal keinen pull-request auslösen - ich kann die Nebenwirkungen nicht gut genug abschätzen.
A.
das ist aus dem zigbee2mqtt profekt.. damit man dort mehr Log sieht..
das kannst du meiner Meinung nach auskommentieren.. für uns unnötig -
@LJSven Hast du die Probleme immernoch? Also ich habe einige Aqara Temp Sensoren und die laufen ohne Probleme. Sie senden halt nur bei Temperaturänderung Werte. Und Batteriezustand hat bei mir Teilweise ein Tag gedauert, bis ich dort einen Wert hatte.
-
Habe heute auf 0.9.2 aktualisiert und seit dem meine Geräteliste und Netzwerkarte ist leer.
Upload und neue starten habe ich gemacht. -
ich springe kurz in den Keller und hole meine Glaskugel raus um mehr über dein System rauszufinden
-
@arteck sagte in [Aufruf] ZigBee CC253x Adapter 0.9:
ich springe kurz in den Keller und hole meine Glaskugel raus um mehr über dein System rauszufinden
Kannst du mir auch mal so eine Glaskugel geben ?
@dimaiv Scherz beiseite. Ohne Informationen gibts keine Hilfe
Kannst du Bitte die Folgenden Schritte durchführen:- Adapter anhalten
- auf die Log-ansicht wechseln, Log zurücksetzen so das nichts angezeigt wird.
- filter auf "zigbee.0"
- Adapter starten
Und uns dann die entsprechenden Log-Einträge zur Verfügung stellen ?