ebusd.mqtt2.template: Fragen, Anregungen

[Reinhart]

ich habe mir dein Problem kurz angesehen, es ist wie auch Beat-User schon festegestellt die Namenskonvention der eigentliche Übeltäter!

Code: [Auswählen]

w,,SetTempDesiredLow,Absenksollwert setzen,,,,0a,,,temp0,,,
w,,SetHeatingCurve,Heizkurve setzen,,,,0b,,,curve,,,du hast die Texte in deiner CSV alle mit "Set...." eingeleitet und die gibt es so nicht in den Templates. Ob Read oder Write hängt ja alleine vom Attribut "r,w,wi" ab. Die beste Möglichkeit du gleichst die Namen an die üblichen Calormatic Texte an.

Beispiel:
Hc1HeatCurve
HwcTempDesired

Code: [Auswählen]

name:E_03_eBus_4xx_devStateIcon_HeatCurve_HwcTemp
filter:TYPE=MQTT2_DEVICE
desc:Format ebus Statusmessages comming from broadcast
par:DEV_ID;name of the device ebus;{ AttrVal("DEVICE","readingList","") =~ m,[^/]+[/]([^/]+).*:, ? $1 : undef }
par:BASE_DEV;base topic set in config;{ AttrVal("DEVICE","readingList","") =~ m,ebusd/([^/]*)/, ? $1 : undef }
attr DEVICE setList Hc1HeatCurve_curve_value:uzsuDropDown,0.20,0.70,0.90,1.00,1.10,1.20,1.30,1.40,1.50,1.60,1.70 ebusd/BASE_DEV/Hc1HeatCurve/set $EVTPART1\
HwcTempDesired_temp1_value:uzsuDropDown,50.0,51.0,52.0,53.0,54.0,55.0,56.0,57.0,58.0,59.0,60.0 ebusd/BASE_DEV/HwcTempDesired/set $EVTPART1
attr DEVICE getList Hc1HeatCurve:noArg Hc1HeatCurve_curve_value ebusd/BASE_DEV/Hc1HeatCurve/get \
HwcTempDesired:noArg HwcTempDesired_temp1_value ebusd/BASE_DEV/HwcTempDesired/get
attr DEVICE devStateIcon {my $vC = ReadingsVal($name, "Hc1HeatCurve_curve_value", "10")*10; my $colCur = substr(Color::pahColor(5,10,15,$vC,0),0,6); my $iconCur = 'time_graph@'.$colCur; my $vH = ReadingsVal($name, "HwcTempDesired_temp1_value", "30"); my $colHot = substr(Color::pahColor(20,40,60,$vH,0),0,6); my $iconHot = 'sani_water_hot@'.$colHot; ; "<div style=\"text-align:right\" >  " . FW_makeImage("$iconCur",'file_unknown@grey') . "<br> " . FW_makeImage("$iconHot",'sani_water_hot@red') . "</div>"}
attr DEVICE webCmd Hc1HeatCurve_curve_value:HwcTempDesired_temp1_value
attr DEVICE webCmdLabel Heizkurve \
:Warmwasser
attr DEVICE room MQTT2_\DEVICE
attr DEVICE group eBus_Hcurve
attr DEVICE icon message_tendency_steady
attr DEVICE model E_03_eBus_4xx_HeatCurve_HwcTemphier ein Auszug aus dem "HeatCurve_HwcTemp" Template und hier wird mit dem Standardnamen "Hc1HeatCurve" und "HwcTempDesired" gerarbeitet. Sie sie dir einfach in der 15.430.csv an. Wenn du die Namen angepasst hast, dann sollten auch zum Großteil die (ebus) Templates funktionieren.
Du kannst aber auch ganz leicht die Templates anpassen, wie du dir leichter tust, nur ich würde auf einheitliche Namen plädieren.

LG

[mr_petz]

Ich habe mal beispielsweise in den default-csv´s geschaut:
 

• bei den Raumreglern vr400,450 ist der Betriebsmodus: Hc1OPMode
• bei dem Raumregler 350 ist der Betriebsmodus: OperatingMode
• bei meiner VR630 Heizungsregelung ist der Betriebsmodus: Status02

Mit Betriebsmodus ist on,off,auto etc gemeint...

Es wird also nicht einfach alles einheitlich zu gestalten.
Da müssten wir mal ne Umfrage starten wer welches Vaillant Gerät hat und welche Modi´s mit welcher default-Namensgebung.

[mr_petz]

ich habe mir dein Problem kurz angesehen, es ist wie auch Beat-User schon festegestellt die Namenskonvention der eigentliche Übeltäter!

Hi Reinhart,
Ich habe damit kein Problem und weiss das man es anpassen kann.
Vergleiche mal bitte die VR630 csv´s und hcmode.inc mit den Raumreglern, da wirst du schon Unterschiede in der Namensgebung sehen wie gerade geschrieben.
Ich habe auch geschrieben, das meine hcmode.inc nur so mit der VR630 spielt (*r,,,,,,"B504",,,,,,,
*w,,,,,,"B505",,,,,,,). Also habe ich schonmal 2 Namen für Hc1OPMode...
Einmal zum lesen und einmal zum schreiben...
Die Namen sind frei vergeben von mir.

