Zugriff auf readings MQTT2_DEVICE

[Tubie1977]

Hallo,
ich stecke schon wieder fest.

Ich möchte von einem externen Mosquitto Broker Daten empfangen. Im MQTT2_CLIENT habe ich 'autocreate' auf complex gestellt. Eingehende topics (subscriptions) werden nun in der readingList des erzeugten MQTT2_myMQTTClient angezeigt. Auch wird in den Readings das Topic, der Bezeichner und der Wert angezeigt. Schön dabei, die Daten kommen im JSON Format und werden von FHEM decodiert:

test_WertASDF  on   2024-12-23 17:00:15


readingList des MQTT2_DEVICE mit den 3 angelegten Topics: /test /hallo und /intern:
unten 2 empfangene Werte "test_Test  on" und "test_WertASDF  on"

Code Auswählen Erweitern

defmod MQTT2_myMQTTClient MQTT2_DEVICE myMQTTClient
attr MQTT2_myMQTTClient readingList myMQTTClient:/test:.* { json2nameValue($EVENT, 'test_', $JSONMAP) }\
myMQTTClient:/hallo:.* { json2nameValue($EVENT, 'hallo_', $JSONMAP) }\
myMQTTClient:/intern:.* { json2nameValue($EVENT, 'intern_', $JSONMAP) }
attr MQTT2_myMQTTClient room MQTT2_DEVICE

setstate MQTT2_myMQTTClient 2024-12-23 16:26:51 test_Test on
setstate MQTT2_myMQTTClient 2024-12-23 16:18:01 test_WertASDF on
Wie kann ich jetzt sinnvoll mit diesem Wert weiter arbeiten, um z.B. einen dummy Switch bei Empfang von Topic="test" und Bezeichner="WertASDF" bei "on/off" zu setzen?

Vielen Dank im Voraus,
Horst

[rudolfkoenig]

z.B. einen dummy Switch bei Empfang von Topic="test" und Bezeichner="WertASDF" bei "on/off" zu setzen?

Mit notify, DOIF oder MQTT2_GENERIC_BRIDGE.

Beobachte die Events im Event-Monitor, markiere eine Zeile, und definiere damit eine notify Instanz mit "Create/Modify device".
In der notify Detailfenter kann man die passende Aktion auswaehlen per "Change wizard".

Oder man definiert es selber:

define n notify MQTT2_myMQTTClient:test_WertASDF set myDummy $EVTPART1

Siehe auch https://fhem.de/commandref_modular.html#notify

[Beta-User]

Oder halt "vereinzeln" in getrennten MQTT2_DEVICE-Instanzen. Siehe auch Wiki zu MQTT2_CLIENT bzgl. bridgeRegexp...

[Tubie1977]

Oh Mann ihr seid Spitze!

Vielen Dank! Habe es jetzt geschafft, die Werte einzulesen. Die Vorschläge von @rudolfkoenig haben mich ans Ziel geführt.

Oder man definiert es selber:

    Zitat
    define n notify MQTT2_myMQTTClient:test_WertASDF set myDummy $EVTPART1

Das hat erstmal nicht funktioniert.

Dann habe ich den Tip über den Event Monitor ausprobiert. Dieser hat  .....test_WertASDF:.off  dann geschrieben. Nachdem ich dann:

Code Auswählen Erweitern

define n MQTT2_myMQTTClient:test_WertASDF:.* set myDummy $EVTPART1
eingegeben habe, hat es funktioniert.

Was aber noch viel wichtiger ist, es war ein kurzweiliger Abend und ich habe wieder viel gelernt - Vielen Dank dafür!

Horst

[Beta-User]

Diese Event-Kette+dummy ist halt völlig überflüssig. Ein M2D täte dasselbe...

[TomLee]

Was aber noch viel wichtiger ist, es war ein kurzweiliger Abend und ich habe wieder viel gelernt

Hallo,

