ebusd.mqtt2.template: Fragen, Anregungen

Begonnen von TomLee, 28 Februar 2019, 17:04:14

Vorheriges Thema - Nächstes Thema

Beta-User

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-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

mr_petz

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. ???

Beta-User

Ä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-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Reinhart

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 Bullseye + SSD, Homematic, ESP8266, ESP32, Sonoff, eBus, NanoCUL, MapleCUL, , MQTT2, Alexa

Beta-User

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-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

mr_petz

Zitat von: Beta-User am 17 November 2020, 11:46:09
...
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

Beta-User

Zitat von: Beta-User am 16 November 2020, 14:47:26
Interessehalber: Hast du je was mit Wochenplänen gemacht? [...]

Zitat von: Beta-User am 17 November 2020, 11:46:09
[...] 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.

Da hier keiner den Ball so richtig aufnehmen wollte die Zwischeninfo, dass wir just diese Themen grade an einem "normalen" Heizungsgerät durchspielen: Antw:Zigbee2MQTT - Template für Thermostat.

Dass das ganze - hier wie dort - "nicht ohne ist", ist klar, aber ggf. werden meine möglicherweise etwas kryptischen Ausführungen hier in diesem Thread mit dem etwas weniger komplexen Device dort (und dem MQTT - workshop, der aber zugegebenermaßen auch ziemlich schnell eher "für Fortgeschrittene" ist) etwas besser verständlich und konkreter...

Jedenfalls gäbe es dort zum einen Beispielcode, der das Temperaturlisten-Array separat extrahiert und myUtils-Code, der aus/mit weekprofile dann "andere" Temperaturlisten-Formate erzeugt und direkt auch versenden könnte. Sollte beides eigentlich nicht allzu schwer auf den hiesigen Anwendungsfall anpassbar sein, im Kern ist es jetzt eigentlich nur noch "einfaches"  Textpuzzeln mit Arrays...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

Nachdem an anderer Stelle Fragen aufgetaucht sind:
Zitat von: beaune am 14 Juni 2021, 10:48:56
Bei den Templates ist mir nicht ganz klar, wo eigentlich die aktuellen offiziell abgelegt sind. Ich hab zwei Versionen: eine, wo die Template-Namen ein vorangestelltes E_ haben und eine ohne. Eigentlich hätte ich erwartet, dass ich die versionierten Templates im fhem-Repo finde, aber da sind sie anscheinend nicht. Was ist denn jetzt aktuell?
Es gibt das "Basis-attrTemplate" zu ebus, das ist in mqtt2.template zu finden, zur Verfolgung von Änderungen kann man https://svn.fhem.de/trac/log/trunk/fhem/FHEM/lib/AttrTemplate/mqtt2.template verwenden, eine Versionsinfo wird (aktuell) durch
setreading DEVICE attrTemplateVersion 20200824
hinterlegt, was in etwa bedeutet: Das Basistemplate wurde zuletzt am 24.08.2020 verändert.

Die weiteren attrTemplate sind im svn in https://svn.fhem.de/trac/browser/trunk/fhem/contrib/AttrTemplate/mqtt2.ebus.template zu finden; das ist afaik im Prinzip der letzte Stand von Reinhart. "Im Prinzip" deswegen, weil zwar inhaltlich nichts geändert wurde, aber z.B. die Sortierung nicht mehr über den Namen erfolgen muss, sondern über einen internen Kenner. Wer also noch E_.*-attrTemplates zur Auswahl hat, hat eventuell eine (doppelte) ältere Version, aber vermutlich jedenfalls nichts neueres.

Zitat von: Reinhart am 16 Juni 2021, 10:06:10
da bei den Templates im allgemeinen kein oder wenig Interesse herrscht habe ich da auch nicht mehr weiter gemacht. Es ist auch schwer die Templates für alle Geräte einheitlich zu gestallten.
Bin nach wie vor nicht überzeugt, dass es dafür keinen Bedarf gibt. Insbesondere _glaube_ ich, dass der Kreis bei manchen Readings von FHEM (set-Anweisung) nach eBus nach FHEM (jsonMap) nicht sauber geschlossen ist und es sinnvoll wäre, ein paar (allgemeingültige?) Beispiele zu zeigen. Das Know-How betr. MQTT2_DEVICE dürfte zwischenzeitlich bei einigen Usern da sein, um zumindest RAW-Definitionen zu zeigen, die das "gut" machen.

Zitat
Ich fänd auch eine Übersicht gut, was es alles an relevanten Templates gibt.
Eigentlich sollten die beim Hauptdevice in der dropdown-Auswahl zu finden sein und alle beieinanderstehen. Es gibt auch einen Wiki-Artikel, der die Visualisierungen (via readingsGroup) zeigt.

Zitat
Da gibt's zwar den Mechanismus mit dem automatischen Nachladen, aber das find ich irgendwie zu spooky und würd das eigentlich viel lieber selbst beeinflussen können, welche Tempates ich haben möchte. Aber dafür bräuchte man eben ein Repo o.ä., damit man sieht was es gibt, und auch Änderungen nachvollziehen kann. Gibt's da was?
Ich kann nicht nachvollziehen, wieso das "spooky" sein soll, erneuerten Content aus dem svn zu ziehen, sei es via update oder via Svn_GetFile().
Wer skeptisch ist, kann zum einen vorab die Änderungen ansehen, und zum anderen sind "heruntergeladene attrTemplate" noch lange keine "angewendeten attrTemplate": Das ganze wirkt sich erst aus, wenn man sie anwendet. Und auch zu dem Zeitpunkt sieht man dann wieder (in FHEMWEB), was passieren wird, wenn man das via dropdown auswählt...
Wer das dann nicht "gut" findet, kann ja immer noch "händisches Cherrypicking" betreiben und die Attribute händisch so setzen, wie er es für richtig findet.

(Klar ist das ganze keine Garantie, dass nicht auch mal was schiefgeht, aber so sind wenigstens alle (potentiell) auf demselben Stand und man kann sich wechselseitig helfen...)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

rob

Hallo Leute.

Ich habe endlich meinen ebus3-Adapter produktiv nehmen können. Docker läuft mit CSV-Configs für Weishaupt (aus Joek3rs Repo), MQTT-Devices sind gem. WIKI angelegt und das ebus-splitter-Template erfolgreich angewandt. Jetzt würde ich gern ein paar Verständnisfragen platzieren:

WIKI sagt:
Zitat...D.h. in der Templateliste das gewünschte auswählen (hier MQTT2_ebusd_bai)...
Woher weiß ich, welches Template ich benötige/ mir wünsche?

Sind die "ebus-Spezifische weitere Templates" vom Hersteller abhängig? BAI und Co. klingen irgendwie nach Vaillant, bei mir hab ich soetwas anscheinend nicht. Passt eines der Templates auch für Weishaupt (welches)?

Kann ich einfach Templates setzen und gefahrlos notfalls wieder zurückrollen und dann das nächste Templ. testen?

Sorry für die doofen Fragen. Taste mich langsam ran und ebus scheint imho komplex (viele Themen zum Einlesen).

Vielen Dank und beste Grüße
rob

PS: Zwei Kleinigkeiten sind mir nebenher aufgefallen. Im Wiki steht:
ZitatDie eBus Templates beginnen alle mit E....
--> aktuell fangen sie nun mit "eBus..." an. Ungefragt möchte ich das nicht einfach im WIKI ändern.
Bei einem Templatenamen hat sich vorne ein "e" verdünnisiert --> "Bus_bai_readingsgroup_eBusCounter"

Beta-User

Zitat von: rob am 12 Juli 2021, 23:13:14
Woher weiß ich, welches Template ich benötige/ mir wünsche?
Optimalerweise sollte sich das aus der "desc" ergeben (=angezeigter Infotext, der unter dem setter angezeigt wird, wenn man was aus dem dropdown auswählt bzw. "?" "anwendet"), und/oder aus dem, was man an Code vorab angezeigt bekommt, den das attrTemplate ausführt.

Wie an anderer Stelle schon geschrieben: M.E. entsprechen die eBus-templates nicht mehr in allen Punkten dem Stand der Technik bzw. der Kenntnisse und Möglichkeiten, was sich z.B. auch bei dem Benennungsthema niederschlägt: Ganz zu Beginn war (nur) der Name des jweiligen attrTemplate für die Sortierung innerhalb der Liste relevant, weswegen eben alle  "E_irgendwas" benannt waren. Als "order" eingeführt wurde, habe ich die Namen vereinfacht, da ist mir das "e" vermutlich verlustig gegangen...

Ein update - auch im Wiki - könnte daher nicht schaden; heute würde man vermutlich schreiben, dass die zusätzlichen Templates dann runtergeladen werden/sichtbar werden, wenn das Basistemplate (splitter) ausgeführt wurde und dann unterhalb des "splitters" zu finden sind (so sollte es jedenfalls sein...).

