ebusd.mqtt2.template: Fragen, Anregungen

[Reinhart]

Fragen, bevor es ggf. weitergeht:
- Wäre die Gerätestruktur, die damit grundlegend angelegt werden würde aus eurer Sicht ok? Also: kann man damit was anfangen, oder bin ich gedanklich auf dem Holzweg?
- Dann wäre nicht schlecht, wenn jemand die Schritte 2 bis Ende mal mit dem MQTT2_SERVER nachvollziehen könnte. Müßte eigentlich gleich sein, kann aber auch sein, dass da irgendwas noch angepaßt werden muss, weil mehr/weniger über die CID bekannt ist.

Gruß, Beta-User

Die Gerätestruktur ist so ok. Das macht Sinn wenn nicht alles im einem Device ist weil es sonst sehr schnell unübersichtlich wird.

Ich habe jetzt den Mosquitto gestoppt und statt dessen den MQTT2_Server gestartet.  Funktioniert auch alles soweit, auch der Sonoff kommt brav an. Aber ich werde die Tage jetzt noch weiter testen, bzw. auf einer nackten Installation von vorne beginnen und alle Schritte noch einmal nachvollziehen.

Danke dir für deine Geduld, das Testsystem laß ich heute Nacht noch offen und schließe morgen dann den Zugang, lasse aber alles so laufen wenn es dann später noch was testen gibt.

LG

[Beta-User]

@TomLee:
Eine Bitte: könntest du in den Thread-Titel noch ein "mqtt2" reinflicken? Hilft ggf., wenn jemand mal danach sucht...

Was das "Einheitsdevice" angeht, vielleicht noch eine Überlegung: Es gibt da ggf. auch Möglichkeiten, die Methoden zu mischen oder später Devices (auch teilweise) wieder zusammenzufügen. Tendenziell würde ich mindestens den ESP und die übrigen Geräte trennen.

Die Gerätestruktur ist so ok. Das macht Sinn wenn nicht alles im einem Device ist weil es sonst sehr schnell unübersichtlich wird.

Danke für die Rückmeldung!
Ist auch eine gute Idee, das Testsystem ggf. erst mal so zu lassen, dass ich später da auch wieder mal rankönnte, siehe nachfolgend .



Zum Neustart des ESP (=>scan-Device) bzw. insgesamt zu dem Dingens:
Zum einen wäre hier noch interessant, was darüber an Infos kommt und wie man das ggf. auch ohne Neustart auslösen kann.
So wie ich das in Erinnerung habe, sendet der ESP ja regelmäßig die uptime. Daher wird dieses Gerät auch in jedem Fall automatisch angelegt.
Kann man den Scan automatisch anstoßen und darüber die Infos bekommen, die bislang erst kamen, wenn das "at" aktiv war, könnte man nämlich den Einrichtungsprozess so umgestalten, dass man via template das ESP-Device entsprechend konfiguriert, dass die Abfrage angestupst wird. Entsprechendes würde gelten, wenn man den ESP anders anweisen könnte, mal alle Daten vom Bus zu publishen.

Ich habe den Verdacht, dass das mit den "get"-Pfaden in der readingList nur von dem at kommt (bzw. den "anonymen" publish-Befehlen da drin). Würde man das "intern" lösen, könnte diese Hälfte der readingList entfallen und dann nur noch jeweils in der getList auftauchen, die man ggf. wieder per template generieren kann, wenn wir "das Gerät an sich" haben. (Bitte nachfragen, wenn das zu verkürzt geschrieben ist...)

