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

[hoppel118]

horchi hat noch mal eine Frage:

wenn man die Unit weglässt wie und wo wird dann entschieden welcher Wert welche Einheit hat?
Und verstehe ich das richtig, als Bezeichnung gibt es nur den ReadingName und dieser sollte keine Sonderzeichen, keine Leerzeichen und kein öäü enthalten?

Gruß Hoppel

[rudolfkoenig]

wenn man die Unit weglässt wie und wo wird dann entschieden welcher Wert welche Einheit hat?

Welcher Wert welche Einheit hat entscheidet immer der Sender.

Der Benutzer, der anhand der Daten Programme baut, wird vorher sich ueberzeugen, in welchen Einheiten die Daten gemeldet werden, entweder aus der Doku, oder bei Pruefen der Werte auf Plausibilitaet. FHEM ist nicht in Bereichen unterwegs, wo die Geraete Fahrenheit melden, aber die Benutzer Celsius gewohnt sind oder andersherum, und den Aufwand fuer die Umrechnerei wuerde ich mir sparen.

Und verstehe ich das richtig, als Bezeichnung gibt es nur den ReadingName und dieser sollte keine Sonderzeichen, keine Leerzeichen und kein öäü enthalten?

Ja. Ich persoenlich wuerde englische Begriffe verwenden, das erspart diese Diskussion, und ist international einfacher zu vermarkten.

[hoppel118]

Hallo Rudi,

danke erstmal für deine tatkräftige Unterstützung. Hier nochmal horchi's Rückmeldung dazu:

okay kann ich so machen, also alles weglassen.

Irgendwie nicht so schön die seitens der Heizung bereitgestellten Titel und Einheiten zu ignorieren und in der Hausautomatisierung wider einzutragen. Hört sich für mich umständlich an - soll mir aber egal sein da ich mit dem homeassistant diese Probleme nicht habe

Irgendwie bin ich bei horchi. Die Informationen sind alle da. Wir sagen: brauchen/wollen wir bei FHEM nicht... Ja, ich weiß, du hast geschrieben, dass man darüber monatelang diskutieren kann. Wir brechen das hier ab.

Gruß Hoppel

[rudolfkoenig]

Bevor ich in die falsche Ecke gesteckt werde:
- wir haben jetzt schon eine Loesung, _ich_ wuerde es nicht anfassen, da ein Umbau Arbeit auf beiden Seiten bedeutet, ohne nennenswerte Vorteile.
- ich habe auf die Frage geantwortet, wie eine aus _meiner Ansicht_  ideale Schnittstelle ausschauen sollte. "richtig" gibt es nicht, weil die Beurteilung, was wichtig, und was man braucht, subjektiv ist. Ich habe wenig Schnittstellen gesehen, die _meinem_ Ideal entsprechen, und ich kann sehr gut damit leben.

[Beta-User]

Es gibt viele Wege, aber wie gesagt, in meiner (auf Hörensagen beruhenden!) Wahrnehmung ins homeassistant ein Sonderfall beim Umgang mit MQTT und ich meine, irgendwo hier vor einigen Monaten gelesen zu haben, dass sich jemand gewundert hat, warum da (homeassistant) jedes MQTT-Gerät mit ca. 20MB Speicherverbrauch zu Buche schlägt... Vermute, das hat auch mit dieser "mittels MQTT übermittelten Konfiguration" zu tun...
Jedenfalls habe ich mehr wie 10 MQTT (Sub-)Devices, und von den ca. 500 MB RAM, die auf meinem Server derzeit genutzt werden, braucht FHEM weniger wie die Hälfte...

[hoppel118]

@Rudi: Ich stecke dich in keine Schublade. Außer es gibt eine Schublade für valide und rational denkende Menschen.

horchi hat nun schon einiges umgesetzt. Ein verbose 5 mit nacktem MQTT2_SERVER und ohne MQTT2_DEVICE ergibt folgendes beim Start von p4d:

https://pastebin.com/zKLyyBn8

Seht ihr hier noch Anpassungsbedarf (abgesehen von den Baugruppen/Subgeräten --> kommt vrsl. später)?

Was ich noch nicht verstehe, am MQTT2_Server sehe ich im RETAIN Reading weiterhin die "homeassistant Einträge", obwohl die ja gar nicht mehr gepublished werden. Ich kann das Reading löschen wie ich will. Die Einträge kommen immer wieder. Im verbose 5 sehe ich keine homeassistant Einträge mehr. Wie kriege ich die weg?

Ein list vom autocreated MQTT2_DEVICE sieht nun wie folgt aus:

Code Auswählen Erweitern

Internals:
   CFGFN     
   CID        p4d_publisher
   DEF        p4d_publisher
   DEVICETOPIC MQTT2_p4d_publisher
   FUUID      5ea54670-f33f-5dcf-e235-c55b7d8b985e5653
   IODev      mqtt2server
   LASTInputDev mqtt2server
   MSGCNT     360
   NAME       MQTT2_p4d_publisher
   NR         908
   STATE      ???
   TYPE       MQTT2_DEVICE
   mqtt2server_MSGCNT 360
   mqtt2server_TIME 2020-04-26 10:38:24
   READINGS:
     2020-04-26 10:38:24   value           3.00
Attributes:
   IODev      mqtt2server
   readingList p4d_publisher:p4d2mqtt/Kesseltemperatur_0x0/state:.* { json2nameValue($EVENT) }
p4d_publisher:p4d2mqtt/Status/state:.* { json2nameValue($EVENT) }
p4d_publisher:p4d2mqtt/Abgastemperatur_0x1/state:.* { json2nameValue($EVENT) }
p4d_publisher:p4d2mqtt/Betriebsmodus/state:.* { json2nameValue($EVENT) }
p4d_publisher:p4d2mqtt/Boardtemperatur_0x2/state:.* { json2nameValue($EVENT) }
p4d_publisher:p4d2mqtt/Uhrzeit/state:.* { json2nameValue($EVENT) }
p4d_publisher:p4d2mqtt/Aussentemperatur_0x4/state:.* { json2nameValue($EVENT) }
p4d_publisher:p4d2mqtt/Saugzugdrehzahl_0x7/state:.* { json2nameValue($EVENT) }
p4d_publisher:p4d2mqtt/Zykluszeit_0xe/state:.* { json2nameValue($EVENT) }
p4d_publisher:p4d2mqtt/Saugzug-Ansteuerung_0xf/state:.* { json2nameValue($EVENT) }
p4d_publisher:p4d2mqtt/Kesselstellgroesse_0x12/state:.* { json2nameValue($EVENT) }
p4d_publisher:p4d2mqtt/Abgas-Solltemperatur_0x13/state:.* { json2nameValue($EVENT) }
p4d_publisher:p4d2mqtt/Vorlauf-Isttemperatur_0x15/state:.* { json2nameValue($EVENT) }
p4d_publisher:p4d2mqtt/Vorlauf-Solltemperatur_0x16/state:.* { json2nameValue($EVENT) }
p4d_publisher:p4d2mqtt/BetriebsartHeizkreis_0x17/state:.* { json2nameValue($EVENT) }
p4d_publisher:p4d2mqtt/Vorlauf-Isttemperatur_0x19/state:.* { json2nameValue($EVENT) }
p4d_publisher:p4d2mqtt/Vorlauf-Solltemperatur_0x1a/state:.* { json2nameValue($EVENT) }
p4d_publisher:p4d2mqtt/BetriebsartHeizkreis_0x1b/state:.* { json2nameValue($EVENT) }
p4d_publisher:p4d2mqtt/Boilertemperaturoben_0x5d/state:.* { json2nameValue($EVENT) }
p4d_publisher:p4d2mqtt/Betriebsstunden_0x62/state:.* { json2nameValue($EVENT) }
p4d_publisher:p4d2mqtt/BetriebsstundeninderFeuererhaltung_0x73/state:.* { json2nameValue($EVENT) }
p4d_publisher:p4d2mqtt/Puffertemperaturoben_0x76/state:.* { json2nameValue($EVENT) }
p4d_publisher:p4d2mqtt/Puffertemperaturunten_0x78/state:.* { json2nameValue($EVENT) }
p4d_publisher:p4d2mqtt/PufferpumpenAnsteuerung_0x8c/state:.* { json2nameValue($EVENT) }
p4d_publisher:p4d2mqtt/BoilerpumpeAnsteuerung_0x90/state:.* { json2nameValue($EVENT) }
p4d_publisher:p4d2mqtt/TemperaturdesZweitkessel_0xc4/state:.* { json2nameValue($EVENT) }
p4d_publisher:p4d2mqtt/Lambdasondenspannunggemessen_0xd3/state:.* { json2nameValue($EVENT) }
p4d_publisher:p4d2mqtt/StundenseitletzterWartung_0xd5/state:.* { json2nameValue($EVENT) }
p4d_publisher:p4d2mqtt/Lambdasondenspannungkorrigiert_0xdc/state:.* { json2nameValue($EVENT) }
p4d_publisher:p4d2mqtt/PufferpumpenbegrenzungdurchAbgastemperatur_0xde/state:.* { json2nameValue($EVENT) }
p4d_publisher:p4d2mqtt/Pufferladezustand_0xe1/state:.* { json2nameValue($EVENT) }
p4d_publisher:p4d2mqtt/FuehleramHydraulikmodul03_0xff/state:.* { json2nameValue($EVENT) }
p4d_publisher:p4d2mqtt/BetriebsstundenvonKessel2Brennerkontakt_0x109/state:.* { json2nameValue($EVENT) }
p4d_publisher:p4d2mqtt/EmpfohleneHolzmengebeimNachlegen_0x10a/state:.* { json2nameValue($EVENT) }
p4d_publisher:p4d2mqtt/BetriebsartBoiler_0x156/state:.* { json2nameValue($EVENT) }
p4d_publisher:p4d2mqtt/Build_0x16f/state:.* { json2nameValue($EVENT) }
p4d_publisher:p4d2mqtt/RaumfuehlerKBGTouch_0x191/state:.* { json2nameValue($EVENT) }
p4d_publisher:p4d2mqtt/PufferladezustandDiskret_0x1c0/state:.* { json2nameValue($EVENT) }
p4d_publisher:p4d2mqtt/VergangeneZeitseitletzterWaermetauscherreinigung_0x1c7/state:.* { json2nameValue($EVENT) }
p4d_publisher:p4d2mqtt/Kesselzustand_0x1c9/state:.* { json2nameValue($EVENT) }
   room       MQTT2_DEVICE

