MQTT-Neuling braucht Hilfe (p4d - Fröling S1 Turbo Holzscheitkessel mit S-3200)

[rudolfkoenig]

Ich meinte ein Regexp der Art: p4d2mqtt/sensor/.*/state
Auf der anderen Seite kann man mit der "unless" Variante und ein .* readingList-Regexp die homeassistant Zeile sparen.

Der Nachteil deines letzten Vorschlags ist, dass man, falls den sinnfreien _value vermeiden will, in jsonMap alle 40+ Readings einbauen muss.
Der Vorteil, dass man die (ab morgen ) kaputtgemachten Umlaute umbenennen kann.

Ich wuerde dein Vorschlag nehmen, _0x76 & co per $TOPIC=~m,sensor/([^/]+)_0x../, wegmachen, die 2-3 Umlaut-Faelle mit jsonMap lesbar machen, und mit _value leben.

[Beta-User]

Hmm, an das weg-regexen hatte ich auch schon gedacht, aber da ist das Problem, dass es mind. zwei gibt, die unterschiedliche HEX-Adressem zu repräsentieren scheinen. Wenn das doch dasselbe ist, macht es Sinn, das so wie vorgeschlagen zu erledigen...
Eines der beiden:

Code Auswählen Erweitern


     2020-04-20 12:47:36   BetriebsartHeizkreis_0x17 0.00
     2020-04-20 12:47:36   BetriebsartHeizkreis_0x1b 0.00

@hoppel: Da du den "Künstler" näher zu kennen scheinst: Evtl. wäre es eine Idee, das irgendwie auf der MQTT-Seite dahingehend zu verbessern, dass man wenigstens nur sprechende Namen hat oder die Möglichkeit, JSON (partiell?) abzuschalten und dann auf den jeweiligen Pfad einfach nur den Wert in Klartext bekommt.
Ist jedenfalls "ungewöhnlich", wie das hier gelöst ist...

[hoppel118]

Ich habe noch keine Idee, wie man diese vermurkste Schnittstelle automatisch entdecken koennte.
Template zaehlt fuer mich nicht als automatisch, und ist in diesem Fall die beste Loesung.

Gegen ein Template habe ich nichts einzuwenden.

Achtung: mit dem update werden die "schoenen" Umlaut-Readings  kaputtgemacht.

Auf die Umlaute in den Readings lege ich keinen Wert. Wichtig ist, dass die Readings überhaupt dargestellt werden. Wenn in FHEM grundsätzlich keine Readings mit Umlauten existieren, warum sollte das denn hier anders sein?

@Rudi: Das shier habe ich (noch?) nicht verstanden:
@hoppel118:

"Von alleine" wird weder autocreate noch attrTemplate dieses "Ding" nicht in den Griff bekommen . Du wirst also mit dem händisch erstellten "leben müssen" .

Die erste Zeile kannst du entweder nach Rudi's Vorschlag oder auch so schreiben:

Code Auswählen Erweitern

p4d2mqtt/sensor/.* { return unless $TOPIC=~m,sensor/([^/]+)/,; json2nameValue($EVENT, '', {value=>$1}) }
Bei dem ganzen würden mich die mitgelieferten Hex-Adressen noch stören. Da die aber von Bedeutung zu sein scheinen (mind. 2 Vorlauftemp sind genannt), müßte man da doch ggf. irgendwas mit jsonMap umbenennen, wenn man das haben wollte.

Die Hex-Adressen sind in diesem Fall praktisch, da ich so immer noch einen direkten Bezug zum eigentlichen Messwert aus der p4d-Software herstellen kann. Zum Verständnis: In der p4d Web-Oberfläche kann ich aus ca. 300 Messwerten auswählen, welche mir in der p4d Web-Oberfläche in Form eines Dashboards angezeigt werden sollen. Da p4d auch für andere Heizungsmodelle vom Hersteller Fröling verwendet werden kann und somit auch weitere Puffer, weitere Vor- und Rücklauftemperaturen, weitere Temperaturen generell, weitere Heizkreise, weitere Kessel, weitere Boiler, etc. angeschlossen werden können, hat man zwangsläufig Dopplungen in den Messwert-Bezeichnungen (Readingnamen). Mit dieser Steuerung kann man quasi alles steuern (Holzscheit-/-pelletverbrennung, Gas, Öl, Solar, etc.).

Kannst ja mal (parallel an einer Kopie) das hier testen:

Code Auswählen Erweitern

p4d2mqtt/sensor/.* { return unless $TOPIC=~m,sensor/([^/]+)/,; json2nameValue($EVENT, "${1}_", $JSONMAP) }

und dazu ein jsonMap-Attribut (aus der Hüfte geschossene Beispiele):

Code Auswählen Erweitern

Puffertemperaturoben_0x76_value:Puffertemperatur_oben Kesseltemperatur_0x0_value:Kesseltemperatur

Sobald ich das jsonMap-Attribut setze, werden alle Readings mit value gedoppelt. Oder habe ich bei folgendem Device irgendwas übersehen?

Code Auswählen Erweitern

Internals:
   CFGFN     
   CID        p4d_publisher
   DEF        p4d_publisher
   DEVICETOPIC EG_HZR_Heizung_Test
   FUUID      5e9da7ae-f33f-5dcf-a7dc-9f138bc0c06110ca
   IODev      mqtt2server
   LASTInputDev mqtt2server
   MSGCNT     405
   NAME       EG_HZR_Heizung_Test
   NR         891
   STATE      ???
   TYPE       MQTT2_DEVICE
   mqtt2server_MSGCNT 405
   mqtt2server_TIME 2020-04-20 15:57:10
   JSONMAP:
     Kesseltemperatur_0x0_value Kesseltemperatur
     Puffertemperaturoben_0x76_value Puffertemperatur_oben
   READINGS:
     2020-04-20 15:49:06   Abgas-Solltemperatur_0x13 275.00
     2020-04-20 15:57:05   Abgas-Solltemperatur_0x13_value 275.00
     2020-04-20 15:49:04   Abgastemperatur_0x1 66.00
     2020-04-20 15:57:04   Abgastemperatur_0x1_value 66.00
     2020-04-20 15:49:05   Außentemperatur_0x4 13.50
     2020-04-20 15:57:05   Außentemperatur_0x4_value 13.50
     2020-04-20 15:49:10   BetriebsartBoiler_0x156 1.00
     2020-04-20 15:57:09   BetriebsartBoiler_0x156_value 1.00
     2020-04-20 15:49:07   BetriebsartHeizkreis_0x17 0.00
     2020-04-20 15:57:06   BetriebsartHeizkreis_0x17_value 0.00
     2020-04-20 15:49:07   BetriebsartHeizkreis_0x1b 0.00
     2020-04-20 15:57:06   BetriebsartHeizkreis_0x1b_value 0.00
     2020-04-20 15:49:04   Betriebsmodus   Dauerlast
     2020-04-20 15:57:04   Betriebsmodus_value Dauerlast
     2020-04-20 15:49:08   Betriebsstunden_0x62 9825.00
     2020-04-20 15:57:07   Betriebsstunden_0x62_value 9825.00
     2020-04-20 15:49:08   BetriebsstundeninderFeuererhaltung_0x73 27.00
     2020-04-20 15:57:07   BetriebsstundeninderFeuererhaltung_0x73_value 27.00
     2020-04-20 15:49:10   BetriebsstundenvonKessel2Brennerkontakt_0x109 2426.00
     2020-04-20 15:57:08   BetriebsstundenvonKessel2Brennerkontakt_0x109_value 2426.00
     2020-04-20 15:49:05   Boardtemperatur_0x2 43.50
     2020-04-20 15:57:04   Boardtemperatur_0x2_value 43.50
     2020-04-20 15:49:08   BoilerpumpeAnsteuerung_0x90 0.00
     2020-04-20 15:57:07   BoilerpumpeAnsteuerung_0x90_value 0.00
     2020-04-20 15:49:08   Boilertemperaturoben_0x5d 67.50
     2020-04-20 15:57:06   Boilertemperaturoben_0x5d_value 68.00
     2020-04-20 15:49:10   Build_0x16f     2.00
     2020-04-20 15:57:09   Build_0x16f_value 2.00
     2020-04-20 15:49:10   EmpfohleneHolzmengebeimNachlegen_0x10a 0.00
     2020-04-20 15:57:09   EmpfohleneHolzmengebeimNachlegen_0x10a_value 0.00
     2020-04-20 15:49:09   FühleramHydraulikmodul03_0xff 67.50
     2020-04-20 15:57:08   FühleramHydraulikmodul03_0xff_value 68.00
     2020-04-20 15:49:06   Kesselstellgröße_0x12 100.00
     2020-04-20 15:57:05   Kesselstellgröße_0x12_value 100.00
     2020-04-20 15:57:04   Kesseltemperatur 74.50
     2020-04-20 15:49:04   Kesseltemperatur_0x0 75.00
     2020-04-20 15:55:04   Kesseltemperatur_0x0_value 75.00
     2020-04-20 15:49:11   Kesselzustand_0x1c9 5.00
     2020-04-20 15:57:10   Kesselzustand_0x1c9_value 5.00
     2020-04-20 15:49:09   Lambdasondenspannunggemessen_0xd3 24.00
     2020-04-20 15:57:08   Lambdasondenspannunggemessen_0xd3_value 24.00
     2020-04-20 15:49:09   Lambdasondenspannungkorrigiert_0xdc 24.00
     2020-04-20 15:57:08   Lambdasondenspannungkorrigiert_0xdc_value 24.00
     2020-04-20 15:49:10   PufferladezustandDiskret_0x1c0 4.00
     2020-04-20 15:57:09   PufferladezustandDiskret_0x1c0_value 4.00
     2020-04-20 15:49:10   Pufferladezustand_0x1bf 96.00
     2020-04-20 15:57:09   Pufferladezustand_0x1bf_value 95.00
     2020-04-20 15:49:09   Pufferladezustand_0xe1 96.00
     2020-04-20 15:57:08   Pufferladezustand_0xe1_value 95.00
     2020-04-20 15:49:08   PufferpumpenAnsteuerung_0x8c 0.00
     2020-04-20 15:57:07   PufferpumpenAnsteuerung_0x8c_value 0.00
     2020-04-20 15:49:09   PufferpumpenbegrenzungdurchAbgastemperatur_0xde 6.00
     2020-04-20 15:57:08   PufferpumpenbegrenzungdurchAbgastemperatur_0xde_value 6.00
     2020-04-20 15:57:07   Puffertemperatur_oben 75.00
     2020-04-20 15:49:08   Puffertemperaturoben_0x76 75.00
     2020-04-20 15:55:07   Puffertemperaturoben_0x76_value 75.00
     2020-04-20 15:49:08   Puffertemperaturunten_0x78 74.00
     2020-04-20 15:57:07   Puffertemperaturunten_0x78_value 73.50
     2020-04-20 15:49:10   RaumfühlerKBGTouch_0x191 19.00
     2020-04-20 15:57:09   RaumfühlerKBGTouch_0x191_value 19.00
     2020-04-20 15:49:06   Saugzug-Ansteuerung_0xf 0.00
     2020-04-20 15:57:05   Saugzug-Ansteuerung_0xf_value 0.00
     2020-04-20 15:49:05   Saugzugdrehzahl_0x7 0.00
     2020-04-20 15:57:05   Saugzugdrehzahl_0x7_value 0.00
     2020-04-20 15:49:04   Status          Feuer Aus
     2020-04-20 15:57:04   Status_value    Feuer Aus
     2020-04-20 15:49:09   StundenseitletzterWartung_0xd5 9825.00
     2020-04-20 15:57:08   StundenseitletzterWartung_0xd5_value 9825.00
     2020-04-20 15:49:09   TemperaturdesZweitkessel_0xc4 16.00
     2020-04-20 15:57:07   TemperaturdesZweitkessel_0xc4_value 16.00
     2020-04-20 15:49:05   Uhrzeit         Monday, 20. Apr. 2020 15:37:40
     2020-04-20 15:57:04   Uhrzeit_value   Monday, 20. Apr. 2020 15:45:40
     2020-04-20 15:49:10   VergangeneZeitseitletzterWärmetauscherreinigung_0x1c7 0.00
     2020-04-20 15:57:09   VergangeneZeitseitletzterWärmetauscherreinigung_0x1c7_value 0.00
     2020-04-20 15:49:06   Vorlauf-Isttemperatur_0x15 25.50
     2020-04-20 15:57:05   Vorlauf-Isttemperatur_0x15_value 25.00
     2020-04-20 15:49:07   Vorlauf-Isttemperatur_0x19 25.50
     2020-04-20 15:57:06   Vorlauf-Isttemperatur_0x19_value 25.00
     2020-04-20 15:49:07   Vorlauf-Solltemperatur_0x16 46.50
     2020-04-20 15:57:06   Vorlauf-Solltemperatur_0x16_value 46.50
     2020-04-20 15:49:07   Vorlauf-Solltemperatur_0x1a 46.50
     2020-04-20 15:57:06   Vorlauf-Solltemperatur_0x1a_value 46.50
     2020-04-20 15:49:06   Zykluszeit_0xe  53.60
     2020-04-20 15:57:05   Zykluszeit_0xe_value 53.90
