openhabforum.de


https://openhabforum.de/

openHAB hängt sich immer wieder nach einer Woche auf.

https://openhabforum.de/viewtopic.php?t=7427

Seite 4 von 5

Re: openHAB hängt sich immer wieder nach einer Woche auf.

Verfasst: 28. Okt 2024 22:16
von Snatsch
Screenshot (67).png
Manchmal läuft es Wochen durch ohne Probleme und manchmal startet openhab am Tag 2-3x neu ohne das ich am PC sitze. Gestern habe ich festgestellt das ffmpeg bei der einen Kamera 20% CPU Auslastung benötigt und wenn ich per openhab auf die zweite Cam zugreife die CPU Auslastung auf 160% geht. Aber das openhab neu startet hatte ich ja auch schon bevor ich die 2 Kameras installiert habe. Ich hatte den Pi auch schon an einen Monitor angeschlossen aber es wurde keine Fehlermeldung gebracht.

Re: openHAB hängt sich immer wieder nach einer Woche auf.

Verfasst: 28. Okt 2024 22:25
von udo1toni
Ja, wie gesagt... schwer zu finden (zumindest für unsereins...)
Ich hatte mal vor langer Zeit einen Fehler in einer Rule, der zu einer Endlosschleife führte. Trat logischerweise nur auf, wenn diese Rule ausgelöst wurde, und die Rule hatte mit der Torsteuerung des zweiten Hofs zu tun, dieses Tor wird nur selten genutzt. Entsprechend habe ich eine Weile gebraucht, überhaupt dahinter zu kommen, dass diese Rule verantwortlich war. Den eigentlichen Fehler zu finden war dann eher schnell erledigt, aber ich musste halt "im richtigen Moment" zuschauen :) um das überhaupt mitzubekommen, weil openHAB halt anschließend selbst neu startete...

Re: openHAB hängt sich immer wieder nach einer Woche auf.

Verfasst: 29. Okt 2024 08:07
von lenschith
Hallo Udo,
ich habe bei mir ein ähnliches Problem und tippe auch auf eine Rule oder Script. Aber ich habe das noch nie geschafft den Moment zu erwischen um im Log zu sehen was los ist. Ich merke das immer nur dann, wenn plötzlich mein iCal Calender nicht mehr synchronisiert. Das Thing ist Online und auch ein Restart des Things behebt den Fehler dann nicht. Zu diesem Zeitpunkt funktioniert dann allerdings mehr nicht. z.B. aktvieren vom Hotspot usw.
Leider sehe ich da dann nix auffälliges im Log, da scheint alles sauber zu sein aber es funktioniert halt nicht.
Ich hatte mir jetzt gedacht ich kann mir evtl. was basteln das mir das Log zu diesem Zeitpunkt speichert und ich im Nachgang schauen kann was los war. hast du da ne Idee wie ich das am klügsten anstellen kann.
Mein System ist auf Docker. Eine Idee war ein tail -f auf die OH logs mit | grep -i auf warn und error? macht das sinn oder hast du da einen besseren Denkanstoß?

Gruß Lenschi

Re: openHAB hängt sich immer wieder nach einer Woche auf.

Verfasst: 29. Okt 2024 13:04
von udo1toni
Liegen die Logs nicht ohnehin auf einem Volume? Dann müsstest Du die Logs doch nur von diesem Volume ziehen?
Falls sie nicht auf einem Volume liegen, musst Du schauen, in welchen Pfad die logs innerhalb des Containers geschrieben werden. Dann richtest Du ein extra Volume dafür ein (Container gestoppt) und nach dem Start sollten die Logs dann in diesem Volume landen.

Ansonsten wäre eine Maßnahme, in allen Rules, bei denen das möglich scheint, fürs erste ein logInfo() zu Beginn der Rule einzubauen, dann bekommst Du zumindest mit, wenn eine Rule ständig neu gestartet wird. Natürlich muss die Meldung eindeutig auf die Rule bezogen sein, also so was wie

Code: Alles auswählen

logInfo("trigger","Rule <rulename> durch {} getriggert.",triggeringItemName)
<rulename> musst Du leider händisch einfügen, da gibt es keine implizite Variable für, und triggeringItemName ist nur gültig bei Rules, die durch Item ... received.../changed getriggert wurden. Hat die Rule hingegen Member of als Trigger, müsstest Du triggeringItem.name verwenden, um das Item zu identifizieren, ähnliche Variablen gibt es auch für Thing und Channel Ereignisse.

Re: openHAB hängt sich immer wieder nach einer Woche auf.

Verfasst: 1. Nov 2024 12:16
von Quautiputzli
Quautiputzli hat geschrieben: ↑27. Okt 2024 15:45

Aber über den browser komm ich nicht weiter:
Screenshot 2024-10-27 134613.png
So, ich habe es nun nochmal versucht. Ich hatte gelesen, dass es Probleme machen kann, wenn jemand während der Installation über den browser auf openHAB zugreifen will. Ich habe nun also nochmal die SD Karte ganz frisch beschrieben, und alle browserfenster geschlossen, die Karte eingesetzt und den Raspi rödeln lassen. Erst nach über einer Stunde habe ich dann mal nachgesehen, und dann kam auch die Startseite mit Anlegen des ersten Users. Ich bin nun direkt auf OH 4.2.2 gegangen. Das backup das ich auf die SD-Karte gespielt hatte wurde jedoch nicht eingespielt, weiß nicht warum.

Ich habe dann erst mosquitto und zigbee2mqtt über openhabian installiert. Das einspielen des zigbee2mqtt backups hat erst nicht geklappt, da musste ich erst den Besitzer dieser Dateinen auf openhabian ändern. Erst dannach habe ich über openhabian-conf das backup eingespielt. Das lief diesmal erstaunlich gut. Das awattar Binding musste ich noch händisch installieren, außerdem auch die awattar bridge neu anlegen. Die Uhrzeit geht wohl noch um eine Stunde nach, zumindest im frontail. Hier gibt es wohl auch mehrere Uhrzeiten im System.

Und das homeconnect binding mag wohl gar nicht mehr.

Und bei ein paar numbers ist die Einheit weg, da hab ich aber gelesen, dass es dort eine Änderung gab.

Nun muss ich mal sehen, ob das ganze durchläuft, ohne sich wieder nach einer Woche aufzuhängen.

Re: openHAB hängt sich immer wieder nach einer Woche auf.

Verfasst: 1. Nov 2024 23:27
von udo1toni
Ich drücke mal die Daumen... :)

Uhrzeit: Es gibt drei Zeiteinstellungen, die openHAB betreffen:
1. Systemzeit. Zeitzone z.B. mittels sudo dpkg-reconfigure tzdata einstellen.
2. Die openHAB Zeit, die per NTP Binding rein kommt (ich nenne sie Mal Bus-Zeit, da über Addon angeliefert). ntp Thing korrekt konfigurieren :)
3. (der wichtigste Punkt) Die Zeit, mit der Die Java Umgebung läuft. Die wird über /etc/default/openhab und den Parameter EXTRA_JAVA_OPTS gesteuert.

Code: Alles auswählen

EXTRA_JAVA_OPTS="-Duser.timezone=Europe/Berlin"
Eigentlich soll openHABian automatisch die eingestellte Zeitzone des Systems verwenden, aus irgendeinem Grund tut das aber seit einiger Zeit nicht mehr (zuverlässig)
Alle drei Stellen sind nur teilweise abhängig voneinander, die Zeitzonen können jedenfalls komplett unabhängig voneinander gesetzt zu werden,

Re: openHAB hängt sich immer wieder nach einer Woche auf.

Verfasst: 2. Nov 2024 13:43
von Quautiputzli
Hi, hab den Paramter hinzugefügt, passt nun.

Ich hab hier noch einige rules über die Oberfläche angelegt, die dann ein javascript auslösen, wie z.B.:

Code: Alles auswählen

events.postUpdate("PV_HausVerbrauch",itemRegistry.getItem("P_PV_Haus").getState() + itemRegistry.getItem("P_PV_Schupfa").getState() + itemRegistry.getItem("P_PV_Garage").getState() + itemRegistry.getItem("FroniusZahlerKaskade").getState() + itemRegistry.getItem("PV_Akku").getState()  );
das verusracht nun Fehler:

Code: Alles auswählen

2024-11-02 13:37:57.352 [ERROR] [.script.javascript.house_consumption] - Failed to execute script: ReferenceError: "events" is not defined
        at <js>.:program(<eval>:1)
        at org.graalvm.polyglot.Context.eval(Context.java:399)
        at com.oracle.truffle.js.scriptengine.GraalJSScriptEngine.eval(GraalJSScriptEngine.java:458)
        at com.oracle.truffle.js.scriptengine.GraalJSScriptEngine.eval(GraalJSScriptEngine.java:426)
        at java.scripting/javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:262)
        ... 21 more
2024-11-02 13:37:57.354 [ERROR] [internal.handler.ScriptActionHandler] - Script execution of rule with UID 'house_consumption' failed: org.graalvm.polyglot.PolyglotException: ReferenceError: "events" is not defined

Außerdem gibt es wohl Probleme mit den "historischen Werten" wie:

Code: Alles auswählen

