ebus Weishaupt MQTT im Zusammenspiel

[rob]

Ob man das "set <m2d> weekprofile ..." verwendet, oder einen der setter in weekprofile unterscheidet sich nur in der Syntax und (nur für Topics) in den Voraussetzungen in der Konfiguration - funktional passiert am Ende immer das gleiche: M2D fragt das angegebene Profil ab, wandelt es um und publisht...

Ich schreibe das ungern, weil ich mir vorkomme, wie ein ewiger Anfänger. Habe mir die Cref + Wiki zu WeekProfile angesehen und leider nicht verstanden, was ich tun muss.

Ist irgendwie OT, ich schreib mal dennoch was ich rausgezogen habe. Comandref sagt:

MQTT2_DEVICE (zusätzlicher Code erforderlich)
...
Hinweis: Geräte des Typs WeekdayTimer und MQTT2_DEVICE können nicht als 'Master-Gerät' verwendet werden.
...
   Wird kein 'Master-Geräte' angegeben, wird ein 'default' Profil angelegt.

Set
...
    Wird kein Gerät angegeben, wird das 'Master-Gerät' verwendet. 'Devices' ist eine kommagetrennte Auflistung von Geräten
...

?? Habs nicht verstanden. Als Master wollte ich schlicht das MQTT2-Device angeben. Das klappt natürlich nicht.
Im Wiki steht:

WeekdayTimer (ermöglicht seit 12/2019 indirekt die Steuerung von anderen Device-Typen wie Z-Wave, MQTT2_DEVICE bzw. MQTT_DEVICE, ZigBee, ...)

Aha, also muss man auch ein Weekdaytimer-Device haben? Wiki sagt:

Zusammenspiel mit weekprofile

Mit dem Modul weekprofile können Temperaturprofile erstellt werden und für verschiedene Anlässe vorbereitet werden. WeekdayTimer kann diese Temperaturlisten verwenden. Dazu ist Voraussetzung, dass in der Definition das weekprofile-Device angegeben wird. Einfaches Beispiel ohne $we-Berücksichtigung (myWeekprofiles ist der Name des weekprofile-Devices):
...
Dasselbe mit $we-Berücksichtigung:

define wd    Weekdaytimer  device weekprofile:myWeekprofiles:true

Nur wie verbinde ich das jetzt mit den MQTT2-Devices? Ich fand Dein Beispiel in diesem Fred hilfreich: https://forum.fhem.de/index.php?topic=122120.0
Schaut aber so aus, als würde erstmal alles im Zieldevice mit den beiden Profilen überschrieben werden. Ich möchte eher die schon vorhandenen Werte ins Weekprofile aus MQTT2 Device übernehmen, einzelne Einträge abändern und dann zum ebus schicken.

Den Code konnte ich nur per copy&paste übernehmen. Da wäre ich anhand Cref/Wiki nicht drauf gekommen, dass ich das so schreiben muss (heißt, ich müsste künftig immer die Profile mit so langen Klammer-Dingern abändern? - man kann das Widget anklicken, OK). Sicherheitshalber habe ich die Setter auf falsche geändert.

Schaut aktuell so aus:

Code Auswählen Erweitern


define MQTT2_ebusd_hc1_HP2 MQTT2_DEVICE
attr MQTT2_ebusd_hc1_HP2 userattr weekprofile
attr MQTT2_ebusd_hc1_HP2 model ebus_analyzeReadingList
attr MQTT2_ebusd_hc1_HP2 readingList ebusd/hc1/HP2.*:.* { FHEM::aTm2u_ebus::upd_day_profile( $NAME, $TOPIC, $EVENT, 'So|Mo|Di|Mi|Do|Fr|Sa' ) }
attr MQTT2_ebusd_hc1_HP2 room 12_Heizraum,MQTT2_DEVICE
attr MQTT2_ebusd_hc1_HP2 setList Sunday Hebusd/hc1/HP2.So/set\
Monday Hebusd/hc1/HP2.Mo/set\
Tuesday Hebusd/hc1/HP2.Di/set\
Wednesday Hebusd/hc1/HP2.Mi/set\
Thursday Hebusd/hc1/HP2.Do/set\
Friday Hebusd/hc1/HP2.Fr/set\
Saturday Hebusd/hc1/HP2.Sa/set
attr MQTT2_ebusd_hc1_HP2 weekprofile MQTT2_ebusd_hc1_HP2

