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

Begonnen von maddinthebrain, 19 November 2021, 11:58:37

Vorheriges Thema - Nächstes Thema

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 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

Viele Grüße
Martin

Futro mit Proxmox und Debian: FHEM, Signalduino 433MHz & 868MHz, MAX!, WeeWX, FHEM2FHEM,
Raspi 4 mit ConBee mit deCONZ und Phoscon für ZigBee Aktoren und Sensoren

Beta-User

attr <M2Server> ignoreRegexp /rainsensor/SETTINGS
Ansonsten würde ich mal empfehlen, das ignoreRegexp-Thema im Wiki zu vertiefen (ist da vermutlich bei MQTT2_CLIENT zu finden).
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

maddinthebrain

Hallo Beta-User,


Danke!!!

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
Viele Grüße
Martin

Futro mit Proxmox und Debian: FHEM, Signalduino 433MHz & 868MHz, MAX!, WeeWX, FHEM2FHEM,
Raspi 4 mit ConBee mit deCONZ und Phoscon für ZigBee Aktoren und Sensoren

Beta-User

#3
Zitat von: maddinthebrain am 19 November 2021, 12:59:59
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...
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

maddinthebrain

Zitat von: Beta-User am 19 November 2021, 13:21:59
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

Viele Grüße
Martin

Futro mit Proxmox und Debian: FHEM, Signalduino 433MHz & 868MHz, MAX!, WeeWX, FHEM2FHEM,
Raspi 4 mit ConBee mit deCONZ und Phoscon für ZigBee Aktoren und Sensoren

Beta-User

Siehe auch meinen Edit: evtl. liegt es an ständigen reboots?
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

maddinthebrain

Zitat von: Beta-User am 19 November 2021, 13:34:59
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
Viele Grüße
Martin

Futro mit Proxmox und Debian: FHEM, Signalduino 433MHz & 868MHz, MAX!, WeeWX, FHEM2FHEM,
Raspi 4 mit ConBee mit deCONZ und Phoscon für ZigBee Aktoren und Sensoren

Beta-User

Zitat von: maddinthebrain am 19 November 2021, 14:08:41
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
ZitatSETTINGS/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).
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

ZitatVermutlich 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:
Zitat[...]
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:

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

Viele Grüße
Martin

Futro mit Proxmox und Debian: FHEM, Signalduino 433MHz & 868MHz, MAX!, WeeWX, FHEM2FHEM,
Raspi 4 mit ConBee mit deCONZ und Phoscon für ZigBee Aktoren und Sensoren

Beta-User

Zitat von: rudolfkoenig am 19 November 2021, 17:51:11
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.
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

maddinthebrain

#11
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
Viele Grüße
Martin

Futro mit Proxmox und Debian: FHEM, Signalduino 433MHz & 868MHz, MAX!, WeeWX, FHEM2FHEM,
Raspi 4 mit ConBee mit deCONZ und Phoscon für ZigBee Aktoren und Sensoren