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