Werte an TFT via ESP8266&MQTT übergeben

Patrick Strassburger · 12 November 2020, 01:05:07

Hallo,

ich möchte Werte von meiner Heizung und PV Anlage an einem abgesetzten TFT anzeigen lassen.
Ich kann Werte von dem ESP8266 mit MQTT an FHEM senden aber habe einen Knoten, wie dies in die andere Richtung funktioniert.
Direkt über

Code Auswählen

set MQTT2_FHEM_Server publish h17TFT/MqttGenericBridge2 solar 1122445" funktioniert es, nur würde ich gerne mqtt_generic_bridge bzw. bridgeRegexp nutzen um die verschiedenen Werte von sich ändernden Readings übertragen.

Mein derzeitiger Stand - ich habe nun auch das eigentliche ESP8266TFT Device als bridge eingerichtet, nachdem ich meine verstanden zu haben, dass das erste erkannte Device als "MQTT2_CLIENT_general_bridge" definiert werden soll? In dem Fall würde ich MQTT2_MQTT2 gar nicht benötigen?

Code Auswählen

Internals:
   CID        MQTT2
   DEF        MQTT2
   DEVICETOPIC MQTT2_MQTT2
   FUUID      5fa5253b-f33f-f3a5-4a14-3e4580067fb8f827
   IODev      MQTT2_FHEM_Server
   NAME       MQTT2_MQTT2
   NR         213
   STATE      ???
   TYPE       MQTT2_DEVICE
   Helper:
     DBLOG:
       attrTemplateVersion:
         myDbLog:
           TIME       1605135325.1237
           VALUE      20200625_2
       state:
         myDbLog:
           TIME       1605133570.4359
           VALUE      clear_all
   OLDREADINGS:
   READINGS:
Attributes:
   IODev      MQTT_GENERIC_BRIDGE
   autocreate 1
   bridgeRegexp (MQTT2_ESP8266_[^/]+)/.*/.*/.*:.* "$1" "$2"
   icon       mqtt_bridge_2
   model      MQTT2_CLIENT_general_bridge
   room       70_MQTT
   setList    clear_all:noArg {fhem("deleteattr $NAME readingList; deletereading -q $NAME (?!associatedWith).*");return undef}
   setStateList on off

Code Auswählen

Internals:
   CFGFN      
   CID        ESP8266_000
   DEF        ESP8266_000
   DEVICETOPIC MQTT2_ESP8266_000
   FUUID      5fac71cb-f33f-f3a5-d659-7bc128540c4cf6ea
   IODev      MQTT2_FHEM_Server
   LASTInputDev MQTT2_FHEM_Server
   MQTT2_FHEM_Server_MSGCNT 370
   MQTT2_FHEM_Server_TIME 2020-11-12 00:52:51
   MSGCNT     370
   NAME       MQTT2_ESP8266_000
   NR         107021
   STATE      ???
   TYPE       MQTT2_DEVICE
   Helper:
     DBLOG:
       attrTemplateVersion:
         myDbLog:
           TIME       1605137234.63891
           VALUE      20200625_2
       counter:
         myDbLog:
           TIME       1605138771.52997
           VALUE      210
       outTopic:
         myDbLog:
           TIME       1605137718.00209
           VALUE      hello world
       status:
         myDbLog:
           TIME       1605137718.51885
           VALUE      reconnected
   OLDREADINGS:
   READINGS:
     2020-11-12 00:52:51   counter         210
     2020-11-12 00:35:18   outTopic        hello world
     2020-11-12 00:35:18   status          reconnected
Attributes:
   IODev      MQTT2_FHEM_Server
   autocreate 1
   bridgeRegexp (MQTT2_ESP8266_*[^/]+)/.*/.*:.* "$1"
   comment    Do not use very open bridgeRegexp expressions! This might lead to irritating results... Especially make sure to not have two regexpes that may both match!
   icon       mqtt_bridge_2
   model      MQTT2_CLIENT_general_bridge
   readingList ESP8266_000:outTopic:.* outTopic
ESP8266_000:h17TFT/state/status:.* status
ESP8266_000:h17TFT/counter:.* counter
ESP8266_000:ESP8266_000/h17TFT/counter:.* counter
   room       MQTT2_DEVICE
   setList    clear_all:noArg {fhem("deleteattr $NAME readingList; deletereading -q $NAME (?!associatedWith).*");return undef}
   setStateList on off

Wende ich die regexp richtig an? Über einen Denkanstoß würde ich mich freuen.

Viele Grüße,
Patrick

rabehd · 12 November 2020, 09:56:35

