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 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?
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
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
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.
// 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")){
....
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
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 (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 (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.
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.
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.
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
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" )
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.
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...
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:
define ntft_03 notify PV_Anlage_1:Act_state_of_charge:.* { fhem "set MQTT2_FHEM_Server publish -r h17TFT/display $NAME $EVENT"}
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
Was das notify angeht: in dem Fall mußt du nicht auf die Perl-Ebene, dann ist es einfacher lesbar:
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: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.