(PV_Battery_SOC.state > 65|% && gPower.averageSince(now.minusMinutes(5)).intValue > 1500)
es folgt der Fehler:

Code: Alles auswählen

2024-11-02 13:38:00.807 [ERROR] [internal.handler.ScriptActionHandler] - Script execution of rule with UID 'WP_awattar-6' failed: 'intValue' is not a member of 'org.openhab.core.types.State'; line 150, column 44, length 49 in WP_awattar
Ich denke hier hat sich die Schreibweise geändert, ich glaube man muss nun irgendwas mit persistance schreiben oder?

Gibt es hier eine Art Übersicht, wie die neuen Schreibweisen sind?

Re: openHAB hängt sich immer wieder nach einer Woche auf.

Verfasst: 2. Nov 2024 22:11
von udo1toni
JavaScript: Hast Du die Rules mittels Blockly erstellt? Dann bitte einmal die Rule in der UI öffnen und neu speichern.
Ansonsten auf die Schnelle:

1. statt itemRegistry schreibst Du items (also statt alt itemRegistry.getItem("P_PV_Haus") jetzt items.getItem("P_PV_Haus"))

2. Ein Status ist ein Status ist ein Status.
Das war schon immer so :) aber bisher hat openHAB sich oftmals extrem gnädig gezeigt und stillschweigend wo möglich entsprechende Typwandlungen vorgenommen.
Jetzt solltest Du (bei Number Items) statt .getState() besser .numericState verwenden (und wenn es um den Status als solchen geht, statt .getState() nun .state)

3. postUpdate und sendCommand nicht mehr als Action nutzen:

Code: Alles auswählen

items.getItem('PV_HausVerbrauch').postUpdate(...);
Was die Persistence betrifft, scheint das eine Zeile aus einer DSL Rule zu sein...
Vermutlich fehlen da noch Informationen, um das zu klären... Welcher Itemtyp ist gPower? Welche Persistence wird verwendet?
Eventuell bezieht sich die Fehlermeldung auch gar nicht auf die Persistence, sondern auf den vorherigen Vergleich, denn, siehe oben (2.). Mutmaßlich müsstest Du hier eher

Code: Alles auswählen

if((PV_Battery_SOC.state as QuantityType<Dimensionless>) > 65|% && gPower.averageSince(now.minusMinutes(5)).intValue > 1500)
schreiben, ist aber nur geraten.
Falls gPower ein QuantityType Item ist (z.B. Group:Number:Power) wird auch hier (vor .intValue) die Einheit mit übergeben, .intValue sollte diese ganz normal strippen, so dass der Vergleich dann klappt, andererseits braucht es das .intValue ja gar nicht, wenn man die Einheit wie im ersten Teil des Vergleichs mit angibt:

Code: Alles auswählen

if((PV_Battery_SOC.state as QuantityType<Dimensionless>) > 65|% && gPower.averageSince(now.minusMinutes(5)) > 1.5|kW)

Re: openHAB hängt sich immer wieder nach einer Woche auf.

Verfasst: 2. Nov 2024 22:25
von Quautiputzli
udo1toni hat geschrieben: ↑2. Nov 2024 22:11 JavaScript: Hast Du die Rules mittels Blockly erstellt?

1. statt itemRegistry schreibst Du items (also statt alt itemRegistry.getItem("P_PV_Haus") jetzt items.getItem("P_PV_Haus"))

2. Ein Status ist ein Status ist ein Status.
Das war schon immer so :) aber bisher hat openHAB sich oftmals extrem gnädig gezeigt und stillschweigend wo möglich entsprechende Typwandlungen vorgenommen.
Jetzt solltest Du (bei Number Items) statt .getState() besser .numericState verwenden (und wenn es um den Status als solchen geht, statt .getState() nun .state)

3. postUpdate und sendCommand nicht mehr als Action nutzen:

Code: Alles auswählen

items.getItem('PV_HausVerbrauch').postUpdate(...);
Nicht mit Blockly, über die UI als "execute an inline script --> Javascript

Ich habe es nunmal so gemacht:

Code: Alles auswählen

items.PV_HausVerbrauch.postUpdate(items.P_PV_Haus.numericState + items.P_PV_Schupfa.numericState + items.P_PV_Garage.numericState + items.FroniusZahlerKaskade.numericState + items.PV_Akku.numericState );
scheint auch zu funktionieren.

Re: openHAB hängt sich immer wieder nach einer Woche auf.