ps. es soll nicht böse klingen...
mfg mr_petz

[Beta-User]

@Reinhart: Das löst aber erst Teil 1 des Problems.

Eigentlich sollten wir die templates dann nochmal so überarbeiten, dass eben nicht "HwcTempDesired" der Reading-Name ist, sondern "desired-temp"; dann sollte das auch mit der Sprachsteuerung klappen ("Helferlein, setze die Warmwassertemperatur auf 55 Grad"). Man muß dann aber eben für verschiedene Baugruppen wirklich getrennte Devices bauen. (Oder man macht eben ein passendes mapping, das ginge auch, ist aber mMn. eher die zweitbeste Lösung...)
Wirf mal einen kurzen Blick in die ems-esp-Thermostat-Templates, v.a. auf den ems-esp_thermostat_simple ab hier: https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/lib/AttrTemplate/mqtt2.template#L3039 dann wird es evtl. klarer (das ems-esp-Konstrukt ist mMn. 1:1 vergleichbar zu ebus).

Vielleicht noch eine Sache, die ich in der Zwischenzeit gelernt habe: Das Verwalten von Temperaturlisten geht TYPE-übergreifend und sehr komfortabel über weekprofile, sowohl, was die Einrichtung angeht wie auch das Anwenden von Änderungen (z.B. Wechsel von "normalem Tagesprogramm" auf "Ferien" oder "Urlaub", "Kurzarbeit",...; eventuell wäre es den Versuch wert, auch dafür eine Schnittstelle zu basteln (der ganze Mechanismus mit den x dummy-Devices usw. kommt mir reichlich "von Hand" vor). Kommt aber darauf an, was so eine Therme überhaupt wie oft verarbeiten kann (EEPROM-wearout).
Da ich sowas schon für WeekdayTimer gemacht habe, sollte es "möglich" sein...

Weiter würde ich bei der Gelegenheit nochmal anregen, die "get"-Anfragen über ein periodicCmd im MQTT2-Device selbst zu lösen und nicht über ein (händisch zu pflegendes) at. Eigentlich müsste man für jede Baugruppe ja wissen, was man abfragen kann und sollte?

Es wird also nicht einfach alles einheitlich zu gestalten.
Da müssten wir mal ne Umfrage starten wer welches Vaillant Gerät hat und welche Modi´s mit welcher default-Namensgebung.

Würde vorschlagen, dass jemand john30 ins Boot holt und er das entscheidet und ggf. auch auf github vereinheitlicht - eventuell kann ja auch "ein advanced User" eine Art Guideline erstellen (ähnlich https://wiki.fhem.de/wiki/DevelopmentGuidelinesAV bzw. https://wiki.fhem.de/wiki/DevelopmentGuidelinesReadings, nur eben auf der ebus-Ebene).
Ansonsten darfst dann eben du entscheiden, wie es gemacht werden soll - "jemand" muß es eben tun (sonst mach ich es, und dann kommt vermutlich was unsinniges raus...).

Auf der FHEM-Seite haben wir übrigens nicht wirklich ein Problem, wir können auch mit unterschiedlichen "Namen" (eigentlich: Topics oder JSON-Keys) für Senden und Empfangen leben, aber wir sollten es dann eben via Readingbenennung/jsonMap so machen, dass es a) einheitlich wird und b) möglichst intuitiv in die allgemeine Landschaft passt...

Klarer?

[mr_petz]

@Reinhart
hier noch ein Vergleich von 350, 430 und 700 der unterschiedlichen Raumsolltemperatur-Namen:
350 = ActualRoomTempDesired
430 = ActualRoomTempDesiredHc1
700 = z1ActualRoomTempDesired (hier geht es ja nach RaumZonen)

@Beta-User
Also bei mehreren Heizkreisen Hc1,Hc2,Hc3 und Raumthermostaten/zonen müsste man sich was einfallen lassen wie man das mappt oder mehrere templates erstellen...

ich denke so müsste das alexa-mapping aussehen und wäre mit andere Thermostat-Devices konform:

Code: [Auswählen]

TargetTemperature=desired-temp,minValue=5,maxValue=35,minStep=0.5,nocache=1
CurrentTemperature=measured-temp,nocache=1
TargetHeatingCoolingState=heatingState,values=OFF:off;HEAT:on;ECO:eco;AUTO:auto;COOL:low,cmds=OFF:Hc1Mode+off;HEAT:Hc1Mode+on;ECO:Hc1mode+eco;AUTO:Hc1Mode+auto;COOL:Hc1Mode+low,valid=OFF;HEAT;ECO;AUTO;COOL
CurrentHeatingCoolingState=heatingState,values=OFF:off;HEAT:on;ECO:eco;AUTO:auto;COOL:low,valud=OFF
history:size=1024
die values aufgeschlüsselt als Beispiel:

desired-temp = Bsp. setList: Hc1RoomSoll:uzsuDropDown,18,19,20,21,22,23,24,25,26,27,28 ebusd/hc/Hc1ActualRoomTempDesired/set $EVTPART1
heatingState = Hc1OPMode --Reading
measured-temp = Hc1RoomTemp --Reading
Hc1Mode (von mir vergeben) = Bsp. setList: Hc1Mode:uzsuDropDown,on,off,auto,eco,low ebusd/hc/Hc1OPMode/set $EVTPART1

schwarz markierte sind die Namen von den *.csv´s und den *.inc die man festlegen könnte....
Das wäre jetzt erstmal so mein Gedankenanstoß wenn ich jetzt nix verwurschtelt habe.

[Beta-User]

Na ja, wenn es mehrere Heizkreise gibt (die gesondert geregelt werden können sollen), sollten die jeweils in ein eigenes Device, ganz klar - die templates würden sich dann wohl auch nur in der setList und im jsonMapping unterscheiden - ganz so wie bei mehrkanaigen Tasmotas - das sollte kein Problem sein, notfalls könnte man auch für "seltene" eines ohne besondere eigene "Intelligenz" erstellen und die relevanten Angaben vom User abfragen.

Der "Witz" mit "desired-temp" sollte eigentlich sein, dass man es im mapping gar nicht braucht, weil es automatisch richtig gemacht wird - evtl. ausgenommen "ungewöhnliche Wertebereiche". Und alles, was man nicht braucht, sollte man (im Mapping) weglassen - so jedenfalls meine Erfahrung bisher mit dem Thema Sprachsteuerung...

Und sind nicht Hc1OPMode und Hc1Mode identisch (nur eben in Sende- und Empfangsrichtung unterschiedlich benannt) und sollten eigentlich "heatingState" heißen?

Und: könnte man dann auf das Mapping auch an der Stelle nicht ganz verzichten (ggf. müßte man die "Modes" vor dem Versenden in der setList übersetzen (Perl)...)?

Ansonsten sähé das dann Minimalistisch so aus:

Code: [Auswählen]

TargetHeatingCoolingState=heatingState,values=OFF:off;HEAT:on;ECO:eco;AUTO:auto;COOL:low,cmds=OFF:Mode+off;HEAT:Mode+on;ECO:mode+eco;AUTO:Mode+auto;COOL:Mode+low,valid=OFF;HEAT;ECO;AUTO;COOL
CurrentHeatingCoolingState=heatingState,values=OFF:off;HEAT:on;ECO:eco;AUTO:auto;COOL:low,valud=OFF
history:size=1024
Hoffe, das wird jetzt langsam klarer, in welche Richtung ich da denke?

[mr_petz]

Na ja, wenn es mehrere Heizkreise gibt (die gesondert geregelt werden können sollen), sollten die jeweils in ein eigenes Device, ganz klar - die templates würden sich dann wohl auch nur in der setList und im jsonMapping unterscheiden - ganz so wie bei mehrkanaigen Tasmotas - das sollte kein Problem sein, notfalls könnte man auch für "seltene" eines ohne besondere eigene "Intelligenz" erstellen und die relevanten Angaben vom User abfragen.

klingt gut.

Der "Witz" mit "desired-temp" sollte eigentlich sein, dass man es im mapping gar nicht braucht, weil es automatisch richtig gemacht wird - evtl. ausgenommen "ungewöhnliche Wertebereiche". Und alles, was man nicht braucht, sollte man (im Mapping) weglassen - so jedenfalls meine Erfahrung bisher mit dem Thema Sprachsteuerung...

wusste ich noch nicht, das das auch ohne mapping geht...

Und sind nicht Hc1OPMode und Hc1Mode identisch (nur eben in Sende- und Empfangsrichtung unterschiedlich benannt) und sollten eigentlich "heatingState" heißen?

Hc1Mode =die setlist vom Hc1OPMode
Hc1OPMode = das Reading
beide können gleich sein (r/w) in der csv, können aber auch unterschiedliche Speicheradressen haben wie in meinem Fall und dadurch 2 Namen w=SetMode r=Mode_hcmode1 haben.

Code: [Auswählen]

# 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",,,,,,,
w,,SetMode,Betriebsart,,,,02,,,hcmode3,,,
r,,Mode,Room-Soll/Boiler-Betriebsart/Mixer-Betriebsart/Boilertyp/Temperatur/DayNight,,,,01,,,temp0;hcmode1;IGN:2;mcmode;hctype7;IGN;daynight,,,

Hoffe, das wird jetzt langsam klarer, in welche Richtung ich da denke?

ja klingt gut die Richtung

[Beta-User]

Hmm, irgendwie müssen wir mal konkreter anfangen...

