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

[Asgothian]

@southparkler said in [Aufruf] ZigBee CC253x Adapter 0.9:

Muss ich eigentlich alle Skripte anpassen wenn ich alles neu pairen möchte? Scheint mir extrem aufwendig zu sein...

Normalerweise nicht - die Objekte werden nach den ID's benannt. Die sollten statisch sein.

A.

[ltsalvatore]

achso.. du meinst das normale resetten..
das habe ich natürlich auch gemacht. aber da denke ich hat asgothian recht, da wird nichts neu generiert.
zum glück auch, sonst müsste ich ja jedes mal meine scripte aufs neuste anpassen. :relaxed:

[chris_xy123]

@arteck
Ich habe ein Update per github versucht. Siehe Anhang.
Keine Veränderungzigbee_github.log

[Phil82]

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

[Asgothian]

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.

[arteck]

@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

[Phil82]

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.

[sphinx_sat]

@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.

[Phil82]

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

[LJSven]

Habe ich es richtig verstanden, daß es sinnvoll ist meinen Stick neu zu flashen, damit meine Osram Plugs besser funktionieren?

[arteck]

@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

[LJSven]

Wenn ich den iobroker neu starte, kommt ständig die Meldung "Zigbee-Shepperd" failed - 60 Sekunden warten. Was bedeutet das?

[arteck]

her doktor herr doktor wenn ich hier drauf drücke tuts wehh.....:-)

welche Version ??

[LJSven]

@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

[Smarti2019]

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

[Asgothian]

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]

[Asgothian]

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.

[LJSven]

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?

[arteck]

@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

[hanswurst0815]

@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.