[Aufruf] ZigBee CC253x Adapter

arteck

zu der Queue…

wir hatten mal Probleme mit der Verarbeitung der Befehle wenn diese pro Lampe kamen.. also mach an Farbe auf grün und helligkeit auf 50 %

die Bedehle kamen sehr träge an...

da einige es nicht nutzten (wie ich) habe ich die queue abschaltbar gemacht..

auch egal.. klasse Arbeit.. ich hoffe Ilya wird bald Zeit haben.. ohh ich sehe grade er hat die Sachen ins DEV übernommen

schau mal im Master auf Zeile 740

const readMessage = converter.convert(preparedValue, preparedOptions, 'get');

verlangt die Funktion convert nicht 4 Parameter ….

und hast du ein PR gestellt ??

modmax

Hi arteck,

danke für den Hinweis .. das ist beim Mergen passiert und mir niocht aufgefallen.

Hatte Ilya im DevBranch wegen den shepherd-converters eingebaut.

Dann habe ich den DEV bei mir in den Master gemerged und dann noch das von allofmex dazu gepackt.

Gav komischerweise aber auch keine Fehler beim Testen … :?:

Einen PR habe ich nicht gestellt, weil der direkt auf den Master-Branch gehen würde. Und dazu ist der Code

bei mir wegen der Verhunzelung nicht geeignet .. :-)

Ich habe Ilya eine Mail geschrieben und ihm das Problem und die Lösung erklärt ... vielleicht findet er die Zeit

sich das mal anzusehen und zu bewerten; oder zu mergen ... oder ich forke das ioBroker.zigbee nochmal

und merge die Änderungen dann nur in den DEV branch.

MfG Markus

Migo

~~@Cumulus:~~

Hi,

<size size="150">EDIT: SOLVED!!!</size>

ICH DOOFKOPP habe bei der Instanz nach zig Versuchen nur noch ttyACM0 statt /dev/ttyACM0 stehen gehabt….

Jetzt kann ich mal testen....

ALT:

<size size="50">ich bekomme meinen Zigbee-Stick nicht am Qnap-NAS zum Laufen.

Daher hier mein letzter Versuch bevor ich mir nen Raspi kaufe: (an dem das Ganze hoffentlich "einfach so" funktioniert).

Mein Fehler:

error Error while starting zigbee-shepherd!. Error: Error: No such file or directory, cannot open ttyACM0

Meine Konfiguration:

IOBroker im Docker auf einem QNAP-NAS.

/dev/ttypACMO existiert im Docker:
root@iobroker:/opt/iobroker# ls -la /dev/ttyACM0                                                                                            

crwxrwxrwx 1 root root 166, 0 Jan  3 22:44 /dev/ttyACM0  
dmesg auf dem QNAP nach einem USB-Stick rein/raus:
[ 2501.185787] usb 1-2: USB disconnect, device number 3

[ 2501.230548] [usb.001.003] /sys/devices/pci0000:00/0000:00:14.0/usb1/1-2 removed.

[ 2503.186946] usb 1-2: new full-speed USB device number 5 using xhci_hcd

[ 2503.361564] cdc_acm 1-2:1.0: ttyACM0: USB ACM device

[ 2503.398168] [usb.001.005] /sys/devices/pci0000:00/0000:00:14.0/usb1/1-2 added.
-> scheint auch I.O.</size>

Wie hast du es geschafft, dass dein QNAP den Stick erkennt (zum Docker durchgeschleift)? Welches Modell & QTS hast du am laufen?

Gruß Migo `

gently

~~@modmax:~~

Fazit also: Man könnte comb.brightnessAndState eigentlich für alle Lampen entfernen; das würde

den Datenverkehr etwas reduzieren. Müßte man dann aber natürlich für jede Lampe testen

oder die Leute hier fragen, ob das noch alles funzt … oder erst alles ändern und nachher fragen, wenn etwas nicht mehr geht ... :-)

Damit man aber noch immer einen STATE hat, habe ich "readAfter"-States eingebaut. Diese

sorgen dafür daß nach Ändern der Helligkeit ein read-Request für An/Aus durchgeführt wird;

durch das Ergebnis dieses Requests wird dann der Status "state" auch korrekt gestellt. `

Das hört sich sehr interessant an. Kannst Du mal eine kleine Anleitung schreiben, wo man den „comb.brightnessAndState“ entfernen muss und wie "readAfter"-States eingebaut werden.

Würde das gerne mal testen.

