kaputte readingList-Einträge

Begonnen von Beta-User, 26 April 2020, 11:14:16

Vorheriges Thema - Nächstes Thema

Beta-User

Hi Rudi,

leider habe ich die Message nicht, die das erzeugt, aber grade mal wieder zumindest ein list von einem Gerät mit "kaputter" readingList:

defmod MQTT2_OpenMQTTGateway_ESP32_1 MQTT2_DEVICE OpenMQTTGateway_ESP32_1
attr MQTT2_OpenMQTTGateway_ESP32_1 IODev MQTT2_FHEM_Server
attr MQTT2_OpenMQTTGateway_ESP32_1 bridgeRegexp home/OpenMQTTGateway_ESP32_1/BTtoMQTT/([0-9A-Z]+):.* "oMQTTgw_BT"\
  home/OpenMQTTGateway_ESP32_1/433toMQTT:.* "oMQTTgw_433"\
  home/OpenMQTTGateway_ESP32_1/IRtoMQTT:.* "oMQTTgw_IR"\
  home/OpenMQTTGateway_ESP32_1/CLIMAtoMQTT/([a-zA-Z0-9]+):.* "OpenMQTTGateway_ESP32_1_$1"
attr MQTT2_OpenMQTTGateway_ESP32_1 devStateIcon online:10px-kreis-gruen offline.*:10px-kreis-rot
attr MQTT2_OpenMQTTGateway_ESP32_1 icon mqtt
attr MQTT2_OpenMQTTGateway_ESP32_1 model OpenMQTTGateway_MCU
attr MQTT2_OpenMQTTGateway_ESP32_1 readingList home/OpenMQTTGateway_ESP32_1/LWT:.* LWT\
  home/OpenMQTTGateway_ESP32_1/version:.* version\
  home/OpenMQTTGateway_ESP32_1/SYStoMQTT:.* { json2nameValue($EVENT,'Sys_')}\
  homeassistant/[^/]*sensor/[^/]+/config:.* { $EVENT =~ m,OpenMQTTGateway_ESP32_1, ? json2nameValue($EVENT,"HASS_") : undef }\
OpenMQTTGateway_ESP32_1:gatewayIR\x22\x2c\x22val_tpl\x22_\x22\x7b\x7b\x2evalue_json\x5c\x2evalue\x2e\x7d\x7d\x22\x2c\x22devi:.* gatewayIR___val_tpl______value_json.value______devi\
OpenMQTTGateway_ESP32_1:6CgatewayIR\x22\x2c\x22val_tpl\x22_\x22\x7b\x7b\x2evalue_json\x5c\x2evalue\x2e\x7d\x7d\x22\x2c\x22device:.* 6CgatewayIR___val_tpl______value_json.value______device\
OpenMQTTGateway_ESP32_1:\x2ahome/home_presence/OpenMQTTGateway_ESP32_1\x7b\x22i:.* OpenMQTTGateway_ESP32_1__i\
OpenMQTTGateway_ESP32_1:CgatewayBT\x22\x2c\x22val_tpl\x22_\x22\x7b\x7b\x2evalue_json\x5c\x2eid\x2e\x7d\x7d\x22\x2c\x22device\x22_\x7b:.* CgatewayBT___val_tpl______value_json.id______device___\
OpenMQTTGateway_ESP32_1:9856CgatewayBT\x22\x2c\x22val_tpl\x22_\x22\x7b\x7b\x2evalue_json\x5c\x2eid\x2e\x7d\x7d\x22\x2c\x22device\x22_\x7b\x22name\x22:.* 9856CgatewayBT___val_tpl______value_json.id______device____name_\
OpenMQTTGateway_ESP32_1:enMQTTGateway_ESP32_1\x22\x2c\x22manufact:.* enMQTTGateway_ESP32_1___manufact\
OpenMQTTGateway_ESP32_1:2home/OpenMQTTGateway_ESP32_1/BTtoMQTT/582D343:.* 582D343\
OpenMQTTGateway_ESP32_1:9\x7b\x22tem\x22_22\x5c\x2e7\x2c\x22hum\x22_33\x5c\x2e8\x7dteway_ESP32_1/LWT\x22\x2c\x22name\x22_\x22O:.* LWT___name___O
attr MQTT2_OpenMQTTGateway_ESP32_1 room Steuerung->Interfaces
attr MQTT2_OpenMQTTGateway_ESP32_1 stateFormat <a href="http://Sys_ip" target="_blank">\
LWT\
</a>Version: version