Wenn du (@mr_petz) mir ein RAW-list von dem Ding postest, kann ich mal versuchen, die "Kreise" konkret zu schließen. Die Variablen auf csv/topic-Ebene kann man dann ja später noch tauschen - scheint ja eh' das Grundproblem zu sein, dass man da ggf. was "dynamisiertes" als template braucht. (Das wird Erklärungsbedarf generieren, die User sind es (noch) nicht gewohnt, Fragen der attrTemplate zu beantworten...)

OT zu dem "möglichst ohne"-mapping-Thema: Es gibt dazu ein paar threads, auf die Schnelle ist evtl. der hier aufschlussreich: https://forum.fhem.de/index.php/topic,108080.0.html

[mr_petz]

OK, ich habe mal ne Nacht darüber geschlafen.
Ich bin zur Erkenntnis gekommen, dass wenn wir wie du sagst "csv/topic-Ebene dynamisch gestalten" ein doch größeres Problem mit den bestehenden ebusd-Nutzern haben.
Wenn die Namen der values in den csv umbenannt/vereinheitlicht werden und ein update der configs (csv) rauskommt , folgt daraus, dass die bestehenden Readings bzw. Set-Befehle wo am Ende noch notifys, doifs oder scripte dran hängen alle nicht mehr greifen und vom User angepasst werden müssten. Oder sehe ich das falsch?
Ich kann mir gut vorstellen, dass da nicht viele erfreut sein werden...

Wenn du (@mr_petz) mir ein RAW-list von dem Ding postest, kann ich mal versuchen, die "Kreise" konkret zu schließen.

Vielleicht sollte da lieber @Reinhart oder ein anderer ebus-Nutzer sein RAW-list posten da er ja die default Sachen drin hat und bei mir ist eher vieles Benutzerdefiniert.
Oder sag konkreter was du wissen/erklärt haben möchtest.
Für den ebusd mqtt2 gibt es ja auch schon templates von euch:
https://wiki.fhem.de/wiki/EBUS-MQTT2#Anwendung_der_Templates
wie es auch hier im Thread zu lesen ist.
Kannst du da nicht auch schon was raus lesen um die Kreise zu schließen oder willst du jetzt ausschließlich meinen Fall zur Grundlage nehmen?
Ich mache hier aber natürlich weiter mit...

[Beta-User]

Spricht irgendwas dagegen, dass du einfach ein RAW von dem Device postest, das du auszugsweise bereits hier gepostet hattest?

Wie gesagt: das ganze ggf. durch Abfragen beim User konfigurierbar zu machen wäre nicht das Problem, wir sollten aber erst den POC fertig machen, und dazu brauche man halt einen Prototypen, selbst, wenn der unter manchen Gesichtspunkten nicht optimal ist...

[mr_petz]

OK. Ich kann erst heute Abend ein RAW posten. bin noch @work...

[mr_petz]

RAW

Code: [Auswählen]

defmod MQTT2_ebusd MQTT2_DEVICE ebusd
attr MQTT2_ebusd IODev ebusMQTT
attr MQTT2_ebusd alexaName Heizung
attr MQTT2_ebusd alias Heizung
attr MQTT2_ebusd autocreate 1
attr MQTT2_ebusd bridgeRegexp (ebus.)[^/]*/(bai|broadcast)/.*:.* "$1_bai"\
  (ebus.)[^/]*/([\d]+)/.*:.* "$1_$2"\
  (ebus.)[^/]*[/][^b][a-zA-Z]+[/].*:.* "$1"