Viele Grüße

Jörg

arteck

~~@gently:~~

~~@modmax:~~

Fazit also: Man könnte comb.brightnessAndState eigentlich für alle Lampen entfernen; das würde

den Datenverkehr etwas reduzieren. Müßte man dann aber natürlich für jede Lampe testen

oder die Leute hier fragen, ob das noch alles funzt … oder erst alles ändern und nachher fragen, wenn etwas nicht mehr geht ... :-)

Damit man aber noch immer einen STATE hat, habe ich "readAfter"-States eingebaut. Diese

sorgen dafür daß nach Ändern der Helligkeit ein read-Request für An/Aus durchgeführt wird;

durch das Ergebnis dieses Requests wird dann der Status "state" auch korrekt gestellt. `

Das hört sich sehr interessant an. Kannst Du mal eine kleine Anleitung schreiben, wo man den „comb.brightnessAndState“ entfernen muss und wie "readAfter"-States eingebaut werden.

Würde das gerne mal testen.

Viele Grüße

Jörg `

hier ist sein Repo

gently

~~@arteck:~~

~~@gently:~~

~~@modmax:~~

Fazit also: Man könnte comb.brightnessAndState eigentlich für alle Lampen entfernen; das würde

den Datenverkehr etwas reduzieren. Müßte man dann aber natürlich für jede Lampe testen

oder die Leute hier fragen, ob das noch alles funzt … oder erst alles ändern und nachher fragen, wenn etwas nicht mehr geht ... :-)

Damit man aber noch immer einen STATE hat, habe ich "readAfter"-States eingebaut. Diese

sorgen dafür daß nach Ändern der Helligkeit ein read-Request für An/Aus durchgeführt wird;

durch das Ergebnis dieses Requests wird dann der Status "state" auch korrekt gestellt. `

Das hört sich sehr interessant an. Kannst Du mal eine kleine Anleitung schreiben, wo man den „comb.brightnessAndState“ entfernen muss und wie "readAfter"-States eingebaut werden.

Würde das gerne mal testen.

Viele Grüße

Jörg `

hier ist sein Repo `

Leider fehlt der Link!

gently

Hab das Repo von modmax gefunden und mir die devstates in meine Installation kopiert.

Danach für meinen Paulmann Adapter die Werte geändert und getestet.

Das Ergebnis ist nach den ersten Tests perfekt. Keine verschluckten Befehle mehr. Jetzt reagiert alles so, wie man es sich vorstellt.

Hoffentlich wird das bald in das produktive Repo gebracht.

Super Arbeit Modmax!

modmax

Dann mußte die mal den aktuellen DEV-Branch holen.

Über die Katze (Githube) oben in der Adapteransicht, dort eine beliebige URL eintragen:

https://github.com/ioBroker/ioBroker.zigbee/tarball/dev

Für eigene Änderungen mußt Du dann die Datei "devStates" bearbeiten.

Zu finden unter /opt/iobroker/node-moduls/ioBroker.zigbee/lib

Als Beispiel könnten Dir die OSRAM-Geräte dienen.

Wenn Du das erfolgreich getestet hast, dann sag mal mit welchen Lampen,

ob das nun besser funzt und wie es mit und ohne transition_time aussieht.

Was die Lampe zum Absturz bringt (bis dahin,d aß ein Reset der Lampe nötig ist

und dann wieder neu Aufpspielen der Updates über nen Hub) sind "Slider" oder "ColorPicker"

in der VIS, die dann munter ber Touch die Farbe ändern. Wenn es zuviele sind, sieht

man das gleich in den Logs …

Aber über Alexa reicht das locker aus ...

MfG Markus

modmax

Ah okay …

@gently

Wenn Du mir sagst bei welchen Lampen das nun besser geht, kann ich das bei mir ändern, so daß

ich das in nen Pull-Request für den DEV-Branch stellen kann.

Arteck sagte mir bereits, daß es für Hue-Lampen funktioniert. Da tat es das aber auch schon vorher;

ist dennoch einen Tick besser für HUEs.

MfG Markus

gently

Hallo Markus,

habe es mit folgendem Zigbee Controller getestet:

// Paulmann

{

vendor: 'Paulmann',

models: ['Dimmablelight '],

icon: 'img/dimmablelight.png',

states: lightStates,

readAfterStates: [readAfter.brightness],

},

Der kann An/Aus und dimmen. Wenn man zuviel spielt kommt irgenwann:

Zigbee publish to '0x00158d000251706f', genLevelCtrl - read - [{"attrId":0}] - 1 failed with error Error: AF data request fails, status code: 233. MAC no ack.

Zigbee publish to '0x00158d000251706f', genLevelCtrl - moveToLevelWithOnOff - {"level":254,"transtime":0} - 1 failed with error Error: Timed out after 30000 ms

aber eher selten.

Bis jetzt steht die transition_time auf 0. Werde das noch mal mit verschiedenen Zeiten testen.

Viele Grüße

Jörg

itzibitzistriezi

Also ich hab ZigBee seit 2 Monate laufen. Gefällt mir. Xiaomi pairing ist manchmal zäh aber wen Mal drinnen dann passt es. Schade das tradfri Steckdosen nicht gehen. Warum eigentlich nicht ?

arteck

~~@itzibitzistriezi:~~

Also ich hab ZigBee seit 2 Monate laufen. Gefällt mir. Xiaomi pairing ist manchmal zäh aber wen Mal drinnen dann passt es. Schade das tradfri Steckdosen nicht gehen. Warum eigentlich nicht ? `