Am MQTT2_SERVER gibt es kein ignoreRegexp mehr.

Könnt ihr uns nochmal Feedback zu folgenden Fragen von horchi geben:

Mittlerweile ist noch ein Openhab User am Start. Er schreibt zu Rudi's beiden Vorschlägen:

Rudi:

Wenn FHEM automatisch die Daten erkennen soll, gibt es zwei Wege:
1. Einzeln: im Topic ReadingName als letztes Element spezifizieren, und den dazugehörigen Wert direkt, ohne JSON im Message mitgeben.
2. Zusammengefasst: Daten als ein JSON-Message, in der Form { "ReadingName1":Wert1, "ReadingName2":Wert2 } übermitteln.
In beiden Fällen sollten nur Änderungen übermittelt werden, und das Topic sollte pro Gerät eindeutig sein. Die zweite Version ist Ressourcenschonender als die Alternative #1, bzw. das, was jetzt praktiziert wird.

Reachy:

ja bitte zusammen gefasst z.B.:
p4d2mqtt/sensor/Parameter={ {"Aussentemperatur":{"value"="16", "Einheit"="°C", "Beschreibung"="Aussentemperatur Haus", "was noch sinnmacht"="Wert dazu"}}, {"Betriebsmodus":{"value"="Heizen","Einheit"="", "Beschreibung"="Aussentemperatur Haus", "was noch sinn macht"="Wert dazu"}}}

horchi:

das ist m.E. kein Json, jason_pp sieht das auch so:

Code Auswählen Erweitern

root@gate> echo '{ {"Aussentemperatur":{"value"="16", "Einheit"="°C", "Beschreibung"="Aussentemperatur Haus", "was noch sinnmacht"="Wert dazu"}}, {"Betriebsmodus":{"value"="Heizen","Einheit"="", "Beschreibung"="Aussentemperatur Haus", "was noch sinn macht"="Wert dazu"}}}' | json_pp
unexpected end of string while parsing JSON string, at character offset 3 (before ""Aussentemperatur":{...") at /usr/bin/json_pp line 45.

horchi:

vermutlich so?

Code Auswählen Erweitern

