also in Openhab is grundsätzlich egal wie die Daten kommen. So wie jetzt der JSON kommt, scicken vielen MQTT-Geräte ihre Daten. Die bei mir eigentlich überwiegen.. ich flashe alles was geht mit Tasmota. Das zusammenfassen in Gruppen machts vielleicht schöner lesbar für den Menschen. Mir reicht im Prinzip die Gruppe Heizung. Mit JSONPATH$ wird der JSON geparst.. wenn mehrere Gruppen da sind, ist die Konfiguration dann deutlich aufwendiger. Ist aber nur meine persönliche Meinung.
so wie es jetzt is, hab ich es eigentlich erwartet.
Also für Openhab gehts so oder so. Aber 2 Wege sollten wir nicht machen.
Wenn pro Baugruppe ein Topic gemacht wird sind wir doch fast beim Ausgangsformat, oder seh ich das falsch?
OK, dann ist es bei FHEM andersherum. Wenn man die Messwerte von einander trennen möchte und nur die verschachtelten Messwertenbezeichnungen hat, wie bspw. Holzscheitkessel_Kesseltemperatur, Puffer_Puffertemperaturoben, Puffer_Puffertemperaturunten, Boiler_Boilertemperaturoben oder Boiler_Boilertemperaturunten, etc., ist das schon sehr aufwändig bzw. für Leute, die p4d eigentlich nur in FHEM einbinden wollen und kein tieferes Knowhow haben, eher schwierig bis gar nicht umsetzbar. Ich glaube, zu dieser Gruppe Leute gehöre ich häufig auch.
Der Ausgangszustand war ein Topic für alle Messwerte der Heizung. Nun haben wir weiterhin ein Topic mit einer Kombinationsbezeichnung "Baugruppe_Messwert". Vom Topic her betrachtet, ist das der Ausgangszustand.
Ich würde es schön finden, wenn man die Option zur Auswahl hätte. So könnte jeder es den Vorlieben seiner Hausautomatisierungssoftware entsprechend konfigurieren. Warum sollten wir auf diesen zweiten Weg verzichten? (Verstehe nicht, was deiner Ansicht nach dagegen spricht.)
also wäre dein Ziel die Verschachtlung mit den Baugruppen so beizubehalten aber für jede ein separates Topic?
Für Fehlermeldungen ein eigenes Topic zu verwenden sehe ich kein Problem.
Das Ziel für FHEM hatte ich Eingangs (Punkt 5 von 
beispielhaft aufgeführt:
5. Im Moment kommen alle "Baugruppen" unter einem Sub-Pfad. Daher muss man händisch sortieren, was wohin (vielleicht...) gehört, dabei kann der Endanwender eigentlich nur raten.
Der Hersteller sollte aber wissen, welche Hex-Adresse zu welcher Baugruppe gehört und welches "Etikett"/welche Bezeichnung die hat. Also sollte es je einen Sub-Pfad geben, der die zusammengehörenden Adressen bündelt.
Beispiel, damit man die Richtung evtl. erkennen kann:CodeAlles anzeigenp4d2mqtt/sensor/Kessel/Temperatur_0x0/state:.* { json2nameValue($EVENT) } p4d2mqtt/sensor/Kessel/Abgastemperatur_0x1/state:.* { json2nameValue($EVENT) } p4d2mqtt/sensor/Kessel/Stellgroesse_0x12/state:.* { json2nameValue($EVENT) } p4d2mqtt/sensor/Kessel/Abgas-Solltemperatur_0x13/state:.* { json2nameValue($EVENT) } p4d2mqtt/sensor/Kessel/Vorlauf-Isttemperatur_0x15/state:.* { json2nameValue($EVENT) } p4d2mqtt/sensor/Kessel/Vorlauf-Solltemperatur_0x16/state:.* { json2nameValue($EVENT) } p4d2mqtt/sensor/Saugzug/Drehzahl_0x7/state:.* { json2nameValue($EVENT) } p4d2mqtt/sensor/Saugzug/Ansteuerung_0xf/state:.* { json2nameValue($EVENT) } p4d2mqtt/sensor/BusInterface/Status/state:.* { json2nameValue($EVENT) } p4d2mqtt/sensor/BusInterface/Zykluszeit_0xe/state:.* { json2nameValue($EVENT) } p4d2mqtt/sensor/Steuerung/Betriebsmodus/state:.* { json2nameValue($EVENT) } p4d2mqtt/sensor/Steuerung/Boardtemperatur_0x2/state:.* { json2nameValue($EVENT) } p4d2mqtt/sensor/Steuerung/Aussentemperatur_0x4/state:.* { json2nameValue($EVENT) }(Was diese Gruppierungen angeht, hatte Beta-User (einer der beiden FHEM Entwickler) für ebus im Hinterkopf, dass das da mit csv-Files gemacht wird, wo die HEX-Adressen dann direkt Gruppen zugeordnet werden und je eine deutsche und englische Bezeichnung für Baugruppe und Element drin stand; kann aber auch falsch sein).
"sensor/" kann man ja mittlerweile schon aus dem Pfad entfernt werden...
Das Ziel für FHEM wäre also eher das Unterbringen der Baugruppen im Topic-Pfad, anstelle einer Kombination der Baugruppen und Messwerte miteinander.
Grundsätzlich ist das auch in FHEM abbildbar, aber für den Ottonormalverbraucher extrem kryptisch.
Hier die Diskussion dazu aus dem FHEM Forum:
ZitatUnd so schauen die Verrenkungen aus, die man alle per Hand anlegen darf:
Codedefine Boiler MQTT2_DEVICE attr Boiler readingList p4d2mqtt.* { my $j=json2nameValue($EVENT);; my %r;; map { $r{$1}=$j->{$_} if($_=~m/Boiler_(.*)/) } keys %{$j};; \%r } define Holzscheitkessel MQTT2_DEVICE attr Holzscheitkessel readingList p4d2mqtt.* { my $j=json2nameValue($EVENT);; my %r;; map { $r{$1}=$j->{$_} if($_=~m/Holzscheitkessel_(.*)/) } keys %{$j};; \%r }
Kuerzer aber nicht weniger kryptisch ist diese Schreibweise:Codeattr Boiler readingList p4d2mqtt.* { hashKeyRename(json2nameValue($EVENT), '^(Boiler_(.*)_value)', '(Boiler.*)') }
Ganz ehrlich, sowas kriegt man nicht hin, wenn man kein Entwickler ist und gerne einzelne Baugruppen habe möchte.
ZitatAlles anzeigen...ich hoffe, das wiederzufinden, wenn wir es wirklich brauchen [Blockierte Grafik: https://forum.fhem.de/Smileys/default/rolleyes.gif] .
(Und hoffe immer noch, dass horchi und "Teilstücke der Pipeline" jeweils auf einem eigenen Teil des Topic-Pfades liefern mag...)
Vielleicht nochmal ein paar Anmerkungen/Fragen):
- (das Connect/Disconnect-Ding ist gelöst?)
- Einen "last will" habe ich nicht gesehen? Absicht? Später? Nicht verstanden, um was es da geht bzw. wie das gedacht ist?
- Es sollte ein "Subgerät" "Busmaster" geben:
-- (da gehört der last will zu online/offline hin = eigener Topic)
-- da sollte man einstellen können, ob
--- das Bezugssystem metrisch oder imperial ist (=km+°C vs. miles+°F). Optimalerweise umschaltbar von metrisch auf imperial via einem MQTT-Kommando;
--- Einheiten überhaupt gesendet werden sollen => Senden von Einheiten ebenfalls im default abgeschaltet, nur bei Bedarf einschaltbar (via MQTT)
--- man die "discovery-Meldung" für homeassistant haben will; auch die fände ich by default im abgeschalteten Zustand besser...
ZitatWarum nur Imperial und nicht US? Oder Magdeburg, von 1430 bis 1630 ? Will damit sagen: sind die Benutzer von diesem Holzscheitkessel-Steuerung in US oder GB (oder Magdeburg, vor 1630
) relevant? Und selbst wenn ja, eine Umstellung direkt am Geraet sollte reichen, sowas stellt man doch nicht staendig um, und schon gar nicht aus der Ferne.
Eine Umstellmoeglichkeit macht Software/Doku/Support/Benutzung komplizierter.
ZitatSoweit korrekt, von mir aus auch gem. US-System oder was auch immer.
Geht nur drum zu sagen: Selbst wenn man es auf "einmalig beim Systemstart" beschränkt, macht das Senden von Einheiten mMn. wenig Sinn. Es erzeugt einfach nur (@FHEM: in 99,999% der Fälle unnötige) Daten - schon gleich, wenn es gar nicht änderbar ist (auf der Sender-Seite).
Was für ein Post... Ich hoffe, dass es nun klarer ist. 
Viele Grüße Hoppel
