[gefixed] Heutiges CUL_HM update defekt

[martinp876]

Noch nicht. Es gab kein Update.

[martinp876]

so, vor dem update noch einmal ein aufruf zum Testen.
Leider habe ich peerSmart noch nicht einsatzbereit....

HMConfig sollte bei euch schon auf dem aktuellen Stand sein (seit Wochen in SVN)
Es gibt interne Umstellungen aber auch bug behebungen beim Register lesen

[det.]

  nach erstem Eindruck - geht alles, auch die virtuellen Türkontakte, Rauchmelder Teamdevice. Danke und Daumen hoch!
eine Stunde später nach inzwischen 2 Totalabstürzen - da ist wohl doch noch was. Sorry, verbose ist bei mir nur auf 2, daher kann ich nur mit folgendem aus dem LOG dienen:

Can't use string ("33") as an ARRAY ref while "strict refs" in use at ./FHEM/10_CUL_HM.pm line 10000.

[Pfriemler]

wäre auch mutig, bin aber leider die nächsten vier Tage von meinem FHEM getrennt ... sorry...

[martinp876]

Keine Tester?  Bei mir läuft es nun schon ein paar Wochen.  Keine Probleme.
Mit der FehlerMeldung kann ich wenig anfangen.

Mein Pi hatte einen Aussetzer und musste gebootet werden.  Datenbank Problem. Nicht alles ist culhm..

[hoppel118]

Moinsen,

danke für die Erinnerung. Wollte auch noch testen. Reicht es das Modul aus Beitrag 168 zu installieren oder gibt es schon was aktuelleres?

Dann werde ich das heute nochmal installieren.

Viele Grüße Hoppel

[Beta-User]

Hab's eben auch getestet, FHEM ist mir grade mit der Fassung v. 1710.02. (Edit: aus Beitrag 168) auch abgeschmiert, ich kann aber nicht mit Sicherheit sagen, dass es an CUL_HM liegt.

Details:
Fhem war auf dem svn-Stand von heute morgen, Neustart ohne Probleme. Dann ca. eine halbe Stunde später die betreffende CUL_HM installiert, FHEM neu gestartet. Lief erst mal alles. Eben war dann FHEMWEB nicht erreichbar, daher Neustart.

Log an der betreffenden Stelle:

Code Auswählen Erweitern

2019.02.21 08:31:55 3: CUL_HM set Jalousie_Links on
Can't use string ("65") as an ARRAY ref while "strict refs" in use at ./FHEM/10_CUL_HM.pm line 10000.
2019.02.21 08:59:15 1: FritzFhemFon[6761], can´t find my parent 6759 in process list !
Died at ./FHEM/96_SIP.pm line 386.
2019.02.21 09:12:39 1: PERL WARNING: "my" variable $symbol_string masks earlier declaration in same scope at ./FHEM/99_myUtils_Homematic.pm line 78.
Das klingt eigentlich danach, als wäre CUL_HM nicht der Verursacher, sondern das SIP-Modul. Das sagt zu version: "96_SIP.pm 17070 2018-07-31 19:02:39Z Wzut"

Vor dem update hatte ich keine Probleme mit Abstürzen, das SIP-Gerät existiert - wie die CUL_HM-Geräte schon lange. FHEM hat allerdings jüngst eine ganz erhebliche Anzahl von Neustarts gehabt, weil ich die ganze Entwicklung bei MQTT2 mitbekommen wollte, kann daher nichts zum Lanzeitverhalten vorher sagen.

Hoffe, das hilft. Jetzt mache ich erst mal die Rolle rückwärts um zu sehen, ob dann dasselbe passiert.

[hoppel118]

So, habe jetzt auch vor ca. 30 min mein FHEM mal auf die aktuellste Version gehoben. Danach das Modul "10_CUL_HM.pm" aus Beitrag 168 installiert und fhem neugestartet. Mein global verbose läuft auf 3. Ich habe folgende Geräte in verschiedenen Mengen im Einsatz:

• HM-WDS10-TH-O
• HM-WDS40-TH-I
• HM-WDS40-TH-I-2
• HM-ES-PMSw1-Pl
• HM-CC-RT-DN

Ich sehe weder im syslog, noch im fhem logfile irgendwelche Fehlermeldungen.

Folgende Befehle ergeben bei mir keine Ausgaben, also alles gut (Ich weiß nicht wo dieses "mId" geloggt wird, so dass ich beide logs geprüft habe):

Code Auswählen Erweitern

root@omv4:~# cat /opt/fhem/log/fhem-2019-02.log | grep mId
root@omv4:~# cat /var/log/syslog | grep mId

Oder wird das nicht in den logs hinterlegt?

In meiner fhem.cfg sehe ich auch nur folgendes:

Code Auswählen Erweitern

root@omv4:~# cat /opt/fhem/fhem.cfg | grep mId
attr HMUSB hmId XXXXXX
attr HMUSB2 hmId XXXXXX

Meine subTypes sind auch alle noch da:

Code Auswählen Erweitern

root@omv4:~# cat /opt/fhem/fhem.cfg | grep subType
attr VCCU subType virtual
attr OG_Badezimmer_Thermostat subType thermostat
attr OG_Buero_Thermostat subType thermostat
attr OG_Flur_Thermostat subType thermostat
attr OG_Kueche_Thermostat subType thermostat
attr OG_SZ_Thermostat subType thermostat
attr OG_WZ_Essbereich_Thermostat subType thermostat
attr OG_WZ_Wohnbereich_Thermostat subType thermostat
attr OG_Badezimmer_Sensor subType THSensor
attr OG_WZ_Sensor subType THSensor
attr Aussen_Nord_Sensor subType THSensor
attr Aussen_Sued_Sensor subType THSensor
attr OG2_Dachboden_Strom_Server subType powerMeter
attr OG_Badezimmer_Deckenlampe subType ctdimmer
attr OG_Badezimmer_Strahler subType ctdimmer
attr OG_Buero_Deckenlampe subType ctdimmer
attr OG_WZ_Wohnbereich_Stehlampe_oben subType extcolordimmer
attr OG_WZ_Wohnbereich_Stehlampe_mitte subType extcolordimmer
attr OG_WZ_Wohnbereich_Stehlampe_unten subType extcolordimmer
attr OG_WZ_Wohnbereich_Deckenlampe_rechts subType extcolordimmer
attr OG_WZ_Wohnbereich_Deckenlampe_links subType extcolordimmer
attr OG_WZ_Wohnbereich_Strahler_vorn subType extcolordimmer
attr OG_WZ_Wohnbereich_Strahler_hinten subType extcolordimmer
attr OG_WZ_Essbereich_Deckenlampe_links subType extcolordimmer
attr OG_WZ_Essbereich_Deckenlampe_mitte subType extcolordimmer
attr OG_WZ_Essbereich_Deckenlampe_rechts subType extcolordimmer
attr OG_WZ_Essbereich_Boardlampe_links subType extcolordimmer
attr OG_WZ_Wohnbereich_Stehlampe subType extcolordimmer
attr OG_WZ_Wohnbereich_Deckenlampe subType extcolordimmer
attr OG_WZ_Wohnbereich_Strahler subType extcolordimmer
attr OG_WZ_Essbereich_Deckenlampe subType extcolordimmer
attr OG_WZ_Essbereich_Boardlampe subType extcolordimmer
attr Roborock subType VacuumCleaner

Gibt es etwas, wonach ich speziell suchen soll?

Ansonsten sieht soweit erstmal alles gut aus. Alle Readings werden aktualisiert, etc. Ich melde mich heute Abend nochmal!


Ich möchte an dieser Stelle auch nochmal für die stetige Weiterentwicklung des Moduls bedanken!

Viele Grüße Hoppel

