[Aufruf] deConz Adapter Testen 1.1.2
-
@Asgothian sagte in [Aufruf] deConz Adapter Testen 1.0.2:
@siggi85 sagte in [Aufruf] deConz Adapter Testen 1.0.2:
@Jey-Cee sagte in [Aufruf] deConz Adapter Testen 0.4.0:
@siggi85 sagte in [Aufruf] deConz Adapter Testen 0.4.0:
Aktuell ist es immer aufregend den Adapter neu zu starten
Dann würde ich vorschlagen ihn nicht neu zu starten
Dafür habe ich noch zu viele Xiaomi Sensoren im Schrank liege die ich die nächste Zeit Stück für Stück verbauen, in meine Oberflächen, Skripte und Adapter hinzufügen möchte. Ich habe für dieses Problem ggf. Eine Lösung. In meinem fork auf github habe ich für die Button-Events einen schattenevent eingefügt, der immer nur für 800 ms gesetzt wird. Insbesondere passiert dieses nicht beim Start des Adapters.
Du kannst den (wenn du magst) gerne mal testen, dazu müsstest du von hier installieren:
https://github.com/asgothian/ioBroker.deconzA.
Cool danke!
Leider komme ich wohl aber erst Ende nächste Woche zum Testen, da wir aktuell Besuch haben und ich dadurch wenig Zeit zum Testen habe auf ein funktionierendes System angewiesen bin.
Trotzdem schon mal danke für die Änderung, Ende nächster Woche teste ich auf jeden Fall!
-
@Jey-Cee
So.. test gemacht:deconz.0 auf debug logging gestellt.
In Yahka einen Datenpunkt für "on" von deconz.0.Lights.3.on auf deconz.0.Light_3.on umgebogen.
per HomeKit (von iOS aus) versucht die Lampe zu schalten - und Bumm
Nachtrag: Ich hab auch einfach mal einen ganz anderen Datenpunkt genommen, einen der vom Namen ueberhaupt nicht in das system passt, aber in Deconz.0 liegt (deconz.0.michgabesnochnie.on). Das Ergebnis ist identisch.
-
Noch ein Nachtrag:
Ich hab einfach einmal von Hand einen Datenpunkt konstruiert (Siehe Bild), und diesen mit Yahka verbunden.
Damit "geht" es, i.e. Yahka kann den schalten, und es passiert auch nichts böses.
Log:
-
@Asgothian gut zu wissen, das muss ich abfangen.
-
Hi,
seit heute läuft bei mir auch ein Conbee-II-Stick. Soweit alles problemlos, allerdings habe ich einen eigenartigen Effekt. Die Zeit bei lastupdated hängt exakt 2 Stunden hinterher. Deconz läuft auf einem Raspberry3 unter Raspbian (aktuelle Updates) in aktueller Version 2.05.61 (keine Beta). Der Raspberry zeigt mittels date die korrekte Zeit, auch die länderspezifischen Settings passen. Auf dem Raspi läuft auch noch PIVCCU, dort stimmen die Zeiten ebenfalls.
Iobroker läuft unter Ubuntu 18.04.2 in einer VM auf einem NUC, auch dort passt die Zeit und auch Skripte lösen korrekt aus und alles. Nur im Punkt lastupdated fehlen irgendwie zwei Stunden. Die Datenpunkte werden sofort und sauber aktualisiert, nur eben mit falschem Wert.Also, wo kann ich noch schauen, wo die zwei Stunden Versatz stecken?
Gruss, Jürgen
-
Ich hätte da 2 oder 3 Stellen im Verdacht:
- Eingestellte Zeitzone in der VM
- Eingestellte Zeitzone auf dem Host
- Eingestellter Ort im ioBroker
Was sagt die Zeit auf der Konsole in der VM bzw. auf dem Host ?
A.
-
@Asgothian sagte in [Aufruf] deConz Adapter Testen 1.0.2:
Ich habe für dieses Problem (- wie erkenne ich Buttonpresses sauber, ohne das beim Neustart die events ausgelöst werden) ggf. Eine Lösung. In meinem fork auf github habe ich für die Button-Events einen schattenevent eingefügt, der immer nur für 800 ms gesetzt wird. Insbesondere passiert dieses nicht beim Start des Adapters.
Du kannst den (wenn du magst) gerne mal testen, dazu müsstest du von hier installieren:
https://github.com/asgothian/ioBroker.deconzA.
Ich hab in den letzten 2 Wochen damit mal weitere Tests gemacht. Aus meiner Sicht funktioniert diese Methode deutlich besser als der "zuletzt geändert" Datenpunkt, primär weil diese Methode deutlich leichter in Skripten abzufragen ist. Ich nutze Events nach dem folgenden Muster.
on ({id: 'datenpunkt', change:'gt'}, function(obj) { switch (obj.state.val) { case 1002: // aktion auslösen break; case 2002: // aktion auslösen break; } });Ich wuerde mich freuen wenn das noch jemand testen könnte, um zu sehen ob die Änderung für den Adapter auf Dauer sinnvoll ist. Alternative Vorschläge (hier oder auch am pull-Request auf Github) ist willkommen.
Ein Punkt noch: Seit der letzten Änderung des Adapters muss man nach dem Anlernen eines neuen Gerätes über die Phoscon Software den Adapter einmal neu starten. Das scheint systematisch so - ich hab inzwischen > 10 geräte neu angelernt und hatte immer nur einige Datenpunkte direkt, nie alle. Ich sehe das nicht als bug an der zu fixen ist, es sollte aber dokumentiert werden.
A.
-
@Asgothian sagte in [Aufruf] deConz Adapter Testen 1.0.2:
Ich hätte da 2 oder 3 Stellen im Verdacht:
- Eingestellte Zeitzone in der VM
- Eingestellte Zeitzone auf dem Host
- Eingestellter Ort im ioBroker
Was sagt die Zeit auf der Konsole in der VM bzw. auf dem Host ?
A.
Die habe ich schon alle durch. Date liefert sowohl auf dem Host (NUC), in der iobroker-VM als auch auf dem Raspberry die korrekte Zeit. In iobroker ist der Ort auch korrekt, die Astrozeiten steuern seit Beginn an Skripte zu den richtigen Zeiten an. Auch per Cronjob gestartete Events starten dann, wenn ich es erwarten würde. In der Phoscon-App wird mir auch die korrekte Uhrzeit angezeigt. Nur auf dem Weg von deconz zu iobroker gehen irgendwie zwei Stunden verloren. Und auch nur da.
Gruss, Jürgen
-
@Asgothian sagte in [Aufruf] deConz Adapter Testen 1.0.2:
Ich wuerde mich freuen wenn das noch jemand testen könnte, um zu sehen ob die Änderung für den Adapter auf Dauer sinnvoll ist. Alternative Vorschläge (hier oder auch am pull-Request auf Github) ist willkommen.
Ich werde das wohl dieses Wochenende testen. Da ich aktuell auf 0.3.0 bin, ändert sich wohl etwas mehr, daher brauche ich ggf. etwas Zeit die potentiellen Anpassungen in Skripten vorzunehmen.
-
@siggi85 sagte in [Aufruf] deConz Adapter Testen 1.0.2:
Da ich aktuell auf 0.3.0 bin, ändert sich wohl etwas mehr, daher brauche ich ggf. etwas Zeit die potentiellen Anpassungen in Skripten vorzunehmen.
Vorsicht dabei - Ich empfehle den folgenden Weg:
- alle Skripte anhalten
- Adapter anhalten
- Objektbaum deconz.0 löschen
- Adapter updaten
- Adapter starten
- Skripte umstellen und neu starten.
Ich hab das nicht so gemacht, und mir damit regelmässige Neustarts des Adapters eingehandelt, weil es Probleme mit den alten Skripten / den Alten Datenpunkten in Yahka gegeben hat.
A.
-
@Asgothian sagte in [Aufruf] deConz Adapter Testen 1.0.2:
@siggi85 sagte in [Aufruf] deConz Adapter Testen 1.0.2:
Da ich aktuell auf 0.3.0 bin, ändert sich wohl etwas mehr, daher brauche ich ggf. etwas Zeit die potentiellen Anpassungen in Skripten vorzunehmen.
Vorsicht dabei - Ich empfehle den folgenden Weg:
- alle Skripte anhalten
- Adapter anhalten
- Objektbaum deconz.0 löschen
- Adapter updaten
- Adapter starten
- Skripte umstellen und neu starten.
Ich hab das nicht so gemacht, und mir damit regelmässige Neustarts des Adapters eingehandelt, weil es Probleme mit den alten Skripten / den Alten Datenpunkten in Yahka gegeben hat.
A.
Danke, so werde ich das machen!
-
@Asgothian sagte in [Aufruf] deConz Adapter Testen 1.0.2:
Ich wuerde mich freuen wenn das noch jemand testen könnte, um zu sehen ob die Änderung für den Adapter auf Dauer sinnvoll ist. Alternative Vorschläge (hier oder auch am pull-Request auf Github) ist willkommen.
Hi, getestet und für gut befunden. Einzig der lange Klick auf die On/Off bei der Tradfri-remote will mir nun nicht immer gelingen. Aber den brauche ich auch nicht unbedingt...
Prinzip habe ich korrekt verstanden? Trigger und Auswerten nun auf "buttenpressed" anstatt "buttonevent"?Wegen mir kann die Änderung so eingecheckt werden, wüsste gerade nichts, was dagegen spricht...
Gruss, Jürgen
-
@Asgothian sagte in [Aufruf] deConz Adapter Testen 1.0.2:
@siggi85 sagte in [Aufruf] deConz Adapter Testen 1.0.2:
Da ich aktuell auf 0.3.0 bin, ändert sich wohl etwas mehr, daher brauche ich ggf. etwas Zeit die potentiellen Anpassungen in Skripten vorzunehmen.
Vorsicht dabei - Ich empfehle den folgenden Weg:
- alle Skripte anhalten
- Adapter anhalten
- Objektbaum deconz.0 löschen
- Adapter updaten
- Adapter starten
- Skripte umstellen und neu starten.
Ich hab das nicht so gemacht, und mir damit regelmässige Neustarts des Adapters eingehandelt, weil es Probleme mit den alten Skripten / den Alten Datenpunkten in Yahka gegeben hat.
A.
Genau so habe ich es gemacht und hat wunderbar funktioniert. Auch das neue Event "buttonpressed" funktioniert einwandfrei! Ich musste nur mein Magic Cube Skript etwas anpassen (da ich die 0 abfangen musste), aber das ist vollkommen ok.
Bezüglich 1.x Version: Die neue Gruppierung nach Sensor Light und Group gefällt mir sehr gut! Schön wäre noch eine Sensorbenamung mit führenden Nullen (bspw. 001), dann würde ein Sensor auch zusammenhängender angezeigt werden (Wenn ein Sensor die IDs 29, 30, 31 hat, steht der 30 und 31 unter Sensor 3). Denn die Sortierung im Objektbaum erfolgt alphabetisch und nicht numerisch.
Aber das ist nur Kritik auf höchstem Niveau. Danke für die tolle Arbeit und den Adapter!Für die, die es interessiert, hier beim Skript zur Steuerung des Magic Cube. Ich setze Hilfsdatenpunkte (buttons) für die einzelnen Aktionen des Cube, analog zum Zigbee Adapter. In den eigentlichen Steuerungsskripten muss ich dann nur noch auf die Hilfsevents triggern.
Nebenbei sende ich noch Notifications an meine Lametric, aber das ist für die meisten sicher uninteressant.
EDIT: Habe nun noch ein bisschen mit meinem Hue Dimmer getestet. Funktioniert zwar, aber vielleicht wäre es besser, wenn der Wert nicht nach jeder Änderung wieder auf 0 gesetzt wird, sondern nur wenn innerhalb von den 800ms (ggf. auch länger) keine weitere Änderung erfolgt. Wenn man auf eine Taste lange drückt und dann mehrere Events hintereinander ausgelöst werden , wird sonst immer die 0 zwischendrin generiert. Denke das ist überflüssig und könnte ggf. zur Problemen führen?!
-
Hallo,
ich habe hier einige Xiaomi zwei Tasten Switch (WXKG02LM) verbaut. Diese sind sowohl über den Deconz als auch am Mihome-Hub betreibe.
Mich hat immer gestört, das die Funktionen Doppelklick und Drücken und halten nicht unterstützt werden (Mir würden hierzu zig Blockly-Anwendungen einfallen)
Gestern habe ich eine neue Lieferung erhalten. Als erstes ist mir eine wesentlich grüßere Verpackung (Doppelt so breit wie die alten - gleiche Verpackung wie die Eintaster) aufgefallen. Die Taster sehen genau gleich aus und auch die Bezeichnung auf der Rückseite ist absolut identisch.
Beim Einlernen in der MiHome-App ist mir folgendes aufgefallen. Es werden jetzt alle gewünschten Zustände erfasst und gelogt:Links Klicken
Rechts Klicken
Beide Drücken
Doppel Links klicken
Doppel Rechts Klicken
Drücken und halten Links
Drücken und halten RechtsIm MiHome-Adapter werden diese Taster aber leider überhaupt nicht mehr erkannt, obwohl Sie in der App vorhanden sind.
Wenn ich diese am Deconz via Phoscon anlerne wird dieser erkannt (Mit dem Zusatz "WXKG02LM Rev. 2").
In der Deconzoberfläche wird er auch angezeigt (korrekt mit dem in Phoscon vergebenen Namen).
In den Deconz-Objekten im IOBroker taucht er leider nicht auf. Habe schon Adapter-Neustart und Installation der Asgothian-Fork probiert.Es wäre genial, wenn diese neue Revision des Tasters in einem Adapterupdate mit berücksichtigt werden könnte.
Gruß DocGame
-
@DocGame
Hallo Doc,in Deconz können wir direkt nichts machen - entweder liefert deconz die Datenpunkte in der restAPI, oder sie tun es nicht. Deswegen die Frage ob er wirklich nicht auftaucht. Ich habe bisher mit meinen keine Probleme, und kann da alle von Dir beschriebenen Funktionen nutzen. Mit deconz 1.0.2:
Erkannt in Phoscon als
A. -
Perfekt...
Als ich das Post schrieb war der Taster zwar in Deconz(Oberfläche) sichtbar, in Phoscon ist hinter Version nichts gestanden.
Nach einer gewissen Zeit ist Unknow dahinter gestanden und nun 20180809.
Und siehe da.... Es geht.
Weil ich Probleme mit der Zustandsabfrage in Blockly hatte, bis ich auf den MiHome-Adapter gewechselt. Mit der "Buttonpressed" Funktionalität werde ich wohl wieder mit allem Umziehen.
Vielen Dank -
Ich möchte mich bitte einmal hier anhängen, denn ich habe gestern den Conbee 2 Stick auf einem Raspberry PI eingerichtet und einen Großteil meiner Xiaomi Sensoren und meiner Tradfri Komponenten dort bereits eingebunden.
Allerdings bin ich noch nicht so ganz fein mit der ganzen Sache, da ich ein kleines Verständnisproblem habe.
Wie immer bei mir, ist auch dies nun eine zweigeteilte Frage.
Der erste Teil umfasst die Logik in der Phoscon App, die mir nicht ganz klar wird.Ich komme vom Tradfri Gateway und dem Tradfri Adapter. Hier war es so, dass Lampen immer nur mit einem Steuergerät eingebunden werden konnten.
Entsprechend habe ich meine Installation auch hardwaremäßig so aufgebaut. Zu jeder Einzellampe und zu jedem Lampenverbund gibt es eine Fernbedienung. Um im ioBroker über den Adapter dann mittels Alexa oder Skripten zu schalten, habe ich virtuelle Gruppen in dem Tradfri Adapter erstellt.Nun habe ich die Lampen und Fernbedienungen in Phoscon eingebunden und bin etwas verwirrt. Zu jeder Lampe wird direkt eine Gruppe angelegt. Ebenso zu jeder Fernbedienung, wobei hier die Fernbedienung selbst eine Gruppe darstellt, wenn ich das richtig verstanden habe.
Ich habe also die Lampe in der Küche einmal in der Gruppe "Küche" und wenn ich diese mit der "Fernbedienung Küche" schalten will, muss ich der Fernbedienung diese Lampe zuweisen. Ist das richtig so?
Das bringt mich dann zum zweiten und interessanten Teil der Frage, nämlich im Deconz Adapter in ioBroker. Dort scheint mir alles etwas unsortiert und ohne wirklich erkennbare Struktur zu sein in den Objekten.
Die Fernbedienungen tauchen dort unter den Sensoren auf und ebenso als Gruppe. Dabei wird aber der Name, den ich in der Phoscon App vergeben habe, zu großen Teilen ignoriert und ich weiß nicht mehr, um welches Device es sich dabei handelt.
Groups 1 mit dem Zusatz "undefined" ist eigentlich die Gruppe "Fernsehzimmer" und die Gruppe 13309 ist eigentlich die "Fernbedienung Schlafzimmer", die ich auch so in Phoscon finde. Dort habe ich nicht eine Gruppe oder Lampe, oder Fernbedienung oder Sensor, der die hier sichtbaren Nummern als Namen hat.
Das sind die Gruppennamen, die von der Phoscon App vergeben werden, wenn man eine Lampe anlernt. Aber die habe ich direkt geändert. NAtürlich auch nicht schön, wenn man einen Spot mit 6 Lampen hat und dann am Ende 6 Gruppen erstmal bearbeiten muss, und diese aus ioBroker dann auch nicht wieder verschwinden, oder wenigstens den geänderten Namen annehmen.
Aber zusätzlich sind die Fernbedienungen auch noch unter den Sensoren zu finden, wobei sie dort auch nicht wirklich stringent umbennant sind und wahllos den Namen übernehmen oder auch nicht.
Ich verstehe die Logik nicht und habe enorme Schwierigkeiten nun meine Skripte anzupassen, weil ich die Objekte nicht wirklich wiederfinde, bzw. gar nicht weiß, welche Objekte ich nun nehmen soll. Lights, Sensors, Groups? Wenn ich sie denn überhaupt zuordnen könnte.
Ich schließe nicht aus, dass bei der Installation von deConz auf dem Raspi etwas fehlt oder falsch gemacht wurde. Ich betreibe den Raspi headless und habe übers macOS Terminal mittels SSH installiert und auch für die eigentliche deConz Software auf dem Raspi die GUI über Raspbian Stretch light nachinstalliert. Bedienen tue ich den Raspi nun grafisch über VNC.
Also wenn irgendwelche Infos noch gebraucht werden, liefere ich die gerne nach.
Adapterversion ist 1.0.2 und im Log ist keinerlei Auffälligkeit zu sehen und die Lampen und Sensoren schalten auch, wenn ich sie denn bediene. Sprich die Fenster und Türkontakte geben Laut und wenn ich eine Gruppe, eine FB oder ein Licht in ioBroker mal identifiziert habe und z. B. Brightness händisch ändere, dann tut es das auch.
Kann halt nur mit dem Klumpatsch, der da nun in den Objekten steht nichts weiter anfangen.
-
@mehrwiedu
Um da etwas Ordnung rein zu bekommen:Deconz Liefert jede Lampe, jeden Sensor und jede Gruppe an IoBroker. Dabei ist zu beachten:
- Alles was Informationen verarbeitet (Lampe, Steckdose, etc.) wird als Lampe weitergereicht
- Alles was Informationen erzeugt (Schalter, Sensor, Fernbedienung) wird als Sensor weitergereicht. Dabei ist es nicht zwingend so das einem Sensor auch nur ein logischer Sensor zugeordnet wird. So haben die Xiaomi Temperatursensoren jeweils 2 Sensoren in deConz
Gruppen werden (meines Wissens) immer dann erzeugt wenn
- Der Benutzer eine Gruppe anlegt und dieser eine oder mehrere Lampen zuweist
- Der Benutzer einer Fernbedienung direkt eine oder mehrere Lampen zuweist
Bei der Zuweisung gibt es keinen Zwang zur 1:1 Zuweisung. Die gleiche Fernbedienung kann in mehreren Gruppen verwendet werden.
Es ist also möglich, in der Web-App keinerlei Verbindungen zwischen Fernbedienungen und Lampen zu erzeugen, und die Steuerung zu 100% über ioBroker zu machen.
Ich hoffe das bringt etwas Ordnung in das Chaos.
A.
-
Danke für Deine Antwort. Soweit habe ich das Verstanden und versuche da jetzt mal Ordnung reinzubringen. Hardwaretechnisch scheint das eine gute Lösung zu sein.
Was mir nur im Wege steht, ist die Benennung der Gruppen in ioBroker. Da kommen die Namen aus Phoscon nicht an.
Wie rufe ich headless die Web App auf? Ist das die Phoscon App, oder noch eine andere Oberfläche in der ich Einstellungen machen kann?
Sonst habe ich nur via VNC die grafische Übersicht der Zigbee Verbindungen.
Lauter farbige Spaghettis Da muss ich auch mal schauen, was die Werte und Farben eigentlich aussagen. -
@mehrwiedu
das ist die web-oberfläche (Phoscon). Und bei mir kommen die Namen durchaus an, aber nur als "Text" an den Objekten, nicht als Name der Objekte - die bleiben immer fix als Lights.1 bis Lights.n und Sensors.1 bis Sensors.nDas ist meiner Meinung nach auch gut so.
A.