root@gate>echo '{"Aussentemperatur": { "value":"16", "Einheit":"°C", "Beschreibung":"Aussentemperatur Haus", "was_noch_sinnmacht":"Wert dazu"}, "Betriebsmodus": {"value":"Heizen","Einheit":"", "Beschreibung":"Aussentemperatur Haus", "was noch sinn macht":"Wert dazu"}}' | json_pp
{
   "Betriebsmodus" : {
      "value" : "Heizen",
      "was noch sinn macht" : "Wert dazu",
      "Einheit" : "",
      "Beschreibung" : "Aussentemperatur Haus"
   },
   "Aussentemperatur" : {
      "Einheit" : "°C",
      "Beschreibung" : "Aussentemperatur Haus",
      "was_noch_sinnmacht" : "Wert dazu",
      "value" : "16"
   }
}

horchi:

und mit Gruppen:

Code Auswählen Erweitern

root@gate> echo '{   "Gruppe 1" : {      "Betriebsmodus" : {         "value" : "Heizen",         "was noch sinn macht" : "Wert dazu",         "Einheit" : "",         "Beschreibung" : "Aussentemperatur Haus"      },      "Aussentemperatur" : {         "Einheit" : "°C",         "Beschreibung" : "Aussentemperatur Haus",         "was_noch_sinnmacht" : "Wert dazu",         "value" : "16"      }   },   "Gruppe 2" : {      "Bar" : {         "value" : "foo",         "was noch sinn macht" : "Wert dazu",         "Einheit" : "",         "Beschreibung" : "Aussentemperatur Haus"      },      "test" : {         "Einheit" : "°C",         "Beschreibung" : "Aussentemperatur Haus",         "was_noch_sinnmacht" : "Wert dazu",         "value" : "16"      }   }}' | json_pp
{
   "Gruppe 2" : {
      "test" : {
         "Beschreibung" : "Aussentemperatur Haus",
         "Einheit" : "°C",
         "was_noch_sinnmacht" : "Wert dazu",
         "value" : "16"
      },
      "Bar" : {
         "was noch sinn macht" : "Wert dazu",
         "value" : "foo",
         "Einheit" : "",
         "Beschreibung" : "Aussentemperatur Haus"
      }
   },
   "Gruppe 1" : {
      "Aussentemperatur" : {
         "value" : "16",
         "was_noch_sinnmacht" : "Wert dazu",
         "Einheit" : "°C",
         "Beschreibung" : "Aussentemperatur Haus"
      },
      "Betriebsmodus" : {
         "value" : "Heizen",
         "was noch sinn macht" : "Wert dazu",
         "Beschreibung" : "Aussentemperatur Haus",
         "Einheit" : ""
      }
   }
}

horchi:

wäre das so für alle Beteiligten okay, wir sprechen ja von FHEM und Openhab?

Danke und Gruß Hoppel


Danke euch und Gruß Hoppel

[TomLee]

Was ich noch nicht verstehe, am MQTT2_Server sehe ich im RETAIN Reading weiterhin die "homeassistant Einträge", obwohl die ja gar nicht mehr gepublished werden. Ich kann das Reading löschen wie ich will. Die Einträge kommen immer wieder. Im verbose 5 sehe ich keine homeassistant Einträge mehr. Wie kriege ich die weg?

Ich meine du bist an diesem Punkt:

Zum absichtlichen Löschen einer retained Message, etwa weil man weiß, dass dieses Topic zukünftig nicht mehr benötigt wird, kann man eine leere Message posten.

Hier ein Beispiel

Gruß

Thomas

[hoppel118]

horchi:

Hier ein Komplettes Beispiel ohne Baugruppen, die Elementbezeichner habe ich jetzt in englisch:

Code Auswählen Erweitern