ZitatKann ich einfach Templates setzen und gefahrlos notfalls wieder zurückrollen und dann das nächste Templ. testen?
Im Prinzip: ja.
Ich empfehle in solchen Fällen, die von autocreate erstellte RAW-Definition wegzusichern, dann kann man immer zurück auf den Ausgangszustand. Etwas schwieriger ist es, wenn - wie teilsweise hier - zusätzliche Geräte erstellt werden. Dann muss man ggf. manuell diese zusätzlichen Geräte löschen, wenn sie einem nicht gefallen bzw. nicht das tun, was man erwartet.

Zitat
Sind die "ebus-Spezifische weitere Templates" vom Hersteller abhängig? BAI und Co. klingen irgendwie nach Vaillant, bei mir hab ich soetwas anscheinend nicht. Passt eines der Templates auch für Weishaupt (welches)?
Kann ich ohne RAW-Defs nicht sagen, und vermutlich würde es auch nicht schaden, die Topic/payload-Kombinationen zu kennen (dann kann ich nachvollziehen, warum welche Readings gebaut werden und ggf. auch manches nachstellen).

Zitat
Sorry für die doofen Fragen. Taste mich langsam ran und ebus scheint imho komplex (viele Themen zum Einlesen).
M. E. sind die Fragen nicht doof, und auch nach meinem Eindruck ist die Auswertung der Daten teilweise ziemlich tricky, nicht zuletzt, weil verschiedene Hersteller dahinter stehen und/oder teilweise die csv-Dateien nicht "standardisiert" sind.

Wir können da gerne einen Anlauf nehmen, das für "Weishaupt" gemeinsam so aufzubereiten, dass es dem aktuellen Stand der Dinge entspricht ;) .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

rob

@Beta-User: Vielen Dank für Deine flinke Antwort.
Mir geht es auch nicht drum etwaige "Schwachstellen" aufzudecken, sondern zunächst halbwegs das Machbare zu verstehen. Wenn nebenher andere User profitieren können, umso besser.
Daten usw. stelle ich gerne zur Verfügung. Passt das denn so Weishaupt-spezifisch hierher oder sollte ich das besser in einem eigenen Fred abtrennen? Ähnliches wurde ja schon im ebus-Fred angeregt. Hab ich auch kein Problem mit.

Vielen Dank und beste Grüße
rob


Beta-User

Zitat von: rob am 13 Juli 2021, 09:38:23[...] zunächst halbwegs das Machbare zu verstehen. Wenn nebenher andere User profitieren können, umso besser.
Erfahrungsgemäß bedingen sich beide Dinge ;) .

ZitatDaten usw. stelle ich gerne zur Verfügung. Passt das denn so Weishaupt-spezifisch hierher oder sollte ich das besser in einem eigenen Fred abtrennen? Ähnliches wurde ja schon im ebus-Fred angeregt. Hab ich auch kein Problem mit.
Ob es ggf. "spezifisch" ist, kann ich ohne Daten nicht beurteilen, und ich würde auch meine Hilfe gerne möglichst auf die Funktionalität beschränken, die MQTT2_DEVICE bietet.