define myWeekProfile weekprofile
attr myWeekProfile room 12_Heizraum

define myWeekdaytimer WeekdayTimer device weekprofile:myWeekprofile:true
attr myWeekdaytimer userattr weekprofile
attr myWeekdaytimer commandTemplate set $NAME  $EVENT
attr myWeekdaytimer room 12_Heizraum

setstate MQTT2_ebusd_hc1_HP2 2021-08-16 12:46:05 Friday 19:00;;23:00;;00:00;;00:00;;00:00;;00:00;;Mo-So
setstate MQTT2_ebusd_hc1_HP2 2021-10-18 07:23:59 IODev myMQTT_Server
setstate MQTT2_ebusd_hc1_HP2 2021-08-16 12:46:45 Monday 19:00;;23:00;;00:00;;00:00;;00:00;;00:00;;Mo-So
setstate MQTT2_ebusd_hc1_HP2 2021-08-16 12:47:01 Saturday 19:00;;23:00;;00:00;;00:00;;00:00;;00:00;;Mo-So
setstate MQTT2_ebusd_hc1_HP2 2021-08-16 12:47:20 Sunday 19:00;;23:00;;00:00;;00:00;;00:00;;00:00;;Mo-So
setstate MQTT2_ebusd_hc1_HP2 2021-08-16 12:45:45 Thursday 19:00;;23:00;;00:00;;00:00;;00:00;;00:00;;Mo-So
setstate MQTT2_ebusd_hc1_HP2 2021-08-16 12:45:25 Tuesday 19:00;;23:00;;00:00;;00:00;;00:00;;00:00;;Mo-So
setstate MQTT2_ebusd_hc1_HP2 2021-08-16 12:46:25 Wednesday 19:00;;23:00;;00:00;;00:00;;00:00;;00:00;;Mo-So
setstate MQTT2_ebusd_hc1_HP2 2021-08-06 12:25:27 associatedWith MQTT2_ebusd_hc1
setstate MQTT2_ebusd_hc1_HP2 2021-09-13 07:33:28 attrTemplateVersion 2021-09-13 07:33:28 $Id: 99_attrTmqtt2_ebus_Utils.pm 24899 2021-08-30 17:39:44Z Beta-User

setstate myWeekProfile created
setstate myWeekProfile 2021-10-20 08:24:30 profile_count 2
setstate myWeekProfile 2021-10-19 12:23:15 state created

Wie im Fred vorgeschlagen, schaue ich mir noch an wie das laut mosquitto_sub ankommt. Das Weekdaytimer-Device benötige ich dann also doch nicht?

Muss mich wohl noch deutlich mehr einlesen. Rund um den Ebus-Krams ist für mich wohl nix einfach 

[Beta-User]

Ich schreibe das ungern, weil ich mir vorkomme, wie ein ewiger Anfänger. Habe mir die Cref + Wiki zu WeekProfile angesehen und leider nicht verstanden, was ich tun muss.
[...]
Muss mich wohl noch deutlich mehr einlesen. Rund um den Ebus-Krams ist für mich wohl nix einfach 

Vorab: Aus der commandref zu weekprofile bin ich damals auch erst mal nicht schlau geworden - man braucht nach meiner Erfahrung einfach erst mal ein, zwei Profile, um zu verstehen, was es überhaupt tut bzw. tun kann. Hat man Hardware, die verwertbare Profile per default mitbringt (wie MAX- oder Homematic-Thermostate), gibt man einen als "Master" an. Aus dem erstellt dann weekprofile das erste "Muster-Profil", und dann ist auch das Web-Interface besser zu verstehen. Das fehlt aber bei M2D bzw. WDT, weil es keinen "standardisierten Rückweg" gibt bzw. ein WDT erst mal gar nichts weiß.

Das alles ist an sich schon komplex und hat (mal wieder) nichts mit ebus zu tun

Das Weekdaytimer-Device benötige ich dann also doch nicht?

Nein, wird nicht benötigt.

Für die Steuerung einer M2D-Instanz mit Hilfe von weekprofile gibt es schlicht und ergreifend zwei Wege:
Will man das Profil letztendlich autonom auf der eigentlichen Hardware laufen haben, muss es umgewandelt und an die Hardware verschickt werden. Das ergibt dann weekprofile+M2D.
Will (oder kann) man das nicht, braucht man eine Timer-Funktionalität, die auf FHEM läuft und die passenden Schaltbefehle dann zum entsprechenden Zeitpunkt (ggf. etwas verzögert) raushaut - ob das Zielgerät dann eine M2D-Instanz ist oder was ganz anderes, ist dabei völlig egal... (es wäre da aber z.B. möglich, zwischen Betriebsmodi der Heizung umzuschalten, also etwa "Tagmodus" bzw. "Absenkmodus").

Als Master wollte ich schlicht das MQTT2-Device angeben. Das klappt natürlich nicht.

Einen master braucht man nicht, s.o.

Nur wie verbinde ich das jetzt mit den MQTT2-Devices? Ich fand Dein Beispiel in diesem Fred hilfreich: https://forum.fhem.de/index.php?topic=122120.0

Danke, so war's gedacht. Habe noch den Hinweis ergänzt, dass man die weitere Konfiguration dann besser in FHEMWEB/weekprofile erledigt.

Schaut aber so aus, als würde erstmal alles im Zieldevice mit den beiden Profilen überschrieben werden.

Den Satz verstehe ich nicht: Es ist immer nur ein Profil aktiv, und man muss die Überragung aktiv anschubsen - entweder aus weekprofile heraus, oder über das M2D

Ich möchte eher die schon vorhandenen Werte ins Weekprofile aus MQTT2 Device übernehmen, einzelne Einträge abändern und dann zum ebus schicken.

Das wird nicht klappen, weil sonst zum einen "Rückwärtscode" für M2D bereit stehen müßte und zum anderen weekprofile eine Funktion haben müßte, das abzurufen. Das lohnt m.E. den Aufwand nicht, zumal ich gewisse Gefahren sehe, dass da was schief geht. Die diversen Profile sind ja dann auf Basis des Beispiels schnell erstellt bzw. angepaßt...

Du hast jetzt halt etwas das "Pech", dass die Doku noch ausbaufähig ist - aber immerhin scheint das Coding in FHEM schon mal soweit konsistent zu sein, dass was passendes rausgeht (auch wenn die Datenpunkte in der csv wohl noch angepaßt werden müssen).

[rob]

Vielen Dank für Deine abermals flinke Klarstellung (gib es zu, Du hast Dich geklont und bist deshalb so fix )

Nur wie verbinde ich das jetzt mit den MQTT2-Devices? Ich fand Dein Beispiel in diesem Fred hilfreich: https://forum.fhem.de/index.php?topic=122120.0

Den Satz verstehe ich nicht: Es ist immer nur ein Profil aktiv, und man muss die Überragung aktiv anschubsen - entweder aus weekprofile heraus, oder über das M2D

Sorry für die Verwirrung. Ich mein das so: im M2D steht drin, was aktuell in der Weishaupt gespeichert ist. z.B.

Code Auswählen Erweitern