{
   "Aussentemperatur_0x4" : {
      "unit" : "°",
      "value" : "22.50",
      "description" : "Außentemperatur"
   },
   "Kesseltemperatur_0x0" : {
      "description" : "Kessel",
      "value" : "62.00",
      "unit" : "°"
   },
   "28-000005679341" : {
      "value" : "58.19",
      "unit" : "°",
      "description" : "Puffer Mitte"
   },
   "Vorlauf-Isttemperatur_0x15" : {
      "value" : "31.00",
      "unit" : "°",
      "description" : "Vorlauf Heizung"
   },
   "RuecklauftemperaturanderZirkulationsLeitung_0xca" : {
      "description" : "Rücklauftemperatur Zirkulation",
      "unit" : "°",
      "value" : "48.50"
   },
   "Kesselstellgroesse_0x12" : {
      "value" : "99.00",
      "unit" : "%",
      "description" : "Kesselstellgröße"
   },
   "FuellstandimPelletsbehaelter_0x71" : {
      "description" : "Füllstand im Pelletsbehälter",
      "unit" : "%",
      "value" : "74.12"
   },
   "PufferpumpenAnsteuerung_0x8c" : {
      "description" : "Pufferpumpen Ansteuerung",
      "unit" : "%",
      "value" : "0.00"
   },
   "Status" : {
      "value" : "Betriebsbereit",
      "unit" : "Status",
      "description" : "zst"
   },
   "DrehzahlderZirkulationsPumpe_0xc9" : {
      "description" : "Drehzahl der Zirkulations Pumpe",
      "value" : "0.00",
      "unit" : "%"
   },
   "Stokerantrieb_0x5" : {
      "description" : "Stokerantrieb",
      "value" : "0.00",
      "unit" : "%"
   },
   "Betriebsmodus" : {
      "description" : "Betriebsmodus",
      "value" : "Übergangsbetrieb",
      "unit" : "zst"
   },
   "Puffertemperaturoben_0x76" : {
      "unit" : "°",
      "value" : "61.50",
      "description" : "Puffer Oben"
   },
   "FuehlerinderSTBHuelse_0x8" : {
      "description" : "Fühler in der STB Hülse",
      "value" : "66.50",
      "unit" : "°"
   },
   "KesselanforderungueberHeizkreisoderBoilerstehtan_0xd6" : {
      "description" : "Kesselanforderung über Heizkreis oder Boiler steht an",
      "value" : "0.00",
      "unit" : ""
   },
   "Vorlauf-Isttemperatur_0x19" : {
      "value" : "25.00",
      "unit" : "°",
      "description" : "Vorlauf Fußboden"
   },
   "Puffertemperaturunten_0x78" : {
      "description" : "Puffer Unten",
      "value" : "58.50",
      "unit" : "°"
   },
   "TemperaturdesZuendrohres_0xd" : {
      "description" : "Temperatur des Zündrohres",
      "value" : "41.00",
      "unit" : "°"
   },
   "Saugzugdrehzahl_0x7" : {
      "description" : "Saugzugdrehzahl",
      "unit" : "U",
      "value" : "0.00"
   },
   "DrehzahlderPumpe_0xc8" : {
      "description" : "Drehzahl der Pumpe",
      "unit" : "%",
      "value" : "0.00"
   },
   "Heizkreispumpe_0x1" : {
      "value" : "0.00",
      "unit" : "",
      "description" : "Bodenheizung"
   },
   "BetriebsstundenStokerschnecke_0xad" : {
      "description" : "Betriebsstunden Stokerschnecke",
      "value" : "10619.00",
      "unit" : "h"
   },
   "Boardtemperatur_0x2" : {
      "description" : "Boardtemperatur",
      "value" : "39.00",
      "unit" : "°"
   },
   "Abgastemperatur_0x1" : {
      "description" : "Abgas",
      "value" : "83.00",
      "unit" : "°"
   },
   "Heizkreispumpe_0x0" : {
      "unit" : "",
      "value" : "0.00",
      "description" : "Heizkreis 1"
   },
   "Betriebsstunden_0x62" : {
      "description" : "Betriebsstunden",
      "value" : "14903.00",
      "unit" : "h"
   },
   "Uhrzeit" : {
      "value" : "Sunday, 26. Apr. 2020 09:46:39",
      "unit" : "T",
      "description" : "Datum Uhrzeit der Heizung"
   }
}

horchi:

in description habe ich die Umlaute beibehalten - so wie ich es verstehe sind diese in JSON erlaubt. bin mir noch nicht 100% sicher ob ein Encoding ähnlich dem bei XML nötig sein könnte. da der Json Parser 'json_pp' an der Kommandozeile dies aber klaglos verarbeitet denke ich das passt so.

Passt das so?

[Beta-User]

Mein "Senf":
Man sollte das Senden von immergleichen Infos konfigurierbar (=abschaltbar) machen. Es macht m.E. keinen Sinn, ständig zu übermitteln, wie der Sensor heißt und was die Einheit ist...
Aber das sind "Feinheiten am Rande"...

Ansonsten bin ich froh, dass sich meine Aussage zu bestätigen scheint, dass homeassistant da "speziell" ist.

