Datenübernahme von MQTT2 nach Userreadings oder direkt nach Filelog

[Otto123]

Steht so im Wiki - ich meine, aus gutem Grund...

Aber eben doch speziell und nicht generell https://wiki.fhem.de/wiki/MQTT2_CLIENT - oder?

Soweit ich das einschätze: ist hier ein MQTT2 Standard Umgebung mit ein paar Tasmota Sensoren im Spiel, die cfg wird direkt editiert, das FileLog ist ein Buch mit 7 Siegeln und eocr ist unwissend irgendwie gesetzt.   
Aber mag ja sein ich sehe noch nicht sehr viel ...

[TomLee]

Steht so im Wiki - ich meine, aus gutem Grund...

Verlink doch gleich ein Beispiel warum, das letzte mal ist ja nicht so lange her, das man auch versteht warum.

https://forum.fhem.de/index.php/topic,121608.msg1162281.html#msg1162281

[Nobbynews]

Interessant am device HZS finde ich
- CFGFN      /opt/fhem/FHEM/MQTT_Sensoren.cfg
- DEF        MQTT2_FHEM_Server
-  IODev      MQTT2_FHEM_Server
- Attributes:
   IODev      MQTT2_HZ_Sensoren.  -> da nur Empfang hier unerheblich

[SABINEMUELLER]

Hier das LOG-Device:

Code Auswählen Erweitern

Internals:
   CFGFN      /opt/fhem/FHEM/MQTT_Sensoren.cfg
   DEF        ./log/HZS_Buero_DHT11_%Y_%m.log HZS_Buero_DHT11:Buero_DHT11_LOG:.*
   FD         46
   FUUID     
   NAME       FileLog_HZS
   NR         661
   NTFY_ORDER 50-FileLog_HZS
   REGEXP     HZS_Buero_DHT11:Buero_DHT11_LOG:.*
   STATE      active
   TYPE       FileLog
   currentlogfile ./log/HZS_Buero_DHT11_2021_07.log
   logfile    ./log/HZS_Buero_DHT11_%Y_%m.log
   READINGS:
     2021-07-11 18:04:44   linesInTheFile  7
Attributes:
   logtype    text
   room       MQTT->4_Log


Nochmal die aktuelle Konfigdatei:

Code Auswählen Erweitern

