FHEM Abstürze mit MQTT Perl Version 5.24.1 - Debian Stretch Patchlevel 20181226

[sbiermann]

Holas,
ich habe mein FHEM Installation umgezogen in einen Raspberry Pi Kubernetes Cluster. Dabei bin ich von Debian Wheezy (alter Rechner war ein Pi 1) auf Debian Stretch Patchlevel 20181226 gewechselt. Es läuft auch soweit sehr stabil und funktioniert alles wie es soll. Mit einer Ausnahme ich habe öfters Abstürze von FHEM mit Exitcode 255, also das meldet Perl jedenfalls. Im Log sehe ich nur folgendes:

Code Auswählen Erweitern

2019.02.17 09:02:19 1: [Freezemon] myFreezemon: possible freeze starting at 09:02:18, delay is 1.216 possibly caused by: no bad guy found :-(
2019.02.17 09:02:21 1: [Freezemon] myFreezemon: possible freeze starting at 09:02:20, delay is 1.114 possibly caused by: no bad guy found :-(
decode_string: insufficient data at /usr/local/share/perl/5.24.1/Net/MQTT/Message/Subscribe.pm line 41.
2019.02.17 09:02:31 1: PERL WARNING: Subroutine HandleTimeout redefined at ./FHEM/99_apptime.pm line 23.
2019.02.17 09:02:31 1: PERL WARNING: Subroutine CallFn redefined at ./FHEM/99_apptime.pm line 57.
2019.02.17 09:02:39 1: Including ./fhem.cfg
2019.02.17 09:02:40 2: Deleting fhem-2019-02-11.log
2019.02.17 09:02:41 3: telnetPort: port 7072 opened
2019.02.17 09:02:46 3: WEB: port 8083 opened
2019.02.17 09:02:47 2: eventTypes: loaded 2980 events from ./log/eventTypes.txt


Code Auswählen Erweitern

2019.02.17 09:03:57 3: CUL_HM set HM_6233CB statusRequest
2019.02.17 09:27:57 1: 192.168.1.101:60128 reappeared (Receiver)
2019.02.17 10:03:22 1: [Freezemon] myFreezemon: possible freeze starting at 10:03:17, delay is 5.114 possibly caused by: no bad guy found :-(
2019.02.17 10:11:31 3: CUL_HM set HM_3B5C89_Sw_02 on
decode_string: insufficient data at /usr/local/share/perl/5.24.1/Net/MQTT/Message/Subscribe.pm line 41.
2019.02.17 10:16:15 1: PERL WARNING: Subroutine HandleTimeout redefined at ./FHEM/99_apptime.pm line 23.
2019.02.17 10:16:15 1: PERL WARNING: Subroutine CallFn redefined at ./FHEM/99_apptime.pm line 57.
2019.02.17 10:16:22 1: Including ./fhem.cfg
2019.02.17 10:16:23 3: telnetPort: port 7072 opened
2019.02.17 10:16:28 3: WEB: port 8083 opened
2019.02.17 10:16:29 2: eventTypes: loaded 2980 events from ./log/eventTypes.txt
2
Wäre es möglich das es an der MQTT Version von Perl liegt? Ich habe sonst im Moment keinen anderen Ansatzpunkt oder Idee woran es liegen könnte. Bei MQTT habe ich viele Geräte die darüber Daten senden und empfangen.

[rudolfkoenig]

Ich kann nur anbieten, auf meinem MQTT2_CLIENT (oder gar MQTT2_SERVER) umzuziehen, diese Module werden (im Gegensatz zu MQTT) gut betreut.
Ist aber (je nach Installation) nicht unbedingt trivial.

[hexenmeister]

Nach dem MQTT-Module "durch mehrere Hände" gegangen sind, habe ich diese irgendwann übernommen und einen oder anderen Fehler ausgemerzt.
Leider bin ich dennoch auch nicht so tief in der Materie drin, dass ich eine eindeutige Aussage zu dem Fehler hier treffen könnte. Bei mir funktionieren diese weit Jehren ohne jeglichen Problemen (eigentlich nur das MQTT-IO-Modul, MQTT_DEVICE und MQTT_BRIDGE verwende ich praktisch nicht mehr).
Nach der Erscheinen von MQTT2-Modulen sehe ich die 'alten' MQTT als depricated und würde bei einer Neuinstallation oder eben bei schwer lösbaren Problemem auf MQTT2-Module umstellen. Vlt. wird der EInsatz von MQTT_GENERIC_BRIDGE den Umstieg etwas erleichter. Die Bridge funktioniert gleichzeitig mit den alten und neuen Modulen. Vlt. könnte man die Umstellung auf diesem Wege etwas erleichtern.

[sbiermann]

Kann man denn den MQTT2_CLIENT mit einen externen Broker betreiben? Ich dachte es wäre Bedingung das man den MQTT2_SERVER nutzt und das kommt bei mir nicht in Frage. Daher habe ich mich bisher auch nicht weiter mit dem MQTT2 beschäftigt.

Es sind zwar relativ viele Sachen die mittlerweile über MQTT laufen, aber ein Umzug ist Schrittweise sicherlich machbar, sofern beide (altes und neues MQTT Modul) zusammen funktionieren.

[rudolfkoenig]

Man sollte MQTT2_CLIENT _nur_ mit einem externen Broker betreiben.
MQTT2_CLIENT mit MQTT2_SERVER zu betreiben ist vergleichbar mit sich selbst anrufen, um die Gedanken mitzuteilen.

Nachtrag zur Klaerung:
Wenn jemand es nicht besser weiss, dann legt man in FHEM eine MQTT2_SERVER Instanz an, und konfiguriert diesen in den MQTT Geraeten (Tasmota/Shelly/zigbee2mqtt/etc) als "MQTT Server". Daraufhin legt FHEM automatisch MQTT2_DEVICE Instanzen an, die zwar automatisch alle Readings bekommen, aber fuer die set Befehle noch ein manuelles "set attrTemplate" benoetigen.

Wenn jemand auf einem externen MQTT Server besteht, der verwendet MQTT2_CLIENT. In diesem Fall ist autocreate nur begrenzt nutzbar (fuer zigbee2mqtt artige Bridge-Geraete), im Normalfall muss man die MQTT2_DEVICE Instanzen selbst anlegen, so wie mit dem guten alten MQTT Modul. Vom attrTemplate kann man aber auch in diesem Fall profitieren.

[sbiermann]

Ich habe mal probehalber 2 verschiedene Devices zusätzlich als MQTT2_DEVICE definiert. Eines klappt hervorragend, beim zweiten kommen absolut keine Werte an.
Nachfolgend das List vom alten MQTT Device

Code Auswählen Erweitern

Internals:
   FUUID      5c45c690-f33f-9d23-26fb-01117fdfa93d6b8b
   IODev      MQTTBroker
   NAME       bme1
   NR         245
   STATE      T: 21.7 H: 34.5 V: 3.6
   TYPE       MQTT_DEVICE
   READINGS:
     2019-02-20 14:26:30   dewpoint        5.4
     2019-02-20 14:26:30   humidity        34.5
     2019-02-20 14:26:30   pressure        990.1
     2019-02-20 14:26:30   temperature     21.7
     2019-02-20 14:26:30   transmission-state incoming publish received
     2019-02-20 14:26:30   voltage         3.6
   helper:
     bm:
       MQTT::DEVICE::Attr:
         cnt        9
         mAr       
         max        0
         tot        0
       MQTT::DEVICE::Define:
         cnt        1
         mAr        HASH(0x3a8d9c8); bme1 MQTT_DEVICE
         max        2
         tot        2
       MQTT::DEVICE::Set:
         cnt        315
         mAr       
         max        0
         tot        0
   message_ids:
   sets:
   subscribe:
     lora/bme1/+/value
     lora/bme1/humidity/value
     lora/bme1/pressure/value
     lora/bme1/temperature/value
     lora/bme1/voltage/value
   subscribeExpr:
     ^lora\/bme1\/([^/]+)\/value$
     ^lora\/bme1\/humidity\/value$
     ^lora\/bme1\/pressure\/value$
     ^lora\/bme1\/temperature\/value$
     ^lora\/bme1\/voltage\/value$
   subscribeQos:
     lora/bme1/+/value
     lora/bme1/humidity/value 0
     lora/bme1/pressure/value 0
     lora/bme1/temperature/value 0
     lora/bme1/voltage/value 0
   subscribeReadings:
     lora/bme1/humidity/value:
       cmd       
       name       humidity
     lora/bme1/pressure/value:
       cmd       
       name       pressure
     lora/bme1/temperature/value:
       cmd       
       name       temperature
     lora/bme1/voltage/value:
       cmd       
       name       voltage
Attributes:
   IODev      MQTTBroker
   alias      bme1_Abstellraum
   autoSubscribeReadings lora/bme1/+/value
   room       Abstellraum,Heizung
   stateFormat T: temperature H: humidity V: voltage
   subscribeReading_humidity lora/bme1/humidity/value
   subscribeReading_pressure lora/bme1/pressure/value
   subscribeReading_temperature lora/bme1/temperature/value
   subscribeReading_voltage lora/bme1/voltage/value
Hier nun das List vom neuen MQTT2_DEVICE:

Code Auswählen Erweitern

Internals:
   CFGFN     
   DEVICETOPIC bme1_2
   FUUID      5c6d4e37-f33f-9d23-628c-be5c4a98aaf988d8
   IODev      MQTT2Broker
   NAME       bme1_2
   NR         2523
   STATE      T: temperature H: humidity V: voltage
   TYPE       MQTT2_DEVICE
   READINGS:
   helper:
     bm:
       MQTT2_DEVICE_Attr:
         cnt        8
         mAr        set; bme1_2; readingList; lora/bme1/+/value.* { json2nameValue($EVENT) }
         max        2
         tot        5
       MQTT2_DEVICE_Define:
         cnt        1
         mAr        HASH(0xd53f1f0); bme1_2 MQTT2_DEVICE
         max        4
         tot        4
       MQTT2_DEVICE_Get:
         cnt        12
         mAr       
         max        0
         tot        0
       MQTT2_DEVICE_Set:
         cnt        33
         mAr        HASH(0xd53f1f0); bme1_2; ?
         max        158
         tot        158
Attributes:
   IODev      MQTT2Broker
   alias      bme1_Abstellraum
   readingList lora/bme1/+/value:.* { json2nameValue($EVENT) }
   room       Abstellraum,Heizung
   stateFormat T: temperature H: humidity V: voltage
Beim neuen MQTT2_DEVICE kommen keine Daten an.
Liegt das womöglich daran das ein + Wildcard gesetzt ist, was ja bei MQTT ein gültiges Wildcard ist aber nicht im MQTT2_DEVICE?

[rudolfkoenig]

Die readingList topic Zeilen sind Regexps, da hat + eine andere Bedeutung als im MQTT Protokoll.
Eine einfache Aequivalente in Regexp ist .+, die "richtige" ist [^/]+

[sbiermann]

Hmm, funktioniert auch nicht. Es kommen immer noch keine Daten an.

Code Auswählen Erweitern

attr bme1_2 readingList lora/bme1/[^/]+/value:.* { json2nameValue($EVENT) }
Auch die vereinfachte Variante mit .+ funktioniert nicht.

[Beta-User]

Interessehalber zwei vielleicht doofe Fragen:
- kommt da überhaupt ein JSON an oder direkt der Wert?
- Wenn ja, würde sowas funktionieren?

Code Auswählen Erweitern

attr bme1_2 readingList lora/bme1/([^/]+)/value:.* { json2nameValue($EVENT,$1) }bzw. wenn nein:

Code Auswählen Erweitern

attr bme1_2 readingList lora/bme1/([^/]+)/value:.* $1

[sledge]

Vielleicht als genereller Tip: Es hilft mE sehr, sich die Nachrichten mit einem mqtt-Client vorher anzuschauen - mqtt.fx oder vergleichbar - das beantwortet die Frage nach dem "in welchem Format kommen die Werte an" eindeutig.

Die alte Config sieht für mich so aus, als ob direkt Werte übergeben werden, kein JSON.

[Beta-User]

mit einem mqtt-Client vorher anzuschauen

Auch MQTT2_CLIENT liefert bei bedarf rawEvents (siehe commandref zum entsprechenden Attribut)... Braucht man keine externen Tools zu.

[sledge]

Auch MQTT2_CLIENT liefert bei bedarf rawEvents (siehe commandref zum entsprechenden Attribut)... Braucht man keine externen Tools zu.

Brauchen sicherlich nicht - ich persönlich empfinde mqtt.fx als einfach zu nutzen und praktisch, wenn man mehrere topics subscribed und die Interaktion im Blick behalten möchte. Free choice

[Beta-User]

Brauchen sicherlich nicht - ich persönlich empfinde mqtt.fx als einfach zu nutzen und praktisch, wenn man mehrere topics subscribed und die Interaktion im Blick behalten möchte. Free choice

*grins* (Ich habe aus purer Gewohnheit auch oft mosquito_sub in einer Konsole am Start...)

Es kann aber nicht schaden, wenn man etwas Regex lernt - damit kann man das auch in der FHEM-MQTT2-Welt haben mit den mehreren Topics .

Edit: Bleibt die Frage, ob das geht (unterstellt, es ist wirklich kein JSON):

Code Auswählen Erweitern

attr bme1_2 readingList lora/bme1/([^/]+)/value:.* $1

[sbiermann]

Nee das funktioniert nicht mit dem $1, dann kommt folgende Meldung:

Code Auswählen Erweitern

bad reading name $1 (contains not A-Za-z/\d_\.- or is too long)

Es ist wirklich kein JSON, ist schon ne Weile her das ich das gemacht hatte, daher komplett verpeilt gehabt.

Anscheinend funktioniert dann mein Anwendungsfall so nicht. Denn ich habe jeden Wert einen eigenen Topic zugewiesen und möchte nun, wie beim alten MQTT_DEVICE, das dieses aus meinen Topic (wo jetzt das + steht) den Namen des Readings nimmt. Also wenn dann lora/bme1/pressure/value oder lora/bme1/temperature/value kommt möchte ich das es Readings temperature und pressure gibt und dort die Werte stehen.

[Beta-User]

Was in jedem Fall geht:
Eine Zeile pro Reading, und den Reading-Namen dann ausgeschrieben. Ist z.B. bei dem shelly-templates so, wenn du eine Referenz suchst (in fhem/FHEM/lib/AttrTemplate/mqtt2.template zu finden).

Was evtl. noch einen Versuch wert sein könnte, wäre, das $1 in geschweifte Klammern zu packen, kann aber nicht sagen, ob das auch zum Erfolg führt (interessieren würde es mich aber...).

Generell: Welchen Sinn macht es, das in "value" zu packen? (Das ist bei den Geräten, die nativ MQTT sprechen und kein JSON verwenden - z.B. den Shellys bisher eigentlich immer anders gewesen). autocreate in FHEM kann "besser" damit umgehen, wenn der Readingname der letzte Teil des Topic-Strings ist...

[sbiermann]

Ja die einzelnen Readingnamen funktionieren. Habs jetzt mal so umgesetzt. Das andere wäre natürlich viel sexier als jetzt, aber nuja es geht.

Das mit den {$1} wird zwar akzeptiert, es passiert aber rein gar nichts wenn eine Message kommt.

Warum ich value in dem Topic Namen verwende? Die Idee dahinter ist, so weiß ich genau die Nachricht in dem Channel ist nur der reine Wert, sprich bei temperature/value steht dann z.B. 20.1. Weiterhin verwendet ich für Geräte wo es möglich ist set im als letztes im Topic Namen, also z.B. temperature/set, so habe ich die Unterscheidung zwischen den Topics für das auslesen und setzen. Klar man könnte natürlich auch umdrehen und .../value/temperature machen und .../set/temperature aber das finde ich nicht so schön.

Ich habe jetzt mal alle MQTT_DEVICEs die regelmäßig Daten empfangen auf MQTT2_DEVICEs. Die schaltenden Devices sind noch auf das alte MQTT_DEVICE, da ich diese als Fehlerquelle für die Abstürze ausschließen kann. Weil um die Uhrzeiten, als die Abstürze waren, niemand auf den Schaltern gedrückt haben kann. Jetzt heißt es warten ob es weitere Abstürze gibt.

[Beta-User]

Nu ja...

Anmerkungen noch: Dass das mit den set-Anweisungen "woanders" sein sollte, leuchtet ein, aber je nachdem brauchst du eh' eine Brücke zwischen set und value (wenn value die "Quittung" sein soll). Das ginge aber genauso, wenn der Wert einfach eine Ebene weiter oben erschiene im Topic-Pfad, oder? (Nur) für das Setzen wäre dann noch die Verlängerung mit .*/reading/set erforderlich.

Eventuell reicht MQTT2_DEVICE nicht nur $EVENT weiter, sondern auch $DEVICETOPIC. Wenn ja, könnte man auch eine allg. Verarbeitungslogik mit Regex basteln, die sich den Readingnamen als $1 extrahiert... (Ich habe dazu aber kein Eigeninteresse und würde das eher lösen wie oben skizziert, und für die GenericBridge gelten wieder andere Regeln, was die set-Auswertung anginge).

[sbiermann]

Nach dem ich erst dachte es reicht nur die Devices umzuziehen die regelmäßig Daten empfangen kam dann trotzdem ein Absturz. Also habe ich auch die restlichen Devices (Schalter) umgezogen auf MQTT2 und seit dem (mehr als 1 Woche) gibt es keinen Absturz mehr. Es muss also wirklich am MQTT bzw. ich vermute an der Perl Implementierung des MQTT Protokolls gelegen haben. Schon sehr seltsam, aber die neuen MQTT2 Devices funktionieren gut und sind auch gefühlt viel schneller als die alten MQTT Devices in der Reaktion.

[rudolfkoenig]

Schon sehr seltsam, aber die neuen MQTT2 Devices funktionieren gut

Was ist daran bitte seltsam, dass mein Code funktioniert?

[sbiermann]

Das sehr seltsam bezieht sich auf die alten Devices, das es da mit der Perl Implementierung anscheinend in meiner Konstellation so viel Probleme gibt.