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
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 (https://forum.fhem.de/index.php/topic,121839.0/topicseen.html).
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
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.