(gelöst) MQTT_Device un Userreading - triggert nicht

Begonnen von maltejahn, 07 Juli 2021, 10:27:07

Vorheriges Thema - Nächstes Thema

maltejahn

Guten morgen,

ich sitze wie der Ochse vor dem Berg:

Ich verwende einen SDR im TFA Dostmann Sensoren zu decodieren:
https://github.com/git-developer/fhem-examples/wiki/Temperatur-Feuchte-Sender-mit-tfrec-und-MQTT
Funktioniert für Temperatursensoren schon einige Zeit richtig gut.
Unschön, hat aber vermutlich nichts mit dem Problem zu tun. Das Skript das die Daten vom SDR an MQTT sendet unterscheidet nicht, ob es ein Temperatur oder sonst ein Sensor ist und sendet alles als Temp/Feuchte. Macht eigentlich nichts (bis darauf das temperature (siehe unten) unnütz in der Datenbank landet). Hier müsste man eine Fallunterscheidung anhand einer Datenbank/IDs machen

Nun habe ich einen Regenmengensensor (ideale Zeit dafür) und müsste ein Reading umrechnen - wollte das über ein UserReading machen. Nur, tut es nicht - wird scheinbar nie berechnet bzw. erstellt  (taucht also nie unter "REadings" auf

Ein Event wird ausgelöst
2021-07-07 09:48:20 MQTT_DEVICE mqtt_klima_regensensor_regen json: { "sensor_id":"0865bcacdff12", "temperature":128.0, "humidity":332, "lowbat":false, "rssi":83 }
2021-07-07 09:48:20 MQTT_DEVICE mqtt_klima_regensensor_regen temperature: 128
2021-07-07 09:48:20 MQTT_DEVICE mqtt_klima_regensensor_regen humidity: 332
2021-07-07 09:48:20 MQTT_DEVICE mqtt_klima_regensensor_regen rssi: 83


(Achtung, temperature ist ein Counter. pro count sind das 0,25mm/m^2; humidity ist die Zeit seit dem letzten count)
List
Internals:
   FUUID      60e491bc-f33f-72a8-269f-0c68f826f694942e
   IODev      mosquitto
   NAME       mqtt_klima_regensensor_regen
   NR         106
   STATE      T: 139 H: 1
   TYPE       MQTT_DEVICE
   Helper:
     DBLOG:
       absFeuchte:
         logdb:
           TIME       1625646327.77777
           VALUE      19.5
       dewpoint:
         logdb:
           TIME       1625646327.77777
           VALUE      27.7
       humidity:
         logdb:
           TIME       1625646327.77777
           VALUE      1
       temperature:
         logdb:
           TIME       1625646327.77777
           VALUE      139
   READINGS:
     2021-07-07 10:25:27   1               19.5
     2021-07-07 09:31:32   IODev           mosquitto
     2021-07-07 10:25:27   absFeuchte      19.5
     2021-07-07 10:25:27   dewpoint        27.7
     2021-07-07 10:25:27   humidity        1
     2021-07-07 10:25:27   json            { "sensor_id":"0865bcacdff12", "temperature":139.0, "humidity":1, "lowbat":false, "rssi":84 }
     2021-07-07 10:25:27   lowbat          0
     2021-07-07 10:25:27   rssi            84
     2021-07-07 10:25:27   sensor_id       0865bcacdff12
     2021-07-07 10:25:27   temperature     139
     2021-07-07 10:25:27   transmission-state incoming publish received
   message_ids:
   sets:
   subscribe:
     devices/tfa/30.3144.it/0865bcacdff12/json
   subscribeExpr:
     ^devices\/tfa\/30.3144.it\/0865bcacdff12\/json$
   subscribeQos:
     devices/tfa/30.3144.it/0865bcacdff12/json 0
   subscribeReadings:
     devices/tfa/30.3144.it/0865bcacdff12/json:
       cmd       
       name       json
Attributes:
   IODev      mosquitto
   event-on-change-reading .*
   room       Wetter
   stateFormat T: temperature H: humidity
   subscribeReading_json devices/tfa/30.3144.it/0865bcacdff12/json
   userReadings RegenmengeLiterStunde{ReadingsVal("mqtt_klima_regensensor_regen", "temperature", 0)/1000}
   verbose    5


Log sagt
2021.07.07 09:54:20 5: publish received for devices/tfa/30.3144.it/0865bcacdff12/json, { "sensor_id":"0865bcacdff12", "temperature":129.0, "humidity":362, "lowbat":false, "rssi":84 }
2021.07.07 09:54:20 5: calling readingsSingleUpdate(mqtt_klima_regensensor_regen,json,{ "sensor_id":"0865bcacdff12", "temperature":129.0, "humidity":362, "lowbat":false, "rssi":84 },1)
2021.07.07 09:54:20 1: dewpoint_notify: humidity device mqtt_klima_regensensor_regen (humidity) invalid: 362

Auch hier, das ich den Regenmengensensor als Tempsensor "erkannt" wird mit seinen Nebeneffekten (quatschwert für Feuchte)

Warum wird die Berechnung (die jetzt noch keine ist) nicht ausgeführt

Beta-User

#1
Sehe ich das richtig und es gibt kein Leerzeichen zwischen dem Namen und dem Perl-Code in dem userReadings-Element?

Dann wäre das der erste Ansatzpunkt.

Daneben gibt es noch ein paar weitere Aspekte:
- userReadings sollten mit trigger versehen werden.
- Für json-Payloads ist die neuere MQTT2-Implementierung mAn. deutlich einfacher in der Handhabung. Hier würde es sich z.B. anbieten, die sensor_id mit in den Reading-Namen reinzuverarbeiten, damit da nicht alles durcheinandergeht, falls mal ein anderer empfangen wird. Gibt es Gründe für MQTT_DEVICE?

Nachtrag: Es könnte dann noch ein Reihenfolgeproblem in der Eventverarbeitung geben (es ist ja scheinbar irgendwo ein expandJSON am Werk), siehe https://forum.fhem.de/index.php/topic,121839.0/topicseen.html.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

maltejahn

Hallo und vielen Dank,

ein Leerzeichen wars...

Zu den Hinweisen/Fragen
- Warum MQTT_DEVICE? Die Antwort wird nicht glücklich machen, weil es in dem Beispiel so realisiert wurde: https://github.com/git-developer/fhem-examples/wiki/Temperatur-Feuchte-Sender-mit-tfrec-und-MQTT
- MQTT oder MQTT2? Habe ich mich ebenfalls nicht beschäftigt. Da ich aber das noch umsetzen möchte: https://github.com/Yattien/ESPEInk_ESP8266 und hier steht: "mosquitto als MQTT-Server (MQTT2_* kann leider kein QOS oder ich hab nicht herausgefunden wie)" (Abschnitt "Benötigt wird") weiß ich nicht ob das beides sich dann beißt

Grüße
Malte

Beta-User

Schön, dass es gelöst ist, auch wenn Leerzeichen und "trigger" zwei Paar Stiefel sind...

Zitat von: maltejahn am 07 Juli 2021, 12:57:44
Die Antwort wird nicht glücklich machen,
Na ja, am Ende sollte es eben funktionieren, und an der Stelle _glaube ich_, dass man es mit den MQTT2-Modulen besser (=eleganter und universeller) lösen könnte; eventuell wäre es hilfreich, wenn man dem betreffenden Autor "passendes Material" zuspielen würde (z.B. um das Temperatur-Reading gleich passend zu benennen...)

Zitat"mosquitto als MQTT-Server (MQTT2_* kann leider kein QOS oder ich hab nicht herausgefunden wie)"
Zumindest MQTT2_CLIENT kann mit QOS 1 versenden, und auch bei MQTT2_SERVER findet sich zumindest auch der Hinweis, dass er QOS 0 und 1 unterstützen würde, aber damit habe ich mich bisher auch noch nicht beschäftigt.

Insgesamt sieht mir die Implementierung auf der Github-Seite "komisch" aus, was der dummy soll, erschließt sich mir z.B. nicht (userReadings in dummy werden nicht "einfach so" aktualisiert, aber vermutlich wird das klarer, wenn man die Haupt-Doku zu dem Modul kennt), und ich frage mich, warum man die MQTT-"Spezialitäten" nicht einfach via MQTT_GENERIC_BRIDGE an das "display"-Device anflanscht. Kann aber sein, dass leere Payloads ein Problem sind.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors