Stringoperationen

[Dragan57]

Hallo
Ich versuche seit Tagen aus Shelly 1PM+ Übertragung (MQTT) einzelne Werte, tC in °C oder tF in °F in ein Dummy oder Userreading zu extrahieren.

Nach

Code Auswählen Erweitern

define Boiler MQTT_DEVICE
attr Boiler subscribeReading_Temp-Boiler Boiler/status/temperature:100

Kriege ich den String
    

Code Auswählen Erweitern

{"id": 100,"tC":23.4, "tF":74.2}

in dem Attribut Temp-Boiler. Soweit so gut.

Wie kriege ich die 23.4 isoliert um weiter damit zu arbeiten.

Besten Dank für ein paar Zeilen (bitte kein Link, ich werde aus den gefundenen Beispielen nicht schlau)

Dragan

[Beta-User]

Gibt es einen guten Grund, warum du das mit MQTTT_DEVICE löst (und nicht mit MQTT2_DEVICE)?

Das kann JSON-Blobs direkt auflösen (und "gute" Reading-Namen erzeugen), bei der alten Implementierung braucht es Hilfsmittel wie expandJson...

[Dragan57]

Hallo Beta-User

Vielen Dank für die schnelle Antwort.

Ja den Grund gibt es.
Meine Fhem Installation is sehr alt (ca. 8 Jahre), sehr Umfangreich (ca. 50 Sensoren und 20 Aktoren).
Ich habe schon sehr viel Zeit in Updateversuche investiert, leider ohne Erfolg.
Deshalb existiert wohl kein MQTT2

[Beta-User]

Meine Fhem Installation is sehr alt (ca. 8 Jahre)

Falls das OS auch so veraltet ist, und irgendwas davon "online" ist, ist ein update (nicht nur von FHEM) ein MUSS (vermutlich nicht nur my2ct!).

Auf welcher Plattform läuft das (Pi nn oder "was gscheids")? (Daran hängt ggf. meine Empfehlung für die weitere Vorgehensweise).

sehr Umfangreich (ca. 50 Sensoren und 20 Aktoren).

Na ja, alles relativ; auf 20 Aktoren komme ich fast schon nur mit Rollläden und Jalousien, das ganze ZigBee-Zeug ist da noch gar nicht mit dabei...

Deshalb existiert wohl kein MQTT2

Falls du auch kein expandJson hast (?), geht notfalls auch ein userReadings-Eintrag, aber wie oben schon erwähnt, meine ich, es ist dringlichst Zeit für ein update.

[Dragan57]

Aktuell läuft mein Fhem auf einem Raspberry

Mit der Idee, dass es mit einem Userreading gehen müsste, bin ich auch schon gekommen.
Nur mit der Parameterisierung stehe ich offensichtlich auf Kriegsfuss.

Eventuell kannst Du mir den zündenden Funken rüberreichen?

[Jamo]

Wie kriege ich die 23.4 isoliert um weiter damit zu arbeiten.

Hier mal ein Vorschlag. Das Beispiel kann man so oben in fhem in die Kommandozeile eingeben, und gibt Dir die 23.4 zurück. Das "(\d\d\.\d)" gibt den ersten match (return $1) der Zahl dd.d zurück, die nach dem String '"tC":' gefunden wird.

{my $test = '{"id": 100,"tC":23.4, "tF":74.2}';; $test =~ /"tC"\d\d\.\d)/;; return $1}

[Beta-User]

Vielleicht etwas generischer wäre diese regex:

Code Auswählen Erweitern

tC..([\d.]+)Um sowas zusammenzubasteln, würde ich einen Blick auf https://regex101.com/ empfehlen, da ist auch erklärt, was was bedeutet.

Aktuell läuft mein Fhem auf einem Raspberry

Frage: Was machst du, wenn die Hardware abkachelt?!? Das Ding scheint ja 8 Jahre alt zu sein, also max. PI B 3+ (oder wie das Ding halt hieß).

Falls du einen 2. rumliegen hast: SD-Karte hast du bestimmt irgenwo rumfliegen, da ein aktuelles OS drauf und FHEM installieren ("the-easy-way"-Anleitung). Dann kannst du entweder in einem Minimal-FHEM per "installer"-Modul checken, was du ggf. für deine aktuelle fhem.cfg so an Perl-Modulen brauchst, oder du startest das neue FHEM dann halt mit der alten cfg und gehst nach und nach die Fehlermeldungen durch, die da so erscheinen, falls es dir zu mühsam sein sollte, die (eventuell) benötigten Perl-Module selbst aus der commandref etc. zusammenzuschreiben.

Falls du keine alternative Hardware hast: Besorge dir einen Lüfterlosen Mini-PC (ggf. auch einen gebrauchten Thin client) und mach es damit; ist billiger wie die aktuellen Pi (und performanter). Der Pi kann danach wieder als Backup dienen (dann halt mit neuer Karte, damit du die alte erst mal noch als Backup bereithalten kannst.) (Für den Fall, dass du irgendwelche Pi-GPIO-Basteleien hast: die kannst du bei der Gelegenheit dann auch direkt loswerden...!)

[Dragan57]

Vielen Dank für die zündende Idee.

Die Lösung:

Code Auswählen Erweitern

{my $temp = ReadingsVal("Boiler","Temp-Boiler",0);; $temp=~ /"tC":(\d\d\.\d)/;;  return $1}
bzw. mit event gesteuerten Zuweisung zur Dummy Variable

Code Auswählen Erweitern

