Autor Thema: ebusd.mqtt2.template: Fragen, Anregungen  (Gelesen 30749 mal)

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 12474
  • eigentlich eher "user" wie "developer"
Antw:ebusd.mqtt2.template: Fragen, Anregungen
« Antwort #225 am: 15 November 2020, 06:44:39 »
Na ja, ein RAW-list von so einem 630 (einschl. Readings), wie es die bridgeRegexp erzeugt, wäre erst mal ein Startpunkt...
Das ist ja das, was ein "Einsteiger" in das Thema zu sehen bekommt und dann weiter konfigurieren bekommt.
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, Twilight,  AttrTemplate => {mqtt2, mysensors, zwave}

Offline mr_petz

  • Full Member
  • ***
  • Beiträge: 151
Antw:ebusd.mqtt2.template: Fragen, Anregungen
« Antwort #226 am: 16 November 2020, 09:12:39 »
Nehmen wir mal das Template zur Vorlage.
Denke da kannst du was mit anfangen.
###############
#ebusd
#
#ebus daemon device
name:eBus_daemon_splitter
filter:TYPE=MQTT2_DEVICE
desc:Device containing all status messages from the ebus daemon itself<br>NOTE: acts also as a bridge device to split up the hardware on the bus into different mqtt2_devices<br>NOTE:<br>- for use with MQTT2_CLIENT use a copy of the Device with the same clientId than the IO, delete original's readingList after applying the template!<br>- this might change the devices CID
order:E_01a
par:DEVTYPE;Internal TYPE of the device; { InternalVal("DEVICE","TYPE",undef)}
par:DEV_ID;base topic set ebus;{ AttrVal("DEVICE","readingList","") =~ m,[^:]+:?(ebus[a-zA-Z])[^/]*[/].*:, ? $1 : "ebusd" }
par:ICON;ICON as set, defaults to sani_boiler_temp;{ AttrVal("DEVICE","icon","sani_boiler_temp") }
{ Svn_GetFile("contrib/AttrTemplate/99_attrTmqtt2_ebus_Utils.pm", "FHEM/99_attrTmqtt2_ebus_Utils.pm", sub(){ CommandReload(undef, "99_attrTmqtt2_ebus_Utils") }) }
{ Svn_GetFile("contrib/AttrTemplate/mqtt2.ebus.template", "FHEM/lib/AttrTemplate/mqtt2.ebus.template", sub(){ AttrTemplate_Initialize() }) }
attr DEVICE icon ICON
modify DEVICE DEV_ID
attr DEVICE autocreate 1
attr DEVICE bridgeRegexp (ebus..*?)/(bai|\d+|cc|e7f|ehp|f\d\d|hc|he.|hmu|hwc|mc|mc.\d|omu|omu.\d|pms|rcc|rcc.\d|sc|sdr_p|ui|uih|v\d\d|v81.\d|vd\d|vl\d|vr_\d\d|zeo)/.*:.* "$1_$2"\
(ebus..*?)/(global|broadcast|general|scan([^/]*))/.*:.* "$1"
attr DEVICE 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}
attr DEVICE stateFormat Status: \
1:running\
Signal: \
2:signal\
<br>Uptime: formatedUptime
attr DEVICE devStateIcon 1.true:it_net 1.false:it_net@red  2.true:lan_rs485 2.false:lan_rs485@red
attr DEVICE setList getKnown:noArg DEV_ID/list onlyknown\
  getAll:noArg DEV_ID/list
set DEVICE getKnown
attr DEVICE comment NOTE: additional templates and code have been downloaded from svn (contrib).
farewell:template has been applied successfully. <br>NOTE: additional templates and code have been downloaded from svn (contrib). <br>To configure further parts of your ebus ecosystem, have a look at these templates and the <a href=https://wiki.fhem.de/wiki/EBUS-MQTT2">Wiki</a>.
attr DEVICE model eBus_daemon_splitter
setreading DEVICE attrTemplateVersion 20200522 or prior

Hier sind ja die bridgeRegexp (hc,mc,hwc....usw.) alle drin:
attr DEVICE bridgeRegexp (ebus..*?)/(bai|\d+|cc|e7f|ehp|f\d\d|hc|he.|hmu|hwc|mc|mc.\d|omu|omu.\d|pms|rcc|rcc.\d|sc|sdr_p|ui|uih|v\d\d|v81.\d|vd\d|vl\d|vr_\d\d|zeo)/.*:.* "$1_$2"\
(ebus..*?)/(global|broadcast|general|scan([^/]*))/.*:.* "$1"
Das habe ich auch als Standard genommen für meine 630.