define MQTT2_FHEM_Server MQTT2_SERVER 1883 global
setuuid MQTT2_FHEM_Server 60e1d481-f33f-5d57-9cbd-704548dfa57240dc
attr MQTT2_FHEM_Server ignoreRegexp cmnd/[^:"]+:
attr MQTT2_FHEM_Server room MQTT->1_Status


define HZS MQTT2_DEVICE MQTT2_FHEM_Server
attr HZS IODev MQTT2_HZ_Sensoren
attr HZS autocreate 0
attr HZS devStateStyle style="color:blue;;font-weight:bold"
attr HZS event-min-interval Buero_DHT11_LOG:60
attr HZS event-on-change-reading DHT11-02_Temperature,DHT11-02_Humidity,DHT11-02_DewPoint
attr HZS icon temperature_humidity
attr HZS readingList tele/DVES_EAD76F/LWT:.* LWT\
cmnd/DVES_EAD76F/POWER:.* Power\
tele/DVES_EAD76F/INFO.:.* { $EVENT =~ m,^..Info[1-3]..(.+).$, ?  json2nameValue($1,'',$JSONMAP) : json2nameValue($EVENT,'',$JSONMAP) }\
stat/DVES_EAD76F/RESULT:.* { json2nameValue($EVENT,'',$JSONMAP) }\
stat/DVES_EAD76F/POWER1:.* state\
tele/DVES_EAD76F/STATE:.* { json2nameValue($EVENT,'',$JSONMAP) }\
tele/DVES_EAD76F/SENSOR:.* { json2nameValue($EVENT,'',$JSONMAP) }\
tele/DVES_EAD76F/UPTIME:.* { json2nameValue($EVENT,'',$JSONMAP) }
attr HZS room MQTT->1_Status
attr HZS stateFormat {sprintf("Temperatur: %.1f °C   Feuchte: %.1f %%   Taupunkt: %.1f °C", ReadingsVal($name,"DHT11-02_Temperature",0), ReadingsVal($name,"DHT11-02_Humidity",0), ReadingsVal($name,"DHT11-02_DewPoint",0))}
attr HZS userReadings Buero_DHT11_LOG:DHT11-02_Temperature:.* {sprintf("Temperatur: %.1f °C   Feuchte: %.1f %%   Taupunkt: %.1f °C", ReadingsVal($name,"DHT11-02_Temperature",0), ReadingsVal($name,"DHT11-02_Humidity",0), ReadingsVal($name,"DHT11-02_DewPoint",0))}

define FileLog_HZS FileLog ./log/HZS_Buero_DHT11_%Y_%m.log HZS_Buero_DHT11:Buero_DHT11_LOG:.*
attr FileLog_HZS logtype text
attr FileLog_HZS room MQTT->4_Log


Bei dem readingList, wie oben schon geschrieben, weis ich nicht was was bedeutet und die WIKI ist da auch nicht aussagekräftig.
Ich habe im Internet schon versucht weitere Info zu bekonmmen. Leider aber nicht Verwertbares. Die Server Konfig habe ich großteils aus dem Wiki. Wie Beta-User schon bemerkt hat.
Wenn ich Bezeichnungen, Namengebungen ändern oder anpassen soll, einfach nur sagen was und wie. Das ist ein Testsystem, da ist noch alles möglich.
Ich bin mir auch nicht sicher ob der Weg über das userreading der richtige ist. Das war nur eine Idee von mir.
Wenn es eine bessere Möglichkeit gibt bin ich für Vorschläge offen.

Gruß
Sabine

[Otto123]

Das ist ein Testsystem, da ist noch alles möglich.
Ich bin mir auch nicht sicher ob der Weg über das userreading der richtige ist. Das war nur eine Idee von mir.

Ich sehe hier nicht durch, zuviele verschiedene zu komplizierte Namen und Geräte. Vielleicht mag das ein Anderer aufdröseln.

Mein Empfehlung: Auf Anfang:
nicht per Hand editieren, cfg Strukturen sind für FHEM so nützlich wie ein Sack Reis.
Mit einem neuen unverbrauchten FHEM starten.
einfach einen MQTT2_SERVER definieren ohne weitere attribute
den Tasmota auf diesen Server verbinden
Per autocreate das MQTT2_DEVICE anlegen lassen - da ist das LogDevice dabei.
Das userReadings anlegen, es wird von selbst mitgeloggt.
Dann einfach mit dem Wizard das Logging einschränken, das ist normalerweise intuitiv bedienbar.
Dann am Gerät weiter spielen bis der gewünschte Stand erreicht ist.
Die event Attribute versuchen zu verstehen.

Achso und wenn ich den Hinweis und Link von Beta-User und TomLee richtig verstehe: nicht ohne Not die topics in tasmota unwissend verbiegen.

Gruß Otto

[Nobbynews]

Hier stimmt doch etwas ganz gewaltig nicht.
In den lists in Antwort #12 haben weder das device HZS noch MQTT2_FHEM_SERVER eine FUUID.
Das Log-Device in Antwort #18 hat ebenfalls keine FUUID, dafür aber der Server in der Config (Auszug von fhem.cfg) plötzlich ein setuuid.
Und dann ist die def von

Code Auswählen Erweitern


define HZS MQTT2_DEVICE MQTT2_FHEM_Server


imho alles andere als richtig. Vermutlich wird aber der Parameter "MQTT2_FHEM_SERVER" im define des device MQTT2_DEVICE nicht berücksichtigt oder geprüft. ?

Ich bin raus.

Norbert

[Beta-User]

Achso und wenn ich den Hinweis und Link [...] richtig verstehe: nicht ohne Not die topics in tasmota unwissend verbiegen.

@Otto:
Die Schlussfolgerung ist zwar an sich auch nicht falsch, aber zur Klarstellung: sowohl bei der Empfehlung zu der ignoreRegexp (die schon länger "indirekt" durch den Verweis auf M2C in den "Praxisbeispielen" steht) wie in dem verlinkten Thread ging es um was anderes:
- allgemein sollte man die Topics "ignorieren", die dazu da sind, Anweisungen an (andere) Clients wie FHEM (intern) zu senden (bei Tasmota eben "cmnd/..."). Sonst kann man nicht sauber zwischen Anweisung und Ergebnis unterscheiden (wenn die Anweisung von woanders her kommt wie FHEM).
- In dem verlinkten Thread hat der User versucht, die Anweisung trotzdem abzugreifen, um "indirekte Verknüpfungen" herzustellen - und das auch noch über den "eigenen" cmnd-Topic. MAn. mehrfach "unglücklich"...
(Hier OT: Für sowas sollte man dann versuchen, entweder an den anderen Client direkt zu publishen (dessen Reaktion sollte dann wieder in FHEM ankommen), oder eben einen "normalen Tastendruck-Event" zu generieren (=>anderer Topic), auf den man dann mit normalen FHEM-Mitteln reagiert.

Die Gesamtzusammenhänge scheinen aber auch über den von TomLee verlinkten Thread (Danke! Der paßt m.E. an sich schon!) nicht klarer zu werden, von daher _glaube ich_, es ist einfacher, die pauschale Empfehlung so unerklärt im Wiki stehen zu lassen, die cmnd-Topics zu ignorieren und bei Bedarf zu erläutern, warum das so ist - es gibt jetzt so langsam aber sicher hoffentlich genug User, die wissen, warum das da steht...

Ich sehe hier nicht durch, zuviele verschiedene zu komplizierte Namen und Geräte. Vielleicht mag das ein Anderer aufdröseln.

Was das angeht, schließe ich mich sowohl der Analyse wie der Schlussfolgerung an!
Wollte nur klarstellen, dass in dem ganzen Wirrwarr dieser eine "richtige" Punkt zu finden war, den man bitte nicht in Frage stellen sollte...

[Otto123]

Wollte nur klarstellen, dass in dem ganzen Wirrwarr dieser eine "richtige" Punkt zu finden war, den man bitte nicht in Frage stellen sollte...

@Beta-User Hab ich verstanden und werde es im Kopf behalten.