ebus Weishaupt MQTT im Zusammenspiel

rob · 15 Juli 2021, 12:53:53

Hab es eingebaut.
list -r MQTT2_ebusd_21.2_1 sagt:


define MQTT2_ebusd_21.2_1 MQTT2_DEVICE ebusd
attr MQTT2_ebusd_21.2_1 autocreate 1
attr MQTT2_ebusd_21.2_1 bridgeRegexp (ebus\S[^/]*?)/(bai|\d+|cc|e7f|ehp|f\d\d|hc|hc\d+|he.|hmu|hwc|mc|mc.\d|omu|omu.\d|pms|rcc|rcc.\d|sc|sdr_p|solar|ui|uih|v\d\d|v81.\d|vd\d|vl\d|vr_\d\d|zeo)/.*:.* "$1_$2"\
(ebus\S[^/]*?)/(global|broadcast|general|scan[^/]+)/.*:.* "$1"
attr MQTT2_ebusd_21.2_1 comment NOTE: additional templates and code have been downloaded from svn (contrib).<br>Pls. inform the maintainer, if the bridgeRegexp doesn't fit to all of your devices connected to the bus.
attr MQTT2_ebusd_21.2_1 devStateIcon 1.true:it_net 1.false:it_net@red  2.true:lan_rs485 2.false:lan_rs485@red
attr MQTT2_ebusd_21.2_1 icon sani_boiler_temp
attr MQTT2_ebusd_21.2_1 model eBus_daemon_splitter
attr MQTT2_ebusd_21.2_1 readingList ebusd/scan[^/]+/.*:.* { $EVENT=~ s{[{]"value":\s("[^"]+")[}]}{$1}g;; $TOPIC =~ m,scan.([^/]+)/,;; json2nameValue($EVENT,"scan_${1}_") }\
ebusd/global/uptime:.* uptime\
ebusd/broadcast/datetime:.* { json2nameValue($EVENT) }\
ebusd/global/running:.* running\
ebusd/global/version:.* version\
ebusd/global/scan:.* scan\
ebusd/global/signal:.* signal
attr MQTT2_ebusd_21.2_1 room MQTT2_DEVICE
attr MQTT2_ebusd_21.2_1 setList getKnown:noArg ebusd/list onlyknown\
  getAll:noArg ebusd/list
attr MQTT2_ebusd_21.2_1 stateFormat Status: \
1:running\
Signal: \
2:signal\
<br>Uptime: formatedUptime
attr MQTT2_ebusd_21.2_1 userReadings formatedUptime:uptime.* {my $m = ReadingsVal($name,"uptime",0)/60;;;; return sprintf "0 000 00:%02d", $m if $m < 60;;;; my $h = $m / 60;;;; $m %= 60;;;; return sprintf "0 000 %02d:%02d", $h, $m if $h < 24;;;; my $d = $h / 24;;;; $h %= 24;;;; return sprintf "0 %03d %02d:%02d", $d, $h, $m if $d <365;;;; my $y = $d / 365;;;; $d %= 365;;;; return sprintf "%d %03d %02d:%02d", $y, $d, $h, $m}

setstate MQTT2_ebusd_21.2_1 Status: \
1:true\
Signal: \
2:true\
<br>Uptime: 0 000 00:00
setstate MQTT2_ebusd_21.2_1 2021-07-15 09:34:17 HW_value 0302
setstate MQTT2_ebusd_21.2_1 2021-07-15 09:34:39 ID_value ??
setstate MQTT2_ebusd_21.2_1 2021-07-15 09:34:17 MF_value Kromschroeder
setstate MQTT2_ebusd_21.2_1 2021-07-15 09:34:17 SW_value 1200
setstate MQTT2_ebusd_21.2_1 2021-07-15 12:34:18 associatedWith MQTT2_ebusd_21.2_1
setstate MQTT2_ebusd_21.2_1 2021-07-15 08:51:39 attrTemplateVersion 20200824
setstate MQTT2_ebusd_21.2_1 2021-07-15 12:34:42 date_value 15.07.2021
setstate MQTT2_ebusd_21.2_1 2021-07-15 12:34:50 formatedUptime 0 000 00:00
setstate MQTT2_ebusd_21.2_1 2021-07-15 12:34:42 outsidetemp_value 17.000
setstate MQTT2_ebusd_21.2_1 2021-07-15 12:34:02 running true
setstate MQTT2_ebusd_21.2_1 2021-07-15 12:34:49 scan "finished"
setstate MQTT2_ebusd_21.2_1 2021-07-15 09:37:46 scan_08_HW_value 0302
setstate MQTT2_ebusd_21.2_1 2021-07-15 09:37:46 scan_08_ID_value W 
setstate MQTT2_ebusd_21.2_1 2021-07-15 09:37:46 scan_08_MF_value Kromschroeder
setstate MQTT2_ebusd_21.2_1 2021-07-15 09:37:46 scan_08_SW_value 1200
setstate MQTT2_ebusd_21.2_1 2021-07-15 12:34:48 scan_0c_ID ??
setstate MQTT2_ebusd_21.2_1 2021-07-15 12:34:13 scan_35_ID W 
setstate MQTT2_ebusd_21.2_1 2021-07-15 09:34:15 scan_35_ID_value W 
setstate MQTT2_ebusd_21.2_1 2021-07-15 12:34:13 scan_35_MF Kromschroeder
setstate MQTT2_ebusd_21.2_1 2021-07-15 09:34:15 scan_35_MF_value Kromschroeder
setstate MQTT2_ebusd_21.2_1 2021-07-15 12:34:13 scan_35_SW 2726
setstate MQTT2_ebusd_21.2_1 2021-07-15 09:34:15 scan_35_SW_value 2726
setstate MQTT2_ebusd_21.2_1 2021-07-15 12:34:16 scan_f6_HW 0302
setstate MQTT2_ebusd_21.2_1 2021-07-15 12:34:16 scan_f6_ID WWST?
setstate MQTT2_ebusd_21.2_1 2021-07-15 12:34:16 scan_f6_MF Kromschroeder
setstate MQTT2_ebusd_21.2_1 2021-07-15 12:34:16 scan_f6_SW 1200
setstate MQTT2_ebusd_21.2_1 2021-07-15 12:34:18 signal true
setstate MQTT2_ebusd_21.2_1 2021-07-15 08:51:39 state getKnown
setstate MQTT2_ebusd_21.2_1 2021-07-15 12:34:42 time_value 12:37:-
setstate MQTT2_ebusd_21.2_1 2021-07-15 09:36:40 updatecheck "OK"
setstate MQTT2_ebusd_21.2_1 2021-07-15 12:34:50 uptime 48
setstate MQTT2_ebusd_21.2_1 2021-07-15 12:34:02 version "ebusd 21.2.v21.2"

Zitat von: Beta-User am 15 Juli 2021, 11:32:23
Für "SetTemp_value" würde ich z.B. "desiredTemp" vorschlagen...

Für mich OK. Ich bin da leidenschaftslos. Du kannst besser einschätzen, was sich harmonisch einfügt/ Sinn macht.
Bei einigen Readings kann ich eh nur raten, was das sein soll z.B. TrendTemp_value - eingebaute Wettervorhersage?!?

Wenn ich Dich richtig verstehe, möchtest Du zunächst die Readings harmonisieren, damit diese unabhängig vom Hersteller gleichartig sind. Korrekt?
Nächster Schritt wäre dann ein Template. Oder?
Ich hab die Templates durchgeschaut. Teilweise werden IODev und Topics gesetzt. Vielleicht kommt man garnicht um ein extriges "weishaupt-Templ." herum? So weit isses aber eh noch nicht.

Aus den anderen Weishaupt-Freds konnte ich nichts ziehen, was uns hier konkret helfen würde (ganz am Schluss ggf. ein paar Graphen). Was kann ich aus Deiner Sicht zur Entlastung noch beisteuern?

Beta-User · 15 Juli 2021, 13:40:32

Zitat von: rob am 15 Juli 2021, 12:53:53
Für mich OK. Ich bin da leidenschaftslos. Du kannst besser einschätzen, was sich harmonisch einfügt/ Sinn macht.

Ich kann das aber auch nur bei einigen wenigen, von denen ich z.B. weiß, dass z.B. Sprachsteuerungslösungen die "gut" finden (und automatisch erkennen, um was es sich handelt

). "Eigentlich" ist das im Wesentlichen eine Fleißaufgabe für User: https://forum.fhem.de/index.php/topic,117933.0.html (Hinweise bzgl. Heizungsgeräten sind v.a. bei den zigbee2mqtt-mqtt2.template-Threads zu finden).

Zitat
Bei einigen Readings kann ich eh nur raten, was das sein soll z.B. TrendTemp_value - eingebaute Wettervorhersage?!?

Na ja, du hast "wenigstens" die Chance zu wissen, aus welchem Register die kommen; sehr vielleicht hat dann auch jemand eine Idee (von Doku ganz zu schweigen!), was sie zu bedeuten haben...

Zitat
Wenn ich Dich richtig verstehe, möchtest Du zunächst die Readings harmonisieren, damit diese unabhängig vom Hersteller gleichartig sind. Korrekt?

Einheitliche "Benennungen" von der eBus-Seite für identische Inhalte zu bekommen, wäre das Optimum, was man erreichen kann. So wie ich das verstanden habe, ginge das nur, wenn die csv's identisch wären (und z.B. bekannt, was sich eigentlich hinter welchem Register verbirgt usw.).

Soweit würde ich im Moment _nicht_ gehen wollen, das wird sonst uferlos!

Was wir beeinflussen können, sind folgende Punkte:
- sinnvolle Reading-Namen => "finden" und "festzurren", und dann ab nach jsonMap,
- Beispiele kreieren, anhand denen man als User erkennen kann, wie es funktioniert. Dann kann der User jeweils entscheiden, ob er lieber seine csv anfasst, oder die jsonMap.

Das mit den Beispielen _kann_ als attrTemplate erfolgen, und wenn wir Glück haben, könnte man dann ggf. auch einfach die jsonMap "Weishaupt"- oder "Vaillant"-spezifisch gestalten und über RADIO-Optionen in ein- und demselben attrTemplate auswählbar machen. Ich würde aber eher vermuten, dass man z.B. für ein "allgemeines Zentralheizungsgerät" ein attrTemplate hat und dann (im Wiki) erläutert, wie man es von "Weishaupf-flavour-3" auf "Vaillant-Geschmacksrichtung-b" anpasst...

Zitat
Ich hab die Templates durchgeschaut. Teilweise werden IODev und Topics gesetzt.

IODev sollte vermutlich nicht mehr gesetzt werden, was Topics angeht, wäre es nicht das erste Mal, dass man den vorhandenen readingList-Topic nimmt und dann daraus eine setList etc. bastelt. Die Struktur ist eh' klar, denn der ebusd nimmt das ja auch wieder auf "seine Art" auseinander.

Ergo: erst mal "gute Geräte" bauen, dann schauen wir, was ggf. in den "Mustergeräten" in der csv angepasst werden kann/soll, und dann sehen wir weiter

.

ZitatWas kann ich aus Deiner Sicht zur Entlastung noch beisteuern?

Du kannst morgen ggf. nochmal ein update machen, ich hoffe, dass ich vorher die myUtils nochmal angepaßt bekomme und einen wrapper für j2nv() reinnehme, mit dem man allg. dieses "_value" unterdrücken kann, ohne jedesmal ausdrücklich die Regex davorzuschreiben

.

Ansonsten ist es an dir rauszufinden, was das für "Baugruppen" sind und welche Werte die eigentlich liefern (und, falls du doch steuern magst: welche Werte du setzen können möchtest...), und ggf. dann mal das "at"->periodicCmd-Thema aufzugreifen...

Ich für meinen Teil bin dann eigentlich weitestgehend "fertig", es bleibt eigentlich "nur noch",
- einmal zu zeigen, wie man den Kreis von setList bzw. getList-Argumenten bis zur Rückmeldung des Geräts "hab's erledigt" schließt,
- zu klären, wie man ggf. mit "neuer" und "alter" Version der attrTemplates umgehen will (würde eine Zeitlang die alten dann als "legacy"-Versionen vorhalten und die desc. entsprechend anpassen)
- ggf. beim Coden für ebus <=> MQTT2_DEVICE <=> weekprofile zu unterstützen (falls jemand mitliest, der das haben will: bitte neuen Thread im MQTT-Bereich aufmachen und Topic-Payload-Daten speziell zu dem Wochenprofil bereitstellen)

Das wäre es dann für's erste auch schon wieder gewesen, oder übersehe ich was...?

TomLee · 15 Juli 2021, 13:40:50

ZitatFür "SetTemp_value" würde ich z.B. "desiredTemp" vorschlagen...

Les ja nur mit, meinst nicht eher DHWSetTemp_value 48.0, verstehe es so das der Wert die eingestellte Warmwassertemperatur ist, k.A. was SetTemp_value ist vermute Warmwasseraufbereitungshysterese.

Und angenommen in dem MQTT2_ebusd_hc1 kommen (in der Heizperiode) zwei Werte, einmal für Tages.- und einmal für die Nachttemperatur, was würdest du dann vorschlagen, dann klappt das was du dir vorstellst doch mit desiredTemp nicht mehr, ausser man macht zwei Geräte daraus ?

Beta-User · 15 Juli 2021, 13:54:19

Zitat von: TomLee am 15 Juli 2021, 13:40:50
Les ja nur mit, meinst nicht eher DHWSetTemp_value 48.0, verstehe es so das der Wert die eingestellte Warmwassertemperatur ist, k.A. was SetTemp_value ist vermute Warmwasseraufbereitungshysterese.

Das kann schon sein mit der Hysterese...

Es ist und bleibt so: ich habe keine Ahnung, was sich hinter den Etiketten verbirgt. Mein Teil beschränkt sich im wesentlichen darauf, dass z.B.
- der "Hauptschalter" möglichst nach "state" gemappt wird und "on" bzw. "off" ist
- die "Zieltemperatur" in "desiredTemp" landet, und eine gemessene Temperatur tendenziell eben "temperature" belabelt wird...

Wo das keinen Sinn macht, stellt sich schnell die Frage nach "guten Standards", und das will ich eigentlich gar nicht für alle aus der Hüfte festschreiben. Tag- und Nachttemperatur kenne ich z.B. von CUL_HM her als dayTemp bzw. nightTemp; bei ZWave heißt das wieder anders, usw. usf..

Zur Klarstellung: das muss alles nicht von heute auf morgen "stehen", aber optimalerweise klären wir eben vorab, was bereits gut supportet wird und sich daher als "gute Lösung" empfiehlt.

Zitat
ausser man macht zwei Geräte daraus

Das kann im Einzelfall ggf. auch rauskommen.
Z.B. die bridgeRegexp in der heutigen Form ist halt mal entstanden, um "irgendwie" überhaupt handhabbare "Baugruppen" zu haben. Wenn man das besser weiter aufdröselt (oder anders gruppiert), soll mir das recht sein, wenn man es besser "uneindeutig" läßt: Mir auch recht, ich will in der Hinsicht nur "guten Support" leisten, damit v.a. die User, die neu in das jeweilige Thema einsteigen nicht vor einem zu ungeordneten "Aha, jetzt habe ich hier irgendwelche Daten, und nun...?!?" sitzen.
Ansonsten gäbe es auch noch readingsProxy und andere Hilfsmittel...

rob · 15 Juli 2021, 15:46:42

Zitat von: Beta-User am 15 Juli 2021, 13:40:32
Ansonsten ist es an dir rauszufinden, was das für "Baugruppen" sind und welche Werte die eigentlich liefern (und, falls du doch steuern magst: welche Werte du setzen können möchtest...), und ggf. dann mal das "at"->periodicCmd-Thema aufzugreifen...

... das habe ich befürchtet

Es kommen halt Werte in Fhem an und ich habe wenig Ahnung, was das sein soll

Gestern hatte ich ungelogen john30s WIKI zu den CSV 10x durchgelesen (https://github.com/john30/ebusd/wiki/4.-Configuration) und anhand J0ek3rs CSVen nachvollziehen wollen. Ich find da nix zusammen. Keine Ahnung, warum das so funktioniert.
Die einfachsten Dinge schaffe ich dort nicht in Einklang zu bringen. Mit Datenbanken, SQL und Relationen hab ich kein Problem und denk mich auch gerne in Programmsourcen rein, aber dieses CSV-Zeugs ist für mich offenbar zu hoch.
Mappings kenne ich via key-value u.ä.. Die CSV sind aber dermaßen verschachtelt und includes gibt es auch noch

Schaut für mich aus wie transponierte Datentabellen ➜ statt viele Zeilen, gibt es viele Spalten - keys finden sich in den Spalten etc..

Hc1 kann ich mir noch zusammenreimen ➜ heating circuit 1
Bei sc muss ich schon passen. Scheint eine stehende Abkürzung zu sein. Jedenfalls wird es in d. CSV nicht kommentiert, aufgelöst oder übersetzt. Oder ich finde es nur nicht.
Nunja, CSV passt so natürlich nicht zum hiesigen MQTT-Thema. Bin aber dran.

Das CSV-Gedöns muss ich versuchen in den passenden Freds zu beleuchten. Ich fürchte nur, dass es nicht viele Leute gibt, die diese CSV-Teile verstehen. Nicht umsonst sucht J0ek3r einen Maintainer...

Zitat von: Beta-User am 15 Juli 2021, 13:40:32
...Dann kann der User jeweils entscheiden, ob er lieber seine csv anfasst, oder die jsonMap.

Ernsthaft? Ich finde Perl & Co 100x einfacher als diese CSVen (was nicht heißt, dass ich darin ein Crack bin...). Ich würde mich immer am json versuchen bevor ich was mit den CSV mach'.
Jetzt schweife ich aber ab

Ich werde mich jetzt in die Dokus eingraben und versuchen die offenen Punkte zu recherchieren.

Viele Grüße
rob

Beta-User · 15 Juli 2021, 19:12:55

Ich vermute ja mal, dass das mit den cvs eigentlich auch keine wirkliche Geheimwissenschaft ist, sondern auch nur strukturiertes search&replace, aber das ist nun wirklich nicht meine Baustelle...

Jedenfalls ist die aktualisierte Fassung der mqtt2.template und der myUtils für ebus im svn, wer mag, kann sich das schon von da holen: