[Aufruf] ZigBee CC253x Adapter
-
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
-
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/ttyACM0dmesg 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 `
-
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
-
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
-
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!
-
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!
-
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
-
Ah okay …
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
-
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
-
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 ?
-
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 ??
-
Ja 2 aber bekomme nur bei beiden
3432_screenshot_20190109-203929-picsay.png -
ahh hab ich wartmal…
jetzt..musst aber mein Repo installieren
-
ahh hab ich wartmal…
jetzt..musst aber mein Repo installieren
Hi Arteck,
nice funkt einwandfrei
Nett ist auch der neue "Developer" Bereich. -> Mal einlesen
DANKE
3432_juhu.jpg
3432_yeah.jpg -
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.
-
-
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
-
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.
-
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..
-
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
-
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
`Sinnvoll wäre auch, meiner Meinung nach, die Möglichkeit zu haben nachträglich schauen zu können, an welchem Gerät was angelernt wurde.
