Guten Morgen zusammen,
@Reinhart vorab: Danke für die Vorschußlorbeeren...
Gleich auch ein paar Anmerkungen:
das kommt von solchen Json Strings, hier eine typische Statusmeldung wie sie als als Broadcast ankommt.
Da würde ich dir gerne eine Wette dagegen anbieten, aber das wäre vermutlich unfair
.
Bitte setzt mal den Vorschlag aus meinem ersten Post um und definiert ein allgemeines Bridge-Gerät. (Für später hinzugestoßene: Das gilt nur für user, die MQTT2_CLIENT als IO verwenden, für MQTT2_SERVER ist das nicht erforderlich. Allgemein: Wer neu in das Thema MQTT einsteigt, sollte direkt MQTT2_SERVER verwenden, das macht es m.E. einfacher, nicht nur in der Handhabung, auch in der Installation; man kann ggf. später umstellen, wenn man doch mosquitto oä. verwenden will).
Für das weitere brauchen wir vermutlich auch "Echtgeräte", allerdings sollte das die Funktionalität der bestehenden Definitionen möglichst nicht beeinträchtigen. Dazu würde ich vorschlagen, dass ihr dazu dann mind. zwei bzw. drei Geräte (defines) habt:
- (Nur MQTT2_CLIENT: eines, auf das A_00_MQTT2_CLIENT_general_bridge angewendet wurde - da würde mich eh' interessieren, ob das funktioniert wie erwartet)
- ein "unangetastetes" Normalgerät für den regulären Betrieb, in das ggf. dann Verbesserungen manuell eingepflegt werden;
- eines zum "Spielen" mit den templates. Da kann es sein, dass wir noch ein paar mehr brauchen...
Daraus ergeben sich leider ein paar Nebenwirkungen, die man im Auge haben sollte: Vorhandene Readings werden zwar in allen MQTT2_DEVICE-Geräten aktualisiert, wenn ein publish eingeht, autocreate wirkt aber ggf. nur auf eines ein - wenn jemand irgendwas bei einem bisher unbekanntem Topic in einer readingList "fehlt", sollte er also immer in allen Geräten nachsehen, wo es ggf. angelegt worden ist. Am "Normalgerät" sollte daher autocreate abgeschaltet werden.
Generell finde ich den Ansatz gut, ggf. erst mal einige wenige Grundtypen zu definieren und da in das template jeweils nur das reinzuschreiben, was auch mit einiger Sicherheit "da" sein wird.
Was mir zum Ganzen generell als Neuerung bei den attrTemplates im Kopf rumschwirrt, wäre ggf. die attrTemplate-Methode zu nutzen, um eine vorhandene readingList, setList oder JSONMAP zu _erweitern_. Das hat auch einen Nachteil: Es könnte zu Doppeleinträgen kommen. Da brauchen wir evtl. eine neue allgemeine Routine oder eine myUtils.pm, um da wieder für Ordnung zu sorgen. Von daher wäre es ggf. auch (später?) sinnvoll, das in den MQTT-Bereich zu verschieben, damit Rudi sich dazu eine Meinung bilden kann.
Weiterer Gedanke: Es wäre auch möglich, statt eines "Großdevices", das alle Readings enthält, auch Teile abzuspalten, und Funktionsgruppen separat darzustellen. Als logische Klammer könnten wir das Reading associatedWith nutzen, und in der Darstellung in FHEMWEB das Gruppen-Attribut, ggf. mit einer Sortierpriorität innerhalb der Gruppe. Konkret könnte das so aussehen, dass man ein template auf das "Stammdevice" anwendet, und das dann ein abgeleitetes Device mit den passenden Readings für eine Funktionsgruppe anlegt, das ganze im selben Raum wie das "Stammdevice", mit dem associatedWith-Reading zum Stammdevice und derselben Gruppenzugehörigkeit.
Dann hätte ich noch die Frage, ob es weitere "setter" geben sollte? Beispiel: ich habe eine Junkers (die leider nicht "ebus" spricht). Da nervt mich z.B. sehr, dass die dort verbaute Uhr so ungenau ist und die Zeitumstellung noch nicht kennt...
Das allererste, was ich der beibringen würde, wäre jeden Monat bzw. zu den Umstellungsdaten die aktuelle Zeit
. Ist doch bestimmt beim ebus möglich...
Zur JSONMAP: Wäre es evtl. sinnvoll, sich an die Terminologie zu halten, die der/die Hersteller auch in ihren Handbüchern verwenden? Dann sprecht ihr dieselbe Sprache wie eure Servicetechniker und Heizungsbauer
.
Was die Bereitstellung der templates und den Verbreitungsweg angeht, muß ich mir mal die Funktionalität des filter-Parameters ansehen. Evtl. wäre es möglich, die ebus-Templates nur mit anzuzeigen, wenn das Gerät, auf das der attrTemplate-?-Befehl angewendet wird, der devspec "model=E_03.*_eBus_.*" entspricht... Dann könnte man die file ohne weiteres größer machen bzw. eine ebus-spezifische template-file via svn ausliefern, ohne dass das den großen Rest irgendwie stört. Nur einmal ein ebus-Basistemplate drüber, schon erhält man Zugriff auf die anderen
. (muß ich mir mal für tasmota... auch ansehen, das würde die Übersichtlichkeit insgesamt vielleicht erhöhen).
Apropos testen:
Um selbst irgendwas auszutesten, würde ich bei Gelegenheit mal ein paar RAW-Definitionen von ebus-Geräten benötigen, sonst habe ich nichts, wogegen ich template-Versuche laufen lassen kann. (am besten eine file, die ich direkt irgendwo wegspeichern kann).
Bitte fragt nach, wenn was nicht verständlich sein sollte, das waren jetzt sehr viele Dinge auf einmal, die auch bei mir noch nicht ausgereift sind.
Einen netten Tag wünscht euch
Beta-User