lass das mal alles "sacken", und mach Dir anschließend Gedanken wie der Ansatz von Beta-User gemeint ist. Die dummy-Definition ist schlicht überflüssig.

Gruß Thomas

[Beta-User]

Vielleicht fällt damit das Gedanken machen leichter:

Code Auswählen Erweitern

defmod test2 MQTT2_DEVICE
attr test2 readingList myMQTTClient:/test:.* { json2nameValue($EVENT, '', $JSONMAP) }
attr test2 jsonMap Test:state WertASDF:0

defmod test3 MQTT2_DEVICE
attr test3 readingList myMQTTClient:/test:.* { json2nameValue($EVENT, '', $JSONMAP) }
attr test3 jsonMap Test:0 WertASDF:state

Anmerkung: Das mit der CID in der readingList habe ich nur drin gelassen, weil der Topic so kurz und uneindeutig ist. Tendenziell würde ich empfehlen, das (nach Umstellung auf eine etwas tiefer gegliederte  Topic-Struktur) raus zu lassen (und ggf. zu überlegen, ob der mosquitto wirklich "notwendig" ist und das ganze nicht einfacher per MQTT2_SERVER umzusetzen wäre).

(Und der "Startstrich" in der Topic-Struktur ist "bäh")

Schöne Weihnachten allseits!

[Tubie1977]

Hallo Beta-User,

Vielen Dank für die Ausführung. Ich habe jetzt mal versucht, das zu verstehen und noch eine Frage:

Im test2 MQTT_DEVICE wird der "state" aus dem Topic geholt. Was bringt das?
Im test3 MQTT_DEVICE wird der "state" aus dem Payload geholt. Das sehe ich ein und funktioniert auch.

Die CID wird später natürlich noch eindeutig vergeben. Bei den Topics kann ich nur das liefern, was bekannt ist. Ich möchte von einer Eaton Easy800 die aktuellen Ausgänge nach FHEM portieren. Dafür habe ich mir mittels Raspi Pico und einem Netzwerk Chip einen "Converter" gebaut. Die Serielle Schnittstelle (TX only) von der SPS überträgt in 64 Bytes alle gerade gesetzten Ein/Ausgänge mit einer 1. Der Pico macht daraus dann das MQTT für Steuerung / Ein- Ausgang und Bit. z.B. CID/SP2/Q2 = on

Mal sehen, ist ein altes Projekt, das ich über die Feiertage mal wieder rausgeholt habe.

Euch auch noch frohe Weihnachten!

Gruß,
Horst 

[Beta-User]

Im test2 MQTT_DEVICE wird der "state" aus dem Topic geholt.

Diese Annahme ist nicht zutreffend.

Bei den Topics kann ich nur das liefern, was bekannt ist.

Das sah eher nach einer Trockenübung aus... Würde empfehlen, den Test direkt mit der konkreten Hardware (dem Pico etc.) zu machen, schon gleich, wenn man damit sowieso nur lesen kann. Dazu sinnvollerweise den MQTT2_SERVER statt mosquitto verwenden.
Alles andere führt (bei Einsteigern in MQTT) erfahrungsgemäß nur zu Verwirrung...

[Tubie1977]

Hallo Beta-User,

Diese Annahme ist nicht zutreffend.

Kannst Du es bitte aufklären, was "Test:state" bedeutet? Ich komme nicht drauf 

Das sah eher nach einer Trockenübung aus...

Ist es auch mehr oder weniger. Erst wenn ich die ganze Kommunikation verstanden habe, wird sie umgesetzt. Um die einzelnen Topics und Payload zu überwachen, die gesendet werden, habe ich mich für Mosquitto entschieden. Hier kann ich einfach am PC sehen, was läuft und was der Pico an Daten produziert und sendet. Auch mit dem Hintergrund eines Amateurfunk Projektes, welches diesen Server wegen mehrerer Clients auch benötigt. Hier wird FHEM nur die Logs zur Datenbank durchreichen...

schon gleich, wenn man damit sowieso nur lesen kann

Die Easy800 hat noch ca. 8 Eingänge frei damit kann ich von extern mit dem Pico die Daten rein schaffen. Habe auch schon was, wie ich mit Clock und Reset pro Schreibvorgang 6 Bits schreiben kann. Einzige Möglichkeit wäre noch ein OPC-Server, der mit der Eaton Steuerung kommuniziert und Merker lesen/schreiben kann. Dafür müsste aber permanent ein Windows Rechner laufen und die Schnittstelle zu FHEM gibt es auch noch nicht. Also bleibe ich bei MQTT.

Aber alles zu seiner Zeit. Erst mal nur in eine Richtung...

Gruß,
Horst

[Beta-User]

Erst wenn ich die ganze Kommunikation verstanden habe, wird sie umgesetzt.

Dann viel Spaß, bei theoretischen Trockenübungen vorab bin ich raus, zumal ich auch die Begründungen gegen MQTT2_SERVER nicht wirklich nachvollziehen kann: Man kann das nachher noch auf MQTT2_CLIENT umstellen, und "von außen" kann man auch einen M2S mit den "üblichen Verdächtigen" ohne weiteres anzapfen, um zu sehen, was da so passiert...

Kannst Du es bitte aufklären, was "Test:state" bedeutet? Ich komme nicht drauf 

Die commandref zu MQTT2_DEVICE/jsonMap sollte Aufschluss geben; aber anscheinend braucht dein Projekt gar kein JSON:

Der Pico macht daraus dann das MQTT für Steuerung / Ein- Ausgang und Bit. z.B. CID/SP2/Q2 = on

Ergo: Trockenübung für die Katz, Erklärung dazu genauso...   

[Tubie1977]

Dann viel Spaß, bei theoretischen Trockenübungen vorab bin ich raus

Das ist schade. Zumal ich noch nicht wirklich verstanden habe, was beim MQTT2_SERVER für Anfänger gegenüber einem MQTT2_DEVICE und einem externen Mosquitto Server besser sein soll. Für Verwirrung sorgt momentan noch die Kryptische Schreibweise der Syntax in FHEM.

Ich möchte halt vom PC, später vom Mikrocontroller, MQTT im JSON Format versenden und sehen, was FHEM daraus macht. Den Controller kenne ich sehr gut, FHEM noch nicht. Einen Programmfehler auf dem Controller kann man aber nur vermeiden und finden, wenn wenigstens die Empfänger Seite zu 100% funktioniert. Das möchte ich erreichen.   

Soll übrigens heißen:  { "CID/SP2/Q2": "on" }

Habe es soweit verstanden, Dankeschön dafür!

Gruß,
Horst

[Beta-User]

was beim MQTT2_SERVER für Anfänger gegenüber einem MQTT2_DEVICE und einem externen Mosquitto Server besser sein soll. Für Verwirrung sorgt momentan noch die Kryptische Schreibweise der Syntax in FHEM.

Um die "Schreibweise" in FHEM zu verstehen, sollte man sich jeweils um _genau ein_ Stück Hardware kümmern können. Genau das erleichtert M2S, indem er die eingehenden Infos gleich so "zusammensortiert", dass per default jedes Stück Hardware genau eine MQTT2_DEVICE-Instanz erhält. Außerdem sieht man _ausgehende_ Infos nicht, muss also nicht dafür sorgen, dass man "set"- und "get"-Anweisungen separat aussortiert...
(Nein, du mußt/wirst das vermutlich nicht direkt verstehen; dass es schlicht einfacher ist, ist halt einfach ein Erfahrungswert aus dem support für Dutzende andere Einsteiger.) 

Ich möchte halt vom PC, später vom Mikrocontroller, MQTT im JSON Format versenden und sehen, was FHEM daraus macht.

Dann verwende zum Testen irgendwas, was schon MQTT+JSON spricht, z.B. irgendeinen Pseudo-Tasmota-ESP.
FHEM wird dir "kaputte Kommunikation" jedenfalls verzeihen.

Also nochmal zurück zu deiner MCU, da du anscheinend "alle Freiheiten" hast, um das zu gestalten:
Vorab - JSON ist kein Wert an sich, sondern bringt in FHEM nur dann einen Mehrwert, wenn man es dazu nutzt, die Kommunikation effektiver zu machen, und nicht, um eher ungünstige Datenstrukturen selbst zusammenzubasteln.

Dein

Code Auswählen Erweitern

{ "CID/SP2/Q2": "on" }hat keinen JSON@FHEM Mehrwert: Eine Info, und dann noch eine key-Benennung mit Querstrichen, die eventuell beim Umbenennen Probleme macht.

Die MCU fragt alle Datenpunkte auf einmal ab? => ein JSON-Blob, in dem alles drin ist (Topic:Payload):

Code Auswählen Erweitern

CID/SP2/outputs:{"Q1": "on", "Q2": "on", "Q3": "off", ...}Wenn du das hinterher in FHEM sowieso "getrennt" haben willst, würde ich hier auf JSON verzichten (bzw. ggf. nur für "health"-Werte der MCU verwenden), und jeweils getrennte Topics/Info verwenden. Also sowas: Q1 ist das Wohnzimmer-Licht, Q2 der Lüfter im Bad, ...
Also:

Code Auswählen Erweitern

CID/SP2/outputs/1:on
CID/SP2/outputs/2:on
CID/SP2/outputs/3:off
...Gibt es welche, die zusammenhängen (Rollläden=2 Relays), ist es ggf. besser, JSON zu verwenden und die "anderen" Relays dann per readingsProxy zu vereinzeln (Wenn du die Relays direkt ansprechen mußt und das nicht die SPS intern macht und passende (z.B. percentage-Infos) liefert!).

Immer noch: Es ist keine gute Idee, das erst theoretisch komplett durchdringen zu wollen, ohne bereits etwas konkretere Erfahrungen mit funktionierender Kommunikation zu haben. FHEM ist jedenfalls nicht das Problem, das ist sehr flexibel...

[Tubie1977]

Hallo,

vielen Dank für die gute Erklärung! Ist einleuchtend, wenn MQTT2_SERVER da schon eine gewisse Voreinstellung für die Devices definieren kann, dass es dann einfacher wird.


Bei der MCU würde ich gerne nur die Änderungen übertragen, wenn Q2 = on auf off fällt oder ein bestimmter Merkerwert (Rollo, Timer, Ereignissse,...) sich ändert. Nach einer einstellbaren Zeit, wird der komplette Inhalt übertragen. Aber wie schon richtig vermutet, hier bin ich voll flexibel.

Das JSON ist ja kein muss, wollte es nur "Einheitlich" und etwas "schön" machen.

Werde mir auf jeden Fall mal einen ESP32 als "Referenz" zulegen steht mit dem die Kommunikation, geht es mit dem Pico weiter.

Vielen Dank nochmal für den Support

Gruß,
Horst

 

[Beta-User]

Danke für deine nette Rückmeldung.

Bei der MCU würde ich gerne nur die Änderungen übertragen, wenn Q2 = on auf off fällt oder ein bestimmter Merkerwert (Rollo, Timer, Ereignissse,...) sich ändert. Nach einer einstellbaren Zeit, wird der komplette Inhalt übertragen. Aber wie schon richtig vermutet, hier bin ich voll flexibel.

Meine 2ct zu dem Thema:
Der Aufwand, das auf der MCU-Seite zu realisieren, erscheint mir ungleich größer wie das Setzen von ein paar passenden Attributen auf der FHEM-Seite.
Im Zweifel würde ich sogar überlegen, ob es nicht einfacher wäre, schlicht die Bit-Arrays an FHEM durchzureichen, und die in (Perl-) myUtils-Code auseinanderzunehmen...