[Aufruf] ZigBee CC253x Adapter

arteck

0.8.0 kannst du nehmen..

aber

wenn die Lampe muckt nimm die doch mal kurz vom Strom .. geht die dann

Arnulf

Vom Strom hatte ich sie mehrfach.

Sowohl kurzfristig (durch das Zurücksetzen mit 6x Anschalten) als auch mittelfristig (durch den Transport an eine andere Steckdose, weil ich sie in die Nähe der Empfänger bringen wollte)

Auch schon lehr lange vom Strom, weil ich sie die Tage eigentlich komplett ausgeschaltet hatte.

modmax

Sodele,

die Osram-Lampen funktionieren nun auch ohne Probleme.

Beim Einschalten über brightness wird auch nun der "state" korrekt gesetzt.

Grundlage der Problematiken kann man hier lesen:

https://github.com/Koenkk/zigbee-shephe … rs/pull/81

Ist wohl das gleiche Problem, was Osram-Lampen haben; die mögen

anscheinend keine "Setze Helligkeit und danach gleich die Lampe an/aus".

Ende September wurde dann "moveToLevel" durch "moveToLevelWithOnOff" ersetzt.

Somit bräuchte man eigentlich keine comb.brightnessAndState mehr, da dies bereits

durch das Zigbee-Kommando selbst erledigt wird und dadurch die Zigbee-Lampen intern an/ausschalten.

Somit ist der State "state" irgendwie auch hinfällig, da sich das "an/aus" aus der Helligekti ergibt.

Bei 0=aus, bei >0 = an. Intern wird in den OSRAM-Lampen aber wohl 1 als Minimum gespeichert, was aber nicht sichbar ist;

dient wohl dazu um bei einem Anschalten per State erstmal eine Helligkeit zu haben. Ist aber nur Spekulation.

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.

Wesentlich eleganter wäre es aber sich die letzte Helligkeit (>0) zu speichern und dann nur noch die Helligkeit

zu schalten ... der State wäre dann nur ein Dummy, der an ist, wenn Helligkeit>0 sonst aus; aber dadurch

wird dann kein echtes onoff-Event getriggert.

Somit laufen die Osrams bei mir nun ziemlich gut; ab und zu gibt es noch ein paar Fehler

(mal hier ein No-Ack oder so) aber das wars dann auch.

Weitere Erkenntnisse:

1.) Den DeveloperTab von allofmex habe ich mir ins Repo gemerged; istr ganz nice, wie meine Kinder sagen würden.

Kann man einiges einstellen ... z.B. die onOffTransitionTime für OSRAM-Lampen, wenn die per state geschaltet wird

oder das onLevel (=Helligkeit der Lampe, wenn diese Strm bekommt).

Die Konfigs sind aber weg nachdem das Device gelöscht wurde und dann wieder neu angelernt wurde.

Auch habe ich gemerkt, daß man sich durch falsche Konfigs die Lampe verkonfigurieren kann; so daß

dann nur ein Reset (zum Glück mit nem Sonoff-S20-Swicht und nem Skript, daß die Resetreihenfolge vornimmt)

und erneutes Aufspielen der aktuellen Firmware weiter hilft.

allofmex hatte im COde verhindert, daß man Router konfigurieren kann; hab ich ausgebaut, so daß nun auch Router gehen.

Aber dieser Einstellungs-Tab sind wirklich nur für Entwickler, und sollte möglichst nur per Einstellung sichtbar sein.

2.) Osram-Firmware

Hatte auf einer (wegen Punkt 1 :-)) die 0102307 drauf .. die tat's gar nicht ... Helligkeit ja aber nach einmal Farbwechsel tat sich nix mehr.

Da hilft dann nur Anlernen am Osram HUB und neueres Update (aktuell 0102501 oder so) aufspielen.

3.) VIS und Colorpicker

Wenn man zu sehr "rumslidet" auf dem RGB-Colorpicker oder Fantastic-Color-Picker, dann gibts irgendwann ziemlich viele

205er-Fehler im Log. Aber die Farben wurden schön gewechselt. Anscheinend kommt der 205er-Fehler vom Osram-Device

wenn zuviele Anfragen kamen ... Neu pairen war hier aber nie nötig. Nach ein paar Sekunden beruhigte sich das wieder.

4.) Queue abschalten

Warum man die Queue abschalten will, sei mal dahin gestellt. Aber ich glaube, daß das dann andere Probleme bringt. Es

ist meistens auch nicht nötig. Hab jedenfalls keine Vorteile durch das Abschalten der Queue bemerkt;

besonders weil es eh nur für die ausgehenden Mitteilungen ist, also solche die man per state durchführt.

Eingehende Meldungen gehen eh durch das event-Handling von zigbee-sheperd.

So .. das wars mal wieder ...

DIe Änderungen sind bei mir auch alle im Repo, falls jemand daran Interesse hat.

Wenn Ilya mal wieder dabei ist und Zeit hat, könnte man ggfs. einiges davon ins Haupt-Repo von iobroke.zigbee übernehmen.

MfG Markus

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

Community Forum

NEWS

[Aufruf] ZigBee CC253x Adapter

Support us

821

32.4k

81.4k

1.3m