Hier ist die originale hcmode.inc für die 630, wo Readings herkommen.
# type (r[1-9];w;u),circuit,name,[comment],[QQ],ZZ,PBSB,[ID],field1,part (m/s),datatypes/templates,divider/values,unit,comment
# HC Betriebsart,,,,,,,,,,,,,
*r,,,,,,"B504",,,,,,,
r,,DateTime,Datum Uhrzeit,,,,00,,,dcfstate;btime;bdate;temp2,,,
r,,Status16,Aussentemperatur,,,,16,,,temp,,,

# HC Betriebsart2,,,,,,,,,,,,,
*r,,,,,,"B511",,,,,,,
*uw,,,,,,"B510",,,,,,,
uw,,SetMode,Betriebsart,,,,00,,,hcmode,,,,flowtempdesired,,temp1,,,,hwctempdesired,,temp1,,,,hwcflowtempdesired,,temp0,,,,,,IGN:1,,,,disablehc,,BI0,,,,disablehwctapping,,BI1,,,,disablehwcload,,BI2,,,,,,IGN:1,,,,remoteControlHcPump,,BI0,,,,releaseBackup,,BI1,,,,releaseCooling,,BI2,,,,
r,,Status01,Vorlauftemperatur/Rücklauftemperatur/Aussentemperatur/WW Temperatur/Speichertemperatur/Pumpenstatus,,,,01,,,temp1;temp1;temp2;temp1;temp1;pumpstate,,,
r,,Status02,Betriebsart/Maximaltemperatur/ReglerCurrentTEMP/Maximaltemperatur/ReglerCurrentTemp,,,,02,,,hwcmode;temp0;temp1;temp0;temp1,,,
r,,Status,Status,,,,03,,,temp;press;press;hcmode2;HEX,,,

