[gelöst] History Adapter bleibt öfters stehen

apollon77

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.

photographix

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.
```

apollon77

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"?

photographix

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

apollon77

Und du kannst sicherstellen das das OS nicht irgendwelche Prozesse killt?

photographix

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.

photographix

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

apollon77

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

photographix

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

apollon77

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?

photographix

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?

apollon77

Log oder History-Data?

Pman

~~@apollon77:~~

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.

apollon77

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

photographix

~~@apollon77:~~

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)

Pman

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.

AlCalzone

~~@apollon77:~~

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?

apollon77

~~@Pman:~~

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

apollon77

Change auf Github: Testergebnisse bitte posten!

http://forum.iobroker.net/posting.php?m … =36&t=5519

photographix

mit dem neuen Github Release habe ich auch keine Probleme mehr.

Der Adapter ist jetzt seit 83915 Sekunden online, connected und ohne Probleme.

Community Forum

NEWS

[gelöst] History Adapter bleibt öfters stehen

Support us

254

32.7k

82.5k

1.3m