define T_Boiler dummy
define Temp_Boiler_event notify Boiler:Temp-Boiler:.* {my $test = ReadingsVal("Boiler","Temp-Boiler",0);; $test=~ /tC..([\d.]+)/;; fhem("set T_Boiler $1");; }

wobei in dem Reading Boiler:Temp-Boiler der Inhalt

Code Auswählen Erweitern

{"id": 100,"tC":23.4, "tF":74.2}
steht

[Beta-User]

Die Lösung

... ist m.E. nicht zur Nachahmung zu empfehlen...

(Wird aber vermutlich eh' keiner machen, weil das ganze System so veraltet ist, dass man vermutlich v.a. deswegen auf solche Klimmzüge kommt, um so ein einfaches Problem zu "lösen".)

[Dragan57]

Hallo Beta-User

Ich habe aufgerüstet 

Aktuell:

-Fhem auf windows
-div. Shellys und Sensoren, welcheauf ESP32 basieren.

Die readings laufen vom feinsten.

Was ich nicht hinkriege ist ein Reading auf ein ESP32 via MQTT auf ein display zu senden.

Das MQTT device (MQTT2_esp_hum_) ist verbunden und sendet Werte via MQTT2_SERVER an FHEM.

Nun möchte ich aus diversen Devices z.B. Shelly "main" das Resultat von Reading "power_TTL" zu dem ESP32 via MQTT in einer Zeile anzeigen lassen.

Die Werte werden von einem Simulator zu dem ESP32 via Paiload "esp-hum/esp-hum/in0" empfangen und verarbeitet.

Bis jetzt bringe ich FHEM nicht dazu über den entsprechenden Pfad den gewünschten Wert zu senden.

Kanst Du mir mit 2,3 Konfigurations Zeilen auf die Sprünge helfen?

Danke und Gruss
Hansulrich

[Prof. Dr. Peter Henning]

Erst einmal ist FHEM auf Windows keine "Aufrüstung", sondern eher eine Krücke.
Da war der Raspberry Pi die bessere Wahl - aber OK.

Zweitens scheint mir das noch etwas durcheinander zu gehen mit "Device" und "Server". Nur MQTT-Devices (also Clients) können Daten an den Server senden.
Wenn man also ein Reading über MQTT an einen anderen MQTT-Client senden will, muss dafür ein _sendendes_ MQTT-Device mit entsprechender setList existieren. In den Topics der Setlist kann man beliebige Daten aus FHEM weiter verarbeiten - also auch irgendwelche Readings. Das _empfangende_ MQTT-Device muss diese Topics beim Server abonnieren.

Ist im Wiki alles sehr gut beschrieben.

LG

pah

[Dragan57]

Hallo pah

Somit hast Du mir bereits bekannte sichtweise über die Übertragungsrichtungen erklährt.

Mir ist klar, Clients senden -> Server empfagnen.

Nichts desto trotz, kann man (so habe ich es mindestens mit der alten FHEM Version hingekriegt) an einen ESP neben den lokalen Messwerten (die via MQTT gesendet werden) auch Messwerte von anderen Devices senden um ev. Berechnungen anzustellen oder auf dem Display anzeigen zu lassen.

Mir ist klar, dass es via Setlist laufen müsste. Blos blicke ich nicht hinter den Syntax bzw. das zu erstellende Umfeld um Werte zu publishen.

Danke auch dass deine 2-3 Zeilen sich wie so oft auf ein Wiki hinweisen ohne einen konkreten Lösungs Ansatz zu vorzuschlagen.

Sei versichert, ich habe schon Stunden bis Tage mit einlesen und Beispielen verbracht.

Wie schreibst Du "aber OK", Midestens hast Du reagiert.

Besten Dank
HUM

[Beta-User]

Meine "3 Zeilen":

- FHEM auf Win.* machen nur Experten, alle anderen sind in der Regel damit irgendwann unglücklich.
- Wenn man ein neues Thema hat, sollte man nicht Threads in alle Ewigkeit fortführen, sondern eigene als gelöst markern und für das neue Thema im passenden Bereich posten*. (Von fremden Threads rede ich gar nicht).
- * Das gilt aber nur, wenn man nicht was durch einfaches Suchen findet. Mit "MQTT2_DEVICE setlist display" landet man z.B. hier: https://forum.fhem.de/index.php?topic=127407.0

Ansonsten gibt es gefühlt mindestens ein Dutzend Optionen, wie man das kombinieren kann:
- die "Basislösung" könnte auch ein notify sein, das auf alle passenden Basis-Trigger (-Reading-updates) lauscht und das dann (aufbereitet?) per "publish"-Anweisung (hier über den MQTT2_SERVER) an den jweils passenden topic weitergibt.
- Oder ein at, das alles ohne Events sammelt,
- ein periodicCmd am MQTT2_DEVICE (mit passender setList), und nicht zuletzt käme
- MQTT_GENERIC_BRIDGE in Frage.

Kommt auch ein bißchen darauf an, wie die persönlichen Vorlieben sind, ich würde es vermutlich mit MQTT_GENERIC_BRIDGE versuchen (vermutlich: separate Instanz für das Display).

[Prof. Dr. Peter Henning]

Clients senden -> Server empfagnen.

Schon mal falsch. Beide senden _und_ empfangen.

Sei versichert, ich habe schon Stunden bis Tage mit einlesen und Beispielen verbracht.

Das kann ich nicht so ganz glauben. Eine Suche mit den Stichworten "MQTT setlist" liefert 21 _Seiten_ voller Hinweise auf das Forum, unter den ersten zehn Einträgen sind schon mehrere Lösungsansätze.

LG

pah