*uw,,,,,,"B512",,,,,,,
uw,,StatusCirPump,Status Zirkulationspumpe,,,,00,,,UCH,0=off;100=on,,
Theoretisch sollte der Status02 die Betriebsmodi (on,off,auto,eco,low) im Reading Status02_1_value liefern. Mehr kann ich dazu nicht sagen.
Bei mir ging das aber nicht, deswegen habe ich eine eigene hcmode.inc verfasst.
# type (r[1-9];w;u),circuit,name,[comment],[QQ],ZZ,PBSB,[ID],field1,part (m/s),datatypes/templates,divider/values,unit,comment
# HC Betriebsart,,,,,,,,,,,,,
*r,,,,,,"B504",,,,,,,
*w,,,,,,"B505",,,,,,,
r,,DateTime,Datum Uhrzeit,,,,00,,,dcfstate;btime;bdate;temp2,,,
r,,Mode,Room-Soll/Boiler-Betriebsart/Mixer-Betriebsart/Boilertyp/Temperatur/DayNight,,,,01,,,temp0;hcmode1;IGN:2;mcmode;hctype7;IGN;daynight,,,
r,,Status16,Aussentemperatur,,,,16,,,temp,,,
r,,Status,VL-Soll/Status/VL-Ist/Room-Soll,,,,0D,,,temp0;onoff;temp;temp0,,,
r,,Params,Raumsollwert/Absenksollwert/Heizkurve/HK1-Typ/AT-Abschaltgrenze/Pumpensperrzeit/HK1-VL-MinTemp/HK1-VL-MaxTemp/Max. Voraufheizung,,,,09,,,temp0;temp0;curve;hctype7;temp0;minutes0;temp0;temp0;hours12,,,
#r,,Status01,Vorlauftemperatur/Rücklauftemperatur/Aussentemperatur/WW Temperatur/Speichertemperatur/Pumpenstatus,,,,01,,,temp;temp1;temp2;temp1;temp1;pumpstate,,,
r,,Status02,Betriebsart/Maximaltemperatur/ReglerCurrentTEMP/Maximaltemperatur/ReglerCurrentTemp,,,,02,,,HEX;HEX;HEX;HEX;HEX;HEX;onoff,,,
w,,SetTempDesired,Solltemperatur setzen,,,,01,,,temp0,,,
w,,SetMode,Betriebsart,,,,02,,,hcmode3,,,
w,,SetFloorPavingDryingDay,Estrichtrocknungstag setzen,,,,03,,,days,,,
w,,SetFloorPavingDryingTemp,Estrichtrocknungstemperatur setzen,,,,04,,,temp0,,,
w,,party,Quick - Party,,,,05,,,onoff,,,
w,,load,Quick - WW Speicherladung,,,,06,,,onoff,,,
w,,save,Quick - Sparen bis,,,,07,,,TTH,,,
w,,SetType,Boilertyp setzen,,,,08,,,hctype,,,
w,,SetTempDesiredLow,Absenksollwert setzen,,,,0a,,,temp0,,,
w,,SetHeatingCurve,Heizkurve setzen,,,,0b,,,curve,,,
w,,SetShutdownTemp,Aussentemp. Abschaltgrenze setzen,,,,0c,,,temp0,,,
w,,SetPumpIdlePeriod,Pumpensperrzeit setzen,,,,0d,,,minutes0,,,
w,,SetFlowTempMin,Minimalen Vorlaufsollwert setzen,,,,0e,,,temp0,,,
w,,SetFlowTempMax,Maximalen Vorlaufsollwert setzen,,,,0f,,,temp0,,,
w,,SetMaxPreHeating,Max. Voraufheizung setzen,,,,10,,,hours12,,,
Hier wird im Reading Mode_02_value die Betriebsmodi gelesen und im SetMode gesetzt.
im Reading Mode_02_value wird die Raumtemperatur gelesen und mit SetTempDesired gesetzt.
Es werden wie hier im Beispiel:
r,,Mode,Room-Soll/Boiler-Betriebsart/Mixer-Betriebsart/Boilertyp/Temperatur/DayNight,,,,01,,,temp0;hcmode1;IGN:2;mcmode;hctype7;IGN;daynight,,,
10 Readings mit Namen: Mode_0_name ~ Mode_4_name (tem0,hcmode1...usw) und Mode_0_value ~ Mode_4_value (on,off,25...etc) erzeugt.
Und das wäre bei mir die ReadingList dafür:
ebusd/hc/Mode:.* { json2nameValue($EVENT, 'Mode_', $JSONMAP) }
Ich hoffe ich konnte da ein wenig Aufschluss geben.

ps.:Wie ich schon einmal sagte, man sollte andere ebusd Nutzer mit ins Boot holen.
Die verschiedenen Geräte (z.B.:350, 430, 700) mit deren Readings kenne ich alle auch nicht.
Weiss sonst auch nicht wie ich weiter helfen kann. ???

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 12474
  • eigentlich eher "user" wie "developer"
Antw:ebusd.mqtt2.template: Fragen, Anregungen
« Antwort #227 am: 16 November 2020, 14:47:26 »
Ähm, komme grade noch nicht mit. Das eBus_daemon_splitter-Template hatte ich damals mal so konzipiert, das scheint ja unverändert zu sein, und mir ist auch einigermaßen präsent, welche Devices es in etwa bei einer "klassischen Heizung" macht. Das "Zentraldevice" ist dann eigentlich nur eine Art "Statusdevice" für den daemon bzw. ESP, alle anderen Teilnehmer auf dem Bus sollten dann separate Devices ergeben.

Unklar ist mir, für was die Devices dann stehen, die "630" scheint irgendein Typ Brennwertkessel oä. zu sein. Soweit, so gut.

Was du jetzt gemacht hattest, war, das "bridgeing" zu "umgehen", indem du die readingList erweitert hattest, und alles in dem Statusdevice zu belassen. Kann man machen, für die Handhabung im Rahmen von Sprachsteuerung erscheint es mir einfacher, wenn jede Baugruppe eben ein eigenes Device ist.

Jetzt habe ich das Ding von neulich nochmal runtergestrippt, dass da nur noch das drin steht, was zu "hc" gehört - geht aber nur bei allem, was ich irgendwie halbwegs eindeutig zuordnen kann, nicht aber beim jsonMap, weil ich die Quelle der Readings nicht kenne.

