Beiträge von hoppel118

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

    Zitat von horchi


    kannst mir ja 'ne Tasse Kaffee zum wach bleiben senden ;)


    Das habe ich direkt mal gemacht. ;)



    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

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

    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

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

    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

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

    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.




    Ich hoffe, dass dir das bei deinen Entscheidungen hilft.


    Gruß Hoppel

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

    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

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

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



    Wie seht ihr das?

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

    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

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

    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:




    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

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

    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.
    Code
    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

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

    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

  • 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.

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

    Zitat von horchi

    /Edit
    Ergänzend, wo/wie werden bei dieser Lösung { "ReadingName1":Wert1, "ReadingName2":Wert2 } Einheit und Titel übertragen?
    Der Titel kann ja noch Sonderzeichen, Leerzeichen etc. enthalten? Und wo die gewünschte Baugruppe? Aus dem im Topic verwendeten Namen bzw. der Sensor ID habe ich die Sonderzeichen wie geschrieben entfernt, aber ein Titel ohne diese wäre m.E. hässlich.

    Hier die Antwort von Rudi:



    Gruß Hoppel