Fröling: [ANNOUNCE] p4d - Visualisierung und Einstellung der S-3200 via COM1

Hier Rudi‘s Antwort:

Zitat von horchi

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.

Zitat von horchi

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.

Rudi hatte ja weiter oben geschrieben, wie man das in JSON verschachteln kann.

Umso länger ich darüber nachdenke, umso schöner fände ich es, wenn Einheit und Titel direkt mitübertragen werden würden. Rudi meinte ja, dass FHEM das parsen kann.

Kannst du das evtl. als Option verfügbar machen? Evtl. brauchen die Openhab User das dann wieder. Keine Ahnung, ob das sinnvoll ist...

Ich schaue nachher mal, dass ich das aktuellste Paket installiert bekomme.

Ich schreibe die ganze Zeit vom Handy...

Gruß Hoppel

Hallo @horchi,

habe gerade die 0.3.20 als Paket installiert. Das hat soweit geklappt. Währenddessen kam eine Meldung, dass die p4d.conf angepasst wurde. Ich verwende nun die neue p4d.conf. Im WebInterface sehe ich unter "Setup - Allg. Konfiguration - HomeMatic Interface" ein paar MQTT-Settings, siehe Screenshot.

Ich habe dort also die MQTT URL zu meinem FHEM MQTT Server ergänzt. Folgendes Ergebnis:

• Wenn ich unter "Config Topic" das Häkchen entferne, danach "Speichern" drücke, werden die "homeassistant Zweige" trotzdem übertragen. Habe nun schon mehrfach das RETAIN-Feld an meinem MQTT Server resettet und das p4d MQTT Device gelöscht. Die Einträge kommen immer wieder.
• Müsste ich den "MQTT Data Topic Name" nun von "p4d2mqtt/sensor/" zu "p4d2mqtt/" anpassen können? Wenn ich "sensor/" am Ende entferne, danach "Speichern" drücke, wird automatisch wieder "p4d2mqtt/sensor/" ergänzt. Oder was war dein Gedanke bei diesem Feld?
• Die p4d2mqtt Announcements enthalten nun einen Doppelslash hinter sensor "p4d_publisher:p4d2mqtt/sensor//", bei den homeassistant Announcements ist es weiterhin ein einfacher Slash:
  -> Ist der Doppelslash geplant? Ist das eine Vorbereitung für die "Baugruppen/Subgeräte"? (Den letzten Slash von "p4d2mqtt/sensor/" kann ich übrigens auch nicht entfernen. Nach "Speichern" kommt auch der automatisch wieder.

p4d_publisher:homeassistant/sensor/Kesseltemperatur_0x0/config:.* { json2nameValue($EVENT) }
p4d_publisher:p4d2mqtt/sensor//Kesseltemperatur_0x0/state:.* { json2nameValue($EVENT) }
p4d_publisher:homeassistant/sensor/Status/config:.* { json2nameValue($EVENT) }
p4d_publisher:p4d2mqtt/sensor//Status/state:.* { json2nameValue($EVENT) }
p4d_publisher:homeassistant/sensor/Abgastemperatur_0x1/config:.* { json2nameValue($EVENT) }
p4d_publisher:p4d2mqtt/sensor//Abgastemperatur_0x1/state:.* { json2nameValue($EVENT) }

• Die Umlaute in den Readings werden nun korrekt übersetzt (ae, oe, ue, ss). Das passt!

Brauchst du weitere Infos von mir? Wenn ja, welche?

Danke auf jeden Fall schonmal!

Gruß Hoppel

Habe jetzt auch ohne Zitat geantwortet, weil das sonst erst ein Admin wieder prüfen muss, wegen der wxternen Links...

Servus Hoppel, Jörg,

zu 1. 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"}}}

das würde aus meiner Sicht auch Punkt 5 erledigen. Würde das für FHEM auch passen, oder eher nicht?

zu 2. würde die Conif schon funktionieren, nur wäre es hier schöner, wenn die einzelnen Werte in einem JSON gesendet werden unter einem Topic. in Openhab kann man alle Paramter und Messwerte unter einer Gruppe (Thing) anlegen. wie unter 1. die Parameter. Nur dass da die Gruppe noc eine geschweifte-Klammer mehr wäre

zu 4 unbedingt. bitte keine Umlaute, Sonderzeichen oder so. das muss JOSN-konform sein z.B. keine "ÄÖÜß-."

zu 6. ok

zu 7. Hier ein Beispiel was erlauben würde dynamisch viele Fehlermeldungen zu senden:
p4d2mqtt/sensor/Stoermeldungen/state={{"Meldung 01":{"value"="E", "date"="2019-08-29", "time"="21:38:39" ,"key"="(00:00:00.000000)", "text"="Steuerung neu gestartet quittiert"},{"Meldung 02":{"value"="I", "date"="2019-08-29", "time"="21:38:39" ,"key"="(00:00:00.000000)", "text"="Aschebox voll, bitte entleeren
gekommen"},{"Meldung 03":{"value"="I", "date"="2019-08-29", "time"="21:38:39" ,"key"="(00:00:00.000000)", "text"="Aschebox voll, bitte entleeren quittiert"}, ......}

zu 8. meinte die Heizung zu parametrisieren? wäre nicht schlecht, aber aktuell keine prio für mich

Sorry für meine späte Anwort. war heute etwas beschäftigt. Sind die JSON-Statements verständlich?

VG

Roland

Zitat von horchi

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

Code

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.

vermutlich so?

Code

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"
   }
}

Alles anzeigen

und mit Gruppen:

Code

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" : ""
      }
   }
}