Daher jetzt mal das als Zwischenergebnis (mit den weggelassenen homebridgeMappings, soweit nach den Tests möglich):
defmod MQTT2_ebusd_test MQTT2_DEVICE ebusd_hc
attr MQTT2_ebusd_test IODev ebusMQTT
attr MQTT2_ebusd_test alexaName EBUSHaZe
attr MQTT2_ebusd_test alias EBUSHaZe
attr MQTT2_ebusd_test autocreate 1
attr MQTT2_ebusd_test genericDeviceType thermostat
attr MQTT2_ebusd_test icon sani_boiler_temp
attr MQTT2_ebusd_test readingList
  ebusd/hc/Mode:.* { json2nameValue($EVENT, 'Mode_', $JSONMAP) }\
  ebusd/hc/Params:.* { json2nameValue($EVENT, 'Params_', $JSONMAP) }\
  ebusd/hc/Status:.* { json2nameValue($EVENT, 'Status_', $JSONMAP) }\
  ebusd/hc/Status16:.* { json2nameValue($EVENT, 'Status16_', $JSONMAP) }\
  ebusd/hc/Params/get:.* get
attr MQTT2_ebusd_test homebridgeMapping TargetHeatingCoolingState=mode,values=OFF:OFF;;HEAT:HEAT;;ECO:ECO;;AUTO:AUTO;;COOL:OFF\
history:size=1024

attr MQTT2_ebusd_test jsonMap Status16_temp_value:measured-temp Status_2_value:desired-temp Mode_hcmode1_value:mode Status01_0_value:_Vorlauf Status01_1_value:_Ruecklauf Status01_2_value:_Aussentemp Status01_3_value:_Warmwasser Status01_4_value:_WWSpeicher Status01_5_value:_Pumpenstatus Status02_0_value:_HWCMode Status02_1_value:_Maximaltemperatur Status02_2_value:_ReglerMaxTEMP Status02_3_value:_ReglerCurrentTemp

attr MQTT2_ebusd_test setList getKnown:noArg ebusd/list onlyknown\
  getAll:noArg ebusd/list\
  Params ebusd/hc/Params/get\
  mode:uzsuDropDown,ON,OFF,AUTO,ECO,LOW ebusd/hc/SetMode/set $EVTPART1\
  MinVLTemp:uzsuDropDown,15,16,17,18,19,20,21,22,23,24,25 ebusd/hc/SetFlowTempMin/set $EVTPART1\
  MaxVLTemp:uzsuDropDown,60,61,62,63,64,65,66,67,68,69,70 ebusd/hc/SetFlowTempMax/set $EVTPART1\
  AussenAusTemp:uzsuDropDown,15,16,17,18,19,20,21,22,23,24,25 ebusd/hc/SetShutdownTemp/set $EVTPART1\
  AbsenkTemp:uzsuDropDown,15,16,17,18,19,20,21,22,23,24,25 ebusd/hc/SetTempDesiredLow/set $EVTPART1\
  desired-temp:uzsuDropDown,-,20,21,22,23,24,25,26,27,28 ebus/hc/SetTempDesired/set $EVTPART1

Grundsätzlich gebe ich dir aber recht, hier müßten noch ein paar andere mit überlegen, was wie Sinn macht, v.a. welche, die grade dabei sind, in das Thema einzusteigen und es "einfach" haben wollen.

Interessehalber: Hast du je was mit Wochenplänen gemacht? Ich habe mir einen Teil der dummy-Geschichte mal angesehen, bin aber nicht so recht schlau draus geworden und hatte am Ende nur den Eindruck, dass das eigentlich so nicht richtig funktionieren kann, schon alleine, weil Daten zu einem Zeitpunkt verwendet werden, zu dem sie noch gar nicht (aktuell) geliefert worden sind. Aber evtl. verstehe ich da auch was falsch...
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, Twilight,  AttrTemplate => {mqtt2, mysensors, zwave}

Offline Reinhart

  • Hero Member
  • *****
  • Beiträge: 2105
Antw:ebusd.mqtt2.template: Fragen, Anregungen
« Antwort #228 am: 16 November 2020, 19:05:43 »
zur Info, die Geräte wie 350, 430, 470, 630 usw sind die Zusatz Regler (calormatic) für die Heizgeräte. An ihnen kann dann ein Außenfühler angeschlossen werden und ermöglich dann eine Witterungs geführte Regelung mit verschiedenen Heizkurven. Auch die Zeitprogramme werden da gespeichert und bieten noch jede Menge zusätzliche Datenpunkte. Diese Regler kommunizieren dann mit dem Masterdevice. Der Masterdevice muss nicht unbedingt einen eigenen Regler haben, der funktioniert auch so, eben ohne dem zusätzlichen Komfort wie Heizkurven und so.