attr MQTT2_ebusd devStateIcon 1.true:it_net 1.false:it_net@red  2.true:lan_rs485 2.false:lan_rs485@red
attr MQTT2_ebusd devStateStyle style="text-align:right"
attr MQTT2_ebusd disable 0
attr MQTT2_ebusd event-on-change-reading .*
attr MQTT2_ebusd genericDeviceType thermostat
attr MQTT2_ebusd homebridgeMapping CurrentTemperature=Status16_temp_value,nocache=1\
TargetHeatingCoolingState=heatingState,values=OFF:OFF;;HEAT:HEAT;;ECO:ECO;;AUTO:AUTO;;COOL:OFF,cmds=OFF:Heizmodus+off;;HEAT:Heizmodus+on;;ECO:Heizmodus+eco;;AUTO:Heizmodus+auto;;COOL:Heizmodus+off,valid=OFF;;HEAT;;ECO;;AUTO;;COOL\
CurrentHeatingCoolingState=heatingState,values=HEAT:HEAT;;ECO:ECO;;AUTO:AUTO;;OFF:OFF;;COOL:OFF,valud=OFF\
TargetTemperature=Status_2_value,minValue=0,maxValue=28,minStep=0.5,nocache=1\
StatusActive=signal,valueOn=true,valueOff=false\
history:size=1024
attr MQTT2_ebusd icon sani_boiler_temp
attr MQTT2_ebusd jsonMap 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 model E_00_eBus_daemon_splitter
attr MQTT2_ebusd readingList ebusd/global/uptime:.* uptime\
ebusd/broadcast/datetime:.* { json2nameValue($EVENT, 'datetime_', $JSONMAP) }\
ebusd/scan\.15/:.* { json2nameValue($EVENT, 'scan.15_', $JSONMAP) }\
ebusd/scan\.23/:.* { json2nameValue($EVENT, 'scan.23_', $JSONMAP) }\
ebusd/scan\.25/:.* { json2nameValue($EVENT, 'scan.25_', $JSONMAP) }\
ebusd/scan\.26/:.* { json2nameValue($EVENT, 'scan.26_', $JSONMAP) }\
ebusd/scan\.35/:.* { json2nameValue($EVENT, 'scan.35_', $JSONMAP) }\
ebusd/scan\.35/id:.* { json2nameValue($EVENT, 'id_', $JSONMAP) }\
ebusd/scan\.44/:.* { json2nameValue($EVENT, 'scan.44_', $JSONMAP) }\
ebusd/scan\.50/:.* { json2nameValue($EVENT, 'scan.50_', $JSONMAP) }\
ebusd/scan\.51/:.* { json2nameValue($EVENT, 'scan.51_', $JSONMAP) }\
ebusd/scan\.84/:.* { json2nameValue($EVENT, 'scan.84_', $JSONMAP) }\
ebusd/global/version:.* version\
ebusd/global/running:.* running\
ebusd/global/updatecheck:.* updatecheck\
ebusd/global/signal:.* signal\
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/ui/OutsideTempOffset:.* { json2nameValue($EVENT, 'OutsideTempOffset_', $JSONMAP) }\
ebusd/hc/Params/get:.* get\
ebusd/ui/OutsideTempOffset/get:.* get
attr MQTT2_ebusd room Heizung
attr MQTT2_ebusd setList getKnown:noArg ebusd/list onlyknown\
getAll:noArg ebusd/list\
Params ebusd/hc/Params/get\
OTempO ebusd/ui/OutsideTempOffset/get\
Heizmodus:uzsuDropDown,on,off,auto,eco,low ebusd/hc/SetMode/set $EVTPART1\
Heizkurve:uzsuDropDown,0.20,0.50,0.70,0.80,0.90,1.00,1.10,1.20,1.30,1.40,1.50,1.60,1.70,1.80,1.90,2.00 ebusd/hc/SetHeatingCurve/set $EVTPART1\
ATKorrektur:uzsuDropDown,-3.00,-2.50,-2.00,-1.50,-1.00,-0.50,0.00,0.50,1.00,1.50,2.00,2.50,3.00 ebusd/ui/OutsideTempOffset/set $EVTPART1\
RoomTemp:uzsuDropDown,18,19,20,21,22,23,24,25,26,27,28 ebusd/hc/SetTempDesired/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
attr MQTT2_ebusd stateFormat Status: \
1:running\
Signal: \
2:signal\
<br>Uptime: formatedUptime
attr MQTT2_ebusd userReadings tempState { if (ReadingsVal($name,"signal","true") eq "true"){"-25"}},\
tempState2 { if (ReadingsVal($name,"signal","true") eq "true"){"0"}},\
heatingState { if (ReadingsVal($name,"Mode_hcmode1_value","-") eq "off"){"OFF"} elsif (ReadingsVal($name,"Mode_hcmode1_value","-") eq "on"){"HEAT"} elsif (ReadingsVal($name,"Mode_hcmode1_value","auto") eq "auto"){"AUTO"} elsif (ReadingsVal($name,"Mode_hcmode1_value","-") eq "low"){"COOL"} else {"ECO"}},\
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 MQTT2_ebusd verbose 0