Attributes:
   IODev      mqtt2server
   jsonMap    Puffertemperaturoben_0x76_value:Puffertemperatur_oben
Kesseltemperatur_0x0_value:Kesseltemperatur
   readingList p4d2mqtt/sensor/.* { return unless $TOPIC=~m,sensor/([^/]+)/,; json2nameValue($EVENT, "${1}_", $JSONMAP) }
   room       System->MQTT

Ich wuerde dein Vorschlag nehmen, _0x76 & co per $TOPIC=~m,sensor/([^/]+)_0x../, wegmachen, die 2-3 Umlaut-Faelle mit jsonMap lesbar machen, und mit _value leben.

wie gesagt, ich brauche nicht unbedingt die Umlaute.

Hmm, an das weg-regexen hatte ich auch schon gedacht, aber da ist das Problem, dass es mind. zwei gibt, die unterschiedliche HEX-Adressem zu repräsentieren scheinen. Wenn das doch dasselbe ist, macht es Sinn, das so wie vorgeschlagen zu erledigen...
Eines der beiden:

Code Auswählen Erweitern


     2020-04-20 12:47:36   BetriebsartHeizkreis_0x17 0.00
     2020-04-20 12:47:36   BetriebsartHeizkreis_0x1b 0.00

@hoppel: Da du den "Künstler" näher zu kennen scheinst: Evtl. wäre es eine Idee, das irgendwie auf der MQTT-Seite dahingehend zu verbessern, dass man wenigstens nur sprechende Namen hat oder die Möglichkeit, JSON (partiell?) abzuschalten und dann auf den jeweiligen Pfad einfach nur den Wert in Klartext bekommt.
Ist jedenfalls "ungewöhnlich", wie das hier gelöst ist...

Ich kenne den Entwickler nicht wirklich näher. Ich war in Kontakt mit dem Entwickler "horchi" von p4d. Der MQTT-Teil wurde aber anscheinend von jemandem aus dem Home Assistant Umfeld entwickelt. Der p4d Entwickler hat den MQTT-Teil dann meinem Verständnis nach in sein p4d Debian-Paket mit aufgenommen, um direkt diese Kompatibilität zu haben. Ganz sicher bin ich mir da aber auch nicht. Ich gebe das Feedback aber trotzdem gern weiter. Wenn das so unüblich ist, besteht wahrscheinlich Interesse das zu erfahren.

Danke euch auf jeden Fall für die Zeit, die Ihr heute investiert habt. Mal sehen, wie das autocreate Device morgen aussieht. Evtl. kann ich damit einfach so leben. Wie gesagt, das einzige, was ich benötige, ist die übliche Readingstruktur. Schönheit der Readingbezeichnungen ist nachrangig. Ich will ein Plot daraus generieren und da kann ich dann wieder eigene Namen pro Reading bzw. Messwert generieren.

Viele Grüße Hoppel

[hoppel118]

@Beta-User

habe dein Vorhaben nun verstanden. Habe gerade nochmal "homeassistant.* {return;}" im readingList ergänzt und schon wurden wurden die Readingnamen "Puffertemperaturoben_0x76_value" und "Kesseltemperatur_0x0_value" entsprechend jsonMap hübsch gemacht. Ich brauche das persönlich aber nicht so hübsch. Hier der Vollständigkeit halber nochmal das vollständige list dazu:

Code Auswählen Erweitern