Alles anzeigen

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

Viele Grüße
Jörg

Alles anzeigen

Ja würde passen.ob Fhem oder Openhab, json kann jeder dekodieren. Von daher für Openhab .
Und sorry, da ist mir in der späten Stunde ein Schreibfehler unter laufen. Hatte den Fehler auf meinem Json-Parser übersehen.

Viele Grüße

Roland

Zitat von horchi

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

Code

{
   "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"
   }
}

Alles anzeigen

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.

Die Umlaute machen nur in den Topics, Gruppen Probleme. In der Beschreibung selbst passt das.
Perfekt!

Viele Grüße

Roland

Danke erstmal horchi. Ich habe die 0.3.21 installiert. Das klappt soweit alles! Ich kann den Pfad über das WebUI anpassen (sensor/ weglassen). die homeassistant Einträge werden nicht mehr übertragen. Ich warte noch auf Rückmeldung im FHEM Forum und melde mich dann wieder.

Gruß Hoppel

Hallo horchi,

hier nochmal Feedback von Beta-User aus dem FHEM Forum:

Zitat von 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 [Blockierte Grafik: https://forum.fhem.de/Smileys/default/wink.gif] .

und hier:

Zitat von Beta-User

Wenn "gute" Strukturen (&goodReadingNames) kommen, braucht man fast kein attrTemplate mehr [Blockierte Grafik: https://forum.fhem.de/Smileys/default/wink.gif] . 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 [Blockierte Grafik: https://forum.fhem.de/Smileys/default/wink.gif] .

Das sieht schonmal super aus. TOP, ich bin total begeistert! Was fehlt uns denn nun noch?

• Baugruppen/Subgeräte
• Fehlermeldungen per MQTT übertragen

Zitat von horchi

und mit Gruppen:

Code

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" : ""
      }
   }
}

Alles anzeigen

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

Für FHEM sollte das dem Feedback nach so passen. Hast du schon eine Idee, wo die Gruppenbezeichnungen herkommen?

Gruß Hoppel

Zitat von Reachy

