Test Adapter OpenDTU
-
@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! -
@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. -
@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 immer2023-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. -
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?
-
Stell zunächst mal deine nodeJS-Installation auf die empfohlene v16 um.
-
@thomas-braun sollte aber nicht daran liegen
"engines": { "node": ">= 14" -
Ist aber trotzdem eine nicht mehr empfohlene Version und gehört angehoben. In
5wenigen Wochen ist v14 EOL (30. April 2023)
Also kann man das auch jetzt anpacken. -
@thomas-braun
Wenns danach geht ist V16 auch in 6Monaten EOL.
Nur aufgeschoben das Ganze. -
@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
-
@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. -
@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?
-
Schlußfolgerung ist, dass der TE sich vermutlich in 6 Monaten wieder bei Dir meldet
-
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.
-
So habe min. nun auf Node 16 angehoben …
-
@idlebit bis jetzt sieht es gut aus,
was mir noch aufgefallen ist, von ausserhalb per vpn kann man über den Reiter, siehe screen, das Dashboard nicht anzeigen lassen, da kommt nur eine weiße Seite
-
@crunchip Moin das liegt aber dann an deine VPN Einstellungen.
Ich binde dort nur ein IFrame ein, und ich bin auch immer per VPN drauf, daher weiss ich das es geht -
@idlebit ich wüsste nicht was an meiner vpn nicht passen sollte, kann ja alles erreichen
ich seh ne weiße Seite, aber man kann nach oben/unten scrollen -
Fakt ist das dort nur ein iFrame eingebunden ist mit dem Protokoll und der IP die du in den Einstellungen angegeben hast.
Wenn das nicht klappt, kann ich nicht viel machen.
Es müsste eine Meldung in deiner Browserkonsole kommen warum er das bei dir verweigert. -
@idlebit ok, neue Erkenntnis, liegt am Chrome Browser warum auch immer, mit anderen Browsern gehts
-
Hab ich bei mir auch. Wird aber daran liegen, dass ich hier mit Tailscale einen Tunnel auf den iob-Host aufbaue, auf der openDTU aber kein Tailscale-Client installiert ist.
Notiz an mich selbst:
https://tailscale.com/kb/1019/subnets/#step-6-use-your-subnet-routes-from-other-machines
prüfen.
