Test Adapter OpenDTU

[crunchip]

@idlebit hab das loggen noch nicht aktiv, bzw mir die Werte bis dato noch nicht angesehen, da ich mich noch nicht entscheiden kann. Aktuell läuft ja mqtt und Ahoy. Werde ich morgen in Angriff nehmen.

[IdleBit]

@hollywoot in der aktuellen Gitversion ist nun die DTU RSSI vorhanden.

[crunchip]

@idlebit hab noch nicht auf die aktuellste Version gewechselt, läuft also noch die davor, allerdings ist mir gerade dieses aufgefallen, das wird nicht mehr richtig angezeigt, im Log hab ich diesbezüglich nichts gefunden

Aktualisierungintervall mqtt sowie dtu stehen auf 10sec

per mqtt zum Vergleich



einen Adapter Neustart hab ich aktuell noch nicht angestoßen

[IdleBit]

@crunchip Also dann muss mal der DTU misst gesendet haben, dann bei z.B. yieldtotal lasse ich immer nur größere Werte zu daher wird sich das auch nicht nach unten korrigieren.
Daher hast du 2 Optionen die fehlerhaften datenpunkte löschen und den Adapter neustarten oder die nullen.

[crunchip]

@idlebit ok
nach nem Adapter neustart, passte yieldday zwar wieder aber total nicht, hab kurzerhand einfach mal alle DP gelöscht und neu anlegen lassen

[andre1980hb]

Moin, hab ihr auch ein Thema mit dem Adapter und häufigen Abstürzen?
Ich erhalte jeden Tag die ioBroker Meldung das opendtu.0 häufig abstürzt (merke es an der Grafana Visualisierung, die Graphen sind leer) nach dem Neustart der Instanz gehts dann wieder.

Vermutlich hängt das mit der Abschaltung der WR über Nacht zusammen.
Ich setze Hardware von AZ Delivery für die openDTU ein und lese 2 WR (HM-600 und HM-1500) aus.

Würde mich mal interessieren ob ihr das auch habt, bzw. was man dagegen tun könnte.

[Thomas Braun]

@andre1980hb

Schau in das LogFile rein.

iob logs

[IdleBit]

@crunchip Heute hatte ich auch das Phänomen, ich habe nun in der aktuellen Git Version die Yield-Protection einfacher gelöst..
Hoffe das nun das Problem nicht mehr auftritt!

[IdleBit]

@andre1980hb Ja wie der @Thomas-Braun schon sagt ich brauche logs, so kann ich leider nichts feststellen.
Aber grundsätzlich ist bei mir auf jedenfalls noch nie der Adapter abgestürzt.

[crunchip]

@idlebit jep, vor 3 Tagen war es wieder bei mir (habs 2Tage lang nicht gemerkt), Gesamt und auch der Tageswert stimmten nicht mehr, völlig falsche Wert, also Objektbaum wieder gelöscht.
Heute Morgen hatte ich dann erneut das Problem, diesmal allerdings nur mit dem Yieldday, der blieb seit 0:00 unverändert bei 0, Gesamt stimmte aber und wurde korrekt aktualisiert.

@idlebit sagte in Test Adapter OpenDTU:

habe nun in der aktuellen Git Version die Yield-Protection einfacher gelöst

werde ich testen, muss ja irgendwie funktionieren, per mqtt gehts ja auch ohne Probleme
@IdleBit was übrigens noch aufgefallen ist, bei einem Adapter restart kommt immer