[hoppel118]

Hab's eben auch getestet, FHEM ist mir grade mit der Fassung v. 1710.02. (Edit: aus Beitrag 168) auch abgeschmiert, ich kann aber nicht mit Sicherheit sagen, dass es an CUL_HM liegt.

Details:
Fhem war auf dem svn-Stand von heute morgen, Neustart ohne Probleme. Dann ca. eine halbe Stunde später die betreffende CUL_HM installiert, FHEM neu gestartet. Lief erst mal alles. Eben war dann FHEMWEB nicht erreichbar,

Hoffe, das hilft. Jetzt mache ich erst mal die Rolle rückwärts um zu sehen, ob dann dasselbe passiert.

OK, habe das anscheinend das gleiche Problem. Ziemlich exakt eine halbe Stunde nach dem Start meines fhem Services, war dann FHEMWEB nicht mehr erreichbar. systemctl gibt mir folgenden Status:

Code Auswählen Erweitern

root@omv4:~# systemctl status fhem
● fhem.service - FHEM Home Automation
   Loaded: loaded (/etc/systemd/system/fhem.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Thu 2019-02-21 11:20:44 CET; 28min ago
  Process: 388 ExecStart=/usr/bin/perl fhem.pl fhem.cfg (code=exited, status=0/SUCCESS)
Main PID: 389 (code=exited, status=255)
      CPU: 20.486s

Feb 21 10:50:43 omv4 systemd[1]: Starting FHEM Home Automation...
Feb 21 10:50:43 omv4 systemd[1]: Started FHEM Home Automation.
Feb 21 11:20:44 omv4 systemd[1]: fhem.service: Main process exited, code=exited, status=255/n/a
Feb 21 11:20:44 omv4 systemd[1]: fhem.service: Unit entered failed state.
Feb 21 11:20:44 omv4 systemd[1]: fhem.service: Failed with result 'exit-code'.

Wenn ich den fhem service stoppe und neu starte funktioniert FHEMWEB wieder.

Dann werde ich jetzt auch erstmal die Rolle rückwärts machen. Backup einspielen und dann erstmal nur FHEM auf die aktuellste Version updaten, um den Fehler eingrenzen zu können.

Gruß Hoppel

[hoppel118]

Das Modul "96_SIP.pm" habe ich übrigens nicht im Einsatz. Das dürfte doch dann eigentlich nicht der Fehlerverursacher sein, oder?

EDIT: Backup ist wiederhegestellt und fhem auf die aktuelle Version geupdated.

Code Auswählen Erweitern

2019.02.21 12:04:06 1: update finished, "shutdown restart" is needed to activate the changes.

Mal sehen, wie es um 12:35 Uhr aussieht.

Gruß Hoppel

[Beta-User]

Das Modul "96_SIP.pm" habe ich übrigens nicht im Einsatz. Das dürfte doch dann eigentlich nicht der Fehlerverursacher sein, oder?

Es könnte auch irgendeine Wechselwirkung sein. Bei verbose 3 und höher müßte eigentlich was im log gestanden haben; das wäre aufschlußreicher als die systemctl-Info.

Jedenfalls läuft hier FHEM mit den aktuellsten Modulen und der svn-CUL_HM-Version seit ca. 3 Stunden vor sich hin, sieht also schon so aus, als wäre CUL_HM jedenfalls irgenwie beteiligt gewesen.

[hoppel118]

Es könnte auch irgendeine Wechselwirkung sein. Bei verbose 3 und höher müßte eigentlich was im log gestanden haben; das wäre aufschlußreicher als die systemctl-Info.

verbose 3 habe ich. Leider aber nicht nach dem FHEMWEB-Absturz nochmal ins Log geschaut, um zu prüfen, ob da noch ein Fehler geloggt wurde, sondern direkt die Rolle rückwärts. Wenn um 12:40 Uhr noch alles läuft, spiele ich nochmal die aktuelle CUL_HM Version ein.

Jedenfalls läuft hier FHEM mit den aktuellsten Modulen und der svn-CUL_HM-Version seit ca. 3 Stunden vor sich hin, sieht also schon so aus, als wäre CUL_HM jedenfalls irgenwie beteiligt gewesen.

Ist "svn-CUL_HM-Version" die Version aus Beitrag 168? Wenn nicht kannst du die aktuellste Version bitte nochmal hier teilen? Oder ist die aktuellste "svn-CUL_HM-Version", die die man mit dem Update erhält?

Danke und Gruß Hoppel

[hoppel118]

So, um 12:53 läuft mein FHEMWEB noch. Es scheint also tatsächlich mit der in Beitrag 168 verlinkten Version zusammenzuhängen.

Ich könnte jetzt nochmal die in Beitrag 168 verlinkte Version installieren, um zu schauen, ob der Fehler dann wieder auftritt und dann eben nochmal einen Blick ins Log werfen.

Wo soll ich genau nach Fehlern schauen? Reicht der Blick ins FHEM log? Soll ich das verbose Level auf 4 oder 5 erhöhen?

Ich werde das Update irgendwann heute Nachmittag einspielen, bzw. wenn ich Antworten auf meine Fragen habe. Vorher macht das ja nur bedingt Sinn...

Gruß Hoppel

[Beta-User]

Ist "svn-CUL_HM-Version" die Version aus Beitrag 168? Wenn nicht kannst du die aktuellste Version bitte nochmal hier teilen? Oder ist die aktuellste "svn-CUL_HM-Version", die die man mit dem Update erhält?

Gemeint war die, die man mit dem update erhält. (Der Weg ist Entwickler läd ins svn, der Stand um kurz vor 8:00 Uhr geht ins update, individuelles FHEM holt sich, was neu ist; dabei müßte der Zeitstemple der Datei entscheidend sein).

verbose 3 habe ich. Leider aber nicht nach dem FHEMWEB-Absturz nochmal ins Log geschaut, um zu prüfen, ob da noch ein Fehler geloggt wurde, sondern direkt die Rolle rückwärts. Wenn um 12:40 Uhr noch alles läuft, spiele ich nochmal die aktuelle CUL_HM Version ein.

Das Log bleibt erhalten. Kannst also auch jetzt noch schauen, was um die Zeit des Absturzes rum passiert ist, auch ohne das nochmal zu provozieren.

Entscheidend sind die Zeilen vor "Server started...." (da gibt es einige Zeilen davor, die zeitlich dem Neustart zuzuordnen sind; die sind noch uninteressant; du solltest dich allg. mal mit deinem log beschäftigen, da stehen oft "interessante" Sachen drin).

Wenn du mehr zur Absturzursache wissen wolltest, wäre stacktrace das Stichwort (habe ich aber bisher auch nicht genutzt). Würde aber mal auf Martin warten, ob der schon eine Idee hat oder das anfordert (dann mache ich auch gerne die Premiere).

[Wzut]

2019.02.21 08:59:15 1: FritzFhemFon[6761], can´t find my parent 6759 in process list !
Died at ./FHEM/96_SIP.pm line 386.

Ich will das SIP Modul als mein Baby zwar nicht heilig sprechen , aber die Erklärung des obigen logs ist simpel:
[6761] = Es handelt sich nicht um das eigentliche Sip Device sondern um einen Child Prozess mit der PID 6791.
Der/das Child schaut wenn es ein Dauerläufer ist ( z.B. aktiver Listen Prozess ) regelmäßig ob es seine Eltern  ( PID = 6759) noch gibt.
Stürzt FHEM jetzt hab sind die Eltern zwar tot das Kind lebt als Waise aber weiter. Bemerkt es diesen Umstand folgt es freiwillig mittels "Die" seiner Verwandschaft, d.h. in meinen Augen alles im grünen Bereich und wie es sein soll.