Internals:
   CFGFN     
   CID        p4d_publisher
   DEF        p4d_publisher
   DEVICETOPIC EG_HZR_Heizung_Test
   FUUID      5e9daf49-f33f-5dcf-c898-48c426bede19ab95
   IODev      mqtt2server
   LASTInputDev mqtt2server
   MSGCNT     365
   NAME       EG_HZR_Heizung_Test
   NR         932
   STATE      ???
   TYPE       MQTT2_DEVICE
   mqtt2server_MSGCNT 365
   mqtt2server_TIME 2020-04-20 16:24:10
   JSONMAP:
     Kesseltemperatur_0x0_value Kesseltemperatur
     Puffertemperaturoben_0x76_value Puffertemperatur_oben
   READINGS:
     2020-04-20 16:24:05   Abgas-Solltemperatur_0x13_value 275.00
     2020-04-20 16:24:04   Abgastemperatur_0x1_value 65.00
     2020-04-20 16:24:05   Außentemperatur_0x4_value 14.00
     2020-04-20 16:24:09   BetriebsartBoiler_0x156_value 1.00
     2020-04-20 16:24:06   BetriebsartHeizkreis_0x17_value 0.00
     2020-04-20 16:24:06   BetriebsartHeizkreis_0x1b_value 0.00
     2020-04-20 16:24:04   Betriebsmodus_value Dauerlast
     2020-04-20 16:24:07   Betriebsstunden_0x62_value 9825.00
     2020-04-20 16:24:07   BetriebsstundeninderFeuererhaltung_0x73_value 27.00
     2020-04-20 16:24:08   BetriebsstundenvonKessel2Brennerkontakt_0x109_value 2426.00
     2020-04-20 16:24:04   Boardtemperatur_0x2_value 43.50
     2020-04-20 16:24:07   BoilerpumpeAnsteuerung_0x90_value 0.00
     2020-04-20 16:24:06   Boilertemperaturoben_0x5d_value 68.00
     2020-04-20 16:24:09   Build_0x16f_value 2.00
     2020-04-20 16:24:09   EmpfohleneHolzmengebeimNachlegen_0x10a_value 0.00
     2020-04-20 16:24:08   FühleramHydraulikmodul03_0xff_value 68.00
     2020-04-20 16:24:05   Kesselstellgröße_0x12_value 100.00
     2020-04-20 16:24:04   Kesseltemperatur 74.00
     2020-04-20 16:22:04   Kesseltemperatur_0x0_value 74.00
     2020-04-20 16:24:10   Kesselzustand_0x1c9_value 5.00
     2020-04-20 16:24:08   Lambdasondenspannunggemessen_0xd3_value 24.00
     2020-04-20 16:24:08   Lambdasondenspannungkorrigiert_0xdc_value 24.00
     2020-04-20 16:24:09   PufferladezustandDiskret_0x1c0_value 4.00
     2020-04-20 16:24:09   Pufferladezustand_0x1bf_value 95.00
     2020-04-20 16:24:08   Pufferladezustand_0xe1_value 95.00
     2020-04-20 16:24:07   PufferpumpenAnsteuerung_0x8c_value 0.00
     2020-04-20 16:24:08   PufferpumpenbegrenzungdurchAbgastemperatur_0xde_value 6.00
     2020-04-20 16:24:07   Puffertemperatur_oben 75.00
     2020-04-20 16:22:07   Puffertemperaturoben_0x76_value 75.00
     2020-04-20 16:24:07   Puffertemperaturunten_0x78_value 73.50
     2020-04-20 16:24:09   RaumfühlerKBGTouch_0x191_value 19.00
     2020-04-20 16:24:05   Saugzug-Ansteuerung_0xf_value 0.00
     2020-04-20 16:24:05   Saugzugdrehzahl_0x7_value 0.00
     2020-04-20 16:24:04   Status_value    Feuer Aus
     2020-04-20 16:24:08   StundenseitletzterWartung_0xd5_value 9825.00
     2020-04-20 16:24:07   TemperaturdesZweitkessel_0xc4_value 16.00
     2020-04-20 16:24:05   Uhrzeit_value   Monday, 20. Apr. 2020 16:12:39
     2020-04-20 16:24:09   VergangeneZeitseitletzterWärmetauscherreinigung_0x1c7_value 0.00
     2020-04-20 16:24:06   Vorlauf-Isttemperatur_0x15_value 23.50
     2020-04-20 16:24:06   Vorlauf-Isttemperatur_0x19_value 23.00
     2020-04-20 16:24:06   Vorlauf-Solltemperatur_0x16_value 46.00
     2020-04-20 16:24:06   Vorlauf-Solltemperatur_0x1a_value 46.00
     2020-04-20 16:24:05   Zykluszeit_0xe_value 54.20
Attributes:
   IODev      mqtt2server
   jsonMap    Puffertemperaturoben_0x76_value:Puffertemperatur_oben
Kesseltemperatur_0x0_value:Kesseltemperatur
   readingList p4d2mqtt/sensor/.* { return unless $TOPIC=~m,sensor/([^/]+)/,; json2nameValue($EVENT, "${1}_", $JSONMAP) }
homeassistant.* {return;}
   room       System->MQTT

[Beta-User]

Hmm, hat sich in Teilen überschnitten...

vielleicht kurz bzetr. die Rückmeldung an den Entwickler:

Wenn bestimmte hex-Adressen zu bestimmten (sub-) Geräten gehören, wäre es besser, diese Subgeräte dann jeweils unter einem Topic zusammenzufassen, dann kann man die wieder z.b. recht einfach einem MQTT2_DEVICE zuordnen; so kommt eben alles irgendwie völlig ungeordnet rein und es bleibt dem User überlassen, für Ordnung zu sorgen. Geht auch, ist aber unschön, und dadurch, dass hier JSON verwendet wird iVm. eigenen Topic-Zweigen ist es irgendwie doppelt gemoppelt (mMn., ich in aber auch kein "formaler Experte" und habe nur sowas wie einen gut abgehangenen Daumenblick für sowas)...

Was die "doppelten" Readings angeht, vermute ich, dass das alte und neue sind, wobei die alten dann nicht mehr aktualisiert werden. Die neueren sind die mit dem "value"-Suffix wie prognostiziert; die könnte man jetzt eben noch via jsomMap "verschönern".

Jedenfalls von meiner Seite wird morgen nix von alleine gehen. Wenn man da was machen will, muß man genau das tun, was der Entwickler auf der anderen Seite vermieden hat: rausfinden, was eigentlich zusammengehört und dann Baugruppen bilden...

