[Gelöst] MQTT Sensor (Temp/Hum) Intervall

Begonnen von iceman, 06 Juli 2020, 08:23:51

Vorheriges Thema - Nächstes Thema

iceman

Hallo zusammen,

ich habe seit einigen Tagen meine Xiaomi Bluetooth Sensoren über ein OpenMQTTGateway an mein FHEM gehängt (früher per sshhost mit Raspi Satelitten). Das funktioniert super, allerdings gibt es 2 Punkte die mich etwas stören und zu denen ich noch keine richtige gefunden Lösung habe.

1. Die Sensoren liefern nun alle 10 Sekunden Werte. Da ich mir Graphen erzeuge, schreibe ich die Werte in ein filelog. Ich habe aber die Befürchtung das die Logs sehr schnell zu lang werden. Leider habe ich bei dem MQTT Template nicht die Möglchkeit das Abfrage Intervall einzustellen um die Datenmenge zu reduzieren oder habe ich da was übersehen?

2. Die gelieferten Temperaturwerte jittern oft um +/-0,1°C was sich im Graph dafür sorgt, dass der Verlauf als gezackte Linie dargestellt wird. Eventuell erübrigt sich das Problem mit einem größeren Abfrage Intervall aber falls nicht, gibt es bei den Plots eine Möglichkeit diese jittern zu glätten bzw. wegzurunden?

Danke schonmal für Euere Hilfe.

Beta-User

Moin,

soweit mir bekannt, gibt es auch (- von direkt in der firmware implementierten Ausnahmefällen abgesehen noch -) keine Option, via OpenMQTTGateway überhaupt was BT-mäßig zu senden, ganz davon abgesehen, dass der Sensor das auch verstehen müßte (was ich nicht glaube).

In https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/lib/AttrTemplate/mqtt2.template#L3184 ist ein Vorschlag, wie man dem Sensor die "Geschwätzigkeit" auf FHEM-Seite austreiben kann. Ggf. mußt du die Grenzwerte da an deine Bedarfe anpassen.
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

iceman

Danke Beta-User, das würde bedeuten, das ich in dem Skript auf meinem Server die Zeile 3184: attr OMG_BT_ID event-min-interval 300 den Wert erhöhen würde.

die Änderung verliere ich aber mit jedem Update oder?

Beta-User

?

Mir ist völlig unklar, was du mir sagen willst:

attrTemplate setzt _bei Anwendung_ (set <device> attrTemplate <xyz>) Attribute. Die werden dann bei dir in der config (vermutlich fhem.cfg) gespeichert, wenn du auf save drückst oder eine vergleichbare Anweisung tätigst. Updates an der template-file wirken sich nur aus, wenn man das geänderte template auch anwendet (das hier verlinkte ist eigentlich seit Monaten unverändert...).


Hier würde ich empfehlen, die betreffenden beiden Attribute "von Hand" zu setzen, nämlich "event-min-interval" auf welchen Wert auch immer und v.a. das, was in der verlinkten Zeile 3184 steht:
event-on-change-reading batteryPercent,temperature:0.2,humidity:0.2,rssi:5,distance:5

Vielleicht solltest du mal nachlesen, was es mit den Attributen auf sich hat, z.B. im Wiki gibt es einen Beitrag, der v.a. event-on-change-reading erläutert. Das Phänomen der "geschwätzigen" Temperatursensoren ist nämlich nichts BT-spezifisches, das kommt häufiger vor...
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

iceman

Alles klar, ich hab jetzt verstanden was Du sagen wolltest. Mit dem event-on-change-reading wird die Anzahl der Einträge reduziert indem man das threshold erhöht. Ich war immer noch auf dem Weg die Menge zu reduzieren in dem man das Interval erhöht. Deshalb war das wahrscheinlich etwas unverständlich.

Ich danke Dir.

Beta-User

Genau.

Was heute im template steht, ist eine von vielen Möglichkeiten. Konkret ist es eben was, was sich für meine Zwecke in Innenräumen als (halbwegs) tauglich erwiesen hat, aber wenn du bessere Vorschläge hast: her damit...

(Ergänzend noch was, was hier keine Rolle spielt, aber in dem Gesamt-Zusammenhang (noch) ziemlich unbekannt ist: timestamp-on-change-reading. Ist vor allem für andere "geschwätzige" Devices interessant, bei denen es es nicht (nur) um Meßwerte, sondern um Statusänderungen geht (namentlich: Shelly-state).)

Markierst du den Thread dann bitte noch als "gelöst"?
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