Modul weekprofile + FHEMWEB widget

[freda]

Hallo,

ich wollte mal nachfragen, ob evtl. Interesse da ist, HMCCU in das Modul weekprofile zu integrieren. Ich weiß, dass hier bereits ein paar Anfragen dazu gab und dass Risiko HMCCU nicht einsetzt. Ich könnte aber auf jeden Fall auf der Seite von HMCCU unterstützen. Bin von CUL_HM auf HMCCU wegen HMIP umgestiegen und vermisse die Funktion für Temperaturlisten. Hab allerdings die Temperaturlisten über hminfo gepflegt und nicht über weekprofile, Da hminfo komplett auf CUL_HM setzt sehe ich bei weekprofile mehr Chancen, dass HMCCU in das Modul integriert wird.

Beschreibung wie die Temperaturen in HMCCU geändert werden können:
Die Devices HM-CC-RT-DN werden im Gegensatz zu CUL_HM nur mit einem Kanal in FHEM angelegt. Das spielt aber keine Rolle.
Das Device hat für jeden Wochentag 13+13 Variablen, mit deren Hilfe die Zeiten / Temparturen gesteuert werden können

Beispiel der Variablen für Montag
R-ENDTIME_MONDAY_1 bis R-ENDTIME_MONDAY_13 (Zeiten)
R-TEMPERATURE_MONDAY_1 bis R-TEMPERATURE_MONDAY_13 (Temperaturen

Die Wochentage sind in Englisch komplett ausgeschrieben.

Gesetz können die Variablen in FHEM wie folgt
set %DEVICE% config ENDTIME_MONDAY_1=600 (Berechnung: Industriezeit  10,00  * 60 = 600 oder Industriezeit 10,50 (10:30 Uhr) * 60 = 630)
set %DEVICE% config TEMPERATURE_MONDAY_1=18.0  (Angabe immer im Format XX.X)   

Damit das Tagesprofil vollständig ist, muss die letzte Uhrzeit auf 24:00 Uhr, also 1440 gesetzt sein. Je nachdem wieviele gesteuerte Zeiten gewünscht sind, kann es die Variable ENDTIME_wochentag_X sein.

Was ich nicht im Einsatz habe, sind Wandthermostate. Wahrscheinlich ist es aber hier die Steuerung ähnlich aufgebaut.
Ansonsten wüsste ich nicht, was man noch beachten muss.

Vielleicht könnte die Logik in zukünftigen Releases integriert werden. Oder ist es bereits im Modul integriert und ich habe in den letzten Beiträgen was überlesen?

Viele Grüße

[clumsy]

Hallo, erst mal besten Dank (ja etwas spät ich weiss) für das Modul, ist ja super praktisch!

Ich weiss zwar dass im Wiki steht, dass wenn man Topics verwendet (mach ich) und man beim auslesen (get ...) kein Topic angibt, immer das "default" genommen wird. Wäre es aber nicht logischer (und allenfalls auch sinnvoller) dann anstatt "default" das "active_tpoic" zu nehmen?

Wenn man sich "programmtechnisch" oder in einem anderen Modul aktiv ein Profil abholen will muss man das entweder immer selbst erst auslesen, damit man das richitge profile erhält, oder eben wissen was es so gibt und dann das Topic richtig angeben. .

Dabei ist mir auch noch aufgefallen, dass mit "set <weekprofile> active_topic" irgendwas angegeben werden kann, d.h. es wird nicht überprüft ob es das Topic auch wirklich gibt, ist das bewusst so?

Ansonsten echt klasse Modul und v.a. sehr praktisch bei über 20 verteilten Thermostaten

Vielen Dank und beste Grüsse aus der Schweiz!

STefan

[freda]

Hallo,

hab gerade das Coding im Modul angeschaut. HMCCUDEV ist bereits für das Device HmIP-eTRV-2 integriert. Auf den ersten Blick sind nur die Readings anders benannt. Wäre es aufwändig die alte Devices auch zu integrieren`

Viele Grüße

[freda]

Hallo,

hab das Coding im Modul für HM-CC-RT-DN Geräte, die über HMCCUDEV eingebunden sind, geändert. Vielleicht könnte es jemand mal gebrauchen. Wäre aber natürlich besser, wenn es im nächsten Release des Moduls drin wäre.

VG

[Risiko]

Hallo,

hab das Coding im Modul für HM-CC-RT-DN Geräte, die über HMCCUDEV eingebunden sind, geändert. Vielleicht könnte es jemand mal gebrauchen. Wäre aber natürlich besser, wenn es im nächsten Release des Moduls drin wäre.

VG

Sorry für die späte Meldung.
Ich schaue es mir (hoffentlich zeitnah) an und wenn es i.O. ist, nehme ich die Änderung auf.

Risiko

[Risiko]

STefan

Hallo Stefan,

danke für die Hinweise.
Muss ich mir mal durch den Kopf gehen lassen.

[Risiko]

Hallo,

hab gerade das Coding im Modul angeschaut. HMCCUDEV ist bereits für das Device HmIP-eTRV-2 integriert. Auf den ersten Blick sind nur die Readings anders benannt. Wäre es aufwändig die alte Devices auch zu integrieren`

Viele Grüße

Hallo.
Ich habe mir die Änderungen angesehen. Durch diese Änderungen funktioniert dann das HmIP-eTRV-2 nicht mehr!
Sorry, aber ich verstehe leider nicht, warum bei gleichem FHEM-Device (HMCCUDEV) die Readungs unterschiedlich sind. Was ist das denn für ein Quatsch.
Das mit den unterschiedlichen Readingsnamen ließe sich wahrscheinlich noch geradeso noch machen (unschön).
Die Änderungen des Befehls (Zeile 388 set <device> config ohne 1) verstehe ich leider nicht. Was ist richtig.
Nehme die Änderungen erstmal nicht auf, bis das geklärt ist.

Risiko

[Risiko]

Ich weiss zwar dass im Wiki steht, dass wenn man Topics verwendet (mach ich) und man beim auslesen (get ...) kein Topic angibt, immer das "default" genommen wird. Wäre es aber nicht logischer (und allenfalls auch sinnvoller) dann anstatt "default" das "active_tpoic" zu nehmen?

Sehe ich auch so. Das Reading "active_topic" wurde später eingeführt. Hab es jetzt so angepasst. Ohne Angabe des Topics wird das "active_topic" verwendet, wenn dieses gesetzt ist. Sonst default.

Dabei ist mir auch noch aufgefallen, dass mit "set <weekprofile> active_topic" irgendwas angegeben werden kann, d.h. es wird nicht überprüft ob es das Topic auch wirklich gibt, ist das bewusst so?

Das verstehe ich leider nicht ganz. Es wird immer ein Profil neu angelegt oder überschrieben. Fehlt die Angabe des Topic-Namens wurde default verwendet. Jetzt das "active_topic"

[freda]

Hallo.
Ich habe mir die Änderungen angesehen. Durch diese Änderungen funktioniert dann das HmIP-eTRV-2 nicht mehr!
Sorry, aber ich verstehe leider nicht, warum bei gleichem FHEM-Device (HMCCUDEV) die Readungs unterschiedlich sind. Was ist das denn für ein Quatsch.
Das mit den unterschiedlichen Readingsnamen ließe sich wahrscheinlich noch geradeso noch machen (unschön).
Die Änderungen des Befehls (Zeile 388 set <device> config ohne 1) verstehe ich leider nicht. Was ist richtig.
Nehme die Änderungen erstmal nicht auf, bis das geklärt ist.

Risiko

Hallo,
ich habe das bestehende Coding nur ersetzt, da ich nicht soweit in der PHP Programmierung drin bin, um es komplett von einander zu trennen.
Der Grund für die unterschiedlichen Readings / Befehle imho ist, dass es sich zum einen um HMIP (HmIP-eTRV-2) und zum anderen um alten HM Geräte (HM-CC-RT-DN) handelt. HMIP ist der neue Standard von EQ3/Homematic. HMCCUDEV kann aber beide Protokolle. Da ich momentan keine HMIP Geräte im Einsatz habe, ist es zwar eine Vermutung, bin mir aber hier ziemlich sicher. Evtl. könnte man über den Gerätenamen die Befele splitten.

VG

[Risiko]

Unabhängig der Protokolle, könnte HMCCUDEV gleiche Readings anbieten.
Naja, überlege mir bei Gelegenheit mal eine Lösung, wenn ihr es dann testet.
Offen ist jetzt noch

Code Auswählen Erweitern


set <device> config mit\oder ohne 1

Eine spezielle Logik, abhängig vom Namen, will ich eigentlich nicht einführen.

[clumsy]

Das verstehe ich leider nicht ganz. Es wird immer ein Profil neu angelegt oder überschrieben. Fehlt die Angabe des Topic-Namens wurde default verwendet. Jetzt das "active_topic"

Sorry, glaub ich hab mich da vertippt, resp. falsch ausgedrückt. Ich kann mit

Code Auswählen Erweitern

set <weekprofile> restore_topic <topic>
auch profile wählen resp. aktiv setzen, die es gar nicht gibt, also auch solche die bei

Code Auswählen Erweitern

get <weekprofile> topic_names
gar nicht aufgelistet werden, also eigentlich auch nicht existieren, resp. keine Profile in dem entsprechenden <topic> definiert sind.

[Risiko]

Ah ok. Verstanden.
Klingt nach nem Fehler.
Schaue es mir bei Gelegenheit an.

Danke.

[freda]

Unabhängig der Protokolle, könnte HMCCUDEV gleiche Readings anbieten.
Naja, überlege mir bei Gelegenheit mal eine Lösung, wenn ihr es dann testet.
Offen ist jetzt noch

Code Auswählen Erweitern


set <device> config mit\oder ohne 1

Eine spezielle Logik, abhängig vom Namen, will ich eigentlich nicht einführen.

Bei HM Devices werden die Werte nicht geändert wenn eine 1 hinter Config gesetzt ist. Bei HMIP kann ich es nicht sagen.

[kotaro]

vielleicht könnte man ja mit @zap reden, ob er nicht standardmäßig ein reading "model" implementiert wird.
Dies wird scheinbar auch für das HCS-Modul benötigt?
Dann könnte man diese Infos unterscheiden für HM und HMIP?

[Risiko]

Habe ihn angeschrieben. Mal schauen...