setstate MQTT2_ebusd_hc1_HP2 2021-08-16 12:46:05 Friday 19:00;;23:00;;00:00;;00:00;;00:00;;00:00;;Mo-So

Erstelle ich nun ein Weekprofile und sage send_to_device, dann dürfte im M2D nicht mehr "19:00;;23:00;;00:00;;00:00;;00:00;;00:00;;Mo-So" stehen, sondern das aus dem neuen Profile.
Wenn die Werte in der Therme also bereits meinen Vortsellungen entsprechen, müsste ich halt initial darauf achten, dass ich genau dieses Profil im WeekProfile-Device auch anlege und eben nicht per copy+paste einfüge, weil sonst meine Werte in der Therme überschrieben werden - nämlich mit den Werten aus dem copy+paste.




OK, ich habe noch ein wenig herum gespielt.
a) im M2D einfach mal den vorhandenen Wert "bestätigt":

Code Auswählen Erweitern

set MQTT2_ebusd_hc1_HP2 Friday 19:00;23:00;00:00;00:00;00:00;00:00;Mo-So
Log:

Code Auswählen Erweitern

2021.10.20 11:41:20 3: MQTT2_DEVICE set MQTT2_ebusd_hc1_HP2 Friday 19:00;23:00;00:00;00:00;00:00;00:00;Mo-So
mosquitto_sub:

Code Auswählen Erweitern

Hebusd/hc1/HP2.Fr/set 19:00;23:00;00:00;00:00;00:00;00:00;Mo-So
Im myWeekProfile Device nun das Profil default leer (Profile count sagt noch =2; Profil mytest ist noch da).

ein

Code Auswählen Erweitern

get myWeekProfile profile_data default
ergibt: " "

ein Klick auf das Widget sagt:

Code Auswählen Erweitern


fhemweb_weekprofile.js line 559:
TypeError: widget.PROFILE[sday] is undefined

danach ist das Widget nicht mehr anklickbar, nur noch ein ° ist zu sehen; Taste F5 hilft

b) Testprofil an M2D senden
ich lasse folgendes los:

Code Auswählen Erweitern


set myWeekProfile send_to_device mytest MQTT2_ebusd_hc1_HP2


Web-UI sagt:

Code Auswählen Erweitern


Unknown argument weekprofile, choose one of Sunday Monday Tuesday Wednesday Thursday Friday Saturday attrTemplate


Log sagt:

Code Auswählen Erweitern


2021.10.20 11:52:18 1: myWeekProfile(Set): Unknown argument weekprofile, choose one of Sunday Monday Tuesday Wednesday Thursday Friday Saturday attrTemplate:?,General_Info,MQTT2_CLIENT_general_bridge,MQTT2_IO_ignoreRegexp_basic,MQTT2_IO_ignoreRegexp_tasmota,MQTT2_IO_ignoreRegexp_shelly,MQTT2_IO_ignoreRegexp_homeassistant,tasmota_basic,tasmota_basic_state_power1,tasmota_3channel_input_shelly_i3,shelly1,ESPurna_single_relay,eBus_daemon_splitter,eBus_analyzeReadingList,ebus_update_files_from_svn,eBus_bai_jsonMap_Status01,eBus_bai_readingsgroup_Status01_Balken,eBus_bai_readingsgroup_Status02,eBus_bai_readingsgroup_Status02_Balken,eBus_bai_readingsgroup_eBusCounter,eBus_bai_readingsgroup_eBusPumpe,eBus_Calormatic_readingsgroup_Set_Hcurve_Hotwater,eBus_Calormatic_TimeProgramm,eBus_4xx_devStateIcon_HeatCurve_HwcTemp,eBus_430_devStateIcon_Pump_Fan_HeatCurve_HwcTemp,eBus_bai_devStateIcon_Fan_Pump,eBus_bai_devStateIcon_Flow_Return_Hotwater_Temp,eBus_bai_devStateIcon_Waterpressure,eBus_bai_Status01+Status02_HWC,eBus_SetMode,eBus_Hc1HeatCurve+HwcTempDesired,eBus_bai_readingsgroup_Status01,ems-esp_heater_device,ems-esp_boiler,ems-esp_thermostat_read-only,ems-esp_thermostat_simple,ems-esp_thermostat_RC35_type,zigbee2mqtt_bridge,sonos2mqtt_bridge,sonos2mqtt_speaker,sonos2mqtt_bridge_comfort,roon,InstarCam,wled_controller,go_eCharger,go_eCharger_old,8channel_ethernet_board_split,8channel_ethernet_board_unified,6channel_ethernet_board_6input_split,6channel_ethernet_board_6input_unified,esp_milight_hub_bridge,OpenMQTTGateway_MCU,worx_landroid,wallpanel_app,weewx_weather_station,McLighting