(Ein list vom scan-Device würde mir da ggf. mal helfen und die Info, was man - neben der Einzelabfrage von Werten via dem .../get-Topic - alles an Befehlen über MQTT hat.

Entsprechendes gilt für Teilbereiche. Wenn es z.B. für die einzelnen Nummernbereiche möglich ist, da eine zentrale Abfrage zu starten, die dann den ganzen Satz liefert, wäre das auch einfacher, als nacheinander Einzelwerte abzurufen.



Zur firmware auf dem ESP noch:
- Es gibt da einen Topic-Tree, der sehr "blöde" ist, weil er einen Punkt enthält. Ich kann leider nicht sagen, wo der herkommt und was da an Info drüber läuft, ich hatte das gestern morgen vollends ausgeblendet... @Reinhart: du findest das auf dem Testsystem im Genera-Bridge-Device. Wenn er nicht benötigt wird oder ein Versehen ist: kann man den ggf. abschalten?
Wenn er benötigt wird: könnte man den umbenennen? Ansonsten brauchen wir jemanden, der besser regexen kann, um die bridge-Regexp anzupassen .
- Wo kann ich mich zur Funktionsweise einlesen? Gibt's irgendwo den Quelltext?
(Wie gesagt, ich habe eine Junkers die vermutlich HT3 als Bussystem spricht; evtl. ließe sich die firmware darauf anpassen; dann wäre "nur noch" die Frage, wie an ein vernunftiges Eingangssignal kommen. Daber entweder die Schaltung läßt sich dafür auch verwenden, oder ich brauche halt doch Teile aus dem HT-Proxy)

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.

Da associatedWith bereits von autocreate gesetzt wird vielleicht nochmal als Erinnerungsposten für Skeptiker der gesplitteten Devices . Jedenfalls in FHEMWEB sollte das Setzen einer gemeinsamen Gruppe und die Festlegung einer passenden Sortierung (Attribut sortby am einzelnen Device) bereits ganz ordentliche Darstellungen ermöglichen, auch das devStateIcon kann jeweils individuelle gewählt werden usw. .

Zur JSONMAP:

Für den Fall, dass doch später alle oder mehrere Devices wieder verbunden werden sollen: Im Moment ist mir noch unklar, ob dann die generelle Verwendung der Langform von json2nameValue sinnvoll wäre. Darüber wäre die Verwendung der Ausgangsquelle (Gerätetyp-Nummer) als Präfix im Großdevice möglich. Das würde zwar zur Orientierung helfen, aber die Variantenvielfalt sehr wahrscheinlich so sehr erhöhen, dass jedenfalls ab da dann der jeweilige User manuell eingreifen muß; eine Logik via template dürfte sich schlicht nicht lohnen...


Wiki-Darstellung:

Im Moment würde ich dazu neigen, die Erkenntnisse bis daher in einem neuen Wiki-Artikel mal zusammenzutragen und in den Praxisbeispielen dann darauf zu verlinken. Ist zwar noch sehr früh, aber vermutlich dauert es insgesamt jetzt nicht mehr so lange, bis wir einen halbwegs konsolidierten Stand haben werden.



Bestimmt fällt mir später wieder das eine oder andere ein, aber für's erste muß das genügen...

[Reinhart]

ja das mit dem Punkt ist mir auch aufgefallen, ich glaube das kommt aber nur einmal beim booten ansonsten ist der nie zu sehen. Vielleicht kann uns da John weiterhelfen wo der herkommt.

Code Auswählen Erweitern

testsystemMQTT2CLIENT:ebusd\.8/global/running:.* running
testsystemMQTT2CLIENT:ebusd\.8/global/version:.* version
testsystemMQTT2CLIENT:ebusd\.8/global/updatecheck:.* updatecheck
version, updatecheck das kommt nur wenn der Dämon gestartet wird und der Scan beginnt.

Aber so wie es jetzt läuft, passt ja alles soweit.
Weil du immer einen ESP erwähnst, das gesamte Testsystem hat keinen, die JSON Strings kommen alle vom eBus Dämon. Die gesamte Doku vom eBus findest du hier auf Johns Github. Es gibt zwar einen Basisadapter mit Erweiterungsplatine auf ESP Basis (Wemos Mini), aber das bekommt Fhem nicht mit weil die Daten immer vom Dämon kommen und nur der mit der Aussenwelt kommuniziert.


Im Augenblick habe ich viel Gartenbetrieb, aber wenn ich Zeit habe dann beschäftige ich mich mit einem schöneren Output der Templates und teste mit Readingsgroups. Das gefällt mit persönlich besser und die gemessenen Temperaturen sind in der Farbe dynamisch. Heiß wird rot, kalt geht ins blau (pahcolor) .  Aber auch hier versuche ich kleinere Funktionsgruppen zu erstellen, das ist übersichtlicher. Für jede Gruppe mache ich ein Template.


LG

[Beta-User]

Vorab mal Danke für die Erläuterungen, irgendwie war ich in der offensichtlich irrigen Annahme, der ESP (genauer: der zweite, da sind ja zwei drauf, wenn ich das richtig im Kopf habe) würde auch die interne Verwaltung der Busdaten machen und man würde gar keinen Dienst auf irgendeinem Rechner benötigen...(Das wäre chick gewesen, und eigentlich müßte ein ESP (vermutlich sogar ein Maple, das wäre meine Lieblingsplattform) sogar in der Lage sein, die ganze Busüberwachung selbständig zu machen. So ist der Vorteil gg. der HT-Proxy Lösung nicht da, soviel jetzt aber abschließend OT).

Im Moment denke ich, es wird das beste sein, den Aufbau - im Prinzip - wie beschrieben zu "vertemplaten", dann finden sich ggf. auch weitere Leute, die das für einzelne typische Baugruppen noch verfeinern können? ReadingsGroups dürften eigentlich für eine "nette" Formatierung mit mehreren devStateIcons nicht erforderlich sein, das müßte mit den neuen Funktionen (NL in stateFormat) oder mit einer Perl-Variante auch so gehen (Extrembeispiel: https://forum.fhem.de/index.php/topic,97430.0.html ).
Ich werde noch etwas rumexperimentieren mit den attrTemplate-Funktionen im Allgemeinen, um das ggf. übersichtlicher zu machen.

Eine RAW-Definition des scan-Devices wäre noch nett, damit ich ggf. die Infos sauber anderen Geräten zu weisen kann (oder @TomLee: das wäre doch eine Herausforderung, die nach der Vorarbeit mit brigdeRegexp evtl. zu meistern wäre? Bei der Gelegenheit auch gleich noch dieses Mistding mit der "\.8" sauber zuweisen... Btw.: ist das bei allen genau dieser String? Dann könnte man das vermutlich auch einfach mit dem template erschlagen... Das ist nur ein Problem für autocreate (und vermutlich auch nur für MQTT2_CLIENT, die Server-Variante kennt ja die richtige CID ): wenn es keine Zurdnung findet, landet es ganz am Ende "irgendwo", in dem Fall eben in der General-Bridge (weil es durch den Weiterleitungsmechanismus die eigene CID voranstellt, wenn ich das richtig interpretiere).

Ich gehe davon aus, dass man in ein Wiki reinschrieben könnte, dass man dann nach Erstellen des ebus-Devices (das den "Dämon" repräsentiert) und Anwenden des template den Dienst neu starten soll, damit alle Geräte dann dadurch automatisch anlegt werden?

Ansonsten habe ich demnächst auch das "Problem", dass der Garten ruft...

[TomLee]

Je nachdem was der Ebusd gerade "rausschickt" (ist meine Erklärung/Feststellung) wird ein MQTT2_ebusd_scan Device  (für .8 und .15) angelegt oder die zwei scan.8 und .15 Devices, das vom jeweiligen Zeitpunkt wenn autocreate "greift" abhängig.

[Reinhart]

Ich gehe davon aus, dass man in ein Wiki reinschrieben könnte, dass man dann nach Erstellen des ebus-Devices (das den "Dämon" repräsentiert) und Anwenden des template den Dienst neu starten soll, damit alle Geräte dann dadurch automatisch anlegt werden?

Das ist leider nicht ganz so, außer ein paar Broadcast kommt da nichts von selbst, deshalb mach ja immer ein Timergesteuertes get auf das was ich haben will. Das war auch in der Testumgebung so, das lief ein Timer der die "get" alle 5 Minuten durchführte.
Das man die Readingsgroups ersetzen kann, da muss ich mich noch einlesen, danke für den Link!

Ansonsten finde die Readingsgroups schon nett weil einiges möglich ist.

LG

[Beta-User]

Hmm, also es ist nicht nur diese "dusselige" .8 im Topic-Tree, sondern es kann mehrere geben, auch noch mit unterschiedlichen präfixen, und wir wissen nicht, was für was ist und warum... Nicht schön.

Stehen denn in allen drei Devices dieselben Dinge drin, nur unterschiedlich zusammengestellt? (Gleiche "eingefangene" Topics, hoffentlich irgendwie unterscheidbar? Wenn das nicht "dynamisch" ist, könnte man es hart via Template codieren, aber dann wäre wichtig zu wissen, was wohin gehört...)
Doof ist halt, dass das Sonderzeichen im ersten Teil des Topictrees steckt, da wollten schon meine diversen Versuche mit passenden Bridge-Anweisungen nicht so recht greifen. (Grummel; vielleicht hat da jemand der besser regexen kann eine Idee? Aber auch der würde eine/mehrere RAW-Definition benötigen, bitte schön .

@Reinhart:
Das "get-at" hatte ich gesehen.
Wie geschrieben halte ich das für "verantwortlich", dass die readingList unnötig lang wird. Besser wäre es m.E., die getLists direkt in den Devices zu definieren, (spätestens) dann könnte man das at mind. dahingehend verkürzen, dass das get auf das Device ausgeführt wird, ohne auf die Perl-Ebene auszuweichen.

Ich fand früher die ReadingsGroups auch eine gute Variante, um was darzustellen. Es ist aber mit dieser Perl- bzw. mehrzeiligen Variante oft nicht (mehr) notwendig; seitdem ich das (vor dem Hintergrund der template-Entwicklung für mehrkanalige Tasmotas) weiß, finde ich die direkte Variante einfacher. Man kann das Gerät selbst verwenden, muß das nicht irgendwohin verschieben und hat direkt eine informative Optik. U.A. meine bisherigen Erkenntnisse dazu noch als further reading: https://wiki.fhem.de/wiki/DeviceOverview_anpassen, dort am Ende Multi-icon-Variante und Perl-Variante (da ist es "etwas" einfacher als bei den HM-Geräten ).

[Beta-User]

So,

leider komme ich grade nicht via ssh auf den Pi, daher anbei zwei ungetestete Templates.

Das erste ist dazu da, eine neue Version des General-Bridge-templates zu testen (meine Gedanken dazu sind in dem Thread mit Rudi bzgl. der Erweiterung der autocreate-Optionen für JSONMAP zu finden).

Es sollte folgendes passieren: Zum einen wird die CID geändert, zum anderen das Device in denselben Raum verschoben werden wie das IO-Device. Schließlich müßte eine recht enge bridgeRegexp dazu führen, dass z.B. Tasmota- oder shelly-Geräte direkt separat angelegt werden.

Alles, was nicht zugeordnet werden kann (z.B. auch der ebus-Dienst), landet wieder in einem "Sammel"-MQTT2-Device (wie bisher).

Bitte dabei UNBEDINGT darauf achten, dass keine weiteren "großzügigen" bridgeRegeps in der Installation vorhanden sind, sonst haben wir wieder seltsame Effekte.

Das zweite kann dann auf das Sammel-Device angewendet werden.
Eregbnis sollte dann sein, dass auch dieses Device mit einer eigenen CID versehen wird (ebusd), umbenannt (Achtung: das geht nur einmal) und dann eine passende bridgeRegexp enthält, die uns die Geräte aufsplittet - dieses Mal hoffentlich nachhaltig sinnvoll...

Im Monent gibt es also danach mind. 3 ebus-Geräte: Den Dienst an sich (CID:ebusd), das ebusd_bai-Gerät, in das ich auch die broadcast-messages umgeleitet habe (sinnvoll?) und je eines für jedes Gerät, das dann mit dem at abgefragt wird und eine Nummer im Topic-Pfad hat (ebusd_NNN).

In diesen Geräten sollte dann hoffentlich alles landen, was irgendwie mit ebus zu tun hat (und nichts anderes sonst).

Danach kann es wieder ein "Sammeldevice" geben, das alles andere aufliest...

An sich dürfte es auch möglich sein, dass ebus-template direkt auf das Sammel-Device (also ganz zu Beginn) loszulassen, wäre evtl. auch einen Test wert...

Zum at noch:
Reinhart, ich hatte das abgeändert. Das funktioniert auch in der Fassung auf dem Pi, ich weiß allerdings nicht mehr, ob die Abfrage vollständig ist.
Die Infos vom bai-Gerät erhält man übrigens auch, wenn man eine Zeile mit "set ebusMQTT publish ebusd/+/+/get" verwendet. Danach geht aber das IO kurz auf disconnect, was schade ist; erwartet hatte ich, dass man darüber auch direkt alle nummerischen Baugruppen direkt abfragen kann, aber das wollte leider nicht...
(aus dem DEF-Editor, sonst muß man immer ein ; mehr machen):

Code Auswählen Erweitern

set ebusMQTT publish ebusd/bai/WaterPressure/get;
set ebusMQTT publish ebusd/bai/FlowTemp/get;
set ebusMQTT publish ebusd/bai/ReturnTemp/get;
set ebusMQTT publish ebusd/bai/OutdoorstempSensor/get;set ebusMQTT publish ebusd/430/Hc1HeatCurve/get;
set ebusMQTT publish ebusd/430/HwcTempDesired/get
An sich würde ich annehmen, dass man die get-Pfade ganz aus den readingList-Attributen bekommt, wenn man entsprechende getList's definiert und dann ein get <device> bla absetzt.

[Reinhart]

Alles was ich getestet habe funkioniert prima!

Auch die direkten Abfragen mit dem at get klappen tadellos. Ob die "Broadcast" sinnvoll in der "bai" untergebracht sind kann man pauschal nicht verneinen. Aber wenn es wem stört, der kann es ja rausnehmen. Ich würde es so lassen, ist ja ein schönes Beispiel wie man die Gruppen umlenken kann.

Rudi sein autocreate mit dem Wert "complex" funktioniert perfekt, die Definition einer "readingList" in den Templates ist somit zumindest beim eBus überflüssig.

Sehr professionelle Arbeit die du da machst!

LG

[Beta-User]

Danke für die Blumen .

Zur Info: eben habe ich die überarbeitete Fassung für die GeneralBridge ins svn geschoben und das (weiter reduzierte) ebus-Basis-template.

Da mir das mit dem Filtern nicht gelungen ist, wäre mein Vorschlag, dass ihr mir sagt, wenn ich an dem was tun soll (einen Link für weitere templates einfügen, z.B.), und ihr ansonsten jetzt alle Freiheiten habt, entweder ein unified "Großdevice" aufzuhübschen oder was sinnvolles mit den Baugruppen anzufangen und das dann in einem separaten tmplate-File zu verwalten (wie bisher).

Zum ebus-Basistemplate würde mich noch interessieren, ob das ggf. sauber den "richtigen" ebusd-Namen aus der readingList extrahiert (wenn man den z.B. gg. "ebusd" verändert, weil man mehrere hat...)

Gruß und dann ein schönes WE,

Beta-User

[Reinhart]

Ich habe heute noch herumgetestet und keine Fehler mehr gefunden!

Das einzige wo ich noch keine elegante Lösung gefunden habe, ist eine Verriegelung wenn jemand aus einem falschem Device ein Template aufruft.
zB: man steht im Device MQTT2_ebusd_bai und versucht das Template "E_05_eBus_430_readingsgroup_Set_Hcurve_Hotwater" zu installieren. Es läßt sich zwar installieren, funktioniert aber nicht weil der zusammen gesetzte Devicenamen "MQTT2_ebusd_BASE_DEV" mit BASE_DEV "bai" zurück liefert und so alles mit falschem BASE_DEV angelegt würde. Andererseits kenne ich BASE_DEV nicht, das kann ja irgend was sein und kann somit nicht verriegeln. Das einzige was ginge, man müsste zB: "HwcTempDesired_temp1_value" prüfen ob er im Device BASE_DEV vorhanden ist, das ist aber schon ganz schön komplex für eine reine Prüfung. Schön wäre hier eine Meldung, "Installation in diesem Device nicht möglich". Das ist aber jetzt meckern auf hohem Niveau!

Im Anhang jetzt die neuen Templates die optisch mit readingsgroups verbessert wurden.

[Reinhart]

@Beta-User
ich versuche das alles nun im Hauptsystem neu zu  installieren und kann hier autocreate "complex" nicht auswählen, der Stand von 00_MQTT2_CLIENT.pm ist ident zum Testsystem, dort gehts.
Kannst du mir einen Tipp geben wie ich das aktivieren kann?

LG
Reinhart

PS: sorry wenn man nicht liest, das geht ja nur am Client!

[rudolfkoenig]

der Stand von 00_MQTT2_CLIENT.pm ist ident zum Testsystem

Das bezweifle ich, man kann es aber mit "version" pruefen.
Evtl. fehlt ein Neustart.

[Beta-User]

Ich habe heute noch herumgetestet und keine Fehler mehr gefunden!

Danke für die Rückinfo; ich hoffe, das bezieht sich auf die via svn ausgelieferten Versionen?
(Es würde wahrscheinlich sinnvoll sein, diese beiden (das 00-er und den ebus-splitter) dann aus anderen template-files zu entfernen, sonst droht Verwirrung bei den usern. Das überarbeitete 00-er ist m.E. auch ein gutes Beispiel, wie man eine Ladung Parameter vorab festlegt (s.u.). Da stehen auch noch auskommentierte FHEM-Befehle drin (würde leider nur bei erstmaliger Anwendung auch so funktionieren, daher deaktiviert), evtl. kann das eine Anregung sein, was man sonst noch so tun kann...

@Rudi:
Eigentlich wäre es für die automatische Erkennung der am ebus angeschlossenen Geräte noch sinnvoll, wenn das Basistemplate für den ebus ein "set <IOdevice> publish ebusd/+/+/get" auslösen würde und auch einen setList-Eintrag mit "get_all" bekäme. Allerdings geht MQTT2CLIENT bei sowas ganz kurz auf disconnected? Habe jetzt nicht untersucht, ob das bei anderen Adressaten auch so ist, würde das aber annehmen. Das wäre nicht sooo toll.
(Leider scheint auch der empfangende ebus-Daemon das nicht vollständig korrekt umzusetzen; es kommen nur die bai-Meldungen zurück; @Reinhart: vielleicht testest du das auch mal direkt auf der mosquitto-Ebene nochmal und gibst das bei einer echten "Fehlfunktion" des Daemon an john weiter; vielleicht kann man das verbessern und dann zentral ergänzen, wenn beide Seiten da problemfrei funktionieren?)

Das einzige wo ich noch keine elegante Lösung gefunden habe, ist eine Verriegelung wenn jemand aus einem falschem Device ein Template aufruft.

M.E. liegt das außerhalb dessen, was man mit attrTemplate sinnvollerweise erreichen können sollte.
Aber (auch @Rudi): Was ich - jedenfalls mal als ersten Gedanken - an sich nicht schlecht fände, wäre eine Option, die Zahl der jeweils angezeigten templates etwas reduzieren zu können. Ich habe einen kurzen Test gemacht, ob man die Anzeige (via ?) einzelner Templates damit bedingen kann, dass z.B. die CID ein "ebus" enthält. Führte aber dazu, dass das betr. Template dann gar nicht angezeigt wurde, auch nicht, als die Bedingung gepaßt hat. Kann sein, dass ich da was falsch gemacht habe.

Die Idee dahinter wäre, die mit ? bzw. dann auch in der Dropdown-Liste angezeigten Templates jeweils auf die zu beschränken, die grade relevant sind. Am Beispiel von zigbee2mqtt würde ich dann erst mal im "Normalfall" nur die "Bridge" anzeigen, und alle anderen erst, wenn auch das "zigbee_" in der CID auftaucht (analog für shelly, milight...). Das würde es ggf. noch etwas übersichtlicher machen und erlauben, dass man auch "exotische" templates zentral mit ausliefert.

Im Anhang jetzt die neuen Templates die optisch mit readingsgroups verbessert wurden.

Sehen nett aus!

Aber m.E. kann man das schon noch deutlich an einigen Stellen optimieren.
- Zum einen durch den Gebrauch einer JSONMAP gleich für eine Benennung der Readings sorgen; ggf. könnte man vorab die language aus global abfragen, um so den "richtigen" Satz in einen Parameter zu bekommen.
- Was den Namen der Geräte angeht, auf die die RG zugreift, könnte das auch dynamischer vom Namen des devices abhängen, von dem aus das aufgerufen wird (DEVICE statt .
- Was "einfache" Geräte angeht (wie das 430-er), ist es m.E. auch nicht das große Problem, die relevanten Dinge gleich in's Device zu packen. Finde ich persönlich charmanter als ein weiteres Gerät (ich meine da einen Versuch von TomLee gesehen zu haben, auch die beiden setter an die richtige Stelle zu bekommen; sowas habe ich bisher aber selbst noch nicht benötigt). Auch die Balkenanzeige sollte mit devStateIcon im Perl-Modus hinzubekommen sein; ggf. macht es da Sinn, code in myUtils auszulagern, grade, wenn es dann farbig werden soll.

- Die templates 9 und 10 würde ich zugunsten von nur 11 rausnehmen, dafür aber das 11-er um eine getList ergänzen (ein Fragment hatte ich hier mal gepostet, meine ich; ggf. melden, wenn ihr da Hilfe braucht, m.E. ist als Beispiel die "beste" getList die von der Zigbee-Bridge L_01, wobei man auch da die beiden Varianten für die networkmap auch in eine Zeile hätte packen können).

Soll in das ebus-Basistemplate noch ein link rein? Wenn ja, wohin? Vorschlagen würde ich diesen Thread hier, dann müßte aber TomLee das jeweils bitte in den ersten Beitrag aktuell einpflegen, oder den allg. ebus-Installationssthread, dann müßtest du das machen.
Oder willst du das zu gegebener Zeit z.B. nach contrib schieben?
(@Rudi: vielleicht hast du da auch eine bessere Idee?)

Ganz allgemein würde ich den Ebus noch in einer Kurzfassung in die Praxisbeispiele aufnehmen, vielleicht mit einem Link zu einem anderen Artikel, wo dann ausführlichere Infos gut aufgehoben wären. Den müßte dann aber jemand anderes erstellen .

[Reinhart]

Es gibt schon diverse Inbetriebnahme Threads wo ich schon einmal kurz auf das Thema MQTT2 eingegangen bin. Das werde ich demnächst auf letzten Stand bringen. Ebenso plane ich im eBusWiki das Thema MQTT2 mit Installation und Beispielen noch zu erweitern und auf MQTT2 zu verlinken.

Das Thema alles in einen Pott zu werfen finde ich nicht gut weil das mehrere Hundert bis Tausend Datenpunkte sein können!

Hier ein Beispiel meiner Umgebung mit nur 2 Geräten am eBus ,der Therme (bai) und dem Steuergerät (Calormatric 430) , das sind schon 347 Datenpunkte die ich abfragen könnte. Vermutlich sind dann je nach Hardware einige Register nicht belegt.

Code Auswählen Erweitern

430 ACTOstorDetected = no data stored
430 actoSTOROPMode = no data stored
430 actostorstate = no data stored
430 ActualRoomTempDesiredHc1 = no data stored
430 ActualWeekday = no data stored
430 adpPreHActive = no data stored
430 adpPreHCurrentRoomTemp = no data stored
430 adpPreHInSideTW = no data stored
430 adpPreHMinutesBeforeFirstTW = no data stored
430 adpPreHOutdoorTemp = no data stored
430 adpPreHOutdoorTempStart = no data stored
430 adpPreHPreheatingTime = no data stored
430 adpPreHRamp = no data stored
430 adpPreHRoomTempDesired = no data stored
430 adpPreHRoomTempStart = no data stored
430 adpPreHStarttime = no data stored
430 AssertFileName = no data stored
430 AssertLineNumber = no data stored
430 AutoOffMode = no data stored
430 B50418actDesFlowTemp = no data stored
430 B51000FlowSetMonitor = no data stored
430 B51000M10HwcFlowSetMon = no data stored
430 B51000M12DisableBitsMon = no data stored
430 B51000M14Monitor = no data stored
430 B51000M7OpModeMonitor = no data stored
430 B51000TempDesiredLoadingPump = no data stored
430 BaseDisplay = no data stored
430 BMUB51101BoilerFlowTemp = no data stored
430 BMUB51101ErrorStatus = no data stored
430 BMUB51101HwcState = no data stored
430 BMUB51101StorageTemp = no data stored
430 BMUFlowTempOrVF1 = no data stored
430 CalculatedKickStopTime = no data stored
430 ccTimer.Friday = no data stored
430 ccTimer.Monday = no data stored
430 ccTimer.Saturday = no data stored
430 ccTimer.Sunday = no data stored
430 ccTimer.Thursday = no data stored
430 ccTimer.Tuesday = no data stored
430 ccTimer.Wednesday = no data stored
430 ChimneySweepModeActive = no data stored
430 CirPump = no data stored
430 ContinuosHeating = no data stored
430 CountryVariant = no data stored
430 CPLPLast24started = no data stored
430 currenterror = no data stored
430 Date = 28.02.2019
430 DisplayedHc1RoomTempDesired = no data stored
430 DisplayedHwcStorageTemp = no data stored
430 DisplayedRoomTemp = no data stored
430 EepromUpdateActive = no data stored
430 EnermanState = no data stored
430 errorhistory = no data stored
430 ExcessTemp = no data stored
430 FrostOverRideTime = no data stored
430 FrostProtectDelayMonitor = no data stored
430 FrostProtectionRequiredMonitor = no data stored
430 FrostProtectStateMonitor = no data stored
430 Hc1ActualFlowTempDesired = no data stored
430 Hc1HcType = no data stored
430 Hc1HeatCurve = 1.00
430 Hc1ManualOPRoomTempDesired = no data stored
430 Hc1MinimalFlowTempDesired = no data stored
430 Hc1NightTemp = no data stored
430 Hc1OPMode = no data stored
430 Hc1PreOrContinuosHeatingActive = no data stored
430 Hc1Pump = no data stored
430 Hc1PumpLast24started = no data stored
430 Hc1QuickVetoActive = no data stored
430 Hc1QuickVetoTemp = no data stored
430 Hc1RoomTempSwitchOn = no data stored
430 Hc1SummerOffset = no data stored
430 Hc2HcType = no data stored
430 HcMc1ConfigCPLPAsLP = no data stored
430 HcMc1CPLPState = no data stored
430 HcMc1Detected = no data stored
430 hcTimer.Friday = no data stored
430 hcTimer.Monday = no data stored
430 hcTimer.Saturday = no data stored
430 hcTimer.Sunday = no data stored
430 hcTimer.Thursday = no data stored
430 hcTimer.Tuesday = no data stored
430 hcTimer.Wednesday = no data stored
430 HolidayEndPeriod = no data stored
430 HolidayRoomTemp = no data stored
430 HolidayStartPeriod = no data stored
430 HRUDetected = no data stored
430 HwcActualTempDesired = no data stored
430 HwcCircuitActive = no data stored
430 HwcLegioStartDay = no data stored
430 HwcLegioStartTime = no data stored
430 HwcLoadingIn430Active = no data stored
430 HwcLoadingInBMUActive = no data stored
430 HwcLoadingOffset = no data stored
430 HwcManualOPTempDesired = no data stored
430 HwcOPMode = no data stored
430 HwcParallelLoading = no data stored
430 HwcPressLowpostrunningtime = no data stored
430 HwcQuickVetoActive = no data stored
430 HwcQuickVetoTemp = no data stored
430 HwcTempDesired = 56.0
430 hwcTimer.Friday = no data stored
430 hwcTimer.Monday = no data stored
430 hwcTimer.Saturday = no data stored
430 hwcTimer.Sunday = no data stored
430 hwcTimer.Thursday = no data stored
430 hwcTimer.Tuesday = no data stored
430 hwcTimer.Wednesday = no data stored
430 IsInHoliday = no data stored
430 KeyCodeforConfigMenu = no data stored
430 LcdContrastValue = no data stored
430 LegioProtectActive = no data stored
430 MaintenanceDate = no data stored
430 MonitorEEpromInkonsiNumber = no data stored
430 NameHc1 = no data stored
430 NameHc2 = no data stored
430 NameHwc = no data stored
430 OutsideTemp = no data stored
430 OutsideTempOffset = no data stored
430 PhoneNumber1 = no data stored
430 PhoneNumber2 = no data stored
430 PreheatingTime = no data stored
430 PreStopTime = no data stored
430 PumpBlockingTimeMax = no data stored
430 PumpEnergySaveCalculatedTimeMonitor = no data stored
430 PumpEnergySaveStateMonitor = no data stored
430 RoomTemp = no data stored
430 RoomTempCorrection = no data stored
430 RoomTempOffsetSelfWarming = no data stored
430 Setpoints.Friday = no data stored
430 Setpoints.Monday = no data stored
430 Setpoints.Saturday = no data stored
430 Setpoints.Sunday = no data stored
430 Setpoints.Thursday = no data stored
430 Setpoints.Tuesday = no data stored
430 Setpoints.Wednesday = no data stored
430 SolModuleDetected = no data stored
430 StartEepromUpdate = no data stored
430 StatusDcf = no data stored
430 SummerWinterTimeAdjust = no data stored
430 Time = 19:43:54
430 V430PluggedIn = no data stored
430 VF1 = no data stored
bai AATemp = no data stored
bai AccessoriesOne = no data stored
bai AccessoriesTwo = no data stored
bai ACRoomthermostat = no data stored
bai AircontrolOk = no data stored
bai AITemp = no data stored
bai AntiCondensValue = no data stored
bai averageIgnitiontime = no data stored
bai BlockTimeHcMax = no data stored
bai BoilerType2 = no data stored
bai BoilerType = no data stored
bai ChangesDSN = no data stored
bai CirPump = no data stored
bai CounterStartattempts1 = 29
bai CounterStartattempts2 = no data stored
bai CounterStartAttempts3 = no data stored
bai currenterror = no data stored
bai DateTime = nosignal;09:00:00;-.-.-;9.062
bai dcfState = no data stored
bai DCFTimeDate = no data stored
bai DCRoomthermostat = no data stored
bai DeactivationsIFC = 18
bai DeactivationsTemplimiter = no data stored
bai DeltaFlowReturnMax = no data stored
bai DisplayMode = no data stored
bai DSN = no data stored
bai DSNOffset = no data stored
bai DSNStart = no data stored
bai EBusHeatcontrol = no data stored
bai EbusSourceOn = no data stored
bai EbusVoltage = no data stored
bai errorhistory = no data stored
bai ExhaustCurve = no data stored
bai exhaustWayBlockCounter = no data stored
bai expertlevel_ReturnTemp = no data stored
bai ExternalFaultmessage = no data stored
bai externalFlowTempDesired = no data stored
bai externalHwcSwitch = no data stored
bai ExternGasvalve = no data stored
bai ExtFlowTempDesiredMin = no data stored
bai extWP = no data stored
bai FanHours = 6141
bai FanMaxSpeedOperation = no data stored
bai FanMinSpeedOperation = no data stored
bai FanPWMSum = no data stored
bai FanPWMTest = no data stored
bai FanSpeed = 1796
bai FanStarts = no data stored
bai Flame = no data stored
bai FlameSensingASIC = no data stored
bai FloorHeatingContact = no data stored
bai FlowsetHcMax = no data stored
bai FlowsetHwcMax = no data stored
bai FlowSetPotmeter = no data stored
bai FlowTemp = 43.06;ok
bai FlowTempDesired = 38.00
bai Fluegasvalve = no data stored
bai Gasvalve3UC = no data stored
bai Gasvalve = no data stored
bai GasvalveASICFeedback = no data stored
bai GasvalveUC = no data stored
bai GasvalveUCFeedback = no data stored
bai GVStepOffsetMax = no data stored
bai GVStepOffsetMin = no data stored
bai HcHours = 5254
bai HcPumpMode = no data stored
bai HcPumpStarts = no data stored
bai HcStarts = 38200
bai HcUnderHundredStarts = no data stored
bai HeatingSwitch = no data stored
bai HoursTillService = no data stored
bai HwcDemand = no data stored
bai HwcHours = 668
bai HwcImpellorSwitch = no data stored
bai HwcPostrunTime = no data stored
bai HwcSetPotmeter = 54.38
bai HwcStarts = 86400
bai HwcSwitch = no data stored
bai HwcTemp = no data stored
bai HwcTempDesired = no data stored
bai HwcTempMax = no data stored
bai HwcTypes = no data stored
bai HwcUnderHundredStarts = no data stored
bai HwcWaterflow = no data stored
bai HwcWaterflowMax = no data stored
bai Ignitor = no data stored
bai IonisationVoltageLevel = no data stored
bai maintenancedata_HwcTempMax = no data stored
bai maxIgnitiontime = no data stored
bai minIgnitiontime = no data stored
bai ModulationTempDesired = no data stored
bai OutdoorstempSensor = 9.06;ok
bai OverflowCounter = no data stored
bai ParamToken = no data stored
bai PartloadHcKW = 18
bai PartloadHwcKW = no data stored
bai PartnumberBox = no data stored
bai PositionValveSet = no data stored
bai PowerValue = no data stored
bai PrAPSCounter = no data stored
bai PrAPSSum = no data stored
bai PredCombustionDecrementTime = no data stored
bai PredCombustionPredCounter = no data stored
bai PredCombustionSwitchingPoint = no data stored
bai PredFanPWMDevThreshold = no data stored
bai PredFanPWMPredCounter = no data stored
bai PredFanPWMRefPWMcounter = no data stored
bai PredFanPWMRefPWMsum = no data stored
bai PredFanPWMSwitchingPoint = no data stored
bai PredIgnitionPredCounter = no data stored
bai PredIgnitionSwitchingPoint = no data stored
bai PredSourcePressureDevThreshold = no data stored
bai PredSourcePressurePredCounter = no data stored
bai PredSourcePressureSwitchingPoint = no data stored
bai PredWaterflowDevThreshold = no data stored
bai PredWaterflowSwitchingPoint = no data stored
bai PredWaterpressureMaxPressure = no data stored
bai PredWaterpressureMinPressure = no data stored
bai PredWaterpressureSwitchingPoint = no data stored
bai PrEnergyCountHc1 = no data stored
bai PrEnergyCountHc2 = no data stored
bai PrEnergyCountHc3 = no data stored
bai PrEnergyCountHwc1 = no data stored
bai PrEnergyCountHwc2 = no data stored
bai PrEnergyCountHwc3 = no data stored
bai PrEnergySumHc1 = no data stored
bai PrEnergySumHc2 = no data stored
bai PrEnergySumHc3 = no data stored
bai PrEnergySumHwc1 = no data stored
bai PrEnergySumHwc2 = no data stored
bai PrEnergySumHwc3 = no data stored
bai PumpHours = no data stored
bai PumpHwcFlowNumber = no data stored
bai PumpHwcFlowSum = no data stored
bai ReduceModulationBlocktime = no data stored
bai RemainingBoilerblocktime = no data stored
bai ReturnRegulation = no data stored
bai ReturnTemp = 34.62;64981;ok
bai ReturnTempMax = no data stored
bai SecondPumpMode = no data stored
bai SerialNumber = no data stored
bai SetFactoryValues = no data stored
bai SetMode = auto;38.0;-;-;0;0;1;0;0;0
bai SHEMaxDeltaHwcFlow = no data stored
bai SHEMaxFlowTemp = no data stored
bai SolPostHeat = no data stored
bai SpecialAdj = no data stored
bai Statenumber = no data stored
bai Status01 = 35.0;35.0;9.062;41.0;38.0;off
bai Status02 = auto;60;70.0;70;54.0
bai Status16 = no data stored
bai Status = no data stored
bai Storageloadpump = no data stored
bai StorageLoadPumpHours = no data stored
bai StorageloadPumpStarts = no data stored
bai StorageLoadTimeMax = no data stored
bai StoragereleaseClock = no data stored
bai StorageTemp = no data stored
bai StorageTempDesired = no data stored
bai StorageTempMax = no data stored
bai TargetFanSpeed = no data stored
bai TargetFanSpeedOutput = no data stored
bai TempDiffBlock = no data stored
bai TempDiffFailure = no data stored
bai TempGradientFailure = no data stored
bai Templimiter = no data stored
bai TemplimiterWithNTC = no data stored
bai TempMaxDiffExtTFT = no data stored
bai TimerInputHc = no data stored
bai ValveMode = no data stored
bai ValveStarts = no data stored
bai VolatileLockout = no data stored
bai WarmstartDemand = no data stored
bai WarmstartOffset = 0.00
bai WaterHcFlowMax = no data stored
bai WaterPressure = 2.010;ok
bai WaterpressureBranchControlOff = no data stored
bai WaterpressureMeasureCounter = no data stored
bai WaterpressureVariantSum = no data stored
bai WP = no data stored
bai WPPostrunTime = no data stored
bai WPPWMPower = 53
bai WPPWMPowerDia = no data stored
bai WPSecondStage = no data stored
broadcast datetime = no data stored
broadcast error = no data stored
broadcast hwcStatus = no data stored
broadcast id = no data stored
broadcast id = no data stored
broadcast load = no data stored
broadcast outsidetemp = 7.062
broadcast signoflife = no data stored
broadcast vdatetime = 17:02:46;09.03.2019
general valuerange = no data stored
memory eeprom = no data stored
memory ram = no data stored
scan id = no data stored
scan.04  = no data stored
scan.08  = Vaillant;BAI00;0518;7401
scan.08 id = ;;;;;;
scan.15  = Vaillant;43000;0215;2002
scan.15 id = 21;11;09;0020028515;0907;006374;N5
scan.26  = Vaillant;43000;0215;2002
scan.26 id = 21;11;09;0020028515;0907;006374;N5

"no data stored" bedeutet hier nur das dieser Datenpunkt noch nie angefordert wurde und sich nicht im Buffer befindet.

und hier jene Datenpunkte, die ich für meine Zwecke benötige, das ist auch der Grund warum du in meiner Testumgebung nicht mehr siehst.

Code Auswählen Erweitern

430 Date = 28.02.2019
430 Hc1HeatCurve = 1.00
430 HwcTempDesired = 56.0
430 Time = 19:43:54
bai CounterStartattempts1 = 29
bai DateTime = nosignal;09:06:14;-.-.-;9.062
bai DeactivationsIFC = 18
bai FanHours = 6142
bai FanSpeed = 0
bai FlowTemp = 32.50;ok
bai FlowTempDesired = 38.00
bai HcHours = 5255
bai HcStarts = 38200
bai HwcHours = 669
bai HwcSetPotmeter = 54.38
bai HwcStarts = 86400
bai OutdoorstempSensor = 9.06;ok
bai PartloadHcKW = 18
bai ReturnTemp = 32.19;65020;ok
bai SetMode = auto;38.0;-;-;0;0;1;0;0;0
bai Status01 = 32.0;32.0;9.062;38.0;37.0;off
bai Status02 = auto;60;70.0;70;54.0
bai WaterPressure = 1.762;ok
bai WPPWMPower = 53
broadcast outsidetemp = 7.062
broadcast vdatetime = 17:08:49;09.03.2019


Mit einem einzigen Befehl wie "get_all" würde man aber empfindlich den internen Verkehr des eBus sehr beeinträchtigen. Wenn jemand 7 Geräte am Bus hängen hat, sind die Zeitfenster für externe Spielereien schon sehr eng und es kommt unweigerlich zu Fehlern am Bus wenn hier pausenlos gepollt wird. Am liebsten sind mir die Statusmeldungen, die kommen alle paar Sekunden und müssen nicht extra angefordert werden. Das ist auch der Grund warum ich die als erstes in den Templates habe.
Der eBus wird ja hauptsächlich zur internen Kommunikation der Geräte untereinander verwendet und die Schnittstelle dient eigentlich nur dem Servicetechniker um einerseits das System besser parametrieren zu können und Fehler besser orten zu können.

Und ja du hast recht, ich werde noch einige Beispiele aus dem Template rausnehmen weil die sich eh überschneiden. Eigentlich ist so ein Template ja ein extrem hoher Komfort, aber etwas Raum für die eigenen Ideen der Anwender sollte man hier offen lassen.

Was man so sieht, hat ja außer TomLee das noch keiner getestet, geschweige denn die Vorteile dieser neuen Technik kennen gelernt. Viele schrecken vor Mosquitto zurück, das ist jetzt mit der Klick Klack Konfiguration (Templates) ja alles Vergangenheit. Wenn dies die ersten Neueinsteiger feststellen wird es vermutlich einen Run auf diese Methode geben. Bisher war es immer noch ECMD, aber auch nur weil das gut mit vielen Beispielen  dokumentiert ist. Und GAEBUS hat ja schon einiges an Komfort angeboten.

LG