In FHEM bekommen wir das auf jeden Fall irgendwie hin, auch wenn "goodReadingName" wohl auch keine Umlaute mögen wird, wenn das via JSON kommt... Das ist dann aber wirklich ein spezielles FHEM-Thema, auf das horchi definitiv keine Rücksicht zu nehmen braucht .

[hoppel118]

@Beta-User

Verstehe ich deine Nachricht richtig, dass das bis auf den Einwand und Vorschlag zum "Senden immer gleicher Informationen" so grundsätzlich erstmal passt?

Ich gebe dein Feedback dann gern weiter.

Gruß Hoppel

[Beta-User]

Nochmal zum Verständnis: Ich habe einige Erfahrung und ein meist valides Bauchgefühl u.a. zu den Dingen, die mit MQTT zusammenhängen. Was ich und Rudi bisher angemerkt hatten, lief eigentlich immer darauf hinaus klarzumachen, dass wir von der FHEM-Seite her mit fast allem klarkommen .

Wie die Dinge am Ende codiert/verschachtelt/verpackt werden, ist eigentlich zweitrangig. Kommen die Daten in einem "Multi-JSON", ist das dahingehend hilfreich, als nur ein "Multi-" Event ausgelöst wird (readingsBulkUpdate); das beschleunigt uU. die weitere Verarbeitung... Aber auch das ist nur eine "Feinheit am Rande".

[hoppel118]

Klar kommt FHEM mit fast allem klar. Aber im Laufe des Threads gab es ja schon einiges an Feedback von euch, was man besser machen könnte, sogar mit ganz konkreten Vorschlägen, insbesondere diese beiden Posts von euch:

https://forum.fhem.de/index.php/topic,110401.msg1045437.html#msg1045437
https://forum.fhem.de/index.php/topic,110401.msg1045439.html#msg1045439

Diese Vorschläge habe ich so weiter gegeben und diese wurden jetzt auch größtenteils von horchi umgesetzt. Das einzige was noch fehlt, ist das Thema mit den Baugruppen/Subgeräten. Am Ende soll das Ganze performant sein und nur wenig Wünsche für andere FHEM User offen lassen. horchi war schneller als erwartet und ihr habt mitgemacht.

@Beta-User Würde denn dann noch irgendwas fehlen, um daraus ein Template für alle p4d User bauen zu können? (Damit sollten wir aber noch warten, bis das mit den Baugruppen geklärt ist.

Gruß Hoppel

[hoppel118]

Ich meine du bist an diesem Punkt:
Hier ein Beispiel

Moin Thomas,

danke für den Hinweis. Einzelne Retain-Nachrichten kann ich über diesen Weg löschen. Durch die ganzen Spielereien und den homeassistant Kram habe ich jetzt aber hunderte solcher retain Nachrichten. Kann ich retain auch irgendwie vollständig zurücksetzen? Wenn nicht, lösche ich kurz das Device "MQTT2_SERVER".

EDIT: Ich habe nun den kurz den MQTT2_SERVER gelöscht und neu definiert. Danach werden sofort die relevanten Nachrichten eingelesen und der ganze Müll ist weg. Wäre trotzdem noch interessant zu verstehen, ob es dafür eine elegantere Möglichkeit gibt.

Gruß Hoppel

[Beta-User]

Wenn "gute" Strukturen (&goodReadingNames) kommen, braucht man fast kein attrTemplate mehr . Damit kann man es dann nur ggf. aber noch "verschönern" (im FHEM-Sinn).
Ansonsten würde ich dann für attrTemplate-Herstellung mal wieder ein RAW-list brauchen, dann können wir noch diskutieren, was wir wie benennen (jsonMap) und was in state soll, that's all... (oder du versuchst dich dran, ist nicht so schwer!).

Ach so: Danke auch für die Kommunikation in Richtung horchi und an horchi selbst! Auch wenn sich manches evtl. von meiner Seite "hart" oder kritisch angehört haben sollte: das war nicht böse gemeint und ich finde es sehr cool, was bis hierhin schon rausgekommen ist - auch für Nutzer anderer HA-Lösungen .

[hoppel118]

OK, das hört sich schon besser an! Deine letzte Nachricht hat mich gerade etwas verwirrt...

Das positive Feedback gebe ich natürlich auch gern weiter!

Das attrTemplate machen wir (ich kann ja mal alleine starten), wenn das mit den Baugruppen/Subgeräten läuft.

Gruß Hoppel