Hallo.
Da es für die Bearbeitung des Wochenprofils keine grafische (jedenfalls nicht für FHEMWEB - bzw. ich hatte nichts gefunden) Bearbeitungsmöglichkeit gab, habe ich selbst angefangen was zu implementieren.
Vielleicht gibt es ja Interessenten dafür.
Das Ganze beruht auf HTML und Java Script. Unter FHEM muss man einfach nur einen weblink anlegen.
define <name> weblink htmlCode {MAX_SHOW_WeekProfile("<MAX DEVICE>");;}
Bis jetzt ist alles fest und teilweise rudimentär umgesetzt. Es hat aber für meine Zwecke gereicht (getestet mit Chrome, Desktop+Mobil).
Je nach Interesse, Anforderungen und Zeit, lässt sich das sicherlich ausbauen.
Viel Spaß.
Der Hammer! Genial Danke dafür!
Keine Frage, unverzichtbar.
Großes Lob an Risiko.
John
Hey,
this is really very cool. It'll be a lot of help for lots of Max users for sure.
:)
Should be pinned!
Bitte um eine kleine Hilfe:
wie kann ich den Weblink einem Raum zuordnen?
attr weblink_{MAX_SHOW_WeekProfile("Hzg_Buero");;} room Plots,MAX
klappt nicht und
attr weblink_MAX_SHOW_WeekProfile room Plots,MAX
auch nicht.
Nabend stgeran,
siehe http://fhem.de/commandref.html#weblink (http://fhem.de/commandref.html#weblink)
attr <name> room Plots, Max
<name> ist frei wählbar
Ja, danke, hat geklappt.
Jetzt noch: wie kann ich die Darstellung in der Breite verändern, damit der Slider unten wegfällt?
Super Sache, vielen Dank dafür.
:)
Andreas
Sehr genial, aber leider habe ich kein MAX, nur FHT und HM :'(
Zitat von: P.A.Trick am 18 Januar 2015, 18:43:45
Der Hammer! Genial Danke dafür!
dem stimme ich zu :)
eine Kleinigikeit hätte ich aber doch : stell doch mal in deinem FHEM als Style z.B. dark ein ....
Ich würde im HTML Code auf Zuweisung direkter Farben u.ä. verzichten , Bsp :
$html .= "<h2 style=\"color:black\">Bearbeite Wochenprofil und die Klassen aus der .css Datei benutzen. Dann sollte das Ding sich perfekt in jede Umgebung einfügen.
Hallo.
Vielen Dank für das Feedback und den Hinweisen (Breite, Farben, etc.).
Genau das habe ich im Eingangsposting mit 'fest' gemeint.
Ich werde die Sachen aufnehmen und in einer nächsten Version nachbessern.
Komme aber frühestens Ende der Woche dazu mir das anzusehen.
Ich bin mir noch nicht so richtig sicher wie ich es machen werde (Parameter in der perl Funktion, Attribute und somit 'Missbrauch' vom weblink, etc.).
Wenn das Ganze auch für HM, FHT, etc. funktionieren soll, könnte man auch über ein Modul nachdecken.
Das schaffe ich zeitlich und aufgrund fehlender Hardware nicht - zumindest nicht allein.
Risiko.
Zitat von: Risiko am 19 Januar 2015, 18:41:36
Komme aber frühestens Ende der Woche dazu mir das anzusehen.
Nur kein Stress , wir haben jetzt sehr lange ganz ohne internen Editor gelebt :)
Meine Version mit unterschiedlichen Farben für gerade und ungerade Zeilen ist fast fertig.
Einnen kleinen Bug habe ich auch noch gefunden :
Die Temperatur Sollwerte sind ganze Zahlen von 10 - 30 hat man aber bereits zb. 19.5 definiert
findet $k == $curtemp den Istwert nicht und das DropDown steht dann auf dem kleinsten Wert (10).
Im Anhang die Version die ich z.Z. mit Style dark einsetze.
Geändert habe ich :
a. gerade und ungerade Zeilen haben verschieden Farben in Tabellen
b. die Temp Auswahl 0.5 Grad Schritten wie bei den MAX Geräten von 5- 30
c. Klassen aus der .css verwendet , das Design der Tabellen ist vom Modul ReadingsGroup "geklaut"
Mir war die Ausgabe ingesamt etwas zu breit und ich habe versucht Platz zu sparen, sieht nun aber mit dem default Style leider etwas gequetscht aus.
irgendwie klappt es nicht bei mir.
so sieht es aus:
define Wochenprofil weblink htmlCode { MAX_SHOW_WeekProfile("Wohnzimmer") }
Fehlermeldung:
Undefined subroutine &main::MAX_SHOW_WeekProfile called at (eval 2178) line 1.
für Hilfe wäre ich dankbar
Zitat von: chris1284 am 19 Januar 2015, 17:42:57
für hm kannichzu mindest schonmal das tempprofil jeden tages anzeigen lassen.. edit fehlt noch
Würde mich über eine Homematic/FHT Unterstützung auch sehr freuen. Das sind genau so Dinger die FHEM noch braucht um die usibility zu steigern.
Zitat von: xobd am 22 Januar 2015, 10:25:50
irgendwie klappt es nicht bei mir.
so sieht es aus:
define Wochenprofil weblink htmlCode { MAX_SHOW_WeekProfile("Wohnzimmer") }
Fehlermeldung:
Undefined subroutine &main::MAX_SHOW_WeekProfile called at (eval 2178) line 1.
Heißt dein Thermostat denn Wohnzimmer und nicht wz_Heizung o.ä.?
Homematic fände ich auch prima. Dann kann endlich jeder sein Wunschwochenprogramm selbst einrichten ;)
Mein Thermostat heisst:
NAME: MAX_<addr>
alias: Wohnzimmer
geht aber auch nicht mit MAX_xxxxxx (xxxxxx=addr)
Zitat von: xobd am 22 Januar 2015, 10:25:50
Fehlermeldung:
Undefined subroutine &main::MAX_SHOW_WeekProfile called at (eval 2178) line 1.
a. Modul 99_UtilsMaxProf.pm in den Ordner FHEM kopieren
b. FHEM shutdown restart
c. dann den neuen Weblink definieren
Habe ich so gemacht.
in der fhem.cfg steht:
define Wochenprofil weblink htmlCode { MAX_SHOW_WeekProfile("MAX_xxxxxxx");; }
Fehler siehe Bilder
Hallo,
vielen Dank dafür! Das sieht vielversprechend aus. Leider gibt es ein Problem:
ich habe zwei Räume mit jeweils 2 Thermostaten in einer Gruppe. Einer Davon noch mit WT.
Wenn ich das Wochenprofil bei einem Thermostat ändere, behalten die anderen im selben Raum leider ihr altes Profil...
Gäbe es nicht eine Möglichkeit, das basierend auf Räumen/groupIDs zu machen?
LG
Hallo,
besten Dank dafür. funktioniert einwandfrei.
Gruß Holgi
Noch ein Zusatz/Vorschlag:
am schönsten wäre die Umsetzung des Einstellen eines Wochenprofils, wenn es möglich wäre, dieses Device für mehrere Thermostaten anzulegen, so dass z.B. mit einer RegEx bei der Definition mehrere Thermostaten angegeben werden könnten, für die beim Setzen immer das selbe gemacht wird... Angezeigt werden müsste ja nur das Profil eines der Thermostaten. Eine Überprüfung, ob alle Synchron sind, wäre dann natürlich optimal (wenn auch nicht notwendig), z.B. durch einen Haken hinter dem jeweiligen Tag, der bestätigt, dass die Readings aller übergebenen Thermostaten übereinstimmen. Falls nicht, könnte ja ein Synchronisieren-Button angezeigt werden, der alle Thermostaten auf das angezeigte Profil des ersten Thermostaten setzt.
Das wäre sowas von toll! Ich bekomme nächste Woche meinen CUL (zu viele nervende Cube-Bugs wie Reset der Firmware, komische Verbindungen zwischen Thermostaten, die einfach mit anderen mitschalten obwohl in anderen Räumen, etc.) und da wäre das natürlich das Sahnehäubchen :))
vielleicht ist das hier: http://forum.fhem.de/index.php/topic,32660.msg250460.html#msg250460 (http://forum.fhem.de/index.php/topic,32660.msg250460.html#msg250460) auch im zusamenhang mit diesem thread interessant.
vielleicht lässt sich beides ja verbinden und so der code zwischen frontend und device gemeinsam nutzen.
gruss
andre
*Sabber* Bitte!!! Ich wäre dem, der das realisiert, auf Raumbasis, auf ewig dankbar.... man stelle sich nur vor, Wochenprofile schick und einfach auf dem Floorplan ändern...
Ich fänds auch gut für andere Dinge. Die Readingsgroup kann direkt drauf verlinken. Der RSS Feed auf dem Tablet ebenfalls. Vorallem sind das auch wirklich Dinge die man mal öfter ändert und auch andere in der Familie.
Sieht super aus. Ich habe "leider" HM-Komponenten, aber mir würde es schon reichen, wenn ich mit der GUI meine verschiedene Temperatur-Profile in der templist.cfg (http://www.fhemwiki.de/wiki/HM-CC-RT-DN_Funk-Heizk%C3%B6rperthermostat#Temperaturprofile_in_einer_Datei) bearbeiten könnte - das "Aktivieren" könnte ich dann ja händisch machen. Es hätte außerdem den Vorteil, dass man Profile für Urlaub, Normal, Abwesenheit und Co. einfach bearbeiten könnte, ohne dass diese aktuell aktiv sind...
Ronny
Gut für so ein Modul wäre vermutlich wenn FHT, Homematic und Max, alle die gleichen Temperaturlisten verarbeiten könnten. Leider werden alle 3 sehr unterschiedlich "befüllt".
der unterschied ist zwar unschön aber mit jeweils einem eigenen kleinen wrapper der zwischen frontend und backend sitzt lässt sich das durchaus lösen. das plotten der wochenprofile im logProxy modul kommt auch mit unterschiedlichen device typen zurecht.
gruss
andre
Hallo.
Ich gebe andre völlig recht.
Mit seinen widgets und dem Wrapper für die unterschiedlichen devices könnte man ein ordentliches WeekProfile Modul entwickeln.
Davon ist der aktuelle Stand noch weit entfernt.
Trotzdem (wie versprochen ein Update - Danke an wzut).
Einige wenige Sachen (Icons und Tagnamen) sind jetzt über userAttr im weblink einstellbar. Alles optional.
Werden die Icons nicht gefunden, dann werden die Tagnamen als Link zum editieren angeboten.
z.B.
define weblnk weblink htmlCode {MAX_SHOW_WeekProfile("MAX_FAKE_WT");;}
attr weblnk userattr usrEditWeekIcon usrEditDayIcon usrDays
attr weblnk room MAX
attr weblnk usrEditDayIcon empty
attr weblnk usrDays Mon,Tue,Wed,Thu,Fri,Sat,Sun
Risiko
Sorry falsche Datei - jetzt die aktuelle.
Hallo,
wollte mich an dieser stelle mal bedanken ;D
super Arbeit genau so was hatte ich noch gesucht!
Gruß Rolf
Hallo zusammen,
ich habe mir einen Dummy angelegt der das Wochenprofil enthält um an Feiertagen das Tagesprogram auf das vom Samstag oder Sonntag zu ändern (in Arbeit).
Wenn über den "HTML-Editor" das Wochenprogramm geändert wird, kann ich da ein Notify anlegen das mir mein Copy aufruft um meinen Dummy entsprechend neu zu setzen? Im Event Monitor habe ich nur das gesehen:
2015-02-01 23:03:51 MAX WZ_Thermostat_Strasse weekprofile-0-Sat-time: 00:00-09:30 / 09:30-22:00 / 22:00-23:55 / 23:55-00:00
2015-02-01 23:03:51 MAX WZ_Thermostat_Strasse weekprofile-0-Sat-temp: 19.0 °C / 22.0 °C / 19.0 °C / 19.0 °C
2015-02-01 23:03:51 MAX WZ_Thermostat_Strasse weekprofile-1-Sun-time: 00:00-09:30 / 09:30-21:30 / 21:30-23:55 / 23:55-00:00
2015-02-01 23:03:51 MAX WZ_Thermostat_Strasse weekprofile-1-Sun-temp: 19.0 °C / 22.0 °C / 19.0 °C / 19.0 °C
2015-02-01 23:03:51 MAX WZ_Thermostat_Strasse weekprofile-2-Mon-time: 00:00-11:00 / 11:00-21:30 / 21:30-23:55 / 23:55-00:00
2015-02-01 23:03:51 MAX WZ_Thermostat_Strasse weekprofile-2-Mon-temp: 19.5 °C / 22.0 °C / 19.0 °C / 19.0 °C
2015-02-01 23:03:51 MAX WZ_Thermostat_Strasse weekprofile-3-Tue-time: 00:00-11:00 / 11:00-21:30 / 21:30-23:55 / 23:55-00:00
2015-02-01 23:03:51 MAX WZ_Thermostat_Strasse weekprofile-3-Tue-temp: 19.0 °C / 22.0 °C / 19.0 °C / 19.0 °C
2015-02-01 23:03:51 MAX WZ_Thermostat_Strasse weekprofile-4-Wed-time: 00:00-11:00 / 11:00-21:30 / 21:30-23:55 / 23:55-00:00
2015-02-01 23:03:51 MAX WZ_Thermostat_Strasse weekprofile-4-Wed-temp: 19.0 °C / 22.0 °C / 19.0 °C / 19.0 °C
2015-02-01 23:03:51 MAX WZ_Thermostat_Strasse weekprofile-5-Thu-time: 00:00-11:00 / 11:00-21:30 / 21:30-23:55 / 23:55-00:00
2015-02-01 23:03:51 MAX WZ_Thermostat_Strasse weekprofile-5-Thu-temp: 19.0 °C / 22.0 °C / 19.0 °C / 19.0 °C
2015-02-01 23:03:51 MAX WZ_Thermostat_Strasse weekprofile-6-Fri-time: 00:00-11:00 / 11:00-22:00 / 22:00-23:55 / 23:55-00:00
2015-02-01 23:03:51 MAX WZ_Thermostat_Strasse weekprofile-6-Fri-temp: 19.0 °C / 22.0 °C / 19.0 °C / 19.0 °C
Kann ich darauf basierend ein Notify definieren? Kann etwas in dieser Art funktionieren?
define updateWeekprofil notify .:weekprofile. {MAX_Copy_Weekprofile_To_Dummy($Device)}
Ich konnte zumindest nichts sehen, es wurde aber auch kein Fehler ins Log geschrieben.
Gruß
Thomas
@Sargon
Das hat nichts mit diesem Modul zu tun.
Denke dafür ist ein separater Thread besser geeignet bzw. schau dir Regular Expressions und Syntax vom notify an.
Aber vielleicht soviel:
define ntfy_copy notify .*weekprofile.* {Copy($EVENT);;}
Wenn es wirklich alle Readings von allen Geräten (auch vom Dummy) sein sollen.
Dann muss man innerhalb von Copy noch $EVENT zerlegen oder du verwendest $EVTPART0, etc.
Viel Erfolg.
Risiko
Hi,
das wäre zwar wahrscheinlich ein Thema für den readingsgroup Thread, paßt aber thematisch besser hierher, wegen dem Aufruf des Wochenprofileditors.
Ich habe eine vorhandene readingsGroup (Heizungswerte) , die ich jetzt um einen Link zum Einstellen des Wochenprofile erweitert habe, zumindest war dies der Plan:
<%sani_heating>,<Ventil>,<Soll-Temp>,<Ist-Temp>,<Modus>,<Batterie> ht_(.*|):valveposition,desiredTemperature,temperature,<{HeizungModeAuto($DEVICE)}@mode>,battery,<{HeizungUpDown($DEVICE,"up")}@desiredTemperature>,<{HeizungUpDown($DEVICE,"down")}@desiredTemperature>,<%weekprofile>
In der letzten Spalte hätte ich nun den Aufruf zum Einstellen der Wochenprofile eingebaut.
Das entsprechende Attribut commands lautet bei mir:
commands { 'Heizungswerte.weekprofile' => '{MAX_EDIT_Week($DEVICE,"Wochenprofil");;}' }
Wenn diese readingsgroup nun im Browser dargestellt wird, dann ergibt sich hier etwas sehr Chaotisches, siehe angefügtes Bild. Erstens wird gleich der Wochenprofil-Editor angezeigt und zweitens ein paar Zeilen Coding anstelle des erwarteten Weblinks.
Was mache ich hier falsch?
Grüße,
Michael
Hallo,
ich glaube mit den Readings von allen Geräten soll kein Problem sein, weekprofile sollte es eigentlich nur bei Thermostaten geben und auch bei den Dummys sollte es kein Problem sein da verwende ich setreading um die Daten in den Dummy zu schreiben.
Was wahrscheinlich das Problem sein dürfte ist, dass ich nicht unterscheiden kann ob das weekprofile von deinem Editor "gesendet" wurde (dann soll der Dummy geändert werden) oder ob es von meiner Feiertagsfunktion gesendet wird (dann soll der Dummy nicht geändert werden). Eventuell muss ich bei dir im Code noch das Update meines Dummys mit einbauen.
Du hast recht das hat wahrscheinlich nur wenig mit deinem Modul zu tun.
Gruß
Thomas
@Roaster
Diese Funktionalität habe ich selbst so noch nicht getestet. Aber ich denke es könnte so gehen.
Bei den command muss man über trigger und einem notify gehen.
Etwa so:
define NTFY_EDIT_WEEK notify NTFY_EDIT_WEEK {MAX_EDIT_Week($EVENT);;}
commands {'Heizungswerte.weekprofile' => 'trigger NTFY_EDIT_WEEK $DEVICE'}
Wenn ich es schaffe, probiere ich es morgen selbst mal aus. Unter Umständen muss ich noch was in der Funktion MAX_EDIT_Week anpassen.
@Sargon
Also der Editor sendet auch nur ein set <device> weekprofile ... , so als wenn man es in der Kommandozeile eingeben würde.
Das notify wird dann vom <device> ausgelöst, nicht vom Editor.
Wenn du bei dem dummy mit setreading arbeitest, dann wird dort auch ein notify ausgelöst.
Ich denke man kann wohl in der Notfy-Funktion unterscheiden, ob das notify vom Device A oder B kommt.
Risiko.
MAX_EDIT_Week liefert den html code inclusive der js routinen zurück. wenn du in der readingsGroup einen link anzeigen willst darfst du natürlich nicht den kompletten html code einbauen sondern musst einen link auf den weblink den du mit MAX_EDIT_Week angelegt hat einbauen.
wenn du tatsächlich den editor in der readingGroup anzeigen möchtest musst du den js teil vom html teil trennen und nur den html teil einbinden. den js teil musst du dann anders auf die seite bringen.
gruss
andre
@andre
Vielen Dank für die Hinweise.
Mir ist klar, dass das Design vom Editor absolut nicht passt. So wie der aktuell Zustand ist, ist er für Readingsgroup, Floorplan, etc nicht geeignet - war auch nicht vorgesehen.
Der richtigere Weg wäre meiner Meinung nach:
- in jedem Device eine Aufbereitung der Readings für ein Widget realisieren
- das Widget wäre dann für alle Thermostate (MAX, Homematic,etc.) nutzbar
- die Readingsaufbereitung z.B. als JSON könnten auch andere Frontends nutzen
- Das widget in js realisieren
- widgetoverride benutzen
Aktuell sehe ich keine Möglichkeit die Informationen von mehreren Readings an ein Widget zu bekommen.
Alle Lösungen (so habe ich es verstanden) basieren auf einer 1:1 Zuordnung.
Mit FW_directNotify komme ich da auch nicht so richtig weiter - kann aber auch ein Verständnisproblem sein.
Zitat von: justme1968 am 03 Februar 2015, 12:47:25
musst einen link auf den weblink ... einbauen.
Das verstehe ich nicht so richtig.
Da Anlegen eines manuellen Links (<a...) scheint nicht zu funktionieren, da dieser immer in das onClick="FW_cmd('/fhem?XHR=1 ... eingebaut wird
Risiko.
Hm so richtig scheint es wirklich nicht zu funktionieren.
Weder define not.EditWeekProfile notify Heizungswerte:not.EditWeekProfile {MAX_EDIT_Week($EVENT);;}
noch define not.EditWeekProfile notify Heizungswerte:not.EditWeekProfile {MAX_SHOW_WeekProfile($DEVICE);;}
oder durch direkte Angabe des Max Thermostats define not.EditWeekProfile notify not.EditWeekProfile {MAX_SHOW_WeekProfile('ht_HeizungEltern');;}
löst hier die Anzeige des Wochenprofils aus.
Restliches Coding der RG
define Heizungswerte readingsGroup [..]<%time_timer@orange>
[..]
attr Heizungswerte commands {'Heizungswerte.time_timer@orange' => 'trigger not.EditWeekProfile'}
Auch ein trigger not.EditWeekProfile direkt in der Kommandozeile löste keine Anzeige des Wochenprofils aus.
der notify und trigger ansatz ist wirklich nicht der richtige um auf eine andere seite zu wechseln.
nur links die ein save oder set enthalten (also ein set kommando ausführen) werden durch eine XHR version ersetzt.
ein ganz normaler link auf eine web seite z.b. die detail seite des weblinks oder einen raum in dem der weblink sichtbar ist werden nicht ersetzt sondern wechseln beim anklicken da hin.
gruss
andre
Super Arbeite "Risiko"
vielen Dank dafür.
beste Grüsse
Thorsten
Hallo @all,
um einen Link zum editieren zu erzeugen, habe ich eine Hilfsfunktion MAX_EDIT_Week_LNK eingebaut.
Damit kann man
einen Link zum editieren auf eine neue Seite in einer Readingsgroup integrieren.
Ich gebe zu, schön ist anders.
define Grp readingsGroup MAX_FAKE_WT.*:desiredTemperature,state,mode,<{MAX_EDIT_Week_LNK("$DEVICE")}>
oder
define Grp readingsGroup MAX_FAKE_WT.*:desiredTemperature,state,mode,<{MAX_EDIT_Week_LNK("$DEVICE",undef,"weblnk")}>
Parameter der Funktion:
- Name des MAX Thermostats
- Name für den link: Name kann auch ein Icon-Name sein, undef für Default-Icon
- Name des weblnk, welcher die userattr beinhaltet.
Risiko.
Hi,
Ich habs noch nicht getestet, aber trotzdem schon Mal Danke dafür.
D. h. dass der Klick auf eines der Icons egal in welcher Zeile, immer die komplette Übersicht für alle Thermostate anzeigt und nicht für ein individuelles Thermostat - das aus der aktuell angeklickten Zeile?
Michael
Hallo Michael,
nein. Jeder einzelne Link führt zur Bearbeitung des kompletten Wochenprofils eines individuellen Thermostats.
Bezogen auf das Bild.
Link (Icon) erste Reihe -> Thermostat A mit dem Name MAX_FAKE_WT
Link (Icon) zweite Reihe -> Thermostat B mit dem Name MAX_FAKE_WT2
Risiko.
@Risiko
Thanx for this extention! Really cool
I altered the tag's using the 'userattr', but can i change the title aswell? the title still say's "Wochenprofil" or "Bearbeite Wochenprofil" in German.
Thanx again,
WBMK
@WBMK
Currently it isn't possible to change the titles by an attribute.
I will consider it in a next version.
Risiko.
hi zusammen,
das ist mal richtig gut.
Bin für die Programmierung bisher immer bei andFhem gelandet, aber jetzt geht es auch vernünftig direkt in FHEM.
Habe mal ein device angelegt und war begeistert, dann das nächste und so weiter.
Jetzt zu meinem Problem:
manche Geräte sind editierbar und haben Zeiten, andere nicht.
Obwohl alles gleich angelegt.
Hier mal bilder und der Code:
define Wohnzimmer_PRG weblink htmlCode {MAX_SHOW_WeekProfile("Wohnzimmer");;}
attr Wohnzimmer_PRG userattr usrEditWeekIcon usrEditDayIcon usrDays
attr Wohnzimmer_PRG room 2.00 Wohnzimmer
attr Wohnzimmer_PRG usrDays Mon,Tue,Wed,Thu,Fri,Sat,Sun
attr Wohnzimmer_PRG usrEditDayIcon empty
define Badezimmer_PRG weblink htmlCode {MAX_SHOW_WeekProfile("Badezimmer");;}
attr Badezimmer_PRG userattr usrEditWeekIcon usrEditDayIcon usrDays
attr Badezimmer_PRG room 5.00 Badezimmer
attr Badezimmer_PRG usrDays Mon,Tue,Wed,Thu,Fri,Sat,Sun
attr Badezimmer_PRG usrEditDayIcon empty
Vielleicht kann mir jemand erklären warum? und was ich ändern muss!
Nutze die 99_UtilsMaxProf.pm aus Post 43
Hallo hyper2910,
es sieht für mich so aus, als würden für "Badezimmer" noch keine Readings bzw. kein Wochenprofil existieren.
Vergleich mal die Readings. Es müssen dort weekprofile-0-Sat-temp, etc. auftauchen.
Risiko.
Hallo Risiko,
das Wochenprofil sieht schon ganz gut aus. Das ist genau das was ich in FHEM noch vermisst habe.
Nach dem editieren und speichern bekomme ich aber die Meldung "Not enough credits" vom MAX_CUL.
Von dem Wochenprofil sind dann auch nur ein Paar Werte übernommen worden.
Wie gut Arbeitet das Weekprofil mit dem Max-Scanner zusammen?
Werden die geänderten Werte in einem zu den Devices gesendet oder Stückchenweise?
mfg. Sabine
Hallo Sabine,
ich habe auch den MAX-Scanner aktiv und noch keine Probleme festgestellt.
Das mit den Credits ist schon ein Problem. Hat aber nichts mit dem Editor zu tun.
Es wird das komplette Wochenprofil (wenn man nicht einen einzelnen Tag editiert) an das MAX-Modul zum Senden an das Device übergeben.
Wie intelligent das dort umgesetzt ist weiß ich noch nicht. Seht aber sowieso auf meiner ToDo-List. Super wäre, wenn nur die Änderungen an das Device gesendet würden.
Das Übertragen des Wochenprofils benötigt eben einige Credits. Daher kann es eine Weile dauern, bis alles versendet und aktualisiert ist.
Ich arbeite aktuell an einem "richtigen" Modul und da werde ich auf jeden Fall nur die Änderungen an das Device geben. Das wird aber noch ne Weile dauern bis es fertig ist.
Risiko.
Ich habe das gleiche Problem wie hyper2910. Im Wohnzimmer stehen keine Zeiten, in den anderen Räumen schon.
define Wochenprofil_wz_Wand weblink htmlCode { MAX_SHOW_WeekProfile("wz_WandThermostat");; }
attr Wochenprofil_wz_Wand room Wohnzimmer
Readings mit dem Wochenprofil zum wz_Wandthermostat sind vorhanden:
weekprofile-0-Sat-temp 12.0 °C / 18.0 °C / 21.0 °C / 17.0 °C 2015-03-07 18:47:33
weekprofile-0-Sat-time 00:00-10:15 / 10:15-17:00 / 17:00-22:00 / 22:00-00:00 2015-03-07 18:47:33
...
Klicke ich auf wz_Wandthermostat, wobei auch die Readings erscheinen, so sehe ich:
Probably associated with
FileLog_wz_Wandthermostat FileLog
In den anderen Räumen erscheint hier zusätzlich das Wochenprofil.
Irgendwie scheint die Assoziierung zum wz_Wandthermostat zu fehlen. Kann man das noch nachträglich machen?
Harald
bei mir klappt es jetzt, habe die Profiles nochmals neugesetzt und dann sind sie auch da.
Hallo Harald,
so richtig kann ich mir das nicht erklären.
Einzige Theorie: Reihenfolgeproblem in der Definitionsreihenfolge?
Soll heißen, erst das MAX-Device definieren und dann den weblink.
Risiko.
Erst einmal Danke für eure Bemühungen.
Ich habe die Reihenfolge der Definitionen jetzt in eine logische Reihenfolge gebracht (ja, tatsächlich fhem.cfg von Hand editiert) und fhem neu gestartet. Das Fehlerbild ist geblieben. Von 7 HT habe ich die Wochenprofile, nicht jedoch vom WT (obwohl in den Readings vorhanden).
Kann es sein, daß ein WT anders behandelt wird als ein HT?
Nein. WT und HT werden gleich behandelt.
Was mir noch aufgefallen ist: "wz_WandThermostat" vs "wz_Wandthermostat".
Ist das der Fehler!?
Risiko.
Hallo "Risiko",
ja, das war der Fehler. Ich muß mich noch mehr daran gewöhnen, Groß- und Kleinschreibung sauber zu beachten. Mit Sprachen, wie z.B. Pascal, mit der ich meistens arbeite, spielt das keine Rolle.
Vielen Dank, dein Tool ist sehr hilfreich!
Harald
Bin jetzt über diesen Thread gestolpert. Tolle Funktion, auf jeden Fall wesentlich besser wie die Profile "von Hand" zu verwalten.
Gibt es eine Möglichkeit das ganze mit Feiertagen / Schulferien zu koppeln (so ähnlich wie bei http://www.fhemwiki.de/wiki/Wochenende,_Feiertage_und_Schulferien (http://www.fhemwiki.de/wiki/Wochenende,_Feiertage_und_Schulferien)), oder was ist da die beste Vorgehensweise?
Die Grundidee wäre, für Ferien / Urlaubstage automatisch ein neues Profil auf ein Max-Gerät zu laden. Wobei diese Profile natürlich mit der Gui editiert werden sollen ::)
Danke für Ideen + Gruss
willy
Verstehe ich das richtig, dass ich die Programmierung der Zeiten/Temperaturen für jedes Gerät im selben Raum einzeln tätigen muss? Oder kann ich z.b. Wandthermostat und Heizungsthermostat in ein und dem selben Raum irgendwie zusammen gruppieren?
Hallo willyk,
ich habe die Entwicklung in diesem Bereich aktuell pausiert.
Ideen habe ich noch so Einige, auch der Wechsel der Profile in Abhängigkeiten von Ereignissen (z.B. eben auch Feiertage). Umgesetzt ist da noch nichts.
Risiko.
Zitat von: LinuxDoc am 13 Oktober 2015, 20:18:25
Verstehe ich das richtig, dass ich die Programmierung der Zeiten/Temperaturen für jedes Gerät im selben Raum einzeln tätigen muss? Oder kann ich z.b. Wandthermostat und Heizungsthermostat in ein und dem selben Raum irgendwie zusammen gruppieren?
Hallo LinuxDoc,
wenn das Heizkörperthermostat mit dem Wandthermostat gekoppelt ist, dann reicht es das Profil im Wandthermostat zu hinterlegen.
Im Heizkörperthermostat sollte dann kein Profil hinterlegt sein, da ja die Vorgaben vom Wandthermostat kommen.
Risiko
Genau das habe ich gemacht, nur auf dem Wandthermostat das Profil geändert, aber mein Heizkörperthermostat hat ein eigenes...
Also am besten die Profile in den Heizkörperthermostaten löschen?
Ich versuche es mal zu ignorieren und ändere nur die Wandthermostate ;-)
Zitat von: Risiko am 08 März 2015, 17:53:19
Hallo Harald,
so richtig kann ich mir das nicht erklären.
Einzige Theorie: Reihenfolgeproblem in der Definitionsreihenfolge?
Soll heißen, erst das MAX-Device definieren und dann den weblink.
Risiko.
Hallo Risiko,
erst einmal vielen Dank für dieses Tool. Klasse.
Ich hatte auch das gleiche Problem. Bei mir war der Weblink ganz am Ende definiert. Erst als ich die Adresse des MAX-Gerätes im Format MAX_0abcdef eingegeben hatte, war alles in Ordnung. Dann wurde auch der Alias im Menü Wochenprofil angezeigt.
Hallo zusammen,
Erstmal vielen Dank für das Modul!
Klappt super, gibt es in Richtung TabetUi schon was neues oder hat die jemand schonmal irgendwie eingebunden?
Steffen
Hallo.
Ich verwendet auch FTUI. Ich habe das provisorisch mit einem iframe und einer FHEM-WEB Instanz ohne Input, Logo, Raumansicht, etc. beholfen.
Somit kann ich gezielt ein Wochenprogramm auf meinem Wandtablet darstellen.
Das Ganze ist nur ein Provisorium. Wenn ich mal wieder etwas mehr Zeit habe, geht es an dieser Stelle evtl. auch weiter.
Risiko
Hi,
ich habe das jetzt mal für Homematic erweitert. (Siehe Datei im Anhang.) Es funktioniert jetzt sowohl für HM-CC-RT-DN als auch für HM-TC-IT-WM-W-EU. Ich hoffe, dass es auch noch für MAX funktioniert. Da ich kein MAX habe konnte ich das nicht ausprobieren.
Als Device muss man jeweils den "Climate" Channel (aka Channel 02) angeben.
Beim TC-IT-WM-W-EU geht das ganze davon aus, dass man die erste Temperaturliste (aka Programm 1) verwendet.
Gruß,
Thorsten
Tolle Sache...
und wenn man als Device den Channel 04 (Clima) benutzt, funktioniert's auch ;)
Zitat von: arne.dien am 02 Dezember 2015, 10:26:50
und wenn man als Device den Channel 04 (Clima) benutzt, funktioniert's auch ;)
Ok, da habe ich wohl gestern am späten Abend nicht so genau hingeschaut.
Beim HM-TC-IT-WM-W-EU ist es Channel 02 ("Climate").
Beim HM-CC-RT-DN ist es Channel 04 ("Clima").
Gruß,
Thorsten
Danke für die Erweiterung für HM!
Ich hätte da noch 'ne Frage/Bitte/Anregung :).
Können die "Experten" das Ganze noch für gespeicherte Listen, die in einer cfg im Hauptverzeichnis liegen, erweitern?
Meine tempList.cfg (HM-Geräte) sieht z.B. so aus:
entities:BD_Hk4_Clima
R_0_tempListSat>08:00 15.0 22:00 21.0 24:00 15.0
R_1_tempListSun>08:00 15.0 22:00 21.0 24:00 15.0
R_2_tempListMon>08:00 15.0 21:00 21.0 24:00 15.0
R_3_tempListTue>08:00 15.0 21:00 21.0 24:00 15.0
R_4_tempListWed>08:00 15.0 21:00 21.0 24:00 15.0
R_5_tempListThu>08:00 15.0 21:00 21.0 24:00 15.0
R_6_tempListFri>08:00 15.0 21:00 21.0 24:00 15.0
entities:BD_Regler_Climate
R_P1_0_tempListSat>06:00 17.0 22:00 21.0 24:00 17.0
R_P1_1_tempListSun>06:00 17.0 22:00 21.0 24:00 17.0
R_P1_2_tempListMon>06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0
R_P1_3_tempListTue>06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0
R_P1_4_tempListWed>06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0
R_P1_5_tempListThu>06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0
R_P1_6_tempListFri>06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0
R_P2_0_tempListSat>24:00 17.0
R_P2_1_tempListSun>24:00 17.0
R_P2_2_tempListMon>24:00 17.0
R_P2_3_tempListTue>24:00 17.0
R_P2_4_tempListWed>24:00 17.0
R_P2_5_tempListThu>24:00 17.0
R_P2_6_tempListFri>24:00 17.0
R_P3_0_tempListSat>24:00 17.0
R_P3_1_tempListSun>24:00 17.0
R_P3_2_tempListMon>24:00 17.0
R_P3_3_tempListTue>24:00 17.0
R_P3_4_tempListWed>24:00 17.0
R_P3_5_tempListThu>24:00 17.0
R_P3_6_tempListFri>24:00 17.0
entities:WZ_Hk0_Clima,WZ_Hk1_Clima
R_0_tempListSat>07:30 17.0 09:00 21.0 16:00 17.0 20:00 21.0 24:00 17.0
R_1_tempListSun>07:30 17.0 09:00 21.0 16:00 17.0 20:00 17.0 22:00 21.0 24:00 17.0
R_2_tempListMon>07:00 17.0 09:00 21.0 16:00 17.0 20:00 21.0 22:00 21.0 24:00 17.0
R_3_tempListTue>07:00 17.0 09:00 17.0 16:00 17.0 20:00 21.0 22:00 21.0 24:00 17.0
R_4_tempListWed>07:00 17.0 09:00 21.0 20:00 17.0 22:00 21.0 24:00 17.0
R_5_tempListThu>07:00 17.0 09:00 21.0 20:00 17.0 22:00 21.0 24:00 17.0
R_6_tempListFri>06:00 17.0 09:00 17.0 17:00 17.0 20:00 17.0 22:00 21.0 24:00 17.0
entities:Früh
tempListSat>14:00 17.0 16:00 19.5 19:00 19.5 21:30 19.5 24:00 17.0
tempListSun>14:00 17.0 16:00 19.5 19:00 19.5 21:30 19.5 24:00 17.0
tempListMon>14:00 17.0 16:00 19.5 19:00 19.5 21:30 19.5 24:00 17.0
tempListTue>14:00 17.0 16:00 19.5 19:00 19.5 21:30 19.5 24:00 17.0
tempListWed>14:00 17.0 16:00 19.5 19:00 19.5 21:30 19.5 24:00 17.0
tempListThu>14:00 17.0 16:00 19.5 19:00 19.5 21:30 19.5 24:00 17.0
tempListFri>14:00 17.0 16:00 19.5 19:00 19.5 21:30 19.5 24:00 17.0
entities:Tag
tempListSat>14:00 17.0 16:00 17.0 19:00 19.5 21:30 19.5 24:00 17.0
tempListSun>14:00 17.0 16:00 17.0 19:00 19.5 21:30 19.5 24:00 17.0
tempListMon>14:00 17.0 16:00 17.0 19:00 19.5 21:30 19.5 24:00 17.0
tempListTue>14:00 17.0 16:00 17.0 19:00 19.5 21:30 19.5 24:00 17.0
tempListWed>14:00 17.0 16:00 17.0 19:00 19.5 21:30 19.5 24:00 17.0
tempListThu>14:00 17.0 16:00 17.0 19:00 19.5 21:30 19.5 24:00 17.0
tempListFri>14:00 17.0 16:00 17.0 19:00 19.5 21:30 19.5 24:00 17.0
entities:Spät
tempListSat>08:00 17.0 12:00 19.5 19:00 17.0 21:30 17.0 24:00 17.0
tempListSun>08:00 17.0 12:00 19.5 19:00 17.0 21:30 17.0 24:00 17.0
tempListMon>07:00 17.0 12:00 19.5 19:00 17.0 21:30 17.0 24:00 17.0
tempListTue>07:00 17.0 12:00 19.5 19:00 17.0 21:30 17.0 24:00 17.0
tempListWed>07:00 17.0 12:00 19.5 19:00 17.0 21:30 17.0 24:00 17.0
tempListThu>07:00 17.0 12:00 19.5 19:00 17.0 21:30 17.0 24:00 17.0
tempListFri>07:00 17.0 12:00 19.5 19:00 17.0 21:30 17.0 24:00 17.0
entities:Nacht
tempListSat>08:00 17.0 12:00 17.0 14:00 17.0 19:30 19.5 24:00 17.0
tempListSun>08:00 17.0 12:00 17.0 14:00 17.0 19:30 19.5 24:00 17.0
tempListMon>07:00 17.0 12:00 17.0 14:00 17.0 19:30 19.5 24:00 17.0
tempListTue>07:00 17.0 12:00 17.0 14:00 17.0 19:30 19.5 24:00 17.0
tempListWed>07:00 17.0 12:00 17.0 14:00 17.0 19:30 19.5 24:00 17.0
tempListThu>07:00 17.0 12:00 17.0 14:00 17.0 19:30 19.5 24:00 17.0
tempListFri>07:00 17.0 12:00 17.0 14:00 17.0 19:30 19.5 24:00 17.0
entities:UrlaubUnterwegs
tempListSat>08:00 14.0 15:00 18.0 21:30 19.0 24:00 14.0
tempListSun>08:00 14.0 15:00 18.0 21:30 19.0 24:00 17.0
tempListMon>07:00 14.0 16:00 18.0 21:00 19.0 24:00 14.0
tempListTue>07:00 14.0 13:00 16.0 16:00 18.0 21:00 19.0 24:00 15.0
tempListWed>07:00 14.0 16:00 18.0 21:00 19.0 24:00 14.0
tempListThu>07:00 14.0 16:00 18.0 21:00 19.0 24:00 14.0
tempListFri>07:00 14.0 13:00 16.0 16:00 18.0 21:00 19.0 24:00 14.0
entities:UrlaubZuhause
tempListSat>08:00 14.0 15:00 18.0 21:30 19.0 24:00 17.0
tempListSun>08:00 14.0 15:00 18.0 21:30 19.0 24:00 14.0
tempListMon>07:00 14.0 16:00 18.0 21:00 19.0 24:00 14.0
tempListTue>07:00 14.0 13:00 16.0 16:00 18.0 21:00 19.0 24:00 15.0
tempListWed>07:00 14.0 16:00 18.0 21:00 19.0 24:00 14.0
tempListThu>07:00 14.0 16:00 18.0 21:00 19.0 24:00 14.0
tempListFri>07:00 14.0 13:00 16.0 16:00 18.0 21:00 19.0 24:00 14.0
In der Art, dass man den Bezeichner nach entities als Gerät übergibt und dann die entsprechenden folgenden Zeilen einliest, bearbeitet und dann wieder speichert?
Danke für Eure Mühe!
Uwe
Zitat von: locodriver am 02 Dezember 2015, 16:58:47Können die "Experten" das Ganze noch für gespeicherte Listen, die in einer cfg im Hauptverzeichnis liegen, erweitern?
Kannst Du erklären, was Du ansonsten mit diesen Listen machst?
Gruß,
Thorsten
Hallo.
Erstmal Danke für die Erweiterung für HM. Sehe ich mir bei Gelegenheit an.
Ich habe mir vorgenommen, dass ganze zum Modul auszubauen und HM, MAX und andere Thermostat soweit wie mgl. zu unterstützen.
Wenn das Modul fertig ist, kann man dann besser widgets für FHEMWEB oder FTUI bauen.
Weiterhin steht auch das Speichern und Wiederherstellen von Profilen auf den Plan.
Erste Ansätze gibt es hier von wzut:
http://forum.fhem.de/index.php?topic=42002.new;topicseen#new
Risiko
Ich habe mal noch den alten Homematic Wandthermostat HM-CC-TC dazugebastelt...
Dort den Kanal 02 (Climate) benutzen
@Thorsten: Na klar ;)
Die Listen können für mehrere Thermostate verwendet werden und ich lade die Listen in der Nacht in die Geräte, wenn sich der Heizmodus für den Folgetag ändert.
So muss nicht in jedem Gerät die Liste editiert (laden, ändern, schreiben) werden sondern nur einmal und nachts wird sie bei Bedarf geschrieben.
Uwe
Zitat von: locodriver am 03 Dezember 2015, 17:06:57
Die Listen können für mehrere Thermostate verwendet werden und ich lade die Listen in der Nacht in die Geräte, wenn sich der Heizmodus für den Folgetag ändert.
Ok, soweit klar, aber wie genau machst Du das "Laden"?
Um 3:30 wird der Heizmode aktualisiert und dann das entsprechende Profil mit dem folgenden DOIF in die RTs und TCs geladen bzw. der Modus umgeschalten (das hängt vom neuen Modus ab).
define Heizmodus DOIF ([BAjetzt] eq "Sommer") (set WZ_Hk0_Clima controlManu 30.5,set WZ_Hk1_Clima controlManu on,set BD_Regler_Climate controlMode manual,set BD_Regler_Climate desired-temp on)\
DOELSEIF\
([BAjetzt] eq "Frostschutz")(set WZ_Hk0_Clima controlManu 12.0,set WZ_Hk1_Clima controlManu 12.0,set BD_Regler_Climate controlMode manual,set BD_Regler_Climate controlManu 12.0)\
DOELSEIF \
([BAjetzt] eq "Früh")(set WZ_Hk0_Clima controlMode auto,set WZ_Hk0_Clima tempListTmpl restore FHEM/tempList.cfg:Früh,set WZ_Hk1_Clima controlMode auto,set WZ_Hk1_Clima tempListTmpl restore FHEM/tempList.cfg:Früh,set BD_Regler_Climate controlMode manual,set BD_Regler_Climate controlManu 20.0)\
DOELSEIF \
([BAjetzt] eq "Tag")(set WZ_Hk0_Clima controlMode auto,set WZ_Hk0_Clima tempListTmpl restore FHEM/tempList.cfg:Tag,set WZ_Hk1_Clima controlMode auto,set WZ_Hk1_Clima tempListTmpl restore FHEM/tempList.cfg:Tag,set BD_Regler_Climate controlMode manual,set BD_Regler_Climate controlManu 20.0)\
DOELSEIF \
([BAjetzt] eq "Spät")(set WZ_Hk0_Clima controlMode auto,set WZ_Hk0_Clima tempListTmpl restore FHEM/tempList.cfg:Spät,set WZ_Hk1_Clima controlMode auto,set WZ_Hk1_Clima tempListTmpl restore FHEM/tempList.cfg:Spät,set BD_Regler_Climate controlMode manual,set BD_Regler_Climate controlManu 20.0)\
DOELSEIF \
([BAjetzt] eq "Nacht")(set WZ_Hk0_Clima controlMode auto,set WZ_Hk0_Clima tempListTmpl restore FHEM/tempList.cfg:Nacht,set WZ_Hk1_Clima controlMode auto,set WZ_Hk1_Clima tempListTmpl restore FHEM/tempList.cfg:Nacht,set BD_Regler_Climate controlMode manual,set BD_Regler_Climate controlManu 20.0)\
DOELSEIF \
([BAjetzt] eq "Ruhe")(set WZ_Hk0_Clima controlManu 17.0,set WZ_Hk1_Clima controlManu 17.0,set BD_Regler_Climate controlMode manual,set BD_Regler_Climate controlManu 20.0)\
DOELSEIF \
([BAjetzt] eq "Urlaub")(set WZ_Hk0_Clima controlManu 14.0,set WZ_Hk1_Clima controlManu 14.0,set BD_Regler_Climate controlMode manual,set BD_Regler_Climate controlManu 15.0)\
DOELSEIF\
([BAjetzt] eq "Auto")(set WZ_Hk0_Clima controlMode auto,set WZ_Hk1_Clima controlMode auto,set BD_Regler_Climate controlMode manual,set BD_Regler_Climate controlManu 20.0)\
DOELSEIF\
([BAjetzt] eq "Manuell")(set WZ_Hk0_Clima controlMode manual,set WZ_Hk1_Clima controlMode manual,set BD_Regler_Climate controlMode manual,set BD_Regler_Climate controlManu 20.0)\
DOELSEIF\
([BAjetzt] eq "Boost")(set WZ_Hk0_Clima controlMode boost,set WZ_Hk1_Clima controlMode boost)\
DOELSEIF\
([BAjetzt] eq "Comfort")(set WZ_Hk0_Clima controlMode day,set WZ_Hk1_Clima controlMode day)\
DOELSEIF\
([BAjetzt] eq "Eco")(set WZ_Hk0_Clima controlMode night,set WZ_Hk1_Clima controlMode night)\
DOELSE()
attr Heizmodus alias aktueller Heizmodus
attr Heizmodus cmdState Sommer|Frostschutz|Früh|Tag|Spät|Nacht|Ruhe|Urlaub|Auto|Manuell|Boost|Comfort|Eco
attr Heizmodus devStateIcon auto:sani_heating_automatic Boost:sani_heating_boost Manuell:sani_heating_manual FHEM:sani_heating_manual AUS:secur_heat_protection Frostschutz:temp_frost
attr Heizmodus disable 0
attr Heizmodus do always
attr Heizmodus group Heizungen
attr Heizmodus icon temp_inside
attr Heizmodus room 010Wohnung
attr Heizmodus webCmd state
s.a. http://forum.fhem.de/index.php/topic,43900.msg357899.html#msg357899 (http://forum.fhem.de/index.php/topic,43900.msg357899.html#msg357899)
Die Modi (jetzt, morgen) werden entweder über eine Setlist, einen HM-Taster oder über Whatsapp gewählt. Wenn der Modus für morgen nicht geändert wird, so wird er auch für den übernächsten Tag usw. verwendet.
Uwe
Hi,
aha, die Homematic-Dinger haben ein restore-Kommando. Damit habe ich bisher nichts gemacht. Es sieht auch nicht so aus, als ob es da einen einfachen Weg gibt, das in's Gui mit aufzunehmen.
Vielleicht will's ja jemand anders machen.
Gruß,
Thorsten
Hallo.
Ich habe die Änderungen für HM eingepflegt. MAX geht auch noch ;)
Anbei der aktuelle Stand.
Risiko
Zitat von: Thorsten Pferdekaemper am 03 Dezember 2015, 19:01:33
Hi,
aha, die Homematic-Dinger haben ein restore-Kommando. Damit habe ich bisher nichts gemacht. Es sieht auch nicht so aus, als ob es da einen einfachen Weg gibt, das in's Gui mit aufzunehmen.
Vielleicht will's ja jemand anders machen.
Gruß,
Thorsten
sas muss man gar nicht. reichen würde es, wenn man die zentralen Zeitprofile editieren kann. Die Restore-funktion hat nicht direkt der DN, sondern die fhem-virtuelle HM-zentrale. Damit kann ich jedem thermostat sagen, welches Profil für ihn gilt, und prüfen, ob er noch übereinstimmt. vorallem im Zusammenhang mit Wandtermostaten wichtig und hilfreich.
Zitat von: JoeALLb am 04 Dezember 2015, 06:53:14
sas muss man gar nicht. reichen würde es, wenn man die zentralen Zeitprofile editieren kann. Die Restore-funktion hat nicht direkt der DN, sondern die fhem-virtuelle HM-zentrale. Damit kann ich jedem thermostat sagen, welches Profil für ihn gilt, und prüfen, ob er noch übereinstimmt. vorallem im Zusammenhang mit Wandtermostaten wichtig und hilfreich.
Hi,
das habe ich schon verstanden, trotzdem ist mir das momentan zu viel Aufwand, um es mal so zum Spaß zu implementieren. Wenn ich es selbst benutzen würde, dann wäre das was anderes.
Gruß,
Thorsten
Zitat von: locodriver am 03 Dezember 2015, 17:06:57
@Thorsten: Na klar ;)
Die Listen können für mehrere Thermostate verwendet werden und ich lade die Listen in der Nacht in die Geräte, wenn sich der Heizmodus für den Folgetag ändert.
So muss nicht in jedem Gerät die Liste editiert (laden, ändern, schreiben) werden sondern nur einmal und nachts wird sie bei Bedarf geschrieben.
Uwe
Zitat von: Risiko am 02 Dezember 2015, 19:05:54
Weiterhin steht auch das Speichern und Wiederherstellen von Profilen auf den Plan.
Erste Ansätze gibt es hier von wzut:
http://forum.fhem.de/index.php?topic=42002.new;topicseen#new
Na das hört sich doch richtig gut an !
Wenn man das schlau zusammenmischt, könnte man ganz neue Funktionen bereitstellen. Z.B.:
- Anlegen von Profilen, z.B. "Bad", "Bad Schulferien", "Bad Urlaub"
- Änderungsmöglichkeit für die Profile
- Verknüpfung der Profile mit Kalender und Anwesenheitserkennung
- Laden des aktuellen Profils auf die HT / WT, abhängig von den verfügbaren Credits
Den letzten Punkt könnte man mit dem Skript von wzut realisieren.
ZitatWenn man das schlau zusammenmischt, könnte man ganz neue Funktionen bereitstellen. Z.B.:
- Anlegen von Profilen, z.B. "Bad", "Bad Schulferien", "Bad Urlaub"
- Änderungsmöglichkeit für die Profile
- Verknüpfung der Profile mit Kalender und Anwesenheitserkennung
- Laden des aktuellen Profils auf die HT / WT, abhängig von den verfügbaren Credits
ZitatIch habe mir vorgenommen, dass ganze zum Modul auszubauen und HM, MAX und andere Thermostat soweit wie mgl. zu unterstützen.
Wenn das Modul fertig ist, kann man dann besser widgets für FHEMWEB oder FTUI bauen.
Weiterhin steht auch das Speichern und Wiederherstellen von Profilen auf den Plan.
Erste Ansätze gibt es hier von wzut:
http://forum.fhem.de/index.php?topic=42002.new;topicseen#new
Genau..., das könnte dann evtl. ein universelles Modul für alle Zeitpläne werden, die die gleiche Syntax benutzen; d.h. es müssen nicht nur Heizpläne sein...
Uwe
Zitat von: locodriver am 04 Dezember 2015, 11:22:39
Genau..., das könnte dann evtl. ein universelles Modul für alle Zeitpläne werden, die die gleiche Syntax benutzen; d.h. es müssen nicht nur Heizpläne sein...
Naja, Gleiche Syntax. MAX und HM sind da schon unterschiedlich.
Zitat von: Thorsten Pferdekaemper am 04 Dezember 2015, 11:52:44
Naja, Gleiche Syntax. MAX und HM sind da schon unterschiedlich.
Ja genau das sollte das Modul ja abfangen. Eine einheitliche Schnittstelle Richtung Anwendung und GUI und die Aufbereitung entsprechend der Hardware in die andere Richtung.
Zitat von: Risiko am 03 Dezember 2015, 19:05:28
Hallo.
Ich habe die Änderungen für HM eingepflegt. MAX geht auch noch ;)
Anbei der aktuelle Stand.
Risiko
Hi,
ich habe den Befehl aus seite 1 und das pm von risiko genommen
Ergebnis ist das BIld - wo kann ich suchen?
Was sind eigentlich die Vorraussetzungen?
Die Readings deines Devices sind vermutlich leer. eventuell ein getconfig absetzen?
Sorry das war mein Fehler. Auf der falschen fhem Instanz eingespielt
Gesendet von meinem Huawei Honor 7
Hallo Zusammen.
Erst mal Danke für diese super Arbeit. Ich bin ziemlicher Laie was diese Programmierung an geht, und deshalb auf solche vorgefertigten Lösungen angewiesen.
Ich habe also das Wochenprogramm bei mir in FHEM ein gebaut, und bin super zufrieden damit.
Jedoch habe ich, wie schon durch den User Mr.Heat hier eingebracht, im Wohnzimmer zwei Max Thermostate. Bei diesen musste ich mit dem Wochenprogramm immer jedes Thermostat einzeln programmieren, weil die Raumlösung (wie bei original Max Software) hier nicht funktioniert. Das heißt, das Wochenprogramm wird immer nur auf dem Thermostat ausgeführt, auf welchem es auch Programmiert wurde.
Ziemlich umständlich und es schleichen sich schnell Fehler ein.
Jetzt haben ich hier ---> http://forum.fhem.de/index.php/topic,42002.new/topicseen.html#new eine für mich praktikable Lösung gefunden. Ich habe mir einen Schalter Dummy erstellt, mit welchem ich über max-backup bei Betätigung zuerst das Wochenprogramm des einen Thermostates in eine backup Datei sichere, und danach dieselbe Datei in den zweiten Thermostat ein lese.
So muss immer nur ein Wochenprogramm geändert werden und danach einmal der Dummy Schalter betätigt werden. Und schon habe ich das Wochenprogramm auch auf dem zweiten Thermostaten.
Ich weiß nicht, ob es dafür schon eine andere Lösung gibt. Gefunden habe ich jedenfalls nichts. Vielleicht hilft dieser Beitrag auch einfach den Profis hier, beim erstellen einer professionelleren Lösung.
Ich finde das Frontend super.
Leider passt mir das Backend garnicht in den kram. Sieht man den system Gedanken ist es nicht brauchbar. Warum?
Es geht mit der Entscheidung los, wie das system aufgesetzt sein sollte. Das system sollte alle Parameter verwalten. Das device ist eine Außenstelle, für die Verwaltung kommt es nicht in Frage.
Betrachtet man nun wochenprogramme sollten diese in der zentrale hinterlegt sein. Für hm habe ich dies mit templisten in einem file realisiert. Über Details kann man streiten, nicht über den Ansatz.
Das feature Temperatur listen files für wochenprogramme kann man auch einfach auf max uebertragen, besser eigentlich so verallgemeinern dass es ein Ansatz ist der für beide passt. Sicher auch noch für andere Systeme.
Nun kommt dies Frontend zum tragen. Es sollte nicht die devices bearbeiten sondern die templates in den/dem templistfiles . ich wünsche mir eine Instanz, ich wählen ein template aus dem file, bearbeiten und speichere es.
Kurz um, wenn das tool wochenprogramme in files verwaltet ist es abstrakt, universell und super.
Es müssten folgende Funktionen addiert werden:
Auswahl eines files
Erkenne und auswählen der templates/wochenprogramme aus dem file
Einfügen eines neuen templates in das file mit default settings
Löschen eines templates aus dem file
Verwalten einer Liste von template files
Ich hoffe die technische Idee ist verstanden. Was für Vorteile verspreche ich mir vom Ansatz file Verwaltung:
In hm realisiert ist das teilen von templisten zwischen den Thermostaten.
Man kann profile umschalten, auf thermostatbasis oder per file für die ganze Wohnung
Der zustand der Thermostaten ist prüfbar. Falls etwas geändert wurde im RT kann ich es finden und korrigieren lassen- alles schon in hm existent.
Die Sicherung der listen ist möglich, der Austausch von RTS einfach.
HM hat schon alle optionen- nur das sehr coole Frontend zum editieren der tempfiles eben nicht.
Nachdem ich so viel Werbung gemacht habe - seht ihr die Vorteile und macht aus dem maxwochemprogramm ein fhemwochenprogrammtemplatefileverwaltungstool?
Wäre echt cool
Ich finde das Frontend super.
Leider passt mir das Backend garnicht in den kram. Sieht man den system Gedanken ist es nicht brauchbar. Warum?
Es geht mit der Entscheidung los, wie das system aufgesetzt sein sollte. Das system sollte alle Parameter verwalten. Das device ist eine Außenstelle, für die Verwaltung kommt es nicht in Frage.
Betrachtet man nun wochenprogramme sollten diese in der zentrale hinterlegt sein. Für hm habe ich dies mit templisten in einem file realisiert. Über Details kann man streiten, nicht über den Ansatz.
Das feature Temperatur listen files für wochenprogramme kann man auch einfach auf max uebertragen, besser eigentlich so verallgemeinern dass es ein Ansatz ist der für beide passt. Sicher auch noch für andere Systeme.
Nun kommt dies Frontend zum tragen. Es sollte nicht die devices bearbeiten sondern die templates in den/dem templistfiles . ich wünsche mir eine Instanz, ich wählen ein template aus dem file, bearbeiten und speichere es.
Kurz um, wenn das tool wochenprogramme in files verwaltet ist es abstrakt, universell und super.
Es müssten folgende Funktionen addiert werden:
Auswahl eines files
Erkenne und auswählen der templates/wochenprogramme aus dem file
Einfügen eines neuen templates in das file mit default settings
Löschen eines templates aus dem file
Verwalten einer Liste von template files
Ich hoffe die technische Idee ist verstanden. Was für Vorteile verspreche ich mir vom Ansatz file Verwaltung:
In hm realisiert ist das teilen von templisten zwischen den Thermostaten.
Man kann profile umschalten, auf thermostatbasis oder per file für die ganze Wohnung
Der zustand der Thermostaten ist prüfbar. Falls etwas geändert wurde im RT kann ich es finden und korrigieren lassen- alles schon in hm existent.
Die Sicherung der listen ist möglich, der Austausch von RTS einfach.
HM hat schon alle optionen- nur das sehr coole Frontend zum editieren der tempfiles eben nicht.
Nachdem ich so viel Werbung gemacht habe - seht ihr die Vorteile und macht aus dem maxwochemprogramm ein fhemwochenprogrammtemplatefileverwaltungstool?
Wäre echt cool
Ich stimme Martin voll und ganz zu :).
Siehe Post #67 von mir als Beispiel für Templisten.
Schönen 3. Advent!
Uwe
Zitat von: JoeALLb am 04 Dezember 2015, 23:54:59
Die Readings deines Devices sind vermutlich leer. eventuell ein getconfig absetzen?
nun habe ich es auf der richtigen instanz - wie sende ich ein getconfig?
Da es hier keinen Danke-Knopf gibt wollte ich einfach nur mal Danke!! für die tolle Erweiterung schreiben.
Nutze sie für meine Max! Komponenten und es erleichtert die Konfiguration enorm.
Zitat von: martinp876 am 13 Dezember 2015, 08:37:00
Ich finde das Frontend super.
Leider passt mir das Backend garnicht in den kram. Sieht man den system Gedanken ist es nicht brauchbar. Warum?
Es geht mit der Entscheidung los, wie das system aufgesetzt sein sollte. Das system sollte alle Parameter verwalten. Das device ist eine Außenstelle, für die Verwaltung kommt es nicht in Frage.
Betrachtet man nun wochenprogramme sollten diese in der zentrale hinterlegt sein. Für hm habe ich dies mit templisten in einem file realisiert. Über Details kann man streiten, nicht über den Ansatz.
Das feature Temperatur listen files für wochenprogramme kann man auch einfach auf max uebertragen, besser eigentlich so verallgemeinern dass es ein Ansatz ist der für beide passt. Sicher auch noch für andere Systeme.
Nun kommt dies Frontend zum tragen. Es sollte nicht die devices bearbeiten sondern die templates in den/dem templistfiles . ich wünsche mir eine Instanz, ich wählen ein template aus dem file, bearbeiten und speichere es.
Kurz um, wenn das tool wochenprogramme in files verwaltet ist es abstrakt, universell und super.
Es müssten folgende Funktionen addiert werden:
Auswahl eines files
Erkenne und auswählen der templates/wochenprogramme aus dem file
Einfügen eines neuen templates in das file mit default settings
Löschen eines templates aus dem file
Verwalten einer Liste von template files
Ich hoffe die technische Idee ist verstanden. Was für Vorteile verspreche ich mir vom Ansatz file Verwaltung:
In hm realisiert ist das teilen von templisten zwischen den Thermostaten.
Man kann profile umschalten, auf thermostatbasis oder per file für die ganze Wohnung
Der zustand der Thermostaten ist prüfbar. Falls etwas geändert wurde im RT kann ich es finden und korrigieren lassen- alles schon in hm existent.
Die Sicherung der listen ist möglich, der Austausch von RTS einfach.
HM hat schon alle optionen- nur das sehr coole Frontend zum editieren der tempfiles eben nicht.
Nachdem ich so viel Werbung gemacht habe - seht ihr die Vorteile und macht aus dem maxwochemprogramm ein fhemwochenprogrammtemplatefileverwaltungstool?
Wäre echt cool
Hallo martinp876,
ich gebe dir soweit recht.
Das ist bis jetzt alles andere als ein brauchbares Modul von Profilen\Wochenprogrammen unabhängig von den Hardwaredevices.
Ideen habe ich auch so Einige, nur leider nicht so viel Zeit zur Umsetzung.
Angefangen Richtung "fhemwochenprogrammtemplatefileverwaltungstool" habe ich.
Mal schauen, wenn ich eine erste Version präsentieren kann.
Die tollen Features von HM hat MAX und wahrscheinlich Andere auch nicht, daher wird es wohl in das Modul mit einfließen.
Risiko
ich denke, das Format des Files wie in HM genutzt sollte prinzipiell auch für andere passen.
Um es universell zu machen könnte man ein format beim File hinterlegen.
Ich schlage vor, dass das File komplett über das Frontend bedienbar ist. Erfahrene User können editieren, wenn sie es crashen ist es ihr Problem. Einfache User sollten es sein lassen. Damit könne wir zu Beginn (erste Zeile) das Fileformat hinterlegen. das macht mir später die Migration vom reinen HMInfo format einfacher.
#Format:weekplan V1.0das übrige format halte ich für hinreichend - aber vielleicht reicht es einem anderen nicht.
ZitatDie tollen Features von HM hat MAX und wahrscheinlich Andere auch nicht, daher wird es wohl in das Modul mit einfließen.
verstehe ich nicht. Ich würde ein neues Modul draus machen, da es übergreifend ist. In HMInfo würde es klappen, passt aber für MAX nicht so recht.
Vorstellen kann man sich, ein Format im Template zu hinterlegen, also ob es für HM oder MAX geeignet ist.
ich werde einmal nachdenken.
Als Anregung: vielleicht sollte man das Thema aus dem MAX-Bereich in den allgemeinen verschieben (Frontends?). Da würde es evtl. von mehr Usern wargenommen - ich bin auch nur zufällig draufgestoßen :).
Zitat von: martinp876 am 13 Dezember 2015, 16:49:13
Ich schlage vor, dass das File komplett über das Frontend bedienbar ist.
....
Vorstellen kann man sich, ein Format im Template zu hinterlegen, also ob es für HM oder MAX geeignet ist.
ich werde einmal nachdenken.
Hallo martinp876,
mir geht es primär darum ein Modul zu machen, dass unabhängig von der Hardware (MAX, HM, HeatingControl, etc.) Wochenprofile bereit stellt. Das ist meiner Meinung nach die Grundlage um Widgets für FHEMWEB, SmartViso, FTUI, etc. zu bauen um Wochenprofile zu bearbeiten.
Das es dann auch mehrere Profile verwalten kann ist zweitrangig. Über das Format habe ich mir noch nicht so die Gedanken gemacht. Es wird aber sicherlich auf json hinauslaufen und hardwareunabhängig sein.
Das Profil soll man natürlich auf unterschiedliche WT,HT aufspielen können.
In der HM-Welt kenne ich mich nicht so aus. Habe kein HM Geräte.
Risiko
Zitat von: locodriver am 13 Dezember 2015, 17:04:47
Als Anregung: vielleicht sollte man das Thema aus dem MAX-Bereich in den allgemeinen verschieben (Frontends?). Da würde es evtl. von mehr Usern wargenommen - ich bin auch nur zufällig draufgestoßen :).
Sobald ein allgemeineres Modul entstanden ist, werde ich das hier zu und einen neuen Thread auf machen. Das wird aber noch etwas dauern.
Ein riesen DANKE an Risiko für diese super Arbeit!!!
so was suche ich schon die ganze Zeit! hat mit kleinen Startschwierigkeiten aber dann sofort Funktioniert!
Hallo @all.
Es geht jetzt hier weiter:
http://forum.fhem.de/index.php?topic=46117.0
Wo bekomme ich die neueste Version des Moduls 99_UtilsMaxProf.pm ?
Genau das ist auch meine Frage: Wäre es nicht sinnvoll immer die aktuelle Version im Post1 zu plazieren? Sonst hangele ich mich durch den ganzen thread und hab schnell was übersehen.
Just my 2cent.
Ich nochmal: Nach meiner Aktivierung
define Buero weblink htmlCode {MAX_SHOW_WeekProfile("Hzg_Buero");;}
attr Buero room Wochenprofil
define WT_WZ weblink htmlCode {MAX_SHOW_WeekProfile("WT_WZ");;}
attr WT_WZ room Wochenprofil
bekomme ich das beim "speichern" drücken
No set implemented for WT_WZ
Wo fehlt da noch was?
Die Verwendung von WR_WZ als Argument der Funktion ist falsch. Da gehört eine MAX-Device hin.
Ich werde den Support hier einstellen, weil die weblink-Lsg durch das Modul weekprofile ersetzt wird.
Nachdem die Comandref für das 98_weekprofile.pm noch nicht so ausführlich ist, wie ich mir das beim Umstieg erhofft habe, habe ich mal eine Wiki-Seite angelegt, um da mal meinen Versuch einer Beschreibung des JSON Formates zu veröffentlichen: http://www.fhemwiki.de/wiki/Weekprofile (http://www.fhemwiki.de/wiki/Weekprofile)
Wäre toll, wenn weitere Mitleser hier Erweiterungen und Verbesserungen beitragen könnten, damit eine möglichst komplette Beschreibung des Moduls entsteht!
Hallo Reiner,
vielen Dank für deine Mühe.
Bitte zukünftig den Thread zu weekprofile verwenden.
Danke
Wäre toll, wenn Du den hier verlinkt hättest. Über die Forensuche ist er zwischen den automatisch generierten Posts mit den Code Changes (http://forum.fhem.de/index.php/topic,47198.0.html) nur schlecht zu finden. Ist doch dieser hier (http://forum.fhem.de/index.php/topic,46117.0.html), oder?