Bei mosquitto_sub kommt so noch nichts an.

Also fehlt mir in beiden Fällen noch etwas. In den M2D stehen nur die Zeiten drin, keine Temperaturen. Im Weekprofile werden Temp. mitgegeben. Wird nicht obiges Problem sein, dürfte aber trotzdem ein weiteres Puzzlestück sein.
Das userattr "weekprofile" habe ich im M2D drin. Hast Du eine Idee?

[Beta-User]

...da fehlt am M2D ein setter für weekprofile (bitte ggf. in die commandref zu den ebus-utils sehen, nicht, dass sich die Syntax geändert hat; da steht auch was zum Zusammenhang zwischen Temperaturen und on/off-Zeiträumen):

Code Auswählen Erweitern

weekprofile { FHEM::aTm2u_ebus::send_weekprofile($NAME, $EVTPART1, $EVTPART2) }\ (Der "analyzer-Code" sollte den automatisch anlegen).

Und irgendwelche Aktionen am M2D haben keine Rückwirkungen auf die weekprofile-Instanz; da ist irgendwas anderes in die Binsen gegangen.

Den "Kreis" zwischen Reading setzen und Rückmeldung vom ebus-Dämon haben wir noch nicht geschlossen, kann gut sein, dass man da eine Abfrage hinterherschicken muss, um die erneuerten Profile zu erhalten.

[rob]

Zum fehlenden Setter
OK. Den Setter habe ich im Device in die setList eingetragen und mir auch die commandref wie empfohlen angeschaut. Ob sich die Syntax geändert hat, konnte ich nicht wirklich ausmachen. Schaut so aus, als würde das passen.

Kurzerhand wieder ein Profil "mytest" angelegt (per copy aus default). Inhalt:

Code Auswählen Erweitern


Mon 00:00-12:00 18.0 °C 12:00-16:00 23.5 °C 16:00-24:00 15.0 °C
Tue 00:00-12:00 18.0 °C 12:00-16:00 23.5 °C 16:00-24:00 15.0 °C
Wed 00:00-12:00 18.0 °C 12:00-16:00 23.5 °C 16:00-24:00 15.0 °C
Thu 00:00-12:00 18.0 °C 12:00-16:00 23.5 °C 16:00-24:00 15.0 °C
Fri 00:00-12:00 18.0 °C 12:00-16:00 23.5 °C 16:00-24:00 15.0 °C
Sat 00:00-11:30 18.0 °C 11:30-16:30 23.5 °C 16:30-24:00 20.0 °C
Sun 00:00-11:00 18.0 °C 11:00-15:00 23.5 °C 15:00-24:00 15.0 °C


Und so geschwind den Befehl abgesetzt:

Code Auswählen Erweitern

set myWeekProfile mytest MQTT2_ebusd_hc1_HP2

Laut moqsuitto_sub kommt das an:

Code Auswählen Erweitern