Verfasst: 2. Nov 2024 22:41
von Quautiputzli
udo1toni hat geschrieben: ↑2. Nov 2024 22:11
...., scheint das eine Zeile aus einer DSL Rule zu sein...
Vermutlich fehlen da noch Informationen, um das zu klären... Welcher Itemtyp ist gPower? Welche Persistence wird verwendet?
Eventuell bezieht sich die Fehlermeldung auch gar nicht auf die Persistence, sondern auf den vorherigen Vergleich, denn, siehe oben (2.). Mutmaßlich müsstest Du hier eher

Code: Alles auswählen

if((PV_Battery_SOC.state as QuantityType<Dimensionless>) > 65|% && gPower.averageSince(now.minusMinutes(5)).intValue > 1500)
schreiben, ist aber nur geraten.
Falls gPower ein QuantityType Item ist (z.B. Group:Number:Power) wird auch hier (vor .intValue) die Einheit mit übergeben, .intValue sollte diese ganz normal strippen, so dass der Vergleich dann klappt, andererseits braucht es das .intValue ja gar nicht, wenn man die Einheit wie im ersten Teil des Vergleichs mit angibt:

Code: Alles auswählen

if((PV_Battery_SOC.state as QuantityType<Dimensionless>) > 65|% && gPower.averageSince(now.minusMinutes(5)) > 1.5|kW)
Hier wurde ja gerade das "intValue" als Fehler angezeit, deshalb habe ich es dort einfach wegelassen, und mit Einheit geschrieben, so wie du forgeschlagen hast:

Code: Alles auswählen

if (PV_Battery_SOC.state > 65|% && gPower.averageSince(now.minusMinutes(5)) > 1500|W)
Das scheint zu funktionieren.

Aber mit dem % beim SOC habe ich dennoch ein Problem. Die Prozentwerte scheinen nun ja grundsätzlich <1 zu sein. Das macht mir nun etwas Probleme. Das kommt ja in meinem Fall vom Fronius Wechselrichter über http. Das sieht ursprünglich so aus:

Code: Alles auswählen

{
   "Body" : {
      "Data" : {
         "0" : {
            "Controller" : {
               "Capacity_Maximum" : 8960,
               "Current_DC" : 0,
               "DesignedCapacity" : 8960,
               "Details" : {
                  "Manufacturer" : "BYD",
                  "Model" : "BYD Battery-Box HV",
                  "Serial" : "401021908-00122"
               },
               "Enable" : 1,
               "StateOfCharge_Relative" : 7,
               "Status_BatteryCell" : 3,
               "Temperature_Cell" : 23.149999999999999,
               "TimeStamp" : 1730583159,
               "Voltage_DC" : 342
            },
            "Modules" : []
         }
      }
   },
   "Head" : {
      "RequestArguments" : {
         "DeviceClass" : "Storage",
         "Scope" : "System"
      },
      "Status" : {
         "Code" : 0,
         "Reason" : "",
         "UserMessage" : ""
      },
      "Timestamp" : "2024-11-02T22:32:43+01:00"
   }
}
--> also 7

Ist im Channel auch als % gekennzeichnet:

Code: Alles auswählen

  - id: fronius_h_akku_SOC
    channelTypeUID: http:number
    label: Akku SOC
    configuration:
      mode: READWRITE
      unit: "%"
      stateExtension: GetStorageRealtimeData.cgi?Scope=System
      stateTransformation: JSONPATH:$.Body.Data.0.Controller.StateOfCharge_Relative
Wenn ich mir das Item in der Developer Sidebar anschaue mit "=items.PV_Battery_SOC" wird folgendes angezeigt:

Code: Alles auswählen

{ "state": "0.07", "displayState": "7.0 %", "numericState": 0.07, "unit": "one", "type": "Quantity" }
Der state ist also 0,07
In der rule mit:

Code: Alles auswählen

if (PV_Battery_SOC.state > 65|% && gPower.averageSince(now.minusMinutes(5)) > 1500|W)
scheint das aber richtig verarbeitet zu werden. Muss ich noch genau checken. Aber was ich auf den ersten Blick gesehen habe passt das.

Ich habe aber nun an einer anderen Stelle in der rule das Problem, dass ich nun gerne genau den Wert 7 weitergeben will. In OH3.2 hat das auch noch so funktioniert. Nun wird aber immer 0,07 weitergegeben, wass ja nicht stimmt. Wie kann ich das umgehen? Muss ich nun "händisch" immer mal Hundert rechnen? "displayState" scheint in der Rule nicht zu funktionieren. So sieht die Problemstelle aus:

Code: Alles auswählen

Battsett_Eingabewert.sendCommand("192.168.2.109 r "+(PV_Battery_SOC.state)+"")
Vielen Dank für die Hilfe.
Alle Zeiten sind UTC+02:00
Seite 4 von 5

Powered by phpBB® Forum Software © phpBB Limited

Deutsche Übersetzung durch phpBB.de