zu 7. Hier ein Beispiel was erlauben würde dynamisch viele Fehlermeldungen zu senden:
p4d2mqtt/sensor/Stoermeldungen/state={{"Meldung 01":{"value"="E", "date"="2019-08-29", "time"="21:38:39" ,"key"="(00:00:00.000000)", "text"="Steuerung neu gestartet quittiert"},{"Meldung 02":{"value"="I", "date"="2019-08-29", "time"="21:38:39" ,"key"="(00:00:00.000000)", "text"="Aschebox voll, bitte entleeren
gekommen"},{"Meldung 03":{"value"="I", "date"="2019-08-29", "time"="21:38:39" ,"key"="(00:00:00.000000)", "text"="Aschebox voll, bitte entleeren quittiert"}, ......}

zu 8. meinte die Heizung zu parametrisieren? wäre nicht schlecht, aber aktuell keine prio für mich

zu 7. Ich habe dazu gerade nochmal im FHEM Forum nachgehakt, ob das so auch für FHEM passt.

zu 8. Das hat für mich auch erstmal gar keine Prio.

Gruß Hoppel

zu Punkt 7 und @Reachy's Vorschlag hat Beta-User folgendes geschrieben:

Zitat von Beta-User

Hmm, auch hier _glaube_ ich wieder, dass wir damit zwar irgendwie klarkommen, aber dass das nicht optimal ist:

Zum einen ist unklar, wie Fehlermeldungen ggf. wieder gelöscht werden (z.B. es sind nicht mehr 3 vorhanden, weil die Aschebox geleert wurde).

Und dann muß das irgenwie weiterverarbeitet werden, was schwieriger ist, wenn man nicht weiß, wo was zu finden ist.

Imo ist es besser, Fehlermeldungen (oder allgemeiner: Statusmeldungen) dahin abzusetzen, wo es thematisch dazupaßt:
Systemstarts nach "System", Aschebox-Zustände zu einer Baugruppe Aschebox (am besten gleich mit der Option, das Entleeren via MQTT zu quittieren?). Da dann mit "voll" bzw. "ok" (bzw. %-Werten, sofern möglich)... Evtl. macht es Sinn, den gesamten Fehlerspeicher informativ zu übertragen, aber sowas schaut man sich mMn. besser am Web-Interface an.

Alles anzeigen

Wie seht ihr das?

Hi, ich denke, dass die Meldungen wie im Webinterface angezeigt, auch Sinn machen per MQTT zu senden. Sicherlich zeigt das Webinterface das heute schon. Wenn man aber nur eine Oberfläche für die Homeautomation verwenden möchte, sind die Messwerte und Parameter nur die halbe Miete. Einen sinnvollen Datenaustausch, ja, das sehr wohl. Wenn die einzelnen Fehlerzeilen, wie ich das schon mal vorgeschlagen habe, gesendet werden, hat das empfangende System alles verfügbar wie im Webinterface und kann die Daten anzeigen oder drauf reagieren. Eine Gruppierung von Meldungen, wie das Beispiel mit der Aschebox, würde voraussetzen, dass wir alle Meldungen kennen. Ich tu das nicht. Darum würde mir die "einfache" Variante ausreichen. Kann ja auch optional sein, wenn das Datenaufkommen nicht jeder haben möchte.
Ansonsten Respekt und danke an die schnellen Aktivitäten, Diskussionen und Antworten.
gefällt mir hier.

Viele Grüße

Roland

Ich hatte dazu auch noch eine kleine Unterhaltung mit Beta-User:

hoppel118:

Zitat

Am WebInterface unter "Fehler - Fehlerspeicher" sieht das bei mir wie folgt aus, siehe Screenshot.

Ich denke nicht, dass man diese Fehlermeldungen irgendwie Baugruppen-spezifisch eingeordnet bekommt. Ich gebe es weiter...

Beta-User:

Zitat

Hmm, dann denke ich, dass es Sinn macht, nur bei _Hinzukommen_ einer Meldung _einen Wert_ zu senden, nämlich die neue Meldung. Darauf kann man dann reagieren, alles andere ist mMn. "kalter Kaffee von vorgestern"... (und informationstechnisch gut auf dem Web-Interface aufgehoben, wenn man es braucht/wissen will).

Jo, horchi, Beta-User und rudolfkoenig haben echt Gas gegeben! Vielen Dank nochmal!

Gruß Hoppel

Hi Hoppel,

vielleicht wäre ein Kompromiss, wenn man die Fehlermeldungen übers Datum einschränken kann, die einen interessieren ausserhalb des Webinterface.
Denn im Falle eines Neustarts von Fhem oder Openhab würd man keine bestehenden Fehler mehr sehen, weil die ja nur einmal geschickt werden, beim Auftreten. Mir wäre es echt wichtig, alle Meldungen einsehen zu können. Auch wenns vielleicht kalter Kaffee ist. Über eine Option Anzahl Tage könnte man ja einschränken oder ggf. deaktivieren mit Wert 0 oder vielleicht sogar -1 heisst nur bei Änderung/neue Meldungen.

Viele Grüsse

Roland

Wenn das so als Option umsetzbar ist, wäre das meiner Ansicht nach in Ordnung.

Gruß Hoppel

@Reachy Kann man einzelne oder auch alle Fehler im Fehlerspeicher eigentlich irgendwie über horchi‘s WebUI oder an der Touchoberfläche der Steuerung entfernen?

Wenn ja, wie würde das mit der MQTT-Übertragung funktionieren, wenn eine oder alle Fehlermeldungen weg sind?

Gruß Hoppel

Zitat von hoppel118

@Reachy Kann man einzelne oder auch alle Fehler im Fehlerspeicher eigentlich irgendwie über horchi‘s WebUI oder an der Touchoberfläche der Steuerung entfernen?

Wenn ja, wie würde das mit der MQTT-Übertragung funktionieren, wenn eine oder alle Fehlermeldungen weg sind?

Gruß Hoppel

hoppel,

meines Wissens werden die Fehler nur angezeigt. Ich sehe dort keine Buttons wo man das löschen könnte. Das müsste auch nicht unbedingt sein. Denn wenn ein Fehler da ist, sollte man das direkt an der Heizung prüfen.

zur 2. Frage. also wenn keine Fehler (mehr) da sind, werden leere Fehlermeldungen (20?) geschickt. Aktuell hab ich 20 drin. Ich gehe mal davon aus, dass das fix/beschränkt ist, oder wie viele hast du drinnen? Ist ja mit allen Paramtern und Messdaten auch so. Wenn Heizkreipumpe aus, dann "0". Bei den Fehlermeldungen wären die halt leer. Sprich in der HA sind dann auch keine Fehlermeldungen mehr da. Da kann jetzt das Argument kommen. man schickt keine leeren Daten. Allerdings würde es anders falsche Fehler anzeigen. Weil wenn man nur einmal eine leere Nachricht schicken würde, und falls das HA-System gerade nich verfügbar wäre. ausser man definiert die Meldungen als "retained", bleiben die Meldungen dort stehen. Aber ehrlich gesagt, würde ich bei den wenigen Daten, von denen wir hier sprechen, es bei updates alle 5 Minuten lassen. oder das Updateintervall einstellbar machen.. bin mir nicht sicher ob das schon geht im Webinterface. glaube nicht.

VG

Reachy