fhem startet neu bei Aufruf der Weboberfläche

Begonnen von Invers, 28 Juni 2022, 10:05:43

Vorheriges Thema - Nächstes Thema

Invers

Seit heute Nacht habe ich mehrere Neustarts von fhem. Im Log finden sich folgende Meldungen

2022.06.28 02:12:49.857 3: my_callmonitor device opened
Unmatched ( in regex; marked by <-- HERE in m/\bring( <-- HERE 40:([^ ]*)/ at ./FHEM/01_FHEMWEB.pm line 3336.
Signal 15 (TERM) empfangen von ps (3.3.17).
ps:ps/display.c:70: Bitte melden Sie diesen Fehler
2022.06.28 02:12:54.974 3: WEB: port 8083 opened


Die Meldung
Unmatched ( in regex; marked by <-- HERE in m/\bring( <-- HERE 40:([^ ]*)/ at ./FHEM/01_FHEMWEB.pm line 3336.
kam öfter, die andere Meldung
Signal 15 (TERM) empfangen von ps (3.3.17).
ps:ps/display.c:70: Bitte melden Sie diesen Fehler


kam nur einmal.
Jeder Aufruf der Weboberfläche, auch Floorplan, liess fhem neu starten.

Neustart von fhem und Raspi brachte keine Besserung.

Inzwischen geht aber auf wundersame Weise alles wieder.

Weiss jemand, woher diese Fehler kommen und was man dagegen machen kann?

Danke im Voraus.

EDIT:Alle Schaltbefehle wurden schnell und korrekt abgearbeitet.
Pi3B+ mit SSD/ Bullseye | FB7590 AX | 12 x Dect200 | CUL433+868 | SDuino | HM-LAN | 3 x Heizung FHT + FKontakte | KeyMatic + 4 FB | HM Wandtaster 2-fach m. LED | 6 x Türkont. TFK-TI | HM-Bew.-Melder innen | 3 x Smoked. HM-SEC-SD-2

Wernieman

Was ir bei solchen Fehlern immer Einfällt: Wie alt ist die SDCard?
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

Invers

Pi3B+ mit SSD/ Bullseye | FB7590 AX | 12 x Dect200 | CUL433+868 | SDuino | HM-LAN | 3 x Heizung FHT + FKontakte | KeyMatic + 4 FB | HM Wandtaster 2-fach m. LED | 6 x Türkont. TFK-TI | HM-Bew.-Melder innen | 3 x Smoked. HM-SEC-SD-2

Beta-User

Unterstellt, FHEM ist ziemlich aktuell - es wird in dem Code-Bereich ausgewertet, welche set-Befehle es gibt. Afaik gab es dort kurzfristig einen bug, der behoben sein sollte. Ansonsten müßtest du ggf. mal überlegen, welches Modul (bzw. welches Gerät) einen "bring"-Setter kennt?
Ich würde annehmen, dass der Absturz nur stattfindet, wenn das fragliche Device angezeigt werden soll.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Invers

OK, ich frage mal meine Frau, wann sie den Floorplan aufgerufen hat.
fhem ist aktuell.

"Ansonsten müßtest du ggf. mal überlegen, welches Modul (bzw. welches Gerät) einen "bring"-Setter kennt?"

Ich weiss nicht einmal, was ein Bring-Setter ist, geschweige denn, wo ich ihn finden kann.

Ich werde das Ganze mal beobachten, vielleicht passiert es ja nicht wieder.

Danke dir.
Pi3B+ mit SSD/ Bullseye | FB7590 AX | 12 x Dect200 | CUL433+868 | SDuino | HM-LAN | 3 x Heizung FHT + FKontakte | KeyMatic + 4 FB | HM Wandtaster 2-fach m. LED | 6 x Türkont. TFK-TI | HM-Bew.-Melder innen | 3 x Smoked. HM-SEC-SD-2

Beta-User

Zitat von: Invers am 28 Juni 2022, 10:56:16
Ich weiss nicht einmal, was ein Bring-Setter ist, geschweige denn, wo ich ihn finden kann.

Es muss ein Gerät geben, das den Befehl
set <devicename> bring <vermutlich irgendwas an weiteren Argumenten>
kennt:
ZitatUnmatched ( in regex; marked by <-- HERE in m/\bring( <-- HERE 40:([^ ]*)/ at ./FHEM/01_FHEMWEB.pm line 3336.
Und vermutlich wird das nicht "von allein" besser!

Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

rudolfkoenig

Die bemaengelte Zeile ist
        if(int(@c) && $allSets && $allSets =~ m/\b$c[0]:([^ ]*)/) {

und wenn man der Fehlermeldung trauen kann, enthaelt ein Befehl ring(40, ohne b, aber mit Klammer auf, und danach 40.
Allerdings fuehrt das nicht zum Absturz von FHEM, nur zu dieser Warnung.

Falls Befehle mit Klammer sinnvoll sein sollten dann muesste ich FHEMWEB.pm anpassen.
Irgendwelche Meinungen dazu?

ps/display.c hat nichts direkt mit FHEM zu tun, hoechstens wird ps von fhem aufgerufen.
Wird auch nicht den Absturtz von FHEM verursacht haben.

Ich empfehle FHEM im Terminal zu starten, und den Absturz zu provozieren, dann muesste man mehr sehen.

Beta-User

 :o Ah, sorry, das ist ja "\b"...

Was Meinungen angeht: Unmittelbaren Handlungsdruck wegen irgendwelcher Klammern kann ich nicht erkennen. Im Zweifel wird die Funktion ja oft aufgerufen, würde das daher bei der mutmaßlich schnelleren einfachen Variante belassen, falls nicht doch irgendwann mehr solcher Wünsche aufkommen.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Invers

Ich kann ja leider (oder zum Glück) den Fehler nicht mehr hervorrufen.
Wir müssen uns also vermutlich bis zum nächsten Schluckauf gedulden und das Schicksal bitten, nicht wieder nachts auszuflippen.
Danke nochmals.
Pi3B+ mit SSD/ Bullseye | FB7590 AX | 12 x Dect200 | CUL433+868 | SDuino | HM-LAN | 3 x Heizung FHT + FKontakte | KeyMatic + 4 FB | HM Wandtaster 2-fach m. LED | 6 x Türkont. TFK-TI | HM-Bew.-Melder innen | 3 x Smoked. HM-SEC-SD-2