Du solltest also entscheiden, ob du die HEX-Adressen drinhaben willst (=> eher Rudi's Vorschlag mit dem Hash hinten in json2NameValue()) oder nicht (dann $JSONMAP selbst entwickeln).
Beides aber erst, wenn das update morgen durch ist (bzw. du alles aus dem svn geholt hast), weil sonst die Namen nicht passen und wir wieder von vorne anfangen müßten...

EDIT: Du kannst das dann - zumindest in der oberen Zeile der rL (die andere drin lassen!) - morgen dann auf den Vorschlag von Rudi mit dem Hash hinbiegen. Würde nur empfehlen, alle Readings zu löschen, sonst kommst du mit neuen und alten durcheinander.

[hoppel118]

vielleicht kurz bzetr. die Rückmeldung an den Entwickler:

Wenn bestimmte hex-Adressen zu bestimmten (sub-) Geräten gehören, wäre es besser, diese Subgeräte dann jeweils unter einem Topic zusammenzufassen, dann kann man die wieder z.b. recht einfach einem MQTT2_DEVICE zuordnen; so kommt eben alles irgendwie völlig ungeordnet rein und es bleibt dem User überlassen, für Ordnung zu sorgen. Geht auch, ist aber unschön, und dadurch, dass hier JSON verwendet wird iVm. eigenen Topic-Zweigen ist es irgendwie doppelt gemoppelt (mMn., ich in aber auch kein "formaler Experte" und habe nur sowas wie einen gut abgehangenen Daumenblick für sowas)...

OK, danke dafür. Ich werde dem Entwickler den gesamten Thread mitteilen. Das ist ja noch nicht wirklich viel, was er hier durchlesen müsste. Er hat aber gestern schon gefragt, ob dass mit MQTT nun funktioniert. Es besteht also grundsätzlich Interesse an Feedback.

Was die "doppelten" Readings angeht, vermute ich, dass das alte und neue sind, wobei die alten dann nicht mehr aktualisiert werden. Die neueren sind die mit dem "value"-Suffix wie prognostiziert; die könnte man jetzt eben noch via jsomMap "verschönern".

Vollkommen richtig! Ich bin im großen und ganzen wirklich nur ein User. Ich habe dann auch irgendwann erkannt, dass sich die Readings ohne "_value" nicht mehr aktualisieren und habe, nachdem ich deinen Beitrag nochmal gelesen habe, dann ein neues Device erstellt.

Jedenfalls von meiner Seite wird morgen nix von alleine gehen. Wenn man da was machen will, muß man genau das tun, was der Entwickler auf der anderen Seite vermieden hat: rausfinden, was eigentlich zusammengehört und dann Baugruppen bilden...

In der Tat, kam mir das auf der anderen Seite auch schon etwas schwierig vor, zu ermitteln, was nun wohin- bzw. wie zusammengehört. Aber ich bin wirklich froh, dass p4d das alles leistet und liefern kann. Andernfalls hätte ich einfach gar nichts. Das Ergebnis, was ihr mir hier heute gebaut habt, ermöglicht mir eigentlich alles. Echt klasse! Kann nur immer wieder DANKE sagen!

Du solltest also entscheiden, ob du die HEX-Adressen drinhaben willst (=> eher Rudi's Vorschlag mit dem Hash hinten in json2NameValue()) oder nicht (dann $JSONMAP selbst entwickeln).
Beides aber erst, wenn das update morgen durch ist (bzw. du alles aus dem svn geholt hast), weil sonst die Namen nicht passen und wir wieder von vorne anfangen müßten...

EDIT: Du kannst das dann - zumindest in der oberen Zeile der rL (die andere drin lassen!) - morgen dann auf den Vorschlag von Rudi mit dem Hash hinbiegen. Würde nur empfehlen, alle Readings zu löschen, sonst kommst du mit neuen und alten durcheinander.

SVN kenne ich mich nicht mit aus. Ich schaue mir das morgen in Ruhe an und melde mich erneut. Welchen "Vorschlag mit dem Hash hinten" meinst du genau? Finde ich irgendwie nicht. Bin wohl gerade blind...

Gibt es einen Befehl, um alle Readings mit einem Mal zu löschen? Ich kenne nur deleteReading, um einzelne Radings zu löschen. Dann ist es für mich einfacher das Device einmal zu löschen und neu anzulegen.

Viele Grüße Hoppel

[Beta-User]

Mit "hash hinten" ist sowas gemeint:

Code Auswählen Erweitern

p4d2mqtt/sensor/.* { return unless $TOPIC=~m,sensor/([^/]+)/,; json2nameValue($EVENT, '', {value=>$1}) }
Deletereading kann man auch mit devspec für den Readingnamen nutzen:

Meine "liebste Form":

Code Auswählen Erweitern

deletereading -q DEVICE (?!associatedWith).*
=> ohne Rückmeldung alles außer "associatedWith".

Falls der Entwicker Interesse hat, kann er gerne auch mal die ebus-attrTemplate ansehen bzw. den Entwicklungsthread dazu. Ist wohl vom "Grundproblem" her ein ähnlicher Fall - ohne denn hätte ich wohl auch kaum die Aussage gewagt, dass das suboptimal ist.
Dann gibt es nochmal ein ähnliches Ding: ems-esp. Ist wieder ein anderes (Junkers&Co.-) Bus-System, das da via ESP8266 "MQTT sprechen gelernt hat".

Und du darfst es schon glauben: das kann man noch "runder" machen .

[hoppel118]

Ich wuerde dein Vorschlag nehmen, _0x76 & co per $TOPIC=~m,sensor/([^/]+)_0x../, wegmachen, die 2-3 Umlaut-Faelle mit jsonMap lesbar machen, und mit _value leben.

Moment mal, verstehe ich dich gerade richtig: Du willst die Hex-Angaben weg machen? Hm... Mit folgendem Device habe ich mich echt gerade angefreundet:

Code Auswählen Erweitern

Internals:
   CFGFN     
   CID        p4d_publisher
   DEF        p4d_publisher
   DEVICETOPIC EG_HZR_Heizung
   FUUID      5e9db2a9-f33f-5dcf-33b5-5a770d1c7f7b806f
   IODev      mqtt2server
   LASTInputDev mqtt2server
   MSGCNT     2630
   NAME       EG_HZR_Heizung
   NR         954
   STATE      Feuer Aus
   TYPE       MQTT2_DEVICE
   mqtt2server_MSGCNT 2630
   mqtt2server_TIME 2020-04-20 17:07:09
   READINGS:
     2020-04-20 17:07:05   Abgas-Solltemperatur_0x13 275.00
     2020-04-20 17:07:04   Abgastemperatur_0x1 64.00
     2020-04-20 17:07:05   Außentemperatur_0x4 14.50
     2020-04-20 17:07:08   BetriebsartBoiler_0x156 1.00
     2020-04-20 17:07:06   BetriebsartHeizkreis_0x17 0.00
     2020-04-20 17:07:06   BetriebsartHeizkreis_0x1b 0.00
     2020-04-20 17:07:04   Betriebsmodus   Dauerlast
     2020-04-20 17:07:06   Betriebsstunden_0x62 9825.00
     2020-04-20 17:07:07   BetriebsstundeninderFeuererhaltung_0x73 27.00
     2020-04-20 17:07:08   BetriebsstundenvonKessel2Brennerkontakt_0x109 2426.00
     2020-04-20 17:07:04   Boardtemperatur_0x2 43.00
     2020-04-20 17:07:07   BoilerpumpeAnsteuerung_0x90 0.00
     2020-04-20 17:07:06   Boilertemperaturoben_0x5d 68.00
     2020-04-20 17:07:09   Build_0x16f     2.00
     2020-04-20 17:07:08   EmpfohleneHolzmengebeimNachlegen_0x10a 1.00
     2020-04-20 17:07:08   FühleramHydraulikmodul03_0xff 68.00
     2020-04-20 17:07:05   Kesselstellgröße_0x12 100.00
     2020-04-20 17:07:04   Kesseltemperatur_0x0 72.50
     2020-04-20 17:07:09   Kesselzustand_0x1c9 5.00
     2020-04-20 17:07:08   Lambdasondenspannunggemessen_0xd3 24.07
     2020-04-20 17:07:08   Lambdasondenspannungkorrigiert_0xdc 24.07
     2020-04-20 17:07:09   PufferladezustandDiskret_0x1c0 4.00
     2020-04-20 17:07:09   Pufferladezustand_0x1bf 94.00
     2020-04-20 17:07:08   Pufferladezustand_0xe1 94.00
     2020-04-20 17:07:07   PufferpumpenAnsteuerung_0x8c 0.00
     2020-04-20 17:07:08   PufferpumpenbegrenzungdurchAbgastemperatur_0xde 6.00
     2020-04-20 17:07:07   Puffertemperaturoben_0x76 75.00
     2020-04-20 17:07:07   Puffertemperaturunten_0x78 72.50
     2020-04-20 17:07:09   RaumfühlerKBGTouch_0x191 19.00
     2020-04-20 17:07:05   Saugzug-Ansteuerung_0xf 0.00
     2020-04-20 17:07:05   Saugzugdrehzahl_0x7 0.00
     2020-04-20 17:07:04   Status          Feuer Aus
     2020-04-20 17:07:08   StundenseitletzterWartung_0xd5 9825.00
     2020-04-20 17:07:07   TemperaturdesZweitkessel_0xc4 15.50
     2020-04-20 17:07:04   Uhrzeit         Monday, 20. Apr. 2020 16:55:39
     2020-04-20 17:07:09   VergangeneZeitseitletzterWärmetauscherreinigung_0x1c7 0.00
     2020-04-20 17:07:05   Vorlauf-Isttemperatur_0x15 42.50
     2020-04-20 17:07:06   Vorlauf-Isttemperatur_0x19 37.50
     2020-04-20 17:07:06   Vorlauf-Solltemperatur_0x16 45.50
     2020-04-20 17:07:06   Vorlauf-Solltemperatur_0x1a 45.50
     2020-04-20 17:07:05   Zykluszeit_0xe  54.20
Attributes:
   IODev      mqtt2server
   alias      Holzscheitkessel
   event-min-interval .*:120
   event-on-change-reading .*
   icon       sani_boiler_temp
   readingList p4d2mqtt/sensor/.* { return unless $TOPIC=~m,sensor/([^/]+)/,; my %r=(value=>$1); json2nameValue($EVENT, '', \%r) }
homeassistant.* {return;}
   room       System->MQTT
   stateFormat Status

Wie funktioniert das denn, wenn man zwei Radings mit identischem Namen hätte?

Code Auswählen Erweitern


     2020-04-20 17:07:05   Vorlauf-Isttemperatur_0x15 42.50
     2020-04-20 17:07:06   Vorlauf-Isttemperatur_0x19 37.50

Ich denke, das ist in meinem Fall noch human. Wenn man mehrere Puffer hat, wird es noch verrückter. Von daher bin ich ja bei Beta-User, dass es Subgeräte geben müsste, die unter einem Topic zusammengefasst werden. Gibt es aber momentan noch nicht. Mal sehen, was der p4d Entwickler dazu sagt. Ist aber wahrscheinlich nichts, was von heute auf morgen passiert.

Und du darfst es schon glauben: das kann man noch "runder" machen .

Ich glaube das (bin auch überzeugt) und werde das auch gerne weitergeben. Aber es ist auch nicht so, dass ich dem Entwickler sehr nahe stehe. Bevor ich p4d installiert habe, hatte ich für die Hardware-Beschaffung ein paar Fragen und kam da mit dem Entwickler horchi in Kontakt. Mehr ist da momentan noch nicht.

Viele Grüße Hoppel

[hoppel118]

Mit "hash hinten" ist sowas gemeint:

Code Auswählen Erweitern

p4d2mqtt/sensor/.* { return unless $TOPIC=~m,sensor/([^/]+)/,; json2nameValue($EVENT, '', {value=>$1}) }
Deletereading kann man auch mit devspec für den Readingnamen nutzen:

Meine "liebste Form":

Code Auswählen Erweitern

deletereading -q DEVICE (?!associatedWith).*
=> ohne Rückmeldung alles außer "associatedWith".

OK, deine "liebste Form" funktioniert! Habe das Device mal auf Rudi's Vorschlag umgebaut. Damit kann ich erstmal gut leben.

Code Auswählen Erweitern

Internals:
   CFGFN     
   CID        p4d_publisher
   DEF        p4d_publisher
   DEVICETOPIC EG_HZR_Heizung
   FUUID      5e9db2a9-f33f-5dcf-33b5-5a770d1c7f7b806f
   IODev      mqtt2server
   LASTInputDev mqtt2server
   MSGCNT     3832
   NAME       EG_HZR_Heizung
   NR         954
   STATE      Feuer Aus
   TYPE       MQTT2_DEVICE
   mqtt2server_MSGCNT 3832
   mqtt2server_TIME 2020-04-20 17:22:16
   OLDREADINGS:
   READINGS:
     2020-04-20 17:22:09   Abgas-Solltemperatur_0x13 275.00
     2020-04-20 17:22:06   Abgastemperatur_0x1 64.00
     2020-04-20 17:22:06   Außentemperatur_0x4 14.50
     2020-04-20 17:22:15   BetriebsartBoiler_0x156 1.00
     2020-04-20 17:22:10   BetriebsartHeizkreis_0x17 0.00
     2020-04-20 17:22:10   BetriebsartHeizkreis_0x1b 0.00
     2020-04-20 17:22:06   Betriebsmodus   Dauerlast
     2020-04-20 17:22:10   Betriebsstunden_0x62 9825.00
     2020-04-20 17:22:10   BetriebsstundeninderFeuererhaltung_0x73 27.00
     2020-04-20 17:22:14   BetriebsstundenvonKessel2Brennerkontakt_0x109 2426.00
     2020-04-20 17:22:06   Boardtemperatur_0x2 43.00
     2020-04-20 17:22:11   BoilerpumpeAnsteuerung_0x90 0.00
     2020-04-20 17:22:10   Boilertemperaturoben_0x5d 68.00
     2020-04-20 17:22:15   Build_0x16f     2.00
     2020-04-20 17:22:15   EmpfohleneHolzmengebeimNachlegen_0x10a 4.00
     2020-04-20 17:22:14   FühleramHydraulikmodul03_0xff 68.00
     2020-04-20 17:22:09   Kesselstellgröße_0x12 100.00
     2020-04-20 17:22:05   Kesseltemperatur_0x0 72.50
     2020-04-20 17:22:16   Kesselzustand_0x1c9 5.00
     2020-04-20 17:22:11   Lambdasondenspannunggemessen_0xd3 24.07
     2020-04-20 17:22:14   Lambdasondenspannungkorrigiert_0xdc 24.07
     2020-04-20 17:22:15   PufferladezustandDiskret_0x1c0 3.00
     2020-04-20 17:22:15   Pufferladezustand_0x1bf 78.00
     2020-04-20 17:22:14   Pufferladezustand_0xe1 78.00
     2020-04-20 17:22:11   PufferpumpenAnsteuerung_0x8c 0.00
     2020-04-20 17:22:14   PufferpumpenbegrenzungdurchAbgastemperatur_0xde 6.00
     2020-04-20 17:22:11   Puffertemperaturoben_0x76 75.00
     2020-04-20 17:22:11   Puffertemperaturunten_0x78 57.50
     2020-04-20 17:22:15   RaumfühlerKBGTouch_0x191 19.00
     2020-04-20 17:22:09   Saugzug-Ansteuerung_0xf 0.00
     2020-04-20 17:22:06   Saugzugdrehzahl_0x7 0.00
     2020-04-20 17:22:06   Status          Feuer Aus
     2020-04-20 17:22:12   StundenseitletzterWartung_0xd5 9825.00
     2020-04-20 17:22:11   TemperaturdesZweitkessel_0xc4 15.50
     2020-04-20 17:22:06   Uhrzeit         Monday, 20. Apr. 2020 17:10:39
     2020-04-20 17:22:15   VergangeneZeitseitletzterWärmetauscherreinigung_0x1c7 0.00
     2020-04-20 17:22:09   Vorlauf-Isttemperatur_0x15 46.50
     2020-04-20 17:22:10   Vorlauf-Isttemperatur_0x19 46.50
     2020-04-20 17:22:09   Vorlauf-Solltemperatur_0x16 45.50
     2020-04-20 17:22:10   Vorlauf-Solltemperatur_0x1a 45.50
     2020-04-20 17:22:08   Zykluszeit_0xe  54.10
Attributes:
   IODev      mqtt2server
   alias      Holzscheitkessel
   event-min-interval .*:120
   event-on-change-reading .*
   icon       sani_boiler_temp
   readingList p4d2mqtt/sensor/.* { return unless $TOPIC=~m,sensor/([^/]+)/,; json2nameValue($EVENT, '', {value=>$1}) }
homeassistant.* {return;}
   room       System->MQTT
   stateFormat Status

Schönen Abend noch und Gruß Hoppel

[Beta-User]

Moment mal, verstehe ich dich gerade richtig: Du willst die Hex-Angaben weg machen? Hm... Mit folgendem Device habe ich mich echt gerade angefreundet:

Wie funktioniert das denn, wenn man zwei Radings mit identischem Namen hätte?

Code Auswählen Erweitern


     2020-04-20 17:07:05   Vorlauf-Isttemperatur_0x15 42.50
     2020-04-20 17:07:06   Vorlauf-Isttemperatur_0x19 37.50

Gar nicht, beides landet im identischen Reading.

Was man auf der FHEM-Seite machen kann: bestimmte Hex-Adressen in ein anderes Device umleiten. Das nennt sich dann bidgeRegexp, und wenn du in dem Bereich was "spezielles" sehen willst, schau mal in diese und die folgenden Zeilen:
https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/lib/AttrTemplate/mqtt2.template#L2273
bzw. ab hier:
https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/lib/AttrTemplate/mqtt2.template#L2302

Dann bekommst du in etwa eine Ahnung, welchen Aufwand man treiben muß, wenn die Dinge bereits vorsortiert sind. Sind sie hier aber nicht, (jedenfalls nicht per Topic-Struktur) dementsprechend hoch wäre der zusätzliche Aufwand ...

[rudolfkoenig]

Moment mal, verstehe ich dich gerade richtig: Du willst die Hex-Angaben weg machen? Hm...

Dann lass das _0x.. im Regexp weg.

Wie funktioniert das denn, wenn man zwei Radings mit identischem Namen hätte?

Der Letzte gewinnt (== ueberschreibt das Vorherige).

Code Auswählen Erweitern

Ich denke, das ist in meinem Fall noch human.
Ab morgen gibts auch noch Au__entemperatur_0x4 dazu

Wir koennen mit bridgeRegexp auch Subgeraete bauen, ist halt nervig, weil man entweder einen (Regexp-)Regel finden muss, oder alle Readings einzeln aufzaehlen darf.

Andererseits sollte alles in Relation bleiben: wegen einem Benutzer, der jetzt schon halbwegs zufrieden ist, muss man nicht die halbe Welt verrueckt machen.

[Beta-User]

Andererseits sollte alles in Relation bleiben: wegen einem Benutzer, der jetzt schon halbwegs zufrieden ist, muss man nicht die halbe Welt verrueckt machen.

Ist ja gut... .

Wenn der Entwickler sich meldet und wir das weiter optimiert bekommen, ist gut, wenn nicht: User ist auch so happy. Auch gut! (und das glücklich auch bei mir angekommen, falls das untergegangen sein sollte!). Geht auch nicht um die halbe Welt, aber wenn er noch einen Last will einbaut, wäre es auch nicht verkehrt, oder? Dürften schon noch ein paar mehr von den Kesseln im Umlauf sein .

@hoppel: Kennt das Ding eigentlich auch Werte, die man setzen kann oder ist das ein reines Info-Ding? (ich sehe nirgends subscriptions)

[rudolfkoenig]

@hoppel: Kennt das Ding eigentlich auch Werte, die man setzen kann oder ist das ein reines Info-Ding? (ich sehe nirgends subscriptions)

Wenn man ins verbose 5 FHEM-Log schaut, sieht man folgenden Muster:

SUBSCRIBE p4d2mqtt/sensor/Abgastemperatur_0x1/state
PUBLISH homeassistant/sensor/Abgastemperatur_0x1/config
UNSUBSCRIBE p4d2mqtt/sensor/Abgastemperatur_0x1/state
PUBLISH p4d2mqtt/sensor/Abgastemperatur_0x1/state

Das wiederholt sich so fuer alle 40+ Readings.
Wie moderne Kunst: man versteht es nicht auf Anhieb

[Beta-User]

Klingt nach kreativem Umgang mit neuartigen Materialien ...

[hoppel118]

Hi,

der Beitrag im Holzvergaser Forum ist hier: https://www.holzheizer-forum.de/index.php?thread/50090-announce-p4d-visualisierung-und-einstellung-der-s-3200-via-com1/&postID=171525#post171525

Mal sehen, wie horchi reagiert.

Gar nicht, beides landet im identischen Reading.

Hm... Das ist aber irgendwie schade. Wie gesagt, solange man nur ein p4d MQTT2_DEVICE hat, kann es massig Readings mit gleicher Bezeichnung geben. Ich kann hier wirklich bis zu 300 Readings verschiedener Subgeräte auswählen, die mir in der p4d Weboberfläche angezeigt werden und auch per MQTT übertragen werden können. So wie ich das bisher sehe, wären die Messwerte dann alle ohne weitere Gruppierung. Sehe zumindest keine Funktion mit der man das regeln könnte. Evtl. übersehe ich auch irgendwo etwas.

Dann lass das _0x.. im Regexp weg.

Wo werde ich das "_0x" morgen finden, am MQTT2_DEVICE unter readingList (sorry, falls das eine dumme Frage ist)?

Der Letzte gewinnt (== ueberschreibt das Vorherige).

Ich hätte die Hex-Angaben erstmal gelassen, bis die weitere Vorgehensweise mit horchi geklärt ist. Wenn er nicht will bzw. keine Zeit hat, dann können wir ja immer noch überlegen, wie es weiter geht.

Code Auswählen Erweitern

Ich denke, das ist in meinem Fall noch human.
Ab morgen gibts auch noch Au__entemperatur_0x4 dazu

Ich sollte wahrscheinlich wirklich erstmal abwarten, wie das morgen aussieht. Grundsätzlich sollte ich also horchi auch mitteilen, dass im Idealfall keine Umlaute per MQTT übertragen werden, sondern diese "konvertiert" werden? (ß=ss, ä=ae, ö=oe, ü=ue, Gibt es noch weitere?)

Wir koennen mit bridgeRegexp auch Subgeraete bauen, ist halt nervig, weil man entweder einen (Regexp-)Regel finden muss, oder alle Readings einzeln aufzaehlen darf.

Andererseits sollte alles in Relation bleiben: wegen einem Benutzer, der jetzt schon halbwegs zufrieden ist, muss man nicht die halbe Welt verrueckt machen.

Klingt kompliziert und mit letzterem hast du Recht. Aber ich bin definitiv nicht der einzige in diesem Forum mit einem Fröling Kessel und der benötigten S-3200 Steuerung. Bisher wurde das aber viel komplizierter an FHEM angebunden. Das lief jetzt für mich quasi durch die Weiterentwicklung von p4d inkl. MQTT und die Integration von MQTT2_SERVER in FHEM wirklich quasi "automatisiert", mal abgesehen davon, dass ihr beide da noch ran musstet. Der nächste hat's dann direkt leichter.

Wie moderne Kunst: man versteht es nicht auf Anhieb

In diesem Sinne, wünsche ich noch einen schönen Abend!

Viele Grüße Hoppel