setstate MQTT2_ebusd Status: \
1:true\
Signal: \
2:true\
<br>Uptime: 0 005 13:51
setstate MQTT2_ebusd 2020-11-06 19:08:52 Mode_daynight_value day
setstate MQTT2_ebusd 2020-11-06 19:08:52 Mode_hcmode1_value auto
setstate MQTT2_ebusd 2020-11-06 19:08:52 Mode_hctype7_value hc789
setstate MQTT2_ebusd 2020-11-06 19:08:52 Mode_mcmode_value off
setstate MQTT2_ebusd 2020-11-06 19:08:52 Mode_temp0_value 26
setstate MQTT2_ebusd 2020-11-06 19:04:42 OutsideTempOffset_temp_value -2.00
setstate MQTT2_ebusd 2020-11-06 19:04:42 Params_0_name temp0
setstate MQTT2_ebusd 2020-11-06 19:04:42 Params_0_value 26
setstate MQTT2_ebusd 2020-11-06 19:04:42 Params_1_name temp0
setstate MQTT2_ebusd 2020-11-06 19:04:42 Params_1_value 16
setstate MQTT2_ebusd 2020-11-06 19:04:42 Params_2_name curve
setstate MQTT2_ebusd 2020-11-06 19:04:42 Params_2_value 1.20
setstate MQTT2_ebusd 2020-11-06 19:04:42 Params_3_name hctype7
setstate MQTT2_ebusd 2020-11-06 19:04:42 Params_3_value hc789
setstate MQTT2_ebusd 2020-11-06 19:04:42 Params_4_name temp0
setstate MQTT2_ebusd 2020-11-06 19:04:42 Params_4_value 19
setstate MQTT2_ebusd 2020-11-06 19:04:42 Params_5_name minutes0
setstate MQTT2_ebusd 2020-11-06 19:04:42 Params_5_value 0
setstate MQTT2_ebusd 2020-11-06 19:04:42 Params_6_name temp0
setstate MQTT2_ebusd 2020-11-06 19:04:42 Params_6_value 20
setstate MQTT2_ebusd 2020-11-06 19:04:42 Params_7_name temp0
setstate MQTT2_ebusd 2020-11-06 19:04:42 Params_7_value 69
setstate MQTT2_ebusd 2020-11-06 19:04:42 Params_8_name hours12
setstate MQTT2_ebusd 2020-11-06 19:04:42 Params_8_value 0
setstate MQTT2_ebusd 2020-11-06 19:08:18 Status16_temp_value 6.00
setstate MQTT2_ebusd 2020-11-06 19:08:52 Status_0_name temp0
setstate MQTT2_ebusd 2020-11-06 19:08:52 Status_0_value 68
setstate MQTT2_ebusd 2020-11-06 19:08:52 Status_1_name onoff
setstate MQTT2_ebusd 2020-11-06 19:08:52 Status_1_value off
setstate MQTT2_ebusd 2020-11-06 19:08:52 Status_2_name temp
setstate MQTT2_ebusd 2020-11-06 19:08:52 Status_2_value 48.81
setstate MQTT2_ebusd 2020-11-06 19:08:52 Status_3_name temp0
setstate MQTT2_ebusd 2020-11-06 19:08:52 Status_3_value 26
setstate MQTT2_ebusd 2020-04-23 19:10:39 ValvePosition 0
setstate MQTT2_ebusd 2020-04-10 16:23:10 associatedWith MQTT2_ebusd
setstate MQTT2_ebusd 2020-11-06 19:08:17 datetime_date_value 06.11.2020
setstate MQTT2_ebusd 2020-11-06 19:08:17 datetime_outsidetemp_value 6.000
setstate MQTT2_ebusd 2020-11-06 19:08:17 datetime_time_value 19:08:01
setstate MQTT2_ebusd 2020-04-23 19:10:39 desired-temp auto
setstate MQTT2_ebusd 2020-11-06 19:08:48 formatedUptime 0 005 13:51
setstate MQTT2_ebusd 2020-11-06 19:04:37 get
setstate MQTT2_ebusd 2020-11-06 19:08:52 heatingState AUTO
setstate MQTT2_ebusd 2020-07-17 09:04:06 id_counter_value 005395
setstate MQTT2_ebusd 2020-07-17 09:04:06 id_prefix_value 21
setstate MQTT2_ebusd 2020-07-17 09:04:06 id_product_value 0020040079
setstate MQTT2_ebusd 2020-07-17 09:04:06 id_suffix_value N2
setstate MQTT2_ebusd 2020-07-17 09:04:06 id_supplier_value 0907
setstate MQTT2_ebusd 2020-07-17 09:04:06 id_week_value 44
setstate MQTT2_ebusd 2020-07-17 09:04:06 id_year_value 11
setstate MQTT2_ebusd 2020-04-23 19:10:39 measured-temp 21
setstate MQTT2_ebusd 2020-11-01 09:13:47 running true
setstate MQTT2_ebusd 2020-07-17 09:03:49 scan.15_HW_value 6201
setstate MQTT2_ebusd 2020-07-17 09:03:49 scan.15_ID_value UI
setstate MQTT2_ebusd 2020-07-17 09:03:49 scan.15_MF_value Vaillant
setstate MQTT2_ebusd 2020-07-17 09:03:49 scan.15_SW_value 0231
setstate MQTT2_ebusd 2020-07-17 09:03:57 scan.23_HW_value 6301
setstate MQTT2_ebusd 2020-07-17 09:03:57 scan.23_ID_value VR630
setstate MQTT2_ebusd 2020-07-17 09:03:57 scan.23_MF_value Vaillant
setstate MQTT2_ebusd 2020-07-17 09:03:57 scan.23_SW_value 0306
setstate MQTT2_ebusd 2020-07-17 09:03:58 scan.25_HW_value 6301
setstate MQTT2_ebusd 2020-07-17 09:03:58 scan.25_ID_value VR630
setstate MQTT2_ebusd 2020-07-17 09:03:58 scan.25_MF_value Vaillant
setstate MQTT2_ebusd 2020-07-17 09:03:58 scan.25_SW_value 0306
setstate MQTT2_ebusd 2020-08-10 10:26:12 scan.26_HW_value 6301
setstate MQTT2_ebusd 2020-08-10 10:26:12 scan.26_ID_value VR630
setstate MQTT2_ebusd 2020-08-10 10:26:12 scan.26_MF_value Vaillant
setstate MQTT2_ebusd 2020-08-10 10:26:12 scan.26_SW_value 0306
setstate MQTT2_ebusd 2020-08-10 10:26:42 scan.35_HW_value 6201
setstate MQTT2_ebusd 2020-08-10 10:26:42 scan.35_ID_value RC C
setstate MQTT2_ebusd 2020-08-10 10:26:42 scan.35_MF_value Vaillant
setstate MQTT2_ebusd 2020-08-10 10:26:42 scan.35_SW_value 0501
setstate MQTT2_ebusd 2020-07-17 09:04:29 scan.44_HW_value 6301
setstate MQTT2_ebusd 2020-07-17 09:04:29 scan.44_ID_value VR630
setstate MQTT2_ebusd 2020-07-17 09:04:29 scan.44_MF_value Vaillant
setstate MQTT2_ebusd 2020-07-17 09:04:29 scan.44_SW_value 0306
setstate MQTT2_ebusd 2020-07-17 09:04:35 scan.50_HW_value 6301
setstate MQTT2_ebusd 2020-07-17 09:04:35 scan.50_ID_value VR630
setstate MQTT2_ebusd 2020-07-17 09:04:35 scan.50_MF_value Vaillant
setstate MQTT2_ebusd 2020-07-17 09:04:35 scan.50_SW_value 0306
setstate MQTT2_ebusd 2020-07-17 09:04:36 scan.51_HW_value 6301
setstate MQTT2_ebusd 2020-07-17 09:04:36 scan.51_ID_value VR630
setstate MQTT2_ebusd 2020-07-17 09:04:36 scan.51_MF_value Vaillant
setstate MQTT2_ebusd 2020-07-17 09:04:36 scan.51_SW_value 0306
setstate MQTT2_ebusd 2020-07-17 09:05:12 scan.84_HW_value 6301
setstate MQTT2_ebusd 2020-07-17 09:05:12 scan.84_ID_value VR630
setstate MQTT2_ebusd 2020-07-17 09:05:12 scan.84_MF_value Vaillant
setstate MQTT2_ebusd 2020-07-17 09:05:12 scan.84_SW_value 0306
setstate MQTT2_ebusd 2020-11-01 09:13:47 signal true
setstate MQTT2_ebusd 2020-11-06 19:04:37 state OTempO
setstate MQTT2_ebusd 2020-11-06 19:08:52 tempState -25
setstate MQTT2_ebusd 2020-11-06 19:08:52 tempState2 0
setstate MQTT2_ebusd 2020-11-01 09:13:47 updatecheck "revision v3.4 available, broadcast.csv: newer version available, vaillant/15.ui.csv: different version available, vaillant/23.vr630.cc.csv: newer version available, vaillant/25.vr630.hwc.csv: different version available, vaillant/26.vr630.hc.csv: different version available, vaillant/50.vr630.mc.csv: newer version available, vaillant/51.vr630.mc.3.csv: newer version available, vaillant/errors.inc: newer version available, vaillant/hcmode.inc: different version available, vaillant/hwcmode.inc: different version available"
setstate MQTT2_ebusd 2020-11-06 19:08:48 uptime 481896
setstate MQTT2_ebusd 2020-11-01 09:13:46 version "ebusd 3.4.v3.3-51-g57eae05"