Hebusd/hc1/HP2.So/set 11:00;15:00;-,-;-,-;-,-;-,-;selected
Hebusd/hc1/HP2.Mo/set 12:00;16:00;-,-;-,-;-,-;-,-;Mo-Fr
Hebusd/hc1/HP2.Mo/set 12:00;16:00;-,-;-,-;-,-;-,-;Mo-Fr
Hebusd/hc1/HP2.Sa/set 11:30;16:30;16:30;24:00;-,-;-,-;selected


Und Log sagt:

Code Auswählen Erweitern


2021.10.27 06:56:50 3: MQTT2_DEVICE set MQTT2_ebusd_hc1_HP2 weekprofile myWeekProfile default:mytest
2021.10.27 06:56:50 3: MQTT2_DEVICE set MQTT2_ebusd_hc1_HP2 Sunday 11:00;15:00;-,-;-,-;-,-;-,-;selected
2021.10.27 06:56:50 3: MQTT2_DEVICE set MQTT2_ebusd_hc1_HP2 Monday 12:00;16:00;-,-;-,-;-,-;-,-;Mo-Fr
2021.10.27 06:56:50 3: MQTT2_DEVICE set MQTT2_ebusd_hc1_HP2 Monday 12:00;16:00;-,-;-,-;-,-;-,-;Mo-Fr
2021.10.27 06:56:50 3: MQTT2_DEVICE set MQTT2_ebusd_hc1_HP2 Saturday 11:30;16:30;16:30;24:00;-,-;-,-;selected


Danach ist das Profil "mytest" wieder leer. Grundsätzlich kommen Einträge also an. Nur komischerweise unvollständig - in obigem Profil sind ja alle Tage mit je drei Uhrzeiten belegt.


Zum Reading Lesen

Laut CSV werden von-bis-Wertepaare zum jeweiligen Heizprogramm und Tag erwartet; Bsp. im cli:

Code Auswählen Erweitern

ebusctl write -c hc1 HP2.Mo.2 "01:00;02:00"

Dazu passend habe ich eine simple getList erstellt:

Code Auswählen Erweitern


Mo_Range1 Monday ebusd/hc1/HP2.Mo.1/get
Mo_Range2 Monday ebusd/hc1/HP2.Mo.2/get
Mo_Range3 Monday ebusd/hc1/HP2.Mo.3/get
Di_Range1 Tuesday ebusd/hc1/HP2.Di.1/get
Di_Range2 Tuesday ebusd/hc1/HP2.Di.2/get
Di_Range3 Tuesday ebusd/hc1/HP2.Di.3/get
Mi_Range1 Thursday ebusd/hc1/HP2.Mi.1/get
Mi_Range2 Thursday ebusd/hc1/HP2.Mi.2/get
Mi_Range3 Thursday ebusd/hc1/HP2.Mi.3/get
Do_Range1 Wednesday ebusd/hc1/HP2.Do.1/get
Do_Range2 Wednesday ebusd/hc1/HP2.Do.2/get
Do_Range3 Wednesday ebusd/hc1/HP2.Do.3/get
Fr_Range1 Friday ebusd/hc1/HP2.Fr.1/get
Fr_Range2 Friday ebusd/hc1/HP2.Fr.2/get
Fr_Range3 Friday ebusd/hc1/HP2.Fr.3/get
Sa_Range1 Saturday ebusd/hc1/HP2.Sa.1/get
Sa_Range2 Saturay ebusd/hc1/HP2.Sa.2/get
Sa_Range3 Saturay ebusd/hc1/HP2.Sa.3/get
So_Range1 Sunday ebusd/hc1/HP2.So.1/get
So_Range2 Sunday ebusd/hc1/HP2.So.2/get
So_Range3 Sunday ebusd/hc1/HP2.So.3/get


Readings werden brav abgeholt. Leider bekomme ich immer einen Hinweis, wenn ich z.B. "get MQTT2_ebusd_hc1_HP2 Mi_Range1" absetze:

Code Auswählen Erweitern

Timeout reading answer for ebusd/hc1/HP2.Mi.1/get