setstate MQTT2_OpenMQTTGateway_ESP32_1 <a href="http://192.168.2.33" target="_blank">\
online\
</a>Version: 0.9.2
setstate MQTT2_OpenMQTTGateway_ESP32_1 2020-04-26 03:46:04 582D343
setstate MQTT2_OpenMQTTGateway_ESP32_1 2020-04-08 09:50:38 71BF79856C___dev_cla___connectiv
setstate MQTT2_OpenMQTTGateway_ESP32_1 2020-04-05 20:22:37 C___dev_cla___connectivity___pl_on___online___pl_off__
setstate MQTT2_OpenMQTTGateway_ESP32_1 2020-02-17 11:54:04 CgatewayBT___val_tpl______value_json.id______device___
setstate MQTT2_OpenMQTTGateway_ESP32_1 2020-04-11 05:34:42 HASS_dev_cla connectivity
setstate MQTT2_OpenMQTTGateway_ESP32_1 2020-04-11 05:34:42 HASS_device_identifiers_1 3C71BF79856C
setstate MQTT2_OpenMQTTGateway_ESP32_1 2020-04-11 05:34:42 HASS_device_manufacturer OMG_community
setstate MQTT2_OpenMQTTGateway_ESP32_1 2020-04-11 05:34:42 HASS_device_name OpenMQTTGateway_ESP32_1
setstate MQTT2_OpenMQTTGateway_ESP32_1 2020-04-11 05:34:42 HASS_device_sw_version 0.9.2
setstate MQTT2_OpenMQTTGateway_ESP32_1 2020-04-11 05:34:42 HASS_name gatewayBT
setstate MQTT2_OpenMQTTGateway_ESP32_1 2020-04-11 05:34:42 HASS_pl_avail online
setstate MQTT2_OpenMQTTGateway_ESP32_1 2020-04-11 05:34:42 HASS_pl_not_avail offline
setstate MQTT2_OpenMQTTGateway_ESP32_1 2020-04-11 05:34:42 HASS_pl_off offline
setstate MQTT2_OpenMQTTGateway_ESP32_1 2020-04-11 05:34:42 HASS_pl_on online
setstate MQTT2_OpenMQTTGateway_ESP32_1 2020-04-11 05:34:42 HASS_stat_t home/OpenMQTTGateway_ESP32_1/BTtoMQTT/
setstate MQTT2_OpenMQTTGateway_ESP32_1 2020-04-11 05:34:42 HASS_uniq_id 3C71BF79856CgatewayBT
setstate MQTT2_OpenMQTTGateway_ESP32_1 2020-04-04 20:35:45 HASS_unit_of_meas %
setstate MQTT2_OpenMQTTGateway_ESP32_1 2020-04-11 05:34:42 HASS_val_tpl {{ value_json.id }}
setstate MQTT2_OpenMQTTGateway_ESP32_1 2020-04-26 10:44:28 LWT online
setstate MQTT2_OpenMQTTGateway_ESP32_1 2020-03-18 01:54:03 LWT___name___O
setstate MQTT2_OpenMQTTGateway_ESP32_1 2020-04-26 02:38:04 OpenMQTTGateway_ESP32_1__i
setstate MQTT2_OpenMQTTGateway_ESP32_1 2020-04-26 11:06:06 Sys_SSID xyz
setstate MQTT2_OpenMQTTGateway_ESP32_1 2020-04-26 11:06:06 Sys_freeMem 70064
setstate MQTT2_OpenMQTTGateway_ESP32_1 2020-04-26 11:06:06 Sys_ip 192.168.2.33
setstate MQTT2_OpenMQTTGateway_ESP32_1 2020-04-26 11:06:06 Sys_mac 3C:71:BF:79:85:6C
setstate MQTT2_OpenMQTTGateway_ESP32_1 2020-04-26 11:06:06 Sys_modules IRBTHADiscovery
setstate MQTT2_OpenMQTTGateway_ESP32_1 2020-04-26 11:06:06 Sys_rssi -24
setstate MQTT2_OpenMQTTGateway_ESP32_1 2020-04-26 11:06:06 Sys_uptime 1005413
setstate MQTT2_OpenMQTTGateway_ESP32_1 2020-04-05 20:56:35 ___dev_cla___connectivity___pl_on___online___pl_off
setstate MQTT2_OpenMQTTGateway_ESP32_1 2020-04-15 04:02:21 __dev_cla___connectivity___pl_on___online___pl_off__
setstate MQTT2_OpenMQTTGateway_ESP32_1 2019-11-19 18:36:30 distance 25.51913
setstate MQTT2_OpenMQTTGateway_ESP32_1 2020-04-25 22:50:04 enMQTTGateway_ESP32_1___manufact
setstate MQTT2_OpenMQTTGateway_ESP32_1 2019-11-19 18:36:30 id 42:b6:11:6b:ad:04
setstate MQTT2_OpenMQTTGateway_ESP32_1 2019-11-19 18:36:30 manufacturerdata L
setstate MQTT2_OpenMQTTGateway_ESP32_1 2019-11-17 17:52:31 name Inspire HR
setstate MQTT2_OpenMQTTGateway_ESP32_1 2019-11-19 18:36:30 rssi -91
setstate MQTT2_OpenMQTTGateway_ESP32_1 2020-04-23 22:33:53 subscriptions +/+/IRtoMQTT home/OpenMQTTGateway_ESP32_1/commands/#
setstate MQTT2_OpenMQTTGateway_ESP32_1 2019-11-19 18:36:30 txpower 12
setstate MQTT2_OpenMQTTGateway_ESP32_1 2020-04-26 10:44:28 version 0.9.2


