[gelöst] Fhem MQTT2-Server, merkwürdiges Verhalte mit einem Node

[maddinthebrain]

Hallo zusammen,

ich habe einen Regensensor von Dillinger erworben https://dillinger-engineering.de/mqtt-kapazitiver-regensensor-modul/2021/05/. Dieser lässt sich per MQTT in Fhem integrieren. Jedoch ist mir ein sehr merkwürdiges Verhalten aufgefallen. Von wem (Sensor oder FHEM MQTT2 Server) das nun verursacht wird ist mir nicht klar.

Und zwar hat der Regensensor Topics die nur lesbar sind, diese sind auch nicht das Problem. Er hat auch Topics über die er konfiguriert werden kann. Diese sind unter /rainsensor/SETTINGS zusammengefasst. Genau dieser SETTINGS "Ordner" ist das Problem. Dieser ist extrem gesprächig und es wirkt wie eine Art Echokammer. Es fallen innerhalb einer halben Stunde zehntausende Messages an. Siehe das Bild im Anhang. Ich habe auch schon den MQTT2 Server schon die entsprechenden Topics mit

Code: [Auswählen]

attr DEVICE ignoreRegexp rainsensor:/rainsensor/SETTINGS ignorieren lassen, es hilft nur nix.

Hat jemand eine Idee, wie man dem auf den Grund gehen kann?

Vielen Dank und Viele Grüße

Martin

[Beta-User]

Code: [Auswählen]

attr <M2Server> ignoreRegexp /rainsensor/SETTINGSAnsonsten würde ich mal empfehlen, das ignoreRegexp-Thema im Wiki zu vertiefen (ist da vermutlich bei MQTT2_CLIENT zu finden).

[maddinthebrain]

Hallo Beta-User,


Danke!!!

Code: [Auswählen]

attr <M2Server> ignoreRegexp /rainsensor/SETTINGS hat geholfen.

Ansonsten eine Idee woran das komische Verhalten liegen könnte? Ich kenne mich mit MQTT nicht in der dafür nötigen Tiefe aus...

Viele Grüße

Martin

[Beta-User]

Ansonsten eine Idee woran das komische Verhalten liegen könnte? Ich kenne mich mit MQTT nicht in der dafür nötigen Tiefe aus...

Das ist nicht komisch, sondern imho ein bug. Würde das an den Firmware-Autor adressieren, ich nehme an, er kennt dieses Verhalten schlicht nicht...

Nachtrag: Die Werte werden angeblich nur gesendet, wenn der ESP neu gestartet wird. Falls also die Spannungsversorgung nicht paßt, könnte das auch das Problem sein, dass der ständig neu bootet...

[maddinthebrain]

Das ist nicht komisch, sondern imho ein bug. Würde das an den Firmware-Autor adressieren, ich nehme an, er kennt dieses Verhalten schlicht nicht...

Habe schon ein Ticket eröffnet (btw. finde ich echt cool, dass er sowas hat, viele Entwickler solcher Teile interessiert es ja oft nicht die Bohne). Er hatte auch schon einen schnellen Bugfix unternommen, jedoch noch ohne Erfolg. Vielleicht liest er ja auch mit.


Viele GRüße

Martin

[Beta-User]

Siehe auch meinen Edit: evtl. liegt es an ständigen reboots?

[maddinthebrain]

Siehe auch meinen Edit: evtl. liegt es an ständigen reboots?

Nein keine reboots, der Sensor sendet auch die Uptime alle 10s, und die läuft schön hoch. Ich nehme mal an, dass der Sensor auf die vom Server empfangenen Pakete und wieder verteilten Pakete aus SETTINGS als Änderung reagiert und diese vielleicht seinerseits mit Senden genau dieser Topics bestätigt. Und das Ganze dann vielleicht deshalb im Kreis läuft... Nur so ein Gedanke, ich kenne den Quelltext der Firmware nicht.

Zumindest das ignorieren der Pakete hat erst mal als Workaround geholfen

[Beta-User]

Nein keine reboots, der Sensor sendet auch die Uptime alle 10s, und die läuft schön hoch. Ich nehme mal an, dass der Sensor auf die vom Server empfangenen Pakete und wieder verteilten Pakete aus SETTINGS als Änderung reagiert und diese vielleicht seinerseits mit Senden genau dieser Topics bestätigt. Und das Ganze dann vielleicht deshalb im Kreis läuft... Nur so ein Gedanke, ich kenne den Quelltext der Firmware nicht.

Das klingt plausibel. Wenn man sich die Beschreibung ansieht, findet man

SETTINGS/Calibrate     Sensorkalibrierung (set true)     Read / Write

Imo ist es ein bug, denselben Topic für Senden und Empfangen zu nehmen, schon gleich, wenn nicht wenigstens anhand der Payload unterschieden wird, ob es nur eine Rückkoppelung ist oder eine echte "Anweisung".

Vermutlich sollte sich das Rudi mal ansehen, kann sein, dass z.B. mosquitto nicht an Clients verteilt, die gerade selbst auf den Topic geschrieben haben, MQTT2_SERVER aber schon. Kenne die specs nicht, die ein MQTT-Server hier einhalten sollte...

(Trotdem ist das m.E. ein Designfehler mit dem Einheitstopic).

[rudolfkoenig]

Vermutlich sollte sich das Rudi mal ansehen, kann sein, dass z.B. mosquitto nicht an Clients verteilt, die gerade selbst auf den Topic geschrieben haben, MQTT2_SERVER aber schon.

In der Spec (https://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html#_Toc384800415) sehe ich keine Einschraenkung:

[...]
The Server uses a PUBLISH Packet to send an Application Message to each Client which has a matching subscription.
[...]

Und mosquitto sendet ein PUBLISH brav zurueck:

Code: [Auswählen]

fhem> attr md setList test testTopic testMessage
fhem> info log
fhem> set md test
2021.11.19 17:48:40 3 : MQTT2_DEVICE set md test
2021.11.19 17:48:40 5 : m2c: sending PUBLISH 0(22)(0)(9)testTopictestMessage
2021.11.19 17:48:40 5 : m2c: received PUBLISH (0)(9)testTopictestMessage
2021.11.19 17:48:40 5 : m2c: dispatch autocreate=no\000m2c\000testTopic\000testMessage
fhem>


[maddinthebrain]

Der Entwickler hatte es mit dem IO Broker getestet. Damit würde es funktionieren. Mal sehen, ansonsten scheint der Regensensor seinen Zweck zu erfüllen. Auf jeden Fall besser supportet, als so manch andere Lösung.

Schöne Grüße

[Beta-User]

In der Spec (https://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html#_Toc384800415) sehe ich keine Einschraenkung:

Danke für's Erläutern!

@maddinthebrain:
Es mag sein, dass ein ganz bestimmter anderer MQTT-Server das anders macht, aber das wäre dann gegen die Spec... Und "funktionieren" tut es mit MQTT2_SERVER ja (irgendwie) auch.

Er sollte das reparieren. Es ist ein Bug der firmware.

[maddinthebrain]

Hallo zusammen,

Der Entwickler hat das Verhalten des Sensors angepasst und ich konnte die Funktion prüfen. Die Fehlfunktion ist behoben. Wer also einen guten Tau- und Niederschlagssensor sucht wird beim Sensor von der Firma Dillinger fündig.

Viele Grüße

Martin