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

Zitat von horchi

okay kann och 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

Verion 0.3.21 läuft! vielen Dank!

Die Einheiten und Beschreibungen würden in den Configs schon Sinn machen. Denn das veranlasst ja das HA-System das anzulegen. Aber wie schon gesagt, für Openab wäre die Zusammenfassung der Werte in eine Gruppe in eine Nachricht vom Datenmodell passender, als alle einzeln zu schicken. Dann wärs mit den Beschreibungen und Einheiten genial.

VG

Reachy

Bei mir sind es gerade 16 Meldungen, siehe Screenshot.

Ich freue mich auf die nächste Version zum Testen.

Danke horchi, dass du dir die Zeit nimmst, obwohl du doch eigentlich deinen Pool bauen wolltest.

Viele Grüße Hoppel

Zitat von horchi

euren Posts nach passt das vorgeschlagene JSON Format so, dann würde ich das so umsetzen.
Noch eine Frage dazu, der FHEM Vorschlag das Einheiten und Beschreibung nur initial gesendet werden passt auch für Openhab?

Die Baugruppen und Fehlermeldungen kommen dann im nächsten Schritt.

Ja, JSON passt
Und Einheiten und Beschreibungen nur initial, würde auch passen.

Viele Grüsse

Reachy

Ich habe das im FHEM Forum hinterfragt. Melde mich, wenn ich da eine Antwort erhalten habe.

Gruß Hoppel

Zitat von horchi

verstehe ich das richtig, ihr möchtet die Fehlermeldungen auf einem separaten Topic und nicht auf dem selben wie die Daten/Temperaturen/etc. ?
und dann so:

Code

{
   "message1" : {
      "time" : "2019-08-29T21:38:39",
      "message" : "Aschebox voll, bitte entleeren",
      "state" : "gegangen",
   },
   "message2" : {
      "time" : "2019-08-29T21:38:39",
      "state" : "gekommen",
      "message" : "Raumaustragung kontrollieren",
   },
   "message3" : {
      "time" : "2019-08-29T21:38:39",
      "message" : "Steuerung neu gestartet",
      "state" :  "quittiert",
   }
}

Alles anzeigen

oder als Array:

Code

{
   "messages" : [
      {
         "state" : "gegangen",
         "message" : "Aschebox voll, bitte entleeren",
         "time" : "2019-08-29T21:38:39"
      },
      {
         "state" : "gekommen",
         "time" : "2019-08-29T21:38:39",
         "message" : "Raumaustragung kontrollieren"
      },
      {
         "state" : "quittiert"
         "message" : "Steuerung neu gestartet",
         "time" : "2019-08-29T21:38:39",
      }
   ]
}

Alles anzeigen

/Edit

jeweils mit Key zum zuordnen, in Variante 1 wäre der Bezeichner (message1) der Key in Variante zwei würde ich "key":"0123" mitgeben

Muss nicht unbedingt ein separates Topic sein. War nur ein erster Vorschlag. Kann genauso mit den Messwerten zusammen gesendet werden, aber ich denke das Array wäre aus meiner Sicht i.O.!

So, die beiden üblichen Verdächtigen haben bereits geantwortet:

Zitat von rudolfkoenig

Es geht darum, dass ein Fehler nicht immer wieder gemeldet wird, sondern nur, wenn es auftaucht, einmal.
Sonst ist es aufwendiger etwas zu basteln, um darauf zu reagieren.

Aus Komplettsicht ist es sinnvoller sowas in FHEM zu filtern, wenn ich mich nicht irre, sollte das mit event-on-change-reading moeglich sein.

Zitat von Beta-User

Hmm, also json2nameValue() macht m.E. auch aus dem Array nichts wesentlich anderes als in der ersten Variante dargestellt.

Solange es sowieso "alles" über einen Topic kommt und nicht baugruppenweise irgendwie unter verschiedenen Topic-Pfaden vorsortiert, ist es m.E. auch egal, ob diese Messages auch noch über diesen Pfad kommen.

Das "Grundproblem" ist m.E. ein anderes: Nach meinem Verständnis ist MQTT ein Protokoll, das mal dafür gemacht war, Zustände ausfallsicher zu übermitteln. Es gibt daher zu jedem Informationspunkt in meiner Gedankenwelt optimalerweise genau eine Information, die in der Auswahl recht beschränkt ist, und irgendwelche Elemente nach dem Muster "0/1/on/off/missing/offline/failure..." haben sollte. Mit JSON weicht man das Prinzip etwas auf, was auch noch solange ok ist, als die Datenpunkte und Werte irgendwie zuordenbar bleiben.