ZitatIch kann Werte von dem ESP8266 mit MQTT an FHEM senden aber habe einen Knoten, wie dies in die andere Richtung funktioniert.

Dein Ansatz klingt für mich, der nur wenig Ahnung hat, komisch.
Ich habe mir mal etwas ähnliches für Zustände und Anmeldung gebaut.

Du sendest die Info an den Broker (Server).
Der Client meldet(vorher) sich beim Broker für die Topics an, die er erhalten will. Der Broker informiert den Client (aurtomatisch) wenn sich der Topic ändert, darauf statet der Client eine Routine, die Änderung verarbeitet.
So habe ich MQTT verstanden.

Code Auswählen

// reagiert, wenn bei MQTT im abonnierten Topic eine neue Nachricht eintrifft
void callback(char* topic, byte* payload, unsigned int length) {
  
  Serial.println((char*)payload);
  // Wenn Topic ibutton, dann
  if (!strcmp(topic,"/Key/ibutton/status")){
....

Patrick Strassburger · 12 November 2020, 10:41:06

Hallo,

ZitatDein Ansatz klingt für mich, der nur wenig Ahnung hat, komisch.

war schon spät...
Den ESP habe/hatte ich ja als Client beim Broker (FHEM/MQTT2) erfolgreich für das Topic angemeldet. Ich steh nur auf dem Schlauch wie ich ein Reading (verschiedene Werte nicht "on/off" von einem nicht MQTT Device an eben jene Subscription senden kann. Nach all dem Lesen dachte ich bridgeexp wäre der Ansatz, dies würde mir auch später helfen wenn ich noch 1-2 zusätzliche kleine TFTs verbaue.
Ich geb zu um so mehr ich lese/versuche es zu verstehen umso verlorener fühle ich mich.

Viele Grüße,
Patrick

Beta-User · 12 November 2020, 10:56:27

Mir ist der Ansatz auch nicht ganz klar (das Ziel schon), zumal überhaupt nicht klar ist, ob jetzt MQTT2_SERVER im Einsatz ist oder z.B. mosquitto (=>https://wiki.fhem.de/wiki/MQTT#Welche_Infos_sollten_Anfragen_im_MQTT-Forum_enthalten.3F)

Die Ganze Konstruktion mit mosquitto+M2_CLIENT ist halt relativ komplex und mMn. nicht gut geeignet, um in das ganze Thema reinzukommen, und MQTT_GENERIC_BRIDGE macht es nicht einfacher (ist aber vermutlich das Mittel der Wahl hier)...

Hier hatte ich mal erläutert, wie man den Datenaustausch zwischen einem externen Device (ob display oder was anderes, ist prinzipiell ja egal) und FHEM via externem Broker organisieren _könnte_: https://forum.fhem.de/index.php/topic,109192.msg1096411.html#msg1096411

Grundsätzlich: bridgeRegexp wirkt nur auf eingehende Nachrichten und kommt auch nur zum Tragen, wenn es _noch kein_ (MQTT2-) Device gibt, das eine passende readingList hat. In Senderichtung hat das keine Bedeutung.

Die erste Frage wäre daher: Brauchst du einen externen Broker? Wenn nein: Fang' mit MQTT2_SERVER an, dann entfällt schon mal ein großer Teil der Zuordnungsprobleme.

rabehd · 12 November 2020, 11:00:44

Bei mir macht das ein DOIF, welche auf die Änderung eines Zustandes reagiert.
Hier im Beispiel wird, wenn die Structure "allesLicht" auf "ein" geht, dann wird diese Info an MQTT gesendet.

Code Auswählen

DOELSEIF ([allesLicht:"^ein$"]) (set MQTT2Broker publish -r /Sicherheit/Zustand/allesLicht ein)

MQTT sind für mich einfach Postfächer. Jemand legt dort einen neuen Zettel rein und das Postamt informiert die Empfänger (die online sind) was da ist.
Das Verfahren trennt Sender und Empfänger.
FHEM sendet nicht an den ESP, sondern beide kommunizieren mit MQTT.

Patrick Strassburger · 12 November 2020, 11:20:54

Hallo Beta-User,

Zitatzumal überhaupt nicht klar ist, ob jetzt MQTT2_SERVER im Einsatz ist oder z.B. mosquitto

Ich habe MQTT2_SERVER im Einsatz - ich sehe ich habe diesen im ersten Posting nicht gelistet.
Ich schaue mir Deinen Post heute abend genauer an - vielen Dank!

Hallo rabehd,

"DOELSEIF" in Verbindung mit "set publish" schaue ich mir auch einmal an - vielen Dank!

Viele Grüße,
Patrick

Beta-User · 12 November 2020, 11:21:46

Klar, wenn man "nur ein paar Daten" versenden will, braucht man den Aufwand mit MGB nicht, das geht mit einem "einfacheren" Eventhandler genausogut (auch MGB ist (u.a.) einer), ich würde das wohl bei nur wenigen Daten auch eher mit einem notify machen. Geschmackssache und eine Frage, wie die Landschaft mittelfristig aussehen soll.

Was die Topic-Struktur angeht, sollte man aber darauf achten, dass man Sende- und Empfangsseite einfach auseinanderhalten kann (machst du wohl mit "Zustand"), dann kann man auch autocreate-features in FHEM weiter nutzen

. (ignoreRegexp@IO ist dein Freund).

(OT: diese Unix-Pfad-like topic-Anfänge sind einfach nur "uncool", und da die meisten (besseren) firmwares auch keinen Schrägstrich am Anfang verwenden, ist es für die Handhabung insgesamt (ignoreRegexp hatte ich schon genannt, es gibt aber noch ein paar mehr, ähnlich gelagerte Themen) mAn. einfacher, man beginnt gleich mit "content" und macht klarer, wo es herkommt. Kommt dan in etwa sowas raus: "fhem_main/status/Sicherheit/allesLicht" )

rabehd · 12 November 2020, 11:23:10

Zitat"DOELSEIF" in Verbindung mit "set publish" schaue ich mir auch einmal an - vielen Dank!

Das ist natürlich nur ein Ausschnitt eines größeren DOIF. Grundsätzlich geht es nur darum auf ein Event zu reagieren. notify geht genauso.

Beta-User · 12 November 2020, 11:28:18

Nachtrag, nachdem du M2_SERVER im Einsatz hast und das dein "Erstling" zu sein scheint: Lösche einfach nochmal alle MQTT2_DEVICE-Geräte und fang' nochmal mit autocreate + reboot des ESP an.

bridgeRegexp (und v.a. MQTT2_CLIENT_general_bridge) kannst du auch erst mal ignorieren, es sei denn, du wolltest etwas über MGB _empfangen_. Bei anderen Devices wird dir das ggf. wieder begegnen, aber dann wird es ggf. auch klarer sein, was es damit auf sich hat...

Patrick Strassburger · 12 November 2020, 23:53:56

Hallo,

vielen Dank für eure Hilfe, in der Tat ging es nun mit relativ wenig Aufwand. Ich werde für jeden Wert, der übertragen werden soll, ein eigenes Notify anlegen:

Code Auswählen

define ntft_03 notify PV_Anlage_1:Act_state_of_charge:.* { fhem "set MQTT2_FHEM_Server publish -r  h17TFT/display $NAME $EVENT"}

Code Auswählen

Internals:
   DEF        PV_Anlage_1:Act_state_of_charge:.* { fhem "set MQTT2_FHEM_Server publish -r  h17TFT/display $NAME $EVENT"}
   FUUID      5fadb6f6-f33f-f3a5-1a24-eaed60393c2a3506
   NAME       ntft_03
   NOTIFYDEV  PV_Anlage_1
   NR         227
   NTFY_ORDER 50-ntft_03
   REGEXP     PV_Anlage_1:Act_state_of_charge:.*
   STATE      active
   TYPE       notify
   READINGS:
     2020-11-12 23:28:06   state           active
Attributes:
   room       70_MQTT

Vielen Dank und Grüße,
Patrick

Beta-User · 13 November 2020, 11:29:14

Was das notify angeht: in dem Fall mußt du nicht auf die Perl-Ebene, dann ist es einfacher lesbar:

Code Auswählen

define ntft_03 notify PV_Anlage_1:Act_state_of_charge:.* set MQTT2_FHEM_Server publish -r h17TFT/display $NAME $EVENT
Und wenn die anderen Bedingungen ähnlich gestrickt sind, kannst du auch einfach alle Auslöser nacheinander auflisten:

Code Auswählen

define ntft_03 notify PV_Anlage_1:Act_state_of_charge:.*|PV_Anlage_2:temp_0815:.* set MQTT2_FHEM_Server publish -r  h17TFT/display $NAME $EVENT

(@alle möglichen Schlauberger: Ja, ist klar, dass man die regex kürzen könnte, das wäre aber aus FHEM-Sicht kontraproduktiv...).

Dass der Code auf dem ESP8266 dieses payload-Format "mag", kommt mir allerdings komisch vor... Hätte jetzt eher erwartet, dass die Topic-Struktur irgendwelche Zeilenvorgaben oä. wiederspiegeln würde. Aber wenn es tut, soll's mir recht sein.