Ich habe den dringenden Verdacht, dass das auch mit den "homeassistant"-autodiscovery-Meldungen zusammenhängt oder den "home-presence"-Meldungen, die ich nicht zuordnen kann. Die Einträge kommen dann nach und nach, also nicht auf einmal. Ich habe den Eindruck, dass das dann irgendwann "Folgefehler" sind.

Vielleicht kannst du ja was aus dem Kaffeesatz lesen?
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

#1
Wenn man
  gatewayIR\x22\x2c\x22val_tpl\x22_\x22\x7b\x7b\x2evalue_json\x5c\x2evalue\x2e\x7d\x7d\x22\x2c\x22devi:.*

zurueckkonvertiert, dann kommt
  gatewayIR","val_tpl"_"{{ value_json\.value }}","devi

raus. Ich vermute, dass bridgeRegexp sich verschaetzt hat, weil angenommen hat, dass : nicht im Message vorkommen kann. + ist ohne ? greedy.


Beta-User

Über
Zitat von: rudolfkoenig am 27 April 2020, 10:35:24
+ ist ohne ? greedy.
muß ich wohl mal philosophieren, ich glaube, soweit ist mein regex-Verständnis noch nicht ausentwickelt, dass ich da von alleine eine konkrete Änderung ableiten kann...

Zu bridgeRegexp allgemein: Bisher war ich implizit immer davon ausgegangen, dass wir da den ganzen Topic-Pfad reinnehmen, was eher einer MQTT-Denke wie einer Perl-Denke entspricht. Das würde bedeutet, dass man eigentlich pro Zeile ein "^" davor denken sollte (und ein "$" am Ende), und das ganze nach dem ersten "Hit" beendet ist.

Kann sein, dass sich da irgendwann jemand dran stört, aber ich meine, dass das an der Stelle so umgesetzt werden sollte (falls das derzeit anders sein sollte). Es gibt in meinem FHEM-log nämlich ein paar "will be fatal in Perl 5.30"-Meldungen im Zusammenhang mit regex und öffnenden Klammern, die ich mir eigentlich nur im Zusammenhang mit diesen kaputten Einträgen erklären kann... Hier sind dann die Wechselwirkungen so abstrakt, dass vermutlich in ferner Zukunft niemand mehr an diese Zusammenhänge denkt, wenn das mal "ernst" wird mit der Verbreitung von 5.30.
(Ich hoffe, du kannst meinen Ausführungen in etwa folgen, sonst bitte nachfragen, dann suche ich die Fundstellen zu der "will be fatal"-Geschichte raus; war bisher beschränkt auf den Zusammenhang mit expandJSON.)
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

ZitatBisher war ich implizit immer davon ausgegangen, dass wir da den ganzen Topic-Pfad reinnehmen
bridgeRegexp prueft (wie readigsList) gegen topic:value und cid:topic:value.

ZitatDas würde bedeutet, dass man eigentlich pro Zeile ein "^" davor denken sollte (und ein "$" am Ende), und das ganze nach dem ersten "Hit" beendet ist.
^ und $ wird (wie beim readigList) immer hinzugefuegt.

Was helfen wuerde, waeren die konkreten MQTT Meldungen, dann koennte man die genaue Ursache lokalisieren.
Solange bleibt es Kaffesatzleserei.

Beta-User

Zitat von: rudolfkoenig am 27 April 2020, 11:17:47
bridgeRegexp prueft (wie readigsList) gegen topic:value und cid:topic:value.
^ und $ wird (wie beim readigList) immer hinzugefuegt.
Das ist schon mal gut.

Zitat
Was helfen wuerde, waeren die konkreten MQTT Meldungen, dann koennte man die genaue Ursache lokalisieren.
Solange bleibt es Kaffesatzleserei.
Hmm, mal schauen. Längerfristig den MQTT-Verkehr mitzuschneiden, dürfte ein Problem werden. Ich habe allerdings den Verdacht, dass das im Zusammenhang mit einem Reboot des ESP32 steht und werde bei Gelegenheit mal austesten, ob ich da was rausklabüsern kann, was etwas weniger Kaffeesatz ist; wird aber dauern...
Wie am besten mitschneiden? RAW-Events am Server aktivieren oder mosquitto_sub?

Kann auch sein, dass das ein Problem der firmware ist; die ist "alt" (es gibt eine aktuellere und ich habe auch noch zwei andere OpenMQTTBridge-ESP's mit aktuellerer firmware rumliegen, die afaik diese "Zicken" nicht machen). Allerdings würde ich das gerne (irgendwann) verstehen, wegen dieser "will be fatal"-Implikation, von daher warte ich erst mal mit dem update.
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