Dinge wie Grafiken (valetudo) oder Konfigurationen (homeassistant-discovery-Meldungen) zu übertragen, sind für mich "abuse", das ist nicht "schlank und schnell" (=MQTT-like=maschinenlesbar), sondern "fett" (Webpage-like=menschenlesbar).

Von diesem "gefählten MQTT-Prinzip" weicht hier aber insbesondere diese "message"-Geschichte sehr massiv ab, weil es keine wirkliche Koppelung zwischen irgendeiner Message und einem konkreten Datenpunkt (für solche Geräte die diesen Kessel eigentlich: einen konkreten Bezugspunkt in der Hardware) gibt. Es ist irgendwelche Info, die im Prinzip willkürlich zu Informationszwecken übertragen wird... Ich sehe nach wie vor nicht den Mehrwert, warum das in der Form überhaupt gemacht wird.

Vielleicht kurz zum Hintergrund: Mein "gedanklicher Prototyp" für den Einsatz von MQTT ist eine Ölpipeline. Für sowas wurde das afaik mal entwickelt:
Hardwareüberwachung unter Extrembedingungen. Lange Stecken, ständig zu befürchtende Verbindungsabbrüche, widrige externe Umstände wie Hitze/Staub/Kälte/Wasser. Also: Wenig Info, eigentliche Auswertung der Info erfolgt "hinter dem Broker".

Ich hoffe, das ist nachvollziehbar und hilft ggf. auch beim Design (imo) "guter" MQTT-Implementierungen?

Alles anzeigen

Ich hoffe, dass dir das bei deinen Entscheidungen hilft.

Gruß Hoppel

Hallo Zusammen,

also ich finde die Darstellung Von Beta-User aus technischer Sicht durch aus richtig, aber nur einseitig betrachtet.
Würde bedeuten man soll entweder

• in ein anderes System schaun um die Fehler zu sehen
• oder eine andere Technik verwenden.

Punkt 2 finde ich zu aufwendig eine 2. Übertragungstechnik auf zu setzen, nur weil es keine direkten Datenpunkte gibt. Wobei für mich Fehlermeldungen 1 - n auch Datenpunkte darstellen, allerdings nicht zu einer Hardware. Ist aber bei "Uhrzeit" aus meiner Sicht auch so. Aber da kann man ewig hin und her diskutieren, wenn die Meinungen so unterschiedlich sind.

Ich will das Thema nicht überstrapazieren. Wenns nicht sein soll dann ist es so. Ich fände es aber schade, weil die Umsetzung technisch gesehen einfach wäre.

Viele Grüße

Reachy

Beta-User und Rudi haben mehrfach in meinem Thread im FHEM Forum betont, dass FHEM die Daten auf jeden Fall ausgewertet bekommt. Die beiden betrachten es aus der Sicht der optimalen/Idealen Schnittstelle. Rudi hatte das fast wortwörtlich so geschrieben:

Zitat

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.

Wir äußern hier lediglich Wünsche und bringen verschiedene Meinungen, Sichtweisen und Fakten ein, die @horchi beim Design unterstützen. Wenn du es unbedingt brauchst, wird niemand horchi verbieten, das zu implementieren. Das muss noch nicht mal groß diskutiert werden.

Ich für meinen Teil bin froh, dass Beta-User und Rudi sich in diese Thematik so einbringen. Ich habe bisher keine Ahnung von MQTT. Die S3200 ist mein erstes MQTT-Device. Die beiden haben keinen Fröling Kessel, aber Rudi ist wie schon erwähnt der FHEM Erfinder und Beta-User gehört auch zum FHEM Urgestein. Beide sind, so wie ich das im FHEM Forum sehe, sehr stark im MQTT Thema unterwegs. Rudi hat in FHEM einen eigenen MQTT-Server integriert und Beta-User erstellt unter anderem MQTT-Templates für alle möglichen Devices. So dann hoffentlich auch bald eins für p4d. Worauf ich hinaus will..., die beiden wissen schon wovon sie reden.

@horchi Es wäre schön, wenn du das als Option verfügbar machen könntest. Dann kann am Ende jeder selbst entscheiden, ob man das benötigt oder nicht. Deine Meinung zu der Thematik wäre mal interessant.

@Reachy Passt das so für dich?

Gruß Hoppel

Hi Hoppel,

Bitte nicht falsch verstehen. War lediglich meine Meinung dazu ohne jemand zu nahe treten zu wollen. Ich bin ja froh dass das Thema überhaupt verfolgt wird. Ich wollte eigentlich damit sage, das ich keine Lösung für mich alleine möchte, sondern das für "alle" passen sollte. Und eine Umsetzung von Anforderungen in Software ist immer auf eine klare Darlegung der Fakten angewiesen. Wobei die Umsetzung oft unterschiedlich angegangen wird. Und würde ein Jörg zum Schluss kommen, er möchte das so nicht umsetzen, wärs schade aber ok. Ist sein Baby.

zu deiner Frage. Für mich würds passen, wie Jörg es beschrieben hat. Die Array-Variante sehe ich als die bessere Variante.

Viele Grüsse

Reachy

Zitat von Reachy

Bitte nicht falsch verstehen. War lediglich meine Meinung dazu ohne jemand zu nahe treten zu wollen.

Alles gut!

Zitat von Reachy

Ich bin ja froh dass das Thema überhaupt verfolgt wird.

Das geht mir genauso. Ich habe p4d vor knapp 2 Wochen installiert und gleich „1000“ Wünsche/Anforderungen/Anpassungsbedarfe. Auch nicht so die feine Art...

Zitat von Reachy

Ich wollte eigentlich damit sage, das ich keine Lösung für mich alleine möchte, sondern das für "alle" passen sollte. Und eine Umsetzung von Anforderungen in Software ist immer auf eine klare Darlegung der Fakten angewiesen. Wobei die Umsetzung oft unterschiedlich angegangen wird. Und würde ein Jörg zum Schluss kommen, er möchte das so nicht umsetzen, wärs schade aber ok. Ist sein Baby.

Sehe ich genauso. Selbst wenn es jetzt nicht ganz perfekt ist, weil es vom Protokoll her so nicht vorgesehen ist, ist es besser, als auf die Statusmeldungen zu verzichten. Vielleicht kommt auch irgendwann mal jemand anderes um die Ecke und hat eine Idee, wie man das besser lösen kann. Oder das MQTT-Protokoll entwickelt sich weiter...

Viele Grüße Hoppel

Zitat von horchi

kannst mir ja 'ne Tasse Kaffee zum wach bleiben senden

Das habe ich direkt mal gemacht.

Zitat von horchi

BTW, die Version 0.3.22 ist jetzt verfügbar, damit sollte der eine Punkt (ein Topic fertig sein).
Die Details werden nur einmalig nach dem p4d Start versendet (nach jedem Start)

Zu Verwendung/Konfiguration:

es gibt im WEBIF nun die Möglichkeit bei "MQTT Data Topic Name" '<NAME>' als Template zu versenden, das sieht dann zum Beispiel so aus:
p4d2mqtt/sensor/<NAME>/state

Macht man das so ist alles beim alten, <NAME> wird gegen den Namen des Messwertes ersetzt und damit für jeden ein Topic angelegt, das benötigen wir für den homeassistant.
Für Openhab und FHEM dort einfach nur ein Topic angeben (ohne den Paltzhalter <NAME>) dann kommt alles in ein Topic.

Alles anzeigen

Super! Für FHEM/Openhab User ändert sich also nichts. Verstehe ich das richtig? Ich trage unter „MQTT Data Topic Name“ wie gehabt „p4d2mqtt/sensor/“ ein. Das „sensor/“ am Ende ist optional. Das Thema Baugruppen/Subgeräte betrachtest du später.

Zitat von horchi

Wegen der Fehler-Messages, schreibt wie ihr es haben möchtet - wenn es ins Design passt setzte ich es um.

Ich dachte mit der Diskussion sind wir jetzt durch:

Zitat von Reachy

Für mich würds passen, wie Jörg es beschrieben hat. Die Array-Variante sehe ich als die bessere Variante.

Viele Grüße Hoppel

Alles klar.

Zitat von horchi

Und vielen Dank für die ganzen Kaffee !!

Ich dachte eher an Pizza und Kaffee!

Viel Spaß noch

@horchi,
Perfekt. Pizza is schon mal unterwegs

hoppel,
Danke für die Koordination