[gelöst] History Adapter bleibt öfters stehen
-
Aaaaalso ….
zu Den ganzen "cannot find log": hast du per Zufall zwei Admin-Adapter laufen? In so einer konstellation hatte ich auch sowas ... ist ein Bug. SInd schon dran.
SIGTERM heisst an sich das der Prozess gekillt wurde ... Hast Du das was gemacht? Ist auf dem Rechner genug freies RAM da nicht das da irgendwas prozesse killt? Irgendwie ist das komisch bei Dir
Die letzte Stelle iost interessant. Jetzt müsstest Du schauen ob andere Restarts auch so aussehen? Also ist es der hm-rega der neu gestartet wird der immer für einen history-Neustart sorgt oder war das Zufall.
-
Nein leider auch nur einen Adapter
! ````
C:\ioBroker>node node_modules/iobroker.js-controller/iobroker.js list instances
system.adapter.admin.0 : admin - enabled, port: 8081, bind: 0.0.0.0 (SSL), run as: admin
system.adapter.cloud.0 : cloud - disabled
system.adapter.dwd.0 : dwd - enabled
system.adapter.history.0 : history - enabled
system.adapter.hm-rega.0 : hm-rega - enabled
system.adapter.hm-rpc.0 : hm-rpc - enabled, port: 0
system.adapter.hm-rpc.1 : hm-rpc - enabled, port: 0
system.adapter.hm-rpc.2 : hm-rpc - enabled, port: 0
system.adapter.ical.0 : ical - enabled
system.adapter.icons-material-svg.0 : icons-material-svg - enabled
system.adapter.icons-mfd-svg.0 : icons-mfd-svg - enabled
system.adapter.javascript.0 : javascript - enabled
system.adapter.jeelink.0 : jeelink - enabled
system.adapter.mobile.0 : mobile - disabled
system.adapter.node-red.0 : node-red - disabled, port: 1880
system.adapter.parser.0 : parser - disabled
system.adapter.ping.0 : ping - enabled
system.adapter.rflink.0 : rflink - disabled
system.adapter.rickshaw.0 : rickshaw - enabled
system.adapter.sayit.0 : sayit - disabled, port: 0
system.adapter.scenes.0 : scenes - enabled
system.adapter.socketio.0 : socketio - enabled, port: 8084, bind: 0.0.0.0 (SSL), run as: admin
system.adapter.tr-064.0 : tr-064 - enabled
system.adapter.upnp.0 : upnp - disabled
system.adapter.vis-players.0 : vis-players - enabled
system.adapter.vis.0 : vis - enabled
system.adapter.web.0 : web - enabled, port: 8082, bind: 0.0.0.0 (SSL), run as: admin
system.adapter.yr.0 : yr - enabled
! C:\ioBroker>Es ist mir mit der History erst aufgefallen seitdem ich intensiver alles loggen lassen. Jetzt habe ich meinen Jeelink von der CCU2 umgezogen und einen RF-Link von Maxtox. Seitdem logge ich einfach erstmal pauschal alles. Vorher war mir die History "nicht wichtig". Ich kann daher nicht sagen seit wann das Problem so ist. Das mit den Fehlenden LOGs ist aber erst seit "kurzem". SIGTERM kenn ich auch, aber nicht mit (7). Der Rega war Zufall. Die Windows VM hat zwei vCPUS mit jeweils 2,4 Ghz und 2GB RAM der aber nur minimal ausgefüllt ist. Gerade eben wieder als ich hier schreibe: host.Smarthub 2017-03-05 21:44:02.567 info Restart adapter system.adapter.history.0 because enabled host.Smarthub 2017-03-05 21:44:02.567 error instance system.adapter.history.0 terminated with code 7 (Adapter already running) >! ``` `2017-03-05 21:43:55.722 - [32minfo[39m: jeelink.0 stateChange jeelink.0.LaCrosse_Schlafzimmer.lowBatt {"val":0,"ack":true,"ts":1488746635723,"q":0,"from":"system.adapter.jeelink.0","lc":1488647976301} 2017-03-05 21:43:55.722 - [32minfo[39m: jeelink.0 stateChange jeelink.0.LaCrosse_Schlafzimmer.newBatt {"val":0,"ack":true,"ts":1488746635723,"q":0,"from":"system.adapter.jeelink.0","lc":1488647976301} 2017-03-05 21:43:55.722 - [32minfo[39m: jeelink.0 stateChange jeelink.0.LaCrosse_Schlafzimmer.temp {"val":17.5,"ack":true,"ts":1488746635723,"q":0,"from":"system.adapter.jeelink.0","lc":1488743985694} 2017-03-05 21:43:55.722 - [32minfo[39m: jeelink.0 stateChange jeelink.0.LaCrosse_Schlafzimmer.humid {"val":49,"ack":true,"ts":1488746635723,"q":0,"from":"system.adapter.jeelink.0","lc":1488746635723} 2017-03-05 21:43:56.113 - [32minfo[39m: jeelink.0 data received: OK 9 48 1 4 136 46 2017-03-05 21:43:56.113 - [32minfo[39m: jeelink.0 stateChange jeelink.0.LaCrosse_Kabuff.lowBatt {"val":0,"ack":true,"ts":1488746636114,"q":0,"from":"system.adapter.jeelink.0","lc":1488647979551} 2017-03-05 21:43:56.113 - [32minfo[39m: jeelink.0 stateChange jeelink.0.LaCrosse_Kabuff.newBatt {"val":0,"ack":true,"ts":1488746636114,"q":0,"from":"system.adapter.jeelink.0","lc":1488647979551} 2017-03-05 21:43:56.113 - [32minfo[39m: jeelink.0 stateChange jeelink.0.LaCrosse_Kabuff.temp {"val":15.9,"ack":true,"ts":1488746636114,"q":0,"from":"system.adapter.jeelink.0","lc":1488740952981} 2017-03-05 21:43:56.113 - [32minfo[39m: jeelink.0 stateChange jeelink.0.LaCrosse_Kabuff.humid {"val":46,"ack":true,"ts":1488746636114,"q":0,"from":"system.adapter.jeelink.0","lc":1488744693618} 2017-03-05 21:43:57.332 - [32minfo[39m: jeelink.0 data received: OK 9 19 1 4 152 51 2017-03-05 21:43:57.332 - [32minfo[39m: jeelink.0 stateChange jeelink.0.LaCrosse_Kinderzimmer.lowBatt {"val":0,"ack":true,"ts":1488746637332,"q":0,"from":"system.adapter.jeelink.0","lc":1488647979364} 2017-03-05 21:43:57.332 - [32minfo[39m: jeelink.0 stateChange jeelink.0.LaCrosse_Kinderzimmer.newBatt {"val":0,"ack":true,"ts":1488746637332,"q":0,"from":"system.adapter.jeelink.0","lc":1488647979364} 2017-03-05 21:43:57.332 - [32minfo[39m: jeelink.0 stateChange jeelink.0.LaCrosse_Kinderzimmer.temp {"val":17.5,"ack":true,"ts":1488746637332,"q":0,"from":"system.adapter.jeelink.0","lc":1488742945271} 2017-03-05 21:43:57.347 - [32minfo[39m: jeelink.0 stateChange jeelink.0.LaCrosse_Kinderzimmer.humid {"val":51,"ack":true,"ts":1488746637332,"q":0,"from":"system.adapter.jeelink.0","lc":1488732516093} 2017-03-05 21:43:59.832 - [32minfo[39m: jeelink.0 data received: OK 9 8 1 4 28 106 2017-03-05 21:44:00.207 - [32minfo[39m: jeelink.0 data received: OK 9 8 1 4 40 106 2017-03-05 21:44:00.847 - [32minfo[39m: jeelink.0 data received: OK 9 42 1 4 172 48 2017-03-05 21:44:00.847 - [32minfo[39m: jeelink.0 stateChange jeelink.0.LaCrosse_Bad-oben.lowBatt {"val":0,"ack":true,"ts":1488746640848,"q":0,"from":"system.adapter.jeelink.0","lc":1488647980536} 2017-03-05 21:44:00.847 - [32minfo[39m: jeelink.0 stateChange jeelink.0.LaCrosse_Bad-oben.newBatt {"val":0,"ack":true,"ts":1488746640848,"q":0,"from":"system.adapter.jeelink.0","lc":1488647980536} 2017-03-05 21:44:00.847 - [32minfo[39m: jeelink.0 stateChange jeelink.0.LaCrosse_Bad-oben.temp {"val":19.5,"ack":true,"ts":1488746640848,"q":0,"from":"system.adapter.jeelink.0","lc":1488746502348} 2017-03-05 21:44:00.847 - [32minfo[39m: jeelink.0 stateChange jeelink.0.LaCrosse_Bad-oben.humid {"val":48,"ack":true,"ts":1488746640848,"q":0,"from":"system.adapter.jeelink.0","lc":1488739598942} 2017-03-05 21:44:01.801 - [32minfo[39m: jeelink.0 data received: OK 9 44 1 4 204 43 2017-03-05 21:44:01.801 - [32minfo[39m: jeelink.0 stateChange jeelink.0.LaCrosse_Bad-unten.lowBatt {"val":0,"ack":true,"ts":1488746641801,"q":0,"from":"system.adapter.jeelink.0","lc":1488647998942} 2017-03-05 21:44:01.801 - [32minfo[39m: jeelink.0 stateChange jeelink.0.LaCrosse_Bad-unten.newBatt {"val":0,"ack":true,"ts":1488746641801,"q":0,"from":"system.adapter.jeelink.0","lc":1488647998942} 2017-03-05 21:44:01.801 - [32minfo[39m: jeelink.0 stateChange jeelink.0.LaCrosse_Bad-unten.temp {"val":22.7,"ack":true,"ts":1488746641801,"q":0,"from":"system.adapter.jeelink.0","lc":1488746633129} 2017-03-05 21:44:01.801 - [32minfo[39m: jeelink.0 stateChange jeelink.0.LaCrosse_Bad-unten.humid {"val":43,"ack":true,"ts":1488746641801,"q":0,"from":"system.adapter.jeelink.0","lc":1488746498473} 2017-03-05 21:44:02.551 - [31merror[39m: host.Smarthub instance system.adapter.history.0 terminated with code 7 (Adapter already running) 2017-03-05 21:44:02.567 - [32minfo[39m: host.Smarthub Restart adapter system.adapter.history.0 because enabled 2017-03-05 21:44:03.894 - [32minfo[39m: jeelink.0 data received: OK 9 8 1 4 28 106 2017-03-05 21:44:04.269 - [32minfo[39m: jeelink.0 data received: OK 9 8 1 4 40 106 2017-03-05 21:44:04.879 - [32minfo[39m: jeelink.0 data received: OK 9 48 1 4 136 46 2017-03-05 21:44:04.879 - [32minfo[39m: jeelink.0 stateChange jeelink.0.LaCrosse_Kabuff.lowBatt {"val":0,"ack":true,"ts":1488746644879,"q":0,"from":"system.adapter.jeelink.0","lc":1488647979551} 2017-03-05 21:44:04.879 - [32minfo[39m: jeelink.0 stateChange jeelink.0.LaCrosse_Kabuff.newBatt {"val":0,"ack":true,"ts":1488746644879,"q":0,"from":"system.adapter.jeelink.0","lc":1488647979551} 2017-03-05 21:44:04.879 - [32minfo[39m: jeelink.0 stateChange jeelink.0.LaCrosse_Kabuff.temp {"val":15.9,"ack":true,"ts":1488746644879,"q":0,"from":"system.adapter.jeelink.0","lc":1488740952981} 2017-03-05 21:44:04.879 - [32minfo[39m: jeelink.0 stateChange jeelink.0.LaCrosse_Kabuff.humid {"val":46,"ack":true,"ts":1488746644879,"q":0,"from":"system.adapter.jeelink.0","lc":1488744693618} 2017-03-05 21:44:05.644 - [32minfo[39m: jeelink.0 data received: OK 9 19 1 4 152 51 2017-03-05 21:44:05.644 - [32minfo[39m: jeelink.0 stateChange jeelink.0.LaCrosse_Kinderzimmer.lowBatt {"val":0,"ack":true,"ts":1488746645645,"q":0,"from":"system.adapter.jeelink.0","lc":1488647979364} 2017-03-05 21:44:05.644 - [32minfo[39m: jeelink.0 stateChange jeelink.0.LaCrosse_Kinderzimmer.newBatt {"val":0,"ack":true,"ts":1488746645645,"q":0,"from":"system.adapter.jeelink.0","lc":1488647979364} 2017-03-05 21:44:05.644 - [32minfo[39m: jeelink.0 stateChange jeelink.0.LaCrosse_Kinderzimmer.temp {"val":17.5,"ack":true,"ts":1488746645645,"q":0,"from":"system.adapter.jeelink.0","lc":1488742945271} 2017-03-05 21:44:05.644 - [32minfo[39m: jeelink.0 stateChange jeelink.0.LaCrosse_Kinderzimmer.humid {"val":51,"ack":true,"ts":1488746645645,"q":0,"from":"system.adapter.jeelink.0","lc":1488732516093} 2017-03-05 21:44:05.894 - [32minfo[39m: jeelink.0 data received: OK 9 32 1 4 191 47 2017-03-05 21:44:05.894 - [32minfo[39m: jeelink.0 stateChange jeelink.0.LaCrosse_Wohnzimmer.lowBatt {"val":0,"ack":true,"ts":1488746645895,"q":0,"from":"system.adapter.jeelink.0","lc":1488647700845} 2017-03-05 21:44:05.894 - [32minfo[39m: jeelink.0 stateChange jeelink.0.LaCrosse_Wohnzimmer.newBatt {"val":0,"ack":true,"ts":1488746645895,"q":0,"from":"system.adapter.jeelink.0","lc":1488647700845} 2017-03-05 21:44:05.894 - [32minfo[39m: jeelink.0 stateChange jeelink.0.LaCrosse_Wohnzimmer.temp {"val":21.4,"ack":true,"ts":1488746645895,"q":0,"from":"system.adapter.jeelink.0","lc":1488746390882} 2017-03-05 21:44:05.894 - [32minfo[39m: jeelink.0 stateChange jeelink.0.LaCrosse_Wohnzimmer.humid {"val":47,"ack":true,"ts":1488746645895,"q":0,"from":"system.adapter.jeelink.0","lc":1488743063130} 2017-03-05 21:44:07.957 - [32minfo[39m: jeelink.0 data received: OK 9 8 1 4 28 106 2017-03-05 21:44:08.129 - [32minfo[39m: jeelink.0 data received: OK 9 18 1 4 152 49 2017-03-05 21:44:08.144 - [32minfo[39m: jeelink.0 stateChange jeelink.0.LaCrosse_Schlafzimmer.lowBatt {"val":0,"ack":true,"ts":1488746648129,"q":0,"from":"system.adapter.jeelink.0","lc":1488647976301} 2017-03-05 21:44:08.144 - [32minfo[39m: jeelink.0 stateChange jeelink.0.LaCrosse_Schlafzimmer.newBatt {"val":0,"ack":true,"ts":1488746648129,"q":0,"from":"system.adapter.jeelink.0","lc":1488647976301} 2017-03-05 21:44:08.144 - [32minfo[39m: jeelink.0 stateChange jeelink.0.LaCrosse_Schlafzimmer.temp {"val":17.5,"ack":true,"ts":1488746648129,"q":0,"from":"system.adapter.jeelink.0","lc":1488743985694} 2017-03-05 21:44:08.144 - [32minfo[39m: jeelink.0 stateChange jeelink.0.LaCrosse_Schlafzimmer.humid {"val":49,"ack":true,"ts":1488746648129,"q":0,"from":"system.adapter.jeelink.0","lc":1488746635723} 2017-03-05 21:44:08.347 - [32minfo[39m: jeelink.0 data received: OK 9 8 1 4 40 106 2017-03-05 21:44:09.504 - [32minfo[39m: jeelink.0 data received: OK 9 42 1 4 172 48 2017-03-05 21:44:09.504 - [32minfo[39m: jeelink.0 stateChange jeelink.0.LaCrosse_Bad-oben.lowBatt {"val":0,"ack":true,"ts":1488746649504,"q":0,"from":"system.adapter.jeelink.0","lc":1488647980536} 2017-03-05 21:44:09.504 - [32minfo[39m: jeelink.0 stateChange jeelink.0.LaCrosse_Bad-oben.newBatt {"val":0,"ack":true,"ts":1488746649504,"q":0,"from":"system.adapter.jeelink.0","lc":1488647980536} 2017-03-05 21:44:09.504 - [32minfo[39m: jeelink.0 stateChange jeelink.0.LaCrosse_Bad-oben.temp {"val":19.5,"ack":true,"ts":1488746649504,"q":0,"from":"system.adapter.jeelink.0","lc":1488746502348} 2017-03-05 21:44:09.504 - [32minfo[39m: jeelink.0 stateChange jeelink.0.LaCrosse_Bad-oben.humid {"val":48,"ack":true,"ts":1488746649504,"q":0,"from":"system.adapter.jeelink.0","lc":1488739598942} 2017-03-05 21:44:10.504 - [32minfo[39m: jeelink.0 data received: OK 9 44 1 4 204 42 2017-03-05 21:44:10.519 - [32minfo[39m: jeelink.0 stateChange jeelink.0.LaCrosse_Bad-unten.lowBatt {"val":0,"ack":true,"ts":1488746650504,"q":0,"from":"system.adapter.jeelink.0","lc":1488647998942} 2017-03-05 21:44:10.519 - [32minfo[39m: jeelink.0 stateChange jeelink.0.LaCrosse_Bad-unten.newBatt {"val":0,"ack":true,"ts":1488746650504,"q":0,"from":"system.adapter.jeelink.0","lc":1488647998942} 2017-03-05 21:44:10.519 - [32minfo[39m: jeelink.0 stateChange jeelink.0.LaCrosse_Bad-unten.temp {"val":22.7,"ack":true,"ts":1488746650504,"q":0,"from":"system.adapter.jeelink.0","lc":1488746633129} 2017-03-05 21:44:10.519 - [32minfo[39m: jeelink.0 stateChange jeelink.0.LaCrosse_Bad-unten.humid {"val":42,"ack":true,"ts":1488746650504,"q":0,"from":"system.adapter.jeelink.0","lc":1488746650504}[/code]` >! es ist als ob der History Adapter sich selbst neu startet. ``` -
Nur so zur SIcherheit: Du hat bei den experteneinstellungen der Adapter nicht zufällig einen Restart hinterlegt?
Sonst habe ich keine Ahnung. Läuft der noch in "debug"?
-
Nope
Nein DEBUG ist aus sonst habe ich heute nacht keinen Platz mehr auf der HDD. Würde das nur bei Bedarf aktivieren.
1443_bildschirmfoto_2017-03-05_um_22.03.50.png -
Und du kannst sicherstellen das das OS nicht irgendwelche Prozesse killt?
-
Ich denke das kann ich im normalen Bereich sicher stellen. Es ist eine normale Server 2016 VM. Ohne externen Antivirus, ohne anderen Kram. Nur ioBroker. Ich versteh es eben auch nicht.
Habe jetzt mal eine Exclusion für den Windows Defender eingerichtet. Den kann man ja dort nicht mehr entfernen. Lasse jetzt DEBUG mal ne Stunde, zwei laufen.
-
Hallo @ all
kann es sein das ich es "verkonfiguriert" habe? Was sind die Standard Werte für den Adapter wenn man nur File DB hat?
1443_2017-03-08_07_22_32-iobroker.admin.png -
Ich glaube der Standard für "Anzahl RAM" sind 960 … also nicht sooo wild, weiterhin wird eh alle 30 Sekunden alles ins File geschrieben. Also das sollte nicht das Problem sein
-
Hallo apollon77
habe das jetzt einmal geändert. Ggf hat er ja "zu viel" schreiben müssen wenn ich aller 100 Einträge das auf die HDD schreibe. Was ist eigentlich die Entprellzeit konkret? Habe dazu nichts gefunden. Bei der http://www.iobroker.net/?page_id=4531&lang=en steht nur "Minimal Interval (in ms )" ich weiss aber nicht ob das die Entprellzeit ist.
Außerdem habe ich unter Objekte die Default Einstellung an alle Objekte vererbt. Vielleicht sind 1019 Objekte zu viel? Ich muss es aber erst mit den neuen Einstellungen testen.
1443_2017-03-08_09_04_37-iobroker.admin.png -
Bei "Debounce" geht es darum das es Geräte gibt die bei einem Schaltvorgang nicht sauber von Zustand A nach B wechseln sondern wo es durchaus zu wachlern ON-OFF-ON kommen kann, meist in sehr kurzen zeitpunkten (z.B. bei tastern bei Kontaktfehlern o.ä.). Um hier das Logging dieser "falschen Zwischenwerte" zu verhindern kann man so eine Debounce-Zeit setzen. Es ist der Zeitraum in dem Statusänderungen ignoriert werden und nicht geloggt werden.
Also Beispiel:
Wert= 1000 = 1 Sekunde
jetzt kommt wert ON
jetzt+100ms kommt Wert OFF - ignoriert
jetzt+200ms kommt Wert ON - ignoriert
jetzt+1100ms (=1 sekunde+100ms) kommt Wert OFF -> wird geloggt
Besser verständlich?
-
ok danke
habe jetzt debounce auf 2000 gestellt.
Problem mit dem Restart bzw Stop des History Adapters bleibt aber bestehen. Das iobroker Log Verzeichnis belegt 16GB und geht "nur" bis in den September 2016 zurück. Ist das normal?
-
Log oder History-Data?
-
jetzt kommt wert ON
jetzt+100ms kommt Wert OFF - ignoriert
jetzt+200ms kommt Wert ON - ignoriert
jetzt+1100ms (=1 sekunde+100ms) kommt Wert OFF -> wird geloggt `
Ist dies wirklich das Verhalten des History Adapters? Meiner Meinung nach müsste der letzte Wert schlussendlich auf jeden Fall geloggt werden, das loggen sollte nur aufgeschoben werden und ggf. abgeändert.
-
Sagen wir es so: Laut code funktioniert debounce so für alle History-Adapter (SQL, InfluxDB und History).
Die Frage ist theoretisch Ansichtssache. Wenn man debounce so definiert das der erste neue Status immer das Ziel ist und man ausgleicht das es ggf. nen "Rückfall" gibt, dann ist das aktuelle Vorgehen korrekt.
Von Kontakten kenne ich Debounce so das man warten auf welchen Wert sich das ganze "stabilisiert", das wäre eher dein Ansatz.
Meinungen? Kann man denke ich gefahrlos umbauen
-
Log oder History-Data? `
Das Verzeichnis c:\iobroker\iobroker-data\history\ 16GB
Das Verzeichnis c:\ioBroker\log\ 1,9GB (wegen Debug, ansonsten nur 30-50MB pro Tag)
-
Das sprengt jetzt zwar den Ramen dieses Threads, aber:
Ich denke grundsätzlich sollte der gespeicherte Wert am Ende dem tatsächlichen entsprechen, wenn es tatsächlich so gelöst ist wie von dir beschrieben wäre es gut möglich, dass am Ende der falsche Wert gespeichert wird, da der letzte einfach verworfen wurde.
Beispiel:
Wert= 1000 = 1 Sekunde
jetzt kommt wert ON -> wird geloggt
jetzt+800ms kommt Wert OFF -> wird ignoriert
keine Änderung mehr -> falscher letzter Wert geloggt
Wäre dies aktuell der Fall? Dann würde ich eher so vorgehen:
Wert= 1000 = 1 Sekunde
jetzt kommt wert ON -> wird geloggt (es gab zuvor für mind. 1000ms keine Änderung)
jetzt+100ms kommt Wert OFF -> Wert wird nach 1000ms geloggt, falls keine weitere Änderung
jetzt+200ms kommt Wert ON -> OFF wird verworfen und Wert wird nach 1000ms geloggt, falls keine weitere Änderung
jetzt+900ms kommt Wert OFF -> ON wird verworfen und Wert wird nach 1000ms geloggt, falls keine weitere Änderung
jetzt+1900ms -> OFF wird geloggt.
So würde auf jeden Fall jede (kurze) Änderung geloggt und ebenfalls der korrekte letzte Wert. Das "Flimmern" würde jedoch nicht geloggt.
-
Ich glaube der Standard für "Anzahl RAM" sind 960 … also nicht sooo wild, weiterhin wird eh alle 30 Sekunden alles ins File geschrieben. Also das sollte nicht das Problem sein `
Kann man diese 30s-Intervalle konfigurieren? Und wenn ja, wo? -
So würde auf jeden Fall jede (kurze) Änderung geloggt und ebenfalls der korrekte letzte Wert. Das "Flimmern" würde jedoch nicht geloggt. `
Nach etwas drüber nachdenken sehe ich das genau so. Verzögerung beenden und neu starten
bei jeder Änderung im Zeitraum … Baue es überall ein. Gibt dann nen tester Thread
-
Change auf Github: Testergebnisse bitte posten!
-
mit dem neuen Github Release habe ich auch keine Probleme mehr.
Der Adapter ist jetzt seit 83915 Sekunden online, connected und ohne Probleme.