Dem Bauchgefühl nach würde ich dazu tendieren, einen neuen Thread im MQTT-Bereich auzumachen (der von hier aus verlinkt werden darf!), und dort mit "eBus + Weishaupt auf der grünen Wiese" zu starten. Ist dann ggf. für Nachahmer leichter und "am Stück" nachzuvollziehen, wie das im Einzelnen aufeinander aufbaut, und ggf. klinkt sich dann auch @beaune mit ein (siehe z.B. die Detailfrage hier: https://forum.fhem.de/index.php/topic,122029.msg1166237.html#msg1166237).

Als vorbereitende Lektüre würde ich empfehlen, den "MQTT-Workshop" zumindest mal zu überfliegen. Ist sehr "harter Stoff", und du musst auch nicht alles verstehen, aber der gibt einen halbwegs vollständigen Überblick über alle möglichen Lösungen, die mit und um MQTT2_DEVICE bisher entwickelt worden sind, so dass es gut wäre, du hättest zumindest einen ersten Eindruck davon, was man alles machen kann...
Vielleicht auch ein guter Einstieg, wie man z.B. JSON "einfängt": https://forum.fhem.de/index.php/topic,117405.0.html
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

rob

habe ich gemacht. In diesem Thread geht es mit dem konkreten Thema weiter: https://forum.fhem.de/index.php/topic,122048.0.html

VG
rob

karlos964

Hallo Ihr Profis,

ich habe ein riesen Problem:
1. wo befinden sich die Template Dateien?
2. wo finde ich eine Vorlage für die Vaillant 630/4 ?
3. kommt eigentlich bei mir was an , ich bekomme immer nur nichts sagende Meldungen wie:
ebusctl info
version: ebusd 3.0.595c7c0
update check: version 22.3 available, broadcast.csv: newer version available
signal: acquired
symbol rate: 50
max symbol rate: 125


oder:
busctl scan result
-bash: line 72: pi@raspberrypi:~$: command not found
/opt/fhem/FHEM/lib/AttrTemplate$ ebusctl scan result
08;Vaillant;BAI00;0703;7401
23;Vaillant;SOLSY;0500;6301
25;Vaillant;SOLSY;0500;6301
26;Vaillant;SOLSY;0500;6301
50;Vaillant;SOLSY;0500;6301
ec;Vaillant;SOLSY;0500;6301


Ich habe es mittlerweile mit : ECMD und MQTT Server versucht, GAEBUS lässt sich erst gar nicht installieren. ( Modul kann nicht gefunden werden. Datei GAEBUS ist aber an der richtigen Stelle ( laut Bescheibung ) vorhanden.
Nachdem ich nun gefühlte 500 Seiten gelesen habe, mir der Kopf qualmt und ich nach jeder Info mehr Fragen als vorher habe bin ich nicht sicher ob ich da jemals was sinnvolles herausbekomme.
Muss ich HTML, Perl, Linux und .... beherrschen um zu vertehen, was die "Vorlagen" mit nicht zusammengehörenden Codeschnipseln mir sagen?
Leider finde ich auch keine sinnvolle Auflistung der Befehle für die Abfrage des ebus. Somit weiss ich nicht, wie ich herausbekomme, ob da nun was kommt, ob das mit der 630 überhaupt geht, noch habe ich irgendeinen Wert erhalten, nur MAsken , wo immer 00 drin steht. das Protokoll weist keinen Fehler auf:
2022.07.12 09:32:31 1: Including fhem.cfg
2022.07.12 09:32:31 3: telnetPort: port 7072 opened
2022.07.12 09:32:32 3: WEB: port 8083 opened
2022.07.12 09:32:32 3: WEBphone: port 8084 opened
2022.07.12 09:32:32 3: WEBtablet: port 8085 opened
2022.07.12 09:32:32 2: eventTypes: loaded 46 lines from ./log/eventTypes.txt
2022.07.12 09:32:32 3: tablet_ui: new ext defined infix:ftui/: dir:./www/tablet:
2022.07.12 09:32:32 3: Registering HTTPSRV tablet_ui for URL /ftui   and assigned link ftui/ ...
2022.07.12 09:32:32 3: Opening EBUS device 192.168.146.10:8888
2022.07.12 09:32:32 3: EBUS device opened
2022.07.12 09:32:32 3: ebusMQTT: port 1883 opened
2022.07.12 09:32:32 3: Can't create ./www/deviceimages
2022.07.12 09:32:32 3: Can't create ./www/deviceimages/mqtt2
2022.07.12 09:32:32 1: Including ./log/fhem.save
2022.07.12 09:32:32 0: Featurelevel: 6.1
2022.07.12 09:32:32 0: Server started with 32 defined entities (fhem.pl:26115/2022-06-04 perl:5.028001 os:linux user:fhem pid:31103)


Was kann ich machen um das zu verstehen?
Grüsse
KarLOs


Beta-User

Hmm, für mich als nicht-Ebus-Nutzer sieht das so aus, als würdest du die csv-Dateien, die man für eine sinnvolle Kommunikation zwischen den Heizgeräten selbst und ebusd benötigt, in einen Topf werfen mit mqtt2-attrTemplate, das als Hilfestellung für die Auswertung der von ebusd gesendeten Daten an FHEM (via MQTT) gedacht sind.

Demnach wärst du hier m.E. mit dem Anliegen falsch (ich kann aber auch falsch liegen).

Jedenfalls: Bitte hier keine Diskussion zur ebus-Konfiguration mit Hilfe von csv-Dateien. (Wer weiterhelfen kann, kann selbstredend gerne einen link dahin posten, wo dazu was zu finden ist!)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files