echt nicht ?? hast mal eine ??

itzibitzistriezi

Ja 2 aber bekomme nur bei beiden
3432_screenshot_20190109-203929-picsay.png

arteck

ahh hab ich wartmal…

jetzt..musst aber mein Repo installieren

https://github.com/arteck/ioBroker.zigbee

itzibitzistriezi

~~@arteck:~~

ahh hab ich wartmal…

jetzt..musst aber mein Repo installieren

https://github.com/arteck/ioBroker.zigbee `

Hi Arteck,

nice funkt einwandfrei :)

Nett ist auch der neue "Developer" Bereich. -> Mal einlesen :)

DANKE
3432_juhu.jpg
3432_yeah.jpg

ReverZ

Hi arteck,

ich hab grad die letzte Version aus deinem Repository installiert und sehe nun auch den Developer-Reiter.

Nur folgende Dinge sind (wie auch bei der vorherigen Version) merkwürdig:

Die Philips Fernbedienung (Switch und Dimmer, RWL021) wurde zwar korrekt am controller angelernt aber das Gerät erscheint in der Netzwerk-Map immer ausserhalb des Netzwerks (ohne Link zu dem Controller). Die Funktion ist allerdings gegeben. Mehrfaches neues anlernen hat daran nichts geändert
Alle Xiaomi-Sensoren werden immer mit Link-Quality "170" in der Netzwerk-Map angezeigt, In den Objekten sieht man aber die "echten" Werte (im Bereich 18 bis 26)
Ich habe zwei Osram-Plugs (Plug 01) im Netzwerk. Einer der Plugs wird mit dem korreten Link-Quality-Wert in der Netzwerk-Map angezeigt, der andere immer nur mit "1". Der tatsächliche Wert steht aber ebenfalls in den Objekten.

Vielleicht hast du ja eine Idee woran diese Effekte liegen können.

modmax

Die Network map wird initial einmal eingelesen … woher die Werte dort kommen kann ich aktuell nicht sagen ....

Ich weiss auch nur daß das über nen Network scan geht.

Die Link quality in den Objekten wird immer dann gesetzt wenn was von den Geräten kommt ... ist also anders als in der Network map.

Daher kann man die beiden Werte nicht vergleichen.

MfG Markus

ReverZ

Bei der Netzwerkkarte hat man allerdings die Möglichkeit diese manuell zu aktualisieren.

Hier wird auch der Link-Quality-Wert des einen Osram-Plug aktualsiert. Der andere wird weiterhin konstant mit "1" angezeigt obwohl in den Objekten ein anderer Wert steht. Und wie gesagt alle Xiaomi-Sensoren konstant mit 170.

arteck

die Map wird laut der DB aufgebaut.. ich weiss aber gerade nicht wann die Werte da akutalisiert werden.. ich meine einmal bei start des Adapters oder wenn ein Device dazu kommt..

itzibitzistriezi

~~@arteck:~~

die Map wird laut der DB aufgebaut.. ich weiss aber gerade nicht wann die Werte da akutalisiert werden.. ich meine einmal bei start des Adapters oder wenn ein Device dazu kommt.. `

Ja die Map wäre in Echtzeit ein Hit. Sind ja alle visuelle Typen ;)

Community Forum

NEWS

[Aufruf] ZigBee CC253x Adapter

Support us

258

32.4k

81.4k

1.3m