[Beta-User]

Umbenanntes Testdevice:

Code: [Auswählen]

defmod MQTT2_ebusd_test MQTT2_DEVICE ebusd
attr MQTT2_ebusd_test IODev ebusMQTT
attr MQTT2_ebusd_test alexaName Heizung
attr MQTT2_ebusd_test alias Heizung
attr MQTT2_ebusd_test autocreate 1
attr MQTT2_ebusd_test devStateIcon 1.true:it_net 1.false:it_net@red  2.true:lan_rs485 2.false:lan_rs485@red
attr MQTT2_ebusd_test devStateStyle style="text-align:right"
attr MQTT2_ebusd_test disable 0
attr MQTT2_ebusd_test event-on-change-reading .*
attr MQTT2_ebusd_test genericDeviceType thermostat
attr MQTT2_ebusd_test homebridgeMapping StatusActive=signal,valueOn=true,valueOff=false\
history:size=1024
attr MQTT2_ebusd_test icon sani_boiler_temp
attr MQTT2_ebusd_test jsonMap Status16_temp_value:measured-temp Status_2_value:desired-temp Mode_hcmode1_value:heatingState 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 model E_00_eBus_daemon_splitter
attr MQTT2_ebusd_test readingList ebusd/global/uptime:.* uptime\
ebusd/broadcast/datetime:.* { json2nameValue($EVENT, 'datetime_', $JSONMAP) }\
ebusd/scan\.15/:.* { json2nameValue($EVENT, 'scan.15_', $JSONMAP) }\
ebusd/scan\.23/:.* { json2nameValue($EVENT, 'scan.23_', $JSONMAP) }\
ebusd/scan\.25/:.* { json2nameValue($EVENT, 'scan.25_', $JSONMAP) }\
ebusd/scan\.26/:.* { json2nameValue($EVENT, 'scan.26_', $JSONMAP) }\
ebusd/scan\.35/:.* { json2nameValue($EVENT, 'scan.35_', $JSONMAP) }\
ebusd/scan\.35/id:.* { json2nameValue($EVENT, 'id_', $JSONMAP) }\
ebusd/scan\.44/:.* { json2nameValue($EVENT, 'scan.44_', $JSONMAP) }\
ebusd/scan\.50/:.* { json2nameValue($EVENT, 'scan.50_', $JSONMAP) }\
ebusd/scan\.51/:.* { json2nameValue($EVENT, 'scan.51_', $JSONMAP) }\
ebusd/scan\.84/:.* { json2nameValue($EVENT, 'scan.84_', $JSONMAP) }\
ebusd/global/version:.* version\
ebusd/global/running:.* running\
ebusd/global/updatecheck:.* updatecheck\
ebusd/global/signal:.* signal\
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/ui/OutsideTempOffset:.* { json2nameValue($EVENT, 'OutsideTempOffset_', $JSONMAP) }\
ebusd/hc/Params/get:.* get\
ebusd/ui/OutsideTempOffset/get:.* get
attr MQTT2_ebusd_test room Heizung
attr MQTT2_ebusd_test setList getKnown:noArg ebusd/list onlyknown\
getAll:noArg ebusd/list\
Params ebusd/hc/Params/get\
OTempO ebusd/ui/OutsideTempOffset/get\
heatingState:uzsuDropDown,ON,OFF,AUTO,ECO,LOW ebusd/hc/SetMode/set $EVTPART1\
Heizkurve:uzsuDropDown,0.20,0.50,0.70,0.80,0.90,1.00,1.10,1.20,1.30,1.40,1.50,1.60,1.70,1.80,1.90,2.00 ebusd/hc/SetHeatingCurve/set $EVTPART1\
ATKorrektur:uzsuDropDown,-3.00,-2.50,-2.00,-1.50,-1.00,-0.50,0.00,0.50,1.00,1.50,2.00,2.50,3.00 ebusd/ui/OutsideTempOffset/set $EVTPART1\
RoomTemp:uzsuDropDown,18,19,20,21,22,23,24,25,26,27,28 ebusd/hc/SetTempDesired/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
attr MQTT2_ebusd_test stateFormat Status: \
1:running\
Signal: \
2:signal\
<br>Uptime: formatedUptime
attr MQTT2_ebusd_test userReadings tempState:signal.* { if (ReadingsVal($name,"signal","true") eq "true"){"-25"}},\
tempState2:signal.* { if (ReadingsVal($name,"signal","true") eq "true"){"0"}},\
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 MQTT2_ebusd_test verbose 0