D.h. ein und dasselbe Heizgerät kann verschiedene Regler angeschlossen haben, deshalb hat jede Calormatic unterschiedliche Datenpunkte, manche sind gleich, manche bei älteren gar nicht vorhanden. Das ist auch der Grund, warum es dazu jeweils ein eigenes Datenbankfile (csv) dazu gibt. Die Entwicklung von Vaillant geht ja ständig weiter und die csv wurden schon vor vielen Jahren erstellt, daher das Problem mit "neueren" Geräten. Daher wer ein solches Device das nicht von einer csv unterstützt wird, muss sich das zunächst selber erstellen. Das ist mit viel Aufwand und Revers Engineering verbunden und sehr zeitaufwändig.

Ich empfehle daher immer zuerst mit der Auswertung der Schnittstellen Daten zu beginnen und erst wenn alles läuft die Visualisierung mittels templates etc.

Im Endeffekt kann ein und dasselbe Heizgerät durch die vielen optionalen Regler von User zu User in Fhem immer anders aussehen. Die templates die du damals erstellt hast, waren auf Basis einer Calormatic 430.

Ich hoffe ich konnte etwas Licht in den Bezeichnungsdschungel bringen.

LG
FHEM auf Raspy4 mit Buster + SSD, mit FS20, Homematic, ESP8266, Sonoff, Electrodragon, eBus, RPi mit COC,NanoCUL, MapleCUL, HM-CFG-LAN Adapter, MQTT2, Alexa

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 12474
  • eigentlich eher "user" wie "developer"
Antw:ebusd.mqtt2.template: Fragen, Anregungen
« Antwort #229 am: 17 November 2020, 11:46:09 »
Danke, etwas heller ist es geworden.

dass das mit den csv-files jeweils eine spezielle Sache ist, war soweit klar, wobei mich etwas wundert, dass es keine wirkliche Standardisierung der "gewünschten" Benennungen (von mir aus je in de bzw. en) zu geben scheint.

Dass erst die Basis von dieser Seite aus passen sollte, ist eigentlich auch klar, wobei bei den jetzigen attrTemplates eben das Problem besteht, dass der "Kreis" zwischen FHEM-Anweisung und Ergebnis auf dem Gerät häufig (?) nicht geschlossen zu sein scheint. Also: "setze Wunschtemperatur am hc (?)" wird von FHEM aus auf den ebus geschrieben, es kommt aber "Temperatur xyz ist jetzt nn" (auf Anfrage?) zurück. Diesen Kreis sollte man mAn. (exemplarisch) schließen (unter Verwendung von "guten" Reading-Namen) und das Vorgehen auch im Wiki darstellen, bevor die nächste Welle von Anwendern dazukommt. Dazu könnte mAn. auch das manuelle at entfallen, weil man (zwischenzeitlich) dasselbe direkt am jeweiligen MQTT2-Teil-Gerät via periodicCmd einstellen könnte. Wäre mAn. im Ergebnis einfacher zu verstehen, weil man dann als Anwender immer nur den jeweiligen Teilaspekt ansieht.

Just my2ct.
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, Twilight,  AttrTemplate => {mqtt2, mysensors, zwave}

Offline mr_petz

  • Full Member
  • ***
  • Beiträge: 151
Antw:ebusd.mqtt2.template: Fragen, Anregungen
« Antwort #230 am: 17 November 2020, 18:30:19 »
...
dass das mit den csv-files jeweils eine spezielle Sache ist, war soweit klar, wobei mich etwas wundert, dass es keine wirkliche Standardisierung der "gewünschten" Benennungen (von mir aus je in de bzw. en) zu geben scheint.
...

Das hatte ich ja schon versucht zu vermitteln, dass es nicht ohne ist.
Es ist denke ich nicht in kurzer Zeit machbar.
Theoretisch sind es ja "nur" 3 Readings und 2 Set´s die man einheitlich gestalten müsste, aber eine Vielzahl an "Baugruppen"....
Bin aber gerne bereit zu helfen wie ich kann...
mfg

 

decade-submarginal