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:
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
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.
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.
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.
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.
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.
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
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:
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?
Die readingList topic Zeilen sind Regexps, da hat + eine andere Bedeutung als im MQTT Protokoll.
Eine einfache Aequivalente in Regexp ist .+, die "richtige" ist [^/]+
Hmm, funktioniert auch nicht. Es kommen immer noch keine Daten an.
attr bme1_2 readingList lora/bme1/[^/]+/value:.* { json2nameValue($EVENT) }
Auch die vereinfachte Variante mit .+ funktioniert nicht.
Interessehalber zwei vielleicht doofe Fragen:
- kommt da überhaupt ein JSON an oder direkt der Wert?
- Wenn ja, würde sowas funktionieren?
attr bme1_2 readingList lora/bme1/([^/]+)/value:.* { json2nameValue($EVENT,$1) }bzw. wenn nein:
attr bme1_2 readingList lora/bme1/([^/]+)/value:.* $1
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.
Zitat von: sledge am 20 Februar 2019, 16:12:37
mit einem mqtt-Client vorher anzuschauen
Auch MQTT2_CLIENT liefert bei bedarf rawEvents (siehe commandref zum entsprechenden Attribut)... Braucht man keine externen Tools zu.
Zitat von: Beta-User am 20 Februar 2019, 16:23:45
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 ;-)
Zitat von: sledge am 20 Februar 2019, 16:51:31
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):
attr bme1_2 readingList lora/bme1/([^/]+)/value:.* $1
Nee das funktioniert nicht mit dem $1, dann kommt folgende Meldung:
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.
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...
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.
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).
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.
ZitatSchon sehr seltsam, aber die neuen MQTT2 Devices funktionieren gut
Was ist daran bitte seltsam, dass mein Code funktioniert? :)
Das sehr seltsam bezieht sich auf die alten Devices, das es da mit der Perl Implementierung anscheinend in meiner Konstellation so viel Probleme gibt.