Und moqsuitto_sub sagt:

Code Auswählen Erweitern


ebusd/hc1/HP2.Mi.1/get (null)
ebusd/hc1/HP2.Mi.1 {
     "End": {"value": "23:00"},
     "Start": {"value": "19:00"}}


An der Weishaupt lassen sich auch Tagebereiche bspw. Mo-Fr eingeben. Aber per aktuellem Setter klappt das noch nicht.
Müsste die setList nicht auch die einzelnen Wertepaare ansteuern analog dem getList-Beispiel? Wenn ich aktuell ein "set MQTT2_ebusd_hc1_HP2 Monday 19:00;23:00;00:00;00:00;00:00;00:00;Mo-So" absetze, welches sich aus der Vorbelegung der Readings ergibt, kommt via MQTT:

Code Auswählen Erweitern


ebusd/hc1/HP2.Mo/set 19:00;20:00;21:00;22:00;00:00;00:00;Mo-So


Damit wird jedoch nichts an der Weishaupt gesetzt. Setze ich jedoch explizit ab:

Code Auswählen Erweitern


set myMQTT_Server publish ebusd/hc1/HP2.Mo.1/set 19:00;20:00


kommt via MQTT:

Code Auswählen Erweitern


ebusd/hc1/HP2.Mo.1/set 19:00;20:00
ebusd/hc1/HP2.Mo.1 {
     "Start": {"value": "19:00"},
     "End": {"value": "20:00"}}
ebusd/hc1/HP2.Mo.1 {
     "Start": {"value": "19:00"},
     "End": {"value": "20:00"}}


Klappt grundsätzlich. Doof: an der Stelle wird schon wieder alles verdreht. Ein get Mo_Range1 holt das Wertepaar, aber es kam schon verdreht an:

Code Auswählen Erweitern


ebusd/hc1/HP2.Mo.1/get (null)
ebusd/hc1/HP2.Mo.1 {
     "End": {"value": "19:00"},
     "Start": {"value": "20:00"}}
ebusd/hc1/HP2.Mo.1 {
     "End": {"value": "19:00"},
     "Start": {"value": "20:00"}}


Da muss ich nochmal schauen, wo das nun wieder herkommt - hatte ich doch eigentl. gefixt 

[Beta-User]

Danach ist das Profil "mytest" wieder leer. Grundsätzlich kommen Einträge also an. Nur komischerweise unvollständig - in obigem Profil sind ja alle Tage mit je drei Uhrzeiten belegt.

Schon, aber Zeiträume mit <20°C (default) sind "off", und der ebus interessiert sich nur für die "on"-Zeiträume . Alles andere wird daher schlicht ignoriert. Das paßt also m.E. so.

An der Weishaupt lassen sich auch Tagebereiche bspw. Mo-Fr eingeben. Aber per aktuellem Setter klappt das noch nicht.

Das sind m.E. mehrere Themen:
- der Code ermittelt, welche Art Profil es ist. Sind an allen Tagen alle Schaltzeiten gleich, ist es "Mo-So". Das wird dann so in das Sendeformat übergeben, das Reinhart in seiner "dummy-Lösung" gewählt hatte. Die ebus-Seite sollte das also prinzipiell verstehen, wenn sowas via MQTT kommt, ich kann aber natürlich mangels anderweitiger Rückmeldung nicht sicher sagen, ob das bis dahin paßt oder noch buggy ist.
- Hier sieht es mir mehr danach aus, als hätte dann der ebus-Client-Code Schwierigkeiten, das (vermutlich mangels entsprechender Infos in den csv?) in passende ebus-Signale umzuwandeln.

- der timeout kommt vermutlich, weil es keinen rechtzeitigen update des Reading-Werts aus der getList gab, es müßte dafür einen passenden Eintrag in der readingList geben, der diese Zweige abboniert (mit dem entsprechenden myUtils-Code-Aufruf).