Hoffe, das klappt so, Teile sind einfach geraten und die Zuordnungen dürfen gerne verbessert werden...

Die bridgeRegexp habe ich weggelassen, die ist ja an dem anderen schon vorhanden. Aber bei der Gelegenheit eine Frage: Warum hast du das so geändert, dass nicht jede Baugruppe ihr eigenes Device erhält?
Meine Gedanken damals bei der Entwicklung war, dass es tendenziell sinnvoll ist, "handhabbare" Teile zu haben, wenn sie funktional für was bestimmtes zuständig sind. Falls diese Überlegung in der Praxis nicht trägt, können wir gerne versuchen, das entsprechend anzupassen, aber gerade dann, wenn man unterschiedliche Teilaspekte "betrachten" will (und z.B. per Sprachsteuerung ansprechen), ist es m.E. einfacher, wenn man aufspaltet.

[mr_petz]

Warum hast du das so geändert, dass nicht jede Baugruppe ihr eigenes Device erhält?

Was meinst du mit Baugruppen?
Und soll ich dein Device jetzt einfach einfügen? Stört das nicht wenn Heizung als alias 2 mal in fhem angelegt wird? Oder soll ich mein Heizungsdevice daweile disablen? Auch schon wegen Alexa-APP...
Will nur sicher gehen.

Edit:
Ich weiss jetzt glaube was du meinst mit Baugruppen (denke ich).
die hc, ui usw.. ?
Die gibt es bei mir auch als seperate Devices, da habe ich mir nur die Readinglists geholt die ich auch nur verwende und damit Zentralisiert.

[Beta-User]

alias kannst du löschen, ansonsten sollte sich das nicht in die Quere kommen.

Und "Baugruppe" ist genau das, was jeweils einen eigenen "Topic"-Abschnitt hat - meine Vermutung ist, dass sich dahinter eben jeweils eine Art logischer "Funktionseinheit" oder so verbirgt - aber wie gesagt, ich habe das nur vor langer Zeit mal remote an einem "fremden" Bus so "festgelegt" und bin für Verbesserungsvorschläge offen, auch, was das "wording" angeht...