2023-02-25 11:56:23.188 - info: host.IoBroker stopInstance system.adapter.opendtu.0 send kill signal
2023-02-25 11:56:23.188 - info: opendtu.0 (52390) terminating
2023-02-25 11:56:23.189 - info: opendtu.0 (52390) Terminated (ADAPTER_REQUESTED_TERMINATION): Without reason
2023-02-25 11:56:24.234 - info: host.IoBroker stopInstance system.adapter.opendtu.0 killing pid 52390
2023-02-25 11:56:24.249 - warn: opendtu.0 (52390) redis get opendtu.0.dtu.available, error - Connection is closed.
2023-02-25 11:56:24.250 - warn: opendtu.0 (52390) redis get opendtu.0.123456789.available, error - Connection is closed.
2023-02-25 11:56:24.359 - warn: opendtu.0 (52390) get state error: Connection is closed.
2023-02-25 11:56:24.403 - warn: opendtu.0 (52390) get state error: Connection is closed.
2023-02-25 11:56:24.537 - info: opendtu.0 (52390) Connect to OpenDTU over websocket connection.
2023-02-25 11:56:24.652 - warn: opendtu.0 (52390) Cannot get view: Connection is closed.
2023-02-25 11:56:24.914 - info: host.IoBroker instance system.adapter.opendtu.0 terminated with code 11 (ADAPTER_REQUESTED_TERMINATION)
2023-02-25 11:56:30.117 - info: host.IoBroker instance system.adapter.opendtu.0 started with pid 466962
2023-02-25 11:56:34.889 - info: opendtu.0 (466962) starting. Version 0.1.0 (non-npm: o0shojo0o/ioBroker.opendtu) in /opt/iobroker/node_modules/iobroker.opendtu, node: v18.14.1, js-controller: 4.0.24
2023-02-25 11:56:35.295 - info: opendtu.0 (466962) Connect to OpenDTU over websocket connection.
2023-02-25 11:56:50.045 - info: opendtu.0 (466962) Connect to OpenDTU over websocket connection.

[andre1980hb]

Kann das ggf. damit zusammenhängen, dass sich der Adapter (für den ioBroker) zu oft auf der openDTU einloggen will, wenn diese schon den oder die Wechselrichter nicht mehr erreichen kann (weil keine Produktion stattfindet)?

Wenn das aber bei wenigen Nutzern auftritt, ist vielleicht irgendeine installierte Komponente bzw. die Version der gemeinsame Nenner?

[Thomas Braun]

@andre1980hb

Stell zunächst mal deine nodeJS-Installation auf die empfohlene v16 um.

[crunchip]

@thomas-braun sollte aber nicht daran liegen

 "engines": {
    "node": ">= 14"

[Thomas Braun]

@crunchip

Ist aber trotzdem eine nicht mehr empfohlene Version und gehört angehoben. In 5 wenigen Wochen ist v14 EOL (30. April 2023)
Also kann man das auch jetzt anpacken.

[haselchen]

@thomas-braun
Wenns danach geht ist V16 auch in 6Monaten EOL.
Nur aufgeschoben das Ganze.

[andre1980hb]

@thomas-braun
Jetzt zum Beispiel will der Adapter gar nicht starten (openDTU läuft und is erreichbar) Die WR produzieren aber auch gerade nicht (logisch, ist ja dunkel)

Nach dem nodejs Update auf v16.19.1 startete er nun erflogreich

Danke dir und Asche auf mein Haupt, dass ich die Update Pflege etwas vernachläßigt habe

[Thomas Braun]

@haselchen sagte in Test Adapter OpenDTU:

Wenns danach geht ist V16 auch in 6Monaten EOL.

Ist es ja auch (11. Sep 2023). Ist aber zur Zeit halt die für ioBroker vorgesehene Version, die v14 ist es nicht. Warum? Siehe nachfolgendes Posting...

Nach dem nodejs Update auf v16.19.1 startete er nun erflogreich

'nuff said...
Haltet die Kisten halt aktuell...
Die EOL-Termine sind nicht zum Spaß da.

[Thomas Braun]

@haselchen sagte in Test Adapter OpenDTU:

Wenns danach geht ist V16 auch in 6Monaten EOL.
Nur aufgeschoben das Ganze.

Und was ist jetzt deine Schlußfolgerung daraus? Gar nicht anpacken?

[haselchen]

@thomas-braun

Schlußfolgerung ist, dass der TE sich vermutlich in 6 Monaten wieder bei Dir meldet

[Thomas Braun]

@haselchen

dass der TE sich vermutlich in 6 Monaten wieder bei Dir meldet

Warum sollte das erforderlich sein? Im Admin wird zu gegebener Zeit bis dahin eine Empfehlung zu nodeJS@18 erfolgt sein. Der Empfehlung sollte man auch dann zeitnah nachkommen, dann rennste erst gar nicht in solche Situationen wie diese. Ein Update des Systems ist ja kein Hexenwerk.

Wenn ich Adapter schreiben würde, ich hätte da als Mindestanforderung immer die aktuelle Empfehlung drin. Egal ob der auch mit nodejs@4 noch laufen würde.