Test Adapter digitalstrom 2.0.x
-
@solarimpulse Sagen wir es mal so: Da ein dss Update meines Wissens nach nie "Breaking "ist sondern maximal neue Funktionen bringt sollte ein dss Update maximal dazu führen das der Adapter loggt das es neue werte gibt die er nicht kennt oder das ggf Werte fehlen. Der Rest sollte an sich irrelevant sein.
Hast Du ein CHangelog? Ich hab gestern wenig dazu gefunden.
-
@apollon77
Ich habe nur das:
https://www.digitalstrom.com/azure/user_upload/tx_dsproductmanagement/documents/software_updates/SRN-2103_v1.0_DE.pdf
und das:
https://help.digitalstrom.com/hc/de-ch/articles/360020810880Das hast du vermutlich aber schon selber gefunden.
-
@solarimpulse Ja meine Frage war eher genereller natur. Und am Ende ist die 1.18.0 denke hier irrelevant (hofe ich) weil der Adapter ja lokal zugreift und nicht remote. Aber da ich mein DSS Testboard erst wieder aufsetzen müsste ist da jetzt ne gute Frage. Im ganzen Changelog wird nur von ds-Cloud gesprochen ...
-
@apollon77 der adapter läuft ganz normal weiter, auch mit der neuen firmware.
-
@apollon77
Hi ich hätte zwei neue Geräte die in dem Adapter nicht richtig unterstützt werden.Da steht undefinied.
Kannst du die mit aufnehmen? -
@apollon77
Hier mein debug log
iobroker.2021-04-13.log -
@cb187 Welche IDs meinst Du ?
EDIT: Also ichhhabe log geschaut. Das einzoge was er meckert was ich spontan sehe sind deine Hue Geräte. Das Problem an denen ist das das undokumentierte gerätetypen sind und ich nicht weiss wie ich die auslesen kann oder setzen kann. Daher ist das bewusst nicht implementiert.
Oder was meinst Du noch?
-
Das Device
digitalstrom.0.devices.73f7e3d7e8545ceac0c926707f75af7200.4f5fbffd59315e97c0b885f0d92c3e1b00
und
digitalstrom.0.devices.302ed89f43f0000000000e400000902800.302ed89f43f000000000454000521d6c00
digitalstrom.0.devices.302ed89f43f0000000000e40000077be00.302ed89f43f0000000000ec0000bb20e00Ist einmal nen uLux Taster, eine Schaltbare Enocean Steckdose über die plan44 und eine neue Lichterklemme.
-
@cb187 sagte in Test Adapter digitalstrom 2.0.x:
Also:
- 4f5fbffd59315e97c0b885f0d92c3e1b00 ... der brightness wird ausgelesen wie es aussieht und sollte da sein. laut log Wert 254
- die anderen beiden haben als HW info ein "IC GE-ZWD300" ... was isn das? Ist das ein offizielles Device oder was anderes? Der Adapter weiss aktuell nur wie die offiziellen geräte abgebildet sind auf Datenebene, von daher können auch nur die sauber ausgelesen werden. Ich habe GitHub mal eingebaut ... lass doch mal testen
geht es damit? Nach GitHub Install bitte manuell Adapter neu starten
-
Das IC GE ist ein OEM Produkt was für Digitalstrom hergestellt wird.Der Baustein ist eine GE 300 Klemme.
Werden beide noch als undefinied angezeigt.
bei dem hier fehlt auch noch der state. -
@cb187 Auch mit der neuen GitHub version?? Nach GitHub update adapter neu gestartet?
Wenn ja-> debug Log bitte nochmal
-
@apollon77
Hier die neue Log.
Adapter Version ist nach Update auf 2.1 -
@cb187 sagte in Test Adapter digitalstrom 2.0.x:
Adapter Version ist nach Update auf 2.1
Was meinst Du damit? Update normal oder hast Du die GitHub Version installiert? Bitte GitHub.
-
@apollon77
Ist von github
-
@cb187 Kann es sein das Du nicht lang genug gewartet hast ... Wenn der Adapter startet werden zuerst alle Objekte angelegt und danach eins nach dem anderen 8weil was anderes kann dss nicht) die werte gelesen ... heisst das kann noch laaaaange Dauern bis alle Werte initial da sind. Dein Log hört "mitten" in dem abholen der Daten auf. Also gib mal bitte ein "längeres" log
-
Warte immer solange bis er grün ist?!
-
@cb187 Ja dann sind alle States angelegt und alle "werte die zu lesen sind" gequeued ... Alle Daten aber noch nicht da ...
Sind denn jetzt alle Werte da?
-
-
@cb187 Naja such nach den IDs im Log ... er hat 17:22 die States angelegt ud 17:25 hat er zB von dem einen Gerät den brightness Wert mal gelesen gehabt:
2021-04-14 17:25:37.174 - [34mdebug[39m: digitalstrom.0 (59677) 1618413937174 Queued entry processed device/getOutputValue and {"dsuid":"302ed89f43f000000000454000521d6c00","offset":0,"category":"manual","token":"eaec203be7bad8b90b961848d8b8b06a1454fae9892d0a3c87c62815d1e1d09f"}: {"result":{"offset":0,"value":0},"ok":true}
Für 302ed89f43f0000000000ec0000bb20e00 als SW-UMR200 mit einem airFlowIntensity Wert ist aktuell unbekannt wie ich den wert auslesen kann ... daher wird er nicht gelesen. sorry. man könnte versuchen ob es it getOutput Value geht aber da reagieren die Geräte irgendwie alle unterschiedlich
