Hallo.
Auf Basis dieser
http://forum.fhem.de/index.php/topic,32390.0.html
ersten Umsetzung speziell für MAX Geräte habe ich nun daraus ein Modul zum verwalten von Wochenprofilen + ein Widget für FHEMWEB gebaut.
Das Modul soll natürlich nicht nur MAX-Thermostate unterstützen. Aktuell sollten noch die Homatic Modelle HM-CC-RT-DN, HM-CC-TC und HM-TC-IT-WM-W-EU funktionieren.
Da ich selbst keine Homatic Geräte besitze, benötige ich da Zuarbeit. Besten Dank an Thorsten Pferdekaemper und arne.dien.
Das Modul ist noch nicht fertig, aber evtl. als Weihnachtsgeschenk der aktuelle Stand zum spielen ;)
Ab morgen ist es aus per update verfügbar.
Ich denke es ist alles soweit alles in der commandref beschrieben (aktuell leider nur in de).
Kurzbeschreibung:
Anlegen einer Instanz mit define name weekprofile [master gerät]
Das 'Master-Gerät' kann eines der oben genannten Thermostate sein. Es wird dann automatisch das Profil 'master' entsprechend dem Wochenprofil vom Gerät angelegt.
Dieses kann dank des Widgets über FHEMWEB bearbeitet werden. Beim Speichern wird dieses automatisch an das 'Master-Gerät' übertragen. Credit und damit verbundene Probleme werden aktuell nicht berücksichtigt.
Wird kein 'Master-Gerät' angegeben, wird ein 'Default'-Profil angelegt.
Es können dann mehrere Profile bspw. für Urlaub, Sommer, Winter, etc. durch kopieren angelegt werden.
Das Senden eines Profils an ein anders nicht 'Master-Gerät' ist ebenfalls möglich.
Ich bin über euer Feedback gespannt.
Beschreibung im Wiki: http://www.fhemwiki.de/wiki/Weekprofile
Danke vielmals, dass es hier weiter geht!!
Spannende Sache, aber den Homematic - Workflow,den es bei mehr als einem Gerät braucht, trifft es noch nicht ganz. Dazu sollte die Homematic - Profildatei, die hminfo verwaltet, bearbeitet werden können. Das aktualisieren der Thermostate geht dann mit
Set DEVICE tempListTmpl restore
wie wäre es, wenn es direkt aus dem hminfo Device die temlatedatei (ist eine normale Textdatei am Filesystem) ausliest und die darin enthaltenen Profile zum editieren anbietet?
Hallo JoeALLb,
das Ganze soll nicht speziell für Homatic sein. MAX bspw. kann selbst nur ein Profil verwalten und es gibt auch noch andere Thermostate.
Könnte mir evtl. einen In- und Export von HMInfo bzw. der Datei vorstellen. Brauche dazu aber mehr Infos (habe kein Homatic).
Hallo,
habe das Modul gerade gefunden, bin schon mal beeindruckt. Bei den Homematic Geräten muß beim Definieren aber das Gerät mit Kanal (Clima bzw. Climate) angegeben werden.
Vielleicht kann das zukünftig gleich mit im Modul eingetragen werden?
Aber erst einmal vielen Dank und ein Frohes Fest Rolf
Zitat von: rvideobaer am 24 Dezember 2015, 10:26:21habe das Modul gerade gefunden, bin schon mal beeindruckt. Bei den Homematic Geräten muß beim Definieren aber das Gerät mit Kanal (Clima bzw. Climate) angegeben werden.
Vielleicht kann das zukünftig gleich mit im Modul eingetragen werden?
Hier muss man etwas aufpassen. Du weißt ja nicht, wie der Kanal jeweils heißt. Bei mir heißen die Dinger z.B. "Op" am Ende und nicht Clima(te).
Gruß,
Thorsten
Looks very useful, thanks - but before I try it I need an 'en' translation :(
Here's a very quick and dirty attempt - I may need to look at it again later if google got too many bits wrong
=pod
=begin html
<a name="weekprofile"></a>
<h3>weekprofile</h3>
<ul>
<b>ToDo: Übersetzung</b><br>
The 'weekprofile' module enables managing of multiple weekprofiles that can be modified and transferred to different devices. Currently, the following hardware is supported:
<li>all MAX Thermostats</li>
<li>Homatic HM-CC-RT-DN </li>
<li>Homatic HM-CC-TC </li>
<li>Homatic HM-TC-IT-WM-W-EU</li>
In the standard case, the module is associated with a device = 'master device',
the weekprofile of the device is edited from the web interface and sets other profiles on the device.
<br>
<b>Attention:</b> Transferring weekprofiles uses a lot of credits. This is not taken into account by the module. It may be that the weekprofile in the module does not immediately match the weekprofile of the device after setting\updating.
<br><br>
<a name="weekprofiledefine"></a>
<b>Define</b>
<ul>
<code>define <name> weekprofile [master device]</code><br>
<br>
Enables the module. When specifying a 'master device' a 'master device' weekprofile is created.
Special treatment of the 'master' profile:
<li>Can not be deleted</li>
<li>When changing\setting the Profile it is automatically sent to the 'master device'</li>
<li>It will come with abgespeicht</li>
<br>
If no 'master device' is set then a 'default' profile is created.
</ul>
<a name="weekprofileset"></a>
<b>Set</b>
<ul>
<li>profile_data<br>
<code>set <name> profile_data <profilname> <json data> </code><br>
Change the profile to 'profilname'. The profile data must be passed in JSON format.
</li>
<li>send_to_device<br>
<code>set <name> send_to_device <profilname> [device] </code><br>
profilname is transmitted to a device. If no device is specified, the 'master device' is used.
</li>
<li>copy_profile<br>
<code>set <name> copy_profile <source> <target> </code><br>
Copies the profile from 'source' to 'target'. 'target' is overwritten or recreated.
</li>
<li>remove_profile<br>
<code>set <name> remove_profile <profilname> </code><br>
The profile 'profilname' is deleted.
</li>
</ul>
<a name="weekprofileget"></a>
<b>Get</b>
<ul>
<li>profile_data<br>
<code>get <name> profile_data <profilname> </code><br>
Returns the profile of 'profilname' in JSON format
</li>
<li>profile_names<br>
<code>set <name> profile_names</code><br>
Provides a list of the profile_names separated by ',''
</li>
</ul>
<a name="weekprofileattr"></a>
<b>Attribute</b>
<ul>
<li>widgetWeekdays<br>
List of weekdays separated by ',' which are displayed in the widget.
Beginning on Monday. z.B.
<code>attr name widgetWeekdays Monday,Tuesday,Wednesday,Thursday,Friday,Saturday,Sunday</code>
</li>
<li>configFile<br>
Path and file name where the profiles are stored.
Default: ./log/weekprofile-<name>.cfg
</li>
<li>icon<br>
The icon used for the edit widget
Default: edit_settings
</li>
</ul>
</ul>
=end html
=cut
Edited
Hallo Risiko,
hatte dein Modul schon vor dieser Änderung getestet.
Kann man die Bezeichnungen für die Tage auf deutsche Tage umstellen oder ist das jetzt fest auf englische Tage codiert?
Gruß Rippi
und Frohe Weihnachten
Zitat von: Thorsten Pferdekaemper am 24 Dezember 2015, 10:32:18
Hier muss man etwas aufpassen. Du weißt ja nicht, wie der Kanal jeweils heißt. Bei mir heißen die Dinger z.B. "Op" am Ende und nicht Clima(te).
Gruß,
Thorsten
Das verstehe ich leider nicht. Dachte das die Syntax bei allen HM gleich ist, nur die Namen der Readings nicht. Naja wird sich schon noch ergeben ;D
Zitat von: rippi46 am 24 Dezember 2015, 10:40:39
Hallo Risiko,
Kann man die Bezeichnungen für die Tage auf deutsche Tage umstellen oder ist das jetzt fest auf englische Tage codiert?
Gruß Rippi
und Frohe Weihnachten
Dafür ist das Attribut widgetWeekdays da
Danke für die "Aufnahme" als offizielles Modul. Tolle Arbeit bis hier her.
Schöne Feiertage an alle!
Uwe
Coole Sachen, vielen Dank :)
btw falls noch jemand sucht wie man die Profile bearbeitet, dazu muss man auf die 3 Zahnräder klicken ^^
$hash->{AttrList} = "widgetWeekdays configFile".$readingFnAttributes;
should be
$hash->{AttrList} = "widgetWeekdays configFile ".$readingFnAttributes;
space before ".
Edit:
Otherwise I see
attr myWeekProfile configFileevent-on-change-reading
or similar
Ich weiß nicht ob es mit dem Fehler von fruit zu tu hat aber wenn ich ein Profil kopiere, dann dort die Temperatur ändere, dann die Änderungen speichere, dann die FHEM Config speichere, dann die Profile wieder aufrufe, dann das eben erstellte auswähle dann steht da nur noch MON bzw Montag, will man es dann noch bearbeiten mit einem Klick auf die Zahnräder dann erscheint keine Eingabemaske mehr.
Saving fhem config is OK here, profile following save is as edited so OK too
My suggestion above (now edited to explain the effect) affects setting the configFile atrr - perhaps it affects the save path too if not changed?
Zitat von: Risiko am 24 Dezember 2015, 11:37:31
Das verstehe ich leider nicht. Dachte das die Syntax bei allen HM gleich ist, nur die Namen der Readings nicht. Naja wird sich schon noch ergeben ;D
Du kannst Deine Devices und Kanäle so nennen, wie Du willst. Das geht einfach mit "rename".
Ich habe das Problem gefunden, liegt in der JS Datei (fhemweb_weekprofile.js) dort wird der Wochentag mittels Split ermittelt und fest auf index 2 gelegt
var id = $(tableDay[i]).attr('id').split('.');
var day = id[2];
Mein Weekprofil nennt sich aber:
weekprofile.Heizung.Profil.Wohnzimmer
somit ist dann z.B. der Sonntag
weekprofile.Heizung.Profil.Wohnzimmer.Sun
var day enthält dann aber Profil statt Sun
Lösung, die Zeile
var day = id[2];
ersetzen durch
var day = id[id.length-1];
Ich hätte da noch einen Vorschlag, ich arbeite im Schichtdienst und ich habe in verschiedenen Räumen verschiedene Zeiten und Temperaturen.
Somit habe ich für jeden Thermostat ein eigenes Weekprofil angelegt wo ich dann für den jeweiligen Raum das passende jeweilige Profil auswählen kann.
Die Unterteilung funktioniert soweit ohne Probleme nur wenn ich ein Profil (wie im Screenshot bei 1) auswähle, dann auf 2. klicke muss ich bei 3 nochmal den Empfänger angeben was dann auf die Dauer vermutlich schon nervig sein kann.
Könntest Du dort evtl das zum Profil gehörende Thermostat als Vorauswahl mit eintragen so das man nur noch auf OK klicken muss ?
Oder evtl als Dropdown mit alles Thermostaten wo das zugehörige Thermostat bereits selected ist.
Hallo Afterburner,
danke für deinen Fix. Hab es übernommen.
Die Sache mit den Devicenamen zur Auswahl (mit multi-select) steht noch auf der ToDo-Liste. Wird nächstes Jahr kommen.
Zitat von: Thorsten Pferdekaemper am 24 Dezember 2015, 15:49:54
Du kannst Deine Devices und Kanäle so nennen, wie Du willst. Das geht einfach mit "rename".
Ja das mit den Namen der Devices ist mir klar. Verstehe aber leider nicht was Kanäle hier (im Zusammenhang mit den Profilen) bedeuten soll. Kann jemand mal ein Beispiel liefern?
Hallo,
bei mir produziert das Modul einen Fehler:
Error messages while initializing FHEM:
statefile: Wochenprofil
Wochenprofil
Wochenprofil
hat vielleicht jemand eine Ahnung woher das kommen kann?
Gruß Rolf
Zitat von: rvideobaer am 02 Januar 2016, 00:26:47
Hallo,
bei mir produziert das Modul einen Fehler:
Error messages while initializing FHEM:
statefile: Wochenprofil
Wochenprofil
Wochenprofil
hat vielleicht jemand eine Ahnung woher das kommen kann?
Gruß Rolf
Hallo Zusammen,
habe hier den selben Effekt:
2016.01.03 16:58:23 0: Server shutdown
2016.01.03 16:58:26 2: MAX MaxScan: UtilsMaxScan_Initialize.86 MaxScan is starting
2016.01.03 16:58:26 1: Including fhem.cfg
2016.01.03 16:58:26 2: eventTypes: loaded 857 events from ./log/eventTypes.txt
2016.01.03 16:58:27 2: Switched Cube rfmode to MAX
splice on reference is experimental at ./FHEM/98_weekprofile.pm line 550, <$fh> line 775.
2016.01.03 16:58:29 1: Including ./log/fhem.save
2016.01.03 16:58:29 1: statefile: ProgrammBad
ProgrammBad
ProgrammBad
ProgrammKinderzimmer
ProgrammKinderzimmer
ProgrammKinderzimmer
ProgrammKueche
ProgrammKueche
ProgrammKueche
ProgrammWohnzimmer
ProgrammWohnzimmer
ProgrammWohnzimmer
2016.01.03 16:58:29 2: Error messages while initializing FHEM: statefile: ProgrammBad ProgrammBad ProgrammBad ProgrammKinderzimmer ProgrammKinderzimmer ProgrammKinderzimmer ProgrammKueche ProgrammKueche ProgrammKueche ProgrammWohnzimmer ProgrammWohnzimmer ProgrammWohnzimmer
2016.01.03 16:58:29 0: Featurelevel: 5.7
2016.01.03 16:58:29 0: Server started with 121 defined entities (fhem.pl:10315/2015-12-31 perl:5.020002 os:linux user:fhem pid:8466)Auffallend ist, das jedes Profil 3 Mal in der Fehlermeldung erscheint.....
Parallel dazu habe ich folgendes Verhalten seit 24.12 beobachten können:
- FHEM Update ok
- define weekprofile ok
((soweit ich mich erinner hier noch keine fehlermeldung)))
- weekprofile über gui verändert (alles + 0,5°C)
- Funktion ok, aber besagte Meldung bei Start von FHEM
- durch anderen Ausfall RPI inkl Linux und FHEM zurück gesetzt auf vor 24.12
-erneut Update und define weekprofile
--->>> Ich hatte plötzlich wieder das alte Wochenprogramm, wo die 0,5°C noch nicht geändert wurden!!
Schreibt die GUI das Wochenprogramm gar nicht INS Thermostat zurück??
(Laut Eigenschaften der Thermostate, ist das WP geschrieben, aber dann hätte es nicht verloren gehen dürfen, oder?)
Grüße,
Kharim
Zitat von: rvideobaer am 02 Januar 2016, 00:26:47
Hallo,
bei mir produziert das Modul einen Fehler:
Error messages while initializing FHEM:
statefile: Wochenprofil
Wochenprofil
Wochenprofil
hat vielleicht jemand eine Ahnung woher das kommen kann?
Gruß Rolf
Habe ich heute gefixt.
Zitat von: Kharim am 03 Januar 2016, 17:08:58
-erneut Update und define weekprofile
--->>> Ich hatte plötzlich wieder das alte Wochenprogramm, wo die 0,5°C noch nicht geändert wurden!!
Schreibt die GUI das Wochenprogramm gar nicht INS Thermostat zurück??
(Laut Eigenschaften der Thermostate, ist das WP geschrieben, aber dann hätte es nicht verloren gehen dürfen, oder?)
Grüße,
Kharim
Hallo Kharim,
die Profile für die Thermostate stehen auch mit im statefile (fhem.save) - jedenfalls bei MAX.
Durch das Zurücksetzen sind meiner Meinung nach die alten Readings in den Thermostaten zurück gesetzt wurden.
Alles klar....also zweimal Credits verschwendet :-D
Reicht ein FHEM Update für das FIX des Wochenprogramms zu?
Zitat von: Kharim am 03 Januar 2016, 18:23:53
Reicht ein FHEM Update für das FIX des Wochenprogramms zu?
Ja, ab morgen.
Hallo @all.
Ab morgen gibt es ein neues Attribut "widgetEditOnNewPage" [0 oder 1] um die Bearbeitung eines WP allein auf einer neue Seite anstatt in der Raumansicht durchführen zu können.
Update gemacht, funktioniert soweit.
Bei Max gibt es halt noch das Problem das wenn man den ganzen Tag über nur 1 Temperatur setzt, also 0000-2400 z.B. 21.5° dann nehmen die Thermostate das nicht an, das liegt aber nicht am Modul sondern am MAX System aber evtl kannst Du das ja in der Software abfangen. Man benötigt dann halt einen weiteren Schaltzeitpunkt, ich habe das z.B. 5 Minuten vor Mitternacht gemacht.
EDIT: was hältst Du von der Idee das pro Thermostat (falls das noch wer so gelöst hat wie ich mit jeweils Profilen pro Raum) aktuell gesetzte Profil auch zu speichern ? Also das man direkt sieht welches Profil in welchem Raum aktiv ist und somit z.B. auch in einer readingsGroup es sich anzeigen lassen zu können
Hallo Risiko,
Dein Modul wird den WAF von FHEM ins Unermessliche schießen :-)
Ich habe ausschließlich Homematic Teile im Einsatz und beginne gerade Dein Modul zu testen.
Alle Informationen zu den Kanälen kannst Du hier finden:
http://www.fhemwiki.de/wiki/HM-CC-RT-DN_Funk-Heizk%C3%B6rperthermostat
Bei mir hat es heuten (nach dem Update) nicht geklappt, ein Profil aus einem Device beim define zu lesen.
Ich habe es versucht mit: "define weekprofile weekprofile Thermostat.OG.Arbeitszimmer_Clima". Das erstellte Master Profil ist dann aber leer und lässt sich auch nicht bearbeiten.
Wenn ich es ohne master definiere "define weekprofile weekprofile" bekomme ich ein default Profil, das ich auch bearbeiten kann.
Die aus HMInfo erzeugte TempList.cfg habe ich als Beispiel mal angehängt. Info hier: http://www.fhemwiki.de/wiki/HomeMatic_HMInfo#tempList_Templates
Sie liegt normalerweise im FHEM Verzeichniss neben den modulen.
Tip noch für die Installationsanweisung: Ich hatte mein FHEM komplett neu aufgesetzt und noch kein JSON installiert.
Man braucht das modul: JSON::PP from package libjson-pp-perl sonst gibt es beim "define" einen Fehler.
Hi Risiko,
vielen Dank für dein Modul - sehr cool! Eine Idee wäre noch, dass man die Zeiten zwischen den Tagen innerhalb eines Profiles übertragen kann? Ich habe beispielsweise von an 4 von 7 Tagen in der Woche die gleichen Zeiten, aber leider 5 Schaltzeiten am Tag (und alle unterschiedlich pro Raum), was bei der Menge an Thermostaten ein endloses geklicke ist ;)
Vielen Dank im Voraus!
Viele Grüße,
Uli
Zitat von: Afterburner am 04 Januar 2016, 09:32:44
Bei Max gibt es halt noch das Problem das wenn man den ganzen Tag über nur 1 Temperatur setzt, also 0000-2400 z.B. 21.5° dann nehmen die Thermostate das nicht an, das liegt aber nicht am Modul sondern am MAX System aber evtl kannst Du das ja in der Software abfangen. Man benötigt dann halt einen weiteren Schaltzeitpunkt, ich habe das z.B. 5 Minuten vor Mitternacht gemacht.
Könnte man evtl. machen. Zumindest beim Setzen könnte man automatisch einen Schaltpunkt einfügen. Weiß jemand wie groß die kleinste Differenz zu 24 Uhr sein muss? Geht auch kleiner 5min?
Beim Auslesen sehen da aber Probleme. Ist der Schaltpunkt gewollt oder nur der Workaround. Vielleicht erstmal so: Wenn genau 2. Schaltpunkte für ein Tag existieren und der letzte Schaltpunkt <5 min vor 24 Uhr ist und die gleiche Temperatur hat, dann werden diese beiden Schaltpunkte im Modul zu einem zusammengefasst. Kommt wahrscheinlich auf einen Versuch an.
Natürlich könnte man das Ganze auch Früh machen, also 1. Schaltpunkt 00:05 Uhr, oder?
Zitat von: Afterburner am 04 Januar 2016, 09:32:44
EDIT: was hältst Du von der Idee das pro Thermostat (falls das noch wer so gelöst hat wie ich mit jeweils Profilen pro Raum) aktuell gesetzte Profil auch zu speichern ? Also das man direkt sieht welches Profil in welchem Raum aktiv ist und somit z.B. auch in einer readingsGroup es sich anzeigen lassen zu können
Wenn ich das richtig verstehe, willst du wissen\auslesen welches Profil zuletzt an des assoziierte Device gesendet wurde? Also z.B. Profil heißt 'Urlaub' und wurde an das Device gesendet. --> das 'Master'-Profil ist dann gleich dem 'Urlaub'-Profil. Könnte mir dafür ein Reading (evtl. active_master_profile oder profile_master) vorstellen, dass die Info aufnimmt was zu letzt gesendet wurde und somit aktiv ist und natürlich nur wenn beide Profile (master, Urlaub) gleich sind. Sonst nimmt das Reading 'Unknown' an.
Zitat von: cjung am 04 Januar 2016, 11:39:18
Alle Informationen zu den Kanälen kannst Du hier finden:
http://www.fhemwiki.de/wiki/HM-CC-RT-DN_Funk-Heizk%C3%B6rperthermostat
Bei mir hat es heuten (nach dem Update) nicht geklappt, ein Profil aus einem Device beim define zu lesen.
Ich habe es versucht mit: "define weekprofile weekprofile Thermostat.OG.Arbeitszimmer_Clima". Das erstellte Master Profil ist dann aber leer und lässt sich auch nicht bearbeiten.
Wenn ich es ohne master definiere "define weekprofile weekprofile" bekomme ich ein default Profil, das ich auch bearbeiten kann.
Erstmal danke für die Infos. Komme damit aber auch nicht so richtig weiter. Da steht nur "Beim HM-CC-RT-DN ist der Kanal 4 (_Clima) für die Temperaturlisten zuständig."
Wie lese ich dann nun die Profile aus?
Für das HM-CC-RT-DN werden aktuell die Readings "R_2_tempListMon, R_3_tempListTue,...R_1_tempListSun" verwendet. Habe ich auch nur übernommen.
Mann muss beim define natürlich den Namen des Devices angeben und nicht die Kanäle.Zitat von: cjung am 04 Januar 2016, 11:39:18
Die aus HMInfo erzeugte TempList.cfg habe ich als Beispiel mal angehängt. Info hier: http://www.fhemwiki.de/wiki/HomeMatic_HMInfo#tempList_Templates
Sie liegt normalerweise im FHEM Verzeichniss neben den modulen.
Ok danke. Schaue ich mir bei Gelegenheit mal an.
Zwecks des Schaltpunktes, das hatte ich damals im Wiki gelesen
ZitatBitte folgendes beachten:
Es gibt im Zusammenhang mit dem Wochenprogramm ein Problem mit dem letzten Schaltpunkt des Tages. Der Workaround wurde hier beschrieben. Man muss dafür sorgen, dass man kurz vor Ende des Tages noch einen Schaltpunkt setzt! Bei mir hat sich ein Schaltpunkt (ohne Änderung der Soll-Temperatur) um 23:55 bewährt:
http://forum.fhem.de/index.php/topic,17231.msg112738.html#msg112738
Hatte es heute mal getestet den ganzen Tag auf eine Temperatur zu setzen und er hatte das nicht angenommen, stand noch 17° bei desiredtemperature drin statt 21,5°
laut list Thermostat war aber das Programm richtig übertragen.
Das mit dem Schaltpunkt auf die selbe Temperatur hatte ich nicht ausprobiert.
ZitatWenn ich das richtig verstehe, willst du wissen\auslesen welches Profil zuletzt an des assoziierte Device gesendet wurde? Also z.B. Profil heißt 'Urlaub' und wurde an das Device gesendet. --> das 'Master'-Profil ist dann gleich dem 'Urlaub'-Profil. Könnte mir dafür ein Reading (evtl. active_master_profile oder profile_master) vorstellen, dass die Info aufnimmt was zu letzt gesendet wurde und somit aktiv ist und natürlich nur wenn beide Profile (master, Urlaub) gleich sind. Sonst nimmt das Reading 'Unknown' an.
Das mit dem Masterprofil habe ich jetzt nicht verstanden, das hat doch andere Einstellungen wie z.B. das UrlaubsProfil.
Ich lege ein weekprofil an und bekomme dann als Erstkonfiguration die Daten vom Thermostat für das ich das Profil angelegt habe.
Jetzt kopiere ich das Profil und ändere die Daten in der Kopie z.B. in den Urlaubsmodus, wenn ich jetzt das Urlaubsprofil an das Thermostat schicke dann ändert sich ja nicht das Masterprofil.
Das Masterprofil ist doch ein eigenständiges Profil wohl nur mit dem Unterschied das wenn man darin was ändert das es wohl gleich ans Thermostat geschickt wird (nicht getestet nur gelesen)
Das Modul ist ja momentan so aufgebaut das man jedes Profil an jedes Device schicken kann, hat zwar seine Vorteile aber verwirrt dann auf der anderen Seite auch wieder. Naja kommt vermutlich auf sein Konzept an wie man es umgesetzt hat.
Ich bei mir habe für jeden Raum (jeweils nur ein Thermostat) ein eigenes "weekprofile" angelegt mit dann jeweils eigenen Profilen für den Raum
Heizung.Schlafzimmer
Profil: Urlaub
Profil: Tagschicht
Profil: Nachtschicht
Heizung.Arbeitszimmer
Profil: Urlaub
Profil: Tagschicht
Profil: Nachtschicht
Heizung.Bad
Profil: Urlaub
Profil: Tagschicht
Profil: Nachtschicht
usw
Wenn ich jetzt z.B. im Schlafzimmer auf Nachtschicht umschalte dann wäre es gut wenn man den Status irgendwo sehen wurde das gerade das Profil Nachtschicht im Raum Schlafzimmer aktiviert wurde in der Art
attr activeProfile Heizung.Profil.Schlafzimmer Nachtschichtso das ich das dann in einer readingsGroup anzeigen kann (siehe Screenshot), evtl dort sogar per Dropdown ändern kann
Zitat von: Afterburner am 04 Januar 2016, 17:46:14
Das mit dem Masterprofil habe ich jetzt nicht verstanden, das hat doch andere Einstellungen wie z.B. das UrlaubsProfil.
Ich lege ein weekprofil an und bekomme dann als Erstkonfiguration die Daten vom Thermostat für das ich das Profil angelegt habe.
Jetzt kopiere ich das Profil und ändere die Daten in der Kopie z.B. in den Urlaubsmodus, wenn ich jetzt das Urlaubsprofil an das Thermostat schicke dann ändert sich ja nicht das Masterprofil.
Das Masterprofil ist doch ein eigenständiges Profil wohl nur mit dem Unterschied das wenn man darin was ändert das es wohl gleich ans Thermostat geschickt wird (nicht getestet nur gelesen)
Da ist wohl noch ein Fehler ???
Das master-Profil soll immer das aktuelle Profil vom assoziierten Device darstellen. Wenn man also ein zweites Profil z.B. Urlaub anlegt und speichert, dann können die Profile unterschiedlich sein. Wenn man nun Urlaub überträgt, dann sollte master gleich Urlaub sein. Ändert man das Profil direkt im Device, dann sollte das master-Profil sich automatisch anpassen (das aber noch nicht umgesetzt).
Danke für Deine Mühe !!
Zitat von: Risiko am 04 Januar 2016, 17:25:19
Erstmal danke für die Infos. Komme damit aber auch nicht so richtig weiter. Da steht nur "Beim HM-CC-RT-DN ist der Kanal 4 (_Clima) für die Temperaturlisten zuständig."
Wie lese ich dann nun die Profile aus?
Für das HM-CC-RT-DN werden aktuell die Readings "R_2_tempListMon, R_3_tempListTue,...R_1_tempListSun" verwendet. Habe ich auch nur übernommen.
Das passt: nur das diese Werte beim HM-CC-RT-DN eben im Kanal 4 liegen. In meinem Fall also: Thermostat.OG.Arbeitszimmer_Clima. Das Device selbst hat die Readings nicht.
2016-01-02 13:18:10 R_0_tempListSat 09:00 18.0 10:00 21.0 24:00 18.0
2016-01-02 13:18:10 R_1_tempListSun 09:00 18.0 10:00 21.0 24:00 18.0
2016-01-02 13:18:10 R_2_tempListMon 08:00 17.0 19:00 21.0 24:00 17.0
2016-01-02 13:18:10 R_3_tempListTue 08:00 17.0 19:00 21.0 24:00 17.0
2016-01-02 13:18:10 R_4_tempListWed 08:00 17.0 19:00 21.0 24:00 17.0
2016-01-02 13:18:10 R_5_tempListThu 08:00 17.0 19:00 21.0 24:00 17.0
2016-01-02 13:18:10 R_6_tempListFri 08:00 18.0 19:00 21.0 24:00 18.0
2016-01-02 13:18:10 R_tempList_State verified
Beim Wandthermostat HM-TC-IT-WM-W-EU liegen die Werte in Kanal 2. In meinem Fall also: Wandthermostat.OG.Atelier_Climate. Dort gibt es allerdings gleich 3 verschiedene Wochenprogramme.
Ich behaupte jetzt einfach mal, das viele nur das erste Programm nutzen.
2016-01-02 12:21:58 R_P1_0_tempListSat 06:00 17.0 22:00 21.0 24:00 17.0
2016-01-02 12:21:58 R_P1_1_tempListSun 06:00 17.0 22:00 21.0 24:00 17.0
2016-01-02 12:21:58 R_P1_2_tempListMon 06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0
2016-01-02 12:21:58 R_P1_3_tempListTue 06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0
2016-01-02 12:21:58 R_P1_4_tempListWed 06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0
2016-01-02 12:21:58 R_P1_5_tempListThu 06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0
2016-01-02 12:21:58 R_P1_6_tempListFri 06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0
2016-01-02 12:21:58 R_P1_tempList_State verified
2016-01-02 12:22:02 R_P2_0_tempListSat 24:00 17.0
2016-01-02 12:22:02 R_P2_1_tempListSun 24:00 17.0
2016-01-02 12:22:02 R_P2_2_tempListMon 24:00 17.0
2016-01-02 12:22:02 R_P2_3_tempListTue 24:00 17.0
2016-01-02 12:22:02 R_P2_4_tempListWed 24:00 17.0
2016-01-02 12:22:02 R_P2_5_tempListThu 24:00 17.0
2016-01-02 12:22:02 R_P2_6_tempListFri 24:00 17.0
2016-01-02 12:22:02 R_P2_tempList_State verified
2016-01-02 12:22:06 R_P3_0_tempListSat 24:00 17.0
2016-01-02 12:22:06 R_P3_1_tempListSun 24:00 17.0
2016-01-02 12:22:06 R_P3_2_tempListMon 24:00 17.0
2016-01-02 12:22:06 R_P3_3_tempListTue 24:00 17.0
2016-01-02 12:22:06 R_P3_4_tempListWed 24:00 17.0
2016-01-02 12:22:06 R_P3_5_tempListThu 24:00 17.0
2016-01-02 12:22:06 R_P3_6_tempListFri 24:00 17.0
2016-01-02 12:22:06 R_P3_tempList_State verified
Zitat von: Risiko am 04 Januar 2016, 17:25:19
Mann muss beim define natürlich den Namen des Devices angeben und nicht die Kanäle.
Leider funktioniert es bei mir weder mit dem Device noch mit dem Kanal :-(
Wenn ich irgendwie helfen kann, melde Dich einfach.
Hi,
ich habe soeben ein wiki zu templisten\woochenplaenen unter hminfo eingestellt. Das erklärt wie man wochenplan meiner Ansicht nach verwaltet.
Ein wochenplan sollte abstrakt abgelegt werden. Ich muss ihn auf unterschiedliche entities anwenden können, ohne ihn zu aendern. Die in hminfo passen für alle homematic Thermostaten.
Ferner muss ein template auf mehrere entities anwendbar sein. Will sagen ich muss einem template mehrere Namen geben können. Anders herum muss ich ein template mehreren entities zuweisen können. Somit setze ich im Thermostat ein attr tempListTmpl mit dem gewünschten Namen. Im template file hat ein template mehr als einen Namen.
Nun 3. müssen alle templates mit einem Rutsch ausgetauscht werden können. Z. B. Wenn der Sommer plötzlich kommt.
Das komplette handling ist implementiert. Was fehlt ist das editieren des template files.
Wäre schön, wenn der wochenplan sich auf das erstellen eines wochenplan konzentriert. Das koennte man dann prima nutzen. Hminfo prüft u.a. einiges an Sinnhaftigkeit in der Implementierung. Wenn ihr hier eingreift stimmt das alles nicht mehr.
Mit anderen Worten: implementiert keine Funktionen, die schon auf den unteren layern existieren und auch dort bleiben sollten.
Vielleicht sind ein paar Anregungen im wiki. Falls ein interface zu hm fehlt kann ich dies bereitstellen.
Hallo martinp876.
Danke für die Ausführungen.
Ich werden mir das zeitnah ansehen und dich ggf. privat kontaktieren.
Wenn ich es so auf die Schnelle richtige verstehe, dann bräuchte man nur eine Schnittstelle zu HMInfo, da es alle HM-Thermostate unterstützt.
Im Fall von HMInfo bräuchten die Profile nicht in diesem Modul gespeichert zu werden. Wäre dann nur ein Aufsatz zur Bearbeitung!?
Bei anderen Geräten (MAX, HC, etc.) gibt es sowas wie HMInfo nicht, deshalb ist dieses Modul entstanden.
Hallo,
ich könnt euch knutschen.
Ich zerbrech mir seit Tagen, den Kopf, wie ich genau das hier umsetzen kann und stoße nur durch Zufall auf Sourceforge auf dieses neue Modul 98_weekprofile .
Ich habs gleich ausprobiert und es scheint bisher mal fehlerfrei zu arbeiten.
Seit wann arbeitest Du denn schon an dem Modul, Risiko? Das ist soo geil. Du musst all meine Weihnachtswünsche zur Wochenprofilsteuerung mitbekommen haben.
Gruß
Volker
Korrekt. Wenn man das file generiert ist der Rest schon vorhanden. Zumindest einige Teile. Gerne passe ich das verhalten von hminfo entsprechend an, wenn es notwendig ist.
Da hminfo mehr ist als eine heizungssteuerung und weniger als ein Frontend sollte es Sinn machen. Heating controller scheint es schon mehrere zu geben.
Aus meiner Sicht sollte jede Familie ein hminfo-like Modul haben, das sich um Daten Konsistenz und Nutzung kümmert.
Gerne können wir es zusammenführen.
Ich kriege das Modul nicht ans Laufen:
Habe die aktuelle Version von Sourceforge runtergeladen, ins Modulverzeichnis kopiert, User, Group und Rechte sind auch OK, aber ich bekomme die Fehlermeldung:
Error messages while initializing FHEM:
configfile: Cannot load module weekprofile
in der fhem.cfg steht testweise:
define wp weekprofile MAX_0914ea
attr wp room Thermostate
Wenn ich versuche die Datei via FHEM zu erstellen bekomme ich die Fehlermeldung:
ERROR:
Can't locate JSON.pm in @INC (@INC contains: ./FHEM/lib ./lib /etc/perl /usr/local/lib/perl/5.14.2 /usr/local/share/perl/5.14.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.14 /usr/share/perl/5.14 /usr/local/lib/site_perl . ./FHEM) at ./FHEM/98_weekprofile.pm line 13. BEGIN failed--compilation aborted at ./FHEM/98_weekprofile.pm line 13.
Mit dem Vorgänger 99_UtilsMaxProf.pm klappte alles einwandfrei...
Das weekprofile-Modul steckt in 98_weekprofile.pm und ist mit "update" automatisch in Fhem. Musste nichts von Sourceforge holen.
Zitat von: YellowBall am 06 Januar 2016, 10:56:10
Error messages while initializing FHEM:
configfile: Cannot load module weekprofile
ERROR:
Can't locate JSON.pm in @INC (@INC contains: ./FHEM/lib ./lib /etc/perl /usr/local/lib/perl/5.14.2 /usr/local/share/perl/5.14.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.14 /usr/share/perl/5.14 /usr/local/lib/site_perl . ./FHEM) at ./FHEM/98_weekprofile.pm line 13. BEGIN failed--compilation aborted at ./FHEM/98_weekprofile.pm line 13.
Mit dem Vorgänger 99_UtilsMaxProf.pm klappte alles einwandfrei...
Du musst das Perl Modul JSON::PP installieren. Alternativ mit apt-get das package libjson-pp-perl sonst gibt es beim "define" einen Fehler.
Darf ich hier auch noch Wünsche äußern : FeatureRequest
SirUli hat ja schon erwähnt, dass es nützlich wäre, die Tagesprofile innerhalb der Wochenprofile kopieren zu können. Zusätzlich wäre dann noch praktisch, die Wochenprofile der einzelnen Geräte untereinander kopieren zu können, so wie es im MAX!-UI gemacht werden kann. Das war bislang der einzige Grund, warum ich den Cube nicht schon längst rausgeschmissen habe.
Zitat von: cjung am 06 Januar 2016, 14:55:56
Du musst das Perl Modul JSON::PP installieren. Alternativ mit apt-get das package libjson-pp-perl sonst gibt es beim "define" einen Fehler.
Perfekt! Das hat schon mal geklappt - vielen Dank!
Ich habe das System noch nicht kapiert:
habe mal testweise folgendes definiert:
# TEST ---------------
define wp_Wohnzimmer weekprofile MAX_0914ea
attr wp_Wohnzimmer alias Wochenprofil Wohnzimmer
attr wp_Wohnzimmer room Thermostate
Und bekomme nur das im Webfrontend zu sehen was ich angehängt habe.
Gibt es dazu vielleicht ein einfaches HowTo?
@YellowBall:
Zitat von: Afterburner am 24 Dezember 2015, 11:49:44
btw falls noch jemand sucht wie man die Profile bearbeitet, dazu muss man auf die 3 Zahnräder klicken ^^
@cjung:
Habe ich doch gleich als erstes gemacht ;-)
aber da tut sich leider nix. (Macbook 12" OSX El Capitan mit Safari)
Zitat von: VolkerGBenner am 06 Januar 2016, 15:44:27
Darf ich hier auch noch Wünsche äußern : FeatureRequest
Zusätzlich wäre dann noch praktisch, die Wochenprofile der einzelnen Geräte untereinander kopieren zu können
Steht schon auf der ToDo-Liste ;)
@YellowBall
Du hast wohl das Modul nicht per Update geholt!!!! sondern einzeln bei Sourceforge --> großer Fehler!!!!!!!!!!!!!
Sieht so aus, als wenn fhemweb_weekprofile.js fehlt.
Zitat von: Risiko am 06 Januar 2016, 19:27:20
@YellowBall
Du hast wohl das Modul nicht per Update geholt!!!! sondern einzeln bei Sourceforge --> großer Fehler!!!!!!!!!!!!!
Sieht so aus, als wenn fhemweb_weekprofile.js fehlt.
OK. Und wie komme ich aus der Nummer raus?
Kann ich das Update machen obwohl ich die aktuelle Version des Moduls habe?
Zitat von: YellowBall am 06 Januar 2016, 19:29:12
OK. Und wie komme ich aus der Nummer raus?
Kann ich das Update machen obwohl ich die aktuelle Version des Moduls habe?
Dich meiner Meinung nach allgemein tiefer in FHEM einarbeiten und dann ganz normal ein Update machen.
Zitat von: Risiko am 06 Januar 2016, 19:33:24
Dich meiner Meinung nach allgemein tiefer in FHEM einarbeiten und dann ganz normal ein Update machen.
Bin schon dabei - vielen Dank für Deinen Tipp mit dem Update - es rennt jetzt.
Respekt für Deine Leistung!
ps: funzt das auch mit AVM-Schaltaktoren (DECT200) ?
Hallo,
ich habe Heute wieder auf die alte Variante des Weekprofile modules gewechselt. Die Handhabung ist leider noch zu umständlich und auch gelingt es mir nicht eine TempListe auser master auf ein Thermostat zu überspielen. Aber der Ansatz ist gut und vielleicht Später werde ich es wieder nutzen.
Gruß Rolf
Also mit den anderen Profilen (außer Master) da
- wählst Du Dein gewünschtes Profil aus,
- klickst dann auf den rechten Button -->
- und trägst dort den Namen vom Device ein an welches es geschickt werden soll
- dann noch auf den OK/Send Button
Zumindest bei Max über MAXLAN hat das heute mit der aktuellen Version funktioniert.
Btw den Vorschlag mit den Tagesprofilen bzw Tagesvorlagen würde ich auch begrüßen :)
Wir sind hier auf jeden Fall auf dem richtigen Weg und an der Stelle nochmal ein großes Lob an den Autor des Moduls :)
Hallo,
also bei mir mit Homematic funktioniert es nicht. Ich habe für jedes Thermostat einen eigenen Wochenplan bei dem ich nur speichern anklicken muss und fertig. Nur so ist WAF hoch genug.
Gruß Rolf
So funktioniert es aber nur mit dem Master Profil, alle anderen musst Du momentan noch manuell senden, zieht den WAF in dem Fall natürlich extrem nach unten ^^
Btw bei mir ist der WAF beim gesamten System auf dem Stand "Mach Du das mal" :D :D :D
Ich muss auch mal an dieser Stelle Risiko ein dickes Lob für seine Arbeit aussprechen:
Das Modul rennt - zumindest mit Max!-Thermostaten - wie Hulle!
Die Steuerung funktioniert zuverlässig und die Möglichkeit verschiedene Profile (z.B. Sommer/Winter/Urlaub) anzulegen ist einfach nur genial!
Dieses Modul hat extrem viel Potential und ich würde mir wünschen, dass bald auch Schaltaktoren (z.B: AVM DECT200) unterstützt werden.
FHEM entwickelt sich langsam als echtes Hobby für mich... ;-)
Super tolles Modul, funktioniert in Kombination mit einem HM-CC-RT-DN super :)
Zitat von: Hauswart am 07 Januar 2016, 09:41:09
Super tolles Modul, funktioniert in Kombination mit einem HM-CC-RT-DN super :)
Wie hast Du das bei Dir konfiguriert ?Bei mir funktioniert es leider nicht.
define WT1 weekprofile HMxxx_Clima
Gruß
Zitat von: Hauswart am 07 Januar 2016, 12:52:58
define WT1 weekprofile HMxxx_Clima
Gruß
Passt, mit dem _Clima Kanal funktioniert es bei mir auch !!
hallo,
ich bin immer noch am experimentieren, wenn ich einen wert des master profiles ändere wird er übertragen. Ändere ich mehrere Einstellungen(zb. Temperatur an 2 oder mehr Tagen wird es nicht übertragen.
Gruß Rolf
Zitat von: rvideobaer am 07 Januar 2016, 13:47:23
hallo,
ich bin immer noch am experimentieren, wenn ich einen wert des master profiles ändere wird er übertragen. Ändere ich mehrere Einstellungen(zb. Temperatur an 2 oder mehr Tagen wird es nicht übertragen.
Gruß Rolf
Könnte an zu wenigen Credits liegen. Hab ich auch schon beobachtet. Die sind dann aber nach und nach von ganz allein aufgetaucht, wenn wieder genug Credits frei waren. (Meine ich beobachtet zu haben :-) )
Ich hab gestern mal ein MAX! Heizkörperthermostat manuell angelernt, also ohne autocreate. Dabei wird dann kein standartmäßiges Wochenprofil angelegt und ich hab auch nicht rausbekommen, wie ich es auf einfachem Weg aus dem Gerät auslesen konnte. Auf jeden Fall ist mir aufgefallen, dass, wenn dem Gerät noch kein Wochenprofil zugeordnet ist, weekProfile auch nichts zum editieren anbietet, ich also auch keine neuen Einträge erstellen kann. WeekProfile kann also nur editieren und nicht anlegen.
Für so bekloppte Individualisten mit Hang zur Bequemlichkeit wäre es noch praktisch, wenn weekProfile auch ein DefaultWochenProgramm mitbringt, so wie autocreate es ja, so nehm ich mal an, auch macht. Ich mußte so jetzt erst über die Eingabezeile ein Minimalwochenprogramm eintipseln, damit weekProfile was zum editieren hatte.
Hallo,
an den Credits liegt es nicht da erst gar nichts ans Thermostat geschickt wird. Bei einem Eintrag sofort CMDs_pending, bei mehr bleibt es bei CMDs_done.
Gruß
Hallo liebe FHEM´ler,
das Modul an sich finde ich klasse. Leider kann ich jedoch meine HM Thermostate nicht aktualisieren. Bei meinen HM-CC-TC kommt die Meldung:
2016.01.07 16:43:09 3: set HM_Wohnzimmer_Climate tempListMon prep 12:00 24.5 24:00 18.5;;set HM_Wohnzimmer_Climate tempListTue prep 24:00 18.5;;set HM_Wohnzimmer_Climate tempListWed prep 24:00 18.5;;set HM_Wohnzimmer_Climate tempListThu prep 24:00 18.5;;set HM_Wohnzimmer_Climate tempListFri prep 24:00 19.5;;set HM_Wohnzimmer_Climate tempListSat prep 24:00 18.5;;set HM_Wohnzimmer_Climate tempListSun exec 24:00 18.5 : Invalid temperature 18.5;set, choose one of on off 6.0 6.5 7.0 7.5 8.0 8.5 9.0 9.5 10.0 10.5 11.0 11.5 12.0 12.5 13.0 13.5 14.0 14.5 15.0 15.5 16.0 16.5 17.0 17.5 18.0 18.5 19.0 19.5 20.0 20.5 21.0 21.5 22.0 22.5 23.0 23.5 24.0 24.5 25.0 25.5 26.0 26.5 27.0 27.5 28.0 28.5 29.0 29.5 30.0
Bei dem Modell HM-TC-IT-WM-W-EU kommt folgende Meldung:
2016.01.07 16:45:51 3: set HM_Bad_oben_Climate tempListMon prep 12:00 24.5 24:00 18.5;;set HM_Bad_oben_Climate tempListTue prep 24:00 18.5;;set HM_Bad_oben_Climate tempListWed prep 24:00 18.5;;set HM_Bad_oben_Climate tempListThu prep 24:00 18.5;;set HM_Bad_oben_Climate tempListFri prep 24:00 19.5;;set HM_Bad_oben_Climate tempListSat prep 24:00 18.5;;set HM_Bad_oben_Climate tempListSun exec 24:00 18.5 : To many arguments, max 13 pairs
Hat jemand die gleichen Probleme?
Zitat von: Hauswart am 07 Januar 2016, 09:41:09
Super tolles Modul, funktioniert in Kombination mit einem HM-CC-RT-DN super :)
define WT1 weekprofile HMxxx_Clima
Danke und super, dass es mit einem HM-Thermostat funzt.
Zitat von: VolkerGBenner am 07 Januar 2016, 14:28:43
Ich hab gestern mal ein MAX! Heizkörperthermostat manuell angelernt, also ohne autocreate. Dabei wird dann kein standartmäßiges Wochenprofil angelegt und ich hab auch nicht rausbekommen, wie ich es auf einfachem Weg aus dem Gerät auslesen konnte. Auf jeden Fall ist mir aufgefallen, dass, wenn dem Gerät noch kein Wochenprofil zugeordnet ist, weekProfile auch nichts zum editieren anbietet, ich also auch keine neuen Einträge erstellen kann. WeekProfile kann also nur editieren und nicht anlegen.
Für so bekloppte Individualisten mit Hang zur Bequemlichkeit wäre es noch praktisch, wenn weekProfile auch ein DefaultWochenProgramm mitbringt, so wie autocreate es ja, so nehm ich mal an, auch macht. Ich mußte so jetzt erst über die Eingabezeile ein Minimalwochenprogramm eintipseln, damit weekProfile was zum editieren hatte.
Ab morgen sollte es gehen! ;)
Zitat von: Risiko am 07 Januar 2016, 20:04:53
Ab morgen sollte es gehen! ;)
;D Mein Held ;D Das nenn ich mal prompten Service.
Zitat von: Gerd.Ternes am 07 Januar 2016, 16:47:53
Bei meinen HM-CC-TC kommt die Meldung: Invalid temperature 18.5;set, choose one of ....
Bei dem Modell HM-TC-IT-WM-W-EU kommt folgende Meldung: To many arguments, max 13 pairs
Hat jemand die gleichen Probleme?
Sorry. Habe mir die Befehlssyntax aus der commandref für CUL_HM abgeschaut - jedenfalls so wie ich es interpretiert habe. Kann da leider nicht so richtig unterstützen. Vielleicht kann ja jemand das korrigieren bzw. die richtige Syntax für HM-CC-TC | HM-TC-IT-WM-W-EU liefern.
Ziel sollte (denke ich aktuell) aber sein, über HMInfo zu gehen. Wird aber leider noch etwas dauern.
Hallo Risiko,
wäre es viel Aufwand, die einzelnen Tage (anstelle die Tage zusammenzufassen) zu schreiben. Es ist zwar nicht die beste Lösung, könnte aber funktionieren.
VG
Gerd
Hallo Risiko,
habe gerade gemerkt, dass es noch sinnvoll sein könnte, die (weekprofile**.cfg)s mit in den "rename"-Befehl einbeziehen zu lassen.
Nur so um alles rund zu machen.
Die fhem***.log-Ausgabe nach Neustart, nachdem ich ein paar vernachlässigte Geräte umbenannt hatte:
2016.01.08 11:53:36 2: wpEsszimmer(assignDev): device MAX_087629 not supported or defined
2016.01.08 11:53:36 2: wpTreppenhaus(assignDev): device MAX_0aff3a not supported or defined
2016.01.08 11:53:36 2: wpWW_Zirkulation(assignDev): device MAX_083109 not supported or defined
2016.01.08 11:53:36 1: Including ./log/fhem.save
2016.01.08 11:53:38 2: wpEsszimmer(assignDev): device MAX_087629 not supported or defined
2016.01.08 11:53:38 2: wpTreppenhaus(assignDev): device MAX_0aff3a not supported or defined
2016.01.08 11:53:38 2: wpWW_Zirkulation(assignDev): device MAX_083109 not supported or defined
Zitat von: Risiko am 07 Januar 2016, 20:03:29
Danke und super, dass es mit einem HM-Thermostat funzt.
Jetzt wohl nicht mehr :o
Zitat2016.01.08 16:15:05 3: set HM_XXX_Clima tempListTue prep 06:00 17.0 08:30 21.0 17:00 17.0 22:00 21.0 24:00 17.0;;set HM_XXX_Clima tempListWed prep 06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0;;set HM_XXX_Clima tempListSat prep 07:00 17.0 22:00 21.0 24:00 17.0;;set HM_XXX_Clima tempListSun exec 07:00 17.0 22:00 21.0 24:00 17.0 : To many arguments, max 13 pairs
Edit: Habe FHEM neu gestartet und nur einen Eintrag bearbeitet und gespeichert => geht.
Edit 2: Zwei Einträge bearbeitet:
Zitat2016.01.08 16:24:38 3: set HM_XXX_Clima tempListMon prep 06:00 17.0 08:30 21.0 17:00 17.0 22:00 21.0 24:00 17.0;;set HM_XXX_Clima tempListFri exec 06:00 17.0 08:30 21.0 17:00 17.0 22:00 21.0 24:00 17.0 : Bad format, use HH:MM TEMP ...
Edit 3:
Zitat2016.01.08 16:26:12 1: PERL WARNING: Use of uninitialized value $temps[0] in substitution (s///) at ./FHEM/98_weekprofile.pm line 124.
2016.01.08 16:26:13 3: CUL_HM set HM_XXX_Clima tempListFri exec 06:00 17.0 08:30 21.0 17:00 17.0 22:00 21.0 24:00 17.0
Also für HM müsste mal jemand die richtige Befehlssyntax zuliefern. Die Einschränkung von 13 steht meiner Meinung nach auch nirgends.
Zu Edit 3: Schaue ich mir an.
Zitat von: VolkerGBenner am 08 Januar 2016, 12:03:18
habe gerade gemerkt, dass es noch sinnvoll sein könnte, die (weekprofile**.cfg)s mit in den "rename"-Befehl einbeziehen zu lassen.
Nur so um alles rund zu machen.
Rename vom Master device und vom Modul selbst wir noch nicht unterstützt. Hab es aber notiert.
Zitat von: Risiko am 08 Januar 2016, 18:35:43
Rename vom Master device und vom Modul selbst wir noch nicht unterstützt. Hab es aber notiert.
Also ich meinte jetzt, dass wenn ich eins meiner Geräte über "rename <device>" umbenenne, auch die Einträge in den Wochenprofilen in den weekprofile.cfg-Dateien mit geändert werden müssen. Sonst findet weekprofile seine master nicht nicht mehr.
ZitatAlso für HM müsste mal jemand die richtige Befehlssyntax zuliefern. Die Einschränkung von 13 steht meiner Meinung nach auch nirgends.
Also bei der hmtl-gui-Variante funktioniert es bei mir und es wird Folgendes angezeigt:
set EG.WZ.HZ_ClimRT_tr tempListMon prep 12:00 17 22:00 21 24:00 17; set EG.WZ.HZ_ClimRT_tr tempListTue prep 12:00 17 22:00 21 24:00 17; set EG.WZ.HZ_ClimRT_tr tempListWed prep 12:00 17 22:00 21 24:00 17; set EG.WZ.HZ_ClimRT_tr tempListThu prep 12:00 17 22:00 21 24:00 17; set EG.WZ.HZ_ClimRT_tr tempListFri prep 12:00 17 23:00 21 24:00 17; set EG.WZ.HZ_ClimRT_tr tempListSat prep 07:00 17 23:00 21 24:00 17; set EG.WZ.HZ_ClimRT_tr tempListSun exec 07:00 17 22:00 21 24:00 17
So,
das sagt mir die fhem.cfg, wenn ich versuche ein Wochenprofil, erstellt mit Hilfe des Default-Profils von weekProfile, an das Device zu senden:
2016.01.08 22:45:02 3: WARNING master device Badezimmer_WT_042d7c has no day profile for Mon - create default
2016.01.08 22:45:02 3: WARNING master device Badezimmer_WT_042d7c has no day profile for Tue - create default
2016.01.08 22:45:02 3: WARNING master device Badezimmer_WT_042d7c has no day profile for Wed - create default
2016.01.08 22:45:02 3: WARNING master device Badezimmer_WT_042d7c has no day profile for Thu - create default
2016.01.08 22:45:02 3: WARNING master device Badezimmer_WT_042d7c has no day profile for Fri - create default
2016.01.08 22:45:02 3: WARNING master device Badezimmer_WT_042d7c has no day profile for Sat - create default
2016.01.08 22:45:02 3: WARNING master device Badezimmer_WT_042d7c has no day profile for Sun - create default
2016.01.08 22:45:04 3: WARNING master device Badezimmer_WT_042d7c has no day profile for Mon - create default
2016.01.08 22:45:04 3: WARNING master device Badezimmer_WT_042d7c has no day profile for Tue - create default
2016.01.08 22:45:04 3: WARNING master device Badezimmer_WT_042d7c has no day profile for Wed - create default
2016.01.08 22:45:04 3: WARNING master device Badezimmer_WT_042d7c has no day profile for Thu - create default
2016.01.08 22:45:04 3: WARNING master device Badezimmer_WT_042d7c has no day profile for Fri - create default
2016.01.08 22:45:04 3: WARNING master device Badezimmer_WT_042d7c has no day profile for Sat - create default
2016.01.08 22:45:04 3: WARNING master device Badezimmer_WT_042d7c has no day profile for Sun - create default
2016.01.08 22:45:04 3: WARNING master device Badezimmer_WT_042d7c has no day profile for Mon - create default
2016.01.08 22:45:04 3: WARNING master device Badezimmer_WT_042d7c has no day profile for Tue - create default
2016.01.08 22:45:04 3: WARNING master device Badezimmer_WT_042d7c has no day profile for Wed - create default
2016.01.08 22:45:04 3: WARNING master device Badezimmer_WT_042d7c has no day profile for Thu - create default
2016.01.08 22:45:04 3: WARNING master device Badezimmer_WT_042d7c has no day profile for Fri - create default
2016.01.08 22:45:04 3: WARNING master device Badezimmer_WT_042d7c has no day profile for Sat - create default
2016.01.08 22:45:04 3: WARNING master device Badezimmer_WT_042d7c has no day profile for Sun - create default
Solange nicht durch manuelle Eingabe in der Eingabezeile oder durch autocreate ein Wochenprofil im/zum Device angelegt wurde, scheint "(ich weiß jetzt grad nicht welche Instanz)" das nicht zu akzeptieren. Oder kommt die Meldung von weekProfile?
Ich habe erst das master-Profil in ein anderes Profil kopiert und das dann an das Device gesendet.
Zitat von: VolkerGBenner am 08 Januar 2016, 22:56:11
Oder kommt die Meldung von weekProfile?
Ja. Es wird versucht das aktuelle Profil vom device auszulesen, um nur Änderungen zu Übertragen. Beim Auslesen wird aber festgestellt, dass es kein Profil für jeden Tag gibt.
Wenn es dann einmal übertragen ist, sollte das nicht mehr kommen.
Ich bekomme jetzt aber irgendwie auch manuell kein "set .. weekProfile ..." übertragen. Bringt mir die gleiche Fehlermeldung. Da könnte dann auch bei mir der Fehler noch woanders liegen. :-(
Neue Funktionalität:
Kopieren zu anderen weekprofile Instanzen
Profile können zu anderen weekprofile Instanzen gesendet werden.
Device-Liste mit Mehrfachauswahl:
Es werden alle unterstützen Geräte mit Alias Namen angezeigt. Das assoziierte master device ist vorausgewählt.
Zum zusätzlichen eintragen muss wie gehabt der Name und nicht der Alias des Gerätes verwendet werden. Sollte aber nicht mehr erforderlich sein.
Es kann somit ein Profil an mehrere Geräte gesendet werden.
Zitat von: VolkerGBenner am 09 Januar 2016, 00:27:59
Ich bekomme jetzt aber irgendwie auch manuell kein "set .. weekProfile ..." übertragen. Bringt mir die gleiche Fehlermeldung. Da könnte dann auch bei mir der Fehler noch woanders liegen. :-(
Sehe nur eine Warnung und kein Fehler. Weiß leider noch nicht so richtig, was du meinst.
Super das mit der Vorauswahl des Devices :)
Evtl noch ein Hinweis für alle die nach dem Update keine Profile mehr sehen, einmal STRG + F5 drücken
Bei HM (HM-CC-RT-DN) kommt leider weiterhin:
2016.01.09 09:07:25 3: set EG.KU.HZ_ClimRT_tr tempListMon prep 12:00 17.0 20:00 19.0 24:00 17.0;;set EG.KU.HZ_ClimRT_tr tempListTue prep 12:00 17.0 20:00 19.0 24:00 17.0;;set EG.KU.HZ_ClimRT_tr tempListWed prep 12:00 17.0 20:00 19.0 24:00 17.0;;set EG.KU.HZ_ClimRT_tr tempListThu prep 12:00 17.0 20:00 19.0 24:00 17.0;;set EG.KU.HZ_ClimRT_tr tempListFri exec 12:00 17.0 20:00 19.0 24:00 17.0 : To many arguments, max 13 pairs
Liegt es evtl. an den doppelten Semikolon's?
Diese Syntax funktioniert:
set EG.WZ.HZ_ClimRT_tr tempListMon prep 12:00 17 22:00 21 24:00 17; set EG.WZ.HZ_ClimRT_tr tempListTue prep 12:00 17 22:00 21 24:00 17; set EG.WZ.HZ_ClimRT_tr tempListWed prep 12:00 17 22:00 21 24:00 17; set EG.WZ.HZ_ClimRT_tr tempListThu prep 12:00 17 22:00 21 24:00 17; set EG.WZ.HZ_ClimRT_tr tempListFri prep 12:00 17 23:00 21 24:00 17; set EG.WZ.HZ_ClimRT_tr tempListSat prep 07:00 17 23:00 21 24:00 17; set EG.WZ.HZ_ClimRT_tr tempListSun exec 07:00 17 22:00 21 24:00 17
Zitat von: Papaloewe am 09 Januar 2016, 09:49:19
Liegt es evtl. an den doppelten Semikolon's?
Hab es geändert und eingecheckt. Bitte mal testen.
Zwecks der neuen "Senden an" Funktion, da bedarf es noch etwas Feintuning ;)
Die rot markierten im Screenshot sollte da nicht drin erscheinen,
die grün markierten sind OK und
die ohne Markierung, also die anderen Weekprofile könnten evtl in einem anderen Menüpunkt untergebracht werden.
ZitatHab es geändert und eingecheckt. Bitte mal testen.
ok, HM scheint jetzt zu funktionieren:
2016.01.10 11:20:21 3: CUL_HM set EG.KU.HZ_ClimRT_tr tempListMon prep 12:00 17.0 20:00 19.0 24:00 17.0
2016.01.10 11:20:21 3: CUL_HM set EG.KU.HZ_ClimRT_tr tempListTue prep 12:00 17.0 20:00 19.0 24:00 17.0
2016.01.10 11:20:21 3: CUL_HM set EG.KU.HZ_ClimRT_tr tempListWed prep 12:00 17.0 20:00 19.0 24:00 17.0
2016.01.10 11:20:21 3: CUL_HM set EG.KU.HZ_ClimRT_tr tempListThu prep 12:00 17.0 20:00 19.0 24:00 17.0
2016.01.10 11:20:22 3: CUL_HM set EG.KU.HZ_ClimRT_tr tempListFri exec 12:00 17.0 20:00 19.0 24:00 17.0Vielen Dank.
Zitat von: Afterburner am 09 Januar 2016, 20:31:33
Zwecks der neuen "Senden an" Funktion, da bedarf es noch etwas Feintuning ;)
Die rot markierten im Screenshot sollte da nicht drin erscheinen,
die grün markierten sind OK und
die ohne Markierung, also die anderen Weekprofile könnten evtl in einem anderen Menüpunkt untergebracht werden.
Also die Shutterkontakte sollte mit der letzten Version nicht mehr auftauchen.
Hättest du auch einen Vorschlag für eines anderen Menüpunkt? Ich finde es dort eigentlich passend. Evtl. könnte man die Typen unterschiedlich Darstellen.
Jupp Fensterkontakte sind raus, Wettersensor, Klingelsensor, Steckdose noch nicht.
Wegen dem Menüpunkt, ich würde das hinter das + legen denn Du kopierst das Profil ja in ein andere Profil und + ist fürs kopieren gedacht
Zitat von: Afterburner am 10 Januar 2016, 15:44:39
Jupp Fensterkontakte sind raus, Wettersensor, Klingelsensor, Steckdose noch nicht.
Was sind das für Devices, Homatic?
Zitat von: Afterburner am 10 Januar 2016, 15:44:39
Wegen dem Menüpunkt, ich würde das hinter das + legen denn Du kopierst das Profil ja in ein andere Profil und + ist fürs kopieren gedacht
Ist was dran. Werde nochmal darüber schlafen ;)
ZitatIst was dran. Werde nochmal darüber schlafen
kannst du beim schlafen denken ? ^^
ZitatArbeitszimmer.Steckdose
Arbeitszimmer.Steckdose_SenPwr
Arbeitszimmer.Steckdose_SenF
Arbeitszimmer.Steckdose_Pwr
Arbeitszimmer.Steckdose_SenI
Arbeitszimmer.Steckdose_SenU
Arbeitszimmer.Steckdose_Sw
HomeMatic 130248 Funk-Schaltaktor 1-fach mit Leistungsmessung HM-ES-PMSw1-Pl
http://www.fhemwiki.de/wiki/HM-ES-PMSw1-Pl_Funk-Schaltaktor_1-fach_mit_Leistungsmessung
ZitatHM.Flur.Klingelsensor
HomeMatic Klingelsensor HM-Sen-DB-PCB
ZitatWetter.Sensor
Das ist der Universalsensor von Dirk hier aus dem Forum
ZitatActionDetector
NAME ActionDetector
NTFY_ORDER 50-ActionDetector
TYPE CUL_HM
PS: was passiert eigentlich wenn Du ein Profil an ein anderes Profil schickst und es das Profil schon gibt ? Also den Namen ? ;)
Zitat von: Afterburner am 10 Januar 2016, 16:53:50
PS: was passiert eigentlich wenn Du ein Profil an ein anderes Profil schickst und es das Profil schon gibt ? Also den Namen ? ;)
Wie auch beim Kopieren. Es wird einfach überschrieben.
Ab morgen sollten dann wirklich nur noch Thermostate in der Deviceliste sein.
Ich habe noch folgendes Problem
Buero Parameter SyntaxError: JSON.parse: unexpected keyword at line 1 column 1 of the JSON data
Und bekomme im Raum Buero NUR die drei Zahnräder.
Ich habe folgendes in der cfg
#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
# TEST ---------------
define Buero weekprofile Hzg_Buero
attr Buero room Wochenprofil
den ersten Teil habe ich auskommentiet wegen der eingestellten Unterstützung und dem...hier gehts weiter
Mein HT ist das Hzg_Buero
Was fehlt mir?
Hallo.
libjson-perl installieren.
Hab ich gemacht, erst mit den eben gemachten heutigen Update habe ich die ersten Erfolge. Dieser Part
define Wohnzimmer weekprofile Hzg_WZ_RE
define Wohnzimmer weekprofile Hzg_WZ_LI
attr Wohnzimmer room Wochenprofil
geht wohl so nicht, um beide Regler zu beeinflussen.
btw kann ich auch mein WT als WT_WZ damit beeinflussen?
Hallo stgeran,
verstehe leider nicht, was du meinst.
Du kannst doch nicht zwei Instanzen (2xdefine) mit dem gleichen Namen "Wohnzimmer" anlegen!!!
Ah, jetzt hab ich das schon mal begriffen. Darf die instanz genau so benannt werder wie das device? z.B.
define Hzg_WZ_RE weekprofile Hzg_WZ_RE
Zitat von: stgeran am 13 Januar 2016, 19:47:32
Ah, jetzt hab ich das schon mal begriffen. Darf die instanz genau so benannt werder wie das device? z.B.
define Hzg_WZ_RE weekprofile Hzg_WZ_RE
Nein, auch das wird nicht gehen (zumindest wenn dein Thermostat auch Hzg_WZ_RE heißt), der Name nach dem define ist ein eindeutiger Identifier für alle in fhem bekannten Entitäten, unabhängig von ihrem Typ.
OK, danke, war nur so ne Idee um die Begriffanzahl klein zu halten.
Wiki-Artikel von Reiner begonnnen. Vielen Dank.
http://www.fhemwiki.de/wiki/Weekprofile
Danke für das Modul, mir ist nur noch nicht so klar, was ich als Master angebe, oft stoße ich auf ein leeres Profil (nur Zahnräder und Überschrift), klicke ich auf die Zahnräder kommt 'ne leere Seite...
Kann man auch (optional) die Wochentage Mo-Fr zusammenlegen? Würde einige Klicks sparen.
Wo werden die Daten gespeichert?
Viele Grüße
Sebastian
Zitat von: szoller am 20 Januar 2016, 08:22:11
Danke für das Modul, mir ist nur noch nicht so klar, was ich als Master angebe, oft stoße ich auf ein leeres Profil (nur Zahnräder und Überschrift), klicke ich auf die Zahnräder kommt 'ne leere Seite...
Verstehe ich leider nicht ganz. Leer darf es nicht sein. Entweder ein Default-Profil, wenn das Device nicht ausgelesen werden konnte oder eben das Profil vom Device.
Steht was dazu im Log?
Zitat von: szoller am 20 Januar 2016, 08:22:11
Kann man auch (optional) die Wochentage Mo-Fr zusammenlegen? Würde einige Klicks sparen.
Ist in Planung.
Zitat von: szoller am 20 Januar 2016, 08:22:11
Wo werden die Daten gespeichert?
Default im Log Ordner. Siehe Attribute configFile
Risiko
ZitatVerstehe ich leider nicht ganz. Leer darf es nicht sein. Entweder ein Default-Profil, wenn das Device nicht ausgelesen werden konnte oder eben das Profil vom Device.
Steht was dazu im Log?
Ich versuch mal Screenshots zu machen :-)
ZitatIst in Planung.
Super! :-)
ZitatDefault im Log Ordner. Siehe Attribute configFile
Okay... gefunden. Dann werd ich's mal anpassen bei mir 8)
Das Problem mit "nur Zahnräder und Überschrift" gibts bei mir auch.
Taucht bei mir manchmal auf und geht erst nach einem Neustart wieder weg.
Die Fhem Logdatei sagt dazu erstmal nichts, aber auf der Weboberfläche gibt es oben kurz eine Meldung:
HeatProfile_OG_Kind Parameter SyntaxError: JSON.parse: unexpected character at line 1 column 1 of the JSON data
Anbei noch mal ein Screenshot der fehlerhaften Darstellung:
Hi.
HeatProfile_OG_Kind ist vom Typ weekprofile?
Dann benötige ich im Fehlerfall mal die Infos von list HeatProfile_OG_Kind
und HeatProfile_OG_Kind get profile_data <names des Wochenplans> wahrscheinlich master.
Tritt der Fehler immer auf oder kann man da irgendwas einschränken?
Die Meldung deutet auf Fehlerhafte Wochenprofildaten hin. Das Parsen der json-Daten im Javascript schlägt fehl.
Bitte auch mal die Console im Browser öffnen und schauen, ob da Fehler zu sehen sind.
In Chrome geht das unter "Weitere Tools" --> "Entwicklertools" oder rechte Maustaste "Prüfen" und dann auf Console.
Risiko
list HeatProfile_OG_Kind
Internals:
DEF Temp_OG_Kind_Climate
NAME HeatProfile_OG_Kind
NR 425
NTFY_ORDER 50-HeatProfile_OG_Kind
STATE defined
TYPE weekprofile
Masterdev:
NAME Temp_OG_Kind_Climate
PROFILES:
Readings:
2016-01-21 20:20:47 profile_count 1
2016-01-19 18:53:31 state assigned
SNDDEVLIST:
Attributes:
alias Wochenplan OG Kind
room Heizung
widgetEditOnNewPage 1
get HeatProfile_OG_Kind profile_data master
Steht nicht zu Auswahl während der Fehler ansteht. Nach dem Neustart geht es wieder problemlos.
(siehe Screenshot unten...)
Die Konsole im Firefox wirft folgendes aus:
12:22:40.331 FW_queryValue:get HeatProfile_EG_Flur profile_data fhemweb.js:232:5
12:22:40.333 FW_cmd:/fhem?cmd={AttrVal("HeatProfile_EG_Flur","widgetWeekdays","")}&XHR=1 fhemweb.js:232:5
12:22:40.336 FW_cmd:/fhem?cmd=get HeatProfile_EG_Flur profile_names&XHR=1 fhemweb.js:232:5
12:22:40.339 FW_queryValue:get HeatProfile_EG_WC profile_data fhemweb.js:232:5
12:22:40.341 FW_cmd:/fhem?cmd={AttrVal("HeatProfile_EG_WC","widgetWeekdays","")}&XHR=1 fhemweb.js:232:5
12:22:40.342 FW_cmd:/fhem?cmd=get HeatProfile_EG_WC profile_names&XHR=1 fhemweb.js:232:5
12:22:40.346 FW_queryValue:get HeatProfile_EG_WohnZ profile_data fhemweb.js:232:5
12:22:40.347 FW_cmd:/fhem?cmd={AttrVal("HeatProfile_EG_WohnZ","widgetWeekdays","")}&XHR=1 fhemweb.js:232:5
12:22:40.349 FW_cmd:/fhem?cmd=get HeatProfile_EG_WohnZ profile_names&XHR=1 fhemweb.js:232:5
12:22:40.352 FW_queryValue:get HeatProfile_OG_Bad profile_data fhemweb.js:232:5
12:22:40.354 FW_cmd:/fhem?cmd={AttrVal("HeatProfile_OG_Bad","widgetWeekdays","")}&XHR=1 fhemweb.js:232:5
12:22:40.356 FW_cmd:/fhem?cmd=get HeatProfile_OG_Bad profile_names&XHR=1 fhemweb.js:232:5
12:22:40.359 FW_queryValue:get HeatProfile_OG_Buero profile_data fhemweb.js:232:5
12:22:40.360 FW_cmd:/fhem?cmd={AttrVal("HeatProfile_OG_Buero","widgetWeekdays","")}&XHR=1 fhemweb.js:232:5
12:22:40.362 FW_cmd:/fhem?cmd=get HeatProfile_OG_Buero profile_names&XHR=1 fhemweb.js:232:5
12:22:40.365 FW_queryValue:get HeatProfile_OG_Kind profile_data fhemweb.js:232:5
12:22:40.367 FW_cmd:/fhem?cmd={AttrVal("HeatProfile_OG_Kind","widgetWeekdays","")}&XHR=1 fhemweb.js:232:5
12:22:40.368 FW_cmd:/fhem?cmd=get HeatProfile_OG_Kind profile_names&XHR=1 fhemweb.js:232:5
12:22:40.521 Longpoll with filter room=Heizung fhemweb.js:232:5
nicht wohlgeformt <unbekannt>:1:153
HeatProfile_EG_Flur error parsing json 'usage: profile_data <name>' fhemweb_weekprofile.js:480:5
12:22:40.862 ERRMSG:HeatProfile_EG_Flur Parameter SyntaxError: JSON.parse: unexpected character at line 1 column 1 of the JSON data< fhemweb.js:232:5
HeatProfile_EG_WC error parsing json 'usage: profile_data <name>' fhemweb_weekprofile.js:480:5
12:22:40.916 ERRMSG:HeatProfile_EG_WC Parameter SyntaxError: JSON.parse: unexpected character at line 1 column 1 of the JSON data< fhemweb.js:232:5
nicht wohlgeformt <unbekannt>:1:153
HeatProfile_EG_WohnZ error parsing json 'usage: profile_data <name>' fhemweb_weekprofile.js:480:5
12:22:40.990 ERRMSG:HeatProfile_EG_WohnZ Parameter SyntaxError: JSON.parse: unexpected character at line 1 column 1 of the JSON data< fhemweb.js:232:5
HeatProfile_OG_Bad error parsing json 'usage: profile_data <name>' fhemweb_weekprofile.js:480:5
12:22:40.999 ERRMSG:HeatProfile_OG_Bad Parameter SyntaxError: JSON.parse: unexpected character at line 1 column 1 of the JSON data< fhemweb.js:232:5
nicht wohlgeformt <unbekannt>:1:153
HeatProfile_OG_Buero error parsing json 'usage: profile_data <name>' fhemweb_weekprofile.js:480:5
12:22:41.081 ERRMSG:HeatProfile_OG_Buero Parameter SyntaxError: JSON.parse: unexpected character at line 1 column 1 of the JSON data< fhemweb.js:232:5
nicht wohlgeformt <unbekannt>:1:153
HeatProfile_OG_Kind error parsing json 'usage: profile_data <name>' fhemweb_weekprofile.js:480:5
12:22:41.105 ERRMSG:HeatProfile_OG_Kind Parameter SyntaxError: JSON.parse: unexpected character at line 1 column 1 of the JSON data< fhemweb.js:232:5
nicht wohlgeformt <unbekannt>:1:153
12:22:41.129 Rcvd: fhemweb.js:232:5
12:22:45.872 ERRMSG:< fhemweb.js:232:5
12:22:45.939 ERRMSG:< fhemweb.js:232:5
12:22:46.000 ERRMSG:< fhemweb.js:232:5
12:22:46.010 ERRMSG:< fhemweb.js:232:5
12:22:46.093 ERRMSG:< fhemweb.js:232:5
12:22:46.125 ERRMSG:< fhemweb.js:232:5
12:22:55.650 Rcvd: ["Heat_EG_Kueche_Clima","T: 20.3 desired: 19.0 valve: 0","<div id=\"Heat_EG_Kueche_Clima\" class=\"col2\">T: 20.3 desired: 19.0 val...(145) fhemweb.js:232:5
12:22:55.653 Rcvd: ["Heat_EG_Kueche_Clima-ValvePosition","0","0"] fhemweb.js:232:5
12:22:55.655 Rcvd: ["Heat_EG_Kueche_Clima-ValvePosition-ts","2016-01-22 12:22:55","2016-01-22 12:22:55"] fhemweb.js:232:5
12:22:55.656 Rcvd: ["Heat_EG_Kueche_Clima-boostTime","-","-"] fhemweb.js:232:5
12:22:55.658 Rcvd: ["Heat_EG_Kueche_Clima-boostTime-ts","2016-01-22 12:22:55","2016-01-22 12:22:55"] fhemweb.js:232:5
12:22:55.659 Rcvd: ["Heat_EG_Kueche_Clima-controlMode","auto","auto"] fhemweb.js:232:5
12:22:55.660 Rcvd: ["Heat_EG_Kueche_Clima-controlMode-ts","2016-01-22 12:22:55","2016-01-22 12:22:55"] fhemweb.js:232:5
12:22:55.661 Rcvd: ["Heat_EG_Kueche_Clima-desired-temp","19.0","19.0"] fhemweb.js:232:5
12:22:55.663 Rcvd: ["Heat_EG_Kueche_Clima-desired-temp-ts","2016-01-22 12:22:55","2016-01-22 12:22:55"] fhemweb.js:232:5
12:22:55.664 Rcvd: ["Heat_EG_Kueche_Clima-measured-temp","20.3","20.3"] fhemweb.js:232:5
12:22:55.666 Rcvd: ["Heat_EG_Kueche_Clima-measured-temp-ts","2016-01-22 12:22:55","2016-01-22 12:22:55"] fhemweb.js:232:5
12:22:55.667 Rcvd: ["Heat_EG_Kueche_Clima-partyEnd","-","-"] fhemweb.js:232:5
12:22:55.668 Rcvd: ["Heat_EG_Kueche_Clima-partyEnd-ts","2016-01-22 12:22:55","2016-01-22 12:22:55"] fhemweb.js:232:5
12:22:55.669 Rcvd: ["Heat_EG_Kueche_Clima-partyStart","-","-"] fhemweb.js:232:5
12:22:55.669 Rcvd: ["Heat_EG_Kueche_Clima-partyStart-ts","2016-01-22 12:22:55","2016-01-22 12:22:55"] fhemweb.js:232:5
12:22:55.670 Rcvd: ["Heat_EG_Kueche_Clima-partyTemp","-","-"] fhemweb.js:232:5
12:22:55.670 Rcvd: ["Heat_EG_Kueche_Clima-partyTemp-ts","2016-01-22 12:22:55","2016-01-22 12:22:55"] fhemweb.js:232:5
12:22:55.671 Rcvd: ["Heat_EG_Kueche_Clima-T","20.3 desired: 19.0 valve: 0","20.3 desired: 19.0 valve: 0"] fhemweb.js:232:5
12:22:55.671 Rcvd: ["Heat_EG_Kueche_Clima-T-ts","2016-01-22 12:22:55","2016-01-22 12:22:55"] fhemweb.js:232:5
12:22:55.672 Rcvd: ["Heat_EG_Kueche_Clima-state","T: 20.3 desired: 19.0 valve: 0","T: 20.3 desired: 19.0 valve: 0"] fhemweb.js:232:5
12:22:55.672 Rcvd: ["Heat_EG_Kueche_Clima-state-ts","2016-01-22 12:22:55","2016-01-22 12:22:55"] fhemweb.js:232:5
12:23:08.613 Rcvd: ["Heat_EG_Flur_Clima","T: 19.3 desired: 17.0 valve: 0","<div id=\"Heat_EG_Flur_Clima\" class=\"col2\">T: 19.3 desired: 17.0 valve: ...(141) fhemweb.js:232:5
12:23:08.614 Rcvd: ["Heat_EG_Flur_Clima-ValvePosition","0","0"] fhemweb.js:232:5
12:23:08.615 Rcvd: ["Heat_EG_Flur_Clima-ValvePosition-ts","2016-01-22 12:23:08","2016-01-22 12:23:08"] fhemweb.js:232:5
12:23:08.615 Rcvd: ["Heat_EG_Flur_Clima-boostTime","-","-"] fhemweb.js:232:5
12:23:08.616 Rcvd: ["Heat_EG_Flur_Clima-boostTime-ts","2016-01-22 12:23:08","2016-01-22 12:23:08"] fhemweb.js:232:5
12:23:08.616 Rcvd: ["Heat_EG_Flur_Clima-controlMode","auto","auto"] fhemweb.js:232:5
12:23:08.617 Rcvd: ["Heat_EG_Flur_Clima-controlMode-ts","2016-01-22 12:23:08","2016-01-22 12:23:08"] fhemweb.js:232:5
12:23:08.617 Rcvd: ["Heat_EG_Flur_Clima-desired-temp","17.0","17.0"] fhemweb.js:232:5
12:23:08.618 Rcvd: ["Heat_EG_Flur_Clima-desired-temp-ts","2016-01-22 12:23:08","2016-01-22 12:23:08"] fhemweb.js:232:5
12:23:08.619 Rcvd: ["Heat_EG_Flur_Clima-measured-temp","19.3","19.3"] fhemweb.js:232:5
12:23:08.619 Rcvd: ["Heat_EG_Flur_Clima-measured-temp-ts","2016-01-22 12:23:08","2016-01-22 12:23:08"] fhemweb.js:232:5
12:23:08.620 Rcvd: ["Heat_EG_Flur_Clima-partyEnd","-","-"] fhemweb.js:232:5
12:23:08.620 Rcvd: ["Heat_EG_Flur_Clima-partyEnd-ts","2016-01-22 12:23:08","2016-01-22 12:23:08"] fhemweb.js:232:5
12:23:08.620 Rcvd: ["Heat_EG_Flur_Clima-partyStart","-","-"] fhemweb.js:232:5
12:23:08.621 Rcvd: ["Heat_EG_Flur_Clima-partyStart-ts","2016-01-22 12:23:08","2016-01-22 12:23:08"] fhemweb.js:232:5
12:23:08.621 Rcvd: ["Heat_EG_Flur_Clima-partyTemp","-","-"] fhemweb.js:232:5
12:23:08.622 Rcvd: ["Heat_EG_Flur_Clima-partyTemp-ts","2016-01-22 12:23:08","2016-01-22 12:23:08"] fhemweb.js:232:5
12:23:08.622 Rcvd: ["Heat_EG_Flur_Clima-T","19.3 desired: 17.0 valve: 0","19.3 desired: 17.0 valve: 0"] fhemweb.js:232:5
12:23:08.622 Rcvd: ["Heat_EG_Flur_Clima-T-ts","2016-01-22 12:23:08","2016-01-22 12:23:08"] fhemweb.js:232:5
12:23:08.623 Rcvd: ["Heat_EG_Flur_Clima-state","T: 19.3 desired: 17.0 valve: 0","T: 19.3 desired: 17.0 valve: 0"] fhemweb.js:232:5
12:23:08.624 Rcvd: ["Heat_EG_Flur_Clima-state-ts","2016-01-22 12:23:08","2016-01-22 12:23:08"] fhemweb.js:232:5
12:23:26.809 Rcvd: ["Heat_EG_WohnZ_Clima","T: 20.3 desired: 19.0 valve: 0","<div id=\"Heat_EG_WohnZ_Clima\" class=\"col2\">T: 20.3 desired: 19.0 valve...(143) fhemweb.js:232:5
12:23:26.814 Rcvd: ["Heat_EG_WohnZ_Clima-ValvePosition","0","0"] fhemweb.js:232:5
12:23:26.817 Rcvd: ["Heat_EG_WohnZ_Clima-ValvePosition-ts","2016-01-22 12:23:26","2016-01-22 12:23:26"] fhemweb.js:232:5
12:23:26.820 Rcvd: ["Heat_EG_WohnZ_Clima-boostTime","-","-"] fhemweb.js:232:5
12:23:26.822 Rcvd: ["Heat_EG_WohnZ_Clima-boostTime-ts","2016-01-22 12:23:26","2016-01-22 12:23:26"] fhemweb.js:232:5
12:23:26.824 Rcvd: ["Heat_EG_WohnZ_Clima-controlMode","auto","auto"] fhemweb.js:232:5
12:23:26.827 Rcvd: ["Heat_EG_WohnZ_Clima-controlMode-ts","2016-01-22 12:23:26","2016-01-22 12:23:26"] fhemweb.js:232:5
12:23:26.830 Rcvd: ["Heat_EG_WohnZ_Clima-desired-temp","19.0","19.0"] fhemweb.js:232:5
12:23:26.833 Rcvd: ["Heat_EG_WohnZ_Clima-desired-temp-ts","2016-01-22 12:23:26","2016-01-22 12:23:26"] fhemweb.js:232:5
12:23:26.835 Rcvd: ["Heat_EG_WohnZ_Clima-measured-temp","20.3","20.3"] fhemweb.js:232:5
12:23:26.837 Rcvd: ["Heat_EG_WohnZ_Clima-measured-temp-ts","2016-01-22 12:23:26","2016-01-22 12:23:26"] fhemweb.js:232:5
12:23:26.839 Rcvd: ["Heat_EG_WohnZ_Clima-partyEnd","-","-"] fhemweb.js:232:5
12:23:26.840 Rcvd: ["Heat_EG_WohnZ_Clima-partyEnd-ts","2016-01-22 12:23:26","2016-01-22 12:23:26"] fhemweb.js:232:5
12:23:26.840 Rcvd: ["Heat_EG_WohnZ_Clima-partyStart","-","-"] fhemweb.js:232:5
12:23:26.841 Rcvd: ["Heat_EG_WohnZ_Clima-partyStart-ts","2016-01-22 12:23:26","2016-01-22 12:23:26"] fhemweb.js:232:5
12:23:26.842 Rcvd: ["Heat_EG_WohnZ_Clima-partyTemp","-","-"] fhemweb.js:232:5
12:23:26.842 Rcvd: ["Heat_EG_WohnZ_Clima-partyTemp-ts","2016-01-22 12:23:26","2016-01-22 12:23:26"] fhemweb.js:232:5
12:23:26.843 Rcvd: ["Heat_EG_WohnZ_Clima-T","20.3 desired: 19.0 valve: 0","20.3 desired: 19.0 valve: 0"] fhemweb.js:232:5
12:23:26.844 Rcvd: ["Heat_EG_WohnZ_Clima-T-ts","2016-01-22 12:23:26","2016-01-22 12:23:26"] fhemweb.js:232:5
12:23:26.844 Rcvd: ["Heat_EG_WohnZ_Clima-state","T: 20.3 desired: 19.0 valve: 0","T: 20.3 desired: 19.0 valve: 0"] fhemweb.js:232:5
12:23:26.845 Rcvd: ["Heat_EG_WohnZ_Clima-state-ts","2016-01-22 12:23:26","2016-01-22 12:23:26"] fhemweb.js:232:5
12:23:31.325 Rcvd: ["Temp_OG_Kind_Climate","T: 19.8 desired: 19.0","<div id=\"Temp_OG_Kind_Climate\" class=\"col2\">T: 19.8 desired: 19.0</div>"] fhemweb.js:232:5
12:23:31.330 Rcvd: ["Temp_OG_Kind_Climate-desired-temp","19.0","19.0"] fhemweb.js:232:5
12:23:31.334 Rcvd: ["Temp_OG_Kind_Climate-desired-temp-ts","2016-01-22 12:23:31","2016-01-22 12:23:31"] fhemweb.js:232:5
12:23:31.336 Rcvd: ["Temp_OG_Kind_Climate-humidity","55","55"] fhemweb.js:232:5
12:23:31.339 Rcvd: ["Temp_OG_Kind_Climate-humidity-ts","2016-01-22 12:23:31","2016-01-22 12:23:31"] fhemweb.js:232:5
12:23:31.340 Rcvd: ["Temp_OG_Kind_Climate-measured-temp","19.8","19.8"] fhemweb.js:232:5
12:23:31.344 Rcvd: ["Temp_OG_Kind_Climate-measured-temp-ts","2016-01-22 12:23:31","2016-01-22 12:23:31"] fhemweb.js:232:5
12:23:31.346 Rcvd: ["Temp_OG_Kind_Climate-T","19.8 desired: 19.0","19.8 desired: 19.0"] fhemweb.js:232:5
12:23:31.348 Rcvd: ["Temp_OG_Kind_Climate-T-ts","2016-01-22 12:23:31","2016-01-22 12:23:31"] fhemweb.js:232:5
12:23:31.350 Rcvd: ["Temp_OG_Kind_Climate-state","T: 19.8 desired: 19.0","T: 19.8 desired: 19.0"] fhemweb.js:232:5
12:23:31.352 Rcvd: ["Temp_OG_Kind_Climate-state-ts","2016-01-22 12:23:31","2016-01-22 12:23:31"] fhemweb.js:232:5
12:23:39.887 Rcvd: ["Heat_EG_WC_Clima","T: 17.3 desired: 17.0 valve: 0","<div id=\"Heat_EG_WC_Clima\" class=\"col2\">T: 17.3 desired: 17.0 valve: 0</d...(137) fhemweb.js:232:5
12:23:39.892 Rcvd: ["Heat_EG_WC_Clima-ValvePosition","0","0"] fhemweb.js:232:5
12:23:39.895 Rcvd: ["Heat_EG_WC_Clima-ValvePosition-ts","2016-01-22 12:23:36","2016-01-22 12:23:36"] fhemweb.js:232:5
12:23:39.897 Rcvd: ["Heat_EG_WC_Clima-boostTime","-","-"] fhemweb.js:232:5
12:23:39.900 Rcvd: ["Heat_EG_WC_Clima-boostTime-ts","2016-01-22 12:23:36","2016-01-22 12:23:36"] fhemweb.js:232:5
12:23:39.901 Rcvd: ["Heat_EG_WC_Clima-controlMode","auto","auto"] fhemweb.js:232:5
12:23:39.905 Rcvd: ["Heat_EG_WC_Clima-controlMode-ts","2016-01-22 12:23:36","2016-01-22 12:23:36"] fhemweb.js:232:5
12:23:39.906 Rcvd: ["Heat_EG_WC_Clima-desired-temp","17.0","17.0"] fhemweb.js:232:5
12:23:39.910 Rcvd: ["Heat_EG_WC_Clima-desired-temp-ts","2016-01-22 12:23:36","2016-01-22 12:23:36"] fhemweb.js:232:5
12:23:39.911 Rcvd: ["Heat_EG_WC_Clima-measured-temp","17.3","17.3"] fhemweb.js:232:5
12:23:39.913 Rcvd: ["Heat_EG_WC_Clima-measured-temp-ts","2016-01-22 12:23:36","2016-01-22 12:23:36"] fhemweb.js:232:5
12:23:39.916 Rcvd: ["Heat_EG_WC_Clima-partyEnd","-","-"] fhemweb.js:232:5
12:23:39.916 Rcvd: ["Heat_EG_WC_Clima-partyEnd-ts","2016-01-22 12:23:36","2016-01-22 12:23:36"] fhemweb.js:232:5
12:23:39.917 Rcvd: ["Heat_EG_WC_Clima-partyStart","-","-"] fhemweb.js:232:5
12:23:39.917 Rcvd: ["Heat_EG_WC_Clima-partyStart-ts","2016-01-22 12:23:36","2016-01-22 12:23:36"] fhemweb.js:232:5
12:23:39.918 Rcvd: ["Heat_EG_WC_Clima-partyTemp","-","-"] fhemweb.js:232:5
12:23:39.918 Rcvd: ["Heat_EG_WC_Clima-partyTemp-ts","2016-01-22 12:23:36","2016-01-22 12:23:36"] fhemweb.js:232:5
12:23:39.919 Rcvd: ["Heat_EG_WC_Clima-T","17.3 desired: 17.0 valve: 0","17.3 desired: 17.0 valve: 0"] fhemweb.js:232:5
12:23:39.919 Rcvd: ["Heat_EG_WC_Clima-T-ts","2016-01-22 12:23:36","2016-01-22 12:23:36"] fhemweb.js:232:5
12:23:39.920 Rcvd: ["Heat_EG_WC_Clima-state","T: 17.3 desired: 17.0 valve: 0","T: 17.3 desired: 17.0 valve: 0"] fhemweb.js:232:5
12:23:39.920 Rcvd: ["Heat_EG_WC_Clima-state-ts","2016-01-22 12:23:36","2016-01-22 12:23:36"] fhemweb.js:232:5
12:23:43.523 Rcvd: ["Temp_EG_WohnZ_Climate","T: 20.3 desired: 19.0","<div id=\"Temp_EG_WohnZ_Climate\" class=\"col2\">T: 20.3 desired: 19.0</div>"] fhemweb.js:232:5
12:23:43.524 Rcvd: ["Temp_EG_WohnZ_Climate-desired-temp","19.0","19.0"] fhemweb.js:232:5
12:23:43.526 Rcvd: ["Temp_EG_WohnZ_Climate-desired-temp-ts","2016-01-22 12:23:43","2016-01-22 12:23:43"] fhemweb.js:232:5
12:23:43.527 Rcvd: ["Temp_EG_WohnZ_Climate-humidity","52","52"] fhemweb.js:232:5
12:23:43.528 Rcvd: ["Temp_EG_WohnZ_Climate-humidity-ts","2016-01-22 12:23:43","2016-01-22 12:23:43"] fhemweb.js:232:5
12:23:43.529 Rcvd: ["Temp_EG_WohnZ_Climate-measured-temp","20.3","20.3"] fhemweb.js:232:5
12:23:43.530 Rcvd: ["Temp_EG_WohnZ_Climate-measured-temp-ts","2016-01-22 12:23:43","2016-01-22 12:23:43"] fhemweb.js:232:5
12:23:43.530 Rcvd: ["Temp_EG_WohnZ_Climate-T","20.3 desired: 19.0","20.3 desired: 19.0"] fhemweb.js:232:5
12:23:43.531 Rcvd: ["Temp_EG_WohnZ_Climate-T-ts","2016-01-22 12:23:43","2016-01-22 12:23:43"] fhemweb.js:232:5
12:23:43.532 Rcvd: ["Temp_EG_WohnZ_Climate-state","T: 20.3 desired: 19.0","T: 20.3 desired: 19.0"] fhemweb.js:232:5
12:23:43.532 Rcvd: ["Temp_EG_WohnZ_Climate-state-ts","2016-01-22 12:23:43","2016-01-22 12:23:43"] fhemweb.js:232:5
12:23:45.318 Rcvd: ["Heat_OG_Bad_Clima","T: 20.6 desired: 20.0 valve: 0","<div id=\"Heat_OG_Bad_Clima\" class=\"col2\">T: 20.6 desired: 20.0 valve: 0<...(139) fhemweb.js:232:5
12:23:45.319 Rcvd: ["Heat_OG_Bad_Clima-ValvePosition","0","0"] fhemweb.js:232:5
12:23:45.320 Rcvd: ["Heat_OG_Bad_Clima-ValvePosition-ts","2016-01-22 12:23:45","2016-01-22 12:23:45"] fhemweb.js:232:5
12:23:45.321 Rcvd: ["Heat_OG_Bad_Clima-boostTime","-","-"] fhemweb.js:232:5
12:23:45.321 Rcvd: ["Heat_OG_Bad_Clima-boostTime-ts","2016-01-22 12:23:45","2016-01-22 12:23:45"] fhemweb.js:232:5
12:23:45.322 Rcvd: ["Heat_OG_Bad_Clima-controlMode","auto","auto"] fhemweb.js:232:5
12:23:45.323 Rcvd: ["Heat_OG_Bad_Clima-controlMode-ts","2016-01-22 12:23:45","2016-01-22 12:23:45"] fhemweb.js:232:5
12:23:45.323 Rcvd: ["Heat_OG_Bad_Clima-desired-temp","20.0","20.0"] fhemweb.js:232:5
12:23:45.324 Rcvd: ["Heat_OG_Bad_Clima-desired-temp-ts","2016-01-22 12:23:45","2016-01-22 12:23:45"] fhemweb.js:232:5
12:23:45.325 Rcvd: ["Heat_OG_Bad_Clima-measured-temp","20.6","20.6"] fhemweb.js:232:5
12:23:45.326 Rcvd: ["Heat_OG_Bad_Clima-measured-temp-ts","2016-01-22 12:23:45","2016-01-22 12:23:45"] fhemweb.js:232:5
12:23:45.326 Rcvd: ["Heat_OG_Bad_Clima-partyEnd","-","-"] fhemweb.js:232:5
12:23:45.327 Rcvd: ["Heat_OG_Bad_Clima-partyEnd-ts","2016-01-22 12:23:45","2016-01-22 12:23:45"] fhemweb.js:232:5
12:23:45.327 Rcvd: ["Heat_OG_Bad_Clima-partyStart","-","-"] fhemweb.js:232:5
12:23:45.328 Rcvd: ["Heat_OG_Bad_Clima-partyStart-ts","2016-01-22 12:23:45","2016-01-22 12:23:45"] fhemweb.js:232:5
12:23:45.329 Rcvd: ["Heat_OG_Bad_Clima-partyTemp","-","-"] fhemweb.js:232:5
12:23:45.329 Rcvd: ["Heat_OG_Bad_Clima-partyTemp-ts","2016-01-22 12:23:45","2016-01-22 12:23:45"] fhemweb.js:232:5
12:23:45.330 Rcvd: ["Heat_OG_Bad_Clima-T","20.6 desired: 20.0 valve: 0","20.6 desired: 20.0 valve: 0"] fhemweb.js:232:5
12:23:45.330 Rcvd: ["Heat_OG_Bad_Clima-T-ts","2016-01-22 12:23:45","2016-01-22 12:23:45"] fhemweb.js:232:5
12:23:45.331 Rcvd: ["Heat_OG_Bad_Clima-state","T: 20.6 desired: 20.0 valve: 0","T: 20.6 desired: 20.0 valve: 0"] fhemweb.js:232:5
12:23:45.332 Rcvd: ["Heat_OG_Bad_Clima-state-ts","2016-01-22 12:23:45","2016-01-22 12:23:45"] fhemweb.js:232:5
Ich habe noch mal ein bißchen rumgespielt und die Profile scheinen sich wohl immer nach einem "rereadcfg" zu verabschieden.
Zitat von: dirkbalzer am 22 Januar 2016, 09:34:03
Ich habe noch mal ein bißchen rumgespielt und die Profile scheinen sich wohl immer nach einem "rereadcfg" zu verabschieden.
Danke. Das war der passende Hinweis.
Habe es gefixt.
Hi,
danke erst mal für das tolle Modul, ich habe lang nach einer Möglichkeit gesucht die Wochenpläne komfortabel zu editieren.
Folgende Frage noch (ich verwende nur Homematic Geräte): In der Auswahlliste zur Zuweisung erscheinen zwar nur Thermostate, aber mit allen Kanälen, siehe Screenshot. Das macht die Auswahl schon sehr schwierig, zumal die auch nicht alphabetisch geordnet sind.(http://www.bernd-schubart.de/downloads/weekprofile_devices.png).
Sinn machen ja eigentlich nur die Kanäle .Clima beim HM-CC-RT-DN und .Climate beim HM-TC-IT-WM-W-EU, oder?
Achja und dann noch was, beim HM ConfigCheck bekomme ich jetzt Fehlermeldungen, weil die Profile nicht mehr zu dem bei den Geräten hinterlegten ConfigFile passen. Ich habe mir den Thread hier zwar durchgelesen, aber mir ist noch nicht klar wie das in Zukunft sein soll, dass das zusammen passt. Oder muss ich da jetzt was anders machen?
Zitat von: Joker am 23 Januar 2016, 21:55:19
Sinn machen ja eigentlich nur die Kanäle .Clima beim HM-CC-RT-DN und .Climate beim HM-TC-IT-WM-W-EU, oder?
Stimmt.
Wie kann man denn die Kanäle eindeutig unterscheiden? Am Namen sicherlich nicht. Gibt es ein passendes Attribut oder Reading?
Model scheint ja bei allen gleich gesetzt zu sein.
Zitat von: Joker am 23 Januar 2016, 21:55:19
Achja und dann noch was, beim HM ConfigCheck bekomme ich jetzt Fehlermeldungen, weil die Profile nicht mehr zu dem bei den Geräten hinterlegten ConfigFile passen. Ich habe mir den Thread hier zwar durchgelesen, aber mir ist noch nicht klar wie das in Zukunft sein soll, dass das zusammen passt. Oder muss ich da jetzt was anders machen?
Zu ConfigCheck kann ich leider nicht viel sagen. Natürlich passen die Daten nicht mehr, da die Config-Files nicht angepasst werden.
Meinst du bei den Config-Files die von HM-Info?
Ich bin mit martinp876 im Gespräch, wie man das Modul mit HM-Info zusammen bringen kann.
Das wird aber noch etwas dauern. Der genaue Workflow steht noch nicht ganz. Also bitte etwas Geduld.
Risiko.
Die Unterscheidung sollte eigentlich über die Internals ganz einfach sein:
Beim HM-CC-RT-DN ist es chanNo = 04, beim HM-TC-IT-WM-W-EU chanNo = 02.
Im Kanal sollte eigentlich immer im Attribute "model" stehen, ob es ein HM-CC-RT-DN oder ein HM-TC-IT-WM-W-EU ist.
ZitatStimmt.
Wie kann man denn die Kanäle eindeutig unterscheiden? Am Namen sicherlich nicht. Gibt es ein passendes Attribut oder Reading?
Model scheint ja bei allen gleich gesetzt zu sein.
Stimmt, am Namen nicht, den kann man frei vergeben. Das Model sollte immer gleich sein. Wenn ich es richtig sehe (habe kurz in den Code geschaut) verwendest Du das auch aktuell zur Unterscheidung zwischen HM und MAX.
ZitatDie Unterscheidung sollte eigentlich über die Internals ganz einfach sein:
Beim HM-CC-RT-DN ist es chanNo = 04, beim HM-TC-IT-WM-W-EU chanNo = 02.
Stimmt, das sollte in der Tat immer so sein, soweit mir das bekannt ist. Dann könnte man vermutlich über das Model nach RT und IT unterscheiden, und müsste dann noch alles wegfiltern was nicht Kanal 4 bzw 2 ist.
ZitatMeinst du bei den Config-Files die von HM-Info?
Ich bin mit martinp876 im Gespräch, wie man das Modul mit HM-Info zusammen bringen kann.
Das wird aber noch etwas dauern. Der genaue Workflow steht noch nicht ganz. Also bitte etwas Geduld.
Ja ich meine die von HMInfo. Wenn ihr da am basteln seid ist das prima, wollte es nur mal gesagt haben ;-)
Zitat von: Reiner am 24 Januar 2016, 12:05:28
Beim HM-CC-RT-DN ist es chanNo = 04, beim HM-TC-IT-WM-W-EU chanNo = 02.
Habe es eingebaut. Es sollten jetzt nur noch die Channel-Devices für Clima bzw. Climate in der Liste sein.
Neues Feature 'Topics'
Eine ausführliche Beschreibung folgt noch im wiki.
Kurzinfo:
Aktiviert wird dieses Feature mit dem Attribut useTopics.
Ein Master-Gerät sollte nicht angegeben werden.
In einer Topic (Winter, Sommer, Party, Urlaub, etc.) kann es mehrere Wochenprofile geben.
Mittels einem Userattribut 'weekprofile' im Thermostat wird die Beziehung hergestellt.
Im Userattribut 'weekprofile' wird nur der Name des Wochenprofils ohne Topicnamen angegeben.
Mittels 'restore_topic' kann man zwischen unterschiedlichen Topics wechseln und die Thermostate erhalten den entsprechenden Wochenplan der Topic.
Zur Verwendung mehrere gleicher Wochenprofile kann man Referenzen verwenden.
Hierbei sind die Daten nicht direkt in jedem einzelnen Wochenplan sondern nur referenziert zu einem einzigen.
Referenzen können über das widget nicht bearbeitet werden.
Viel Spaß beim Spielen.
Zitat von: Risiko am 24 Januar 2016, 20:12:08
Habe es eingebaut. Es sollten jetzt nur noch die Channel-Devices für Clima bzw. Climate in der Liste sein.
Funktioniert perfekt. Vielen Dank! Ich weiß nicht, ob das allgemein von Interesse ist, aber die Liste noch sortiert ausgeben? ;)
Findet das Weekprofile-Modul mittlerweile auch schon Anwendung bei Schaltakturen von HomeMatic oder AVM? Es wäre traumhaft wenn ich die Wochenprofile für meine DECT200 nicht mehr in der FritzBox pflegen müßte... ;)
Zitat von: Reiner am 25 Januar 2016, 09:40:15
...aber die Liste noch sortiert ausgeben? ;)
Schaue es mit bei Gelegenheit mal an.
Zitat von: YellowBall am 25 Januar 2016, 10:00:17
Findet das Weekprofile-Modul mittlerweile auch schon Anwendung bei Schaltakturen von HomeMatic oder AVM? Es wäre traumhaft wenn ich die Wochenprofile für meine DECT200 nicht mehr in der FritzBox pflegen müßte... ;)
Was meinst du bei "Schaltakturen von HomeMatic"??
Zu den DECT200 Thermostaten von AVM - unterstützt das FHEM-Modul denn Wochenprofile? Konnte in den CommandRef (FBDECT?) nichts dahingehend finden.
Zu den leeren Profilen:
Wenn ich den Raum aufrufe, in dem ein leeres Profil ist, erhalte ich die Meldung "Parameter syntax error: Unexpected token p".
Dasselbe auch wenn ich die Zahnräder anklicke zum Konfigurieren.
Adresse im Browser sieht zB. so aus fhem?cmd={weekprofile_editOnNewpage("Wochenprofil_Bad","default:default","?room=Bad");;}
Zitat von: Risiko am 24 Januar 2016, 20:25:36
Neues Feature 'Topics'
... Feature mit dem Attribut useTopics....
Sehr schön, aber bitte sprich Dich wirklich mit Martin ab. So eine (ähnliche) Funktion ist für Homematic schon existent, ihr entwickelt also irgendwie doppelte Dinge.
Martin meinte, das sollte einheitlich zentral umgesetzt werden....
Zitat von: szoller am 27 Januar 2016, 15:25:40
Zu den leeren Profilen:
Wenn ich den Raum aufrufe, in dem ein leeres Profil ist, erhalte ich die Meldung "Parameter syntax error: Unexpected token p".
Also es scheint kein Profil angelegt zu sein, was seltsam ist. Es sollte zumindest das Default-Profil da sein.
Mach mal bitte ein list Wochenprofil_Bad. Lösche ggf. mal die config-Datei und starte FHEM neu.
Zitat von: JoeALLb am 27 Januar 2016, 15:38:51
Sehr schön, aber bitte sprich Dich wirklich mit Martin ab. So eine (ähnliche) Funktion ist für Homematic schon existent, ihr entwickelt also irgendwie doppelte Dinge.
Martin meinte, das sollte einheitlich zentral umgesetzt werden....
Wie bereits geschrieben, bin ich mit Martin in Kontakt.
Doppelt - sehe ich nicht so. HM-Info kann eben nur Homatic. Das ist ja auch mit ein Grund, warum das Modul entstanden ist.
ternals:
DEF Master
NAME Wochenprofil_Bad
NR 67
NTFY_ORDER 50-Wochenprofil_Bad
STATE created
TYPE weekprofile
Masterdev:
NAME Master
PROFILES:
HASH(0x1d55a58)
Readings:
2016-01-21 06:52:16 profile_count 1
2016-01-21 06:52:16 state created
SNDDEVLIST:
HASH(0x1e0c500)
HASH(0x1e01518)
HASH(0x1e0e5f8)
HASH(0x1e01620)
HASH(0x1ec1018)
HASH(0x1e0c578)
HASH(0x1db9a70)
Attributes:
group Heizung
room Bad
widgetEditOnNewPage 1
widgetWeekdays Montag,Dienstag,Mittwoch,Donnerstag,Freitag,Samstag,Sonntag
Welche config löschen?
Zitat von: szoller am 28 Januar 2016, 09:46:27
Welche config löschen?
Hallo.
Im Log Ordner weekprofile-Wochenprofil_Bad.cfg.
Was ist denn "Master" für ein Device?
Hast du auch die letzte Version "98_weekprofile.pm 10613 2016-01-24 19:10:01Z risiko79"
Also mein Vorschlag
1. update
2. Datei löschen
3. Neustart
Scheint geklappt zu haben :-)
Mir ist aber immer noch nicht klar, was als Master anzugeben ist...
- Ein Wochenplan?
- Als Default bzw. Fallback, falls nix anderes angegeben?
- Ein Gerät (=Thermostat)?
Zitat von: szoller am 29 Januar 2016, 10:23:02
Scheint geklappt zu haben :-)
Mir ist aber immer noch nicht klar, was als Master anzugeben ist...
Ein Thermostat oder nichts.
Wenn ich am WE etwas Zeit finde, werde ich die Doku im Wiki erweitern, Zugang habe ich jetzt :)
Beschreibung im Wiki erweitert: http://www.fhemwiki.de/wiki/Weekprofile
Noch nicht fertig, aber ich hoffe es wird etwas verständlicher. ::)
Hallo Risiko,
Bin eher per Zufall auf das Modul gestoßen, super !!!, da steckt ne Menge Zeit und Arbeit drin.
Ich werde das die Tage auch mal testen.... War auch lange auf der Suche noch se etwas .
Gibt es den für das FTUI schon einen Ansatz.
Gruß und. Danke
Zitat von: kvo1 am 03 Februar 2016, 18:06:13
Gibt es den für das FTUI schon einen Ansatz.
Nein leider noch nicht.
Meiner Meinung bietet das Modul aber die Möglichkeit dafür.
Mich würde persönlich auch ein widget für FTUI interessieren. Selbst hatte aber noch keine Zeit dafür.
Zitat von: Reiner am 25 Januar 2016, 09:40:15
...aber die Liste noch sortiert ausgeben? ;)
Ab morgen sind alle Listen alphabetisch sortiert.
Zitat von: szoller am 20 Januar 2016, 08:22:11
Kann man auch (optional) die Wochentage Mo-Fr zusammenlegen? Würde einige Klicks sparen.
Zusammenlegen nicht. Es gibt aber jetzt die Möglichkeit die Einstellungen von einem Tag auf andere zu übertragen.
Hallo,
ein schönes Modul, genau was ich vermisst hatte.
Ein kleiner Hinweis zur Fehlerbehandlung:
Ich habe versehentlich bei einem HM-CC-RT-DN das Device und nicht den Clima Channel als Master Gerät angegeben. Da wird das weekkprofile zunächst angelegt, aber kurz darauf stürzt fhem komplett ab. Es lässt sich erst wieder starten, wenn man die Definition aus der fhem.cfg entfernt.
Im Logfile lese ich:
2016.02.10 08:07:59 2: ProfilSchlafzimmerOG(assignDev): device SchlafzimmerOG not supported or defined
hash- or arrayref expected (not a simple scalar, use allow_nonref to allow this) at ./FHEM/98_weekprofile.pm line 475.
Gruß
Otto
Hallo Otto,
danke fürs Feedback.
Sehe es mir baldmöglichst an. Abstürzen soll es natürlich nicht!
Nachtrag:
Konnte den Fehler nicht reproduzieren. Verwendest du auch die letzte Version (10738)?
Hallo,
auch ich finde das Modul toll, erleichtert die Pflege der Wochenprofile für meine 10 MAX Thermostate enorm.
Eines ist mir bei der Funktion "Profil auf anderen Tag übertragen" aufgefallen. Und zwar werden dabei die Temperaturen nicht korrekt mit übernommen. Bei mir konnte ich den Fehler mit einen solchen Profil nachstellen:
00:00-06:00 17.0
06:00-18:00 21.0
18:00-00:00 17.0
Wenn ich dieses Profil nun übertrage, sind die Zeiten überall korrekt, allerdings ist die Temperatur bei allen Zeiten 17.0 Grad, die 21.0 in der Mitte fehlt.
Danke für das Modul!
Gruss
Zitat von: Risiko am 10 Februar 2016, 18:54:19
Konnte den Fehler nicht reproduzieren. Verwendest du auch die letzte Version (10738)?
Ja.
Ich habe es nochmal probiert, der Fehler lässt sich bei mir zuverlässig reproduzieren. Seltsam.
Zitat von: Talkabout am 13 Februar 2016, 17:44:55
Eines ist mir bei der Funktion "Profil auf anderen Tag übertragen" aufgefallen. Und zwar werden dabei die Temperaturen nicht korrekt mit übernommen.
Danke. Behoben
Zitat von: knodono am 13 Februar 2016, 19:08:53
Ja.
Ich habe es nochmal probiert, der Fehler lässt sich bei mir zuverlässig reproduzieren. Seltsam.
Wirklich seltsam. Hab nochmal was geändert. Die Ursache ist mir leider trotzdem nicht klar.
Zitat von: Risiko am 14 Februar 2016, 11:13:41
Wirklich seltsam. Hab nochmal was geändert. Die Ursache ist mir leider trotzdem nicht klar.
Die Änderung hat leider nichts gebracht. Gleiches Verhalten und gleiche Fehlermeldung im Log (Zeilennummer ist jetzt 477).
Zitat von: Risiko am 04 Februar 2016, 06:48:26
Mich würde persönlich auch ein widget für FTUI interessieren. Selbst hatte aber noch keine Zeit dafür.
Gibt es dazu inzwischen was?
Meiner Meinung nach wäre das hier eine ganz gute Basis:
http://forum.fhem.de/index.php/topic,48106.0.html (http://forum.fhem.de/index.php/topic,48106.0.html)
Vielleicht könnte man die Unterstützung für weekprofile auch direkt dort integrieren.
Gruß,
Thorsten
Hallo,
bis gestern schien mein Weektimer zu laufen. Heute nach Update und Neustart (keine Ahnung, obs daran liegt) kommt beim Aufruf der Räume mit Weektimer:
Kueche_HZ Parameter SyntaxError: JSON.parse: unexpected end of data at line 1 column 1 of the JSON data
Hat jemand eine Idee?
Ich habe den Weektimer auch schon komplett gelöscht und völlig neu angelegt... hilft nichts.
Dankeschön
Zitat von: Thorsten Pferdekaemper am 18 Februar 2016, 23:49:03
Gibt es dazu inzwischen was?
Meiner Meinung nach wäre das hier eine ganz gute Basis:
http://forum.fhem.de/index.php/topic,48106.0.html (http://forum.fhem.de/index.php/topic,48106.0.html)
Vielleicht könnte man die Unterstützung für weekprofile auch direkt dort integrieren.
Gruß,
Thorsten
Hallo Thorsten,
von mir leider nicht. Keine Zeit bzw. andere Baustellen.
Evtl. kann man basierend auf dem weekdaytimer-widget was machen. Auf den ersten Blick ist die Logik aber doch etwas anders.
Ich habe mir erstmal mit einer speziellen WEB-Instanz ohne Eingabe, Raumübersicht, etc. geholfen.
Rufe die Seite innerhalb von FTUI mittels eines iframes auf.
Daher ist das Thema für mich nicht ganz so eilig.
Wenn es dich (oder jemand anderes) interessiert, kann ich gern hierzu noch weitere Ausführungen machen.
Risiko
Zitat von: FHEM-User22 am 20 Februar 2016, 11:17:09
Hallo,
bis gestern schien mein Weektimer zu laufen. Heute nach Update und Neustart (keine Ahnung, obs daran liegt) kommt beim Aufruf der Räume mit Weektimer:
Kueche_HZ Parameter SyntaxError: JSON.parse: unexpected end of data at line 1 column 1 of the JSON data
Hat jemand eine Idee?
Ich habe den Weektimer auch schon komplett gelöscht und völlig neu angelegt... hilft nichts.
Dankeschön
Hallo.
Ohne weitere Infos leider nicht.
Ich hoffe, du verwechselst WeekDayTimer und weekprofile nicht.
Wo bekommst du den die Meldung?
Evtl. hilft ein löschen de Config und ein Neustart von fhem
Hallo.
Es gibt ab morgen ein neues optionales Attribut "widgetEditDaysInRow"
Damit kann man die darzustellenden Tage pro Reihe im Bearbeitungsmodus einstellen. Default ist 2
Desweiteren kann man die Darstellung auch bei Verwendung der internen Funktion "weekprofile_editOnNewpage" verändern. z.B.
fhem?cmd={weekprofile_editOnNewpage("<weekprf>","<topic:profile>","<count days>");;}
fhem?cmd={weekprofile_editOnNewpage("PRF.KUECHE","default:master","4");;}
Hallo Risiko,
ZitatWenn es dich (oder jemand anderes) interessiert, kann ich gern hierzu noch weitere Ausführungen machen.
JA, das würde mich interessieren ! Danke schon mal vorab ;)
Hallo Zusammen,
heute wollte ich an meinem vorhandenen Thermostat (HM CC TC; altes Modell :-( ) einen neuen Heizplan einspielen. Leider habe ich festgestellt, dass die Thermostate nicht mehr angezeigt werden. Gab es hier eine Änderung die ich verpasst habe?
Danke im Voraus
Gerd
Zitat von: Gerd.Ternes am 21 Februar 2016, 12:33:55
Leider habe ich festgestellt, dass die Thermostate nicht mehr angezeigt werden. Gab es hier eine Änderung die ich verpasst habe?
Eigentlich nicht. Was meinst du mit "nicht mehr angezeigt"?
Gibt es irgend welche Fehlermeldungen?
Ich habe noch 4 der o.a. Thermostate im Einsatz, sowie 2 Thermostat HM-TC-IT-WM-W-EU.
Leider werden nur die beiden letzten angezeigt.
Zitat von: kvo1 am 20 Februar 2016, 20:10:22
JA, das würde mich interessieren ! Danke schon mal vorab ;)
Kurzbeschreibung zum Thema weekprofile in FTUI (Notlösung da noch kein FTUI-widget existiert)1. FHEMWEB-Instanz wo alles (Eingabe, Raumansicht entfernt wurde)
define WEB_FOR_TUI FHEMWEB 8888 global
attr WEB_FOR_TUI CssFiles my/no_menu.css
attr WEB_FOR_TUI hiddenroom input
attr WEB_FOR_TUI stylesheetPrefix darktouchpad
no_menu.css entfernt die Raumansicht, etc. und passt die Tabellen ein wenig an.
Liegt bei mir im Ordner "my"
2. iframe innerhalb von FTUI z.B.
<div data-type="iframe" class="top-space" data-width="1000" data-height="720" data-scrolling="auto"
data-src="http://192.168.178.250:8888/fhem?cmd={weekprofile_editOnNewpage(%22PRF_BAD_HK%22,%22default:master%22,%223%22);;}"></div>
Die Startseite von FTUI sollt auch über die gleiche Adresse und Port (im Beispiel: 192.168.178.250:8888) wie für die Anzeige des FHEMWEB-Widget verwendet werden.
Zitat von: Gerd.Ternes am 21 Februar 2016, 13:28:08
Ich habe noch 4 der o.a. Thermostate im Einsatz, sowie 2 Thermostat HM-TC-IT-WM-W-EU.
Leider werden nur die beiden letzten angezeigt.
Bei HM wird jetzt noch die Kanalnummer (intern chanNo) überprüft.
Entsprechend den Vorgaben hier im Thread wird aktuell beim *HM-CC* nur Kanal 4 und beim *HM-TC* nur Kanal 2 erlaubt.
Super Modul tolle Arbeit. Damit macht Heizungssteuerung richtig Spaß. DANKE!!!!
Ich habe hier gerade alles von Honeywell auf Max! umgerüstet und schon überlegt wie das komfortabel anstelle :) Jetzt ganz EASY :D
Aber eine Frage ich hätte gerne einen Button "Anwesend Absend Party Urlaub"
Muss ich das über einen Dummy lösen und dann ein Set Kommando aufrufen um das Profil zu übertragen ?
Und vielleicht hat ja dann auch noch jemand eine Idee wie das mit dem Urlaub lösen könnte.
Meine alte Honnywell Steuerung hatte die Möglichkeit ein Datum einzugeben bis wann der Urlaub geht, damit die Heizung rechtzeitig startet
und es Warm ist wenn man nach Hause kommt.
Stefan
Dafür sind die Topics (restore_topic) vorgesehen eben z.B. Anwesend Absend Party Urlaub
Wann und wie du eine Topic wechselst, kann meiner Meinung nach mit anderen Modulen (DOIF, at, etc.) gelöst werden.
ja, der Kanal (2) ist vorhanden. Das gesamte Device wird aber nicht angezeigt.
VG
Gerd
Bei HM wird jetzt noch die Kanalnummer (intern chanNo) überprüft.
Entsprechend den Vorgaben hier im Thread wird aktuell beim *HM-CC* nur Kanal 4 und beim *HM-TC* nur Kanal 2 erlaubt.
Zitat von: Gerd.Ternes am 21 Februar 2016, 14:01:43
ja, der Kanal (2) ist vorhanden. Das gesamte Device wird aber nicht angezeigt.
Nein. chanNo gibt es dort nicht.
Was steht bei list von HM_Wohnzimmer_Climate? Benötige Model und chanNo von HM_Wohnzimmer_Climate!
Hallo Risiko,
hier das List:
Das Gerät ist ein HM-CC-TC. Vor ca. 1 Monat als ich das Weekprofile getestet habe war das Device ohne Probleme zu erkennen.
Internals:
CFGFN /opt/fhem/FHEM/Wohnzimmer.cfg
DEF 20E1B802
NAME HM_Wohnzimmer_Climate
NR 418
NTFY_ORDER 50-HM_Wohnzimmer_Climate
STATE 1
TYPE CUL_HM
chanNo 02
device HM_Wohnzimmer
Readings:
2016-02-21 13:40:05 CommandAccepted yes
2016-02-21 13:49:01 R-controlMode auto
2016-02-21 13:49:01 R-day-temp 21 C
2016-02-21 13:49:01 R-displayMode temp-hum
2016-02-21 13:49:01 R-displayTemp actual
2016-02-21 13:49:01 R-displayTempUnit celsius
2016-02-21 13:49:01 R-mdTempValve auto
2016-02-21 13:49:01 R-night-temp 17 C
2016-02-21 13:49:01 R-party-temp 20 C
2016-02-21 13:49:52 R_tempList_State incomplete
2016-02-21 14:27:59 RegL_05. 01:09 02:2A 03:2A 04:22 05:18 06:28 07:00 08:58 09:00 0A:00 0B:2A 0C:2A 0D:84 0E:2A 0F:90 10:2A 11:84 12:27 13:90 14:26 15:90 16:28 17:90 18:28 19:90 1A:28 1B:90 1C:28 1D:90 1E:28
2016-02-21 13:49:52 controlMode auto
2016-02-21 13:49:52 day-temp 21 C
2016-02-21 13:49:52 decalcDay ???
2016-02-21 13:40:05 desired-temp 21.0
2016-02-21 13:49:52 displayMode temp-hum
2016-02-21 13:49:52 displayTemp actual
2016-02-21 13:49:52 displayTempUnit celsius
2016-02-21 13:49:52 night-temp 17 C
2016-02-21 13:49:52 party-temp 20 C
2016-02-21 13:40:05 recentStateType ack
2016-02-21 13:41:46 state set_desired-temp 21.0
Templist:
Mon:
0:
HOUR 06
MINUTE 00
TEMP 17.0
1:
HOUR 08
MINUTE 00
TEMP 17.0
2:
HOUR 13
MINUTE 00
TEMP 19.0
3:
HOUR 22
MINUTE 00
TEMP 19.0
4:
HOUR 24
MINUTE 00
TEMP 17.0
Helper:
getCfgListNo
peerIDsRaw ,00000000
Expert:
def 1
det 0
raw 1
tpl 0
Role:
chn 1
Shadowreg:
RegL_05. 01:09 02:2A 03:2A 04:22 05:18 06:28 07:00 08:58 09:00 0A:00 0B:2A 0C:2A 0D:84 0E:2A 0F:90 10:2A 11:84 12:27 13:90 14:26 15:90 16:28 17:90 18:28 19:90 1A:28 1B:90 1C:28 1D:90 1E:28 6B:24 6C:22 6D:30 6E:22 6F:4E 70:26 71:84 72:26 73:90 74:22
Attributes:
expert 2_full
model HM-CC-TC
peerIDs 00000000,
room Wohnzimmer
stateFormat 1
Zitat von: Risiko am 21 Februar 2016, 13:51:36
Dafür sind die Topics (restore_topic) vorgesehen eben z.B. Anwesend Absend Party Urlaub
Wann und wie du eine Topic wechselst, kann meiner Meinung nach mit anderen Modulen (DOIF, at, etc.) gelöst werden.
Danke, das habe ich übersehen.
Nur noch rausfinden wie ich die Nutze ;)
Zitat von: Gerd.Ternes am 21 Februar 2016, 14:30:31
Das Gerät ist ein HM-CC-TC. Vor ca. 1 Monat als ich das Weekprofile getestet habe war das Device ohne Probleme zu erkennen.
Hallo Gerd,
kann mir das leider nicht so richtig erklären. Da ich kein HM habe, kann ich das leider nicht testen.
Magst du bitte die beigefügte Version testen? Da sind noch ein paar Logs mit drin. Mal schauen, was da raus kommt.
Wird das weekprofile Modul nach den HM Sachen angelegt?
Hallo risiko,
leider gleiches Problem. Die Thermostate werden nicht angezeigt.
ich müsste mal nachsehen, ob ich noch eine "alte" Version des Modules habe.
Danke schon mal
gerd
Gibt es irgendwelche Logausschriften der Art: "weekprofile_getDeviceType: ....." ?
ja,
so wie ich´s sehe, findet er das device auch
2016.02.21 20:02:46 2: weekprofile_getDeviceType: HM_Wohnzimmer_Climate, HM-CC-TC, 2
bei den anderen Kanälen findet er wohl nichts
2016.02.21 20:02:46 2: weekprofile_getDeviceType: HM_Flur_oben, HM-CC-TC, has no chanNo
Zitat von: Gerd.Ternes am 21 Februar 2016, 20:04:33
ja,
so wie ich´s sehe, findet er das device auch
2016.02.21 20:02:46 2: weekprofile_getDeviceType: HM_Wohnzimmer_Climate, HM-CC-TC, 2
bei den anderen Kanälen findet er wohl nichts
2016.02.21 20:02:46 2: weekprofile_getDeviceType: HM_Flur_oben, HM-CC-TC, has no chanNo
Hmm. Es fehlt trotzdem das HM_Wohnzimmer_Climate?
Leider habe ich immer noch keine richtige Idee warum.
Mach mal bitte ein
get Wohnraeume sndDevList
Es werden nur die beiden "neuen" HM devices angezeigt. Die HM-CC_TC werden nicht angezeigt
Zitat von: Reiner am 24 Januar 2016, 12:05:28
Die Unterscheidung sollte eigentlich über die Internals ganz einfach sein:
Beim HM-CC-RT-DN ist es chanNo = 04, beim HM-TC-IT-WM-W-EU chanNo = 02.
Im Kanal sollte eigentlich immer im Attribute "model" stehen, ob es ein HM-CC-RT-DN oder ein HM-TC-IT-WM-W-EU ist.
Hallo Gerd,
du hast ein HM-CC-TC und da ist chanNo auch 2, wie beim HM-TC-IT-WM-W-EU!
Ich hatte nur auf HM-CC geprüft. Muss also HM-CC-RT-DN und HM-CC-TC noch unterscheiden.
Sollte ab morgen gefixt sein.
super, vielen Dank!
Moin,
ich habe gerade begonnen mich mit dem Modul weekprofile zu beschäftigen, habe aber noch nicht so richtig herausgefunden wie das Thema 'Topics' funktioniert. Z.B. wie man einen 'Topicname' anlegt.
So adhoc fallen mir auch 2 generelle Möglichkeiten ein mit Topics zu arbeiten:
1. Topic mit Wochenplänen - ein Wochenplan für alle Thermostate
2. Topic mit Wochenplänen - individuelle Wochenpläne je Thermostate
Habe ich das soweit richtig verstanden, dass Topics eher den 1ten Fall abdecken?
Gruß Ralf
Hallo Ralf,
Du kannst beide Fälle damit realisieren.
Zuerst musst du das Feature mit dem Attribut useTopics aktivieren. Dann gibt es immer eine Default-Topic.
Andere kannst du dann durch Kopieren anlegen.
Risiko.
Hi,
da vielleicht nicht jeder jeden Forumsbereich liest: http://forum.fhem.de/index.php/topic,50197.0.html.
Gruß,
Thorsten
Guten morgen...
ich habe das Problem wenn ich ein neues Profil anlege, ändere, sende, abspeicher und Fhem neustarte ist das Profil wieder verschwunden...
Es leider auch nichts in der log file ....
Mach ich etwas falsch ???
Hallo Lapalutschi,
hast du weekprofile mit einem master-Device verbunden? In diesem Fall wird das eine Profil nur im Device gespeichert. Alle weiteren Profile dann in der config-Datei vom Modul weekprofile.
Daran liegt es leider nicht.... Hab es erstellt ohne device...
also ich hab als server ein Synology NAS und was noch nicht funktioniert ist das Modul Enigma2 (Unknow Modul) evtl. gibt es da einen zusammenhang??
So jetzt bin ich soweit das es wohl an Perl liegt... hab 2 Version installiert ...
Hab es mit Synology aufgeben und mir ein Raspberry gekauft.. Soweit läuft jetzt alles :-)
Nur.... Ich hab im Weekprofile ein Profil Namens Büro angelegt .. das scheint er gar nicht zu mögenwegen dem ü .... Wie bekomme ich dies wieder raus ???
Hallo Lapalutschi.
Du kannst den Eintrag aus der config-Datei löschen und FHEM neu starten.
Könntest du den Fehler evtl. etwas besser beschreiben als "scheint er gar nicht zu mögen".
Hallo Risko,
hast Du etwas dagegen, wenn ich das Wiki noch ein wenig unterfüttere? Bitte nicht falsch verstehen, denke, das Wichtigste steht schon drin, ich musste manches nur 2 mal lesen und manches erst selbst ausprobieren, um es komplett zu verstehen. Habe natürlich eher die Anwendersicht.
Würde mich freuen, wenn Du im Anschluss auch nochmal drüber liest. Änderungen kannst Du ja leicht wieder rückgängig machen.
@ Lapalutschi, bei mir gab es mit einem Profil Namens "Küche" unter einem Topic noch keine merkbaren Abweichungen. Allerdings habe ich noch keine Profile an die Thermostaten übertragen, Status: in Vorbereitung.
ps: Danke für das coole Modul!
Zitat von: joshi04 am 17 März 2016, 06:06:55
hast Du etwas dagegen, wenn ich das Wiki noch ein wenig unterfüttere? Bitte nicht falsch verstehen, denke, das Wichtigste steht schon drin, ich musste manches nur 2 mal lesen und manches erst selbst ausprobieren, um es komplett zu verstehen.
Natürlich. Bitte ergänzen\verbessern. Dafür ist doch das wiki meiner Meinung doch da.
Klasse, allerdings wird das noch etwas dauern.
Das Verhalten mit den Umlauten konnte ich nun dafür nachvollziehen (erst nach einem restart/rereadcfg):
- Der Umlaut wird nicht mehr richtig dargestellt.
- Ein hinterlegtes Profil wird nicht mehr dargestellt/gefunden.
- Das Profil mit dem Umlaut kann nicht gelöscht werden.
- Ein anderes Profil kann nicht angelegt werden (z.B. "Kueche").
siehe Screenshots
Derzeit kann man das leicht umgehen, in dem man
- Keine Umlaute in der Namensgebung verwendet.
- Hat man das doch irrtümlich getan, in der ./log/weekprofile-Heizprofile.cfg die entsprechenden Zeilen manuell löscht/umbenennt und danach einmal rereadcfg ausführt.
Hallo Zusammen,
ich bin ganz neu im Thema FHEM und bin schon sehr begeistert was alles möglich ist. :-)
Ich habe FHEM auf meinem Mac Mini installiert und mit meinem Max Cube über MAXLAN verbunden. Ich habe 3 Räume definiert. Schlafzimmer und Bad haben jeweils eine Heizung und einen Fenstersensor. Das Wohnzimmer hat davon jeweils 3 und ein Wandthermostat. Ich habe in jeden Raum das Weekprofile Modul eingebunden und es zeigt auch das aktuelle Profil an. Was mir aber noch noch nicht ganz klar ist:
1. Ich habe im Wohnzimmer das Wandthermostat als Master angegeben. Wenn ich dort jetzt ein Profil hin schicke, wird das dann auch auf die Heizungen übertragen oder muss ich das Profil an jedes Thermostat einzeln schicken?
2. joshi04 hat in seinem ersten Screenshot zwei Dropdown Boxen und kann in dem unterem einen Raum wählen. Ich habe das nicht. Was mache ich falsch?
Eingebundene habe ich alles so:
define Wohnzimmer.Profil weekprofile Wandthermostat.Kamin
attr Wohnzimmer.Profil room Wohnzimmer
define Schlafzimmer.Profil weekprofile Heizung.Schlafzimmer
attr Schlafzimmer.Profil room Schlafzimmer
define Badezimmer.Profil weekprofile Heizung.Bad
attr Badezimmer.Profil room Badezimmer
Vielen Dank für eure Hilfe!
Zitat von: joshi04 am 19 März 2016, 12:42:07
Das Verhalten mit den Umlauten konnte ich nun dafür nachvollziehen (erst nach einem restart/rereadcfg):
Danke für die Beschreibung. Ich sehe es mir bei den nächst möglichen freien Minuten an!
Nachtrag:
Hab es gefixed. Sollte ab morgen gehen.
@solbadguy2010
zu 1:
Das gehört prinzipiell in MAX Bereich. Dort wurde das Thema auch schon mehrmals diskutiert.
Bitte dort suchen.
Kurz: Wenn die WT und HT assoziiert sind, reicht es das Weekprofile am WT zu ändern.
zu 2:
Thema Topics: Bitte im wiki erst einlesen bzw. warten bis joshi04 den Artikel überarbeitet hat.
Das Wiki habe ich ein wenig erweitert. @ Risiko, würde mich freuen, wenn Du bei Gelegenheit mal drüber schau könntest. Bitte fühle Dich frei, unrichtige Sachen wieder rauszuschmeißen. Ich hoffe, ich habe es einigermaßen getroffen.
Bei der Einrichtung hatte ich allerdings einige Auffälligkeiten, leider alles ohne dass ich es einwandfrei reproduzieren könnte, daher leider nur zur Info:
- Beim Aufrufen der Bearbeiten Seite gab es eine JSON Fehlermeldung.
- Der Plan wurde nicht zuverlässig gespeichert.
- Der Name der Wochentage wurde nicht immer zuverlässig auf der Bearbeitenseite angezeigt.
Was mir aber am meisten Probleme bereitet, ist die Tatsache, dass ich bei der Verwendung von Topics und aktivieren eines solchen, die Pläne nicht übertragen werden. Ich denke, das ist u.a. der Tatsache geschuldet, dass ich Homematic verwende. Die beiden notwendigen Attribute habe ich natürlich entsprechend gesetzt.
Generelle Frage:
Hat das eigentlich schon jemand mit Homematic Komponenten und Topics am laufen? Falls ja, würde ich hier noch einmal ein wenig weiter debuggen, woran es bei mir liegt.
Falls nein, bin ich der Meinung wäre das bis zur Implementierung der Schnittstelle zur HMInfo ein wenig vergebene Liebesmühe. Ich glaube, martinp976 hatte das weiter oben schon einmal erwähnt und seine Unterstützung angeboten.
@ Risiko, ich weiß, Du hast keine Homematic Komponenten, sondern nur MAX. Daher finde ich das Klasse, dass Du die Homematic-Unterstützung überhaupt in Erwägung ziehst.
Wenn Du an der HMInfo Front weitermachen möchtest, stehe ich natürlich fürs Debugging etc. bereit, kann aber auch gut nachvollziehen, wenn es hier erstmal nicht weitergeht. Ich schaue mir das auf alle Fälle schon mal an, werd's ja vermutlich so oder so brauchen. :)
Zitat von: joshi04 am 20 März 2016, 16:30:04
Das Wiki habe ich ein wenig erweitert. @ Risiko, würde mich freuen, wenn Du bei Gelegenheit mal drüber schau könntest. Bitte fühle Dich frei, unrichtige Sachen wieder rauszuschmeißen. Ich hoffe, ich habe es einigermaßen getroffen.
Werde ich machen!
Zitat von: joshi04 am 20 März 2016, 16:30:04
Bei der Einrichtung hatte ich allerdings einige Auffälligkeiten, leider alles ohne dass ich es einwandfrei reproduzieren könnte, daher leider nur zur Info:
- Beim Aufrufen der Bearbeiten Seite gab es eine JSON Fehlermeldung.
- Der Plan wurde nicht zuverlässig gespeichert.
- Der Name der Wochentage wurde nicht immer zuverlässig auf der Bearbeitenseite angezeigt.
Ok. Danke für die Infos. Ohne weitere Analyse kann ich da leider aktuell nicht weiter helfen.
Zitat von: joshi04 am 20 März 2016, 16:30:04
Was mir aber am meisten Probleme bereitet, ist die Tatsache, dass ich bei der Verwendung von Topics und aktivieren eines solchen, die Pläne nicht übertragen werden. Ich denke, das ist u.a. der Tatsache geschuldet, dass ich Homematic verwende. Die beiden notwendigen Attribute habe ich natürlich entsprechend gesetzt.
Hmm. Wenn das Übertragen ohne Topics geht, sollt es auch mit Topics gehen. Natürlich muss im Attribut 'weekprofile' des jeweiligen Devices der richtige\passender Profilname stehen.
Kannst ja bitte mal verbose auch 5 stellen und schauen was im Log steht.
Zitat von: joshi04 am 20 März 2016, 16:30:04
Wenn Du an der HMInfo Front weitermachen möchtest, stehe ich natürlich fürs Debugging etc. bereit, kann aber auch gut nachvollziehen, wenn es hier erstmal nicht weitergeht. Ich schaue mir das auf alle Fälle schon mal an, werd's ja vermutlich so oder so brauchen. :)
Danke für das Angebot.
Ich hatte mit martinp876 dazu Kontakt und wir hatte ein paar Dinge abgestimmt. Warte jetzt auf Rückmeldung.
Wahrscheinlich liegt das Thema bei ihm aber erstmal auf Eis.
Zitat von: Risiko am 20 März 2016, 18:46:02
Kannst ja bitte mal verbose auch 5 stellen und schauen was im Log steht.
Verbose steht bereits auf 5 und im Log findet sich nach aktivieren des Topics nur
2016.03.20 19:11:46 5: Heizprofile(Set): found device BD_Klima_ClimateDaher bin ich ein wenig ratlos, da ich den Mechanismus des Übertragens nicht kenne und mir daher die weiteren Debugmöglichkeiten fehlen.
Welcher Befehl wird denn eigentlich abgesetzt, wenn ein Profil übertragen werden soll? Würde auch denken, dass ich im Homematic-Modul sehe, dass Commands zur Abarbeitung anstehen. Und wenn ich da nichts finde, spätestens am nächsten Tag das Profil auf dem Thermostat sein müsste. Hmmm ???
Ich mache nochmal einen Versuch in absolut einfacher Konfiguration mit nur einem Thermostat (Betriebsmodus: Standard Verwaltung).
Auf der anderen Seite, wie gesagt, ich bin der Meinung, Du solltest hier nicht zuviel Energie hinein investieren. Ein sauberes Interface zu HMInfo wäre mir deutlich lieber, als eine schnelle, dafür aber nur temporäre Lösung. ;)
@ Community, gibt es jemanden, der das Modul mit Homematic erfolgreich am Laufen hat?
Am Ende liegt das Problem vermutlich sowieso wieder vor der Tastatur...
Also im einfachen Modus läuft es auf alle Fälle:
Eventmonitor sieht gut aus:
2016-03-20 19:59:00 CUL_HM BD_Klima_Climate R_P1_0_tempListSat: 07:00 20.0 10:00 22.0 24:00 20.0
2016-03-20 19:59:00 CUL_HM BD_Klima_Climate R_P1_1_tempListSun: 07:00 20.0 10:00 22.0 24:00 20.0
2016-03-20 19:59:00 CUL_HM BD_Klima_Climate R_P1_2_tempListMon: 04:00 20.0 08:00 22.0 15:00 17.0 24:00 20.0
2016-03-20 19:59:00 CUL_HM BD_Klima_Climate R_P1_3_tempListTue: 04:00 20.0 08:00 22.0 15:00 17.0 24:00 20.0
2016-03-20 19:59:00 CUL_HM BD_Klima_Climate R_P1_4_tempListWed: 04:00 20.0 08:00 22.0 15:00 17.0 24:00 20.0
2016-03-20 19:59:00 CUL_HM BD_Klima_Climate R_P1_5_tempListThu: 04:00 20.0 08:00 22.0 15:00 17.0 24:00 20.0
2016-03-20 19:59:00 CUL_HM BD_Klima_Climate R_P1_6_tempListFri: 04:00 20.0 08:00 22.0 15:00 17.0 24:00 20.0
2016-03-20 19:59:00 CUL_HM BD_Klima_Climate R_P1_tempList_State: set
2016-03-20 19:59:00 weekprofile Heizprofil_test send_to_device default:Bad BD_Klima_Climate
Und im Log siehts auch gut aus:
2016.03.20 19:59:00 3: CUL_HM set BD_Klima_Climate tempListMon prep 04:00 20.0 08:00 22.0 15:00 17.0 24:00 20.0
2016.03.20 19:59:00 3: CUL_HM set BD_Klima_Climate tempListTue prep 04:00 20.0 08:00 22.0 15:00 17.0 24:00 20.0
2016.03.20 19:59:00 3: CUL_HM set BD_Klima_Climate tempListWed prep 04:00 20.0 08:00 22.0 15:00 17.0 24:00 20.0
2016.03.20 19:59:00 3: CUL_HM set BD_Klima_Climate tempListThu prep 04:00 20.0 08:00 22.0 15:00 17.0 24:00 20.0
2016.03.20 19:59:00 3: CUL_HM set BD_Klima_Climate tempListFri prep 04:00 20.0 08:00 22.0 15:00 17.0 24:00 20.0
2016.03.20 19:59:00 3: CUL_HM set BD_Klima_Climate tempListSat prep 07:00 20.0 10:00 22.0 24:00 20.0
2016.03.20 19:59:00 3: CUL_HM set BD_Klima_Climate tempListSun exec 07:00 20.0 10:00 22.0 24:00 20.0
2016.03.20 19:59:08 3: CUL_HM set BD_Klima_Climate getConfig
Zwischenzeitlich habe ich aber auch noch ein JSON-Paket nachinstalliert, das noch nicht drauf war. Da ich allerdings wie im Forum beschrieben keine Fehlermeldung beim Define hatte, hatte ich ein Fehlen erstmal nicht in Erwägung gezogen.
Ob's daran lag und ob die Topics nun laufen, steht noch aus.
Das hier müsste dann auf alle Fälle als Voraussetzung noch ins Wiki:
sudo apt-get install libjson-pp-perl
Welche Pakete wären denn noch Voraussetzung, damit man das vollständig angeben kann? Bei mir ist schon ziemlich viel drauf, sodass ich das nicht mehr identifizieren kann.
Zitat von: joshi04 am 20 März 2016, 19:38:05
Daher bin ich ein wenig ratlos, da ich den Mechanismus des Übertragens nicht kenne und mir daher die weiteren Debugmöglichkeiten fehlen.
Welcher Befehl wird denn eigentlich abgesetzt, wenn ein Profil übertragen werden soll? Würde auch denken, dass ich im Homematic-Modul sehe, dass Commands zur Abarbeitung anstehen. Und wenn ich da nichts finde, spätestens am nächsten Tag das Profil auf dem Thermostat sein müsste. Hmmm ???
Bei Verwendung von Topics werden die Profile erst bei restore_topic aktualisiert\übertragen. Das "T" in der GUI.
In deinem Beispiel muss aber in BD_Klima_Climat das Attribut weekprofile über Userattr mit einem passenden Profilname gesetzt sein.
Hoffe es wurde jetzt verstanden ;)
Zitat von: joshi04 am 20 März 2016, 20:10:17
sudo apt-get install libjson-pp-perl
Welche Pakete wären denn noch Voraussetzung, damit man das vollständig angeben kann? Bei mir ist schon ziemlich viel drauf, sodass ich das nicht mehr identifizieren kann.
Ich habe libjson-pp-perl nicht installiert. Bei mir ist noch libjson-xs-perl drauf. Liegt evtl. an der perl Version?
Zitat von: Risiko am 20 März 2016, 20:19:35
Bei mir ist noch libjson-xs-perl drauf. Liegt evtl. an der perl Version?
Das erklärt, warum ich beim Define keine Fehlermeldung bekommen habe. Das hatte ich nämlich schon drauf. Die Info hatte ich von hier https://forum.fhem.de/index.php/topic,46117.msg384439.html#msg384439 (https://forum.fhem.de/index.php/topic,46117.msg384439.html#msg384439).
Zur Sicherheit habe ich gerade noch einmal alles aktualisiert:
Perl ist nun v5.14.2.
Verstanden hatte ich das bereits alles, auch dass man das Topic aktivieren muss, um die Pläne zu ändern. Zum Glück bestätigt Deine Beschreibung meine Interpretation. Nur die Befehle werden nicht abgesetzt.
Ich werde das morgen nochmal in Ruhe kontrollieren, probieren und ordentlich protokollieren/dokumentieren. Vielleicht habe ich irgendwo einen dämlichen Typo drin.
Für heute schon einmal vielen Dank!
Mich hat's nicht in Ruhe gelassen.
Wie erwartet, der Fehler saß vor der Tastatur.
Hatte das Attribut falsch gesetzt. Das muss ich auf alle Fälle noch einmal etwas deutlicher im Wiki dokumentieren. Sorry für die Aufregung! :-[
Letztendlich hat mich aber das Beispiel auf den richtigen Weg gebracht.
Dafür habe ich es reproduzierbar geschafft, mein FHEM zum Absturz zu bringen. Das verrate ich aber frühestens morgen, wie ich das hinbekomme. ;)
Ich habe gesehen, Du warst fleissig und hast die Umlaute gefixt. Danke!
Kurz zusammengefast, führe ich einen restore_topic aus, dass ein referenziertes Profil enthält, stürzt FHEM ab.
Bei Interesse schau es Dir gerne an, ich werde das Modul erst einmal ohne referenzierte Profile verwenden. Das Kopieren ist ja sehr einfach möglich. :)
Außerdem werde ich wohl erstmal die Tempprofile über HMInfo in Betrieb nehmen. Also bitte stecke hier nicht zuviel Energie hinein.
Damit Du ein möglichst komplettes Bild bekommst, so sieht meine Testumgebung aus:
Eine Definition des Moduls weekprofile (11099) mit 2 Profilen und aktivierten Topics
Internals:
NAME Heizprofile
NR 831
NTFY_ORDER 50-Heizprofile
STATE created
TYPE weekprofile
PROFILES:
HASH(0x3336fb0)
HASH(0x3335fd0)
Readings:
2016-03-20 21:31:17 active_topic normalerWochenplan
2016-03-23 10:07:04 profile_count 2
2016-03-23 10:07:04 state created
SNDDEVLIST:
HASH(0x334c510)
HASH(0x334c570)
HASH(0x334c5d0)
HASH(0x334c630)
HASH(0x334c690)
HASH(0x334c6f0)
HASH(0x334c750)
HASH(0x334c7b0)
HASH(0x334c810)
HASH(0x334c870)
TOPICS:
normalerWochenplan
Attributes:
room develop_weekprofile,System
useTopics 1
verbose 5
widgetEditOnNewPage 1
widgetWeekdays Montag,Dienstag,Mittwoch,Donnerstag,Freitag,Samstag,Sonntag
Der Inhalt der Datei weekprofile-Heizprofile.cfg lautet wie folgt:
__version__=1.1
entry={"NAME":"Bad","DATA":{"Mon":{"temp":["20.0","22.0","17.0","20.0"],"time":["04:00","08:00","15:00","24:00"]},"Tue":{"temp":["20.0","22.0","17.0","20.0"],"time":["04:00","08:00","15:00","24:00"]},"Fri":{"temp":["20.0","22.0","17.0","20.0"],"time":["04:00","08:00","15:00","24:00"]},"Wed":{"temp":["20.0","22.0","17.0","20.0"],"time":["04:00","08:00","15:00","24:00"]},"Sun":{"temp":["20.0","22.0","20.0"],"time":["07:00","10:00","24:00"]},"Sat":{"temp":["20.0","22.0","20.0"],"time":["07:00","10:00","24:00"]},"Thu":{"temp":["20.0","22.0","17.0","20.0"],"time":["04:00","08:00","15:00","24:00"]}},"TOPIC":"normalerWochenplan","REF":null}
entry={"NAME":"Bad_HT","DATA":null,"REF":"normalerWochenplan:Bad","TOPIC":"normalerWochenplan"}
Man sieht, ich habe ein Profil mit dem Namen "Bad" und eines mit Namen "Bad_HT", das auf Bad referenziert. Diese wurden über das Widget erstellt.
Die Thermostaten, auf die die Profile angewendet werden sollen sind
zum einen ein Wandthermostat:
Internals:
DEF 569DB913
NAME BD_Klima_Climate
NR 805
NTFY_ORDER 50-BD_Klima_Climate
STATE T: 20.3 desired: 20.0
TYPE CUL_HM
chanNo 02
device BD_Klima
peerList BD_Heiz_Climate,
Helper:
Dblog:
Desired-temp:
Mydblog:
TIME 1458760688.3489
VALUE 20.0
Humidity:
Mydblog:
TIME 1458760688.3489
VALUE 63
Measured-temp:
Mydblog:
TIME 1458760688.3489
VALUE 20.3
State:
Mydblog:
TIME 1458741600.13252
VALUE set_desired-temp 20.0
Readings:
2016-03-23 15:00:01 CommandAccepted yes
2016-03-10 18:59:32 R-dayTemp 21 C
2016-03-10 18:59:32 R-daylightSaveTime on
2016-03-10 18:59:32 R-heatCool heating
2016-03-10 18:59:32 R-hyst2point 0.4 C
2016-03-10 18:59:32 R-modePrioManu all
2016-03-10 18:59:32 R-modePrioParty all
2016-03-10 18:59:32 R-nightTemp 17 C
2016-03-10 18:59:32 R-noMinMax4Manu off
2016-03-10 18:59:32 R-sendWeatherData on
2016-03-10 18:59:32 R-showHumidity temp
2016-03-10 18:59:32 R-showInfo time
2016-03-10 18:59:32 R-showSetTemp actTemp
2016-03-10 18:59:28 R-sign off
2016-03-10 18:59:32 R-tempOffset 0.0K
2016-03-10 18:59:32 R-weekPrgSel prog1
2016-03-10 18:59:32 R-winOpnBoost off
2016-03-20 21:23:24 R_P1_0_tempListSat 07:00 20.0 10:00 22.0 24:00 20.0
2016-03-20 21:23:24 R_P1_1_tempListSun 07:00 20.0 10:00 22.0 24:00 20.0
2016-03-20 21:23:24 R_P1_2_tempListMon 04:00 20.0 08:00 22.0 15:00 17.0 24:00 20.0
2016-03-20 21:23:24 R_P1_3_tempListTue 04:00 20.0 08:00 22.0 15:00 17.0 24:00 20.0
2016-03-20 21:23:24 R_P1_4_tempListWed 04:00 20.0 08:00 22.0 15:00 17.0 24:00 20.0
2016-03-20 21:23:24 R_P1_5_tempListThu 04:00 20.0 08:00 22.0 15:00 17.0 24:00 20.0
2016-03-20 21:23:24 R_P1_6_tempListFri 04:00 20.0 08:00 22.0 15:00 17.0 24:00 20.0
2016-03-20 21:23:24 R_P1_tempList_State verified
2016-03-20 21:23:28 R_P2_0_tempListSat 24:00 17.0
2016-03-20 21:23:28 R_P2_1_tempListSun 24:00 17.0
2016-03-20 21:23:28 R_P2_2_tempListMon 24:00 17.0
2016-03-20 21:23:28 R_P2_3_tempListTue 24:00 17.0
2016-03-20 21:23:28 R_P2_4_tempListWed 24:00 17.0
2016-03-20 21:23:28 R_P2_5_tempListThu 24:00 17.0
2016-03-20 21:23:28 R_P2_6_tempListFri 24:00 17.0
2016-03-20 21:23:28 R_P2_tempList_State verified
2016-03-20 21:23:32 R_P3_0_tempListSat 24:00 17.0
2016-03-20 21:23:32 R_P3_1_tempListSun 24:00 17.0
2016-03-20 21:23:32 R_P3_2_tempListMon 24:00 17.0
2016-03-20 21:23:32 R_P3_3_tempListTue 24:00 17.0
2016-03-20 21:23:32 R_P3_4_tempListWed 24:00 17.0
2016-03-20 21:23:32 R_P3_5_tempListThu 24:00 17.0
2016-03-20 21:23:32 R_P3_6_tempListFri 24:00 17.0
2016-03-20 21:23:32 R_P3_tempList_State verified
2016-03-20 21:23:20 RegL_01. 08:00 00:00
2016-03-20 21:23:24 RegL_07. <Raw ausgeblendet>
2016-03-20 21:23:28 RegL_08. <Raw ausgeblendet>
2016-03-20 21:23:32 RegL_09. <Raw ausgeblendet>
2016-03-23 20:01:34 boostTime -
2016-03-23 20:01:34 commReporting off
2016-03-23 20:01:34 controlMode manual
2016-03-23 20:18:08 desired-temp 20.0
2016-03-23 20:18:08 humidity 63
2016-03-23 20:18:08 measured-temp 20.3
2016-03-23 10:06:59 peerList BD_Heiz_Climate,
2016-03-23 15:00:01 recentStateType ack
2016-03-23 20:18:08 state T: 20.3 desired: 20.0
2016-03-10 19:01:24 temperature 0
2016-03-23 20:01:34 winOpenReporting off
Helper:
Expert:
def 1
det 0
raw 1
tpl 0
Role:
chn 1
Shregr:
07 00
Attributes:
alias Bad Wandthermostat
group Heizung
icon temp_control
model HM-TC-IT-WM-W-EU
peerIDs 00000000,55E74B15,
room Bad
userattr weekprofile
weekprofile Bad
Zum anderen ein Heizungsthermostat:
Internals:
CFGFN ./FHEM/99_HM.cfg
DEF 55E74B15
NAME BD_Heiz_Clima
NR 324
NTFY_ORDER 50-BD_Heiz_Clima
STATE T: 20.2 T-soll: 20.0 Ventil: 0.0
TYPE CUL_HM
chanNo 04
device BD_Heiz
Helper:
Dblog:
Valveposition:
Mydblog:
TIME 1458761095.27111
VALUE 0
Desired-temp:
Mydblog:
TIME 1458761095.27111
VALUE 20.0
Measured-temp:
Mydblog:
TIME 1458761095.27111
VALUE 20.2
Readings:
2016-03-23 15:05:14 CommandAccepted yes
2016-02-21 18:24:23 R-boostPos 80 %
2016-02-21 18:24:23 R-btnNoBckLight off
2016-02-21 18:24:23 R-dayTemp 21 C
2016-02-21 18:24:23 R-daylightSaveTime on
2016-02-21 18:24:23 R-modePrioManu all
2016-02-21 18:24:23 R-modePrioParty all
2016-02-21 18:24:23 R-nightTemp 17 C
2016-02-21 18:24:23 R-noMinMax4Manu off
2016-02-21 18:24:23 R-regAdaptive on
2016-02-21 18:24:23 R-showInfo time
2016-02-21 18:24:18 R-sign off
2016-02-21 18:24:23 R-tempOffset 0.0K
2016-02-21 18:24:23 R-valveOffsetRt 0 %
2016-02-21 18:24:23 R-winOpnBoost off
2016-03-13 15:20:27 R_0_tempListSat 06:00 17.0 22:00 21.0 24:00 17.0
2016-03-13 15:20:27 R_1_tempListSun 06:00 17.0 22:00 21.0 24:00 17.0
2016-03-13 15:20:27 R_2_tempListMon 06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0
2016-03-13 15:20:27 R_3_tempListTue 06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0
2016-03-13 15:20:27 R_4_tempListWed 06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0
2016-03-13 15:20:27 R_5_tempListThu 06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0
2016-03-13 15:20:27 R_6_tempListFri 06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0
2016-03-13 15:20:27 R_tempList_State verified
2016-03-13 15:17:55 RegL_01. 08:00 00:00
2016-03-13 15:20:27 RegL_07. <Raw ausgeblendet>
2016-03-23 20:24:55 ValvePosition 0
2016-03-23 20:24:55 boostTime -
2016-03-23 20:24:55 controlMode manual
2016-03-23 20:24:55 desired-temp 20.0
2016-03-23 20:24:55 measured-temp 20.2
2016-03-23 20:24:55 partyEnd -
2016-03-23 20:24:55 partyStart -
2016-03-23 20:24:55 partyTemp -
2016-03-23 15:05:14 recentStateType ack
2016-03-23 20:24:55 state T: 20.2 desired: 20.0 valve: 0
Helper:
Expert:
def 1
det 0
raw 1
tpl 0
Role:
chn 1
Shregr:
07 00
Attributes:
alias Bad Heizungsthermostat
group Heizung
icon temp_control
model HM-CC-RT-DN
peerIDs 00000000,
room Bad
stateFormat {sprintf("T: %.1f T-soll: %.1f Ventil: %.1f", ReadingsVal($name,"measured-temp",0), ReadingsVal($name,"desired-temp",0), ReadingsVal($name,"ValvePosition",0))}
userattr weekprofile
weekprofile Bad_HT
Der relevante Teil des Logs sieht so aus:
2016.03.23 20:30:55 4: WEB_192.168.150.33_49806 POST /fhem?cmd=set%20Heizprofile%20restore_topic%20normalerWochenplan&XHR=1&fw_id=7864; BUFLEN:0
2016.03.23 20:30:55 5: Cmd: >set Heizprofile restore_topic normalerWochenplan<
2016.03.23 20:30:55 5: Heizprofile(Set): found device BD_Klima_Climate
2016.03.23 20:30:55 4: Heizprofile(Set): Send profile normalerWochenplan:Bad to BD_Klima_Climate
2016.03.23 20:30:55 4: Heizprofile(sendDevProfile): nothing to do
2016.03.23 20:30:55 5: Heizprofile(Set): found device KU_Klima_Climate
2016.03.23 20:30:55 5: Heizprofile(Set): found device SZ_Klima_Climate
2016.03.23 20:30:55 5: Heizprofile(Set): found device BD_Heiz_Clima
2016.03.23 20:30:55 4: Heizprofile(Set): Send profile normalerWochenplan:Bad_HT to BD_Heiz_Clima
Can't use an undefined value as an ARRAY reference at ./FHEM/98_weekprofile.pm line 209.
Nach der letzten Zeile steigt fhem komplett aus und muss über /etc/init.d/fhem start neu gestartet werden. Man sieht außerdem, auf BD_Klima_Climate ist schon das richtige Profil drauf und daher -> nothing to do. Man sieht auch, dass ich noch weitere Thermostaten mit Attributen ausgestattet habe. Beim Versuch, das referenzierte Profil zu senden, steigt er aus.
Ergänzung:
Auch wenn das Profil geändert wird, sieht das log leider gleich aus:
2016.03.23 21:05:07 5: Heizprofile(Set): found device BD_Klima_Climate
2016.03.23 21:05:07 4: Heizprofile(Set): Send profile normalerWochenplan:Bad to BD_Klima_Climate
2016.03.23 21:05:07 4: Heizprofile(sendDevProfile): set BD_Klima_Climate tempListMon prep 04:00 20.0 08:00 22.0 15:00 16.5 24:00 20.0; set BD_Klima_Climate tempListTue prep 04:00 20.0 08:00 22.0 15:00 16.5 24:00 20.0; set BD_Klima_Climate tempListWed prep 04:00 20.0 08:00 22.0 15:00 16.5 24:00 20.0; set BD_Klima_Climate tempListThu prep 04:00 20.0 08:00 22.0 15:00 16.5 24:00 20.0; set BD_Klima_Climate tempListFri prep 04:00 20.0 08:00 22.0 15:00 16.5 24:00 20.0; set BD_Klima_Climate tempListSat prep 07:00 20.0 10:00 22.0 24:00 20.5; set BD_Klima_Climate tempListSun exec 07:00 20.0 10:00 22.0 24:00 20.5
2016.03.23 21:05:07 3: CUL_HM set BD_Klima_Climate tempListMon prep 04:00 20.0 08:00 22.0 15:00 16.5 24:00 20.0
2016.03.23 21:05:07 3: CUL_HM set BD_Klima_Climate tempListTue prep 04:00 20.0 08:00 22.0 15:00 16.5 24:00 20.0
2016.03.23 21:05:07 3: CUL_HM set BD_Klima_Climate tempListWed prep 04:00 20.0 08:00 22.0 15:00 16.5 24:00 20.0
2016.03.23 21:05:07 3: CUL_HM set BD_Klima_Climate tempListThu prep 04:00 20.0 08:00 22.0 15:00 16.5 24:00 20.0
2016.03.23 21:05:07 3: CUL_HM set BD_Klima_Climate tempListFri prep 04:00 20.0 08:00 22.0 15:00 16.5 24:00 20.0
2016.03.23 21:05:07 3: CUL_HM set BD_Klima_Climate tempListSat prep 07:00 20.0 10:00 22.0 24:00 20.5
2016.03.23 21:05:07 3: CUL_HM set BD_Klima_Climate tempListSun exec 07:00 20.0 10:00 22.0 24:00 20.5
2016.03.23 21:05:07 5: Heizprofile(Set): found device KU_Klima_Climate
2016.03.23 21:05:07 5: Heizprofile(Set): found device SZ_Klima_Climate
2016.03.23 21:05:07 5: Heizprofile(Set): found device BD_Heiz_Clima
2016.03.23 21:05:07 4: Heizprofile(Set): Send profile normalerWochenplan:Bad_HT to BD_Heiz_Clima
Can't use an undefined value as an ARRAY reference at ./FHEM/98_weekprofile.pm line 209.
Hallo joshi04,
vielen Dank für die ausführliche Analyse.
Ich sehe mir das mit den Referenzen nach Ostern mal an.
Betreffs HMInfo warte ich wie gesagt auf martinp876.
Hallo.
Das Problem mit den referenzierten Profilen\Daten sollte ab morgen behoben sein.
Hallo Risiko,
vielen Dank. Bestätige, läuft!
Jetzt leider noch einmal eine blöde Frage von der Anwenderseite:
Ich habe ein Profil (z.B. "Wohnzimmer") per Attribut mehreren Thermostaten (z.B. WZ_Klima_Climate, WZ_Heiz_Kammer_Clima und WZ_Heiz_Clima) zugeordnet. Gegenüber der Verwendung von Referenzen hat dieses den Vorteil, dass nur ein Profil auftaucht, dass auch bearbeitet werden kann und über das Attribut zugeordnet auf 3 Thermostate übertragen wird. Welchen Anwendungsfall gibt es dann noch für "referenzierende Profile"?
Sorry, weiß nicht, warum ich da nicht früher drauf gekommen bin. :-\
Oder stelle ich mir das wieder zu einfach vor und hätte ich diese Frage nicht stellen sollen?
Btw möchtest Du eigentlich überhaupt weitere Erfahrungswerte oder bist Du froh, wenn es erstmal läuft?
Hier der relevante Auszug aus dem erfolgreichen Log:
2016.03.29 18:38:25 5: Heizprofile(Set): found device WZ_Heiz_Clima
2016.03.29 18:38:25 4: Heizprofile(Set): Send profile testWochenplan:Wohnzimmer to WZ_Heiz_Clima
2016.03.29 18:38:25 4: Heizprofile(sendDevProfile): set WZ_Heiz_Clima tempListMon exec 15:30 17.0 18:00 20.0 24:00 17.0
2016.03.29 18:38:25 3: CUL_HM set WZ_Heiz_Clima tempListMon exec 15:30 17.0 18:00 20.0 24:00 17.0
2016.03.29 18:38:25 5: Heizprofile(Set): found device WZ_Klima_Climate
2016.03.29 18:38:25 4: Heizprofile(Set): Send profile testWochenplan:Wohnzimmer to WZ_Klima_Climate
2016.03.29 18:38:25 4: Heizprofile(sendDevProfile): set WZ_Klima_Climate tempListMon exec 15:30 17.0 18:00 20.0 24:00 17.0
2016.03.29 18:38:25 3: CUL_HM set WZ_Klima_Climate tempListMon exec 15:30 17.0 18:00 20.0 24:00 17.0
2016.03.29 18:38:25 5: Heizprofile(Set): found device WZ_Heiz_Kammer_Clima
2016.03.29 18:38:25 4: Heizprofile(Set): Send profile testWochenplan:Wohnzimmer to WZ_Heiz_Kammer_Clima
2016.03.29 18:38:25 4: Heizprofile(sendDevProfile): set WZ_Heiz_Kammer_Clima tempListMon exec 15:30 17.0 18:00 20.0 24:00 17.0
2016.03.29 18:38:26 3: CUL_HM set WZ_Heiz_Kammer_Clima tempListMon exec 15:30 17.0 18:00 20.0 24:00 17.0
Anmerkung zu HMInfo:
Bei HMInfo vermute ich zurückblickend, haben wir vielleicht aneinander vorbei kommuniziert. Ich dachte ursprünglich an ein Interface, dass mir die Templ-Dateien für HMInfo erstellt, um diese dann mit HMInfo zu übertragen. Das allerdings kann das Weekprofile ja aber bereits direkt, so dass mein Bedarf der Verwaltung perfekt abgedeckt ist. Du und vielleicht Martin hattet vielleicht eher die prüfende Funktionalität von HMInfo im Sinn. Dass allerdings wäre wirklich nur nice-to-have. Außerdem prüft Weekprofile ja ebenfalls auf Übereinstimmungen beim restore eines Topics, daher wird solch eine Integration der Prüfung noch weniger interessant.
Schöne Grüße,
John
Hallo John,
so wie du es konfiguriert hast, kann man es natürlich machen. Ich sehe es aber nicht für so sinnvoll an.
Willst du nun bspw. einem Thermostat in der Sommerperiode ein anderes Profil geben, ist das nicht so einfach mgl. Jedenfalls nicht mit nur einer Instanz von weekprofile.
Ich würde es z.B. so machen:
Deine drei Thermostate kürze ich mal mit WZ1, WZ2, WZ3 ab.
Topic: Standard, Winter, Sommer mit folgenden Profilen anlegen.
Standard:Wohnzimmer = dein aktueller Plan "Wohnzimmer"
Winter:WZ1 --> referenziert zu Standard:Wohnzimmer
Winter:WZ2 --> referenziert zu Standard:Wohnzimmer
Winter:WZ3 --> referenziert zu Standard:Wohnzimmer
Sommer:WZ1 --> referenziert zu Standard:Wohnzimmer
Sommer:WZ2 --> referenziert zu Standard:Wohnzimmer
Sommer:WZ3
neues Profil\Plan für dieses Thermostat im SommerDen Userattributen der einzelnen Thermostate muss WZ1,WZ2 bzw. WZ3 zugewiesen werden.
Wenn man nun von Winter auf Sommer wechselt, wird nur das Profil im Thermostat WZ3 geändert, weil sich Sommer:WZ3 von Standard:Wohnzimmer unterscheidet.
Will man nun bspw. den Standardplan ändern muss man dieses Plan nur einmalig in Standard:Wohnzimmer ändern und dann restore Topic Sommer\Winter aufrufen.
Hoffe der Sinn von Referenzen ist somit etwas verständlicher geworden.
Zitat von: joshi04 am 29 März 2016, 19:25:29
Btw möchtest Du eigentlich überhaupt weitere Erfahrungswerte oder bist Du froh, wenn es erstmal läuft?
Bin immer offen für neue\andere Anwendungsfälle bzw. Erfahrungen, denn nur so kann das Modul sinnvoll weiter entwickelt werden.
Damit ist natürlich noch nicht gesagt, ob und wenn das erfolgen wird.
Zu HMInfo:
Um hier konkrete Aussagen treffen zu können, fehlt mir die Erfahrung mit HMInfo. Kenne den Workflow hier nicht ausreichend. Meiner Meinung nach könnte die Wochenprofilverwaltung aus HMInfo entfernt werden. Ob und wie HMInfo zur Prüfung auf weekprofile zurückgreift ist noch nicht diskutiert worden. Den oder die konkreten Anwendungsfälle müssen hier von HM-Anwendern kommen.
Auch der anfänglich gedachte Plan die Wochenprofile von HMInfo einzulesen\abzufragen ist bis jetzt nicht weiter verfolgt worden.
Risiko
Hallo Risiko,
Danke für die Erklärung. Ich glaube langsam wird mir klarer wozu man die Referenzen benötigt. Aber auch klarer, dass das vermutlich ein ganz anderer Anwendungsfall ist, als er bei mir zum Einsatz kommt.
Wenn ich es in meinen Worten noch einmal ausdrücken darf:
Topics:
Falls man in einem Topic (Winter) das gleiche Profil (Wohnzimmer) mehreren Thermostaten (WZ1, WZ2 und WZ3) zuweisen möchte, in einem anderen Topic (Sommer) für einen dieser Thermostate (WZ3) aber ein abweichendes benötigt.
Bei mir sind alle drei Thermostate in einem Raum und unterschiedliche Profile innerhalb des gleichen Raumes werden nicht benötigt. Im Detail handelt es sich um einen Wandthermostat, der für sich alleine eigentlich schon ausreichen würde, die beiden Heizungsthermostate (an der Heizung) zu steuern und nur aus Redundanzgründen soll das gleiche Profil auch auf die Heizungsthermostate selbst drauf, falls mal was mit dem Wandthermostat nicht passt.
HM-Hintergrund: Bei HM ist es möglich, die Solltemperatur und/oder die Ist-Temperatur von einem Wandthermostat an einen Heizungsthermostaten zu übergeben. Das Profil auf den Heizungsthermostaten ist bei dieser Betriebsart nicht aktiv. Ich bin nicht sicher, wie das bei MAX läuft. Und um ehrlich zu sein, weiß ich auch nicht, was der Heizungsthermostat macht, wenn er nichts mehr vom Wandthermostat hört...
Für diesen Anwendungsfall würde ich ein und das selbe Profil einfach direkt allen Thermostaten zuweisen ohne Referenzen. Das hat zum Vorteil, dass ich auch nur ein Profil pro Raum im Dropdown habe, mehr wäre aber auch nicht nötig. Könntest Du erläutern, ob bzw. was Du daran nicht für sinnvoll hältst? Ich fühle mich begriffsstutzig mit Brett vor dem Kopf in der Hoffnung, ich habe meinen Fall zu ungenau beschrieben.
Zu HMInfo, einen Bedarf kann ich selbst derzeit nicht formulieren. Das mag aber auch daran liegen, dass ich bzgl. HM noch am Anfang stehe und mich mit HMInfo bislang auch nur rudimentär und mit Hinblick auf die Wochenpläne beschäftigt habe. Dieses Feld läuft aber mit Deinem Modul anwenderfreundlicher und aufgabenerfüllend. Daher, solle man den Hinweis im Wiki erstmal wieder herausnehmen? Ansonsten übergebe ich hier gerne an andere HM-Anwender mit konkreten Vorstellungen. ;)
Bezüglich Betrieb ist mir noch etwas aufgefallen, dass mM die Funktionalität aber nicht beeinträchtigt.
Wenn ich fhem starte (nicht beim reread oder shutdown restart) erhalte ich folgenden Log:
2016.03.31 20:40:06 1: Including ./FHEM/99_HM.cfg
2016.03.31 20:40:06 1: HMLAN_Parse: HMLAN new condition disconnected
2016.03.31 20:40:06 3: Opening HMLAN device 192.168.150.13:1000
2016.03.31 20:40:06 3: HMLAN device opened
2016.03.31 20:40:06 1: HMLAN_Parse: HMLAN new condition init
main::weekprofile_findPRF() called too early to check prototype at ./FHEM/98_weekprofile.pm line 572.
2016.03.31 20:40:09 5: Heizprofile(weekprofile_Attr): set, widgetEditOnNewPage, 1
2016.03.31 20:40:09 5: Heizprofile(weekprofile_Attr): set, widgetWeekdays, Montag,Dienstag,Mittwoch,Donnerstag,Freitag,Samstag,Sonntag
Normaler Weise würde ich bei so etwas auf die Reihenfolge der Defines innerhalb der fhem.cfg tippen, die Definition von Weekprofile steht aber ganz unten, nachdem alle Thermostaten bereits bekannt sein sollten.
Ich werde mal ein bisschen herum probieren, ob ich das näher eingrenzen kann. Noch ist nichts produktiv.
Schöne Grüße,
John
Hallo John,
wenn alle Thermostate in einem Raum ist, ist der Weg mit dem Attribut schon völlig ok.
Denke aber auch, dass es eigentlich völlig ausreichend sein sollte das Profil dem Wandthermostat und nicht noch den Heizkörperthermostaten zu senden. Mach ich bei MAX! auch so.
Betreffs der Logmeldung:
Kann ich leider (noch) nicht nachvollziehen. Spontan habe ich auch keine Idee woher das kommen könnte.
Versuche da aber mal dran zu bleiben.
Hallo Risiko,
über die Fragestellung, welche Profile auf welches Thermostat sollte, gibt es tatsächlich sehr unterschiedliche Meinungen hier im Forum. Die Fragestellung ist hier aber OT. Nur zur Info, nach etwas Suchen im Forum hat Martin für HM hier mal etwas detaillierter eine Aussage gemacht. https://forum.fhem.de/index.php/topic,46790.msg385323.html#msg385323 (https://forum.fhem.de/index.php/topic,46790.msg385323.html#msg385323) Und wenn man genau liest, steht es auch im Wiki. :o
Bezüglich der Logmeldung konnte ich das Verhalten leider nicht weiter eingrenzen.
Falls Du trotzdem schauen möchtest im Folgenden was ich probiert habe:
- Meldung kommt nur beim Kaltstart, also wenn man den fhem-Dienst beendet und neu startet und "shutdown restart". Bei "reread config" taucht die Meldung nicht auf. Leider weiß ich nicht genau, welche Prozesse während der Initialisierung im Einzelnen ablaufen.
- Meldung ist unabhängig vom Attribut Topics.
- Meldung ist unabhängig von referenzierten Profilen.
- Meldung ist unabhängig von zugewiesenen Profilen, d.h. auch ohne Deckung zwischen Profilen und Attributdefinition.
- Meldung kommt auch, wenn die Definition des Moduls ganz am Ende der cfg steht (um Fehler durch die Reihenfolge auszuschließen).
- Meldung kommt auch auf einem komplett nackten System, sobald man das Modul einmal definiert hat.
- Perl Version 5.14.2
- dpkg -s libjson-pp-perl | grep Version
Version: 2.27200-2 - 98_weekprofile.pm 11138 2016-03-28 14:28:21Z risiko79
- Mehr fällt mir nicht ein.
Da die Funktionalität aber nicht beeinträchtigt scheint, würde ich das mit sehr geringer Wichtigkeit einstufen.
Eine Anmerkung noch zu HMInfo, im oben verlinkten Forumseintrag hatte Martin im Januar man geschrieben, wie er sich das vermutlich vorstellt. Wenn das noch seine aktuelle Meinung ist und ich Dich auch richtig verstanden habe, gibt es vermutlich einen Patt.
Allerdings bleibe ich auch bei meiner Aussage, bei mir läuft derzeit alles. :)
Seit ein paar Tagen (mM nach einem Update außerhalb von weekprofile) sind ein paar Perl Warnungen beim Systemstart aufgetaucht:
2016.04.10 18:03:35 1: PERL WARNING: Argument "0D" isn't numeric in addition (+) at ./FHEM/98_weekprofile.pm line 68.
2016.04.10 18:03:35 1: PERL WARNING: Argument "0A" isn't numeric in addition (+) at ./FHEM/98_weekprofile.pm line 68.
2016.04.10 18:03:35 1: PERL WARNING: Argument "0E" isn't numeric in addition (+) at ./FHEM/98_weekprofile.pm line 68.
2016.04.10 18:03:35 1: PERL WARNING: Argument "0C" isn't numeric in addition (+) at ./FHEM/98_weekprofile.pm line 68.
2016.04.10 18:03:35 1: PERL WARNING: Argument "0B" isn't numeric in addition (+) at ./FHEM/98_weekprofile.pm line 68.
2016.04.10 18:03:35 1: PERL WARNING: Argument "0F" isn't numeric in addition (+) at ./FHEM/98_weekprofile.pm line 68.
Hat das noch jemand bei sich?
Hallo joshi04,
da scheint die Channel Nummer 'chanNo' vom Device keine Zahl zu sein!?
Hat sich da was bei HM geändert?
Fange das jetzt explizit ab.
Hallo Risiko,
zumindest nicht offensichtlich, hier ein Wandthermostat mit chanNo "02". Ein Heizungsthermostat hat wie bekannt "04".
CFGFN ./FHEM/99_HM.cfg
CHANGED
DEF 458DB802
NAME BD_Klima_Climate
NR 340
STATE T: 21.7 desired: 20.0
TYPE CUL_HM
chanNo 02
device BD_Klima
peerList BD_Heiz_Climate,
Helper:
Dblog:
Desired-temp:
Mydblog:
TIME 1460389370.88268
VALUE 20.0
Readings:
2016-04-07 06:36:15 CommandAccepted yes
2016-03-26 12:56:53 R-dayTemp 22 C
2016-03-25 13:50:41 R-daylightSaveTime on
2016-03-25 13:50:41 R-heatCool heating
2016-03-25 13:50:41 R-hyst2point 0.4 C
2016-03-25 13:50:41 R-modePrioManu all
2016-03-25 13:50:41 R-modePrioParty all
2016-03-25 13:50:41 R-nightTemp 17 C
2016-03-25 13:50:41 R-noMinMax4Manu off
2016-04-02 13:33:29 R-sendWeatherData on
2016-04-02 13:33:29 R-showHumidity tempHum
2016-03-25 13:50:41 R-showInfo time
2016-04-02 13:33:29 R-showSetTemp actTemp
2016-03-25 13:50:36 R-sign off
2016-04-02 13:33:29 R-tempOffset 0.0K
2016-03-25 13:50:41 R-weekPrgSel prog1
2016-03-25 13:50:41 R-winOpnBoost off
2016-04-02 13:33:29 R_P1_0_tempListSat 07:00 20.0 10:00 22.0 24:00 20.5
2016-04-02 13:33:29 R_P1_1_tempListSun 07:00 20.0 10:00 22.0 24:00 20.5
2016-04-02 13:33:29 R_P1_2_tempListMon 04:00 20.0 08:00 22.0 15:00 16.5 24:00 20.0
2016-04-02 13:33:29 R_P1_3_tempListTue 04:00 20.0 08:00 22.0 15:00 16.5 24:00 20.0
2016-04-02 13:33:29 R_P1_4_tempListWed 04:00 20.0 08:00 22.0 15:00 16.5 24:00 20.0
2016-04-02 13:33:29 R_P1_5_tempListThu 04:00 20.0 08:00 22.0 15:00 16.5 24:00 20.0
2016-04-02 13:33:29 R_P1_6_tempListFri 04:00 20.0 08:00 22.0 15:00 16.5 24:00 20.0
2016-04-02 13:33:29 R_P1_tempList_State verified
2016-04-02 13:33:33 R_P2_0_tempListSat 24:00 17.0
2016-04-02 13:33:33 R_P2_1_tempListSun 24:00 17.0
2016-04-02 13:33:33 R_P2_2_tempListMon 24:00 17.0
2016-04-02 13:33:33 R_P2_3_tempListTue 24:00 17.0
2016-04-02 13:33:33 R_P2_4_tempListWed 24:00 17.0
2016-04-02 13:33:33 R_P2_5_tempListThu 24:00 17.0
2016-04-02 13:33:33 R_P2_6_tempListFri 24:00 17.0
2016-04-02 13:33:33 R_P2_tempList_State verified
2016-04-02 13:33:36 R_P3_0_tempListSat 24:00 17.0
2016-04-02 13:33:36 R_P3_1_tempListSun 24:00 17.0
2016-04-02 13:33:36 R_P3_2_tempListMon 24:00 17.0
2016-04-02 13:33:36 R_P3_3_tempListTue 24:00 17.0
2016-04-02 13:33:36 R_P3_4_tempListWed 24:00 17.0
2016-04-02 13:33:36 R_P3_5_tempListThu 24:00 17.0
2016-04-02 13:33:36 R_P3_6_tempListFri 24:00 17.0
2016-04-02 13:33:36 R_P3_tempList_State verified
2016-04-02 13:33:25 RegL_01. 08:00 00:00
2016-04-02 13:33:29 RegL_07. 01:2C 02:22 03:09 04:3D 05:00 06:00 07:00 08:00 09:C7 0A:30 0B:00 0C:00 0D:00 0E:01 0F:04 10:00 11:00 12:09 13:00 14:50 15:54 16:58 17:78 18:53 19:20 1A:45 1B:20 1C:45 1D:20 1E:45 1F:20 20:45 21:20 22:45 23:20 24:45 25:20 26:45 27:20 28:45 29:20 2A:45 2B:20 2C:45 2D:20 2E:50 2F:54 30:58 31:78 32:53 33:20 34:45 35:20 36:45 37:20 38:45 39:20 3A:45 3B:20 3C:45 3D:20 3E:45 3F:20 40:45 41:20 42:45 43:20 44:45 45:20 46:45 47:20 48:50 49:30 4A:58 4B:60 4C:42 4D:B4 4E:51 4F:20 50:45 51:20 52:45 53:20 54:45 55:20 56:45 57:20 58:45 59:20 5A:45 5B:20 5C:45 5D:20 5E:45 5F:20 60:45 61:20 62:50 63:30 64:58 65:60 66:42 67:B4 68:51 69:20 6A:45 6B:20 6C:45 6D:20 6E:45 6F:20 70:45 71:20 72:45 73:20 74:45 75:20 76:45 77:20 78:45 79:20 7A:45 7B:20 7C:50 7D:30 7E:58 7F:60 80:42 81:B4 82:51 83:20 84:45 85:20 86:45 87:20 88:45 89:20 8A:45 8B:20 8C:45 8D:20 8E:45 8F:20 90:45 91:20 92:45 93:20 94:45 95:20 96:50 97:30 98:58 99:60 9A:42 9B:B4 9C:51 9D:20 9E:45 9F:20 A0:45 A1:20 A2:45 A3:20 A4:45 A5:20 A6:45 A7:20 A8:45 A9:20 AA:45 AB:20 AC:45 AD:20 AE:45 AF:20 B0:50 B1:30 B2:58 B3:60 B4:42 B5:B4 B6:51 B7:20 B8:45 B9:20 BA:45 BB:20 BC:45 BD:20 BE:45 BF:20 C0:45 C1:20 C2:45 C3:20 C4:45 C5:20 C6:45 C7:20 C8:45 C9:20 CA:00 CB:00 CC:00 CD:00 CE:00 CF:00 00:00
2016-04-02 13:33:33 RegL_08. 01:00 02:00 03:00 04:00 05:00 06:00 07:00 08:00 09:00 0A:00 0B:00 0C:00 0D:00 0E:00 0F:00 10:00 11:00 12:00 13:00 14:45 15:20 16:45 17:20 18:45 19:20 1A:45 1B:20 1C:45 1D:20 1E:45 1F:20 20:45 21:20 22:45 23:20 24:45 25:20 26:45 27:20 28:45 29:20 2A:45 2B:20 2C:45 2D:20 2E:45 2F:20 30:45 31:20 32:45 33:20 34:45 35:20 36:45 37:20 38:45 39:20 3A:45 3B:20 3C:45 3D:20 3E:45 3F:20 40:45 41:20 42:45 43:20 44:45 45:20 46:45 47:20 48:45 49:20 4A:45 4B:20 4C:45 4D:20 4E:45 4F:20 50:45 51:20 52:45 53:20 54:45 55:20 56:45 57:20 58:45 59:20 5A:45 5B:20 5C:45 5D:20 5E:45 5F:20 60:45 61:20 62:45 63:20 64:45 65:20 66:45 67:20 68:45 69:20 6A:45 6B:20 6C:45 6D:20 6E:45 6F:20 70:45 71:20 72:45 73:20 74:45 75:20 76:45 77:20 78:45 79:20 7A:45 7B:20 7C:45 7D:20 7E:45 7F:20 80:45 81:20 82:45 83:20 84:45 85:20 86:45 87:20 88:45 89:20 8A:45 8B:20 8C:45 8D:20 8E:45 8F:20 90:45 91:20 92:45 93:20 94:45 95:20 96:45 97:20 98:45 99:20 9A:45 9B:20 9C:45 9D:20 9E:45 9F:20 A0:45 A1:20 A2:45 A3:20 A4:45 A5:20 A6:45 A7:20 A8:45 A9:20 AA:45 AB:20 AC:45 AD:20 AE:45 AF:20 B0:45 B1:20 B2:45 B3:20 B4:45 B5:20 B6:45 B7:20 B8:45 B9:20 BA:45 BB:20 BC:45 BD:20 BE:45 BF:20 C0:45 C1:20 C2:45 C3:20 C4:45 C5:20 C6:45 C7:20 C8:45 C9:20 CA:00 CB:00 CC:00 CD:00 CE:00 CF:00 00:00
2016-04-02 13:33:36 RegL_09. 01:00 02:00 03:00 04:00 05:00 06:00 07:00 08:00 09:00 0A:00 0B:00 0C:00 0D:00 0E:00 0F:00 10:00 11:00 12:00 13:00 14:45 15:20 16:45 17:20 18:45 19:20 1A:45 1B:20 1C:45 1D:20 1E:45 1F:20 20:45 21:20 22:45 23:20 24:45 25:20 26:45 27:20 28:45 29:20 2A:45 2B:20 2C:45 2D:20 2E:45 2F:20 30:45 31:20 32:45 33:20 34:45 35:20 36:45 37:20 38:45 39:20 3A:45 3B:20 3C:45 3D:20 3E:45 3F:20 40:45 41:20 42:45 43:20 44:45 45:20 46:45 47:20 48:45 49:20 4A:45 4B:20 4C:45 4D:20 4E:45 4F:20 50:45 51:20 52:45 53:20 54:45 55:20 56:45 57:20 58:45 59:20 5A:45 5B:20 5C:45 5D:20 5E:45 5F:20 60:45 61:20 62:45 63:20 64:45 65:20 66:45 67:20 68:45 69:20 6A:45 6B:20 6C:45 6D:20 6E:45 6F:20 70:45 71:20 72:45 73:20 74:45 75:20 76:45 77:20 78:45 79:20 7A:45 7B:20 7C:45 7D:20 7E:45 7F:20 80:45 81:20 82:45 83:20 84:45 85:20 86:45 87:20 88:45 89:20 8A:45 8B:20 8C:45 8D:20 8E:45 8F:20 90:45 91:20 92:45 93:20 94:45 95:20 96:45 97:20 98:45 99:20 9A:45 9B:20 9C:45 9D:20 9E:45 9F:20 A0:45 A1:20 A2:45 A3:20 A4:45 A5:20 A6:45 A7:20 A8:45 A9:20 AA:45 AB:20 AC:45 AD:20 AE:45 AF:20 B0:45 B1:20 B2:45 B3:20 B4:45 B5:20 B6:45 B7:20 B8:45 B9:20 BA:45 BB:20 BC:45 BD:20 BE:45 BF:20 C0:45 C1:20 C2:45 C3:20 C4:45 C5:20 C6:45 C7:20 C8:45 C9:20 CA:00 CB:00 CC:00 CD:00 CE:00 CF:00 00:00
2016-04-11 18:35:50 boostTime -
2016-04-11 18:35:50 commReporting off
2016-04-11 18:35:50 controlMode auto
2016-04-11 18:48:19 desired-temp 20.0
2016-04-11 18:48:19 humidity 54
2016-04-11 18:48:19 measured-temp 21.7
2016-04-10 20:52:47 peerList BD_Heiz_Climate,
2016-04-07 06:36:15 recentStateType ack
2016-04-11 18:48:19 state T: 21.7 desired: 20.0
2016-03-25 13:53:36 temperature 0
2016-04-11 18:35:50 winOpenReporting off
Helper:
Expert:
def 1
det 0
raw 1
tpl 0
Role:
chn 1
Shregr:
07 00
Attributes:
alias Bad Wandthermostat
event-on-change-reading desired-temp
group Heizung
icon hm-tc-it-wm-w-eu
model HM-TC-IT-WM-W-EU
peerIDs 00000000,44E63B02,
room Bad
tempListTmpl none
userattr weekprofile
weekprofile Bad
Schöne Grüße,
John
Bestätige, heute nach update keine Warnungen mehr.
Vielen Dank für die schnelle Behebung.
Schön. Danke fürs schnelle Testen.
PS: Die Warnungen können auch von anderen CUL_HM-Devices gekommen sein.
Hm... vielleicht haben wir uns zu früh gefreut. Getestet, ja, vielleicht aber zu schnell und nicht nachhaltig genug.
Zwar sind die Warnungen verschwunden, allerdings anscheinend auch die Funktionalität.
Ein restore Topic führt nicht zur Übertragung an die Thermostate, bzw. im Detail, es passiert nichts und das Log bleibt leer (verbose 5), als ob die Ausführung abgefangen wird.
Getestet mit 98_weekprofile.pm 11226 2016-04-11 16:38:26Z risiko79
Um sicher zu gehen, habe ich es noch einmal mit der vorherigen Version getestet:
98_weekprofile.pm 11138 2016-03-28 14:28:21Z risiko79
Hier kommen die Einträge im Log wie erwartet:
2016.04.14 20:46:46 5: Heizprofile(Set): found device SZ_Heiz_Clima
2016.04.14 20:46:46 4: Heizprofile(Set): Send profile normalerWochenplan:Schlafzimmer to SZ_Heiz_Clima
...
Sorry!
Vielleicht könnte noch jemand anders mit HM-Thermostaten das nachstellen um auszuschließen, dass es an meiner Konfig liegt.
Anbei mal eine Version, wo ich die letzte Änderung wieder rückgängig gemacht und mehr Log's eingebaut habe.
Hoffe somit dem Problem auf die Spur zu kommen.
Bitte mal mit verbose 4 testen.
Danke.
Mal ein kurzer Status von meiner Seite, versuche gerade ein Minimalsystem zu identifizieren, um die Warnungen weiter einzugrenzen.
Zwischenstand, mit "nur alle Thermostate" definiert, bekomme ich keine Warnungen.
Das hatte ich mir irgendwie leichter zu identifizieren vorgestellt...
Neue Version ins SVN eingecheckt. Warnungen + Fehler gefixed.
Sorry, ich war nicht schnell genug.
Um das Rätsel zu lüften:
Zitat von: Risiko am 12 April 2016, 21:30:03
PS: Die Warnungen können auch von anderen CUL_HM-Devices gekommen sein.
Und genau so war es auch:
Internals:
CFGFN ./FHEM/99_HM_test.cfg
DEF 303FBB0A
NAME FL_centralswitch_Btn_10
NR 119
NTFY_ORDER 50-FL_centralswitch_Btn_10
STATE ???
TYPE CUL_HM
chanNo 0A
device FL_centralswitch
Readings:
Helper:
Expert:
def 1
det 0
raw 1
tpl 0
Role:
chn 1
Attributes:
model HM-PB-4DIS-WM-2
peerIDs 00000000, Und davon gibt es noch ein paar weitere Buttons...
Werde morgen nach dem normalen Update nochmal testen.
Danke für das schnelle fixen.
Getestet: Systemstart, Verify bei restore Topic ohne Änderung und Änderung eine Profils mit restore Topic funktionieren.
Beim Systemstart kommt noch eine Warnung, die beeinträchtigt aber nicht die Funktion. Und ich weiß jetzt auch, welche Definitionen im "hex-bereich" liegen :)
2016.04.17 09:12:07 1: PERL WARNING: Use of uninitialized value $type in concatenation (.) or string at ./FHEM/98_weekprofile.pm line 99.
2016.04.17 09:12:07 4: Heizprofile(getDeviceType): FL_centralswitch_Btn_15, HM-PB-4DIS-WM-2, chanNo 0F is no number
2016.04.17 09:12:07 4: Heizprofile(getDeviceType): FL_centralswitch_Btn_13, HM-PB-4DIS-WM-2, chanNo 0D is no number
2016.04.17 09:12:07 4: Heizprofile(getDeviceType): FL_centralswitch_Btn_14, HM-PB-4DIS-WM-2, chanNo 0E is no number
2016.04.17 09:12:07 4: Heizprofile(getDeviceType): FL_centralswitch, HM-PB-4DIS-WM-2, has no chanNo
2016.04.17 09:12:07 4: Heizprofile(getDeviceType): FL_centralswitch_Btn_11, HM-PB-4DIS-WM-2, chanNo 0B is no number
2016.04.17 09:12:07 4: Heizprofile(getDeviceType): FL_centralswitch_Btn_10, HM-PB-4DIS-WM-2, chanNo 0A is no number
2016.04.17 09:12:07 4: Heizprofile(getDeviceType): ActionDetector, ActionDetector, has no chanNo
2016.04.17 09:12:07 4: Heizprofile(getDeviceType): VCCU, CCU-FHEM, has no chanNo
2016.04.17 09:12:07 4: Heizprofile(getDeviceType): FL_centralswitch_Btn_12, HM-PB-4DIS-WM-2, chanNo 0C is no number
Danke und schönen Sonntag.
Hallo John,
danke fürs testen. Habe nun hoffentlich mit der neuen Version im SVN auch die letzte Warnung gefixt. ???
In der neuen Version prüfe ich auch erst auf model und dann auf chanNo.
Au weia, und alles nur wegen meinem Multischalter :-[
Melde mich morgen nach dem offiziellen Update.
Getestet: Systemstart ohne Warnung, Verify bei restore Topic ohne Änderung und Änderung eines Profils mit restore Topic funktionieren.
Läuft!
Vielen Dank.
Hallo!
Also erstmal ein dickes DANKE für das super Widget!
Ich hab bei mir ein weekprofile mit
define WZ_Heiz_Wochenplan weekprofile
definiert und es wurde automatisch mit einem Profil "default" angelegt.
Ich brauche nur das default Profil, da ich für jedes Zimmer ein eigenes weekprofil erstellen will um dies dann auch im FTUI ändern zu können.
Wenn ich jetzt das Wochenprofil ändere und es meinem Thermostat_Climate zuweise passiert erstmal nichts. Eh klar.
Dann stelle ich mit
set WZ_Heiz_Therm_Climate controlMode auto
auf automatischen Betrieb um.
Jetzt wird die desiredTemp auf die gewünschte Temperatur umgestellt.
Aber leider nur dieses eine mal. Dann tut sich nichts mehr.
Auf einmal funktionierts! :-)
In meinem Logfile steht:
PERL WARNING: splice on reference is experimental at ./FHEM/98_weekprofile.pm line 305, <$fh> line 193.
PERL WARNING: splice on reference is experimental at ./FHEM/98_weekprofile.pm line 856, <$fh> line 193.
Kann mir hier jemand sagen was ich machen soll?
Danke im voraus.
Hallo Hanner72,
sorry für die späte Antwort. Etwas viel Beschäftigt.
Steht doch aber in der Warnung alles da. In deiner Perlversion ist die Funktion splice noch als experimentell eingestuft. Da kannst du nicht viel machen. Wenn es funktioniert, würde ich nichts ändern. Ggf. kannst du die Perlversion wechseln oder ich könnte eine Alternative implementieren, wofür ich aktuell aber keine Zeit habe.
Risiko.
Zitat von: Risiko am 11 September 2016, 20:21:06
Steht doch aber in der Warnung alles da. In deiner Perlversion ist die Funktion splice noch als experimentell eingestuft. Da kannst du nicht viel machen. Wenn es funktioniert, würde ich nichts ändern. Ggf. kannst du die Perlversion wechseln oder ich könnte eine Alternative implementieren, wofür ich aktuell aber keine Zeit habe.
Die Standard Perl Version auf dem Raspbian Jessie stuft splice on reference derzeit als experimentell ein.
Fehlfunktionen sind mir nicht aufgefallen.
ich habe Zeile 305
splice($hash->{SNDDEVLIST});durch
delete $hash->{SNDDEVLIST};und Zeile 856
splice($own->{PROFILES});durch
delete $own->{PROFILES};ersetzt.
Das sollte die gleiche Funktion haben und die Warnungen sind weg.
Grüße
Klaus
Hallo Klaus,
könntest du mir nen Diff schicken, dann kann ichs als Fix rein nehmen.
Danke.
so etwa?
diff -crB 98_weekprofile.pm 98_weekprofile.old
*** 98_weekprofile.old 2016-09-19 21:46:05.683354300 +0200
--- 98_weekprofile.pm 2016-09-19 21:43:57.416245900 +0200
***************
*** 302,308 ****
my ($hash) = @_;
my $me = $hash->{NAME};
! splice($hash->{SNDDEVLIST});
foreach my $d (keys %defs)
{
--- 302,308 ----
my ($hash) = @_;
my $me = $hash->{NAME};
! delete $hash->{SNDDEVLIST};
foreach my $d (keys %defs)
{
***************
*** 853,859 ****
my ($what,$who) = split(' ',$s);
if ($what =~ m/INITIALIZED/ || $what =~ m/REREADCFG/) {
! splice($own->{PROFILES});
weekprofile_refreshSendDevList($own);
weekprofile_assignDev($own);
weekprofile_readProfilesFromFile($own);
--- 853,859 ----
my ($what,$who) = split(' ',$s);
if ($what =~ m/INITIALIZED/ || $what =~ m/REREADCFG/) {
! delete $own->{PROFILES};
weekprofile_refreshSendDevList($own);
weekprofile_assignDev($own);
weekprofile_readProfilesFromFile($own);
wenns nicht passt habe ich das komplette file angehängt
Hab es übernommen.
Ab morgen per Update.
super, danke
Edit: funktioniert bei mir..Warnung ist weg
Ist es eigentlich möglich, über weekprofile auch die Heizungszustände "On" und "Off" einzustellen? Im Widget kann ich nur einen Wert zwischen 5°C und 30°C einstellen.
Hallo reibuehl,
ich glaube, in den Wochenprofilen für die Thermostate ist on und off nicht vorgesehen. Habe es nie probiert.
Wenn alle Thermostate es unterstützen würden, könnte ich es im Modul weekprofile mit einbauen.
Risiko.
Ich kann nur für die aktuellen Homematic Thermostate sprechen. Der HM-CC-RT-DN und der HM-TC-IT-WM-W-EU können über das normale Web Interface beide auf On oder Off gestellt werden.
Ja schon klar. Aber innerhalb von Wochenprofilen?
Hallo,
ich habe das Problem das mir Fhem abstürzt wenn ich ein weekprofil mit assoziiertem Gerät anlege.
Nach diesem Muster:
define <name> weekprofile <device>
Mache ich das ohne Gerät , geht alles.
Fehlermeldung im Log:
hash- or arrayref expected (not a simple scalar, use allow_nonref to allow this) at ./FHEM/98_weekprofile.pm line 502.
Update sind aktuell und auch das vorgeschriebene Jason ist installiert.
Da ich die Thermostate über FTUI steuern möchte benötige ich die Variante assoziiertes Gerät ja.
Was mache ich falsch?
Hallo namor,
wenn kommt es zu dem Fehler? Geht es ohne FTUI, also nur mit FHEMWEB?
Was für ein Thermostat ist es denn? Wie sieht dein define aus?
Es sieht so aus, als wenn das Wochenprofil vom Thermostat nicht richtig abgefragt werden kann.
Risiko
Hallo Risiko,
wenn ich das weekprofil ohne assoziiertem Thermostat anlege läuft alles wie es soll.
Ich kann verschiedene Pläne anlegen und diese an meine verschiedenen Thermostate (Auswahl Thermostat_Climate) übertragen.
Meine Def:
define Heizplan_WHZ weekprofile
attr Heizplan_WHZ room 1_Wohnzimmer
Internals:
CFGFN /opt/fhem/FHEM/Wohnzimmer.cfg
NAME Heizplan_WHZ
NR 328
NTFY_ORDER 50-Heizplan_WHZ
STATE created
TYPE weekprofile
PROFILES:
HASH(0x10ed3d8)
Readings:
2016-10-02 12:14:09 profile_count 1
2016-10-02 12:14:09 state created
SNDDEVLIST:
HASH(0x2501468)
HASH(0x1c79460)
HASH(0x1bba228)
HASH(0x10989a0)
HASH(0x2501138)
HASH(0x2500928)
HASH(0x22692a0)
HASH(0x20117a0)
TOPICS:
default
Attributes:
room 1_Wohnzimmer
Soweit alles gut.
Da ich aber bei der Integration ins Ftui keine spezielle Möglichkeit zur Übertragung an den Thermostaten habe (über das Ftui Widget ändert er schön brav den Wochenplan),
benötige ich nach meinem Verständnis des weekprofil-Modules, ein assoziiertes Gerät (also meinen Thermostaten "THM_WHZ").
Wenn ich also folgende Def mache:
define Heizplan_WHZ weekprofile THM_WHZ
attr Heizplan_WHZ room 1_Wohnzimmer
Erstellt er alles wie gewünscht, doch beim nächsten rereadcfg hängt sich Fhem weg.
Erst ein Neustart bringt Fhem wieder hoch.
Danach sehe ich im Log die aufgeführte Meldung.
Bei jedem weiteren reredcfg passiert das selbe.
Zu Deinen Fragen.
Ich versuche das alles erst einmal ohne FTUI.
Meine gesamte Fhem Umgebung ist Homematic, der Thermostat mit welchem ich das teste ist ein aktueller HM-TC-IT-WM-W-EU mit zwei angebundenen Heizkörperthermostaten HM-CC-RT-DN und einem Fensterkontakt HM-SEC-SCo.
Im Log- Verzeichnis wird auch die Wochenprofil.cfg erstellt.
Ich habe keine Ahnung was da nicht passt.
Hi Risiko,
sorry für den Aufwand.
Habe den Fehler gefunden, wer Lesen kann ist klar im Vorteil.
Bei Homematc muss wohl als assoziiertes Gerät der Climate Kanal (THM_WHZ_Climate) angegeben werden.
Deine Aussage das der Wochenplan aus dem Gerät nicht gelesen werden kann hat mich darauf gebracht.
Dennoch vielen Dank für Deine Unterstützung.
Kurz noch zur Ergänzung für alle Homematic Anwender.
Bei Homematic muss als Device der Climate angegeben werden, Im weekprofil und im Attribut des Device.
Weekprofil (als assoziiertes Master Device ):
define Heizplan_WHZ weekprofile THM_WHZ_Climate
Attribute im Device (THM_WHZ_Climate)
attr THM_WHZ_Climate userattr weekprofile
attr THM_WHZ_Climate weekprofile master
@Risiko
Das sollte evtl. auch ins Wiki.
Steht doch din ;)
Die Attribute brauchst du in diesem Fall nicht.
Hallo,
vielen Dank erstmal für das tolle Modul.
Leider gibt es einen Bug falls der Device-Name einen Punkt beinhaltet. Das Widget bringt beim Speichern eines Profils FHEM komplett zum Absturz.
Meine Lösung war es den Wochentag als data-Attribut zu hinterlegen; somit spart man sich "split-Abenteuer" ;-)
Hier die Änderungen in fhemweb_weekprofile.js:
ALT: $(table).attr('id',"weekprofile."+widget.DEVICE+"."+shortDays[day]);
NEU: $(table).attr('id',"weekprofile."+widget.DEVICE).attr("data-day", shortDays[day]);
ALT: var id = $(tableDay[i]).attr('id').split('.'); var day = id[2];
NEU: var day = $(tableDay[i]).data("day");
Vielleicht kann man die Änderung ja mit übernehmen.
Gruß
Hulzer
Vielen Dank.
Hab es übernommen und eingecheckt.
Hallo,
Leider haben die Änderungen in fhemweb_weekprofile.js einen Seiteneffekt auf das Kopieren von "Tageseinstellungen". Seit der Änderung funktioniert dies leider nicht mehr.
Ich habe bei mir die alte fhemweb_weekprofile.js vom 20-02-2016 zurückgesichert und damit klappts wieder einwandfrei. (Habe aber auch keine Punkte in meinen Device Names)
Das Problem wurde auch bereits hier https://forum.fhem.de/index.php?topic=59360.new;topicseen#new (https://forum.fhem.de/index.php?topic=59360.new;topicseen#new) angesprochen.
Vielleicht kann sich das jemand ansehen.
Danke und lg
Hab es gefixt und eingecheckt.
Ab morgen per Update.
Super! Danke für den schnellen Fix! Klappt wieder!
Ich habe das Update gemacht, bei mir tut sich nichts. Shutdown restart natürlich auch.
Siehe anderen Thread: Neuanlegen und Neustart und GEHT!
Danke
Ich habe mein altes, neues Problem im anderen weekprofile Thread gepostet.
Dann wird es wohl nicht bearbeitet.
Ich beobachte nur diesen Thread, da dieser der Thread für das Modul ist
OK, ich habe das
Ich habe mich zu früh gefreut. Die Übertragung der Tage ging ABER ich kann nichts mehr ändern. Ändern ja, die speicherung geht aber nicht, es bleibt beim alten. Wie soll ich vorgehen?
im anderen thread gepostet.
Das "nichtspeichern" ist mein Problem.
Also ich kann kein Problem feststellen.
Verbose des Moduls mal auf 5 stellen, Änderungen machen und speichern. Schauen was im Log ankommt.
Nur um sicher zu gehen. Wäre das richtig?
attr weekprofile verbose 5
Hallo,
ich nutze das Modul und bräuchte einen Event zum Aktualisieren von Userreadings, der immer trifft, wenn ich eine Einstellung geändert habe.
Aktuell werden Userreadings nur aktualisiert, wenn sich "profile_count" ändert. Ich muss also immer ein neues Profile hinzufügen oder eines löschen.
Übersehe ich da etwas?
Danke für die Info.
Im logfile sehe ich gar nichts was auch nur annähernd mit "weekprofile" zu tun hat!
Zitat von: stgeran am 07 November 2016, 07:49:59
Nur um sicher zu gehen. Wäre das richtig?
attr weekprofile verbose 5
Wenn es bei dir genauso heißt wie das Modul. Also define weekprofile weekprofile. Dann ja.
Zitat von: JoeALLb am 07 November 2016, 16:58:02
Hallo,
ich nutze das Modul und bräuchte einen Event zum Aktualisieren von Userreadings, der immer trifft, wenn ich eine Einstellung geändert habe.
Aktuell werden Userreadings nur aktualisiert, wenn sich "profile_count" ändert. Ich muss also immer ein neues Profile hinzufügen oder eines löschen.
Übersehe ich da etwas?
Danke für die Info.
Was meinst du mit Userreadings?
profile_count ist kein Userreading!
Es gibt aktuell kein Event für irgendeine Änderung, sondern eben nur wenn sich das Reading profile_count ändert.
Ich könnte sicherlich ein Event generieren, wenn Daten gespeichert werden. Das hilft denke ich aber nicht, oder?
Das Event soll doch nur erzeugt werden, wenn sich tatsächlich was an den Profldaten ändert.
Dazu muss ich mir aber erst noch Gedanken machen.
Zitat von: Risiko am 08 November 2016, 20:05:22
Es gibt aktuell kein Event für irgendeine Änderung, sondern eben nur wenn sich das Reading profile_count ändert.
Ich könnte sicherlich ein Event generieren, wenn Daten gespeichert werden. Das hilft denke ich aber nicht, oder?
Doch, genau das würde mir sehr helfen!!
Ich generiere aktuell über ein Userreading eine Datei, um Homematik-Devices über das hmindo-Modul mit seinen Templates zu versorgen.
Klappt ganz gut uns passt wunderbar zusammen, lediglich eben dieses Event fehlt mir! Ich könnte aktuell auch drauf verzichten, dass es nur dann feuert, wenn tatsächlich etwas geändert wurde.
Meinetwegen könnte es bei jedem klick auf speichern feuern!!
Ok. Ich habe zwei events eingebaut.
PROFILE_TRANSFERED - wenn ein Profil zu einem Gerät gesendet wurde
PROFILES_SAVED - wenn Profile in der Konfigurationsdatei gespeichert wurden
Viel Spaß beim Testen.
Hallo Risiko,
Danke! Das Event sehe ich schön im Eventmonitor,
jedoch ein simples
attr device userReadings tmp {return "1"}
feuert nicht! es wird nach wie vor nur aktualisiert, wenn sich profile_count ändert...
Sorry verstehe auch nicht, was du mit dem userreading möchtest. "Feuern" wird das auch nicht, es wird ja nicht verändert. Du kannst doch jetzt mit einem notify auf das Event reagieren und hast alle Möglichkeiten.
Risiko
Bei mir funktioniert das Modul nicht richtig. Ich kann kaum Profile erstellen, weil nichts davon gespeichert wird.
Profil erstellen ,kopieren clonen oder dublizieren geht alles nicht vernünftig. Ich will mich auch nicht ewig mit den Weekprofielen beschäftigen und herumschlagen.
Schade
Hallo hermann258,
ohne weitere\nützliche Informationen kann ich dir leider nicht helfen.
hermann258 hat das gleiche Problem wie ich! Mal geht ein Übertrag von einem Tag auf einen anderen und mal nicht. Man ändert einen Tag und speichert und alles ist beim alten. Wenn ich es gefühlt 10 mal mache KANN ich Glück haben und es ist gespeichert. Ich habe auch schon abgewartet ob sich nach dem Speichern etwas tut, manchmal ja, manchmal nein. Seltsamer Effekt: Ändern von z.B. Montag, speichern für alle Tage und Dienstag, Donnerstag, Samstag und Sonntag werden gespeichert. Mittwoch und Freitag jedoch nicht. Das raff ich nicht mehr. Ich versuche mal mit dem verbose 5 und den neuen "Eventanzeigen" eine Aktion auszulösen und dann mal im log sehen, was sich tut.
Zitat von: Risiko am 12 November 2016, 18:56:26
... Du kannst doch jetzt mit einem notify auf das Event reagieren und hast alle Möglichkeiten.
Das notify löst eben NIE aus, egal ob ich es als
define Wochenplan.Notify notify Wochenplan:PROFILES_SAVED.* set x onoder als
define Wochenplan.Notify notify Wochenplan.* set x ondefiniere..
Logfile
2016.11.14 17:06:06 4: Wohnzimmer(getDeviceType): WT_WZ is type MAX
2016.11.14 17:06:06 4: Wohnzimmer(sendDevProfile): set WT_WZ weekProfile Mon 18.0,09:00,22.0,15:00,22.5,23:55,18.0
2016.11.14 17:06:06 5: Wohnzimmer(Notify): WT_WZ, weekProfile
2016.11.14 17:06:06 4: Wohnzimmer(Notify): reread master profile from WT_WZ
und Bild
Ich frage mich, wo die verdammte Änderung bleibt die ich im log sehe.
So geht das Stück für Stück. Ändern, Speichern, NICHTS
Was mir beim Speichern der Zeiten aufgefallen ist, ich sehe kurz die Speicherung und dann ist alles weg.
Ist es richtig das die Daten im Ordner Log gespeichert werden?
Zitat von: stgeran am 14 November 2016, 17:09:24
Logfile
2016.11.14 17:06:06 4: Wohnzimmer(getDeviceType): WT_WZ is type MAX
2016.11.14 17:06:06 4: Wohnzimmer(sendDevProfile): set WT_WZ weekProfile Mon 18.0,09:00,22.0,15:00,22.5,23:55,18.0
2016.11.14 17:06:06 5: Wohnzimmer(Notify): WT_WZ, weekProfile
2016.11.14 17:06:06 4: Wohnzimmer(Notify): reread master profile from WT_WZ
und Bild
Ich frage mich, wo die verdammte Änderung bleibt die ich im log sehe.
So geht das Stück für Stück. Ändern, Speichern, NICHTS
Also es wird nur der Montag aktualisiert. Die anderen Tage scheinen keine Änderung zu haben. D.h. die Readings (z.B. weekprofile-0-Sat-temp) vom Device "WT_WZ" sind entsprechend gesetzt.
Noch eine Anmerkung:
Das master-Profil wird nicht vom Modul weekprofile separat gespeichert! Es holt nur die Informationen vom assoziiertem Device.
Wenn das master-Profil gespeichert wird, werden die Daten gleich zum assoziiertem Device gesendet. Entsprechend der Credits kann es etwas dauern, bis die Änderungen wirksam werden! Auf jedenfall bekommt weekprofile mit, wenn sich die Profildaten im assoziiertem Device dann ändern!
Zitat von: hermann258 am 14 November 2016, 17:23:51
Was mir beim Speichern der Zeiten aufgefallen ist, ich sehe kurz die Speicherung und dann ist alles weg.
Ist es richtig das die Daten im Ordner Log gespeichert werden?
Ja die Daten werden im Log-Ordner gespeichert. Siehe aber auch vorherigen Post.
Zitat von: JoeALLb am 14 November 2016, 16:09:26
Das notify löst eben NIE aus, egal ob ich es als
define Wochenplan.Notify notify Wochenplan:PROFILES_SAVED.* set x on
oder als
define Wochenplan.Notify notify Wochenplan.* set x on
definiere..
Ok. Ich schaue es mir bei Gelegenheit mal an. Wird aber wahrscheinlich die Woche nichts mehr.
Hallo,
ich würde gerne die Modus "off" und "on" auch zeitlich programmieren und habe daher die Temperaturliste erweitert:
547 547 //temp
548 548 html += "<td><select name=\"TEMP\" size=\"1\" onchange=\"FW_weekprofileTemp_chached(this)\">";
549 - for (var k=5; k <= 30; k+=.5)
549 + for (var k=4.5; k <= 30.5; k+=.5)
550 550 {
551 551 var selected = (k == temps[i]) ? "selected " : "";
552 - html += "<option "+selected+"value=\""+k.toFixed(1)+"\">"+k.toFixed(1)+"</option>";
553 - }
552 + if (k == 4.5)
553 + html += "<option "+selected+"value=\"off\">off</option>";
554 + else if (k == 30.5)
555 + html += "<option "+selected+"value=\"on\">on</option>";
556 + else
557 + html += "<option "+selected+"value=\""+k.toFixed(1)+"\">"+k.toFixed(1)+"</option>";
558 + }
Leider kann ich nicht beurteilen in wiefern das auch mit HomeMatic-Thermostaten funktioniert. Eventuell kann könnte man hier noch eine Unterscheidung im Script machen?
Gruß
Hulzer
Zitat von: Risiko am 15 November 2016, 20:21:14
Ok. Ich schaue es mir bei Gelegenheit mal an. Wird aber wahrscheinlich die Woche nichts mehr.
Hm, habs gerade nochmal mit einem DoIF versucht, damit klappts.. hab den Fehler aber noch nicht gefunden.. Sorry, sollte es eine Falschmeldung sein!
Zitat von: hulzer am 16 November 2016, 09:30:22
Hallo,
ich würde gerne die Modus "off" und "on" auch zeitlich programmieren und habe daher die Temperaturliste erweitert:
OK. Könntest du das als Patch anhängen (Datei)?
Wieso bei 4.5 und 30.5°C ?
Zitat von: hulzer am 16 November 2016, 09:30:22
Leider kann ich nicht beurteilen in wiefern das auch mit HomeMatic-Thermostaten funktioniert. Eventuell kann könnte man hier noch eine Unterscheidung im Script machen?
Es wäre gut, wenn das jemand mal beurteilen könnte, der HomeMatic im Einsatz hat!!!
Zitat von: JoeALLb am 16 November 2016, 16:59:17
Hm, habs gerade nochmal mit einem DoIF versucht, damit klappts.. hab den Fehler aber noch nicht gefunden.. Sorry, sollte es eine Falschmeldung sein!
Also, ich kann keinen Fehler finden. Bei mir funktionieren die notfies.
z.B.
define NTF.saveweekprofile notify .*PROFILES_SAVED.* {Log3 $NAME, 1, "$NAME $EVENT";;}
Zitat von: Risiko am 17 November 2016, 20:10:54
OK. Könntest du das als Patch anhängen (Datei)?
Wieso bei 4.5 und 30.5°C ?
Den Patch habe ich angehängt.
Bei MAX bedeutet 4.5°C = off und 30.5°C = on (Ventilöffnung bis maxValveSetting, also i.d.R. 100%).
Zitat von: Risiko am 25 Januar 2016, 18:28:22
Was meinst du bei "Schaltakturen von HomeMatic"??
Zu den DECT200 Thermostaten von AVM - unterstützt das FHEM-Modul denn Wochenprofile? Konnte in den CommandRef (FBDECT?) nichts dahingehend finden.
Ich verwende Aktoren von Homematic um Garagentor, Alarmsirene usw. zu steuern und die AVM DECT 200 für die Steckdosen.
Kann das Modul Weekprofile mittlerweile auch diese Aktoren verwalten?
Ich habe mir ein Script geschrieben, das die Konfigurationsdatei für Homematic Thermostate erstellt und dann ganz normal über
die hm-module verwaltet und verteilt werden können. Mir ist die Verwaltung über das HM-Tool lieber und es läuft bei mir stabiler, als das direkte Senden der Werte an ein Device.
Am Schönsten wäre es natürlich, wenn dieses Script in das Modul direkt eingebunde werden würde, im Moment behelfe ich mir damit über ein notify.
Das Notify schreibt praktisch be jeder Änderung an einem Wochenprofil die ganze Template-Datei.
@Risiko: Wäre das denkbar, so etwas einzubauen? Ich denke dabei an 2 Attribute:
1. hmTemplatefile #speichert den Pfad zur Datei
2. hmWriteTemplate # oder ähnlich, aktiviert das Script zum Schreiben der Datei beim klicken auf "Speichern" in einem Wochenprofil.
Wenn soetwas möglich ist, kann ich mein Script (dessen Stil jedoch nicht allzu hübsch ist, das auch nicht allzu komplizier ist), gerne zur Verfügung stellen.
Zitat von: hulzer am 20 November 2016, 15:46:26
Den Patch habe ich angehängt.
Bei MAX bedeutet 4.5°C = off und 30.5°C = on (Ventilöffnung bis maxValveSetting, also i.d.R. 100%).
Also der patch\diff ist falsch herum. Habe es aber trotzdem mal zum Test eingebaut.
Es wird dann on\off aber in das Profil geschrieben und nicht 4.5 bzw 30.5. Somit würde bei Homematic on\off auch an das Device gesendet werden.
Ich habe in der Doku zu HM aber auf die Schnelle erstmal nix dazu gefunden. Daher würde ich es so erstmal noch nicht einbauen wollen. Sehe schon die Fehlermeldungen ;)
Ich mach mir dazu nochmal Gedanke. Evtl. kann man es über ein Attribut im Modul aktivieren. Mal schauen.
Gibt es hier kein HM-User, der mal was dazu sagen könnte ?
Zitat von: JoeALLb am 21 November 2016, 09:44:20
Ich habe mir ein Script geschrieben, das die Konfigurationsdatei für Homematic Thermostate erstellt und dann ganz normal über
die hm-module verwaltet und verteilt werden können. Mir ist die Verwaltung über das HM-Tool lieber und es läuft bei mir stabiler, als das direkte Senden der Werte an ein Device.
Am Schönsten wäre es natürlich, wenn dieses Script in das Modul direkt eingebunde werden würde, im Moment behelfe ich mir damit über ein notify.
Das Notify schreibt praktisch be jeder Änderung an einem Wochenprofil die ganze Template-Datei.
@Risiko: Wäre das denkbar, so etwas einzubauen? Ich denke dabei an 2 Attribute:
1. hmTemplatefile #speichert den Pfad zur Datei
2. hmWriteTemplate # oder ähnlich, aktiviert das Script zum Schreiben der Datei beim klicken auf "Speichern" in einem Wochenprofil.
Wenn soetwas möglich ist, kann ich mein Script (dessen Stil jedoch nicht allzu hübsch ist, das auch nicht allzu komplizier ist), gerne zur Verfügung stellen.
Hallo.
Prinzipiell wäre da schon was machbar. Gefällt mir persönlich leider nicht so richtig.
Leider sind meine Bemühungen, mit martinp876 eine Lösung direkt mit HMInfo kommunizieren zu können, im Sand verlaufen. Das wäre für mich der richtigere Weg.
Was ist denn so schlecht an der notify-Lösung, gerade seit dem es das Event 'PROFILES_SAVED' gibt. Somit ist dies doch eine flexible Lösung!?
Danke Risiko, mir wäre es integriert lieber, abe rnatürlich geht es auch so ohne Schwierigkeiten,
Anbei das Script, mit dem sich die Homematik-Templatefiles für HM-CC-RT-DN generieren lassen.
Sollte jemand einen schöneren Perl-Code daraus machen... immer her damit ;-)
Code für die 99_myUtils, hier bitte die Config-Datei anpassen: weekprofile-tempList.cfg
use JSON;
sub weekTemp($) {
my ($DEVI) = @_;
my $entit = fhem("get $DEVI profile_names");;
my $ret="\# bis Soll bis Soll bis Soll bis Soll\n";;
my @lines = split /,/, $entit;;
foreach my $Raum (@lines) {
my $tmp = fhem("get $DEVI profile_data $Raum");;
my $text = decode_json($tmp);;
Log 1, "Heizmodus $Raum $tmp";
$ret.="entities:".$Raum."\n".
jpars($text,'Mon').jpars($text,'Tue').jpars($text,'Wed').jpars($text,'Thu').jpars($text,'Fri').jpars($text,'Sat').jpars($text,'Sun');;
}
open IMGFILE, '>'.'/opt/fhem/FHEM/weekprofile-tempList.cfg';;
print IMGFILE $ret;;
close IMGFILE;;
return 0
}
sub jpars(%){
my ($text,$Day) = @_;
my $ret="tempList".$Day.">".
$text->{$Day}{'time'}[0]." ".$text->{$Day}{'temp'}[0]." ".
$text->{$Day}{'time'}[1]." ".$text->{$Day}{'temp'}[1]." ".
$text->{$Day}{'time'}[2]." ".$text->{$Day}{'temp'}[2]." ".
$text->{$Day}{'time'}[3]." ".$text->{$Day}{'temp'}[3]." ".
$text->{$Day}{'time'}[4]." ".$text->{$Day}{'temp'}[4]." ".
$text->{$Day}{'time'}[5]." ".$text->{$Day}{'temp'}[5]." ".
$text->{$Day}{'time'}[6]." ".$text->{$Day}{'temp'}[6]." ".
$text->{$Day}{'time'}[7]." ".$text->{$Day}{'temp'}[7]."\n";;
return $ret;
}
Das Doif, das das Template generiert: (natürlich auch als notify möglich)
define Heizmodus DOIF ([HeizungWochenplan:"PROFILES_SAVED"])\
({weekTemp('HeizungWochenplan')})\
## Zeile zum Aktualisieren der Einträge im HM-Device\
(attr hm configTempFile FHEM/weekprofile-tempList.cfg)
Jede Änderung im Wochenprofil wird damit automatisch in die Datei geschrieben und kann mit
set hm tempList verify
kontrolliert bzw mit
set hm tempList restore
aktualisiert werden.
Das lässt sich dann auch schön in eine RG bringen um dort das Profil auszuwählen.
Zitat von: Risiko am 21 November 2016, 22:38:59
Also der patch\diff ist falsch herum. Habe es aber trotzdem mal zum Test eingebaut.
Es wird dann on\off aber in das Profil geschrieben und nicht 4.5 bzw 30.5.
Hallo Risiko,
danke, es funktioniert auch wenn man 4.5 bzw. 30.5 ins das Profil schreibt, wäre eventuell auch sauberer.
Allerdings ist mir noch aufgefallen, dass bei Kopieren von Profilen zu anderen Devices ein "Invalid temperature" vom 10_MAX gemeldet wird. Grund ist, dass vor dem send_to_device das Profil wieder ausgelesen wird und dort die beiden Werte nicht wieder modifiziert werden.
Ich habe einen Patch angehängt.
Gruß
Hulzer
Ok. Sehe es mir nach meinem Urlaub mal an.
Wie kopiere ich das Topic "default" in ein Wintertopic?
Habe keine Masterdevices definiert, und arbeitete bisher mit useTopics=0.
Nun möchte ich gerne mit den Topics spielen, und wollte dahei ein neues anlegen.
set xx copy_profile default Winter
--> Error unknown profile default
Was hab ich da falsch verstanden?
Also wenn useTopics=0 ist, gibt es keine Topics.
Ansonsten:
set xx copy_profile default:default Winter:test
Kopiert das Default profile aus Topic default nach Topic Winter mit namen test
Also für für Quelle und Ziel immer topicname:profilname angeben.
Wenn useTopics=0 gesetzt ist, dann kann man den topicnamen weglassen.
Hoffe das hilft dir. ;)
Zitat von: Risiko am 20 Dezember 2016, 20:46:05
Also wenn useTopics=0 ist, gibt es keine Topics.
useTopics hatte ich zuerst auf 0, nun ist es 1.
Wenn ich
set xx copy_profile default:default Winter:testeingebe, erhalte ich dennoch:
Error unknown profile default und genau das verstehe ich eben nicht....
Edit1: Sorry, ziehe zurück:
Es heißt natürlich
set xx copy_profile default:Bad Winter:Bad... alles ok, sorry!!
Hallo Risiko,
besten Dank für das schöne Modul. Ich bin umgestiegen da die Heizpläne schöne online im Browser editiert werden können. Ich habe dazu Fragen bzw. eine Bitte um Unterstützung.
Mein Setup ... mehrere HM-Thermostate. Ich sende die Wochenpläne an jedes Thermostat einzeln. Ich habe zwei Dinge die ich gerne hätte bzw. wissen möchte ob es irgendwie geht. Ich sende mit "set wp_wohnzimmer send_to_device Wohnzimmer_Urlaub" den Wochenplan "Urlaub" an den Heizkörper im Wohnzimmer.
1) Ich würde gerne in einem Reading oder im state sehen welches weekprofile gerade aktiv ist oder welches zuletzt mit "set" gesetzt wurde.
2) Zusätzlich wäre es gut, wenn im Widget das gesetzte weekprofile angezeigt wird anstatt "master". Mir wäre schon geholfen, wenn ich per Befehl sagen könnte, welches weekprofile im Widget angezeigt wird. Ich setze das sowieso schon per "set", ein weiterer Befehl wäre kein Problem.
Ich habe mehrere Bedingungen die meine weekprofile an die unterschiedlichen Heizkörper sendet. Zum Prüfen, welches aktuell im Heizkörper ist muss ich aktuell im Heizkörper selber lesen.
Wenn es (noch) nicht möglich ist und ich eine Änderung testen soll kannst du mir das auch so zukommen lassen bevor du etwas eincheckst.
Danke schon mal!
Zitat von: kadettilac89 am 20 Dezember 2016, 21:28:03
1) Ich würde gerne in einem Reading oder im state sehen welches weekprofile gerade aktiv ist oder welches zuletzt mit "set" gesetzt wurde.
Was gerade aktiv ist, ist bei einem assoziierten Gerät immer das master Profil. Man kann ja das Profil vom assoziierten Device auch anderweitig verstellen und master passt sich an. Ich könnte mir nur ein Reading 'last_sended_profile' oder so vorstellen. Dieses muss aber nicht mehr aktiv sein, z.B. wenn man das Profil mit HMInfo verstellt hat.
Wenn du mit Topics arbeiten würdest, gibt es jetzt schon ein Reading 'active_topic'
Zitat von: kadettilac89 am 20 Dezember 2016, 21:28:03
2) Zusätzlich wäre es gut, wenn im Widget das gesetzte weekprofile angezeigt wird anstatt "master". Mir wäre schon geholfen, wenn ich per Befehl sagen könnte, welches weekprofile im Widget angezeigt wird. Ich setze das sowieso schon per "set", ein weiterer Befehl wäre kein Problem.
Siehe auch Punkt 1. Du kannst natürlich auch andere Profile anlegen.
Zitat von: kadettilac89 am 20 Dezember 2016, 21:28:03
Wenn es (noch) nicht möglich ist und ich eine Änderung testen soll kannst du mir das auch so zukommen lassen bevor du etwas eincheckst.
Danke fürs Angebot. Dazu müssen wir aber erstmal eine Lösung haben\diskutieren.
Zitat von: hulzer am 06 Dezember 2016, 23:24:12
Hallo Risiko,
danke, es funktioniert auch wenn man 4.5 bzw. 30.5 ins das Profil schreibt, wäre eventuell auch sauberer.
Allerdings ist mir noch aufgefallen, dass bei Kopieren von Profilen zu anderen Devices ein "Invalid temperature" vom 10_MAX gemeldet wird. Grund ist, dass vor dem send_to_device das Profil wieder ausgelesen wird und dort die beiden Werte nicht wieder modifiziert werden.
Ich habe einen Patch angehängt.
Gruß
Hulzer
Hallo. Ich komme erst nächstes Jahr dazu. Würde das Ganze gern optional einbauen. Weiter sollte man die Temperaturen für on,off über Attribute statt fest im Code verstellen können.
Hallo Hulzer,
anbei eine Version, wo mann die on und off Temperatur mittels der Attribute tempON und tempOFF vergeben kann.
Sind die Attribute nicht gesetzt, gibt es kein on/off.
Könntest du das bitte mal testen, bevor ich die Version einchecke.
Danke
Hallo, ich versuche gerade, das Modul weekprofile mit verschiedenen MAX Geräten zum laufen zu kriegen.
Die Wochenpläne werden mir auch angezeigt und ich kann die auch ändern, aber nach dem speichern
ist alles wieder auf Default. Was mache ich falsch?
Edit: habe rausgefunden das es sich nur beim Masterplan so verhält. Wenn ich ein neues Profil anlege, scheint es zu gehen. Ist das so
gewollt? Kann ich den Masterplan nicht anpassen?
Edit: Ich habe mir jetzt mal ein eigenes Profil angelegt und nach meinen Bedürfnissen eingestellt. Es ist mehrfach während des Einstellens passiert,
dass die Werte plötzlich überschrieben wurden. Dann habe ich nach jedem Tag gespeichert und dann den nächsten Tag editiert.
Als ich fertig war, war alles nach mehrfachem Aktualisieren der Seite noch so wie ich es eingestellt habe. Dann habe ich an das Device gesendet.
(Anbei bemerkt sind die Credits sofort ausgegangen) - danach war wieder meine ganze Konfiguration durcheinander.
Was ist denn da los? Was mache ich falsch?
Die Definition sieht so aus für 4 Wochenpläne:
#
# -------------------
# - Wochenprogramme -
# -------------------
#
define EG_BAD weekprofile MAX_0b1c72
attr EG_BAD room EG Temperaturen
#
define EG_DANIEL weekprofile MAX_0ba1f1
attr EG_DANIEL room EG Temperaturen
#
define EG_ALEXANDRA weekprofile MAX_1270ec
attr EG_ALEXANDRA room EG Temperaturen
define OG_WOHNZIMMER weekprofile MAX_0a07e9
attr OG_WOHNZIMMER room OG Temperaturen
Weiß jemand Rat?
Hi,
im heutigen Update war ja eine neue Version von der Datei fhemweb_weekprofile.js.
Leider erhalte ich im FHEMWEB immer noch folgende Fehlermeldung:
fhemweb_weekprofile.js line 6: TypeError: $(...).tooltip is not a function
wenn ich folgende Zeilen aus der Datei lösche funzt es ohne Fehlermeldung.
//for tooltip
$(document).ready(function(){
$('[data-toggle="tooltip"]').tooltip();
language = window.navigator.userLanguage || window.navigator.language;
});
evtl. gibt's da ja eine andere Lösung?
Aberweiß ich nicht ob das löschen der Zeilen was ausmacht!
Hallo punker,
ich habe keine neue Version seit Monaten eingestellt.
Was steht denn in der 1. Zeile für eine Version?
Ja, stimmt, ist seltsam weil die Version schon älter ist:
// $Id: fhemweb_weekprofile.js 12477 2016-10-31 12:49:30Z risiko79 $
aber wurde vom FHEM-update letzte Woche in den Restore-Ordner verschoben!
Deshalb dachte ich das wär ein Update.
Hallo Heimweh,
die Besonderheiten mit dem Master-Profil, Credits, etc. habe ich hier im Thread schon mehrfach erklärt. Bitte selbst mal nachlesen.
Da Userreadings in diesem Modul enabled sind, wäre es schön, wenn man diese auch nutzen könnte...
Bei folgendem Code sollte nach einem Speichervorgang ein Reading mit Name "tmp" und
dem Wert "testOK" angelegt werden. Tut es aber leider nicht...
attr weekProfile.Home userReadings tmp {return "testOK"}
Hat jemand eine Idee, wie man das korrigieren kann? :D?
Hallo Risko,
danke. Ich habe mir den kompletten Thread nun schon zwei mal durchgelesen. Vor ein paar Tagen, nachdem ich in kleinen Schritten jede Änderung im Masterprofil gespeichert hatte, hat es geklappt.
D.h. es ist so geblieben und wurde offensichtlich auch gespeichert. In der Zwischenzeit hab ich mal ein FHEM update gemacht. Am selben Tag habe ich ein Programm mit andFHEM geändert und
heute stelle ich fest, das alle Programme wieder weg sind und durchgehend auf 18° stehen. Die Thermostate allerdings haben noch die Programme gespeichert.
Kannst Du mir nicht einen Hinweis geben? Ich verzweifle noch daran .... Danke
Zitat von: JoeALLb am 17 Januar 2017, 08:49:40
Da Userreadings in diesem Modul enabled sind, wäre es schön, wenn man diese auch nutzen könnte...
Bei folgendem Code sollte nach einem Speichervorgang ein Reading mit Name "tmp" und
dem Wert "testOK" angelegt werden. Tut es aber leider nicht...
attr weekProfile.Home userReadings tmp {return "testOK"}
Hat jemand eine Idee, wie man das korrigieren kann? :D?
Funktioniert es in anderen Modulen? Z. B. Dummy? userReadings ist global und nicht auf weekprofile beschränkt. Wenn "Fehler" auch in anderen Modulen --> Post in entsprechendes Forum / Topic. FHEM an sich aktuell? Wenn nicht mach mal ein Update.
Zitat von: kadettilac89 am 17 Januar 2017, 16:24:23
Funktioniert es in anderen Modulen? Z. B. Dummy? userReadings ist global und nicht auf weekprofile beschränkt. Wenn "Fehler" auch in anderen Modulen --> Post in entsprechendes Forum / Topic. FHEM an sich aktuell? Wenn nicht mach mal ein Update.
ja, in anderen Modulen funktioniert es, auch in dummy!!
Man kann es auch innerhalb eines Moduls deaktivieren, indem man eine Referenz nicht lädt.
Da es in diesem Modul aber geladen ist und auch praktisch wäre, würde ich mich freuen, wenn man es funktionsfähig bekommt. Vermutlich
ist das nicht viel, weil es eben ein allgemeindes Modul ist, aber leide rbin ich dazu viel zuwenig programmierer ;-)
Zitat von: JoeALLb am 17 Januar 2017, 16:34:04
ja, in anderen Modulen funktioniert es, auch in dummy!!
Man kann es auch innerhalb eines Moduls deaktivieren, indem man eine Referenz nicht lädt.
Da es in diesem Modul aber geladen ist und auch praktisch wäre, würde ich mich freuen, wenn man es funktionsfähig bekommt. Vermutlich
ist das nicht viel, weil es eben ein allgemeindes Modul ist, aber leide rbin ich dazu viel zuwenig programmierer ;-)
Ich glaub du hast ein Verständnisproblem. Es funktioniert, gerade nachgestellt. Userreadings werden berechnet wenn sich ein anderes Reading in weekprofile ändert. Ich habe ein Userreading eines anderen Devices genommen und zum test ein weiteres Weekprofile angelegt damit sich etwas in den anderen Readings ändert (count profiles) und ... voalá im reading tmp habe ich die Werte zu CPU. Siehe list unten.
Internals:
CFGFN ./config/Heating_DBLog.cfg
DEF Heizung_Schlafzimmer_Clima
NAME wp_schlafzimmer
NR 292
NTFY_ORDER 50-wp_schlafzimmer
STATE assigned
TYPE weekprofile
Masterdev:
NAME Heizung_Schlafzimmer_Clima
TYPE CUL_HM
PROFILES:
HASH(0x2065da0)
HASH(0x205c260)
HASH(0x205ed98)
HASH(0x2065b90)
HASH(0x206a808)
HASH(0x2c57688)
Readings:
2017-01-17 18:22:12 profile_count 6
2017-01-10 19:18:44 state assigned
2017-01-17 18:22:12 tmp 0.72 0.00 0.73 98.36 0.15 0.00 0.04 1.64
SNDDEVLIST:
HASH(0x2c8f048)
HASH(0x3763648)
HASH(0x2d96910)
TOPICS:
default
Attributes:
group Wochenprogramme
room HomeMatic
userReadings tmp {CPU_All(ReadingsVal("sysmon","stat_cpu_percent",0))}
Du hast recht!
Was ich bräuchte ist, dass ich userReadings anstoßen kann, wenn das event "PROFILES_SAVED" ausgelöst wird....
Nun ja, der Weg über ein Notify bleibt mir ja, aber das andere wäre eben so viel praktischer ;-)
Zitat von: JoeALLb am 17 Januar 2017, 19:11:57
Du hast recht!
Was ich bräuchte ist, dass ich userReadings anstoßen kann, wenn das event "PROFILES_SAVED" ausgelöst wird....
Nun ja, der Weg über ein Notify bleibt mir ja, aber das andere wäre eben so viel praktischer ;-)
Du könntest den Autor des Moduls (Risiko) fragen ob er in Sub "weekprofile_writeProfilesToFile" ein State wie saved oder so setzt. Ich glaube das hätte keine funktionelle Auswirkung. Alternativ ggf. ein weiteres Reading das mit der letzten Aktion (erfolgreich_gespeichert, fehler_beim_schreiben, profile_assigned,...). Dann hättest das event dass userReadings setzen würde.
In der Hilfe steht dass ...
Events:
Currently the following event will be created:
PROFILE_TRANSFERED: if a profile or a part of a profile (changes) is send to a device
PROFILES_SAVED: the profile are stored in the config file (also if there are no changes)
--> Vielleicht kann man genau dieses Event auch in State als Text schreiben. Wäre durchgängig und dein Problem wäre gelöst.
Zitat von: Heimweh am 17 Januar 2017, 13:51:09
Kannst Du mir nicht einen Hinweis geben? Ich verzweifle noch daran .... Danke
Also das master-Profil wird nicht im Modul weekprofile gespeichert! Sondern es sollt immer dem Profil des assoziieren Gerätes entsprechen.
Was zeigen denn die Readings (weekprofile-0-Sat-...., etc.) des assoziieren MAX-Thermostats? Wenn du das master-Profil änderst, wird das geänderte Profil
sofort an des Thermostat übertragen.
Je nach Credits dauert es dann, bis das neue Profil vollständig auf dem Thermostat übertragen wurde. Zwischenzeitlich ändert sich z.B. nur ein Tag (z.B. das Reading weekprofile-0-Sat...) und weekprofile bekommt das mit und ließt das master-Profil neu vom assoziieren Thermostat aus. Dadurch kommt es einem so vor, als wenn das soeben erstellte Profil wieder weg ist!. Man muss eben warten, bis das Profil vollständig übertragen wurde. Wenn du das Profil im Thermostat anderweitig z.B. mittels andFHEM änderst, dann sollte sich das master-Profil entsprechend mit ändern.
So jetzt hab ich es nochmal erklärt ;)
Danke für die Erklärung. So hatte ich es auch gedacht. Die Readings der Geräte haben immer noch das von mir erstellte Wochenprogramm. Das Weekprofile Widget hat nur noch ein Programm namens "default". Ein Master Profil gibt es nicht mehr. Das default Profil hat rund um die Uhr 18 Grad. Wenn ich jetzt manuell die Temperatur in FHEM ändere, wird sie sofort übertragen, der CUNO arbeitet also....
Gesendet von meinem SM-G925F mit Tapatalk
Ohh. Da schein die Assoziation verloren gegangen oder gar nicht existiert zu haben!
Steht was Verdächtiges im Log?
Hallo Risiko,
ich muss mich entschuldigen. Ich habe die Thermostate umbenannt und nicht bedacht das die dadurch die Assoziation verloren gegangen ist. SORRY
Hallo @all
ich hatte hier https://forum.fhem.de/index.php/topic,46117.msg556586.html#msg556586
eine Testversion für On und Off eingestellt.
Wie sind die Erfahrungen?
Würde es gern einchecken.
@Risiko, darf ich Dich bitten, dir diesen Wunsch anzusehen?
Mit einem funktionierenden
userReadings könnte ich mein Script für die Verbindung zu HMinfo elegant vereinfachen!
Zitat von: kadettilac89 am 17 Januar 2017, 19:39:51
Du könntest den Autor des Moduls (Risiko) fragen ob er in Sub "weekprofile_writeProfilesToFile" ein State wie saved oder so setzt. Ich glaube das hätte keine funktionelle Auswirkung. Alternativ ggf. ein weiteres Reading das mit der letzten Aktion (erfolgreich_gespeichert, fehler_beim_schreiben, profile_assigned,...). Dann hättest das event dass userReadings setzen würde.
Zu der On/Off-Version kann ich nichts beitragen, da ich diese nicht getestet habe. Würde mich aber auch interessieren!
Danke!
Hallo Risiko,
habe die Testversion installiert und damit ein Profile erstellt und dieses dann an ein HT gesendet, klappt alles einwandfrei und funktioniert wie es soll.
Gruß
Klaus
Zitat von: JoeALLb am 25 Januar 2017, 11:39:05
@Risiko, darf ich Dich bitten, dir diesen Wunsch anzusehen?
So richtig gefällt mir das mit dem Setzen eines Readings auf z.B. saved nicht, da sich der Zustand nicht wieder auf z.B. auf unsaved ändern wird! Deswegen würde ich es nicht in den Code einbauen.
Du kannst dir das aber mit einem Notify selbst machen. z.B.
define NTF.savedweekprofile_to_myReading notify .*PROFILES_SAVED.* {fhem("setreading $NAME myReading saved");;}
Dadurch wird jedem weekprofile ein Reading 'myReading' erstellt\geupdatet wenn die Profile gespeichert wurden.
Ich verstehe leider nicht, warum man userReadings nicht an das Event 'PROFILES_SAVED' binden kann.
Zitat von: Risiko am 29 Januar 2017, 20:17:04
So richtig gefällt mir das mit dem Setzen eines Readings auf z.B. saved nicht, da sich der Zustand nicht wieder auf z.B. auf unsaved ändern wird! Deswegen würde ich es nicht in den Code einbauen.
aber die Readingzeit aktualisiert sich ja, somit besagt es korrekterweise "zuletzt gespeichert am".
Zitat von: Risiko am 29 Januar 2017, 20:17:04
Ich verstehe leider nicht, warum man userReadings nicht an das Event 'PROFILES_SAVED' binden kann.
weil userReadings even nur auf readings, und nicht auf Events reagiert ;-)
Hallo,
ich habe hier wohl ein Verständnisproblem mit dem weekprofile.
Ich habe Daten per JSON Liste an weekprofile übergeben:
{"Sun":{"time":["06:00","23:00"],"temp":["20.0","17.0"]},"Sat":{"time":["06:00","23:00"],"temp":["20.0","17.0"]},"Thu":{"time":["06:00","24:00"],"temp":["20.0","17.0"]},"Fri":{"time":["06:00","24:00"],"temp":["20.0","17.0"]},"Tue":{"time":["06:00","24:00"],"temp":["20.0","17.0"]},"Wed":{"time":["06:00","24:00"],"temp":["20.0","17.0"]},"Mon":{"time":["06:00","24:00"],"temp":["20.0","17.0"]}}
Erwartet habe ich eine tägliches Schalten um 6:00 Uhr auf 20.0 Grad und um 23:00 bzw. 24:00 Uhr auf 17.0, aber fhemweb zeigt mir das hier:
Mon 00:00-06:00 20.0 °C 06:00-24:00 17.0 °C
Tue 00:00-06:00 20.0 °C 06:00-24:00 17.0 °C
Wed 00:00-06:00 20.0 °C 06:00-24:00 17.0 °C
Thu 00:00-06:00 20.0 °C 06:00-24:00 17.0 °C
Fri 00:00-06:00 20.0 °C 06:00-24:00 17.0 °C
Sat 00:00-06:00 20.0 °C 06:00-23:00 17.0 °C
Sun 00:00-06:00 20.0 °C 06:00-23:00 17.0 °C
Also praktisch genau umgekehrt von dem was ich möchte, was mache ich da falsch?
vg
Marc-Antón
sorry, habe da mal eine Frage... ist es bei Euch möglich die Zeiten im Profil per Dropdown einzustellen oder ist das nur ein Wunschgedanke von mir? - kriege das nämlich nicht hin. (Habe HM-CC-RT-DN-Thermostate) Grüße Dirk
irgendwie geht widgetEditOnNewPage bei mir nicht mehr. Kann auch nicht sagen ob es an 98_weekprofile oder an fhemweb liegt. Auch nicht genau seit wann. Wenn ich
{weekprofile_editOnNewpage("<weekprofil>","default:master");;}
in die Befehlszeile eingebe geht die Seite auf. Kann das jemand bestätigen?
LG Tom_S
ok. alles klar. Habe nicht mitbekommen das csrfToken jetzt per default aktiv ist.
Daher der o.g. Fehler (cmd in der url)
LG
@risco
kannst du bitte in der fhemweb_weekprofile.js in Zeile 140 am Ende, also nach }
&fwcsrf='+$("body").attr('fwcsrf')+'
einfügen. Dann sollte es mit csrfToken wieder gehen. Ohne habe ich nicht getestet.
Tom_S
Hallo, Risiko
Mit das Attribute widgetWeekday kann man eine Liste von Wochentagen getrennt durch ',' welche im Widget angezeigt werden, eingeben. Beginnend bei Montag. z.B. attr name widgetWeekdays Montag,Dienstag,Mittwoch,Donnerstag,Freitag,Samstag,Sonntag.
In die Bearbeitungsmodus sieht man rechts Unten die Buttons "Speichern" und "Abbrechen".
Gibt es eine Möglichkeit um diese Aufschriften zu ändern? Beispielsweise: "Save" und "Cancel" oder "Opslaan" und "Afbreken"?
Gruß
Sibbe
hallo SibbeH
Du möchtest es sicher mit einem Attribut haben (mehrsprachig). Ob das allgemein eingebaut werden sollte weis ich nicht.
Du kannst aber deine "fhemweb_weekprofile.js" anpassen. Die Butten werden in 606 u 607 definiert. Da kannst du value einfach ändern. Wird aber vom Update wieder überschrieben.
LG
Hallo Tom_S
Danke für deinem Antwort. Tatsächlich möchte ich es gerne mit einem Attribut haben. In der gleichen Weise wie die Wochentage.
Ich werde noch eine Weile warten auf Risiko. Er war am letzten am 05 Februar auf das Forum.
Grüße
Sibbe
Hi,
vielleicht kann mir mal jemand einen Tipp geben:
Ich würde gern nur das Zahnrädchen in eine Readingsgroup einfügen, um damit zum eigentlichen Modul zu gelangen um dort die Einstellungen durchführen zu können.
Habe mir schon einen "Wolf" gesucht, aber ich komme nicht voran.
Hallo,
ich habe 2 MAX Thermostate für die ich insgesamt 3 Weekprofiles angelegt habe. Jeweils eins habe ich direkt dem Thermostat zugewiesen und mit einem dritten will ich allgemeine Urlaubs- und Sommer-Schaltungen vornehmen. Anders gesagt, wenn ich das Haus für eine ungeplante Zeit verlassen, schalte ich mit dem Standard-Profil Weekprofile alle Geräte gleichzeitig auf z.B. 17°C und wenn ich zurück komme, dann aktiviere ich mit den einzel-Profilen wieder den regulären Plan.
Jetzt würde ich aber speziell die Einzelprofile per andFhem ausführen. Aber außer die Anzahl der gespeicherten Profile, sehe ich in der App keine Möglichkeit, diese auszuwählen, zu verändern und dann an das Gerät zu senden. Was ist zu tun, damit ich die Funktionalität vom Webinterface in der App erhalte? Denn momentan muss ich dann doch auf das Webinterface zugreifen, um die Aktion ausführen zu können.
Hallo Risiko,
ich versuche gerade in das Weekprofile Widget für FTUI einen update Mechanismus einzubauen.
Dazu kann ich derzeit nur auf Readings triggern (der Trigger PROFILES_SAVED kommt leider nicht an).
Könntest du bei Änderung an Profildaten z.B. das Reading state auf modified setzen oder den profile_count aktualisieren so das ein event ausgelöst wird auf das ich reagieren kann?
Grüße
Klaus
Ich verstehe nicht ganz. Bei mir funktioniert das notify:
https://forum.fhem.de/index.php/topic,63549.msg605214.html#msg605214
Jede Änderung des Plans triggert meine Funktion DecodeWeekProfile()
Gruß
Ich hatte versucht, durch den Trigger PROFILES_SAVED, die Daten des widged_weekprofile in der Tablet UI aktualisieren.
Es kommen aber nur globale Trigger in der Tablet UI.
Bei Readings gibt es dieses Problem nicht. Daher würde es mir helfen, wenn beispielsweise das Reading state bei jedem Ändern eines Profils gesetzt wird.
Falls etwas gegen diese Änderung spricht dann wäre das halt Pech 8)
Zitat von: klausw am 26 März 2017, 13:00:50
Ich hatte versucht, durch den Trigger PROFILES_SAVED, die Daten des widged_weekprofile in der Tablet UI aktualisieren.
Es kommen aber nur globale Trigger in der Tablet UI.
Bei Readings gibt es dieses Problem nicht. Daher würde es mir helfen, wenn beispielsweise das Reading state bei jedem Ändern eines Profils gesetzt wird.
Falls etwas gegen diese Änderung spricht dann wäre das halt Pech 8)
Selbes Thema mit Lösung?
https://forum.fhem.de/index.php/topic,46117.msg572686.html#msg572686 (https://forum.fhem.de/index.php/topic,46117.msg572686.html#msg572686)
Hallo, ich bin erst vor ein paar Tagen von der alten "99_UtilsMaxProf.pm"
auf weekprofile umgestiegen.
Wie kann ich die alten, in den MAX Thermostaten abgelegten Profile, auslesen und abspeichern?
Ich möchte die ausgelesenen Profile dann gerne in das neue WeekProfile übernehmen. Geht das?
Ich habe 10 MAX Thermostate.
MFG. S.
Zitat von: kadettilac89 am 26 März 2017, 13:43:20
Selbes Thema mit Lösung?
https://forum.fhem.de/index.php/topic,46117.msg572686.html#msg572686 (https://forum.fhem.de/index.php/topic,46117.msg572686.html#msg572686)
Nicht wirklich, da es für ein Widget ohne zusätzliche Basteleien funktionieren sollte.
Es würde auch reichen wenn sich nur der Timestamp ändert.
Zitat von: klausw am 29 März 2017, 09:31:56
Nicht wirklich, da es für ein Widget ohne zusätzliche Basteleien funktionieren sollte.
Es würde auch reichen wenn sich nur der Timestamp ändert.
Ein Wunsch, den ich auch schon länger habe.....
Hallo.
Sorry, ich war längere Zeit dienstlich unterwegs.
Werde versuchen mir die Sachen zeitnah anzusehen.
Risiko
Hallo,
ich wollte jetzt mal mit dem Weekprofile in der Variante der Topics loslegen. Das grundsätzliche Anlegen ist ja auch kein Problem.
Ich habe nur eine Frage:
Gibt es eine Möglichkeit, ein bestehendes Wochenprofil eines Thermostats als Profil ablegen/kopieren zu lassen?
Sozusagen das Gegenteil von "restore_topic" :)
Ich habe ja jetzt momentan meine Wochenprofile in meinen 9 Devices schon drin, die ich gerne komplett als Basis für mein zukünftiges Winterprofil verwenden würde...
Danke schon mal...
EDIT: Ich sehe gerade, dass ein Stückchen weiter oben jemand diese Frage auch schon formuliert hatte. Sorry, dann hänge ich dort mit dran...
Grüße
Reinerlein
Hallo,
ich habe eine Lösung für mich gefunden.
Ich habe einfach temporär ein Weekprofile mit dem entsprechenden Thermostaten als Master definiert:
define temp weekprofile heizung_Wohnzimmer
Damit wird das Wochenprofile vom FHEM-Device gelesen. Anschließend kann man mit
get temp profile_data master
Dann nur noch im Ziel mit
set weekprofile profile_data Topic:Profil <JSONDATA_AUS_ZWISCHENABLAGE>
Danach das temporäre Device wieder löschen:
delete temp
Danach das gleiche wieder für das nächste Thermostat...
Da ich "nur" 10 Thermostate habe, war das ganze in ein paar Minuten erledigt. Da ich das nie wieder machen muss, war es für mich in Ordnung. Trotzdem wäre ein einfacherer Weg doch angenehmer, zumal der Code dafür ja schon vollständig vorhanden ist...
Danke für das Modul :)
Grüße
Reinerlein
Zitat von: Tom_S am 21 Februar 2017, 22:55:18
@risco
kannst du bitte in der fhemweb_weekprofile.js in Zeile 140 am Ende, also nach }
&fwcsrf='+$("body").attr('fwcsrf')+'
einfügen. Dann sollte es mit csrfToken wieder gehen. Ohne habe ich nicht getestet.
Tom_S
Danke.
Habe es so ähnlich eingebaut. Funktioniert jetzt mit und ohne csrfToken
Zitat von: SibbeH am 10 März 2017, 19:03:33
Hallo Tom_S
Danke für deinem Antwort. Tatsächlich möchte ich es gerne mit einem Attribut haben. In der gleichen Weise wie die Wochentage.
Ich werde noch eine Weile warten auf Risiko. Er war am letzten am 05 Februar auf das Forum.
Grüße
Sibbe
Hallo.
Ich habe es eingebaut, auch wenn meiner Meinung nach die Übersetzung ein zentrales Problem von FHEM ist. Eine generische Lösung z.B. in FHEMWEB wäre prinzipiell schöner.
Das Attribut heißt widgetTranslations.
Beispiel:
attr name widgetTranslations Abbrechen:Cancel,Speichern:Save
Zitat von: JoeALLb am 29 März 2017, 20:13:45
Ein Wunsch, den ich auch schon länger habe.....
Da es jetzt hier mehr als eine Anfrage zum update eins Readings beim Speichern gab, sollte ab morgen das Reading 'profile_count' immer triggern.
Zitat von: Reinerlein am 10 April 2017, 18:20:22
Gibt es eine Möglichkeit, ein bestehendes Wochenprofil eines Thermostats als Profil ablegen/kopieren zu lassen?
Ich verstehe leider nicht so richtig was gemeint ist, doch das kopieren geht doch mit dem Befehl 'send_to_device'.
Hier kann man auch Profile zwischen mehreren weekprofile Instanzen hin- und her senden.
Also wenn ich das richtig interpretiert habe wäre das für dein Beispiel so:
set temp send_to_device master weekprofile
set weekprofile copy_profile default:master newtopis:newprofile
Zitat von: Risiko am 12 April 2017, 23:45:11
Ich verstehe leider nicht so richtig was gemeint ist, doch das kopieren geht doch mit dem Befehl 'send_to_device'.
Gesucht wäre etwas wie "import_from_device", also das Übernehmen von schon am Gerät korrekt eingestellten Profilen
in das Modul. Ich habe auch 20 Heizungsaktoren verbaut, deren Einstellung ich nicht nochmal abtippen möchte, sondern in das Modul
"importieren". Dazu verwende ich imMoment den Workaround, den Reinerlein gepostet hat.
Zitat von: Risiko am 12 April 2017, 23:28:36
Da es jetzt hier mehr als eine Anfrage zum update eins Readings beim Speichern gab, sollte ab morgen das Reading 'profile_count' immer triggern.
Das Attribut "userReadings" wird damit immer noch nicht angetriggert, obwohl das Reading jetzt korrekt aktualisiert wird. Ist die Einbindung dieser Standardfunktion
eventuell nicht ganz korrekt?
Zitat von: JoeALLb am 13 April 2017, 09:26:36
Das Attribut "userReadings" wird damit immer noch nicht angetriggert, obwohl das Reading jetzt korrekt aktualisiert wird. Ist die Einbindung dieser Standardfunktion
eventuell nicht ganz korrekt?
Ich habe es eben getestet ... bei mir funktioniert es. Funktioniert bei dein UserReading in einem anderen Device, hast du ggf. einen Fehler in der Definition?
1 UserReading angelegt ... Wert aus einem Dimmer geholt --> funktioniert
2) Dimmer geändert
3) Weekprofile geändert, gespeichert
4) Profilecount wurde getriggered + UserReading wurde getriggered und neuer Wert aus dem Dimmer gesetzt
Readings:
2017-04-13 09:59:22 dimm 68
2017-04-13 09:59:22 profile_count 5
2017-04-13 09:45:29 state assigned
... dimm ist ein Test-userReading
Attributes:
userReadings dimm { ReadingsVal("Dimmer2","state",0);; }
habe auch geprüft ob Events geschrieben werden ... Alle erwarteten Events erzeugt
2017-04-13 09:58:57.150 dummy Dimmer2 68
2017-04-13 09:59:22.472 weekprofile wp_schlafzimmer PROFILES_SAVED
2017-04-13 09:59:22.483 weekprofile wp_schlafzimmer profile_count: 5
2017-04-13 09:59:22.483 weekprofile wp_schlafzimmer dimm: 68
Zitat von: kadettilac89 am 13 April 2017, 10:02:48
[...], hast du ggf. einen Fehler in der Definition?
Ok, ja, hatte einen Perl-Fehler völlig übersehen! Jetzt gehts :D !! Danke!!
Zitat von: Risiko am 12 April 2017, 23:28:36
Da es jetzt hier mehr als eine Anfrage zum update eins Readings beim Speichern gab, sollte ab morgen das Reading 'profile_count' immer triggern.
Funktioniert super, danke.
Dann werde ich das in die widget_weekprofile.js noch einbauen.
Zur Info: Hier meine Lösung für das Modul weekprofile und den Homematic_Templates für HMinfo, für Interessierte.
https://forum.fhem.de/index.php/topic,70494.msg619911.html#msg619911
Ich bekomme folgende Fehlermeldung und FHEM schmiert ab:
hash- or arrayref expected (not a simple scalar, use allow_nonref to allow this) at ./FHEM/98_weekprofile.pm line 508.
Direkt nach dem Anlegen der Definition.
Wie sieht denn die Definition aus?
Ich sehe es mir nach meinem Urlaub an.
Ganz normal: define wt3 weekprofile HM_[...]
Wie kann ich ein weekprofile für 3 Geräte bauen ?
define weekprofile_heizung_bad weekprofile heizung_bad_Clima ....
mir leereichen oder Komma?
Habe in einem Raum 3 Geräte will aber kein Team daraus machen :)
Zitat von: Hauswart am 25 September 2017, 15:40:15
Ganz normal: define wt3 weekprofile HM_[...]
Ja aber das wichtigste vergessen. Was ist HM_...?
Ich kann den Fehler (mit perl 5.14.2 und 5.22.1) nicht nachstellen! Ist libjson-perl installiert?
Zitat von: ChrisW am 02 Oktober 2017, 19:41:49
Wie kann ich ein weekprofile für 3 Geräte bauen ?
define weekprofile_heizung_bad weekprofile heizung_bad_Clima ....
mir leereichen oder Komma?
Habe in einem Raum 3 Geräte will aber kein Team daraus machen :)
Hallöchen. Verstehe leider die Anforderung nicht. Wie meinst du das?
Hast du dir auch die Doku im wiki angesehen? https://wiki.fhem.de/wiki/Weekprofile
Zitat von: Risiko am 03 Oktober 2017, 13:49:50
Ja aber das wichtigste vergessen. Was ist HM_...?
Ich kann den Fehler (mit perl 5.14.2 und 5.22.1) nicht nachstellen! Ist libjson-perl installiert?
Wenn man HM_XXX_Clima/Climate verwendet geht es auch :)
Habe aber folgenden Fehler:
Zitat
2017.10.04 08:04:15 3: CUL_HM set HM_XXX_Clima tempListMon prep 06:30 17.0 08:30 21.0 17:00 17.0 22:00 21.0 24:00 17.0
2017.10.04 08:04:15 3: CUL_HM set HM_XXX_Clima tempListTue prep 06:30 17.0 08:30 21.0 17:00 17.0 22:00 21.0 24:00 17.0
2017.10.04 08:04:15 3: CUL_HM set HM_XXX_Clima tempListWed prep 06:30 17.0 08:30 21.0 17:00 17.0 22:00 21.0 24:00 17.0
2017.10.04 08:04:15 3: CUL_HM set HM_XXX_Clima tempListThu prep 06:30 17.0 08:30 21.0 17:00 17.0 22:00 21.0 24:00 17.0
2017.10.04 08:04:15 1: PERL WARNING: Use of uninitialized value $temps[0] in substitution (s///) at ./FHEM/98_weekprofile.pm line 154.
2017.10.04 08:04:15 3: CUL_HM set HM_XXX_Clima tempListFri exec 06:30 17.0 08:30 21.0 17:00 17.0 22:00 21.0 24:00 17.0
2017.10.04 08:06:23 3: CUL_HM set HM_XXX_Clima getConfig
Habe 3 Thermostate
heizung_bad_Clima
heizung_bad2_Clima
heizung_bad3_Clima
Die sollen einen Plan bekommen. Will Sie nicht als Team zusammenpacken.
Wie ist die Definition zum Hinzufügen in Fhem?
Ich würde das weekprofile ohne Maste-Gerät definieren, und dann folgendes nutzen:
set <name> send_to_device <profilname> [devices]
Siehe CommandRef.
ok eifach nur leerstelle getrennt hintereinenander ?
Zitat von: CommandREFsend_to_device
set <name> send_to_device <profilname> [devices]
Das Profil wird an ein oder mehrere Geräte übertragen. Wird kein Gerät angegeben, wird das 'Master-Gerät' verwendet. 'Devices' ist eine kommagetrennte Auflistung von Geräten
okay danke jedoch muss ich das jedes mal neu setzen :( Ändere ich also den Plan muss ich es Manuell wieder setzen :(
Zitat von: ChrisW am 04 Oktober 2017, 21:41:16
okay danke jedoch muss ich das jedes mal neu setzen :( Ändere ich also den Plan muss ich es Manuell wieder setzen :(
Das kannst Du auch automatisch machen wenn dein änderndes Device einen passenden Event auslöst.
Ich nutze beispielsweise das Modul "HMinfo" zum Verteilen der Wochenpläne, zum editieren der Zeitpläne jedoch dieses weekprofile hier.
(Wie das geht habe ich weiter vorne im Thread beschrieben).
Funktioniert tadellos, hängt aber ganz vom Einsatzzweck ab...
Zitat von: ChrisW am 04 Oktober 2017, 20:36:51
Habe 3 Thermostate
heizung_bad_Clima
heizung_bad2_Clima
heizung_bad3_Clima
Die sollen einen Plan bekommen. Will Sie nicht als Team zusammenpacken.
Wie ist die Definition zum Hinzufügen in Fhem?
Also weekprofile kann aktuell nur mit einem Device assoziiert sein (master).
Ich verstehe zwar nicht, was du mit "als Team zusammenpacken" meinst, aber wenn die drei Thermostate den gleichen Plan bekommen sollen, dann geht das mit Topics.
Dazu weekprofile ohne Device anlegen und den Thermostaten mittels userattr "weekprofile" die gleiche Topic vergeben.
Mit dem Befehl 'restore_topic" wird dann der gewählte Plan an alle Thermostate übertragen.
Zitat von: Hauswart am 04 Oktober 2017, 08:09:32
Wenn man HM_XXX_Clima/Climate verwendet geht es auch :)
Habe aber folgenden Fehler:
Ich sehe da kein Fehler, sondern nur eine Warnung ;). Die könnte man noch beseitigen. Muss ich mal schauen ....
Anbei eine Version mit Log (verbose auf 4)
Kurze Frage: Gibt es eine Möglichkeit, dass man bei den Temperaturen neben 5.0 °C auch noch "off" auswählen kann? Ich hatte das gerne für die Pläne meines Sommer-Topics.
Vielen Dank!
Geht doch mit den Attributen tempON bzw tempOFF !?
Hallo,
gibt es hier ne Anleitung wie ich das ganze installiere bzw . einrichte ?
Viele Gruesse
Markus
https://wiki.fhem.de/wiki/Weekprofile
Hahahah Du bist ja auch ein lustiger.
Im anderen Forum kennste das Ding nicht aber hier kennste ne Anleitung wie man das einrichtet.
Gruss
Da steht aber nur drinne wie man JSOn installiert aber nicht dieses Anzeige Modul
Zum einwandfreien Betrieb des Moduls wird JSON benötigt. Dieses kann z.B. über folgendes installiert werden
sudo apt-get install libjson-pp-perl
Kann jemand helfen
Wo in Herrgottsnamen list Du denn
define <name> weekprofile <device>
Steht da, Groß und Breit
Ich glaub du verstehts mich nicht.
Ich will nicht über define EG_Bad_WEEKPROFILE weekprofile EG_Bad_THERMOSTAT_Climate oder irgend eine Syntax Wochenpläne erstellen.
Ich will ueber das Modul mit KLicki Bunti Maus die Wochenpläne erstellen. Dazu muss ich das aber irgendwie installieren das steht in der Anleitung aber nicht drinne.
meinst du das hier
Das weekprofile-Modul ist standardmässig in einer aktuellen FHEM-Installation vorhanden/installiert, ansonsten "update" durchführen. Danach eben die Definition anlegen und dann kannst du Klicki Bunti Maus :)
Er brauch doch wirklich nur stur diesen Wikieintrag befolgen. Ich verstehe nicht was daran so schwer sein sein.
Ja ok das hat mir keiner gesagt das das Modul schon integriert ist. Konnte mir vorhin nicht beantwortet werden aber danke.
Einfach aus probieren. Man kann ja nichts kaputt machen.
Zitat von: CoolTux am 03 November 2017, 14:15:15
meinst du das hier
Ja das meine ich wo finde ich das in FHEM ? Kann ich nicht sehe .
Hast Du das Device bereits angelegt? Wenn ja dann sollte es sofort zu sehen sein.
Meinst Du mein Thermostat ? Ja das ist angelegt
Vergiss es. Du bist mir zuviel des guten.
Schönes Wochenende
Hallo appelwoin76,
ich weiß auch nicht, wie man dir noch helfen kann.
Mach doch einfach mal ein
define test weekprofile
Hallo zusammen,
ich bin sehr begeistert von dem Modul weekprofile. Das ist genau das, was ich gesucht habe.
Nun habe ich allerding ein paar Fragen, die ich mir durch die Forensuche und WIKI nicht beantworten konnte.
Zuerst, ist es überhaupt möglich weekprofile zu nutzen, wenn man die Homematic Heizkörpertermostate über eine CCU2 per HMCCUDEV oder HMCCUCHN eingebunden hat?
Ich habe beides ausprobiert und bekomme immer die Meldung "Error device type not supported".
Da ich im WIKI gelesen habe, dass direkt der Kanal _Climate angesprochen werden muss, habe ich auch mit HMCCUCHN direkt ein Device mit dem Channel 2 _Climate angelegt, allerdings funktioniert auch dies nicht :-(
Ich hab ein bißchen das Gefühl, dass es generell mit HMCCU Devices nicht funktioniert, vielleicht kann der Entwickler was dazu sagen.
Falls es wirklich nicht integriert sein sollte, wäre es natürlich mein größer Wunsch, diese Funktion zu implementieren ;-)
Ich denke, ich bin bestimmt nicht der Einzige, der seine Homematic Devices über eine CCU2 anspricht.
Hier noch meine definierten Devices:
Direkt der Climate Channel 2:
define wz_heizung_climate HMCCUCHN OEQ0844452:2 defaults
attr wz_heizung_climate IODev d_ccu
attr wz_heizung_climate room Homematic,Wohnzimmer
Das normale Heitzungsdevice:
define wz_heizung HMCCUDEV OEQ0844452
attr wz_heizung IODev d_ccu
attr wz_heizung cmdIcon Auto:sani_heating_automatic Manu:sani_heating_manual Boost:sani_heating_boost on:general_an off:general_aus
attr wz_heizung controldatapoint 4.SET_TEMPERATURE
attr wz_heizung eventMap /datapoint 4.MANU_MODE 20.0:Manu/datapoint 4.AUTO_MODE 1:Auto/datapoint 4.BOOST_MODE 1:Boost/datapoint 4.MANU_MODE 4.5:off/datapoint 4.MANU_MODE 30.5:on/
attr wz_heizung hmstatevals FAULT_REPORTING!1:valve_tight,2:range_too_large,3:range_too_small,4:communication_error,5:other_error,6:battery_low,7:valve_error_pos
attr wz_heizung room Homematic,Wohnzimmer,Homematic
attr wz_heizung statedatapoint 4.SET_TEMPERATURE
attr wz_heizung stripnumber 1
attr wz_heizung substexcl control
attr wz_heizung substitute CONTROL_MODE!0:AUTO,1:MANU,2:PARTY,3:BOOST;;SET_TEMPERATURE!#0-4.5:off,#30.5-40:on;;FAULT_REPORTING!0:no,1:valve_tight,2:range_too_large,3:range_too_small,4:communication_error,5:other_error,6:battery_low,7:valve:error_pos
attr wz_heizung webCmd control:Auto:Manu:Boost:on:off
attr wz_heizung widgetOverride control:slider,4.5,0.5,30.5,1
Schon mal vielen Dank für eure Unterstützung!
Gruß
Lars
Hallo Lars,
leider kann ich zu HM nicht viel sagen, da ich selbst kein HM habe.
Alles ist in Zusammenarbeit mit den HM-Usern entstanden. Denke, dass wir das in deinem Fall auch hin bekommen.
Das werden unter Umständen aber paar Iterationen werden.
Ich benötige ein Device, wo ich die Readings der Wochenpläne auslesen bzw. abfragen kann.
Zeige mir doch mal die Detailansicht (Typ, Readings, etc.) von "wz_heizung_climate" Vielleicht ist es auch nur eine Kleinigkeit.
Hallo Risiko,
erstmal vielen Dank für deine Unterstüzung!
Hier erstmal der Link zum Wiki Eintrag, das du nachvollziehen kannst wie ich meine Homematicgeräte eingebunden habe:
https://wiki.fhem.de/wiki/HMCCU (https://wiki.fhem.de/wiki/HMCCU)
https://wiki.fhem.de/wiki/HMCCUDEV (https://wiki.fhem.de/wiki/HMCCUDEV)
Dann noch der Wiki Eintrag zu meinem Heizkörperthermostat:
https://wiki.fhem.de/wiki/HM-CC-RT-DN_Funk-Heizk%C3%B6rperthermostat (https://wiki.fhem.de/wiki/HM-CC-RT-DN_Funk-Heizk%C3%B6rperthermostat)
So wie ich es verstehe wird der Channel (Kanal) 04 _Clima benutzt um Temperaturlisten bzw. Weekprofile zu übertragen.
Ich habe mein Device wz_heizung per HMCCUDEV eingebunden. Damit sollten alle Kanäle verfügbar sein.
Die Infos findest du in den Screenshots wz_heizung_internals, wz_heizung_readings und wz_heizung_attributes.
Zusätzlich habe ich zum testen nun von dem selben Device per HMCCUCHN nur den Kanal 4 eingebunden.
Die Infos zum Device im Screenshot wz_heizung_clima. Unterscheidet sich nicht großartig.
Falls ich sonst noch irgendwie unterstützen kann, meld dich einfach!
Vielen Dank und schönen Gruß
Lars
Hallo Risiko,
ein kleines Stück weiter bin ich selbst schon gekommen.
Es ist wohl per Standart ein ccureadingsfilter gesetzt, diesen habe ich nun auf .* gesetzt und nun sieht es Readingtechnisch schon viel umfangreicher aus.
0.AES_KEY 0 09.11.2017 14:45
0.CONFIG_PENDING false 09.11.2017 14:45
0.DEVICE_IN_BOOTLOADER false 09.11.2017 14:45
0.INHIBIT false 09.11.2017 14:45
0.LOWBAT false 09.11.2017 14:45
0.RSSI_DEVICE 191 09.11.2017 14:45
0.RSSI_PEER 160 09.11.2017 14:45
0.STICKY_UNREACH true 09.11.2017 14:45
0.UNREACH false 09.11.2017 14:45
0.UPDATE_PENDING false 09.11.2017 14:45
4.ACTUAL_TEMPERATURE 42848 10.11.2017 17:56
4.BATTERY_STATE 42738 10.11.2017 17:56
4.BOOST_STATE 0 10.11.2017 17:56
4.CONTROL_MODE AUTO 10.11.2017 17:56
4.FAULT_REPORTING no 10.11.2017 17:56
4.PARTY_START_DAY 1 10.11.2017 17:56
4.PARTY_START_MONTH 1 10.11.2017 17:56
4.PARTY_START_TIME 0 10.11.2017 17:56
4.PARTY_START_YEAR 0 10.11.2017 17:56
4.PARTY_STOP_DAY 1 10.11.2017 17:56
4.PARTY_STOP_MONTH 1 10.11.2017 17:56
4.PARTY_STOP_TIME 0 10.11.2017 17:56
4.PARTY_STOP_YEAR 0 10.11.2017 17:56
4.PARTY_TEMPERATURE 5.0 10.11.2017 17:56
4.SET_TEMPERATURE 21.0 10.11.2017 17:56
4.VALVE_STATE 15 10.11.2017 17:56
R-ADAPTIVE_REGULATION 2 10.11.2017 17:55
R-BACKLIGHT_ON_TIME 10 10.11.2017 17:55
R-BOOST_AFTER_WINDOW_OPEN 0 10.11.2017 17:55
R-BOOST_POSITION 80 10.11.2017 17:55
R-BOOST_TIME_PERIOD 1 10.11.2017 17:55
R-BURST_RX 1 10.11.2017 17:55
R-BUTTON_LOCK 0 10.11.2017 17:55
R-BUTTON_RESPONSE_WITHOUT_BACKLIGHT 0 10.11.2017 17:55
R-CYCLIC_INFO_MSG 1 10.11.2017 17:55
R-CYCLIC_INFO_MSG_DIS 0 10.11.2017 17:55
R-DAYLIGHT_SAVING_TIME 1 10.11.2017 17:55
R-DECALCIFICATION_TIME 660 10.11.2017 17:55
R-DECALCIFICATION_WEEKDAY 0 10.11.2017 17:55
R-DISPLAY_INFORMATION 0 10.11.2017 17:55
R-ENDTIME_FRIDAY_1 840 10.11.2017 17:55
R-ENDTIME_FRIDAY_10 1440 10.11.2017 17:55
R-ENDTIME_FRIDAY_11 1440 10.11.2017 17:55
R-ENDTIME_FRIDAY_12 1440 10.11.2017 17:55
R-ENDTIME_FRIDAY_13 1440 10.11.2017 17:55
R-ENDTIME_FRIDAY_2 1320 10.11.2017 17:55
R-ENDTIME_FRIDAY_3 1440 10.11.2017 17:55
R-ENDTIME_FRIDAY_4 1320 10.11.2017 17:55
R-ENDTIME_FRIDAY_5 1440 10.11.2017 17:55
R-ENDTIME_FRIDAY_6 1440 10.11.2017 17:55
R-ENDTIME_FRIDAY_7 1440 10.11.2017 17:55
R-ENDTIME_FRIDAY_8 1440 10.11.2017 17:55
R-ENDTIME_FRIDAY_9 1440 10.11.2017 17:55
R-ENDTIME_MONDAY_1 840 10.11.2017 17:55
R-ENDTIME_MONDAY_10 1440 10.11.2017 17:55
R-ENDTIME_MONDAY_11 1440 10.11.2017 17:55
R-ENDTIME_MONDAY_12 1440 10.11.2017 17:55
R-ENDTIME_MONDAY_13 1440 10.11.2017 17:55
R-ENDTIME_MONDAY_2 1320 10.11.2017 17:55
R-ENDTIME_MONDAY_3 1440 10.11.2017 17:55
R-ENDTIME_MONDAY_4 1320 10.11.2017 17:55
R-ENDTIME_MONDAY_5 1440 10.11.2017 17:55
R-ENDTIME_MONDAY_6 1440 10.11.2017 17:55
R-ENDTIME_MONDAY_7 1440 10.11.2017 17:55
R-ENDTIME_MONDAY_8 1440 10.11.2017 17:55
R-ENDTIME_MONDAY_9 1440 10.11.2017 17:55
R-ENDTIME_SATURDAY_1 540 10.11.2017 17:55
R-ENDTIME_SATURDAY_10 1440 10.11.2017 17:55
R-ENDTIME_SATURDAY_11 1440 10.11.2017 17:55
R-ENDTIME_SATURDAY_12 1440 10.11.2017 17:55
R-ENDTIME_SATURDAY_13 1440 10.11.2017 17:55
R-ENDTIME_SATURDAY_2 1380 10.11.2017 17:55
R-ENDTIME_SATURDAY_3 1440 10.11.2017 17:55
R-ENDTIME_SATURDAY_4 1440 10.11.2017 17:55
R-ENDTIME_SATURDAY_5 1440 10.11.2017 17:55
R-ENDTIME_SATURDAY_6 1440 10.11.2017 17:55
R-ENDTIME_SATURDAY_7 1440 10.11.2017 17:55
R-ENDTIME_SATURDAY_8 1440 10.11.2017 17:55
R-ENDTIME_SATURDAY_9 1440 10.11.2017 17:55
R-ENDTIME_SUNDAY_1 540 10.11.2017 17:55
R-ENDTIME_SUNDAY_10 1440 10.11.2017 17:55
R-ENDTIME_SUNDAY_11 1440 10.11.2017 17:55
R-ENDTIME_SUNDAY_12 1440 10.11.2017 17:55
R-ENDTIME_SUNDAY_13 1440 10.11.2017 17:55
R-ENDTIME_SUNDAY_2 1320 10.11.2017 17:55
R-ENDTIME_SUNDAY_3 1440 10.11.2017 17:55
R-ENDTIME_SUNDAY_4 1440 10.11.2017 17:55
R-ENDTIME_SUNDAY_5 1440 10.11.2017 17:55
R-ENDTIME_SUNDAY_6 1440 10.11.2017 17:55
R-ENDTIME_SUNDAY_7 1440 10.11.2017 17:55
R-ENDTIME_SUNDAY_8 1440 10.11.2017 17:55
R-ENDTIME_SUNDAY_9 1440 10.11.2017 17:55
R-ENDTIME_THURSDAY_1 840 10.11.2017 17:55
R-ENDTIME_THURSDAY_10 1440 10.11.2017 17:55
R-ENDTIME_THURSDAY_11 1440 10.11.2017 17:55
R-ENDTIME_THURSDAY_12 1440 10.11.2017 17:55
R-ENDTIME_THURSDAY_13 1440 10.11.2017 17:55
R-ENDTIME_THURSDAY_2 1320 10.11.2017 17:55
R-ENDTIME_THURSDAY_3 1440 10.11.2017 17:55
R-ENDTIME_THURSDAY_4 1320 10.11.2017 17:55
R-ENDTIME_THURSDAY_5 1440 10.11.2017 17:55
R-ENDTIME_THURSDAY_6 1440 10.11.2017 17:55
R-ENDTIME_THURSDAY_7 1440 10.11.2017 17:55
R-ENDTIME_THURSDAY_8 1440 10.11.2017 17:55
R-ENDTIME_THURSDAY_9 1440 10.11.2017 17:55
R-ENDTIME_TUESDAY_1 840 10.11.2017 17:55
R-ENDTIME_TUESDAY_10 1440 10.11.2017 17:55
R-ENDTIME_TUESDAY_11 1440 10.11.2017 17:55
R-ENDTIME_TUESDAY_12 1440 10.11.2017 17:55
R-ENDTIME_TUESDAY_13 1440 10.11.2017 17:55
R-ENDTIME_TUESDAY_2 1320 10.11.2017 17:55
R-ENDTIME_TUESDAY_3 1440 10.11.2017 17:55
R-ENDTIME_TUESDAY_4 1320 10.11.2017 17:55
R-ENDTIME_TUESDAY_5 1440 10.11.2017 17:55
R-ENDTIME_TUESDAY_6 1440 10.11.2017 17:55
R-ENDTIME_TUESDAY_7 1440 10.11.2017 17:55
R-ENDTIME_TUESDAY_8 1440 10.11.2017 17:55
R-ENDTIME_TUESDAY_9 1440 10.11.2017 17:55
R-ENDTIME_WEDNESDAY_1 840 10.11.2017 17:55
R-ENDTIME_WEDNESDAY_10 1440 10.11.2017 17:55
R-ENDTIME_WEDNESDAY_11 1440 10.11.2017 17:55
R-ENDTIME_WEDNESDAY_12 1440 10.11.2017 17:55
R-ENDTIME_WEDNESDAY_13 1440 10.11.2017 17:55
R-ENDTIME_WEDNESDAY_2 1320 10.11.2017 17:55
R-ENDTIME_WEDNESDAY_3 1440 10.11.2017 17:55
R-ENDTIME_WEDNESDAY_4 1320 10.11.2017 17:55
R-ENDTIME_WEDNESDAY_5 1440 10.11.2017 17:55
R-ENDTIME_WEDNESDAY_6 1440 10.11.2017 17:55
R-ENDTIME_WEDNESDAY_7 1440 10.11.2017 17:55
R-ENDTIME_WEDNESDAY_8 1440 10.11.2017 17:55
R-ENDTIME_WEDNESDAY_9 1440 10.11.2017 17:55
R-GLOBAL_BUTTON_LOCK 0 10.11.2017 17:55
R-I_VALUE_EXTERN 15 10.11.2017 17:55
R-I_VALUE_INTERN 17 10.11.2017 17:55
R-LOCAL_RESET_DISABLE 0 10.11.2017 17:55
R-LOW_BAT_LIMIT 42737 10.11.2017 17:55
R-MANU_MODE_PRIORITIZATION 1 10.11.2017 17:55
R-MIN_MAX_VALUE_NOT_RELEVANT_FOR_MANU_MODE 0 10.11.2017 17:55
R-MODUS_BUTTON_LOCK 0 10.11.2017 17:55
R-PARTY_MODE_PRIORITIZATION 1 10.11.2017 17:55
R-P_START_VALUE_EXTERN 30 10.11.2017 17:55
R-P_START_VALUE_INTERN 40 10.11.2017 17:55
R-P_VALUE_EXTERN 30 10.11.2017 17:55
R-P_VALUE_INTERN 32 10.11.2017 17:55
R-SHOW_WEEKDAY 0 10.11.2017 17:55
R-TEMPERATUREFALL_MODUS 4 10.11.2017 17:55
R-TEMPERATUREFALL_VALUE 42826 10.11.2017 17:55
R-TEMPERATUREFALL_WINDOW_OPEN 12.0 10.11.2017 17:55
R-TEMPERATUREFALL_WINDOW_OPEN_TIME_PERIOD 15 10.11.2017 17:55
R-TEMPERATURE_COMFORT 21.0 10.11.2017 17:55
R-TEMPERATURE_FRIDAY_1 17.0 10.11.2017 17:55
R-TEMPERATURE_FRIDAY_10 17.0 10.11.2017 17:55
R-TEMPERATURE_FRIDAY_11 17.0 10.11.2017 17:55
R-TEMPERATURE_FRIDAY_12 17.0 10.11.2017 17:55
R-TEMPERATURE_FRIDAY_13 17.0 10.11.2017 17:55
R-TEMPERATURE_FRIDAY_2 21.0 10.11.2017 17:55
R-TEMPERATURE_FRIDAY_3 17.0 10.11.2017 17:55
R-TEMPERATURE_FRIDAY_4 21.0 10.11.2017 17:55
R-TEMPERATURE_FRIDAY_5 17.0 10.11.2017 17:55
R-TEMPERATURE_FRIDAY_6 17.0 10.11.2017 17:55
R-TEMPERATURE_FRIDAY_7 17.0 10.11.2017 17:55
R-TEMPERATURE_FRIDAY_8 17.0 10.11.2017 17:55
R-TEMPERATURE_FRIDAY_9 17.0 10.11.2017 17:55
R-TEMPERATURE_LOWERING 17.0 10.11.2017 17:55
R-TEMPERATURE_MAXIMUM 42885 10.11.2017 17:55
R-TEMPERATURE_MINIMUM 42859 10.11.2017 17:55
R-TEMPERATURE_MONDAY_1 17.0 10.11.2017 17:55
R-TEMPERATURE_MONDAY_10 17.0 10.11.2017 17:55
R-TEMPERATURE_MONDAY_11 17.0 10.11.2017 17:55
R-TEMPERATURE_MONDAY_12 17.0 10.11.2017 17:55
R-TEMPERATURE_MONDAY_13 17.0 10.11.2017 17:55
R-TEMPERATURE_MONDAY_2 21.0 10.11.2017 17:55
R-TEMPERATURE_MONDAY_3 17.0 10.11.2017 17:55
R-TEMPERATURE_MONDAY_4 21.0 10.11.2017 17:55
R-TEMPERATURE_MONDAY_5 17.0 10.11.2017 17:55
R-TEMPERATURE_MONDAY_6 17.0 10.11.2017 17:55
R-TEMPERATURE_MONDAY_7 17.0 10.11.2017 17:55
R-TEMPERATURE_MONDAY_8 17.0 10.11.2017 17:55
R-TEMPERATURE_MONDAY_9 17.0 10.11.2017 17:55
R-TEMPERATURE_OFFSET 7 10.11.2017 17:55
R-TEMPERATURE_SATURDAY_1 17.0 10.11.2017 17:55
R-TEMPERATURE_SATURDAY_10 17.0 10.11.2017 17:55
R-TEMPERATURE_SATURDAY_11 17.0 10.11.2017 17:55
R-TEMPERATURE_SATURDAY_12 17.0 10.11.2017 17:55
R-TEMPERATURE_SATURDAY_13 17.0 10.11.2017 17:55
R-TEMPERATURE_SATURDAY_2 21.0 10.11.2017 17:55
R-TEMPERATURE_SATURDAY_3 17.0 10.11.2017 17:55
R-TEMPERATURE_SATURDAY_4 17.0 10.11.2017 17:55
R-TEMPERATURE_SATURDAY_5 17.0 10.11.2017 17:55
R-TEMPERATURE_SATURDAY_6 17.0 10.11.2017 17:55
R-TEMPERATURE_SATURDAY_7 17.0 10.11.2017 17:55
R-TEMPERATURE_SATURDAY_8 17.0 10.11.2017 17:55
R-TEMPERATURE_SATURDAY_9 17.0 10.11.2017 17:55
R-TEMPERATURE_SUNDAY_1 17.0 10.11.2017 17:55
R-TEMPERATURE_SUNDAY_10 17.0 10.11.2017 17:55
R-TEMPERATURE_SUNDAY_11 17.0 10.11.2017 17:55
R-TEMPERATURE_SUNDAY_12 17.0 10.11.2017 17:55
R-TEMPERATURE_SUNDAY_13 17.0 10.11.2017 17:55
R-TEMPERATURE_SUNDAY_2 21.0 10.11.2017 17:55
R-TEMPERATURE_SUNDAY_3 17.0 10.11.2017 17:55
R-TEMPERATURE_SUNDAY_4 17.0 10.11.2017 17:55
R-TEMPERATURE_SUNDAY_5 17.0 10.11.2017 17:55
R-TEMPERATURE_SUNDAY_6 17.0 10.11.2017 17:55
R-TEMPERATURE_SUNDAY_7 17.0 10.11.2017 17:55
R-TEMPERATURE_SUNDAY_8 17.0 10.11.2017 17:55
R-TEMPERATURE_SUNDAY_9 17.0 10.11.2017 17:55
R-TEMPERATURE_THURSDAY_1 17.0 10.11.2017 17:55
R-TEMPERATURE_THURSDAY_10 17.0 10.11.2017 17:55
R-TEMPERATURE_THURSDAY_11 17.0 10.11.2017 17:55
R-TEMPERATURE_THURSDAY_12 17.0 10.11.2017 17:55
R-TEMPERATURE_THURSDAY_13 17.0 10.11.2017 17:55
R-TEMPERATURE_THURSDAY_2 21.0 10.11.2017 17:55
R-TEMPERATURE_THURSDAY_3 17.0 10.11.2017 17:55
R-TEMPERATURE_THURSDAY_4 21.0 10.11.2017 17:55
R-TEMPERATURE_THURSDAY_5 17.0 10.11.2017 17:55
R-TEMPERATURE_THURSDAY_6 17.0 10.11.2017 17:55
R-TEMPERATURE_THURSDAY_7 17.0 10.11.2017 17:55
R-TEMPERATURE_THURSDAY_8 17.0 10.11.2017 17:55
R-TEMPERATURE_THURSDAY_9 17.0 10.11.2017 17:55
R-TEMPERATURE_TUESDAY_1 17.0 10.11.2017 17:55
R-TEMPERATURE_TUESDAY_10 17.0 10.11.2017 17:55
R-TEMPERATURE_TUESDAY_11 17.0 10.11.2017 17:55
R-TEMPERATURE_TUESDAY_12 17.0 10.11.2017 17:55
R-TEMPERATURE_TUESDAY_13 17.0 10.11.2017 17:55
R-TEMPERATURE_TUESDAY_2 21.0 10.11.2017 17:55
R-TEMPERATURE_TUESDAY_3 17.0 10.11.2017 17:55
R-TEMPERATURE_TUESDAY_4 21.0 10.11.2017 17:55
R-TEMPERATURE_TUESDAY_5 17.0 10.11.2017 17:55
R-TEMPERATURE_TUESDAY_6 17.0 10.11.2017 17:55
R-TEMPERATURE_TUESDAY_7 17.0 10.11.2017 17:55
R-TEMPERATURE_TUESDAY_8 17.0 10.11.2017 17:55
R-TEMPERATURE_TUESDAY_9 17.0 10.11.2017 17:55
R-TEMPERATURE_WEDNESDAY_1 17.0 10.11.2017 17:55
R-TEMPERATURE_WEDNESDAY_10 17.0 10.11.2017 17:55
R-TEMPERATURE_WEDNESDAY_11 17.0 10.11.2017 17:55
R-TEMPERATURE_WEDNESDAY_12 17.0 10.11.2017 17:55
R-TEMPERATURE_WEDNESDAY_13 17.0 10.11.2017 17:55
R-TEMPERATURE_WEDNESDAY_2 21.0 10.11.2017 17:55
R-TEMPERATURE_WEDNESDAY_3 17.0 10.11.2017 17:55
R-TEMPERATURE_WEDNESDAY_4 21.0 10.11.2017 17:55
R-TEMPERATURE_WEDNESDAY_5 17.0 10.11.2017 17:55
R-TEMPERATURE_WEDNESDAY_6 17.0 10.11.2017 17:55
R-TEMPERATURE_WEDNESDAY_7 17.0 10.11.2017 17:55
R-TEMPERATURE_WEDNESDAY_8 17.0 10.11.2017 17:55
R-TEMPERATURE_WEDNESDAY_9 17.0 10.11.2017 17:55
R-VALVE_ERROR_RUN_POSITION 15 10.11.2017 17:55
R-VALVE_MAXIMUM_POSITION 100 10.11.2017 17:55
R-VALVE_OFFSET 0 10.11.2017 17:55
control 21.0 10.11.2017 17:56
hmstate 21.0 10.11.2017 17:56
state 21.0 10.11.2017 17:56
Hier sind nun die Tages Temperaturen und Zeiten zu sehen, wobei ich den Wert bei den Zeiten noch nicht verstehe :-/
Jetzt wäre der nächste Schritt herrauszufinden, wie man diese Werte per setzen kann, dies ist mir allerdings noch nicht gelungen.
Mit set <device> datapoint <datapoint> <value> lassen sich wahrscheinlich nur die Werte mit [W] ändern.
CHN OEQ0844452:0 wz_heizung:0
DPT {b} BidCos-RF.OEQ0844452:0.UNREACH = false [RE]
DPT {b} BidCos-RF.OEQ0844452:0.STICKY_UNREACH = true [RWE]
DPT {b} BidCos-RF.OEQ0844452:0.CONFIG_PENDING = false [RE]
DPT {b} BidCos-RF.OEQ0844452:0.LOWBAT = false [RE]
DPT {n} BidCos-RF.OEQ0844452:0.RSSI_DEVICE = 191 [RE]
DPT {n} BidCos-RF.OEQ0844452:0.RSSI_PEER = 160 [RE]
DPT {b} BidCos-RF.OEQ0844452:0.INHIBIT = false [RWE]
DPT {b} BidCos-RF.OEQ0844452:0.DEVICE_IN_BOOTLOADER = false [RE]
DPT {b} BidCos-RF.OEQ0844452:0.UPDATE_PENDING = false [RE]
DPT {n} BidCos-RF.OEQ0844452:0.AES_KEY = 0 [R]
CHN OEQ0844452:4 HM-CC-RT-DN OEQ0844452:4
DPT {i} BidCos-RF.OEQ0844452:4.CONTROL_MODE = 0 [RE]
DPT {i} BidCos-RF.OEQ0844452:4.FAULT_REPORTING = 0 [RE]
DPT {f} BidCos-RF.OEQ0844452:4.BATTERY_STATE = 3.100000 [RE]
DPT {i} BidCos-RF.OEQ0844452:4.VALVE_STATE = 8 [RE]
DPT {i} BidCos-RF.OEQ0844452:4.BOOST_STATE = 0 [RE]
DPT {f} BidCos-RF.OEQ0844452:4.ACTUAL_TEMPERATURE = 23.300000 [RE]
DPT {f} BidCos-RF.OEQ0844452:4.SET_TEMPERATURE = 21.000000 [RWE]
DPT {b} BidCos-RF.OEQ0844452:4.AUTO_MODE = [W]
DPT {f} BidCos-RF.OEQ0844452:4.MANU_MODE = [W]
DPT {b} BidCos-RF.OEQ0844452:4.BOOST_MODE = [W]
DPT {b} BidCos-RF.OEQ0844452:4.COMFORT_MODE = [W]
DPT {b} BidCos-RF.OEQ0844452:4.LOWERING_MODE = [W]
DPT {s} BidCos-RF.OEQ0844452:4.PARTY_MODE_SUBMIT = [W]
DPT {f} BidCos-RF.OEQ0844452:4.PARTY_TEMPERATURE = 5.000000 [RW]
DPT {i} BidCos-RF.OEQ0844452:4.PARTY_START_TIME = 0 [RW]
DPT {i} BidCos-RF.OEQ0844452:4.PARTY_START_DAY = 1 [RW]
DPT {i} BidCos-RF.OEQ0844452:4.PARTY_START_MONTH = 1 [RW]
DPT {i} BidCos-RF.OEQ0844452:4.PARTY_START_YEAR = 0 [RW]
DPT {i} BidCos-RF.OEQ0844452:4.PARTY_STOP_TIME = 0 [RW]
DPT {i} BidCos-RF.OEQ0844452:4.PARTY_STOP_DAY = 1 [RW]
DPT {i} BidCos-RF.OEQ0844452:4.PARTY_STOP_MONTH = 1 [RW]
DPT {i} BidCos-RF.OEQ0844452:4.PARTY_STOP_YEAR = 0 [RW]
mit get configlist bekomme ich auch eine Liste mit allen Werten:
ADAPTIVE_REGULATION=2
BACKLIGHT_ON_TIME=10
BOOST_AFTER_WINDOW_OPEN=0
BOOST_POSITION=80
BOOST_TIME_PERIOD=1
BURST_RX=1
BUTTON_LOCK=0
BUTTON_RESPONSE_WITHOUT_BACKLIGHT=0
CYCLIC_INFO_MSG=1
CYCLIC_INFO_MSG_DIS=0
DAYLIGHT_SAVING_TIME=1
DECALCIFICATION_TIME=660
DECALCIFICATION_WEEKDAY=0
DISPLAY_INFORMATION=0
ENDTIME_FRIDAY_1=840
ENDTIME_FRIDAY_10=1440
ENDTIME_FRIDAY_11=1440
ENDTIME_FRIDAY_12=1440
ENDTIME_FRIDAY_13=1440
ENDTIME_FRIDAY_2=1320
ENDTIME_FRIDAY_3=1440
ENDTIME_FRIDAY_4=1320
ENDTIME_FRIDAY_5=1440
ENDTIME_FRIDAY_6=1440
ENDTIME_FRIDAY_7=1440
ENDTIME_FRIDAY_8=1440
ENDTIME_FRIDAY_9=1440
ENDTIME_MONDAY_1=840
ENDTIME_MONDAY_10=1440
ENDTIME_MONDAY_11=1440
ENDTIME_MONDAY_12=1440
ENDTIME_MONDAY_13=1440
ENDTIME_MONDAY_2=1320
ENDTIME_MONDAY_3=1440
ENDTIME_MONDAY_4=1320
ENDTIME_MONDAY_5=1440
ENDTIME_MONDAY_6=1440
ENDTIME_MONDAY_7=1440
ENDTIME_MONDAY_8=1440
ENDTIME_MONDAY_9=1440
ENDTIME_SATURDAY_1=540
ENDTIME_SATURDAY_10=1440
ENDTIME_SATURDAY_11=1440
ENDTIME_SATURDAY_12=1440
ENDTIME_SATURDAY_13=1440
ENDTIME_SATURDAY_2=1380
ENDTIME_SATURDAY_3=1440
ENDTIME_SATURDAY_4=1440
ENDTIME_SATURDAY_5=1440
ENDTIME_SATURDAY_6=1440
ENDTIME_SATURDAY_7=1440
ENDTIME_SATURDAY_8=1440
ENDTIME_SATURDAY_9=1440
ENDTIME_SUNDAY_1=540
ENDTIME_SUNDAY_10=1440
ENDTIME_SUNDAY_11=1440
ENDTIME_SUNDAY_12=1440
ENDTIME_SUNDAY_13=1440
ENDTIME_SUNDAY_2=1320
ENDTIME_SUNDAY_3=1440
ENDTIME_SUNDAY_4=1440
ENDTIME_SUNDAY_5=1440
ENDTIME_SUNDAY_6=1440
ENDTIME_SUNDAY_7=1440
ENDTIME_SUNDAY_8=1440
ENDTIME_SUNDAY_9=1440
ENDTIME_THURSDAY_1=840
ENDTIME_THURSDAY_10=1440
ENDTIME_THURSDAY_11=1440
ENDTIME_THURSDAY_12=1440
ENDTIME_THURSDAY_13=1440
ENDTIME_THURSDAY_2=1320
ENDTIME_THURSDAY_3=1440
ENDTIME_THURSDAY_4=1320
ENDTIME_THURSDAY_5=1440
ENDTIME_THURSDAY_6=1440
ENDTIME_THURSDAY_7=1440
ENDTIME_THURSDAY_8=1440
ENDTIME_THURSDAY_9=1440
ENDTIME_TUESDAY_1=840
ENDTIME_TUESDAY_10=1440
ENDTIME_TUESDAY_11=1440
ENDTIME_TUESDAY_12=1440
ENDTIME_TUESDAY_13=1440
ENDTIME_TUESDAY_2=1320
ENDTIME_TUESDAY_3=1440
ENDTIME_TUESDAY_4=1320
ENDTIME_TUESDAY_5=1440
ENDTIME_TUESDAY_6=1440
ENDTIME_TUESDAY_7=1440
ENDTIME_TUESDAY_8=1440
ENDTIME_TUESDAY_9=1440
ENDTIME_WEDNESDAY_1=840
ENDTIME_WEDNESDAY_10=1440
ENDTIME_WEDNESDAY_11=1440
ENDTIME_WEDNESDAY_12=1440
ENDTIME_WEDNESDAY_13=1440
ENDTIME_WEDNESDAY_2=1320
ENDTIME_WEDNESDAY_3=1440
ENDTIME_WEDNESDAY_4=1320
ENDTIME_WEDNESDAY_5=1440
ENDTIME_WEDNESDAY_6=1440
ENDTIME_WEDNESDAY_7=1440
ENDTIME_WEDNESDAY_8=1440
ENDTIME_WEDNESDAY_9=1440
GLOBAL_BUTTON_LOCK=0
I_VALUE_EXTERN=15
I_VALUE_INTERN=17
LOCAL_RESET_DISABLE=0
LOW_BAT_LIMIT=2.100000
MANU_MODE_PRIORITIZATION=1
MIN_MAX_VALUE_NOT_RELEVANT_FOR_MANU_MODE=0
MODUS_BUTTON_LOCK=0
PARTY_MODE_PRIORITIZATION=1
P_START_VALUE_EXTERN=30
P_START_VALUE_INTERN=40
P_VALUE_EXTERN=30
P_VALUE_INTERN=32
SHOW_WEEKDAY=0
TEMPERATUREFALL_MODUS=4
TEMPERATUREFALL_VALUE=1.400000
TEMPERATUREFALL_WINDOW_OPEN=12.000000
TEMPERATUREFALL_WINDOW_OPEN_TIME_PERIOD=15
TEMPERATURE_COMFORT=21.000000
TEMPERATURE_FRIDAY_1=17.000000
TEMPERATURE_FRIDAY_10=17.000000
TEMPERATURE_FRIDAY_11=17.000000
TEMPERATURE_FRIDAY_12=17.000000
TEMPERATURE_FRIDAY_13=17.000000
TEMPERATURE_FRIDAY_2=21.000000
TEMPERATURE_FRIDAY_3=17.000000
TEMPERATURE_FRIDAY_4=21.000000
TEMPERATURE_FRIDAY_5=17.000000
TEMPERATURE_FRIDAY_6=17.000000
TEMPERATURE_FRIDAY_7=17.000000
TEMPERATURE_FRIDAY_8=17.000000
TEMPERATURE_FRIDAY_9=17.000000
TEMPERATURE_LOWERING=17.000000
TEMPERATURE_MAXIMUM=30.500000
TEMPERATURE_MINIMUM=4.500000
TEMPERATURE_MONDAY_1=17.000000
TEMPERATURE_MONDAY_10=17.000000
TEMPERATURE_MONDAY_11=17.000000
TEMPERATURE_MONDAY_12=17.000000
TEMPERATURE_MONDAY_13=17.000000
TEMPERATURE_MONDAY_2=21.000000
TEMPERATURE_MONDAY_3=17.000000
TEMPERATURE_MONDAY_4=21.000000
TEMPERATURE_MONDAY_5=17.000000
TEMPERATURE_MONDAY_6=17.000000
TEMPERATURE_MONDAY_7=17.000000
TEMPERATURE_MONDAY_8=17.000000
TEMPERATURE_MONDAY_9=17.000000
TEMPERATURE_OFFSET=7
TEMPERATURE_SATURDAY_1=17.000000
TEMPERATURE_SATURDAY_10=17.000000
TEMPERATURE_SATURDAY_11=17.000000
TEMPERATURE_SATURDAY_12=17.000000
TEMPERATURE_SATURDAY_13=17.000000
TEMPERATURE_SATURDAY_2=21.000000
TEMPERATURE_SATURDAY_3=17.000000
TEMPERATURE_SATURDAY_4=17.000000
TEMPERATURE_SATURDAY_5=17.000000
TEMPERATURE_SATURDAY_6=17.000000
TEMPERATURE_SATURDAY_7=17.000000
TEMPERATURE_SATURDAY_8=17.000000
TEMPERATURE_SATURDAY_9=17.000000
TEMPERATURE_SUNDAY_1=17.000000
TEMPERATURE_SUNDAY_10=17.000000
TEMPERATURE_SUNDAY_11=17.000000
TEMPERATURE_SUNDAY_12=17.000000
TEMPERATURE_SUNDAY_13=17.000000
TEMPERATURE_SUNDAY_2=21.000000
TEMPERATURE_SUNDAY_3=17.000000
TEMPERATURE_SUNDAY_4=17.000000
TEMPERATURE_SUNDAY_5=17.000000
TEMPERATURE_SUNDAY_6=17.000000
TEMPERATURE_SUNDAY_7=17.000000
TEMPERATURE_SUNDAY_8=17.000000
TEMPERATURE_SUNDAY_9=17.000000
TEMPERATURE_THURSDAY_1=17.000000
TEMPERATURE_THURSDAY_10=17.000000
TEMPERATURE_THURSDAY_11=17.000000
TEMPERATURE_THURSDAY_12=17.000000
TEMPERATURE_THURSDAY_13=17.000000
TEMPERATURE_THURSDAY_2=21.000000
TEMPERATURE_THURSDAY_3=17.000000
TEMPERATURE_THURSDAY_4=21.000000
TEMPERATURE_THURSDAY_5=17.000000
TEMPERATURE_THURSDAY_6=17.000000
TEMPERATURE_THURSDAY_7=17.000000
TEMPERATURE_THURSDAY_8=17.000000
TEMPERATURE_THURSDAY_9=17.000000
TEMPERATURE_TUESDAY_1=17.000000
TEMPERATURE_TUESDAY_10=17.000000
TEMPERATURE_TUESDAY_11=17.000000
TEMPERATURE_TUESDAY_12=17.000000
TEMPERATURE_TUESDAY_13=17.000000
TEMPERATURE_TUESDAY_2=21.000000
TEMPERATURE_TUESDAY_3=17.000000
TEMPERATURE_TUESDAY_4=21.000000
TEMPERATURE_TUESDAY_5=17.000000
TEMPERATURE_TUESDAY_6=17.000000
TEMPERATURE_TUESDAY_7=17.000000
TEMPERATURE_TUESDAY_8=17.000000
TEMPERATURE_TUESDAY_9=17.000000
TEMPERATURE_WEDNESDAY_1=17.000000
TEMPERATURE_WEDNESDAY_10=17.000000
TEMPERATURE_WEDNESDAY_11=17.000000
TEMPERATURE_WEDNESDAY_12=17.000000
TEMPERATURE_WEDNESDAY_13=17.000000
TEMPERATURE_WEDNESDAY_2=21.000000
TEMPERATURE_WEDNESDAY_3=17.000000
TEMPERATURE_WEDNESDAY_4=21.000000
TEMPERATURE_WEDNESDAY_5=17.000000
TEMPERATURE_WEDNESDAY_6=17.000000
TEMPERATURE_WEDNESDAY_7=17.000000
TEMPERATURE_WEDNESDAY_8=17.000000
TEMPERATURE_WEDNESDAY_9=17.000000
VALVE_ERROR_RUN_POSITION=15
VALVE_MAXIMUM_POSITION=100
VALVE_OFFSET=0
Vielleicht hilft das schon mal etwas weiter ;-)
Gruß Lars
Hallo Lars,
danke für die vielen Infos. Doch sorry, ich kann mich nicht selbst durch den ganzen HM-Gram arbeiten.
Wenn es ein Device gibt, wo man die Wochenpläne auslesen und setzen kann, dann kann ich auch was machen. Dazu musst du mir dann genau sagen wie das geht.
Es scheint sich die HMCCU auch ganz schön von CUL_HM zu unterscheiden ???
Risiko.
Hallo Risiko,
ZitatEs scheint sich die HMCCU auch ganz schön von CUL_HM zu unterscheiden
Genau das ist das Problem. Ich hab momentan keine Ahnung wie ich die Ausgelesenen Wochenpläne deuten soll und auch bisher keine Möglichkeit gefunden diese über fhem zu setzten...
Falls ich noch was herrausfinde, melde ich mich hier. Kann dich verstehen und weiss was du benötigst. Vielen Dank!
Gruß
Lars
Hallo LaSto,
ich habe Risiko gerade eine auf die CCU2 angepasse Version zugeschickt. Sie scheint bei mir mit Homematic IP Geräten zu laufen... Allerdings sind meine Anpassungen noch nicht vollständig...
Gruß
Manfred
Bitte Datei zur Verfügung stellen, dann schaue ich es mir bei Gelegenheit mal an.
Wenn mgl. auch soweit wie mgl. dokumentieren.
Guten Morgen,
weiß jemand Rat? Ich nutze derzeit nur die Masterprofile. Nun habe ich mal ein master Profil kopiert, einen neuen Namen für dieses zweite Profil angelegt und kann auch über ein Pulldown
zwischen dem master und dem neuen Profil hin und her schalten. Wenn ich aber nun das neu angelegte ändere, und auf speichern klicke, wird die Änderung nicht übernommen. Woran könnte
das liegen?
Hallo.
Was meinst du mit Änderung nicht übernommen?
Die Profile werden in einer Datei "weekprofile-<name>_.cfg" im Log Ordner gespeichert.
Das neue Profil wird nicht automatisch zum Thermostat gesendet.
naja ich habe das bestehende master Profil in ein neues kopiert, und einen Namen vergeben (z.B. "Sommer"). Dann habe ich auf die Zahnräder geklickt, und habe Zeiten und Temperaturen verändert.
Dann auf speichern. Jetzt bin ich wieder aus dem editier Modus draußen und kann über das Pulldown zwischen "master" und "Sommer" wählen. Aber meine Änderungen werden hier dann nicht angezeigt.
Hmm. Kann ich leider nicht viel sagen.
Kann keinen Fehler nachstellen. Existiert denn die Datei im Log Ordner und was steht drin?
An alle Nutzer einer CCU2.
Anbei eine erste Testversion. Dank an vocaris.
Vielleicht kannst du vocaris noch was zur Konfiguration schreiben
Weekprofil zeigt keine Werte mehr an:
Siehe Bild im Anhang.
Habe keine Ahnung seit wann das so ist, oder was ich gemacht habe.
list BU_Heizung_Heizplan
Internals:
DEF BU_Heizung_Clima
NAME BU_Heizung_Heizplan
NR 396
NTFY_ORDER 50-BU_Heizung_Heizplan
STATE assigned
TYPE weekprofile
MASTERDEV:
NAME BU_Heizung_Clima
TYPE CUL_HM
PROFILES:
HASH(0x4803a98)
HASH(0x47f3d38)
HASH(0x47f1718)
HASH(0x4808d90)
HASH(0x480aa48)
HASH(0x480f7b0)
READINGS:
2017-11-26 22:22:41 profile_count 6
2017-11-26 21:58:00 state assigned
SNDDEVLIST:
HASH(0x4d2eb90)
HASH(0x4d2e548)
HASH(0x4d7a0c0)
HASH(0x488ffe0)
HASH(0x4ae4148)
HASH(0x3302328)
HASH(0x4f0ead0)
TOPICS:
default
Attributes:
room Buero
Hallo Risiko,
die Datei existiert, und es werden auch Änderungen darin vorgenommen, allerdings nicht alle. Wenn ich mit FHEM ein Wochenprogramm editiere (habe mal 7 Temperaturwerte verändert) und dann
speichere, werden mal 1 mal 2 der Änderungen in die Datei geschrieben. Der Rest bleibt verfällt....
@Heimweh und @Jewe
setzt mal bitte verbose auf 5 und schaut mal ins Log bzw. zeigt mit die Ausgaben von weekprofile
Hallo Risiko,
das ist das Log mit Verbose 5:
2017.11.28 23:27:50 5: BU_Heizung_Heizplan(Notify): BU_Heizung_Clima, ValvePosition:
2017.11.28 23:27:50 4: BU_Heizung_Heizplan(Notify): reread master profile from BU_Heizung_Clima
2017.11.28 23:30:15 5: BU_Heizung_Heizplan(Notify): BU_Heizung_Clima, ValvePosition:
2017.11.28 23:30:15 4: BU_Heizung_Heizplan(Notify): reread master profile from BU_Heizung_Clima
2017.11.28 23:32:26 5: BU_Heizung_Heizplan(Notify): BU_Heizung_Clima, ValvePosition:
2017.11.28 23:32:26 4: BU_Heizung_Heizplan(Notify): reread master profile from BU_Heizung_Clima
2017.11.28 23:35:26 5: BU_Heizung_Heizplan(Notify): BU_Heizung_Clima, ValvePosition:
2017.11.28 23:35:26 4: BU_Heizung_Heizplan(Notify): reread master profile from BU_Heizung_Clima
2017.11.28 23:38:12 5: BU_Heizung_Heizplan(Notify): BU_Heizung_Clima, ValvePosition:
2017.11.28 23:38:12 4: BU_Heizung_Heizplan(Notify): reread master profile from BU_Heizung_Clima
2017.11.28 23:40:44 5: BU_Heizung_Heizplan(Notify): BU_Heizung_Clima, ValvePosition:
2017.11.28 23:40:44 4: BU_Heizung_Heizplan(Notify): reread master profile from BU_Heizung_Clima
2017.11.28 23:43:01 5: BU_Heizung_Heizplan(Notify): BU_Heizung_Clima, ValvePosition:
2017.11.28 23:43:01 4: BU_Heizung_Heizplan(Notify): reread master profile from BU_Heizung_Clima
2017.11.28 23:45:03 5: BU_Heizung_Heizplan(Notify): BU_Heizung_Clima, ValvePosition:
2017.11.28 23:45:03 4: BU_Heizung_Heizplan(Notify): reread master profile from BU_Heizung_Clima
2017.11.28 23:47:55 5: BU_Heizung_Heizplan(Notify): BU_Heizung_Clima, ValvePosition:
2017.11.28 23:47:55 4: BU_Heizung_Heizplan(Notify): reread master profile from BU_Heizung_Clima
Hallo Jewe,
leider kann ich da nichts erkennen.
Da ich an weekprofile nichts geändert habe, nehme ich mal an, dass sich was an CUL_HM geändert hat.
Ich habe leider momentan etwas wenig Zeit. Ich versuche in den nächsten Tag mal eine Version mit mehr Logs zu erstellen.
Hallo Risiko,
ich habe jetzt noch ein bisschen experimentiert. In die .cfg Datei werden die Änderungen die ich im Widget mache eingetragen. Zumindest wenn ich Tag für Tag einzeln ändere (einen
Tag ändern und auf die anderen kopieren geht nicht). und dann speicher, wird es in die Datei geschrieben. Allerdings wird das neue Profil dann nicht im Widget angezeigt.
Also die Temperaturen die in der cfg stehen, zeigt das Widget nicht an - im Widget stehen dann noch die alten Werte....
Hallo Heimweh,
leider kann ich das bei mir nicht nachvollziehen. Welchen Browser verwendest du?
Sind die Werte aktuell, wenn die Sie Seite aktualisierst (Browsercache ggf. löschen)
Risiko.
@Risiko
Ich benutze Chrome. Alle Änderungen werden richtig gespeichert in der cfg Datei, aber FHEM liest es nicht neu ein sondern zeigt immer alles an wie vor meiner Änderung.
Hallo Heimweh,
ich verwende auch Chrome und kann keine Probleme feststellen.
Kannst du bitte verbose auf weekprofile auf 5 stellen und die Datei fhemweb_weekprofile.js mit Meldungen zum Test verwenden! Mit Logmeldungen und Messages posten.
Die Datei muss nach 'www/pgm2/'
Hallo,
erstmal rießen Lob für das Plugin.
Ich finds klasse und nutze es ausgibig um meine Heizprofile zu verwalten, welche ich dann per Dummy Schalter meiner entsprechenden Schicht dann direkt auf meine Themorstate schicken lasse.
Allerdings vermisse ich ein gutes Feature, das ich früher bei meiner Qivicon nutzen konnte.
Die meiste Zeit über will ich egt meinen Thermostaten eine gewünschte Temperatur von 22°C schicken.
Doch hin und wieder (wenns draußen richtig kalt ist), hätte ich gerne eine gewünschte Temperatur von 23°C (ja das macht mir viel aus ;D ).
Und genau hier fehlt mir jetzt das Feature von der Qivicon... dort konnte man zwei Temperaturen als Variable festlegen und schnell ändern, was sich dann wiederum auf den Wochenplan ausgewirkt hatte, wo die zwei Variablen übernommen wurden.
Kurzgefasst, ich hätte gerne die Möglichkeit Variablen in dem Wochenplan, anstatt feste Temperaturen festzulegen.
Also anstatt:
Mon 00:00-15:00 6.0 °C 15:00-22:00 22.0 °C 22:00-24:00 6.0 °C
So etwas:
Mon 00:00-15:00 6.0 °C 15:00-22:00 $temp °C 22:00-24:00 6.0 °C
Dann könnte ich letzendlich meine "Wohlfühltemperatur" zentral anpassen und ändern, was sich wiederum auf alle meine Pläne auswirken würde (ich nutze Profile für meine unterschiedlichen Schichten: Frühschicht, Tagschicht, Spätschicht, Nachtschicht, Frei).
Ist nur ein Vorschlag, vielen Dank. ;)
Hallo borsTiHD,
so richtig habe ich leider den Sinn noch nicht verstanden. Wieso machst du das nicht mit mehr Profilen. z.B. Spätschicht_22,Spätschicht_23? So häufig wirst du doch diese "Wohlfühltemperatur" nicht ändern, oder?
Wo soll die Temperatur für die Variable $temp definiert werden und was soll passieren, wenn sich dieser Wert ändert?
Hi, erstmal danke für die schnelle Antwort. ;)
Ich habe derzeit 6 Wochenpläne erstellt, mit jeweils einer Aufteilung für 3 Raumbereiche (Bad, Schlafzimmer, Wohnbereich).
Damit komme ich auf insgesamt 18 unterschiedliche Pläne (Screenshot im Anhang).
Die Wochenpläne selbst habe ich keinem Thermostat zugewiesen, ich habe mir eine kleine Funktion gebaut in Verbindung mit einem Dummy Schalter (Screenshot im Anhang).
Sobald ich im Dummy Schalter beispielsweise Spätschicht anklicke, wird meinen Thermostaten entsprechend ihrer Zugehörigkeit, der Wochenplan "
wp_Spaetschicht" mit dem Profil "
Wohnbereich (da sind 3 Thermostate zugewiesen),
Bad (1 Thermostat) und
Schlafzimmer (1 Thermostat)" zugeteilt.
Soweit bin ich damit auch sehr zufrieden und das klappt wunderbar.
Jetzt habe ich aber in allen Plänen die festen 22°C drin stehen, zu den Zeiten an denen ich es gerne geheizt habe und 6°C zu den Zeiten an denen nicht geheizt werden soll.
Mein Wunsch wäre es jetzt, zu all diesen Zeiten in denen ich derzeit die festen 22°C drin habe, eine Variable stehen hab um bei Bedarf niedrigere, oder höhere Temperaturen einzustellen, ohne gleich 16 Wochenpläne anpassen zu müssen.
Ich würde also gerne über den Wochenplan nur noch die "Zeitpunkte" bestimmen an denen ich heize oder nicht heize und die Temperatur über ein zusätzliches Dropdown Menü anpassen.
Hoffe ich konnte es so besser erklären. :D
€dit:
Achso, die 22°C und 23°C waren jetzt nur ein Beispiel.
Zitat von: Risiko am 22 Dezember 2017, 13:18:08
Wo soll die Temperatur für die Variable $temp definiert werden und was soll passieren, wenn sich dieser Wert ändert?
Das wäre mir erstmal nicht sooo wichtig.
Schön wäre natürlich ein definierbares Devices für das Webinterface von FHEM (ähnlich meinem Dummy Schalter, nur mit einem Dropdown Menü für die Temperatur), aber auch ein Wert in einer Funktion unter "99_myUtils.pm", oder einer *.cfg fänd ich schon super.
Dann wünschenswert wäre wenn der Wochenplan einfach beim "senden" zu einem Thermostat den Wert aus der Variable nimmt.
Meinst du der Aufwand lohnt sich nicht entsprechend?
Hallo borsTiHD,
habe ich verstanden. Könnte mir folgendes Vorstellen:
Ein Attribut in weekprofile mit einer Liste von Variablennamen z.B. tempVars = temp1,temp2,...tempN.
Diese tauchen dann auch als Readings auf (default 20°): temp1= 20°. Diese kann man dann natürlich ändern.
In den Wochenplänen kann man dann statt feste Werte die Variablennamen aus der Liste verwenden $temp1..$tempN
Bevor dann ein Wochenplan gesendet oder abgefragt wird, werden die Variablen entsprechend ihrer Werte aus den Readings ersetzt.
Beim erstellen der Wochenpläne in FHEMWEB tauchen die Variablennamen wie auch on,off in der Dropdownbox auf.
Denke, dass ist eine generische Lösung und hilft hoffentlich mehreren Leuten.
@All - ein kurzes Feedback dazu wäre super. Wann ich natürlich zu der Umsetzung komme, kann ich noch nicht sagen.
Noch eine Anmerkung zu deiner speziellen Konstellation. Ich bin der Meinung, dass man alles mit einem einzigen weekprofile durch Verwendung von Topics realisieren kann. Bei Topics kann man auch Referenzen auf andere Pläne machen! Hast du dir das schon mal angesehen?
Zitat von: Risiko am 27 Dezember 2017, 10:23:41
Denke, dass ist eine generische Lösung und hilft hoffentlich mehreren Leuten.
@All - ein kurzes Feedback dazu wäre super. Wann ich natürlich zu der Umsetzung komme, kann ich noch nicht sagen.
Hi risiko,
ich nutze weekprofile auch schon eine Weile und finde die Idee mit generischen Werten super.
Wie viele Variablen würdest du zusätzlich einbauen? Ich denke egal wie viele, entweder es sind zu wenige, oder es wird unübersichtlich.
Ein anderer Gedankengang:
1) Werte aus beliebigem Device per readingsval oder Funktionen übernehmen.
2) Im Weekprofile bräuchtest du ein Attribut namens "source" das default (nicht gesetzt) feste Werte im Weekprofile (wie jetzt) erwartet, wenn "source = generic" ist, wird die im Feld hinterlegte Funktion eingestellt. Das könnte ein readingsval, oder auch eine Funktion in 99_myutils sein.
3) Damit das visuell auch ansprechend bleibt, wäre die Ausgabe des aktuellen Wertes auch nett
4) Eine Funktion "refresh" oder so wäre dann auch nötig, um per event auf Änderungen reagieren zu können bzw. ein reload anzustoßen. "send_to_device" gibt es schon, müsste man testen ob das ausreicht. Hängt halt von der Implementierung ab.
Beispiel:
Dummy dy_Temperaturen hat ein UserReading, Temp1_day, Temp2_day, Temp3_day, Temp1_night... und so weiter. Damit könnte man sich beliebige Gruppen, Scenarien abbilden, der Rest wird dann gemacht wenn per notify auf eine Änderung reagiert wird.
Vorteil, völlig generisch
Nachteil, für weniger "geübte" mehr Fehlerquellen und Dokumentation etwas aufwändig.
Hallo kadettilac89,
danke für deinen Vorschlag. Ganz verstanden habe ich ihn leider nicht. Du willst also, dass weekprofile aus einem Device Readings ausliest !?
Das ist aber nicht der Sinn des Moduls. Es soll eben relativ einfach Wochenpläne verwalten. Wenn die Pläne primär aus einem anderen Device kommen, dann ist das Ganze für mich Sinn frei oder ich hab es eben nicht verstanden ::)
Nein, weekprofile bleibt weiterhin das führende Device. Was ich vorschlage ist, die dynamischen Werte aus beliebigen Quellen per readingsval oder 99_myutils-Funktion.
Dein Vorhaben war diese dynamischen Werte als Attribut im Weekprofile zu pflegen wenn ich das richtig deute. Dadurch müssten die Werte wieder in den weekprofiles (mehrfach?) definiert werden.
Vielleicht haben wir ähnliche Ideen und reden aneinander vorbei.
Beispiel, ich hoffe, dass ich mich verständlicher ausdrücke ...
Source soll hier mal ein Dummy sein
Dummy namens dy_Temp
attr1: temp_day_1
attr2: temp_day_2
attr3: temp_day_3
Im Weekprofile ist folgender Zeitplan für einen Tag :
Mon 00:00-06:00 14.0 °C 06:00-07:00 16.0 °C 07:00-22:00 20.0 °C 22:00-24:00 16.0 °C
Die Werte werden aus dem Dummy übernommen
Mon 00:00-06:00 =dy_Temp-attr_day_1 06:00-07:00 =dy_Temp-temp_day_2 07:00-22:00 =dy_Temp-temp_day_3 22:00-24:00 =dy_Temp-temp_day_1
Hallo kadettilac89,
ich denke, ich habe deinen Ansatz verstanden. Finde ihn aber zu kompliziert. Man müsste ja auch noch definieren, welches Plan man über dieses "fremde" Device (in deinem Beispiel das Dummy) manipulieren möchte. Weiterhin muss man meiner Meinung nach sehr viel Aufwand in das Dummy oder die Funktion stecken und ich wäre dann für den Support und Fragen verantwortlich! Finde ich nicht so prickelnd. Wer diesen Aufwand in einer 99_myutils-Funktion treiben möchte, kann dies jetzt auch schon tun. Er schreibt sich eine Funktion, die einen Wochenplan im json-Format zusammenstellt und ihn dann per set einfach an weekprofile übergibt\ändert!
Also kurzum, du hast mich noch nicht überzeugt ;)
Risiko.
Frohes Neues erstmal an alle. ;D
Zitat von: Risiko am 27 Dezember 2017, 10:23:41
Hallo borsTiHD,
habe ich verstanden. Könnte mir folgendes Vorstellen:
Ein Attribut in weekprofile mit einer Liste von Variablennamen z.B. tempVars = temp1,temp2,...tempN.
Diese tauchen dann auch als Readings auf (default 20°): temp1= 20°. Diese kann man dann natürlich ändern.
In den Wochenplänen kann man dann statt feste Werte die Variablennamen aus der Liste verwenden $temp1..$tempN
Bevor dann ein Wochenplan gesendet oder abgefragt wird, werden die Variablen entsprechend ihrer Werte aus den Readings ersetzt.
Beim erstellen der Wochenpläne in FHEMWEB tauchen die Variablennamen wie auch on,off in der Dropdownbox auf.
Denke, dass ist eine generische Lösung und hilft hoffentlich mehreren Leuten.
@All - ein kurzes Feedback dazu wäre super. Wann ich natürlich zu der Umsetzung komme, kann ich noch nicht sagen.
Ja genau, sowas meinte ich, danke das du dir dazu Gedanken machst. :D
Würde mich freuen wenn du sowas umgesetzt bekommst.
Zitat von: Risiko am 27 Dezember 2017, 10:23:41
Noch eine Anmerkung zu deiner speziellen Konstellation. Ich bin der Meinung, dass man alles mit einem einzigen weekprofile durch Verwendung von Topics realisieren kann. Bei Topics kann man auch Referenzen auf andere Pläne machen! Hast du dir das schon mal angesehen?
Hm... danke für den Hinweis, werde mich da die Tage mal einlesen und mal was ausprobieren.
Derzeit hab ich das wie gesagt mit dem einen Dummy Device als Schalter, mit dem ich quasi bestimme welche Schicht ich habe (der kleinere Screenshot von meinem vorherigen Post).
Darauf reagiert ein Notify, das eine Funktion aus meiner "99_myUtils.pm" öffnet und übergibt nur den Schichtnamen.
Die Funktion sieht derzeit so aus (Grundgerüst hab ich von jemand anderem hier im Forum übernommen und dann meinen Bedürfnissen angepasst, bzw umgeschrieben):
# Heizungssteuerung mit Profilen
sub setTemp($) {
my ($profil) = @_;
if($profil eq "Komfort"){
fhem( "set .*_Clima controlMode auto" );
fhem( "set wp_Komfort send_to_device Wohnbereich HM_2F8AA7_Clima,HM_2F91A3_Clima,HM_2F95F7_Clima" );
fhem( "set wp_Komfort send_to_device Schlafzimmer HM_2F8A1D_Clima" );
fhem( "set wp_Komfort send_to_device Bad HM_2F8F5A_Clima" );
fhem( "set TelegrammBot message ♨ Heizungsprofil: Komfort eingestellt." );
}
if($profil eq "Früh"){
fhem( "set .*_Clima controlMode auto" );
fhem( "set wp_Fruehschicht send_to_device Wohnbereich HM_2F8AA7_Clima,HM_2F91A3_Clima,HM_2F95F7_Clima" );
fhem( "set wp_Fruehschicht send_to_device Schlafzimmer HM_2F8A1D_Clima" );
fhem( "set wp_Fruehschicht send_to_device Bad HM_2F8F5A_Clima" );
fhem( "set TelegrammBot message ♨ Heizungsprofil: Frühschicht eingestellt." );
}
if($profil eq "Tag"){
fhem( "set .*_Clima controlMode auto" );
fhem( "set wp_Tagschicht send_to_device Wohnbereich HM_2F8AA7_Clima,HM_2F91A3_Clima,HM_2F95F7_Clima" );
fhem( "set wp_Tagschicht send_to_device Schlafzimmer HM_2F8A1D_Clima" );
fhem( "set wp_Tagschicht send_to_device Bad HM_2F8F5A_Clima" );
fhem( "set TelegrammBot message ♨ Heizungsprofil: Tagschicht eingestellt." );
}
if($profil eq "Spät"){
fhem( "set .*_Clima controlMode auto" );
fhem( "set wp_Spaetschicht send_to_device Wohnbereich HM_2F8AA7_Clima,HM_2F91A3_Clima,HM_2F95F7_Clima" );
fhem( "set wp_Spaetschicht send_to_device Schlafzimmer HM_2F8A1D_Clima" );
fhem( "set wp_Spaetschicht send_to_device Bad HM_2F8F5A_Clima" );
fhem( "set TelegrammBot message ♨ Heizungsprofil: Spätschicht eingestellt." );
}
if($profil eq "Nacht"){
fhem( "set .*_Clima controlMode auto" );
fhem( "set wp_Nachtschicht send_to_device Wohnbereich HM_2F8AA7_Clima,HM_2F91A3_Clima,HM_2F95F7_Clima" );
fhem( "set wp_Nachtschicht send_to_device Schlafzimmer HM_2F8A1D_Clima" );
fhem( "set wp_Nachtschicht send_to_device Bad HM_2F8F5A_Clima" );
fhem( "set TelegrammBot message ♨ Heizungsprofil: Nachtschicht eingestellt." );
}
if($profil eq "Sommer"){
fhem( "set .*_Clima controlMode auto" );
fhem( "set wp_Sommer send_to_device default HM_2F8AA7_Clima,HM_2F91A3_Clima,HM_2F95F7_Clima,HM_2F8A1D_Clima,HM_2F8F5A_Clima" );
fhem( "set TelegrammBot message ♨ Heizungsprofil: Sommer eingestellt." );
}
if($profil eq "Off"){
fhem( "set .*_Clima controlMode manual" );
fhem( "set TelegrammBot message ♨ Heizungsplan wurde deaktiviert. Mode: manual" );
}
}
# //Heizungssteuerung mit Profilen
Hallo,
zuerst mal alles Gute im neuen Jahr 2018.
Wollte gerade mal weekprofile im Zusammenspiel mit einer CCU2 testen, aber irgendwie muss ich da etwas entscheidendes übersehen haben. Mein Fhem hängt sich nach dem Befehl "define <name> weekprofile" komplett auf. In der Oberfläche ist die eingefrorene Seite des weekprofiles noch zu sehen aber das wars auch schon.
Nach einem start des fhem Servers (Raspi3) fährt dieser wieder hoch, das Device weekprofile ist aber nicht mehr vorhanden.
"sudo apt-get install libjson-pp-perl" habe ich nachinstalliert, fhem ist aktuell, der Raspi wurde auch neu gestartet.
Im Log ist folgendes noch zu lesen:
2018.01.03 15:26:17 2: HMCCURPC: Updated devices. Success=56 Failed=0
2018.01.03 15:26:17 1: Perfmon: possible freeze starting at 15:26:14, delay is 3.399
hash- or arrayref expected (not a simple scalar, use allow_nonref to allow this) at ./FHEM/98_weekprofile.pm line 581.
Mit einem List des Device kann ich leider nicht dienen, da ich soweit erst gar nicht komme :(.
Hab ich da noch etwas übersehen?
Klappt das (derzeit) überhaupt nur mit HmIP Komponenten über eine CCU2 (HMCCU; HMCCURPC)?
Es wäre nett wenn mir jemand noch einen entsprechenden Hinweis geben könnte.
Hinweis:
Auch die Anlage über "define <name> weekprofile <MasterDevice>" liefert kein anderes Ergebnis. Versucht habe ich es mit einem HmIP-WTH-2.
Gruß Reinhard
Hallo Rewe2000,
leider kann ich zum Thema CCU2 nicht viel beitragen, da ich keine habe.
Die Änderungen hierzu sind vom Mitglied vocaris. Ggf. ihn mal direkt anschreiben, wenn er hier.
Du benötigst "libjson-perl"!!
Hallo Risiko,
danke für die Antwort, ich habe Fhem gemäß Wiki installiert, da war libjson-perl bereits dabei.
Ich habe die aktuelle Version (2.90-1) auf dem Raspi, sollte eigentlich passen.
Die aktuell im Repository von Fhem enthaltene Version von weekprofile sollte doch eigentlich die CCU2 unterstützen, oder muss ich dazu die "alte" Testversion hier im Forum laden?
Ich werde vocaris bitten, mir hierzu mal einen Tipp zu geben.
Oder gibt es User, welche das Modul zusammen mit einer CCU2 einsetzen?
Gruß Reinhard
Zitat von: Rewe2000 am 03 Januar 2018, 21:55:48
Ich habe die aktuelle Version (2.90-1) auf dem Raspi, sollte eigentlich passen.
Ich habe sogar nur 2.53-1. Welche perl Version verwendest du? Ein einfaches
define test weekprofile geht schon nicht?
Zitat von: Rewe2000 am 03 Januar 2018, 21:55:48
Die aktuell im Repository von Fhem enthaltene Version von weekprofile sollte doch eigentlich die CCU2 unterstützen, oder muss ich dazu die "alte" Testversion hier im Forum laden?
Ja. Wenn du direkt das Repository verwendest oder update in FHEM durchgeführt hast. Aktuell ist Rev. 15568
Im Anhang und morgen per Update eine neue Version (Rev. 15778) mit verbesserter Fehlerbehandlung.
Hallo Risiko,
mit der neuesten Version von weekprofile 15778 stürzt mir Fhem zumindest nicht mehr koplett ab. Das Device weekprofile ist jetzt in fhem zu finden, aber wenn ich den Raum Unsortet betrete, in welchen sich das Device jetzt noch befindet, bekomme ich auf der Fhem Oberfläche folgende Fehlermeldung angezeigt:
test Parameter SyntaxError: JSON.parse: unexpected end of data at line 1 column 1 of the JSON data
Diese Meldung wird im log bei Verbose 2 und 4 jedoch nicht angezeigt.
Klicke ich auf das Device (Zahnrad) kommt folgende Meldung:
fhemweb_weekprofile.js line 551: TypeError: widget.PROFILE is undefined
So wie es mir vorkommt, fehlt hier das Default Profil für das Device, dieses sollte ja eigentlich bei dieser Art der Installation automatisch angelegt werden.
Angelegt habe ich das Device wie folgt:
define test weekprofile
Ich habe Fhem vor einigen Wochen komplett neu auf ein neues Debian Strech Lite (Raspi3), mit der in der WIKI vorgeschlagenen Vorgehensweise https://wiki.fhem.de/wiki/Raspberry_Pi (https://wiki.fhem.de/wiki/Raspberry_Pi) installiert.
Folgende Module habe ich auf meinem Raspi derzeit installiert. Ich kann jedoch auf den ersten Blick nicht erkennen, was da noch fehlen sollte.
libacme-damn-perl 0.08-1 armhf
libalgorithm-c3-perl 0.10-1 all
libalgorithm-diff-perl 1.19.03-1 all
libalgorithm-diff-xs-perl 0.04-4+b2 armhf
libalgorithm-merge-perl 0.08-3 all
libauthen-sasl-perl 2.1600-1 all
libb-hooks-endofscope-perl 0.21-1 all
libcgi-fast-perl 1:2.12-1 all
libcgi-pm-perl 4.35-1 all
libclass-accessor-perl 0.34-1 all
libclass-c3-perl 0.32-1 all
libclass-c3-xs-perl 0.14-1+b1 armhf
libclass-data-inheritable-perl 0.08-2 all
libclass-dbi-abstractsearch-perl 0.07-3 all
libclass-dbi-mysql-perl 1.00-3 all
libclass-dbi-perl 3.0.17-4 all
libclass-factory-util-perl 1.7-3 all
libclass-method-modifiers-perl 2.12-1 all
libclass-singleton-perl 1.5-1 all
libclass-trigger-perl 0.14-1 all
libclass-xsaccessor-perl 1.19-2+b13 armhf
libclone-perl 0.38-2+b1 armhf
libcommon-sense-perl 3.74-2 armhf
libdata-optlist-perl 0.110-1 all
libdatetime-format-builder-perl 0.8100-1 all
libdatetime-format-iso8601-perl 0.08-2 all
libdatetime-format-strptime-perl 1.7200-1 all
libdatetime-locale-perl 1:1.11-1 all
libdatetime-perl 2:1.42-1 armhf
libdatetime-timezone-perl 1:2.09-1+2017c all
libdbd-mysql-perl 4.041-2 armhf
libdbd-sqlite3-perl 1.54-1 armhf
libdbi-perl 1.636-1+b1 armhf
libdbix-contextualfetch-perl 1.03-3 all
libdevel-caller-perl 2.06-1+b4 armhf
libdevel-globaldestruction-perl 0.14-1 all
libdevel-lexalias-perl 0.05-1+b4 armhf
libdevel-stacktrace-perl 2.0200-1 all
libdevice-serialport-perl 1.04-3+b3 armhf
libdigest-hmac-perl 1.03+dfsg-1 all
libdpkg-perl 1.18.24 all
libencode-locale-perl 1.05-1 all
libeval-closure-perl 0.14-1 all
libexception-class-perl 1.42-1 all
libexporter-tiny-perl 0.042-1 all
libfcgi-perl 0.78-2 armhf
libfile-fcntllock-perl 0.22-3+b2 armhf
libfile-listing-perl 6.04-1 all
libfont-afm-perl 1.20-2 all
libforks-perl 0.36-2+b2 armhf
libgd-graph-perl 1.48-2 all
libgd-perl 2.53-3+b1 armhf
libgd-text-perl 0.86-9 all
libhash-merge-perl 0.200-1 all
libhtml-form-perl 6.03-1 all
libhtml-format-perl 2.12-1 all
libhtml-parser-perl 3.72-3 armhf
libhtml-tagset-perl 3.20-3 all
libhtml-template-perl 2.95-2 all
libhtml-tree-perl 5.03-2 all
libhttp-cookies-perl 6.01-1 all
libhttp-daemon-perl 6.01-1 all
libhttp-date-perl 6.02-1 all
libhttp-message-perl 6.11-1 all
libhttp-negotiate-perl 6.00-2 all
libima-dbi-perl 0.35-2 all
libimage-base-bundle-perl 1.0.7-3.2 all
libimage-info-perl 1.39-1 all
libimage-librsvg-perl 0.07-8+b3 armhf
libimport-into-perl 1.002005-1 all
libio-html-perl 1.001-1 all
libio-multiplex-perl 1.16-1 all
libio-socket-inet6-perl 2.72-2 all
libio-socket-ssl-perl 2.044-1 all
libio-string-perl 1.08-3 all
libio-stringy-perl 2.111-2 all
libjson-perl 2.90-1 all
libjson-pp-perl 2.27400-1 all
libjson-xs-perl 3.030-1 armhf
liblingua-en-inflect-perl 1.901-1 all
liblist-moreutils-perl 0.416-1+b1 armhf
liblocale-gettext-perl 1.07-3+b1 armhf
liblwp-mediatypes-perl 6.02-1 all
liblwp-protocol-https-perl 6.06-2 all
libmail-imapclient-perl 3.38-1 all
libmailtools-perl 2.18-1 all
libmodule-implementation-perl 0.09-1 all
libmodule-runtime-perl 0.014-2 all
libmoo-perl 2.002005-1 all
libmro-compat-perl 0.12-1 all
libnamespace-autoclean-perl 0.28-1 all
libnamespace-clean-perl 0.27-1 all
libnet-cidr-perl 0.18-1 all
libnet-dns-perl 1.07-1 all
libnet-http-perl 6.12-1 all
libnet-ip-perl 1.26-1 all
libnet-server-perl 2.008-3 all
libnet-sip-perl 0.808-1 all
libnet-smtp-ssl-perl 1.04-1 all
libnet-ssleay-perl 1.80-1 armhf
libpackage-deprecationmanager-perl 0.17-1 all
libpackage-stash-perl 0.37-1 all
libpackage-stash-xs-perl 0.28-3+b1 armhf
libpadwalker-perl 2.2-2+b1 armhf
libparams-classify-perl 0.013-6+b1 armhf
libparams-util-perl 1.07-3+b1 armhf
libparams-validate-perl 1.26-1 armhf
libparams-validationcompiler-perl 0.23-1 all
libparse-recdescent-perl 1.967013+dfsg-1 all
librole-tiny-perl 2.000005-1 all
librpc-xml-perl 0.80-1 all
libscalar-list-utils-perl 1:1.47-1 armhf
libsocket6-perl 0.27-1+b1 armhf
libspecio-perl 0.33-1 all
libsql-abstract-limit-perl 2:0.14.1-5 all
libsql-abstract-perl 1.81-1 all
libstrictures-perl 2.000003-1 all
libsub-exporter-perl 0.986-1 all
libsub-exporter-progressive-perl 0.001013-1 all
libsub-identify-perl 0.12-2+b1 armhf
libsub-install-perl 0.928-1 all
libsub-name-perl 0.21-1 armhf
libsys-sigaction-perl 0.23-1 all
libterm-readkey-perl 2.37-1 armhf
libtest-fatal-perl 0.014-1 all
libtext-charwidth-perl 0.04-7+b7 armhf
libtext-csv-perl 1.33-2 all
libtext-csv-xs-perl 1.26-1 armhf
libtext-diff-perl 1.44-1 all
libtext-iconv-perl 1.7-5+b8 armhf
libtext-wrapi18n-perl 0.06-7.1 all
libthread-queue-any-perl 1.14-1 all
libtime-piece-mysql-perl 0.06-2 all
libtimedate-perl 2.3000-2 all
libtry-tiny-perl 0.28-1 all
libtypes-serialiser-perl 1.0-1 all
libuniversal-moniker-perl 0.08-7 all
liburi-perl 1.71-1 all
libvariable-magic-perl 0.61-1 armhf
libwww-perl 6.15-1 all
libwww-robotrules-perl 6.01-1 all
libxml-libxml-perl 2.0128+dfsg-1+deb9u1 armhf
libxml-namespacesupport-perl 1.11-1 all
libxml-parser-perl 2.44-2+b1 armhf
libxml-sax-base-perl 1.07-1 all
libxml-sax-expat-perl 0.40-2 all
libxml-sax-perl 0.99+dfsg-2 all
libxml-simple-perl 2.22-1 all
Setze ich verbose auf 4, erhalte ich folgende Meldungen im Log:
2018.01.05 15:07:32 4: WEB: /fhem?cmd.attrglobal%3Dattr%20global%20verbose%204&XHR=1&fwcsrf=csrf_163170332821252&fw_id=500 / RL:20 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2018.01.05 15:07:35 4: Connection closed for WEB_192.168.1.26_51434: EOF
2018.01.05 15:07:35 4: WEB_192.168.1.26_51429 GET /fhem?room=Unsorted; BUFLEN:0
2018.01.05 15:07:35 4: Ignoring unknown_1586C2
...........
2018.01.05 15:07:35 4: Ignoring unknown_1D4EE7
2018.01.05 15:07:35 4: WEB: /fhem?room=Unsorted / RL:4204 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2018.01.05 15:07:35 4: WEB_192.168.1.26_51429 GET /fhem?cmd=get%20test%20profile_data%20default%3Adefault&XHR=1&fwcsrf=csrf_163170332821252; BUFLEN:0
2018.01.05 15:07:35 1: test(Get): invalid profile data - set verbose to 4 to see the data
2018.01.05 15:07:35 4: WEB: /fhem?cmd=get%20test%20profile_data%20default%3Adefault&XHR=1&fwcsrf=csrf_163170332821252 / RL:20 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2018.01.05 15:07:35 4: Connection accepted from WEB_192.168.1.26_51436
2018.01.05 15:07:35 4: WEB_192.168.1.26_51433 POST /fhem?cmd={AttrVal(%22test%22,%22widgetWeekdays%22,%22%22)}&XHR=1&fwcsrf=csrf_163170332821252&fw_id=494; BUFLEN:0
2018.01.05 15:07:35 4: WEB: /fhem?cmd={AttrVal(%22test%22,%22widgetWeekdays%22,%22%22)}&XHR=1&fwcsrf=csrf_163170332821252&fw_id=494 / RL:21 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2018.01.05 15:07:35 4: WEB_192.168.1.26_51436 POST /fhem?cmd={AttrVal(%22test%22,%22widgetTranslations%22,%22%22)}&XHR=1&fwcsrf=csrf_163170332821252&fw_id=494; BUFLEN:0
2018.01.05 15:07:35 4: WEB: /fhem?cmd={AttrVal(%22test%22,%22widgetTranslations%22,%22%22)}&XHR=1&fwcsrf=csrf_163170332821252&fw_id=494 / RL:21 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2018.01.05 15:07:35 4: Connection accepted from WEB_192.168.1.26_51437
2018.01.05 15:07:35 4: WEB_192.168.1.26_51437 POST /fhem?cmd=get%20test%20profile_names%20default&XHR=1&fwcsrf=csrf_163170332821252&fw_id=494; BUFLEN:0
2018.01.05 15:07:35 4: WEB: /fhem?cmd=get%20test%20profile_names%20default&XHR=1&fwcsrf=csrf_163170332821252&fw_id=494 / RL:28 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2018.01.05 15:07:35 4: WEB_192.168.1.26_51429 GET /fhem?cmd=get%20test%20profile_data%20default%3Adefault&XHR=1&fwcsrf=csrf_163170332821252; BUFLEN:0
2018.01.05 15:07:35 1: test(Get): invalid profile data - set verbose to 4 to see the data
2018.01.05 15:07:35 4: WEB: /fhem?cmd=get%20test%20profile_data%20default%3Adefault&XHR=1&fwcsrf=csrf_163170332821252 / RL:20 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2018.01.05 15:07:35 4: WEB_192.168.1.26_51429 GET /fhem?XHR=1&inform=type=status;filter=room=Unsorted;since=1515161254;fmt=JSON&fw_id=494×tamp=1515161257417; BUFLEN:0
2018.01.05 15:07:39 4: Connection closed for WEB_192.168.1.26_51429: EOF
2018.01.05 15:07:39 4: WEB_192.168.1.26_51437 GET /fhem/FileLog_logWrapper?dev=Logfile&type=text&file=fhem-2018-01.log; BUFLEN:0
2018.01.05 15:07:39 4: WEB_192.168.1.26_51437 GET /fhem/FileLog_logWrapper?XHR=1&inform=type=status;filter=;since=1515161258;fmt=JSON&fw_id=503×tamp=1515161261020; BUFLEN:0
2018.01.05 15:07:55 4: BlockingCall (DbLog_PushAsync): created child (21742), uses telnetForBlockingFn_1515154557.89901 to connect back
2018.01.05 15:07:55 4: Connection accepted from telnetForBlockingFn_1515154557.89901_127.0.0.1_39100
2018.01.05 15:08:47 4: Closing inactive connection WEB_192.168.1.26_51436
2018.01.05 15:08:47 4: Closing inactive connection WEB_192.168.1.26_51433
2018.01.05 15:08:54 4: Connection closed for WEB_192.168.1.26_51437: EOF
2018.01.05 15:08:55 4: Connection accepted from WEB_192.168.1.26_51444
2018.01.05 15:08:55 4: WEB_192.168.1.26_51444 GET /fhem?room=Unsorted; BUFLEN:0
2018.01.05 15:08:55 4: WEB: /fhem?room=Unsorted / RL:4204 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2018.01.05 15:08:55 4: WEB_192.168.1.26_51444 GET /fhem?cmd=get%20test%20profile_data%20default%3Adefault&XHR=1&fwcsrf=csrf_163170332821252; BUFLEN:0
2018.01.05 15:08:55 1: test(Get): invalid profile data - set verbose to 4 to see the data
2018.01.05 15:08:55 4: WEB: /fhem?cmd=get%20test%20profile_data%20default%3Adefault&XHR=1&fwcsrf=csrf_163170332821252 / RL:20 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2018.01.05 15:08:55 4: Connection accepted from WEB_192.168.1.26_51445
2018.01.05 15:08:55 4: Connection accepted from WEB_192.168.1.26_51446
2018.01.05 15:08:55 4: WEB_192.168.1.26_51445 POST /fhem?cmd={AttrVal(%22test%22,%22widgetWeekdays%22,%22%22)}&XHR=1&fwcsrf=csrf_163170332821252&fw_id=505; BUFLEN:0
2018.01.05 15:08:55 4: WEB: /fhem?cmd={AttrVal(%22test%22,%22widgetWeekdays%22,%22%22)}&XHR=1&fwcsrf=csrf_163170332821252&fw_id=505 / RL:21 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2018.01.05 15:08:55 4: Connection accepted from WEB_192.168.1.26_51447
2018.01.05 15:08:55 4: WEB_192.168.1.26_51446 POST /fhem?cmd={AttrVal(%22test%22,%22widgetTranslations%22,%22%22)}&XHR=1&fwcsrf=csrf_163170332821252&fw_id=505; BUFLEN:0
2018.01.05 15:08:55 4: WEB: /fhem?cmd={AttrVal(%22test%22,%22widgetTranslations%22,%22%22)}&XHR=1&fwcsrf=csrf_163170332821252&fw_id=505 / RL:21 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2018.01.05 15:08:55 4: WEB_192.168.1.26_51447 POST /fhem?cmd=get%20test%20profile_names%20default&XHR=1&fwcsrf=csrf_163170332821252&fw_id=505; BUFLEN:0
2018.01.05 15:08:55 4: WEB: /fhem?cmd=get%20test%20profile_names%20default&XHR=1&fwcsrf=csrf_163170332821252&fw_id=505 / RL:28 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2018.01.05 15:08:55 4: WEB_192.168.1.26_51444 GET /fhem?cmd=get%20test%20profile_data%20default%3Adefault&XHR=1&fwcsrf=csrf_163170332821252; BUFLEN:0
2018.01.05 15:08:55 1: test(Get): invalid profile data - set verbose to 4 to see the data
2018.01.05 15:08:55 4: WEB: /fhem?cmd=get%20test%20profile_data%20default%3Adefault&XHR=1&fwcsrf=csrf_163170332821252 / RL:20 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2018.01.05 15:08:55 4: WEB_192.168.1.26_51444 GET /fhem?XHR=1&inform=type=status;filter=room=Unsorted;since=1515161334;fmt=JSON&fw_id=505×tamp=1515161336718; BUFLEN:0
2018.01.05 15:08:55 4: BlockingCall (DbLog_PushAsync): created child (21777), uses telnetForBlockingFn_1515154557.89901 to connect back
2018.01.05 15:08:55 4: Connection accepted from telnetForBlockingFn_1515154557.89901_127.0.0.1_39102
2018.01.05 15:09:04 4: Connection closed for WEB_192.168.1.26_51444: EOF
2018.01.05 15:09:04 4: WEB_192.168.1.26_51447 GET /fhem?detail=global; BUFLEN:0
2018.01.05 15:09:04 4: WEB: /fhem?detail=global / RL:4247 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2018.01.05 15:09:04 4: WEB_192.168.1.26_51447 GET /fhem?cmd=%7BAttrVal(%22global%22%2C%22room%22%2C%22%22)%7D&XHR=1&fwcsrf=csrf_163170332821252; BUFLEN:0
2018.01.05 15:09:04 4: WEB: /fhem?cmd=%7BAttrVal(%22global%22%2C%22room%22%2C%22%22)%7D&XHR=1&fwcsrf=csrf_163170332821252 / RL:21 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2018.01.05 15:09:04 4: WEB_192.168.1.26_51447 GET /fhem?XHR=1&inform=type=status;filter=global;since=1515161343;fmt=JSON&fw_id=508×tamp=1515161346227; BUFLEN:0
2018.01.05 15:09:07 4: WEB_192.168.1.26_51445 GET /fhem?cmd=%7BAttrVal(%22global%22%2C%22verbose%22%2C%22%22)%7D&XHR=1&fwcsrf=csrf_163170332821252; BUFLEN:0
2018.01.05 15:09:07 4: WEB: /fhem?cmd=%7BAttrVal(%22global%22%2C%22verbose%22%2C%22%22)%7D&XHR=1&fwcsrf=csrf_163170332821252 / RL:22 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2018.01.05 15:09:11 4: Ignoring HM_4DC29E
........
2018.01.05 15:09:11 4: Ignoring unknown_B71B36
2018.01.05 15:09:11 4: no_DbLogExclude exec attr $EVTPART1 DbLogExclude .*
2018.01.05 15:09:11 4: test(getDeviceType): du_Sonnenaufgang is not supported
.........
2018.01.05 15:09:11 4: test(getDeviceType): HM_EG_TKE1_Wohnzimmer is not supported
2018.01.05 15:09:14 4: WEB_192.168.1.26_51445 POST /fhem?cmd.attrglobal%3Dattr%20global%20verbose%202&XHR=1&fwcsrf=csrf_163170332821252&fw_id=508; BUFLEN:0
Die Meldungen habe ich versucht zu bereinigen, damit die Datenmenge nicht zu viel wird.
Hinweis:
Ich habe nur HmIP Device in Fhem (über CCU2) angemeldet, welche überhaupt Wochenprogramme unterstützen. Es sind keinerlei HM-Device (ohne IP) in Fhem (über CCU2 oder CUL) vorhanden.
Kann dies der Grund für das Verhalten sein?
Ich habe selbst keine Vermutung was es sein könnte, aber leider nicht so viel Ahnung den Fehler selbst zu finden.
Gruß Reinhard
Hallo Rewe2000,
du solltest nur verbose vom device "test" aus 4 (besser gleich mal auf 5) setzen ;) - Bitte mal nachholen.
Ja es sieht so aus, als wenn kein Default-Profile angelegt bzw. gespeichert wird. Fehlen evtl. Schreibrechte im Log-Verzeichnis?
Bis jetzt habe ich es leider noch nicht geschafft diesen Fall nachzustellen.
Hallo Risiko,
so weit bin ich gar nicht gekommen, das Device
test war unter Unsorted nur als Symbol (Zahnräder) und Devicename sichtbar, ein klick darauf brachte folgende Meldung:
ZitatKlicke ich auf das Device (Zahnrad) kommt folgende Meldung:
Code: [Auswählen]
fhemweb_weekprofile.js line 551: TypeError: widget.PROFILE is undefined
So wie es mir vorkommt, fehlt hier das Default Profil für das Device, dieses sollte ja eigentlich bei dieser Art der Installation automatisch angelegt werden.
Somit blieb mir "nur" das Verbose 4 in global.
Heute war jedoch das Device sofort nach dem Anlegen sichtbar und ich konnte hier Verbose 5 setzen.
Der Datenmenge wegen habe ich nahezu gleiche Einträge mit ...... gelöscht.
2018.01.06 13:05:30 1: Perfmon: possible freeze starting at 13:05:28, delay is 2.527
2018.01.06 13:18:25 1: test(Get): invalid profile data - set verbose to 4 to see the data
2018.01.06 13:18:25 1: test(Get): invalid profile data - set verbose to 4 to see the data
2018.01.06 13:18:55 1: test(Get): invalid profile data - set verbose to 4 to see the data
2018.01.06 13:18:55 1: test(Get): invalid profile data - set verbose to 4 to see the data
2018.01.06 13:19:15 4: test(Get): invalid profile data $VAR1 = {
'Thu' => {
'temp' => [
'18.0'
],
'time' => [
'24:00'
]
},
.......
'Wed' => {
'temp' => [
'18.0'
],
'time' => [
'24:00'
]
}
};
2018.01.06 13:19:15 4: test(Get): invalid profile data $VAR1 = {
'Thu' => {
'temp' => [
'18.0'
],
'time' => [
'24:00'
]
},
......
'Wed' => {
'temp' => [
'18.0'
],
'time' => [
'24:00'
]
}
};
2018.01.06 13:19:30 4: test(Get): invalid profile data $VAR1 = {
'Thu' => {
'temp' => [
'18.0'
],
'time' => [
'24:00'
]
},
......
'Wed' => {
'temp' => [
'18.0'
],
'time' => [
'24:00'
]
}
};
2018.01.06 13:19:30 4: test(Get): invalid profile data $VAR1 = {
'Thu' => {
'temp' => [
'18.0'
],
'time' => [
'24:00'
]
},
......
'Wed' => {
'temp' => [
'18.0'
],
'time' => [
'24:00'
]
}
};
2018.01.06 13:21:48 0: Server shutdownDas Device war aber nur dieses einzige Mal mit der Devicemaske sichtbar, jeder weitere klick darauf brachte wieder den o.g. Fehler.
Die Schreibrechte im Log-Verzeichnis sollten eigentlich passen, ich habe diese global für Fhem nochmals mit folgenden Befehlen neu gesetzt.
"sudo usermod -a -G tty pi"
"sudo usermod -a -G tty fhem"
"cd /opt"
"sudo chmod -R a+w fhem"
"sudo addgroup fhem dialout"
"sudo addgroup fhem audio"
"sudo chown -R fhem:dialout /opt/fhem"
Bitte prüfe ob hier noch etwas fehlt, ich denke aber es sollte so passen.
pi@raspberrypi:/opt/fhem $ ls -ls
insgesamt 704
4 drwxrwxrwx 2 fhem dialout 4096 Jan 6 03:11 backup
4 drwxrwxrwx 2 fhem dialout 4096 Dez 7 20:08 cache
4 drwx-wx-wx 2 fhem dialout 4096 Dez 29 2016 certs
224 -rw-rw-rw- 1 fhem dialout 226531 Jan 5 13:13 CHANGED
40 -rw-rw-rw- 1 fhem dialout 39189 Sep 20 19:36 configDB.pm
4 drwxrwxrwx 40 fhem dialout 4096 Dez 29 2016 contrib
4 drwxrwxrwx 3 fhem dialout 4096 Dez 29 2016 demolog
4 drwxrwxrwx 4 fhem dialout 4096 Jun 30 2017 docs
32 drwxrwxrwx 6 fhem dialout 28672 Dez 25 19:58 FHEM
168 -rw-rw-rw- 1 fhem dialout 171903 Jan 3 13:14 fhem.cfg
16 -rw-rw-rw- 1 fhem dialout 15740 Okt 14 21:49 fhem.cfg.demo
140 -rw-rw-rw- 1 fhem dialout 142055 Jan 5 13:13 fhem.pl
4 drwxrwxrwx 2 fhem dialout 4096 Jan 1 00:00 log
36 -rw-rw-rw- 1 fhem dialout 36221 Jan 5 13:13 MAINTAINER.txt
4 -rw-rw-rw- 1 fhem dialout 935 Dez 29 2016 README_DEMO.txt
4 drwxrwxrwx 5 fhem dialout 4096 Jan 5 13:13 restoreDir
4 drwxrwxrwx 2 fhem dialout 4096 Jan 3 13:13 temp
4 drwxrwxrwx 2 fhem dialout 4096 Dez 29 2016 unused
4 drwxrwxrwx 10 fhem dialout 4096 Okt 30 20:33 www
So wie ich es gestern im Log gesehen habe, versucht dein Device automatisiert im Hintergrund, in der Fhem Umgebung Devices zu finden, welche ansprechbar sind:
Zitat2018.01.05 15:09:11 4: test(getDeviceType): du_Sonnenaufgang is not supported
.........
2018.01.05 15:09:11 4: test(getDeviceType): HM_EG_TKE1_Wohnzimmer is not supported
Legt weekprofile dann trotzdem das Default-Profile an, wenn es kein passendes Device findet?
Bisher habe ich keine entsprechenden Kanäle angelegt, kann dies mit der Grund für das Fehlverhalten sein?Ich wüsste aber ehrlich gesagt auch (noch) nicht, wie ich diese über die CCU2 anlegen sollte.
ZitatHinweis:
Bei HomeMatic müssen die Kanäle "Clima" bzw. "_Climate" verwendet werden.
Gruß Reinhard
Zitat von: Rewe2000 am 06 Januar 2018, 14:08:01
Hallo Risiko,
so weit bin ich gar nicht gekommen, das Device test war unter Unsorted nur als Symbol (Zahnräder) und Devicename sichtbar.....
Du kannst doch neben den Zahnrädern auf den Devicenamen klicken und wie gewohnt Attribute einstellen !!!, oder nicht!?
Zitat von: Rewe2000 am 06 Januar 2018, 14:08:01
So wie ich es gestern im Log gesehen habe, versucht dein Device automatisiert im Hintergrund, in der Fhem Umgebung Devices zu finden, welche ansprechbar sind:
Legt weekprofile dann trotzdem das Default-Profile an, wenn es kein passendes Device findet?
Ja. Es wird auch angelegt. Ich verstehe nur leider nicht, warum das Profil nicht in einen Json-String gewandelt werden kann :(
Leider ist es für mich nicht so einfach, genau auf deine libjson-perl Version zu wechseln. Mal schauen, vielleicht kann ich dir morgen mal ein kleines Testprogramm zusenden.
Hallo Risiko,
ZitatDu kannst doch neben den Zahnrädern auf den Devicenamen klicken und wie gewohnt Attribute einstellen !!!, oder nicht!?
Ja du hast recht, wenn ich "nur" auf die "Zahnräder" klicke, kommt die Fehlermeldung:
fhemweb_weekprofile.js line 551: TypeError: widget.PROFILE is undefinedDas Device ist dann verschwunden und es wird erst wieder sichtbar, wenn ich den Raum erneut "betrete".
Klicke ich "nur" auf den Devicenamen, so wird das Device geöffnet so wie es sein soll.
defmod test weekprofile
attr test DbLogExclude .*
attr test room Unsorted
setstate test created
setstate test 2018-01-06 20:04:42 profile_count 1
setstate test 2018-01-06 20:04:42 state createdImmer wenn ich alleine nur den Raum betrete, in welchen sich das Device momentan befindet, wenn ich ein Attribut ändere oder hinzufüge oder wenn ich den Devicenamen anklicke, kommt
nur auf der Fhem Oberfläche und nicht im Log die Fehlermeldung:
test Parameter SyntaxError: JSON.parse: unexpected end of data at line 1 column 1 of the JSON dataIch vermute fast da klappt irgend etwas mit Json nicht bei mir. Gibt es eine Möglichkeit was ich bei mir unter Fhem oder am Raspi direkt testen kann, damit wir das Phänomen bei mir eingrenzen können?
Es muss ja nicht an deinem Device liegen, wenn andere User damit keine Probleme haben.
Meist sitzen die Probleme ca. 50 cm vor dem Bildschirm. ;)
Gruß Reinhard
Hi Risiko,
ich habe immer wieder das Phänomen, dass ich ein Profil an einen meiner Thermostate sende und dann komische Werte ankommen.
Ich nutze hierzu nicht den Button mit dem Pfeil, sondern den set-Befehl, in dem Fall set wp_schlafzimmer send_to_device xxx. Das wird auch gemacht, Thermostat zeigt ein paar CMD an. Irgend eine Idee woher das kommt?
Mein Vorgehen gestern:
Update Fhem, Reboot
$Id: 98_weekprofile.pm 15778 2018-01-04 12:34:56Z Risiko $
Datei lt. Fileattribute: 06.01.2018 10:30:17
Anpassen des weekprofiles
Datei lt. Fileattribut: 06.01.2018 10:44:22
__version__=1.1
entry={"REF":null,"NAME":"Schlafzimmer_Aus","DATA":{"Mon":{"time":["24:00"],"temp":["11.0"]},"Thu":{"temp":["11.0"],"time":["24:00"]},"Sun":{"time":["24:00"],"temp":["11.0"]},"Sat":{"time":["24:00"],"temp":["11.0"]},"Fri":{"temp":["11.0"],"time":["24:00"]},"Wed":{"time":["24:00"],"temp":["11.0"]},"Tue":{"time":["24:00"],"temp":["11.0"]}},"TOPIC":"default"}
entry={"TOPIC":"default","REF":null,"NAME":"Schlafzimmer_Homeoffice","DATA":{"Mon":{"temp":["11.0"],"time":["24:00"]},"Thu":{"time":["20:00","24:00"],"temp":["14.5","16.5"]},"Sun":{"temp":["16.5","11.0"],"time":["07:00","24:00"]},"Wed":{"temp":["12.0"],"time":["24:00"]},"Tue":{"temp":["11.0"],"time":["24:00"]},"Sat":{"time":["07:00","20:00","24:00"],"temp":["16.5","14.5","16.5"]},"Fri":{"temp":["16.5","14.5","16.5"],"time":["07:00","20:00","24:00"]}}}
entry={"REF":null,"NAME":"Schlafzimmer_Arbeit","DATA":{"Mon":{"temp":["11.0"],"time":["24:00"]},"Sun":{"temp":["16.5","11.0"],"time":["07:00","24:00"]},"Thu":{"time":["24:00"],"temp":["12.0"]},"Tue":{"temp":["11.0"],"time":["24:00"]},"Wed":{"time":["24:00"],"temp":["11.0"]},"Fri":{"temp":["14.5","16.5"],"time":["20:00","24:00"]},"Sat":{"temp":["16.5","14.5","16.5"],"time":["07:00","20:00","24:00"]}},"TOPIC":"default"}
entry={"TOPIC":"default","NAME":"Schlafzimmer_Urlaub","DATA":{"Wed":{"time":["07:00","20:00","24:00"],"temp":["16.5","14.5","16.5"]},"Tue":{"time":["07:00","20:00","24:00"],"temp":["16.5","14.5","16.5"]},"Sat":{"time":["07:00","20:00","24:00"],"temp":["16.5","14.5","16.5"]},"Fri":{"time":["07:00","20:00","24:00"],"temp":["16.5","14.5","16.5"]},"Mon":{"time":["07:00","20:00","24:00"],"temp":["16.5","14.5","16.5"]},"Thu":{"temp":["16.5","14.5","16.5"],"time":["07:00","20:00","24:00"]},"Sun":{"temp":["16.5","14.5","16.5"],"time":["07:00","20:00","24:00"]}},"REF":null}
Per set an das Thermostat geschickt:
... Auszug aus List ...
2018-01-06 10:54:01 R_0_tempListSat 07:00 16.5 20:00 14.5 41:20 16.5 24:00 16.5
2018-01-06 10:54:01 R_1_tempListSun 07:00 16.5 20:00 13.5 24:00 16.5
2018-01-06 10:54:01 R_2_tempListMon 05:45 16.5 20:00 13.5 24:00 16.5
2018-01-06 10:54:01 R_3_tempListTue 05:45 16.5 20:00 13.5 24:00 16.5
2018-01-06 10:54:01 R_4_tempListWed 05:45 16.5 20:00 13.5 24:00 16.5
2018-01-06 10:54:01 R_5_tempListThu 05:45 16.5 20:00 13.5 24:00 16.5
2018-01-06 10:54:01 R_6_tempListFri 20:00 14.5 41:20 16.5 24:00 16.5
So sieht master aus, diese Werte sind in der json-Datei nicht enthalten. Zeit 41:20 an Fri + Sat??? Zeitstempel
Eigentlich sollte Profil "Arbeit" aktiv sein. D. h. Mo-Do 11 Grad (Heizung aus)
Mon 00:00-05:45 16.5 °C 05:45-20:00 13.5 °C 20:00-24:00 16.5 °C
Tue 00:00-05:45 16.5 °C 05:45-20:00 13.5 °C 20:00-24:00 16.5 °C
Wed 00:00-05:45 16.5 °C 05:45-20:00 13.5 °C 20:00-24:00 16.5 °C
Thu 00:00-05:45 16.5 °C 05:45-20:00 13.5 °C 20:00-24:00 16.5 °C
Fri 00:00-20:00 14.5 °C 20:00-41:20 16.5 °C 41:20-24:00 16.5 °C
Sat 00:00-07:00 16.5 °C 07:00-20:00 14.5 °C 20:00-41:20 16.5 °C 41:20-24:00 16.5 °C
Sun 00:00-07:00 16.5 °C 07:00-20:00 13.5 °C 20:00-24:00 16.5 °C
Das ist ein List des weekprofiles
Internals:
DEF Heizung_Schlafzimmer_Clima
NAME wp_schlafzimmer
NR 307
NTFY_ORDER 50-wp_schlafzimmer
STATE assigned
TYPE weekprofile
MASTERDEV:
NAME Heizung_Schlafzimmer_Clima
TYPE CUL_HM
PROFILES:
HASH(0x52e1718)
HASH(0x52e2530)
HASH(0x5360d70)
HASH(0x5361478)
HASH(0x5361b40)
READINGS:
2018-01-06 16:32:05 profile_count 5
2018-01-06 16:32:05 state assigned
SNDDEVLIST:
HASH(0x5d4ce30)
HASH(0x5d4cec0)
HASH(0x5d4cf20)
TOPICS:
default
helper:
bm:
weekprofile_Get:
cnt 32
dmx -1000
dtot 0
dtotcnt 0
mTS 07.01. 08:45:27
max 0.00108194351196289
tot 0.0149655342102051
mAr:
HASH(0x41080d8)
wp_schlafzimmer
profile_data
default:master
weekprofile_Notify:
cnt 2182
dmx -1000
dtot 0
dtotcnt 0
mTS 06.01. 16:32:05
max 0.0379369258880615
tot 0.123831748962402
mAr:
HASH(0x41080d8)
HASH(0x227ea78)
weekprofile_Set:
cnt 7
dmx -1000
dtot 0
dtotcnt 0
mTS 07.01. 08:28:08
max 0.000121116638183594
tot 0.000646829605102539
mAr:
HASH(0x41080d8)
wp_schlafzimmer
?
Attributes:
group Wochenprogramme
room HomeMatic
Weiterer Test ...
ich habe nun
-- Profil "Aus" an das Thermostat geschickt:
Diesmal hat Thu eine Zeit die nicht passt. Außerdem sollten alle Tage identisch sein.
R_0_tempListSat 24:00 11.0 2018-01-07 09:01:46
R_1_tempListSun 24:00 11.0 2018-01-07 09:01:46
R_2_tempListMon 05:45 16.5 20:00 13.5 24:00 16.5 2018-01-07 09:01:46
R_3_tempListTue 05:45 16.5 20:00 13.5 24:00 16.5 2018-01-07 09:01:46
R_4_tempListWed 05:45 16.5 20:00 13.5 24:00 16.5 2018-01-07 09:01:46
R_5_tempListThu 27:05 11.0 20:00 13.5 24:00 16.5 2018-01-07 09:01:46
R_6_tempListFri 24:00 11.0 2018-01-07 09:01:46
Hallo kadettilac89,
der master wird nicht gespeichert - liegt ja im assoziiertem Device.
Um zu sehen, was weekprofile ans device sendet, musst du verbose von weekprofile auf 4 setzen. Das solltest du mal beobachten.
Es werden aber nur Änderungen zum Device gesendet!
Was das Device (CUL_HM) daraus macht und welche Readings sich daraus ergeben, kann weekprofile natürlich nicht beeinflussen. Also am Besten mal den tatsächlichen Befehl an das Device mit loggen.
ich logge mal mit verbose und teste noch ein wenig rum.
Wann - bei welchem event - wird "master" aktuallisiert? Kann ich das erzwingen? Thermostat ist mit richtigen Werten aktiv, in master werden immer noch alte Werte angezeigt.
Zitat von: Rewe2000 am 06 Januar 2018, 20:48:13
Ich vermute fast da klappt irgend etwas mit Json nicht bei mir. Gibt es eine Möglichkeit was ich bei mir unter Fhem oder am Raspi direkt testen kann, damit wir das Phänomen bei mir eingrenzen können?
Es muss ja nicht an deinem Device liegen, wenn andere User damit keine Probleme haben.
Meist sitzen die Probleme ca. 50 cm vor dem Bildschirm. ;)
Gruß Reinhard
Hallo Reinhard,
im Anhang ein kleines Testprogramm zum testen. Aufruf perl test_json.pl.
Zitat von: kadettilac89 am 07 Januar 2018, 12:56:42
Wann - bei welchem event - wird "master" aktuallisiert? Kann ich das erzwingen? Thermostat ist mit richtigen Werten aktiv, in master werden immer noch alte Werte angezeigt.
Eigentlich sollte weekprofile das per Notify mitbekommen und das Masterprofil selbständig neu vom Device auslesen. Sendet denn das Device bei Änderung ein Notify? Habe nur MAX und da klappt das prima. Explizit erzwingen kann man das aktuell leider nicht. Kann ich aber bei Gelegenheit mal einbauen.
Nachtrag:
Habe es eingebaut.
Ab morgen kann man mittels
reread_master das erneute auslesen des master Profiles erzwingen.
irgendwie komisch dass es nur eines der Thermostate ist. Events sind da. Werde mal das Thermostat komplett neu einbinden und dann beobachten. Das Verhalten mit den vermischten Temp-List ist aber auch schon an anderen aufgetreten. Verbose ist aktiv, mal abwarten ob es nochmal vorkommt.
DAnke dir für die Unterstützung. Normal schalte ich selten, nur heute aufgefallen da ich geändert hatte und der Heizkörper dennoch warm war.
Schönen Sonntag noch.
Hallo Risiko,
danke für das Testprogramm, ich habe dieses auf meinem Raspi ausgeführt und so wie ich es sehe, sollte es funktioniert haben:
pi@raspberrypi:~/Downloads $ perl test_json.pl
test array: ["Foo","Bar","Baz"]
test hash: {"fname":"Foo","lname":"Bar"}
test hash of arrays: {"Foo Bar":[23,42,73],"Peti Bar":[10,15],"Zorg":[10,20,30,40]}
test profile: {"Fri":{"temp":["18.0"],"time":["24:00"]},"Wed":{"temp":["18.0"],"time":["24:00"]},"Mon":{"temp":["18.0"],"time":["24:00"]},"Tue":{"time":["24:00"],"temp":["18.0"]},"Sat":{"temp":["18.0"],"time":["24:00"]},"Sun":{"temp":["18.0"],"time":["24:00"]},"Thu":{"time":["24:00"],"temp":["18.0"]}}
pi@raspberrypi:~/Downloads $
Gerne führe ich noch weitere Tests bei mir aus, wenn ich dich damit unterstützen kann.
Gruß Reinhard
Hallo,
erstmal vielen Dank für dieses super praktische Tool, funktioniert einfacher als man beim lesen des Wiki vermutet.
Eine von mir gewünschte Einstellung funktioniert leider nicht wie beschrieben.
Wenn ich einen HomeMatic Thermostat auf "ON" stellen möchte, dann wird er auf "OFF" gesetzt.
Setzt man ihn auf "OFF" dann funktioniert das.
userattr "weekprofile" ist gesetzt
Wieso nimmt er die Einstellung "ON" nicht an?
Wäre toll wenn du dir das mal anschauen könntest, da ich während der "Nicht Heizperiode" alle Regler auf "ON" stellen möchte, weil das die Ventile entlastet.
Danke und Gruß
Robert
konnte das Verhalten nachstellen.
Log was an das Thermostat gesendet wird:
2018.01.30 12:38:49.166 3: CUL_HM set Heizung_Wohnzimmer_Clima tempListSun exec 06:00 18.0 07:00 19.0 16:00 on 24:00 off
2018.01.30 12:38:49.153 3: CUL_HM set Heizung_Wohnzimmer_Clima tempListSat prep 06:00 18.0 07:00 19.0 22:00 on 24:00 18.0
2018.01.30 12:38:49.150 3: CUL_HM set Heizung_Wohnzimmer_Clima tempListFri prep 14:00 18.0 17:00 20.5 22:00 on 24:00 18.0
2018.01.30 12:38:49.146 3: CUL_HM set Heizung_Wohnzimmer_Clima tempListWed prep 24:00 off
2018.01.30 12:38:49.144 3: CUL_HM set Heizung_Wohnzimmer_Clima tempListTue prep 24:00 off
2018.01.30 12:38:49.142 3: CUL_HM set Heizung_Wohnzimmer_Clima tempListMon prep 24:00 off
--> Muss noch etwas geändert werden, damit das "off" durch den echten Wert aus dem Attribut getauscht wird? Ein "off" in der TempList wird bei mir als 0.00 °C interpretiert.
--> Noch ein Testergebnis ... Im Dropdown erscheint "on" ganz unten. Ich hatte den Wert 21.5 als on. Ich kann dann im Dropdown keine Werte größer 21.5 auswählen.
Zitat von: treborst am 29 Januar 2018, 22:44:33
Wäre toll wenn du dir das mal anschauen könntest, da ich während der "Nicht Heizperiode" alle Regler auf "ON" stellen möchte, weil das die Ventile entlastet.
Ich gehe davon aus, du sprichst von den Attributen
attr wp_wohnzimmer tempOFF 11
attr wp_wohnzimmer tempON 21,5
Wenn ich das richtig verstehe ist das nur ein Platzhalter für die Temperatur (11 Grad bei mir). Dadurch ist das Thermostat weder abgeschaltet noch verhält es sich anders als wenn du den Wert manuell setzen würdest. Nicht gleichzusetzen mit dem "set <Heizung> off".
Zitatattr wp_wohnzimmer tempOFF 11
attr wp_wohnzimmer tempON 21,5
Wenn ich das richtig verstehe ist das nur ein Platzhalter für die Temperatur (11 Grad bei mir). Dadurch ist das Thermostat weder abgeschaltet noch verhält es sich anders als wenn du den Wert manuell setzen würdest. Nicht gleichzusetzen mit dem "set <Heizung> off".
Ich habe das so verstanden, dass bei "OFF" das Ventil geschlossen wird (Wert 0) und bei "ON" geöffnet wird (Wert 100); d.h. es findet keine Regelung mehr statt, bis ein Wert <> ON/OFF eingestellt wird,
Bin mir relativ sicher dass das so ist, da ich bei 2 Heizkörpern den Wert of "OFF" gesetzt habe und da keine Regelung stattfindet.
Somit müsste nur der Wert "ON" auch übertragen werden.
ZitatNicht gleichzusetzen mit dem "set <Heizung> off".
Was meinst du damit? Den Befehl kenne ich noch nicht.
Grüße
das hast du falsch verstanden.
tempON
Temperature für 'on'. z.B. 30
tempOFF
Temperature für 'off'. z.B. 4
Wenn du ein wenig zurückblätterst siehst du die Diskussion dazu. Der Wunsch war, dass eine Variable gesetzt werden kann und diese im weekprofile ersetzt wird. Eine Variable damit man nicht so viel klicken muss.
Aktuell wird bei OFF der Wert 00.0 gesetzt und du hast immer ein geschlossenes Thermostat ... außer in deinem Wohnzimmer würde die Temp darunter liegen.
Ich vermute, dass Risiko mit der Umsetzung noch nicht ganz fertig ist. Ich habe nicht gesehen, dass er die Funktion als Neuerung kommuniziert hat.
Interessehalber habe ich mal den Sourcecode angesehen und das Modul zum Test etwas angepasst ... wenn man in der Sub noch on/off durch die entsprechenden Werte ersetzt kann man das ans Thermostat senden. Neu die letzten if-Staements. Aber am besten einfach warten :)
##############################################
sub weekprofile_sendDevProfile(@)
{
my ($device,$prf,$me) = @_;
my $type = weekprofile_getDeviceType($me, $device,"SND");
return "Error device type not supported" if (!defined ($type));
return "profile has no data" if (!defined($prf->{DATA}));
my $tempON = AttrVal($me, "tempON", undef);
my $tempOFF = AttrVal($me, "tempOFF", undef);
if ($type eq "WEEKPROFILE") {
my $json = JSON->new;
my $json_text = undef;
eval ( $json_text = $json->encode($prf->{DATA}) );
return "Error in profile data" if (!defined($json_text));
return fhem("set $device profile_data $prf->{TOPIC}:$prf->{NAME} $json_text",1);
}
my $devPrf = weekprofile_readDevProfile($device,$type,$me);
# only send changed days
my @dayToTransfer = ();
foreach my $day (@shortDays){
my $tmpCnt = scalar(@{$prf->{DATA}->{$day}->{"temp"}});
next if ($tmpCnt <= 0);
if ($tmpCnt != scalar(@{$devPrf->{$day}->{"temp"}})) {
push @dayToTransfer , $day;
next;
}
my $equal = 1;
for (my $i = 0; $i < $tmpCnt; $i++) {
if ( ($prf->{DATA}->{$day}->{"temp"}[$i] eq "on" ) && defined($tempON) ) {
$prf->{DATA}->{$day}->{"temp"}[$i] = $tempON;
}
if ( ($prf->{DATA}->{$day}->{"temp"}[$i] eq "off" ) && defined($tempOFF)) {
$prf->{DATA}->{$day}->{"temp"}[$i] = $tempOFF;
}
Hallo zusammen,
ich bin leider aktuell sehr eingespannt und konnte somit noch nicht mit der Umsetzung beginnen.
Steht aber auf der ToDo Liste.
Aktuell sollte On bzw. durch die jeweiligen Werte aus den Attributen ersetzt werden. Je nach Thermostat wird das aber anders interpretiert.
Risiko.
Hallo Risiko,
alles klar, keine Eile, der Sommer ist noch fern :D
Problem erkannt ist schon mal ein gutes Statement.
Ich nutze Homematic HM-CC-RT-DN Thermostate und da funktioniert aktuell nur "OFF"; "ON" wird ebenfalls als "OFF" interpretiert.
Vielen Dank für dein Modul
Gruß
Robert
Zitat von: kadettilac89 am 31 Januar 2018, 21:57:57
Interessehalber habe ich mal den Sourcecode angesehen und das Modul zum Test etwas angepasst ... wenn man in der Sub noch on/off durch die entsprechenden Werte ersetzt kann man das ans Thermostat senden. Neu die letzten if-Staements. Aber am besten einfach warten :)
Ich muss hier nochmal nachhacken.
Aktuell ist es so, dass on und off direkt zum Device gesendet wird. Bei MAX kann man z.B. desiredTemperature on setzen. Wenn das bei HM nicht geht, dann müsste man wirklich on,off durch die entsprechenden Werte ersetzen. Bei MAX ist das jedenfalls nicht notwendig.
Zitat von: treborst am 01 Februar 2018, 23:26:16
Ich nutze Homematic HM-CC-RT-DN Thermostate und da funktioniert aktuell nur "OFF"; "ON" wird ebenfalls als "OFF" interpretiert.
Dann ist das meiner Meinung nach ein Fehler in CUL_HM. Im Log sollte beim Senden (verbose 4) off bzw on richtig stehen.
Zitat von: Risiko am 08 Februar 2018, 20:25:30
Ich muss hier nochmal nachhacken.
Aktuell ist es so, dass on und off direkt zum Device gesendet wird. Bei MAX kann man z.B. desiredTemperature on setzen. Wenn das bei HM nicht geht, dann müsste man wirklich on,off durch die entsprechenden Werte ersetzen. Bei MAX ist das jedenfalls nicht notwendig.
Ich konnte das Verhalten von treborst reproduzieren - off wird mit Temperatur 0.0 °C zurückgeliefert obwohl on gesetzt wurde.
Verständnisfrage, welches Verhalten ist gewünscht bzw. vorgesehen?
on = weekprofileparameter tempON
off = weekprofileparameter tempOFF
ODER
on = <HM-Heizkörper>-R-dayTemp
off = <HM-Heizkörper>-R-nightTemp
---> hier auch Antwort auf deine Frage: Ja, HM unterstützt auch ein on/off. Die R-**Temp-Werte sollten dann intern verwendet werden.
Ich ging davon aus, dass die Werte aus weekprofile tempON/OFF ersetzt und gesetzt werden sollten, darum hab ich im Modul die Werte ersetzt. Es gab vor kurzem eine Diskussion genau in die Richtung. Wenn nicht, wofür sind die Parameter?
... ich denke dass noch irendwo eine Abfrage was anderes zurückliefert o. ä. vielleicht auch weil HM ggf. anders reagiert als MAX.
Wenn du mir sagst, welches Verhalten du einbauen möchtest kann ich am Wochenende nochmal testen und schaun ob ich was finde.
EDIT: ich glaube ich weiß was das Verhalten verursacht.
Man kann zwar set desired-temp on / off setzen. - OK so weit. Da bleibt auch der Wert mit on/off im Device.
ABER
wenn man die Templiste mit on setzen will wird 00.0 als Temperatur gesetzt.
set <heizkörper>_Clima tempListWed 24:00 on
wird so gespeichert: R_4_tempListWed 24:00 00.0
Mit der Temperatur 00.0 kann dein Master-weekprofile natürlich nichts mehr anfangen. Ob nun das CUL_HM fehlerhaft ist, oder der Thermostat einfach nur numerische Werte akzeptiert weiß ich nicht.
Zitat von: kadettilac89 am 08 Februar 2018, 22:00:51
set <heizkörper>_Clima tempListWed 24:00 on
wird so gespeichert: R_4_tempListWed 24:00 00.0
Mit der Temperatur 00.0 kann dein Master-weekprofile natürlich nichts mehr anfangen. Ob nun das CUL_HM fehlerhaft ist, oder der Thermostat einfach nur numerische Werte akzeptiert weiß ich nicht.
Das ist meiner Meinung nach genau das Problem. Bei MAX sind on=30.5 und off=4.5.
Aktuell sind die Attribute tempOff bzw. tempOn primär für die FHEMWEB-GUI. Zwischen diesen Werten wird in 0.5° die Dropdownlist gefüllt. Im Wochenplan stehen nicht die Werte sondern off bzw. on und es wird auch on\off gesendet.
Da es bei MAX egal ist, ob man off oder <= 4.5 sendet würde ich jetzt zur Vereinheitlichung doch on/off durch die entsprechenden Werte ersetzen und dann die Werte ans Thermostat senden. Beim Lesen dann natürlich anders herum.
Anbei eine Version zum testen wo das so umgesetzt sein sollte.
Risiko
EDIT: Neue Version angehangen
Test sieht schon mal gut aus..
Paramter im Thermostat
tempOFF 5
tempON 29
Ausgangssituation
Tue 00:00-24:00 11.0 °C
Werte neu gesetzt und gespeichert
Tue 00:00-10:00 11.0 °C 10:00-14:00 off °C 14:00-16:00 11.0 °C 16:00-20:00 on °C 20:00-24:00 off °C
Nachdem Thermosat Befehle abgearbeitet hatte
R_3_tempListTue 10:00 11.0 14:00 05.0 16:00 11.0 20:00 29.0 24:00 05.0
Anzeige master
Tue 00:00-10:00 11.0 °C 10:00-14:00 0off.0 °C 14:00-16:00 11.0 °C 16:00-20:00 on.0 °C 20:00-24:00 0off.0 °C
Sobald der master-Heizplan aktuallisiert wurde, wird on / off als 0off.0 oder on.0 angezeigt. ... vermutlich durch regex beim Ersetzen.
Noch eine Frage, ist es gewollt, dass im Temperatur-Dropdown die Werte genau von ON - OFF auswählbar sind? Für den FAll, dass ON auf 21 °C gesetzt wird ist es nicht möglich eine höhere Temperatur einzutragen. Z. B. höhere Temperatur für eine halbe Stunde am Morgen.
Hallo kadettilac89,
danke fürs testen.
Zitat von: kadettilac89 am 10 Februar 2018, 11:57:53
Sobald der master-Heizplan aktuallisiert wurde, wird on / off als 0off.0 oder on.0 angezeigt. ... vermutlich durch regex beim Ersetzen.
Verstehe ich leider nicht. Wie sehen denn die Readings vom Device aus?
Zitat von: kadettilac89 am 10 Februar 2018, 11:57:53
Noch eine Frage, ist es gewollt, dass im Temperatur-Dropdown die Werte genau von ON - OFF auswählbar sind? Für den FAll, dass ON auf 21 °C gesetzt wird ist es nicht möglich eine höhere Temperatur einzutragen. Z. B. höhere Temperatur für eine halbe Stunde am Morgen.
Das kommt aus der Philosophie von MAX.
Alle größeren Werte als On (bei MAX 30.5) werden so on (30.5) reduziert. Bei Off (4.5) alles was kleiner ist. Daher kann man ein MAX nur Werte in diesem Bereich setzen. Deshalb ist es so umgesetzt. On bzw. begrenzen also den Wertebereich. Das ist doch beim HM auch so, oder?
Zitat von: Risiko am 10 Februar 2018, 12:53:39
Hallo kadettilac89,
danke fürs testen.
gerne
Zitat von: Risiko am 10 Februar 2018, 12:53:39
Verstehe ich leider nicht. Wie sehen denn die Readings vom Device aus?
Ich teste hier "Schweinereien". Ich habe als ON / OFF ganze Gradwerte gesetzt. Ohne dem Punkt und der dezimalen Null.
5 statt 5.0
Dadurch hat Regex dann nicht alles ersetzt. Du könntest beim speichern des Attributes ggf. immer .0 anhängen wenn es eine ganze Zahl ist. Damit sollte es dann funktionieren.
Zitat von: Risiko am 10 Februar 2018, 12:53:39
Das kommt aus der Philosophie von MAX.
Alle größeren Werte als On (bei MAX 30.5) werden so on (30.5) reduziert. Bei Off (4.5) alles was kleiner ist. Daher kann man ein MAX nur Werte in diesem Bereich setzen. Deshalb ist es so umgesetzt. On bzw. begrenzen also den Wertebereich. Das ist doch beim HM auch so, oder?
Das ist bei HM genau so ... denke ich. Ich meine es anders.
Beispiel.
tempOFF 17 .... wäre die Temperatur für Abwesenheit
tempON 21 .... wäre die Temperatur für Anwesenheit
Im Dropdown ist dann nur OFF, 17.5, 18.0, 18.5, 19.0, 19.5, 20.0, 20.5, ON
Es ist aber nicht möglich z. B. 24 zu setzen. Kommt aus der fhemweb_weekprofile.js, da setzt du bei Zeile 567 den min- und maxwert auf die beiden Temperaturen aus dem Parameter. Das sind dann die Begrenzer in Schleife 584.
Das wäre hinderlich wenn das Bad den ganzen Tag auf 21 Grad sein soll, nur morgens für eine halbe Stunde auf 24 wenn die Kinder drin sind. Ich würde den Bereich auf 4.5 - 30.5 (Maximum) belassen, und zusätzlich am Anfang OFF einfügen, am Ende noch ON.
Zitat von: kadettilac89 am 10 Februar 2018, 13:18:01
Du könntest beim speichern des Attributes ggf. immer .0 anhängen wenn es eine ganze Zahl ist. Damit sollte es dann funktionieren.
Kann ich machen.
Zitat von: kadettilac89 am 10 Februar 2018, 13:18:01
Ich meine es anders.
Beispiel.
tempOFF 17 .... wäre die Temperatur für Abwesenheit
tempON 21 .... wäre die Temperatur für Anwesenheit
Dafür waren die Attribute nie gedacht! Sondern für den Wertebereich entsprechend der Thermostate. Ggf. werde ich weitere Variablen einführen. Ist hier ja schonmal diskutiert worden.
kurze Frage. Nutzt jemand das attr "widgetEditOnNewPage"
wenn ich das gesetzt habe, kann ich das Profil nicht mehr ändern. Habe jetzt lange gesucht, und festgestellt, das es nur daran liegt.
Ich habe es jetzt noch mal auf einem anderen System getestet. Mit dem gleichen Ergebnis. Auf das Zahnrad klicken -> Temperatur ändern -> speichern, und alles ist wie es war. Ich meine das hat schon mal funktioniert.
LG Tom
Hallo Risiko, Hallo kadettilac89,
habe die Diskussion, welche um meine Frage entstanden ist, mit Interesse verfolgt-
Leider ist der Ausgang nicht in meinem Sinne, da ich die Funktion "Temp_ON"/"Temp_OFF" anders verstehe als es jetzt umgesetzt wurde.
Nach meinem Verständnis hat "ON" bzw "OFF" nichts mit einer Temperatur zu tun, sondern soll die Ventilstellung dauerhaft auf "ON" (100%) bzw. "OFF" (0%) stellen.
Für das von kadettilac89 beschriebene Szenario gibt es die Register "R-nightTemp" und "R-dayTemp"; diese Voreinstellungen lassen sich beliebig nach unten oder oben korrigieren.
Bis zu meiner Anfrage hat es ja auch schon "zur Hälfte" funktioniert, die Vorgabe "OFF" wurde richtig umgesetzt, das Ventil ist dauerhaft geschlossen.
Nur der Wert "ON" wurde im Thermostat falsch gesetzt (OFF statt ON)
Mit der jetzigem Umsetzung wird der im Userattribut "weekprofile" hinterlegte Wert für ON bzw. OFF (bei mir 4 bzw. 34) im Thermostat eingetragen.
Die Einstellung des Ventils bleibt aber weiterhin auf "OFF" also 0% unabhängig vom geforderten Wert (OFF/ON)
Mit der Umsetzung dass ich für "ON/OFF" einen unteren bzw. oberen Wert definieren muss, kann ich leben (auch wenn das für ein HomeMatic Thermostat nicht nötig sein sollte).
Aber bitte setzt es so um, dass bei "ON" das Ventil zu 100% geöffnet ist.
Das Modul "Weekprofile" ist für mich eine lang gesuchte Lösung, da mir der Umgang mit den HM_Info Templates zu umständlich war und ich nach einer Umsetzung mit GUI lange gesucht habe.
Deshalb ist es mir wichtig, dass wegen unterschiedlicher Ansichten vorhandene Funktionen nicht "verbogen" und damit nicht mehr brauchbar werden.
Freue mich auf den Fortgang der Diskussion.
Grüße
Robert
Zitat von: Tom_S am 15 Februar 2018, 22:31:17
kurze Frage. Nutzt jemand das attr "widgetEditOnNewPage"
wenn ich das gesetzt habe, kann ich das Profil nicht mehr ändern. Habe jetzt lange gesucht, und festgestellt, das es nur daran liegt.
Ich habe es jetzt noch mal auf einem anderen System getestet. Mit dem gleichen Ergebnis. Auf das Zahnrad klicken -> Temperatur ändern -> speichern, und alles ist wie es war. Ich meine das hat schon mal funktioniert.
LG Tom
Hallo Tom,
ich schaue es mir bei Gelegenheit mal an.
Zitat von: treborst am 16 Februar 2018, 17:40:34
Mit der jetzigem Umsetzung wird der im Userattribut "weekprofile" hinterlegte Wert für ON bzw. OFF (bei mir 4 bzw. 34) im Thermostat eingetragen.
Die Einstellung des Ventils bleibt aber weiterhin auf "OFF" also 0% unabhängig vom geforderten Wert (OFF/ON)
Hier unterscheiden sich leider HM und MAX. Da bei MAX Temperaturen <= OFF (4.5°) Ventil zu und Tempertauren >=on (30.5) Ventil 100% auf bedeutet, habe ich kürzlich eben statt on/off zu senden auf die korrespondierenden Temperaturen umgestellt. Für MAX ergibt sich da keine Änderung. Das heißt also, wenn man bei HM eine Temperatur kleiner als R-nightTemp sendet, geht das Ventil nicht automatisch auf Off?
Zitat von: treborst am 16 Februar 2018, 17:40:34
Bis zu meiner Anfrage hat es ja auch schon "zur Hälfte" funktioniert, die Vorgabe "OFF" wurde richtig umgesetzt, das Ventil ist dauerhaft geschlossen.
Nur der Wert "ON" wurde im Thermostat falsch gesetzt (OFF statt ON)
Das "zur Hälfte" ist eine Fehlinterpretation.
Risiko kann mit dem Weekprofile nur setzen was das Thermostat auch zulässt. Kannst selber testen, setze die Templist für einen Tag mal an auf "on" und auch mal auf "off". Egal was gesetzt ist, wird 00.0 eingetragen. Das ist ein Initialwert oder Dummy weil das Thermostat nicht weiß was du willst.
Beispiele
set Heizung_Clima tempListSat 06:00 18.0 07:00 19.0 16:00 21.5 24:00 on
set Heizung_Clima tempListSat 06:00 18.0 07:00 19.0 16:00 21.5 24:00 off
wird beide Male zu "R_0_tempListSat
06:00 18.0 07:00 19.0 16:00 21.5 24:00 00.0".
Als Workaround hat Risiko nun auf die Attribute tempON und tempOFF zurück gegriffen. Dein gewünschtes Verhalten sollte aber mit 4 bzw. 30 als Attribut erreichbar sein.
Bei 4 bleibt das Thermostat zu. Bei 30 wird es offen bleiben solange die Temperatur in deinem Zimmer darunter liegt.
Zitat von: Tom_S am 15 Februar 2018, 22:31:17
kurze Frage. Nutzt jemand das attr "widgetEditOnNewPage"
wenn ich das gesetzt habe, kann ich das Profil nicht mehr ändern. Habe jetzt lange gesucht, und festgestellt, das es nur daran liegt.
Ich habe es jetzt noch mal auf einem anderen System getestet. Mit dem gleichen Ergebnis. Auf das Zahnrad klicken -> Temperatur ändern -> speichern, und alles ist wie es war. Ich meine das hat schon mal funktioniert.
LG Tom
Also ich konnte kein Fehler feststellen. Allerdings kann es sein, dass beim "Rückspringen" auf die vorherige Seite vor der Bearbeitung, die Seite aus dem Browser Cache (also die 'alte' Seite) dargestellt wird. Hier hilft ein Reload.
Ich habe einen kleinen Fix eingebaut, welchen den "HTTP-Referrer" verwendet, falls er gesetzt ist.
Browser Cache kann ich ausschließen. Es wir ja auch nichts an's Thermostat gesendet. Ich verwende MAX. Auf der gleichen Seite geht es, nur mit "widgetEditOnNewPage" wird nichts geändert. csrf-Token ist an. Funktioniert aber auch nicht ohne.
Ich gehe davon aus, das es bei dir funktioniert.
LG Tom
Also ich kann wie gesagt kein Fehler feststellen.
Stelle doch mal bitte verbose vom Weekprofile auf 4 und schaue im Log, was an das Thermostat bei "Speichern" gesendet wird.
also wenn attr "widgetEditOnNewPage" 0 ist dann wird
2018.02.20 16:59:24 4: weekp_Thermostat_1(sendDevProfile): set Thermostat_1 weekProfile Mon 17.0,06:00,17.5,07:20,17.0,14:00,22.0,20:30,19.0,23:50,17.0
2018.02.20 16:59:24 4: weekp_Thermostat_1(Notify): reread master profile from Thermostat_1
gesendet.
und wenn attr "widgetEditOnNewPage" 1 ist, wird nichts gesendet.
LG Tom
Hmm. Kann ich leider nicht nachvollziehen. Welche Browser verwendest du?
hallo Risiko
ich verwende Firefox Quantum 58.02 64bit (Ubuntu, Mint, Debian).
Geht aber auch von iPhone mit Safari oder Firefox nicht.
Und gerade getestet - Windows mit IE das gleiche.
Hat wohl irgendwann mal funktioniert. Auf der gleichen Seite geht es ja.
LG Tom
Hallo,
ich hatte das gleiche Problem wie Rewe2000 (https://forum.fhem.de/index.php/topic,46117.msg742961.html#msg742961). Auf meinem RPI3 mit Debian Stretch funktionierte das weekprofile Widget nicht.
Ich habe dann hier https://forum.fhem.de/index.php/topic,76842.msg687580.html#msg687580 eine Lösung "geklaut" und das Modul 98_weekprofile.pm an 6 Stellen angepasst
my $json = JSON->new;
geändert in
my $json = JSON->new->allow_nonref;
Jetzt gibt es keine JSON-Fehler mehr und Laden und Speichern der Wochenprofile geht wieder.
Vielleicht hilft es ja jemanden.
Gruß
Matthias
Hallo mattes66,
vielen Dank.
Anbei mal eine Version mit der Änderung. Ich konnte keine Probleme feststellen.
Weiß jemand, ob das auch mit älteren Perlversionen funktioniert?
Risiko
Moin,
erstmal vielen Dank an Risiko für dieses geniale Modul!
Hab jetzt auch damit meine Wochenpläne für die Homematic Wandthermostate umgesetzt, vorher hatte ich eine Eigenkreation am laufen, die die Thermostate zur gegebenen Zeit im Manuellen Modus geschaltet hat.
Die Nachteile waren halt, dass man am Thermostat nicht sehen konnte, wann die nächste Änderung stattfindet und dass bei einem zeitweisen Ausfall von fhem keine Umschaltung mehr stattfindet.
Was mich jedoch beim Wochenprofil ein bischen gestört hat, waren die Datenmengen beim Umschalten der Topics, daher habe ich 98_weekprofile.pm so angepasst, dass nun die 3 Programme genutzt werden, die der Wandthermostat unterstützt.
Wenn ich also einen Topic anwende, schaltet weekprofile nun das aktive Programm des Wandthermostaten um und aktualisiert nur die entsprechenden Register, falls sie nicht übereinstimmen.
Dadurch kann ich mir einige Overloads ersparen und das Umschalten der Profile geht auch schneller.
Da ich das sehr praktisch finde, wollte ich das hier mal teilen. Sicher ist der Ansatz noch ausbaufähig, zu beachten ist z.B. dass dies nur bei den Wandthermostaten funktioniert (HM-TC-IT-WM-W-EU), da die Heizkörperthermostate leider nur über ein Profil verfügen. Im Mischbetrieb wird das wahrscheinlich zu fehlern führen, das habe ich nicht berücksichtigt, da müsste man vor dem Senden prüfen, um welches Modell es sich handelt und entsprechend unterschiedlich reagieren.
Um das ganze nutzen zu können, müssen für die Topics, die umgelagert werden sollen, Userattribute im weekprofile angelegt werden.
Beispiel:
attr S_Heizung_WochenProfil userattr Urlaub Sommer
attr S_Heizung_WochenProfil Sommer 3
attr S_Heizung_WochenProfil Urlaub 2
Das bewirkt, dass für die Topic Sommer immer das Programm 3 genutzt wird und für das Topic Urlaub das Programm 2.
Alle anderen Topics nutzen Programm 1, wie gewohnt. Mehrfache Belegungen für 2 und 3 sind auch möglich.
Meine angepasste Datei habe ich angehängt, die Änderungen sind jeweils #Svenchange start/end markiert.
Viele Grüße
Sven
Erstmal Danke für das tolle Modul.
Habe meine Homematic Thermostate damit versorgt und es funktioniert einwandfrei.
3 Thermostate habe ich über das Homematic Wandthermostat (HM-TC-IT-WM-W-EU) gesteuert und frage mich gerade ob das jemand schon für die Device am laufen hat.
Bisher habe ich ein weekprofile pro Device angelegt.
Wie funktioniert das mit dem Wandthermostat?
Kann mir jemand weiter helfen?
Danke AlexD_76,
vielen Dank.
Ich schaue es mit bei Gelegenheit an und überlege, ob ich es übernehme.
Eigentlich wollte ich nicht so viel Device spezifische Sachen einbauen, zumal ich es wegen fehlender Hardware nicht wirklich supporten kann.
Ich melde mich wieder.
Hallo AlexD_76,
so ganz kompatibel scheint mir das nicht zu sein. Es sieht für mich so aus, als wenn das jetzt nur noch für dieses spezielle Thermostat funktioniert.
Es müsste zumindest im Default-Fall Profilselect auf undefined stehen und das "alte" Verhalten erhalten bleiben!
So kann ich es leider nicht einfach aufnehmen, zumal ich es nicht testen kann.
Vielleicht könntest du deine Version noch etwas überarbeiten?
Wie viele wären dann an so einer Lösung (das Thermostat unterstützt selbst mehrere Profile) interessiert?
Oh, da hast du Recht, in Zeile 32 wird Profilselect auf "3" gesetzt, das sollte "1" sein, dann sollte das Verhalten gleich sein wie vor meiner Änderung.
Zitat von: Risiko am 15 April 2018, 14:13:40
Wie viele wären dann an so einer Lösung (das Thermostat unterstützt selbst mehrere Profile) interessiert?
Wäre toll wenn Du das machen könntest.
Mir ist noch was aufgefallen.
Ich habe 7 HM Heizungsthermostate und für alle habe ich das Modul eingebunden.
Wenn ich die Werte anpassen will, dann wird das selten durchgeführt.
Beim ändern von einen Wert geht es öfter; beim ändern von mehreren Werten kaum.
Habe noch keine Logik entdecken können wann es geht bzw. nicht geht.
Ändere ich einen Wert, dann muss ich ihn ein paarmal ändern bevor die Änderng an das Thermostat geschickt wird.
Hallo zusammen,
ich finde die Wochenprofilverwaltung gut, aber meine Heizkörperthermostate sind nicht kompatibel zu weekprofile (Comet DECT an einer Fritzbox).
Die Steuerung der Thermostate würde ich aber gerne aus der Fritzbox nach FHEM verlagern. Erreichen kann ich sie schon (über FBDECT).
Meine Frage: Kann weekprofile an jedem Schaltzeitpunkt ein event auslösen, welches ich dann mit notify fangen und an den Heizkörper senden kann?
Würde weekprofile für alle Heizkörper- (oder Lichtsteuerungen, 'Temperatur' dann als z. B. dim-Wert) etc. als Basis erlauben.
event-Struktur etwa:
2018-09-01 14:38:33 weekprofile <device> <Profilname> <ab jetzt gültige Temperatur>
Wäre echt super.
Vielen Dank
db0b23b
Schon mal Heating_Control probiert?
https://fhem.de/commandref_DE.html#Heating_Control
Zitat von: db0b23b am 01 September 2018, 14:44:43
Hallo zusammen,
Meine Frage: Kann weekprofile an jedem Schaltzeitpunkt ein event auslösen, welches ich dann mit notify fangen und an den Heizkörper senden kann?
db0b23b
Hallo db0b23b,
dafür war und ist weekprofile nicht vorgesehen. Das sollten schon die Devices selbst machen.
Ggf. kann man über eine Unterstützung von Heating Control nachdenken.
Risiko
Ich bin der Meinung, die Heizungssteuerung sollte nicht FHEM (oder eine andere Zentrale) übernehmen, sondern die sollte so "nah" wie möglich am Thermostat erfolgen. Fhem "darf" durchaus Temperaturprofile erstellen und an das Thermostat senden oder auch mal in einem Sonderfall überschreiben (zum Beispiel eine Feier) aber wenn fhem die komplette Steuerung übernimmt hieße ein Ausfall der Zentrale, dass es in der Wohnung kalt (oder warm) bleibt...
Ronny
Gesendet von meinem SM-G935F mit Tapatalk
Zitat von: RoBra81 am 02 September 2018, 18:45:42
Ich bin der Meinung, die Heizungssteuerung sollte nicht FHEM (oder eine andere Zentrale) übernehmen, sondern die sollte so "nah" wie möglich am Thermostat erfolgen. Fhem "darf" durchaus Temperaturprofile erstellen und an das Thermostat senden oder auch mal in einem Sonderfall überschreiben (zum Beispiel eine Feier) aber wenn fhem die komplette Steuerung übernimmt hieße ein Ausfall der Zentrale, dass es in der Wohnung kalt (oder warm) bleibt...
Ronny
Gesendet von meinem SM-G935F mit Tapatalk
Da hast Du recht. Leider unterstützten die FritzBox und die Fritz!Dect Thermostate es nicht. Man kann zwar Wochenprofile in der Fritzbox einstellen, aber die stehen nicht in der API zur Verfügung, und sind dann nicht mit FHEM steuerbar.
Vielen Dank, ich schaue mir mal Heating_Control an und wie das mit einer einfachen Rückfallsteuerung (reine Nachtabsenkung) in der FritzBox harmoniert.
db0b23b
Zunächst mal danke für das tolle Modul!
Ich habe aber leider ein Problem dabei, meine MAX-Thermostate per weekprofile auf "off" (=4.5°C) zu setzen, da ich beim setzen des Profils immer die Fehlermeldung
Zitatweekprf error restore topic 'Invalid temperature (Must be one of: off|on|5|5.5|6|6.5..30) '
erhalte.
Mein weekprofile widget definiere ich so:
define weekprf weekprofile
attr weekprf room MAX
attr weekprf tempOFF 4.5
attr weekprf tempON 30.5
attr weekprf useTopics 1
Und zum Testen habe ich einen denkbar simplen Wochenplan :D
{
"Sun":{"time":["24:00"],"temp":["off"]},
"Mon":{"temp":["off"],"time":["24:00"]},
"Wed":{"temp":["off"],"time":["24:00"]},
"Sat":{"temp":["off"],"time":["24:00"]},
"Thu":{"time":["24:00"],"temp":["off"]},
"Fri":{"time":["24:00"],"temp":["off"]},
"Tue":{"temp":["off"],"time":["24:00"]}
}
Jemand eine Idee?
Vielen Dank!
Zitat von: Vrob01 am 13 September 2018, 12:46:17
...
weekprf error restore topic 'Invalid temperature (Must be one of: off|on|5|5.5|6|6.5..30) '
...
...
attr weekprf tempON 30.5
...
Bin nicht sicher, da ich kein MAX einsetze, aber die Fehlermeldung hat als letzten Wert 30, Du definierst tempON mit 30.5!
Setz da mal 30 ein
Gruß Heiko
Das habe ich schon probiert, dann setzt er die Temperatur zwar korrekt auf 30.0°C (oder 5°C), aber eben nicht auf on/off. Bei MAX sind die Werte 4.5°C und 30.5°C spezielle Werte mit denen die Thermostate dauerhaft auf 0% bzw. 100% Öffnung gesetzt werden können
Hallo Risiko,
die Winterzeit geht wieder los :)
Also ich habe mein Fhem auf den aktuellen Stand gebracht und auch festgestellt das du einige Anpassungen im Skript vorgenommen hast u.A. ist auch die Zeile verschwunden die mir damals immer eine Fehlermeldung ausgeworfen hat.
(Raspberry PI + HomeMatic Gateway)
Nun jetzt habe ich die Tage mein Wintermodus (Arbeit) aktiviert.
Allerdings fällt mir wieder auf das wie auch bei Soc nicht alle Thermostate bzw. Wandthermostate auf einen Schlag die Daten bekommen.
Sondern das ich den Button "Restore topic: 'Arbeit' " alle x Minuten mal drücken muss bis alle Daten übertragen wurden.
Hallt dann wenn ich sehe, das im Event Monitor nicht mehr passiert.
Sicherlich kennst du das Problem schon. Hast du dafür eine Begründung?
Hast du einen Vorschlag um das Problem zu unterbinden?
Auch wenn ich in jedem Datensatz die 23° auf 24° ändere, also nicht ein komplett anderes Profil lade, benötige ich mehrere Anläufe.
Ich habe in meinem Profil Arbeit, 10 Sub Profile.
Arbeit
EG_Bad --> (1x HomeMatic Thermostat)
EG_Buero --> (1x HomeMatic Thermostat + 1x HomeMatic Wandthermostat)
EG_Flur --> (HomeMatic Thermostat + 1x HomeMatic Wandthermostat)
EG_WohnEsszimmer --> (2x HomeMatic Thermostat + 1x HomeMatic Wandthermostat)
KG_Bad --> (1x HomeMatic Thermostat)
OG_Bad_HK1 --> (1x HomeMatic Thermostat)
OG_Bad_HK2 --> (1x HomeMatic Thermostat)
OG_Gaestezimmer --> (1x HomeMatic Thermostat + 1x HomeMatic Wandthermostat)
OG_Kinderzimmer --> (1x HomeMatic Thermostat + 1x HomeMatic Wandthermostat)
OG_Schlafzimmer --> (1x HomeMatic Thermostat + 1x HomeMatic Wandthermostat)
Mit je etwa 5 Zeiten/Temperaturen pro Tag.
Bei allen Thermostaten ist das Attribut hinterlegt, so das auf denen die Profile geladen werden sollen. (Siehe auch cfg Datei im Anhang.)
#### Nachtrag:
Ok ich habe mal die Logs durchgeschaut: MUARTLGW HomeMaticLGW: queue is full, dropping packet
Also ist das Problem, das es zu viele Daten auf einmal sind. Könnte man nicht dann im Skript eine Wait Logik bauen, die dann immer ein Paar Datensätze überträgt übermittelt und dann nach einer Einstellbaren Zeit die nächsten Datensätze losschickt?
Das würde doch das Problem aushebeln.
Liber soll es 10 oder 20 Minuten die einzelnen abarbeiten, als das man ab und an nachschauen muss ob alle Daten übermittelt wurden.
Wäre das kein Lösungsansatz?
######
Zitat von: Soc am 23 April 2018, 16:24:16
Wäre toll wenn Du das machen könntest.
Mir ist noch was aufgefallen.
Ich habe 7 HM Heizungsthermostate und für alle habe ich das Modul eingebunden.
Wenn ich die Werte anpassen will, dann wird das selten durchgeführt.
Beim ändern von einen Wert geht es öfter; beim ändern von mehreren Werten kaum.
Habe noch keine Logik entdecken können wann es geht bzw. nicht geht.
Ändere ich einen Wert, dann muss ich ihn ein paarmal ändern bevor die Änderng an das Thermostat geschickt wird.
Hallo LHBL2003,
nein, ich kenne das Problem nicht - vielleicht habe ich es aber auch nicht richtig verstanden ;)
Ich habe nur MAX und da kann man dem Modul stätig neue Sachen senden. Das Modul selbst scheint eine Queue zu haben und sendet nur bei vorhandenen Credits die Daten an die Thermostate weiter.
Das Problem liegt meiner Meinung also am HomeMatic Gateway. Scheinbar kann der die Daten nicht richtig verarbeiten bzw. puffern. Du solltes hier meiner Meinung auch mal nachfragen.
Dein Lösungsvorschlag würde bestimmt helfen, wenn der Gateway zumindest Daten von einem komplette Wochenprofil verarbeiten kann. Könnte mir vorstellen (wenn du beim Homatic Modulentwickler nichts erreichst), zwischen dem Senden der einzelnen Wochenprofile eine Wartezeit ein zu bauen. Die zu sendeten Daten pro Wochenprofil nochmal zu splitten, sehe ich als zu aufwendig an. Das Ganze sehe ich aber nur als Workaround. Das Problem sollte dort gelöst werden, wo es auftritt.
Risiko
Hi, erstmal danke für das Hilfreiche Modul. Leider verlieren alle meine Max Thermostate ihr Weekprofil nach einem neustart vom FHEM. Wie muss ich es einstellen, damit das nciht passiert. ich brauche eigentlich nicht für jedes Thermostat ein eigenes Profil, deshlab habe ich die auch nciht direkt zugeprdnet sondern sende die immer zu dem jeweiligen Gerät. Ist das also works as designed oder doch ein Fehler?
sind die werte an sich noch in der übersicht? oder ist das widget komplett leer? das modul schreibt im fhem-logverzeichnis für die profile eine datei. sind die vorhanden, habe die ggf. falsche berechtigungen?
wie sieht das "verlieren" aus? ich nutze homematic, die logik sollte aber identisch sein. mein fhem behält auch nach restart alles was benötgit wird.
Probier mal Antwort 1 aus (also den zweiten Eintrag)
Wenn es ein rechte Problem ist, hilft das bei mir immer.
https://forum.fhem.de/index.php?topic=12037.0
Danke für die Antworten, also die Werte fehlen wirklich in jedem Gerät in der Ansicht bis ich sie manuell wieder gesendet habe. Mir fällt grade ein, dass das erst so ist, seit ich den Max Cube als CUNO geflast habe und betreibe. Vorher hatte ich das Problem nicht. Denke also an Rechten kann es nicht liegen, denn das FHEM ist noch das gleiche. Werde das aber trotzdem mal prüfen.
Könnt ihr mir sagen wo genau FHEM diese Infos aus den Max Thermostaten speichert? Da ich mit einer speziellen Linux Version für mein Smarthome arbeite und das FHEM selbst nur ein Modul darin ist, würde ich mal gern die Berechtigungen auf diese Dateien prüfen.
Komisch ist halt, dass alle anderen Dinge gespeichert bleiben die ich im FHEm habe.
Also das Thema ist gelöst, problem war, dass die FHEM.save im Log verzeichnis lag und dieses beim Reboot gelöscht wurde. Verschoben an einen anderen Ort und alles war gut!
Das Problem bei MAX! ist, dass die in den Thermostaten gespeicherten Wochenprofile nicht ausgelesen werden können. Das kann nicht einmal der original CUBE. Deswegen muss man ja auch bei einem Cube-Reset alles neu einrichten und das wo man da nichtmal ein Backup machen kann.
Wenn in FHEM falsche oder keine Wochenprofile angezeigt werden, heißt das nicht, dass auch in den Thermostaten (Wand- oder HK) falsche Programme liegen. Was du einmal auf die Thermostate geschickt hast bleibt da auch bis du ein Werksreset machst oder etwas neues hinschickst. Bei den Wandthermostaten läßt sich für den aktuellen Tag das Programm an der unteren Punktlinie ja so grob ablesen. Das Menü ist nunmal leider nach dem Pairing nicht mehr zugänglich.
wenn es nur dazu dient die anzeige beim reboot gerade zu ziehen kannst du ja ein notify auf reboot setzen und dann mit "set <weekprofile> send_to_device <device> senden. das machts du aktuell manuell.
Beispiel des reboot-notify. das beispiel sendet ein mail, musst halt die entsprechenden set-befehle eintragen.
defmod ntf_global_INITIALIZED notify global:INITIALIZED {DebianMail('xxxxx','FHEM Restarted',':','')}
Hallo Risiko und co.,
Es geht um das Thema, das Homatic Thermostate und Wandthermostate nicht korrekt geladen werden.
Probleme sind solche Dinge wie: MUARTLGW HomeMaticLGW: queue is full, dropping packet
Bereits erwähnt in Antwort #444 am: 25 Oktober 2018, 19:29:29
Ich habe daraufhin mal das Problem versucht zu analysieren, da du ja MAX Systeme hast.
Ich muss sagen, dass es bei mir seit November sehr zuverlässig und Fehlerfrei funktioniert. Dadurch ist aber mindestens ein Punkt entstanden, der bei jeden Update übergebügelt werden würde. Deshalb würde ich mich freuen, wenn du dir diesen Beitrag durchlesen würdest. Vielen Dank vorab.
Problem Vermeidung Nr.1 queue is full, dropping packet:
Ich habe das ganze Problem aushebeln können, indem ich meine 17 Devices zeitversetzt lade.
In meinem Fall habe ich dafür gesorgt, das die Profile mit je einem Versetzt von einer Minute abgesendet werden.
Dadurch kommt es zu keinen "queue is full".
Hierzu musste ich deinen Quellcode (FHEM/98_weekprofile.pm) etwas von dir angepasst werden (Datei auch im Angang):
Zeile 25 bis 31 (Deklaration):
#HEMPEL
use DateTime; # Verweis auf DateTime Lib
#HEMPEL
#Zeitverzögerung wann das letzte Profil geplant gesendet wird
#Initialzeit liegt in der Vergangenheit
my $DATETIME_WHEN_THE_LAST_PROFILE_IS_SEND = DateTime->new( year => 1999, month => 1, day => 1 );
Zeile 414 bis 450 (Verhalten beim HM Devices --> Befehle werden im 60 Sekunden Zyklus ausgelöst und im Logfile Dokumentiert):
#HEMPEL
my $datetimenow = DateTime->now(); #Aktuelle Zeit als UTC Zeit
$datetimenow->set_time_zone( 'local' ); #Aktuelle Zeit in lokaler Zeitzone
#Jedes Profil wird Verzögert an das Device gesendet um die Meldung "queue is full, dropping packet" zu unterbinden.
if ($type eq "CUL_HM") {
Log3 $me, 1, "$me --> Zeitpunkt wann aktuell das letzte Profil Übertragen wird. ($DATETIME_WHEN_THE_LAST_PROFILE_IS_SEND)";
#Wenn aktuell keine Profile Zeitverzögert übertragen werden, dann sende das gemeldete Profil sofort.
#Ansonsten
#Wenn in der letzten Sekunde bereits ein Profil übertragen wurde, dann sende das nächste um x Sekunden Zeitverzögert.
#Werden noch weitere Profile zum senden gemeldet, so werden diese ebenso Zeitverzögert nach dem letzten Profil eingereiht.
if ($DATETIME_WHEN_THE_LAST_PROFILE_IS_SEND->epoch < $datetimenow->epoch-1)
{
#Aktuelle Uhrzeit als Auslösezeit für das senden Merken
$DATETIME_WHEN_THE_LAST_PROFILE_IS_SEND = $datetimenow;
Log3 $me, 1, "$me Profil wird jetzt an $device übergeben. ($DATETIME_WHEN_THE_LAST_PROFILE_IS_SEND)";
}
else
{
#Zeitpunkt der letzten geplanten Übertragung + 60 Sekunden. (TODO: Dieser Wert sollte dynamisch angebbar sein. Dann kann jeder sein Optimum ermitteln.)
$DATETIME_WHEN_THE_LAST_PROFILE_IS_SEND = $DATETIME_WHEN_THE_LAST_PROFILE_IS_SEND->add(seconds => 60);
Log3 $me, 1, "$me Profil wird 60 Sekunden nach der letzten geplanten Übertragung an $device gesendet. ($DATETIME_WHEN_THE_LAST_PROFILE_IS_SEND)";
}
#Zeit zwischen jetzt und geplanten Senden in Sekunden.
my $SleepTime = $datetimenow->subtract_datetime_absolute($DATETIME_WHEN_THE_LAST_PROFILE_IS_SEND)->seconds;
Log3 $me, 1, "$me Geplante SleepTime in Sekunden. ($SleepTime)";
#Übertrage das Profil Zeitverzögert. (Fhem Sleep damit das System nicht einfriert.)
$ret = fhem("sleep $SleepTime; $cmd",1);
}
else{
#ORIGINAL
$ret = fhem($cmd,1);
}
Man könnte sich noch überlegen ob man die Zeitangabe (in meinem Beispiel 60 Sek.) konfigurierbar gestaltet, damit jeder seinen eigenen Wert ermitteln könnte.
Aber mit 60 Sekunden fährt man sehr gut.
Beim Auslösen des T (Restore topic) Buttons werden dann folgende Logfile Einträge erzeugt:
Dort kann man sehen welches Thermostat wann seine Daten bekommt:
2018.12.27 15:32:00.550 1: weekprofile --> Zeitpunkt wann aktuell das letzte Profil Übertragen wird. (1999-01-01T00:00:00)
2018.12.27 15:32:00.551 1: weekprofile Profil wird jetzt an OG_Gaestezimmer_THERMOSTAT_Clima übergeben. (2018-12-27T15:32:00)
2018.12.27 15:32:00.552 1: weekprofile Geplante SleepTime in Sekunden. (0)
2018.12.27 15:32:00.641 1: weekprofile --> Zeitpunkt wann aktuell das letzte Profil Übertragen wird. (2018-12-27T15:32:00)
2018.12.27 15:32:00.644 1: weekprofile Profil wird 60 Sekunden nach der letzten geplanten Übertragung an EG_Flur_THERMOSTAT_Clima gesendet. (2018-12-27T15:33:00)
2018.12.27 15:32:00.644 1: weekprofile Geplante SleepTime in Sekunden. (60)
2018.12.27 15:32:00.733 1: weekprofile --> Zeitpunkt wann aktuell das letzte Profil Übertragen wird. (2018-12-27T15:33:00)
2018.12.27 15:32:00.737 1: weekprofile Profil wird 60 Sekunden nach der letzten geplanten Übertragung an EG_Bad_THERMOSTAT_Clima gesendet. (2018-12-27T15:34:00)
2018.12.27 15:32:00.737 1: weekprofile Geplante SleepTime in Sekunden. (120)
2018.12.27 15:32:00.811 1: weekprofile --> Zeitpunkt wann aktuell das letzte Profil Übertragen wird. (2018-12-27T15:34:00)
2018.12.27 15:32:00.813 1: weekprofile Profil wird 60 Sekunden nach der letzten geplanten Übertragung an OG_Kinderzimmer_WANDTHERMOSTAT_Climate gesendet. (2018-12-27T15:35:00)
2018.12.27 15:32:00.814 1: weekprofile Geplante SleepTime in Sekunden. (180)
2018.12.27 15:32:00.883 1: weekprofile --> Zeitpunkt wann aktuell das letzte Profil Übertragen wird. (2018-12-27T15:35:00)
2018.12.27 15:32:00.885 1: weekprofile Profil wird 60 Sekunden nach der letzten geplanten Übertragung an EG_WohnEsszimmer_WANDTHERMOSTAT_Climate gesendet. (2018-12-27T15:36:00)
2018.12.27 15:32:00.886 1: weekprofile Geplante SleepTime in Sekunden. (240)
2018.12.27 15:32:00.954 1: weekprofile --> Zeitpunkt wann aktuell das letzte Profil Übertragen wird. (2018-12-27T15:36:00)
2018.12.27 15:32:00.957 1: weekprofile Profil wird 60 Sekunden nach der letzten geplanten Übertragung an OG_Bad_HK2_WANDTHERMOSTAT_Climate gesendet. (2018-12-27T15:37:00)
2018.12.27 15:32:00.957 1: weekprofile Geplante SleepTime in Sekunden. (300)
2018.12.27 15:32:01.026 1: weekprofile --> Zeitpunkt wann aktuell das letzte Profil Übertragen wird. (2018-12-27T15:37:00)
2018.12.27 15:32:01.028 1: weekprofile Profil wird 60 Sekunden nach der letzten geplanten Übertragung an OG_Bad_HK2_THERMOSTAT_Clima gesendet. (2018-12-27T15:38:00)
2018.12.27 15:32:01.029 1: weekprofile Geplante SleepTime in Sekunden. (360)
2018.12.27 15:32:01.097 1: weekprofile --> Zeitpunkt wann aktuell das letzte Profil Übertragen wird. (2018-12-27T15:38:00)
2018.12.27 15:32:01.099 1: weekprofile Profil wird 60 Sekunden nach der letzten geplanten Übertragung an EG_Buero_THERMOSTAT_Clima gesendet. (2018-12-27T15:39:00)
2018.12.27 15:32:01.100 1: weekprofile Geplante SleepTime in Sekunden. (419)
2018.12.27 15:32:01.169 1: weekprofile --> Zeitpunkt wann aktuell das letzte Profil Übertragen wird. (2018-12-27T15:39:00)
2018.12.27 15:32:01.171 1: weekprofile Profil wird 60 Sekunden nach der letzten geplanten Übertragung an EG_Wohnzimmer_THERMOSTAT_Clima gesendet. (2018-12-27T15:40:00)
2018.12.27 15:32:01.171 1: weekprofile Geplante SleepTime in Sekunden. (479)
2018.12.27 15:32:01.254 1: weekprofile --> Zeitpunkt wann aktuell das letzte Profil Übertragen wird. (2018-12-27T15:40:00)
2018.12.27 15:32:01.256 1: weekprofile Profil wird 60 Sekunden nach der letzten geplanten Übertragung an OG_Schlafzimmer_THERMOSTAT_Clima gesendet. (2018-12-27T15:41:00)
2018.12.27 15:32:01.257 1: weekprofile Geplante SleepTime in Sekunden. (539)
2018.12.27 15:32:01.334 1: weekprofile --> Zeitpunkt wann aktuell das letzte Profil Übertragen wird. (2018-12-27T15:41:00)
2018.12.27 15:32:01.336 1: weekprofile Profil wird 60 Sekunden nach der letzten geplanten Übertragung an OG_Schlafzimmer_WANDTHERMOSTAT_Climate gesendet. (2018-12-27T15:42:00)
2018.12.27 15:32:01.337 1: weekprofile Geplante SleepTime in Sekunden. (599)
2018.12.27 15:32:01.412 1: weekprofile --> Zeitpunkt wann aktuell das letzte Profil Übertragen wird. (2018-12-27T15:42:00)
2018.12.27 15:32:01.414 1: weekprofile Profil wird 60 Sekunden nach der letzten geplanten Übertragung an EG_Flur_WANDTHERMOSTAT_Climate gesendet. (2018-12-27T15:43:00)
2018.12.27 15:32:01.415 1: weekprofile Geplante SleepTime in Sekunden. (659)
2018.12.27 15:32:01.489 1: weekprofile --> Zeitpunkt wann aktuell das letzte Profil Übertragen wird. (2018-12-27T15:43:00)
2018.12.27 15:32:01.491 1: weekprofile Profil wird 60 Sekunden nach der letzten geplanten Übertragung an KG_Bad_THERMOSTAT_Clima gesendet. (2018-12-27T15:44:00)
2018.12.27 15:32:01.492 1: weekprofile Geplante SleepTime in Sekunden. (719)
2018.12.27 15:32:01.566 1: weekprofile --> Zeitpunkt wann aktuell das letzte Profil Übertragen wird. (2018-12-27T15:44:00)
2018.12.27 15:32:01.568 1: weekprofile Profil wird 60 Sekunden nach der letzten geplanten Übertragung an EG_Buero_WANDTHERMOSTAT_Climate gesendet. (2018-12-27T15:45:00)
2018.12.27 15:32:01.569 1: weekprofile Geplante SleepTime in Sekunden. (779)
2018.12.27 15:32:01.643 1: weekprofile --> Zeitpunkt wann aktuell das letzte Profil Übertragen wird. (2018-12-27T15:45:00)
2018.12.27 15:32:01.645 1: weekprofile Profil wird 60 Sekunden nach der letzten geplanten Übertragung an OG_Bad_HK1_WANDTHERMOSTAT_Climate gesendet. (2018-12-27T15:46:00)
2018.12.27 15:32:01.645 1: weekprofile Geplante SleepTime in Sekunden. (839)
2018.12.27 15:32:01.720 1: weekprofile --> Zeitpunkt wann aktuell das letzte Profil Übertragen wird. (2018-12-27T15:46:00)
2018.12.27 15:32:01.722 1: weekprofile Profil wird 60 Sekunden nach der letzten geplanten Übertragung an OG_Bad_HK1_THERMOSTAT_Clima gesendet. (2018-12-27T15:47:00)
2018.12.27 15:32:01.723 1: weekprofile Geplante SleepTime in Sekunden. (899)
2018.12.27 15:32:01.804 1: weekprofile --> Zeitpunkt wann aktuell das letzte Profil Übertragen wird. (2018-12-27T15:47:00)
2018.12.27 15:32:01.807 1: weekprofile Profil wird 60 Sekunden nach der letzten geplanten Übertragung an EG_Esszimmer_THERMOSTAT_Clima gesendet. (2018-12-27T15:48:00)
2018.12.27 15:32:01.808 1: weekprofile Geplante SleepTime in Sekunden. (959)
2018.12.27 15:32:01.890 1: weekprofile --> Zeitpunkt wann aktuell das letzte Profil Übertragen wird. (2018-12-27T15:48:00)
2018.12.27 15:32:01.892 1: weekprofile Profil wird 60 Sekunden nach der letzten geplanten Übertragung an EG_Bad_WANDTHERMOSTAT_Climate gesendet. (2018-12-27T15:49:00)
2018.12.27 15:32:01.893 1: weekprofile Geplante SleepTime in Sekunden. (1019)
2018.12.27 15:32:01.973 1: weekprofile --> Zeitpunkt wann aktuell das letzte Profil Übertragen wird. (2018-12-27T15:49:00)
2018.12.27 15:32:01.975 1: weekprofile Profil wird 60 Sekunden nach der letzten geplanten Übertragung an OG_Kinderzimmer_THERMOSTAT_Clima gesendet. (2018-12-27T15:50:00)
2018.12.27 15:32:01.976 1: weekprofile Geplante SleepTime in Sekunden. (1079)
2018.12.27 15:32:01.991 3: CUL_HM set OG_Gaestezimmer_THERMOSTAT_Clima tempListMon prep 04:30 20.0 07:00 20.0 12:45 20.0 19:00 23.5 24:00 20.0
2018.12.27 15:32:01.993 3: CUL_HM set OG_Gaestezimmer_THERMOSTAT_Clima tempListTue prep 04:30 20.0 07:00 20.0 12:45 20.0 19:00 23.5 24:00 20.0
2018.12.27 15:32:01.995 3: CUL_HM set OG_Gaestezimmer_THERMOSTAT_Clima tempListWed prep 04:30 20.0 07:00 20.0 12:45 20.0 19:00 23.5 24:00 20.0
2018.12.27 15:32:01.997 3: CUL_HM set OG_Gaestezimmer_THERMOSTAT_Clima tempListThu prep 04:30 20.0 07:00 20.0 12:45 20.0 19:00 23.5 24:00 20.0
2018.12.27 15:32:01.999 3: CUL_HM set OG_Gaestezimmer_THERMOSTAT_Clima tempListFri prep 04:30 20.0 07:00 20.0 12:45 20.0 19:00 23.5 24:00 20.0
2018.12.27 15:32:02.000 3: CUL_HM set OG_Gaestezimmer_THERMOSTAT_Clima tempListSat prep 09:00 20.0 20:00 23.5 24:00 20.0
2018.12.27 15:32:02.485 3: CUL_HM set OG_Gaestezimmer_THERMOSTAT_Clima tempListSun exec 09:00 20.0 20:00 23.5 24:00 20.0
2018.12.27 15:32:09.405 3: CUL_HM set EG_Kueche_Schaltsteckdose_Dunstabzugshaube off
2018.12.27 15:33:00.650 3: CUL_HM set EG_Flur_THERMOSTAT_Clima tempListMon prep 04:30 20.0 07:00 22.0 12:45 20.0 22:00 22.0 24:00 20.0
2018.12.27 15:33:00.653 3: CUL_HM set EG_Flur_THERMOSTAT_Clima tempListTue prep 04:30 20.0 07:00 22.0 12:45 20.0 22:00 22.0 24:00 20.0
2018.12.27 15:33:00.657 3: CUL_HM set EG_Flur_THERMOSTAT_Clima tempListWed prep 04:30 20.0 07:00 22.0 12:45 20.0 22:00 22.0 24:00 20.0
2018.12.27 15:33:00.661 3: CUL_HM set EG_Flur_THERMOSTAT_Clima tempListThu prep 04:30 20.0 07:00 22.0 12:45 20.0 22:00 22.0 24:00 20.0
2018.12.27 15:33:00.665 3: CUL_HM set EG_Flur_THERMOSTAT_Clima tempListFri prep 04:30 20.0 07:00 22.0 12:45 20.0 22:00 22.0 24:00 20.0
2018.12.27 15:33:01.191 3: CUL_HM set EG_Flur_THERMOSTAT_Clima tempListSun exec 07:00 20.0 22:00 22.0 24:00 20.0
2018.12.27 15:33:05.915 3: CUL_HM set OG_Gaestezimmer_THERMOSTAT_Clima getConfig
2018.12.27 15:33:32.005 3: CUL_HM set EG_Flur_THERMOSTAT_Clima getConfig
2018.12.27 15:34:00.747 3: CUL_HM set EG_Bad_THERMOSTAT_Clima tempListMon prep 04:30 20.0 07:00 23.5 12:45 20.0 22:00 23.5 24:00 20.0
2018.12.27 15:34:00.759 3: CUL_HM set EG_Bad_THERMOSTAT_Clima tempListTue prep 04:30 20.0 07:00 23.5 12:45 20.0 22:00 23.5 24:00 20.0
2018.12.27 15:34:00.763 3: CUL_HM set EG_Bad_THERMOSTAT_Clima tempListWed prep 04:30 20.0 07:00 23.5 12:45 20.0 22:00 23.5 24:00 20.0
2018.12.27 15:34:00.767 3: CUL_HM set EG_Bad_THERMOSTAT_Clima tempListThu prep 04:30 20.0 07:00 23.5 12:45 20.0 22:00 23.5 24:00 20.0
2018.12.27 15:34:00.771 3: CUL_HM set EG_Bad_THERMOSTAT_Clima tempListFri prep 04:30 20.0 07:00 23.5 12:45 20.0 22:00 23.5 24:00 20.0
2018.12.27 15:34:01.298 3: CUL_HM set EG_Bad_THERMOSTAT_Clima tempListSat exec 07:00 20.0 22:30 23.5 24:00 20.0
2018.12.27 15:35:00.819 3: CUL_HM set OG_Kinderzimmer_WANDTHERMOSTAT_Climate tempListMon prep 04:30 20.0 07:00 23.5 12:45 20.0 22:00 23.5 24:00 20.0
2018.12.27 15:35:00.823 3: CUL_HM set OG_Kinderzimmer_WANDTHERMOSTAT_Climate tempListTue prep 04:30 20.0 07:00 23.5 12:45 20.0 22:00 23.5 24:00 20.0
2018.12.27 15:35:00.827 3: CUL_HM set OG_Kinderzimmer_WANDTHERMOSTAT_Climate tempListWed prep 04:30 20.0 07:00 23.5 12:45 20.0 22:00 23.5 24:00 20.0
2018.12.27 15:35:00.831 3: CUL_HM set OG_Kinderzimmer_WANDTHERMOSTAT_Climate tempListThu prep 04:30 20.0 07:00 23.5 12:45 20.0 22:00 23.5 24:00 20.0
2018.12.27 15:35:00.835 3: CUL_HM set OG_Kinderzimmer_WANDTHERMOSTAT_Climate tempListFri prep 04:30 20.0 07:00 23.5 12:45 20.0 22:00 23.5 24:00 20.0
2018.12.27 15:35:00.838 3: CUL_HM set OG_Kinderzimmer_WANDTHERMOSTAT_Climate tempListSat prep 04:30 20.0 22:00 23.5 24:00 20.0
2018.12.27 15:35:00.880 3: CUL_HM set OG_Kinderzimmer_WANDTHERMOSTAT_Climate tempListSun exec 04:30 20.0 22:00 23.5 24:00 20.0
2018.12.27 15:35:04.898 3: CUL_HM set OG_Kinderzimmer_WANDTHERMOSTAT_Climate getConfig
2018.12.27 15:35:32.037 3: CUL_HM set OG_Gaestezimmer_THERMOSTAT_Clima getConfig
2018.12.27 15:36:00.891 3: CUL_HM set EG_WohnEsszimmer_WANDTHERMOSTAT_Climate tempListMon prep 04:30 20.0 07:00 23.5 12:45 21.0 22:00 23.5 24:00 20.0
2018.12.27 15:36:00.895 3: CUL_HM set EG_WohnEsszimmer_WANDTHERMOSTAT_Climate tempListTue prep 04:30 20.0 07:00 23.5 12:45 21.0 22:00 23.5 24:00 20.0
2018.12.27 15:36:00.899 3: CUL_HM set EG_WohnEsszimmer_WANDTHERMOSTAT_Climate tempListWed prep 04:30 20.0 07:00 23.5 12:45 21.0 22:00 23.5 24:00 20.0
.........usw. für den Rest
Problem Vermeidung Nr.2 R_tempList_State meldet incomplete und bleibt ewig bestehen:
Überblick:
Jedes Thermostat hat ein "...Clima" Device Element, dieses beinhaltet die Readings R_0_tempListSat bis R_6_tempListFri.
Die ...tempList... Reading Informationen werden angepasst, sobald das Thermostat seine aktuellen Informationen zurücksendet.
Aktuelles Verhalten:
Beim auslösend der Befehle zum übertragen der Temperaturinformationen wird der Reading Status "R_tempList_State" auf incomplete gesetzt.
Sobald die Daten tatsächlich an das Thermostat gesendet werden (HMLANGW Logik arbeitet die übergebenen Befehle ab),
sendet dieses Modul auch den Befehl GetConfig, damit die aktuellen Temperatureinstellungen zurückgemeldet werden.
Die zurückgemeldeten Einstellungen werden dann normalerweise in die Readings R_0_tempListSat bis R_6_tempListFri eingetragen.
Das Problem ist aber, das die Schnittstelle gut beschäftigt und ab und an keine Rückmeldung durch GetConfig erfolgt.
Das sorgt dafür, das weiterhin in FEHM veraltete Daten in den Readings R_0_tempListSat bis R_6_tempListFri stehen, obwohl das Thermostat Tagelang bereits die neuen Temperaturdaten benutzt. Demzufolge hat man dann beim Wechsel zwischen zwei Wochenprofielen riesige Probleme, denn die weekprofile Logik schaut ob sich die Daten zwischen dem zu seidenen Profil und den Readings R_0_tempListSat bis R_6_tempListFri unterscheidet (beachtet aber nicht das "incomplete", was ich aktuell auch noch nicht abgefangen habe.)
Der Status R_tempList_State bleibt also bis zum nächsten auslösen und erfolgreich abgearbeiteten GetConfig auf incomplet. (Wenn es keiner auslöst also ewig.)
Lösungsansatz:
Daher habe ich bei mir ein Notify angelegt (n_Check_HM_tempList_State) evtl. kann man die Logik auch im WeekProfil Modul verheiraten:
Das Notify prüft ob irgend ein ...Clima Device Element bei irgend einen der ...tempList_State den Status incomplet besitzt.
Sobald dies der Fall ist wird temorär ein "at" Modul im Raum "Temp" angelegt, welches nach 3 Minuten und 30 Sekunden erneut ein "GetConfig" für das Thermostat auslöst.
3 Minuten und 30 Sekunden daher, weil ja die HM Thermostate im Normalfall alle 3 Minuten aufgaben abarbeiten und in den ersten 3 Minuten ja erst einmal die Daten gesendet werden und mit etwas Glück auf das normale GetConfig funktioniert.
Dies wird solange durchgeführt, bis der Staus ..tempList_State nicht mehr incomplet ist.
Sobald das überprüfte incomplet verschwunden ist, wird auch das "AT" Modul entfernt, damit keine GetConfig Anforderungen mehr ausgelöst werden.
Mann könnte das zwar auf über viele Watchdogs erledigen. Aber dann benötige massig viele Watchdogs, denn ein Wandthermostat könnte ja 3 Profile besitzen.
.*THERMOSTAT_Clima:.*_tempList_State:.* {
# Log Präfix, der vorweg angegeben wird
my $LogPrefix = "n_Check_HM_tempList_State:";
my $ReadingName = (split(":",$EVTPART0))[0];
#$NAME = Name vom Device welches überwacht werden soll (NOTIFYDEV)
#$EVENT = Wert des Readings der gelesen wird
#Log3 ($LogPrefix, 1, "$LogPrefix: name=$NAME event=$EVENT");
if($EVENT eq "R_tempList_State: incomplete")
{
Log3 ($LogPrefix, 1, "Das Device $NAME meldet $EVENT. GetConfig wird in 3 Minute und 30 Sekunden ausgelöst um erneut die Daten abzufragen." );
if(Value("$NAME"."$ReadingName"."_NewSetGetConfig") ne "")
{
Log3 ($LogPrefix, 1, "$NAME"."$ReadingName"."_NewSetGetConfig wurde schon angelegt, also erst mal löschen.");
fhem ("delete $NAME"."$ReadingName"."_NewSetGetConfig");
}
fhem ("define $NAME"."_NewSetGetConfig at +00:03:30 set $NAME getConfig");
}
else
{
if(Value("$NAME"."$ReadingName"."_NewSetGetConfig") ne "")
{
Log3 ($LogPrefix, 1, "Das Device $NAME meldet $EVENT. GetConfig Timer wird gelöscht.");
fhem ("delete $NAME"."$ReadingName"."_NewSetGetConfig");
}
}
}
Sobald ein "incomplete" auftaucht, wird ein Logeintrag mit der Überwachungsinformation im FHEM Log angelegt.
2018.12.27 15:32:02.024 1: Das Device OG_Gaestezimmer_THERMOSTAT_Clima meldet R_tempList_State: incomplete. GetConfig wird in 3 Minute und 30 Sekunden ausgelöst um erneut die Daten abzufragen.
Frohe Weihnachten und einen Guten Rutsch ins neue Jahr.
Hallo LHBL2003,
danke für die ausführliche Erklärung. Ich habe es nur überflogen.
Schaue es mit im neuen Jahr näher an.
Guten Rutsch.
Risiko
Hallo LHBL2003,
ich habe das verzögerte Senden pro Device eingebaut. Habe aber nur die Idee und nicht die eigentliche Implementierung übernommen.
Die Zeit kann man über das Attribut 'send_delay' [Sekunden] einstellen.
Könntest du die Version bitte testen.
Danke.
Risiko.
Hallo Risiko,
danke schon mal für die Bearbeitung. Ich habe die Datei vor etwa 10 Minuten eingespielt und habe das Attribut send_delay auch auf 16 Sek. gestellt.
Aktuell kann ich dir sagen, dass mein FHEM am strick hängt. Denn die Webseite wird nicht geladen.
Gerade habe ich gesehen, dass mein FHEM Log vollläuft. Ich habe dir die Logs im Anhang beigefügt.
- fhem-2019-01-04_Test1.log ist der erste Test gewesen, allerdings mit verbose Level 3
- fhem-2019-01-04_Test2 Mit LOG Level 4.log ist der zweite Test gewesen. Diesen habe ich nach einem Neustart vom Raspberry PI durchgeführt. Aber dann mit dem globalen Attribut "attr global verbose 4".
Gruß Denis
Hallo Denis,
schon mal vielen Dank.
Ich kann leider nichts Verdächtiges finden.
Aber nochmal zum Verständnis.
Nicht jedes Thermostat z.B. OG_Bad_HK2_THERMOSTAT_Clima hat eine eigene Queue sondern das "Masterdevice" z.B. HMUARTLGW?
Somit macht das Timeout pro Device (Thermostat) keinen Sinn. Also müsste es aus Sicht von weekprofile pro Typ wirken.
Ich habe eine neue Version erstellt.
Risiko
Hallo.
Eine weitere Version. Nun wirkt das verzögerte Senden auch (wieder) über mehrere weekprofile Instanzen hinweg.
Soll heißen, wenn über weekprofile Profile gesendet werden wird global das verzögerte Senden an einen gleichen Thermostattyp berücksichtigt, sofern send_delay > 0 ist.
Viel Spaß beim Testen.
Nachtrag:
Habe die Version gerade eingecheckt. Das Attribut heißt jetzt sendDelay. Default: 0
Hallo Denis,
für dein 2. Problem gibt es jetzt das Attribut 'forceCompleteProfile'. Damit wird erzwungen, dass immer das komplette Wochenprofil an das Thermostat gesendet wird und nicht nur Änderungen. Somit ist es auch möglich ein Profil nochmal zu senden.
Vielleicht hilft es dir ja.
Risiko.
Hallo Risiko,
die letzten beiden Beiträge habe ich soeben erst gelesen und noch nicht berücksichtigt.
Aber ich war die Tage dabei die Antwort #456 zu testen.
Zu deiner Frage:
ZitatNicht jedes Thermostat z.B. OG_Bad_HK2_THERMOSTAT_Clima hat eine eigene Queue sondern das "Masterdevice" z.B. HMUARTLGW?
Ja das würde ich auch so sehen. Zumindest kommt das
Log3($hash, 1, "HMUARTLGW ${name}: queue is full, dropping packet"); aus der 00_HMUARTLGW.pm
Folgendes Ergebnis zum Test:
Das Verzögerte Senden funktioniert zuverlässig. So das mit einer Verzögerung von 60 Sekunden keine "queue is full" Meldungen kommen.
Die Daten werden an das Thermostat bzw. Wandthermostat übermittelt.
Wichtig ist aber!:
Sofern im Reading R_tempList_State (Thermostat) bzw. R_P1_tempList_State (Wandthermostat) nicht "verified" steht,
kann sich das WeekProfil niemals darauf Verlassen, das die aktuellen Daten in R_P1_0_tempListSat bis R_P1_6_tempListFri stimmen.
Soviel ich es in Erinnerung habe, prüfst du ob die Daten in R_P1_0_tempListSat bis. R_P1_6_tempListFri mit den zu sendenden Daten übereinstimmen.
Wenn dies nicht übereinstimmen, dann sendest du diese. Wenn diese übereinstimmen, dann sendest du diese nicht. (Bei z.B. "incomplet" oder "set", muss man dennoch senden. Denn niemand weiß welchen Stand das Device hat.)
Wäre also gut wenn du dies bitte noch berücksichtigen könntest, wenn dies nicht durch das neue Update schon mit kommen wird.
Nachtrag:(Das Forcen wird mit etwas mehr Trafic auf das selbe Ergebnis hinzielen) :)
Jetzt muss ich nur noch schauen wie man dieses Thema R_tempList_State bzw. R_P1_tempList_State = "incomplet" 100% in den griff bekommt, bzw. zum Standard bringt.
Denn das ewige senden von GetConfig bis mal aus "incomplet" --> "verified" wird ist noch unschön.
So dann mache ich mal ein FHEM update und schaue mir mal die Neuerungen an.
Gruß Denis
Hallo Denis,
R_tempList_State bzw. R_P1_tempList_State wird nicht berücksichtigt.
Wenn ich es richtig verstehe, dann soll bei einem R_tempList_State != verified immer ein Senden mit force=1 (komplettes Profil) erfolgen?
Was mache ich aber beim Lesen, wenn R_tempList_State != verified ist? So wie jetzt ignorieren?
Risiko.
Hallo Risiko,
ZitatR_tempList_State bzw. R_P1_tempList_State wird nicht berücksichtigt.
Wenn ich es richtig verstehe, dann soll bei einem R_tempList_State != verified immer ein Senden mit force=1 (komplettes Profil) erfolgen?
Richtig, folgendes Beispiel:
- Ich sende ein Profil "A" mit jeden R_0_tempListXYZ Tag 20°C (Order jeden Tag andere Daten, wie auch immer)
- Die Daten werden erfolgreich übertragen und auch GetConfig hat geklappt. (R_0_tempListXYZ beinhaltet die Richtigen Daten)
- Ich sende ein Profil "B" mit jeden R_0_tempListXYZ Tag 5°C (Order jeden Tag andere Daten, wie auch immer)
- Die Daten werden erfolgreich übertragen das Device stellt auf 5° ABER GetConfig hat nicht geklappt, mit etwas Pech steht sogar der Status vom Device auf "CMDs_done" aber R_tempList_State bzw. R_P1_tempList_State auf incomplet.
- Jetzt bekomme ich dies nicht mit.
- Ich sende das Profil "A" mit jeden R_0_tempListXYZ Tag 20°C
- Jetzt sagt sich das WeekProfil. Joar, R_0_tempListXYZ stimmen überein. Brauche ich also nicht abarbeiten. (Verdammt R_tempList_State bzw. R_P1_tempList_State ist nicht verified. Die Daten in Fhem stimmen evtl. garnicht mit dem Device überein.)
ZitatWas mache ich aber beim Lesen, wenn R_tempList_State != verified ist? So wie jetzt ignorieren?
Also ich habe eine Seite, wo ich von allen Thermostaten die aktuellen Einstellungen Darstelle. (Siehe Anhang: Normalerweise müsste beim Test alle Thermostate bis auf Keller, die selben Einstellungen haben. Da es nicht der Fall ist, weiß ich, dass irgendwelche Einstellungen noch nicht zurückgemeldet wurden.)
Am allerbesten wäre, ein Hinweis, evtl. sogar eine Einfärbung so das man erkennen kann, dass die Daten nicht (bzw. noch nicht) Valide sind.
PS: Früher vor etwa 1 oder 2 Jahren war es übrigens so, dass die Wochentage R_0_tempListXYZ den Status incomplet hatte, solange die Daten nicht aktuell waren. Das ist aber nicht mehr so. Jetzt hat R_tempList_State den Status und R_0_tempListXYZ behält die Daten, bis diese aktualisiert werden. Damit war es früher so, das in deinen Profilen immer incomplet angezeigt wurde (Was eigentlich ein praktischer Nebeneffekt war).
Gruß Denis
Nach einem Umzug meines FHEM auf einen anderen RasPi sind meine Profile weg. Ich vermute, die Config-Dateien sind separat abgelegt (wo?) und ich hab sie vergessen, umzuziehen?
Meistens liegen die configurationen im Logfile Ordner. :)
Zitat von: grappa24 am 13 Februar 2019, 12:38:23
Nach einem Umzug meines FHEM auf einen anderen RasPi sind meine Profile weg. Ich vermute, die Config-Dateien sind separat abgelegt (wo?) und ich hab sie vergessen, umzuziehen?
im Logverzeichnis liegen Dateien weekprofile-*** diese musst du mir umziehen
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
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
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,
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
Zitat von: freda am 19 Februar 2019, 22:10:50
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
Zitat von: clumsy am 16 Februar 2019, 01:01:02
STefan
Hallo Stefan,
danke für die Hinweise.
Muss ich mir mal durch den Kopf gehen lassen.
Zitat von: freda am 16 Februar 2019, 22:06:20
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
Zitat von: clumsy am 16 Februar 2019, 01:01:02
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.
Zitat von: clumsy am 16 Februar 2019, 01:01:02
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"
Zitat von: Risiko am 03 März 2019, 14:01:48
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
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
set <device> config mit\oder ohne 1
Eine spezielle Logik, abhängig vom Namen, will ich eigentlich nicht einführen.
Zitat von: Risiko am 03 März 2019, 14:53:49
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
set <weekprofile> restore_topic <topic>auch profile wählen resp. aktiv setzen, die es gar nicht gibt, also auch solche die bei
get <weekprofile> topic_namesgar nicht aufgelistet werden, also eigentlich auch nicht existieren, resp. keine Profile in dem entsprechenden <topic> definiert sind.
Ah ok. Verstanden.
Klingt nach nem Fehler.
Schaue es mir bei Gelegenheit an.
Danke.
Zitat von: Risiko am 05 März 2019, 19:35:47
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
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.
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?
Habe ihn angeschrieben. Mal schauen...
Hab noch aus meiner Sicht ein kleinen Bug bei HMCCUDEV gefunden.
Bei den Readings der Temperaturlisten ist der letzte Eintrag immer der, bei dem eine Zeit von 1440 gesetzt ist. Es kann vorkommen, dass noch nachfolgende Einträge eine unterschiedliche Zeit haben, diese haben aber keine Relevanz. Die Datenkonstellation kann auftreten, wenn vorher mehrere Zeiträume (mehr als 2) definiert waren und bei der auf nur eine Temperaturzeit wird die erste Einstellung auf eine Zeit von 1440 gesetzt und andere Einträge behalten ihre Zeit.
Coding-Korrektur:
elsif ($type eq "HMCCUDEV"){
my $lastTime = "";
for (my $i = 1; $i < 14; $i+=1){
my $prfTemp = ReadingsVal($device, "R-TEMPERATURE_" . $reading . "_$i", "");
my $prfTime = ReadingsVal($device, "R-ENDTIME_" . $reading . "_$i", "");
$prfTime = weekprofile_minutesToTime($prfTime);
# if ($lastTime ne $prfTime){ Ersetzt durch nächste Zeile
if ($lastTime ne "24:00"){
Hallo.
Laut @zap gibt es in den Internals bereits 'ccutype', was das Model hält.
Es wäre gut, wenn ihr mal ein list von den jeweiligen Thermostaten hier zur Verfügung stellen könntet.
Risiko
Hallo,
bei meinen Heizkörperthermostaten für HM ist die CCUTYPE "HM-CC-RT-DN" hinterlegt. Ich denke alte Geräte fangen alle mit HM-* an die neue mit HmIP-* (Case sensitiv?). Ansonsten gibt es laut ELV folgende Thermostate:
HM:
HM-CC-RT-DN
HM-TC-IT-WM-W-EU
HMIP:
HMIP-eTRV-2
HmIP-eTRV-C
HMIP-WTH-2
HMIP-BWTH
HMIP-BWTH24
Ich hoffe das hilft etwas weiter. VG
Hey.
es gibt auch noch Virtuelle Gruppen:
Homematic: HM-CC-VG-1 wobei hier das 1 scheinbar die Nummer der Gruppe entspricht...
Homepatic IP: HmIP-HEATING
ansonsten:
Homematic:
und Homematic wie auch ist HMIP groß geschrieben.. und die Nachfolgenden Buchstaben, wie oben genannt..
Ich dachte eher an die Ausgabe von list <device>.
Dann sehe ich alles (Internals, Readings) und auch, wie alles geschrieben wird (Groß- Kleinschreibung, etc.)
Anbei eine erste Testversion, welche hoffentlich alle HMCCUDEV Geräte unterstützt.
Bitte mal testen, ich kann es leider nicht.
Risiko
ich habe ein list device für einen HM-CC-RT-DN angehängt (andere habe ich momentan nicht im Einsatz).
Die Konfigurationsdaten werden richtig übertragen. Allerdings werden die aktuellen Einstellungen nicht korrekt gelesen (HMCCU_HM).
Danke.
Habe einen kleinen Fehler gefunden.
Neue Version im Anhang
Meine Tests mit HM-* Thermostaten waren erfolgreich. Die Zeitpläne werden nun auch korrekt gelesen.
Vielen Dank
:) :)
Hallo,
leider kriege ich meine HM_Thermostat über hmccu nicht das Profile ausgelesen...
Meine Readings sind R_P1_
Leider kann weekprofile dies nicht auslesen.....
Internals:
DEF OEQ1670515
FUUID 5c9a993b-f33f-787c-0476-ba3bcc73507dc4ba
IODev d_ccu
NAME HM_CLONE_WT_Wohnzimmmer
NR 158
STATE 22.0
TYPE HMCCUDEV
ccuaddr OEQ1670515
ccudevstate active
ccuif BidCos-RF
ccuname WT_Wohnzimmer
ccutype HM-TC-IT-WM-W-EU
channels 6
firmware 1.4
statevals devstate
READINGS:
2019-09-29 09:52:15 1.HUMIDITY 57
2019-09-29 09:52:15 1.TEMPERATURE 22.1
2019-09-29 09:51:56 2.SET_TEMPERATURE 22.0
2019-09-29 09:42:25 2.WINDOW_OPEN_REPORTING closed
2019-09-29 09:18:35 R-P1_ENDTIME_FRIDAY_1 360
2019-09-29 09:18:35 R-P1_ENDTIME_FRIDAY_10 1440
2019-09-29 09:18:35 R-P1_ENDTIME_FRIDAY_11 1440
2019-09-29 09:18:35 R-P1_ENDTIME_FRIDAY_12 1440
2019-09-29 09:18:35 R-P1_ENDTIME_FRIDAY_13 1440
2019-09-29 09:18:35 R-P1_ENDTIME_FRIDAY_2 1320
2019-09-29 09:18:35 R-P1_ENDTIME_FRIDAY_3 1440
2019-09-29 09:18:35 R-P1_ENDTIME_FRIDAY_4 1320
2019-09-29 09:18:35 R-P1_ENDTIME_FRIDAY_5 1440
2019-09-29 09:18:35 R-P1_ENDTIME_FRIDAY_6 1440
2019-09-29 09:18:35 R-P1_ENDTIME_FRIDAY_7 1440
2019-09-29 09:18:35 R-P1_ENDTIME_FRIDAY_8 1440
2019-09-29 09:18:35 R-P1_ENDTIME_FRIDAY_9 1440
2019-09-29 09:18:35 R-P1_ENDTIME_MONDAY_1 360
2019-09-29 09:18:35 R-P1_ENDTIME_MONDAY_10 1440
2019-09-29 09:18:35 R-P1_ENDTIME_MONDAY_11 1440
2019-09-29 09:18:35 R-P1_ENDTIME_MONDAY_12 1440
2019-09-29 09:18:35 R-P1_ENDTIME_MONDAY_13 1440
2019-09-29 09:18:35 R-P1_ENDTIME_MONDAY_2 1320
2019-09-29 09:18:35 R-P1_ENDTIME_MONDAY_3 1440
2019-09-29 09:18:35 R-P1_ENDTIME_MONDAY_4 1320
2019-09-29 09:18:35 R-P1_ENDTIME_MONDAY_5 1440
2019-09-29 09:18:35 R-P1_ENDTIME_MONDAY_6 1440
2019-09-29 09:18:35 R-P1_ENDTIME_MONDAY_7 1440
2019-09-29 09:18:35 R-P1_ENDTIME_MONDAY_8 1440
2019-09-29 09:18:35 R-P1_ENDTIME_MONDAY_9 1440
2019-09-29 09:18:35 R-P1_ENDTIME_SATURDAY_1 360
2019-09-29 09:18:35 R-P1_ENDTIME_SATURDAY_10 1440
2019-09-29 09:18:35 R-P1_ENDTIME_SATURDAY_11 1440
2019-09-29 09:18:35 R-P1_ENDTIME_SATURDAY_12 1440
2019-09-29 09:18:35 R-P1_ENDTIME_SATURDAY_13 1440
2019-09-29 09:18:35 R-P1_ENDTIME_SATURDAY_2 1320
2019-09-29 09:18:35 R-P1_ENDTIME_SATURDAY_3 1440
2019-09-29 09:18:35 R-P1_ENDTIME_SATURDAY_4 1440
2019-09-29 09:18:35 R-P1_ENDTIME_SATURDAY_5 1440
2019-09-29 09:18:35 R-P1_ENDTIME_SATURDAY_6 1440
2019-09-29 09:18:35 R-P1_ENDTIME_SATURDAY_7 1440
2019-09-29 09:18:35 R-P1_ENDTIME_SATURDAY_8 1440
2019-09-29 09:18:35 R-P1_ENDTIME_SATURDAY_9 1440
2019-09-29 09:18:35 R-P1_ENDTIME_SUNDAY_1 360
2019-09-29 09:18:35 R-P1_ENDTIME_SUNDAY_10 1440
2019-09-29 09:18:35 R-P1_ENDTIME_SUNDAY_11 1440
2019-09-29 09:18:35 R-P1_ENDTIME_SUNDAY_12 1440
2019-09-29 09:18:35 R-P1_ENDTIME_SUNDAY_13 1440
2019-09-29 09:18:35 R-P1_ENDTIME_SUNDAY_2 1320
2019-09-29 09:18:35 R-P1_ENDTIME_SUNDAY_3 1440
2019-09-29 09:18:35 R-P1_ENDTIME_SUNDAY_4 1440
2019-09-29 09:18:35 R-P1_ENDTIME_SUNDAY_5 1440
2019-09-29 09:18:35 R-P1_ENDTIME_SUNDAY_6 1440
2019-09-29 09:18:35 R-P1_ENDTIME_SUNDAY_7 1440
2019-09-29 09:18:35 R-P1_ENDTIME_SUNDAY_8 1440
2019-09-29 09:18:35 R-P1_ENDTIME_SUNDAY_9 1440
2019-09-29 09:18:35 R-P1_ENDTIME_THURSDAY_1 360
2019-09-29 09:18:35 R-P1_ENDTIME_THURSDAY_10 1440
2019-09-29 09:18:35 R-P1_ENDTIME_THURSDAY_11 1440
2019-09-29 09:18:35 R-P1_ENDTIME_THURSDAY_12 1440
2019-09-29 09:18:35 R-P1_ENDTIME_THURSDAY_13 1440
2019-09-29 09:18:35 R-P1_ENDTIME_THURSDAY_2 1320
2019-09-29 09:18:35 R-P1_ENDTIME_THURSDAY_3 1440
2019-09-29 09:18:35 R-P1_ENDTIME_THURSDAY_4 1320
2019-09-29 09:18:35 R-P1_ENDTIME_THURSDAY_5 1440
2019-09-29 09:18:35 R-P1_ENDTIME_THURSDAY_6 1440
2019-09-29 09:18:35 R-P1_ENDTIME_THURSDAY_7 1440
2019-09-29 09:18:35 R-P1_ENDTIME_THURSDAY_8 1440
2019-09-29 09:18:35 R-P1_ENDTIME_THURSDAY_9 1440
2019-09-29 09:18:35 R-P1_ENDTIME_TUESDAY_1 360
2019-09-29 09:18:35 R-P1_ENDTIME_TUESDAY_10 1440
2019-09-29 09:18:35 R-P1_ENDTIME_TUESDAY_11 1440
2019-09-29 09:18:35 R-P1_ENDTIME_TUESDAY_12 1440
2019-09-29 09:18:35 R-P1_ENDTIME_TUESDAY_13 1440
2019-09-29 09:18:35 R-P1_ENDTIME_TUESDAY_2 1320
2019-09-29 09:18:35 R-P1_ENDTIME_TUESDAY_3 1440
2019-09-29 09:18:35 R-P1_ENDTIME_TUESDAY_4 1320
2019-09-29 09:18:35 R-P1_ENDTIME_TUESDAY_5 1440
2019-09-29 09:18:35 R-P1_ENDTIME_TUESDAY_6 1440
2019-09-29 09:18:35 R-P1_ENDTIME_TUESDAY_7 1440
2019-09-29 09:18:35 R-P1_ENDTIME_TUESDAY_8 1440
2019-09-29 09:18:35 R-P1_ENDTIME_TUESDAY_9 1440
2019-09-29 09:18:35 R-P1_ENDTIME_WEDNESDAY_1 360
2019-09-29 09:18:35 R-P1_ENDTIME_WEDNESDAY_10 1440
2019-09-29 09:18:35 R-P1_ENDTIME_WEDNESDAY_11 1440
2019-09-29 09:18:35 R-P1_ENDTIME_WEDNESDAY_12 1440
2019-09-29 09:18:35 R-P1_ENDTIME_WEDNESDAY_13 1440
2019-09-29 09:18:35 R-P1_ENDTIME_WEDNESDAY_2 1320
2019-09-29 09:18:35 R-P1_ENDTIME_WEDNESDAY_3 1440
2019-09-29 09:18:35 R-P1_ENDTIME_WEDNESDAY_4 1320
2019-09-29 09:18:35 R-P1_ENDTIME_WEDNESDAY_5 1440
2019-09-29 09:18:35 R-P1_ENDTIME_WEDNESDAY_6 1440
2019-09-29 09:18:35 R-P1_ENDTIME_WEDNESDAY_7 1440
2019-09-29 09:18:35 R-P1_ENDTIME_WEDNESDAY_8 1440
2019-09-29 09:18:35 R-P1_ENDTIME_WEDNESDAY_9 1440
2019-09-29 09:18:35 R-P1_TEMPERATURE_FRIDAY_1 18.0
2019-09-29 09:18:35 R-P1_TEMPERATURE_FRIDAY_10 17.0
2019-09-29 09:18:35 R-P1_TEMPERATURE_FRIDAY_11 17.0
2019-09-29 09:18:35 R-P1_TEMPERATURE_FRIDAY_12 17.0
2019-09-29 09:18:35 R-P1_TEMPERATURE_FRIDAY_13 17.0
2019-09-29 09:18:35 R-P1_TEMPERATURE_FRIDAY_2 20.0
2019-09-29 09:18:35 R-P1_TEMPERATURE_FRIDAY_3 18.0
2019-09-29 09:18:35 R-P1_TEMPERATURE_FRIDAY_4 21.0
2019-09-29 09:18:35 R-P1_TEMPERATURE_FRIDAY_5 17.0
2019-09-29 09:18:35 R-P1_TEMPERATURE_FRIDAY_6 17.0
2019-09-29 09:18:35 R-P1_TEMPERATURE_FRIDAY_7 17.0
2019-09-29 09:18:35 R-P1_TEMPERATURE_FRIDAY_8 17.0
2019-09-29 09:18:35 R-P1_TEMPERATURE_FRIDAY_9 17.0
2019-09-29 09:18:35 R-P1_TEMPERATURE_MONDAY_1 18.0
2019-09-29 09:18:35 R-P1_TEMPERATURE_MONDAY_10 17.0
2019-09-29 09:18:35 R-P1_TEMPERATURE_MONDAY_11 17.0
2019-09-29 09:18:35 R-P1_TEMPERATURE_MONDAY_12 17.0
2019-09-29 09:18:35 R-P1_TEMPERATURE_MONDAY_13 17.0
2019-09-29 09:18:35 R-P1_TEMPERATURE_MONDAY_2 20.0
2019-09-29 09:18:35 R-P1_TEMPERATURE_MONDAY_3 18.0
2019-09-29 09:18:35 R-P1_TEMPERATURE_MONDAY_4 21.0
2019-09-29 09:18:35 R-P1_TEMPERATURE_MONDAY_5 17.0
2019-09-29 09:18:35 R-P1_TEMPERATURE_MONDAY_6 17.0
2019-09-29 09:18:35 R-P1_TEMPERATURE_MONDAY_7 17.0
2019-09-29 09:18:35 R-P1_TEMPERATURE_MONDAY_8 17.0
2019-09-29 09:18:35 R-P1_TEMPERATURE_MONDAY_9 17.0
2019-09-29 09:18:35 R-P1_TEMPERATURE_SATURDAY_1 18.0
2019-09-29 09:18:35 R-P1_TEMPERATURE_SATURDAY_10 17.0
2019-09-29 09:18:35 R-P1_TEMPERATURE_SATURDAY_11 17.0
2019-09-29 09:18:35 R-P1_TEMPERATURE_SATURDAY_12 17.0
2019-09-29 09:18:35 R-P1_TEMPERATURE_SATURDAY_13 17.0
2019-09-29 09:18:35 R-P1_TEMPERATURE_SATURDAY_2 20.0
2019-09-29 09:18:35 R-P1_TEMPERATURE_SATURDAY_3 18.0
2019-09-29 09:18:35 R-P1_TEMPERATURE_SATURDAY_4 17.0
2019-09-29 09:18:35 R-P1_TEMPERATURE_SATURDAY_5 17.0
2019-09-29 09:18:35 R-P1_TEMPERATURE_SATURDAY_6 17.0
2019-09-29 09:18:35 R-P1_TEMPERATURE_SATURDAY_7 17.0
2019-09-29 09:18:35 R-P1_TEMPERATURE_SATURDAY_8 17.0
2019-09-29 09:18:35 R-P1_TEMPERATURE_SATURDAY_9 17.0
2019-09-29 09:18:35 R-P1_TEMPERATURE_SUNDAY_1 18.0
2019-09-29 09:18:35 R-P1_TEMPERATURE_SUNDAY_10 17.0
2019-09-29 09:18:35 R-P1_TEMPERATURE_SUNDAY_11 17.0
2019-09-29 09:18:35 R-P1_TEMPERATURE_SUNDAY_12 17.0
2019-09-29 09:18:35 R-P1_TEMPERATURE_SUNDAY_13 17.0
2019-09-29 09:18:35 R-P1_TEMPERATURE_SUNDAY_2 20.0
2019-09-29 09:18:35 R-P1_TEMPERATURE_SUNDAY_3 18.0
2019-09-29 09:18:35 R-P1_TEMPERATURE_SUNDAY_4 17.0
2019-09-29 09:18:35 R-P1_TEMPERATURE_SUNDAY_5 17.0
2019-09-29 09:18:35 R-P1_TEMPERATURE_SUNDAY_6 17.0
2019-09-29 09:18:35 R-P1_TEMPERATURE_SUNDAY_7 17.0
2019-09-29 09:18:35 R-P1_TEMPERATURE_SUNDAY_8 17.0
2019-09-29 09:18:35 R-P1_TEMPERATURE_SUNDAY_9 17.0
2019-09-29 09:18:35 R-P1_TEMPERATURE_THURSDAY_1 18.0
2019-09-29 09:18:35 R-P1_TEMPERATURE_THURSDAY_10 17.0
2019-09-29 09:18:35 R-P1_TEMPERATURE_THURSDAY_11 17.0
2019-09-29 09:18:35 R-P1_TEMPERATURE_THURSDAY_12 17.0
2019-09-29 09:18:35 R-P1_TEMPERATURE_THURSDAY_13 17.0
2019-09-29 09:18:35 R-P1_TEMPERATURE_THURSDAY_2 20.0
2019-09-29 09:18:35 R-P1_TEMPERATURE_THURSDAY_3 18.0
2019-09-29 09:18:35 R-P1_TEMPERATURE_THURSDAY_4 21.0
2019-09-29 09:18:35 R-P1_TEMPERATURE_THURSDAY_5 17.0
2019-09-29 09:18:35 R-P1_TEMPERATURE_THURSDAY_6 17.0
2019-09-29 09:18:35 R-P1_TEMPERATURE_THURSDAY_7 17.0
2019-09-29 09:18:35 R-P1_TEMPERATURE_THURSDAY_8 17.0
2019-09-29 09:18:35 R-P1_TEMPERATURE_THURSDAY_9 17.0
2019-09-29 09:18:35 R-P1_TEMPERATURE_TUESDAY_1 18.0
2019-09-29 09:18:35 R-P1_TEMPERATURE_TUESDAY_10 17.0
2019-09-29 09:18:35 R-P1_TEMPERATURE_TUESDAY_11 17.0
2019-09-29 09:18:35 R-P1_TEMPERATURE_TUESDAY_12 17.0
2019-09-29 09:18:35 R-P1_TEMPERATURE_TUESDAY_13 17.0
2019-09-29 09:18:35 R-P1_TEMPERATURE_TUESDAY_2 20.0
2019-09-29 09:18:35 R-P1_TEMPERATURE_TUESDAY_3 18.0
2019-09-29 09:18:35 R-P1_TEMPERATURE_TUESDAY_4 21.0
2019-09-29 09:18:35 R-P1_TEMPERATURE_TUESDAY_5 17.0
2019-09-29 09:18:35 R-P1_TEMPERATURE_TUESDAY_6 17.0
2019-09-29 09:18:35 R-P1_TEMPERATURE_TUESDAY_7 17.0
2019-09-29 09:18:35 R-P1_TEMPERATURE_TUESDAY_8 17.0
2019-09-29 09:18:35 R-P1_TEMPERATURE_TUESDAY_9 17.0
2019-09-29 09:18:35 R-P1_TEMPERATURE_WEDNESDAY_1 18.0
2019-09-29 09:18:35 R-P1_TEMPERATURE_WEDNESDAY_10 17.0
2019-09-29 09:18:35 R-P1_TEMPERATURE_WEDNESDAY_11 17.0
2019-09-29 09:18:35 R-P1_TEMPERATURE_WEDNESDAY_12 17.0
2019-09-29 09:18:35 R-P1_TEMPERATURE_WEDNESDAY_13 17.0
2019-09-29 09:18:35 R-P1_TEMPERATURE_WEDNESDAY_2 20.0
2019-09-29 09:18:35 R-P1_TEMPERATURE_WEDNESDAY_3 18.0
2019-09-29 09:18:35 R-P1_TEMPERATURE_WEDNESDAY_4 21.0
2019-09-29 09:18:35 R-P1_TEMPERATURE_WEDNESDAY_5 17.0
2019-09-29 09:18:35 R-P1_TEMPERATURE_WEDNESDAY_6 17.0
2019-09-29 09:18:35 R-P1_TEMPERATURE_WEDNESDAY_7 17.0
2019-09-29 09:18:35 R-P1_TEMPERATURE_WEDNESDAY_8 17.0
2019-09-29 09:18:35 R-P1_TEMPERATURE_WEDNESDAY_9 17.0
2019-09-29 09:51:56 control 22.0
2019-09-29 09:52:15 hmstate 22.0
2019-09-29 09:51:56 state 22.0
hmccu:
devspec OEQ1670515
dp:
0.AES_KEY:
OVAL 0
VAL 0
0.CONFIG_PENDING:
OVAL false
VAL false
0.DEVICE_IN_BOOTLOADER:
OVAL false
VAL false
0.INHIBIT:
OVAL false
VAL false
0.LOWBAT:
OVAL false
VAL false
0.RSSI_DEVICE:
OVAL 1
VAL 1
0.RSSI_PEER:
OVAL 197
VAL 197
0.STICKY_UNREACH:
OVAL false
VAL false
0.UNREACH:
OVAL false
VAL false
0.UPDATE_PENDING:
OVAL false
VAL false
1.HUMIDITY:
OSVAL 57
OVAL 57
SVAL 57
VAL 57
1.TEMPERATURE:
OSVAL 22.1
OVAL 22.100000
SVAL 22.1
VAL 22.100000
2.ACTUAL_HUMIDITY:
OVAL 57.000000
VAL 57.000000
2.ACTUAL_TEMPERATURE:
OVAL 22.100000
VAL 22.100000
2.BATTERY_STATE:
OVAL 3.000000
VAL 3.000000
2.BOOST_STATE:
OVAL 0
VAL 0
2.COMMUNICATION_REPORTING:
OVAL false
VAL 0
2.CONTROL_MODE:
OVAL 0
VAL 0
2.LOWBAT_REPORTING:
OVAL false
VAL 0
2.PARTY_START_DAY:
OVAL 1
VAL 1
2.PARTY_START_MONTH:
OVAL 1
VAL 1
2.PARTY_START_TIME:
OVAL 0
VAL 0
2.PARTY_START_YEAR:
OVAL 0
VAL 0
2.PARTY_STOP_DAY:
OVAL 1
VAL 1
2.PARTY_STOP_MONTH:
OVAL 1
VAL 1
2.PARTY_STOP_TIME:
OVAL 0
VAL 0
2.PARTY_STOP_YEAR:
OVAL 0
VAL 0
2.PARTY_TEMPERATURE:
OVAL 5.000000
VAL 5.000000
2.SET_TEMPERATURE:
OSVAL 22.0
OVAL 22.000000
SVAL 22.0
VAL 22.000000
2.WINDOW_OPEN_REPORTING:
OSVAL closed
OVAL false
SVAL closed
VAL 0
7.DECISION_VALUE:
OVAL 0
VAL 0
Attributes:
DbLogExclude .*
IODev d_ccu
ccureadingfilter (^HUMIDITY|^TEMPERATURE|^SET_TEMPERATURE|^WINDOW_OPEN)
cmdIcon Auto:sani_heating_automatic Manu:sani_heating_manual Boost:sani_heating_boost on:general_an off:general_aus
controldatapoint 2.SET_TEMPERATURE
eventMap /datapoint 2.MANU_MODE 20.0:Manu/datapoint 2.AUTO_MODE 1:Auto/datapoint 2.BOOST_MODE 1:Boost/datapoint 2.MANU_MODE 4.5:off/datapoint 2.MANU_MODE 30.5:on/
genericDeviceType thermostat
room Homematic-clone
statedatapoint 2.SET_TEMPERATURE
stripnumber 1
substexcl control
substitute CONTROL_MODE!0:AUTO,1:MANU,2:PARTY,3:BOOST;WINDOW_OPEN_REPORTING!(true|1):open,(false|0):closed;SET_TEMPERATURE!#0-3.5:off,#30.5-40:on
webCmd control:Auto:Manu:Boost:on:off
widgetOverride control:slider,4.5,0.5,30.5,1
Könntet ihr mir da helfen?
Hallo kotaro,
ich versuche es mir die Woche mal anzusehen. Ist alles schon ne Weile her.
Hast du ggf. noch was aus dem Log?
Risiko.
na klar:
2019.10.03 18:58:53 5: weekprofile_test_1(Notify): HM_CLONE_WT_Wohnzimmer, 2.SET_TEMPERATURE:
2019.10.03 18:58:53 4: weekprofile_test_1(Notify): reread master profile from HM_CLONE_WT_Wohnzimmer
2019.10.03 18:58:53 5: weekprofile_test_1(readDayProfile): read from type HMCCU_HM
2019.10.03 18:58:53 5: weekprofile_test_1(readDayProfile): MONDAY_1
2019.10.03 18:58:53 1: PERL WARNING: Argument "" isn't numeric in division (/) at ./FHEM/98_weekprofile.pm line 77.
2019.10.03 18:58:53 1: stacktrace:
2019.10.03 18:58:53 1: main::__ANON__ called by ./FHEM/98_weekprofile.pm (77)
2019.10.03 18:58:53 1: main::weekprofile_minutesToTime called by ./FHEM/98_weekprofile.pm (235)
2019.10.03 18:58:53 1: main::weekprofile_readDayProfile called by ./FHEM/98_weekprofile.pm (275)
2019.10.03 18:58:53 1: main::weekprofile_readDevProfile called by ./FHEM/98_weekprofile.pm (1130)
2019.10.03 18:58:53 1: main::weekprofile_Notify called by fhem.pl (3752)
2019.10.03 18:58:53 1: main::CallFn called by fhem.pl (3672)
2019.10.03 18:58:53 1: main::DoTrigger called by fhem.pl (4735)
2019.10.03 18:58:53 1: main::readingsEndUpdate called by ./FHEM/88_HMCCU.pm (3415)
2019.10.03 18:58:53 1: main::HMCCU_UpdateSingleDevice called by ./FHEM/88_HMCCU.pm (3471)
2019.10.03 18:58:53 1: main::HMCCU_UpdateMultipleDevices called by ./FHEM/88_HMCCURPCPROC.pm (734)
2019.10.03 18:58:53 1: main::HMCCURPCPROC_Read called by fhem.pl (3752)
2019.10.03 18:58:53 1: main::CallFn called by fhem.pl (750)
2019.10.03 18:58:53 5: weekprofile_test_1(readDayProfile): MONDAY_2
2019.10.03 18:58:53 1: PERL WARNING: Argument "" isn't numeric in division (/) at ./FHEM/98_weekprofile.pm line 77.
2019.10.03 18:58:53 1: stacktrace:
2019.10.03 18:58:53 1: main::__ANON__ called by ./FHEM/98_weekprofile.pm (77)
2019.10.03 18:58:53 1: main::weekprofile_minutesToTime called by ./FHEM/98_weekprofile.pm (235)
2019.10.03 18:58:53 1: main::weekprofile_readDayProfile called by ./FHEM/98_weekprofile.pm (275)
2019.10.03 18:58:53 1: main::weekprofile_readDevProfile called by ./FHEM/98_weekprofile.pm (1130)
2019.10.03 18:58:53 1: main::weekprofile_Notify called by fhem.pl (3752)
2019.10.03 18:58:53 1: main::CallFn called by fhem.pl (3672)
2019.10.03 18:58:53 1: main::DoTrigger called by fhem.pl (4735)
2019.10.03 18:58:53 1: main::readingsEndUpdate called by ./FHEM/88_HMCCU.pm (3415)
2019.10.03 18:58:53 1: main::HMCCU_UpdateSingleDevice called by ./FHEM/88_HMCCU.pm (3471)
2019.10.03 18:58:53 1: main::HMCCU_UpdateMultipleDevices called by ./FHEM/88_HMCCURPCPROC.pm (734)
2019.10.03 18:58:53 1: main::HMCCURPCPROC_Read called by fhem.pl (3752)
2019.10.03 18:58:53 1: main::CallFn called by fhem.pl (750)
2019.10.03 18:58:53 5: weekprofile_test_1(readDayProfile): MONDAY_3
2019.10.03 18:58:53 1: PERL WARNING: Argument "" isn't numeric in division (/) at ./FHEM/98_weekprofile.pm line 77.
2019.10.03 18:58:53 1: stacktrace:
2019.10.03 18:58:53 1: main::__ANON__ called by ./FHEM/98_weekprofile.pm (77)
2019.10.03 18:58:53 1: main::weekprofile_minutesToTime called by ./FHEM/98_weekprofile.pm (235)
2019.10.03 18:58:53 1: main::weekprofile_readDayProfile called by ./FHEM/98_weekprofile.pm (275)
2019.10.03 18:58:53 1: main::weekprofile_readDevProfile called by ./FHEM/98_weekprofile.pm (1130)
2019.10.03 18:58:53 1: main::weekprofile_Notify called by fhem.pl (3752)
2019.10.03 18:58:53 1: main::CallFn called by fhem.pl (3672)
2019.10.03 18:58:53 1: main::DoTrigger called by fhem.pl (4735)
2019.10.03 18:58:53 1: main::readingsEndUpdate called by ./FHEM/88_HMCCU.pm (3415)
2019.10.03 18:58:53 1: main::HMCCU_UpdateSingleDevice called by ./FHEM/88_HMCCU.pm (3471)
2019.10.03 18:58:53 1: main::HMCCU_UpdateMultipleDevices called by ./FHEM/88_HMCCURPCPROC.pm (734)
2019.10.03 18:58:53 1: main::HMCCURPCPROC_Read called by fhem.pl (3752)
2019.10.03 18:58:53 1: main::CallFn called by fhem.pl (750)
2019.10.03 18:58:53 5: weekprofile_test_1(readDayProfile): MONDAY_4
2019.10.03 18:58:53 1: PERL WARNING: Argument "" isn't numeric in division (/) at ./FHEM/98_weekprofile.pm line 77.
2019.10.03 18:58:53 1: stacktrace:
2019.10.03 18:58:53 1: main::__ANON__ called by ./FHEM/98_weekprofile.pm (77)
2019.10.03 18:58:53 1: main::weekprofile_minutesToTime called by ./FHEM/98_weekprofile.pm (235)
2019.10.03 18:58:53 1: main::weekprofile_readDayProfile called by ./FHEM/98_weekprofile.pm (275)
2019.10.03 18:58:53 1: main::weekprofile_readDevProfile called by ./FHEM/98_weekprofile.pm (1130)
2019.10.03 18:58:53 1: main::weekprofile_Notify called by fhem.pl (3752)
2019.10.03 18:58:53 1: main::CallFn called by fhem.pl (3672)
2019.10.03 18:58:53 1: main::DoTrigger called by fhem.pl (4735)
2019.10.03 18:58:53 1: main::readingsEndUpdate called by ./FHEM/88_HMCCU.pm (3415)
2019.10.03 18:58:53 1: main::HMCCU_UpdateSingleDevice called by ./FHEM/88_HMCCU.pm (3471)
2019.10.03 18:58:53 1: main::HMCCU_UpdateMultipleDevices called by ./FHEM/88_HMCCURPCPROC.pm (734)
2019.10.03 18:58:53 1: main::HMCCURPCPROC_Read called by fhem.pl (3752)
2019.10.03 18:58:53 1: main::CallFn called by fhem.pl (750)
2019.10.03 18:58:53 5: weekprofile_test_1(readDayProfile): MONDAY_5
2019.10.03 18:58:53 1: PERL WARNING: Argument "" isn't numeric in division (/) at ./FHEM/98_weekprofile.pm line 77.
2019.10.03 18:58:53 1: stacktrace:
2019.10.03 18:58:53 1: main::__ANON__ called by ./FHEM/98_weekprofile.pm (77)
2019.10.03 18:58:53 1: main::weekprofile_minutesToTime called by ./FHEM/98_weekprofile.pm (235)
2019.10.03 18:58:53 1: main::weekprofile_readDayProfile called by ./FHEM/98_weekprofile.pm (275)
2019.10.03 18:58:53 1: main::weekprofile_readDevProfile called by ./FHEM/98_weekprofile.pm (1130)
2019.10.03 18:58:53 1: main::weekprofile_Notify called by fhem.pl (3752)
2019.10.03 18:58:53 1: main::CallFn called by fhem.pl (3672)
2019.10.03 18:58:53 1: main::DoTrigger called by fhem.pl (4735)
2019.10.03 18:58:53 1: main::readingsEndUpdate called by ./FHEM/88_HMCCU.pm (3415)
2019.10.03 18:58:53 1: main::HMCCU_UpdateSingleDevice called by ./FHEM/88_HMCCU.pm (3471)
2019.10.03 18:58:53 1: main::HMCCU_UpdateMultipleDevices called by ./FHEM/88_HMCCURPCPROC.pm (734)
2019.10.03 18:58:53 1: main::HMCCURPCPROC_Read called by fhem.pl (3752)
2019.10.03 18:58:53 1: main::CallFn called by fhem.pl (750)
2019.10.03 18:58:53 5: weekprofile_test_1(readDayProfile): MONDAY_6
2019.10.03 18:58:53 1: PERL WARNING: Argument "" isn't numeric in division (/) at ./FHEM/98_weekprofile.pm line 77.
2019.10.03 18:58:53 1: stacktrace:
2019.10.03 18:58:53 1: main::__ANON__ called by ./FHEM/98_weekprofile.pm (77)
2019.10.03 18:58:53 1: main::weekprofile_minutesToTime called by ./FHEM/98_weekprofile.pm (235)
2019.10.03 18:58:53 1: main::weekprofile_readDayProfile called by ./FHEM/98_weekprofile.pm (275)
2019.10.03 18:58:53 1: main::weekprofile_readDevProfile called by ./FHEM/98_weekprofile.pm (1130)
2019.10.03 18:58:53 1: main::weekprofile_Notify called by fhem.pl (3752)
2019.10.03 18:58:53 1: main::CallFn called by fhem.pl (3672)
2019.10.03 18:58:53 1: main::DoTrigger called by fhem.pl (4735)
2019.10.03 18:58:53 1: main::readingsEndUpdate called by ./FHEM/88_HMCCU.pm (3415)
2019.10.03 18:58:53 1: main::HMCCU_UpdateSingleDevice called by ./FHEM/88_HMCCU.pm (3471)
2019.10.03 18:58:53 1: main::HMCCU_UpdateMultipleDevices called by ./FHEM/88_HMCCURPCPROC.pm (734)
2019.10.03 18:58:53 1: main::HMCCURPCPROC_Read called by fhem.pl (3752)
2019.10.03 18:58:53 1: main::CallFn called by fhem.pl (750)
2019.10.03 18:58:53 5: weekprofile_test_1(readDayProfile): MONDAY_7
2019.10.03 18:58:53 1: PERL WARNING: Argument "" isn't numeric in division (/) at ./FHEM/98_weekprofile.pm line 77.
2019.10.03 18:58:53 1: stacktrace:
2019.10.03 18:58:53 1: main::__ANON__ called by ./FHEM/98_weekprofile.pm (77)
2019.10.03 18:58:53 1: main::weekprofile_minutesToTime called by ./FHEM/98_weekprofile.pm (235)
2019.10.03 18:58:53 1: main::weekprofile_readDayProfile called by ./FHEM/98_weekprofile.pm (275)
2019.10.03 18:58:53 1: main::weekprofile_readDevProfile called by ./FHEM/98_weekprofile.pm (1130)
2019.10.03 18:58:53 1: main::weekprofile_Notify called by fhem.pl (3752)
2019.10.03 18:58:53 1: main::CallFn called by fhem.pl (3672)
2019.10.03 18:58:53 1: main::DoTrigger called by fhem.pl (4735)
2019.10.03 18:58:53 1: main::readingsEndUpdate called by ./FHEM/88_HMCCU.pm (3415)
2019.10.03 18:58:53 1: main::HMCCU_UpdateSingleDevice called by ./FHEM/88_HMCCU.pm (3471)
2019.10.03 18:58:53 1: main::HMCCU_UpdateMultipleDevices called by ./FHEM/88_HMCCURPCPROC.pm (734)
2019.10.03 18:58:53 1: main::HMCCURPCPROC_Read called by fhem.pl (3752)
2019.10.03 18:58:53 1: main::CallFn called by fhem.pl (750)
2019.10.03 18:58:53 5: weekprofile_test_1(readDayProfile): MONDAY_8
2019.10.03 18:58:53 1: PERL WARNING: Argument "" isn't numeric in division (/) at ./FHEM/98_weekprofile.pm line 77.
2019.10.03 18:58:53 1: stacktrace:
2019.10.03 18:58:53 1: main::__ANON__ called by ./FHEM/98_weekprofile.pm (77)
2019.10.03 18:58:53 1: main::weekprofile_minutesToTime called by ./FHEM/98_weekprofile.pm (235)
2019.10.03 18:58:53 1: main::weekprofile_readDayProfile called by ./FHEM/98_weekprofile.pm (275)
2019.10.03 18:58:53 1: main::weekprofile_readDevProfile called by ./FHEM/98_weekprofile.pm (1130)
2019.10.03 18:58:53 1: main::weekprofile_Notify called by fhem.pl (3752)
2019.10.03 18:58:53 1: main::CallFn called by fhem.pl (3672)
2019.10.03 18:58:53 1: main::DoTrigger called by fhem.pl (4735)
2019.10.03 18:58:53 1: main::readingsEndUpdate called by ./FHEM/88_HMCCU.pm (3415)
2019.10.03 18:58:53 1: main::HMCCU_UpdateSingleDevice called by ./FHEM/88_HMCCU.pm (3471)
2019.10.03 18:58:53 1: main::HMCCU_UpdateMultipleDevices called by ./FHEM/88_HMCCURPCPROC.pm (734)
2019.10.03 18:58:53 1: main::HMCCURPCPROC_Read called by fhem.pl (3752)
2019.10.03 18:58:53 1: main::CallFn called by fhem.pl (750)
2019.10.03 18:58:53 5: weekprofile_test_1(readDayProfile): MONDAY_9
2019.10.03 18:58:53 1: PERL WARNING: Argument "" isn't numeric in division (/) at ./FHEM/98_weekprofile.pm line 77.
2019.10.03 18:58:53 1: stacktrace:
2019.10.03 18:58:53 1: main::__ANON__ called by ./FHEM/98_weekprofile.pm (77)
2019.10.03 18:58:53 1: main::weekprofile_minutesToTime called by ./FHEM/98_weekprofile.pm (235)
2019.10.03 18:58:53 1: main::weekprofile_readDayProfile called by ./FHEM/98_weekprofile.pm (275)
2019.10.03 18:58:53 1: main::weekprofile_readDevProfile called by ./FHEM/98_weekprofile.pm (1130)
2019.10.03 18:58:53 1: main::weekprofile_Notify called by fhem.pl (3752)
2019.10.03 18:58:53 1: main::CallFn called by fhem.pl (3672)
2019.10.03 18:58:53 1: main::DoTrigger called by fhem.pl (4735)
2019.10.03 18:58:53 1: main::readingsEndUpdate called by ./FHEM/88_HMCCU.pm (3415)
2019.10.03 18:58:53 1: main::HMCCU_UpdateSingleDevice called by ./FHEM/88_HMCCU.pm (3471)
2019.10.03 18:58:53 1: main::HMCCU_UpdateMultipleDevices called by ./FHEM/88_HMCCURPCPROC.pm (734)
2019.10.03 18:58:53 1: main::HMCCURPCPROC_Read called by fhem.pl (3752)
2019.10.03 18:58:53 1: main::CallFn called by fhem.pl (750)
2019.10.03 18:58:53 5: weekprofile_test_1(readDayProfile): MONDAY_10
2019.10.03 18:58:53 1: PERL WARNING: Argument "" isn't numeric in division (/) at ./FHEM/98_weekprofile.pm line 77.
2019.10.03 18:58:53 1: stacktrace:
2019.10.03 18:58:53 1: main::__ANON__ called by ./FHEM/98_weekprofile.pm (77)
2019.10.03 18:58:53 1: main::weekprofile_minutesToTime called by ./FHEM/98_weekprofile.pm (235)
2019.10.03 18:58:53 1: main::weekprofile_readDayProfile called by ./FHEM/98_weekprofile.pm (275)
2019.10.03 18:58:53 1: main::weekprofile_readDevProfile called by ./FHEM/98_weekprofile.pm (1130)
2019.10.03 18:58:53 1: main::weekprofile_Notify called by fhem.pl (3752)
2019.10.03 18:58:53 1: main::CallFn called by fhem.pl (3672)
2019.10.03 18:58:53 1: main::DoTrigger called by fhem.pl (4735)
2019.10.03 18:58:53 1: main::readingsEndUpdate called by ./FHEM/88_HMCCU.pm (3415)
2019.10.03 18:58:53 1: main::HMCCU_UpdateSingleDevice called by ./FHEM/88_HMCCU.pm (3471)
2019.10.03 18:58:53 1: main::HMCCU_UpdateMultipleDevices called by ./FHEM/88_HMCCURPCPROC.pm (734)
2019.10.03 18:58:53 1: main::HMCCURPCPROC_Read called by fhem.pl (3752)
2019.10.03 18:58:53 1: main::CallFn called by fhem.pl (750)
2019.10.03 18:58:53 5: weekprofile_test_1(readDayProfile): MONDAY_11
2019.10.03 18:58:53 1: PERL WARNING: Argument "" isn't numeric in division (/) at ./FHEM/98_weekprofile.pm line 77.
2019.10.03 18:58:53 1: stacktrace:
2019.10.03 18:58:53 1: main::__ANON__ called by ./FHEM/98_weekprofile.pm (77)
2019.10.03 18:58:53 1: main::weekprofile_minutesToTime called by ./FHEM/98_weekprofile.pm (235)
2019.10.03 18:58:53 1: main::weekprofile_readDayProfile called by ./FHEM/98_weekprofile.pm (275)
2019.10.03 18:58:53 1: main::weekprofile_readDevProfile called by ./FHEM/98_weekprofile.pm (1130)
2019.10.03 18:58:53 1: main::weekprofile_Notify called by fhem.pl (3752)
2019.10.03 18:58:53 1: main::CallFn called by fhem.pl (3672)
2019.10.03 18:58:53 1: main::DoTrigger called by fhem.pl (4735)
2019.10.03 18:58:53 1: main::readingsEndUpdate called by ./FHEM/88_HMCCU.pm (3415)
2019.10.03 18:58:53 1: main::HMCCU_UpdateSingleDevice called by ./FHEM/88_HMCCU.pm (3471)
2019.10.03 18:58:53 1: main::HMCCU_UpdateMultipleDevices called by ./FHEM/88_HMCCURPCPROC.pm (734)
2019.10.03 18:58:53 1: main::HMCCURPCPROC_Read called by fhem.pl (3752)
2019.10.03 18:58:53 1: main::CallFn called by fhem.pl (750)
2019.10.03 18:58:53 5: weekprofile_test_1(readDayProfile): MONDAY_12
2019.10.03 18:58:53 1: PERL WARNING: Argument "" isn't numeric in division (/) at ./FHEM/98_weekprofile.pm line 77.
2019.10.03 18:58:53 1: stacktrace:
2019.10.03 18:58:53 1: main::__ANON__ called by ./FHEM/98_weekprofile.pm (77)
2019.10.03 18:58:53 1: main::weekprofile_minutesToTime called by ./FHEM/98_weekprofile.pm (235)
2019.10.03 18:58:53 1: main::weekprofile_readDayProfile called by ./FHEM/98_weekprofile.pm (275)
2019.10.03 18:58:53 1: main::weekprofile_readDevProfile called by ./FHEM/98_weekprofile.pm (1130)
2019.10.03 18:58:53 1: main::weekprofile_Notify called by fhem.pl (3752)
2019.10.03 18:58:53 1: main::CallFn called by fhem.pl (3672)
2019.10.03 18:58:53 1: main::DoTrigger called by fhem.pl (4735)
2019.10.03 18:58:53 1: main::readingsEndUpdate called by ./FHEM/88_HMCCU.pm (3415)
2019.10.03 18:58:53 1: main::HMCCU_UpdateSingleDevice called by ./FHEM/88_HMCCU.pm (3471)
2019.10.03 18:58:53 1: main::HMCCU_UpdateMultipleDevices called by ./FHEM/88_HMCCURPCPROC.pm (734)
2019.10.03 18:58:53 1: main::HMCCURPCPROC_Read called by fhem.pl (3752)
2019.10.03 18:58:53 1: main::CallFn called by fhem.pl (750)
2019.10.03 18:58:53 5: weekprofile_test_1(readDayProfile): MONDAY_13
2019.10.03 18:58:53 1: PERL WARNING: Argument "" isn't numeric in division (/) at ./FHEM/98_weekprofile.pm line 77.
2019.10.03 18:58:53 1: stacktrace:
2019.10.03 18:58:53 1: main::__ANON__ called by ./FHEM/98_weekprofile.pm (77)
2019.10.03 18:58:53 1: main::weekprofile_minutesToTime called by ./FHEM/98_weekprofile.pm (235)
2019.10.03 18:58:53 1: main::weekprofile_readDayProfile called by ./FHEM/98_weekprofile.pm (275)
2019.10.03 18:58:53 1: main::weekprofile_readDevProfile called by ./FHEM/98_weekprofile.pm (1130)
2019.10.03 18:58:53 1: main::weekprofile_Notify called by fhem.pl (3752)
2019.10.03 18:58:53 1: main::CallFn called by fhem.pl (3672)
2019.10.03 18:58:53 1: main::DoTrigger called by fhem.pl (4735)
2019.10.03 18:58:53 1: main::readingsEndUpdate called by ./FHEM/88_HMCCU.pm (3415)
2019.10.03 18:58:53 1: main::HMCCU_UpdateSingleDevice called by ./FHEM/88_HMCCU.pm (3471)
2019.10.03 18:58:53 1: main::HMCCU_UpdateMultipleDevices called by ./FHEM/88_HMCCURPCPROC.pm (734)
2019.10.03 18:58:53 1: main::HMCCURPCPROC_Read called by fhem.pl (3752)
2019.10.03 18:58:53 1: main::CallFn called by fhem.pl (750)
2019.10.03 18:58:53 4: weekprofile_test_1(ReadDayProfile): temp 0
2019.10.03 18:58:53 4: weekprofile_test_1(ReadDayProfile): temp 1
2019.10.03 18:58:53 4: weekprofile_test_1(ReadDayProfile): temp 2
2019.10.03 18:58:53 4: weekprofile_test_1(ReadDayProfile): temp 3
2019.10.03 18:58:53 4: weekprofile_test_1(ReadDayProfile): temp 4
2019.10.03 18:58:53 4: weekprofile_test_1(ReadDayProfile): temp 5
2019.10.03 18:58:53 4: weekprofile_test_1(ReadDayProfile): temp 6
2019.10.03 18:58:53 4: weekprofile_test_1(ReadDayProfile): temp 7
2019.10.03 18:58:53 4: weekprofile_test_1(ReadDayProfile): temp 8
2019.10.03 18:58:53 4: weekprofile_test_1(ReadDayProfile): temp 9
2019.10.03 18:58:53 4: weekprofile_test_1(ReadDayProfile): temp 10
2019.10.03 18:58:53 4: weekprofile_test_1(ReadDayProfile): temp 11
2019.10.03 18:58:53 4: weekprofile_test_1(ReadDayProfile): temp 12
2019.10.03 18:58:53 5: weekprofile_test_1(readDayProfile): read from type HMCCU_HM
2019.10.03 18:58:53 5: weekprofile_test_1(readDayProfile): TUESDAY_1
2019.10.03 18:58:53 1: PERL WARNING: Argument "" isn't numeric in division (/) at ./FHEM/98_weekprofile.pm line 77.
2019.10.03 18:58:53 1: stacktrace:
2019.10.03 18:58:53 1: main::__ANON__ called by ./FHEM/98_weekprofile.pm (77)
2019.10.03 18:58:53 1: main::weekprofile_minutesToTime called by ./FHEM/98_weekprofile.pm (235)
2019.10.03 18:58:53 1: main::weekprofile_readDayProfile called by ./FHEM/98_weekprofile.pm (275)
2019.10.03 18:58:53 1: main::weekprofile_readDevProfile called by ./FHEM/98_weekprofile.pm (1130)
2019.10.03 18:58:53 1: main::weekprofile_Notify called by fhem.pl (3752)
2019.10.03 18:58:53 1: main::CallFn called by fhem.pl (3672)
2019.10.03 18:58:53 1: main::DoTrigger called by fhem.pl (4735)
2019.10.03 18:58:53 1: main::readingsEndUpdate called by ./FHEM/88_HMCCU.pm (3415)
2019.10.03 18:58:53 1: main::HMCCU_UpdateSingleDevice called by ./FHEM/88_HMCCU.pm (3471)
2019.10.03 18:58:53 1: main::HMCCU_UpdateMultipleDevices called by ./FHEM/88_HMCCURPCPROC.pm (734)
2019.10.03 18:58:53 1: main::HMCCURPCPROC_Read called by fhem.pl (3752)
2019.10.03 18:58:53 1: main::CallFn called by fhem.pl (750)
2019.10.03 18:58:53 5: weekprofile_test_1(readDayProfile): TUESDAY_2
2019.10.03 18:58:53 1: PERL WARNING: Argument "" isn't numeric in division (/) at ./FHEM/98_weekprofile.pm line 77.
2019.10.03 18:58:53 1: stacktrace:
2019.10.03 18:58:53 1: main::__ANON__ called by ./FHEM/98_weekprofile.pm (77)
2019.10.03 18:58:53 1: main::weekprofile_minutesToTime called by ./FHEM/98_weekprofile.pm (235)
2019.10.03 18:58:53 1: main::weekprofile_readDayProfile called by ./FHEM/98_weekprofile.pm (275)
2019.10.03 18:58:53 1: main::weekprofile_readDevProfile called by ./FHEM/98_weekprofile.pm (1130)
2019.10.03 18:58:53 1: main::weekprofile_Notify called by fhem.pl (3752)
2019.10.03 18:58:53 1: main::CallFn called by fhem.pl (3672)
2019.10.03 18:58:53 1: main::DoTrigger called by fhem.pl (4735)
2019.10.03 18:58:53 1: main::readingsEndUpdate called by ./FHEM/88_HMCCU.pm (3415)
2019.10.03 18:58:53 1: main::HMCCU_UpdateSingleDevice called by ./FHEM/88_HMCCU.pm (3471)
2019.10.03 18:58:53 1: main::HMCCU_UpdateMultipleDevices called by ./FHEM/88_HMCCURPCPROC.pm (734)
2019.10.03 18:58:53 1: main::HMCCURPCPROC_Read called by fhem.pl (3752)
2019.10.03 18:58:53 1: main::CallFn called by fhem.pl (750)
2019.10.03 18:58:53 5: weekprofile_test_1(readDayProfile): TUESDAY_3
2019.10.03 18:58:53 1: PERL WARNING: Argument "" isn't numeric in division (/) at ./FHEM/98_weekprofile.pm line 77.
2019.10.03 18:58:53 1: stacktrace:
2019.10.03 18:58:53 1: main::__ANON__ called by ./FHEM/98_weekprofile.pm (77)
2019.10.03 18:58:53 1: main::weekprofile_minutesToTime called by ./FHEM/98_weekprofile.pm (235)
2019.10.03 18:58:53 1: main::weekprofile_readDayProfile called by ./FHEM/98_weekprofile.pm (275)
2019.10.03 18:58:53 1: main::weekprofile_readDevProfile called by ./FHEM/98_weekprofile.pm (1130)
2019.10.03 18:58:53 1: main::weekprofile_Notify called by fhem.pl (3752)
2019.10.03 18:58:53 1: main::CallFn called by fhem.pl (3672)
2019.10.03 18:58:53 1: main::DoTrigger called by fhem.pl (4735)
2019.10.03 18:58:53 1: main::readingsEndUpdate called by ./FHEM/88_HMCCU.pm (3415)
2019.10.03 18:58:53 1: main::HMCCU_UpdateSingleDevice called by ./FHEM/88_HMCCU.pm (3471)
2019.10.03 18:58:53 1: main::HMCCU_UpdateMultipleDevices called by ./FHEM/88_HMCCURPCPROC.pm (734)
2019.10.03 18:58:53 1: main::HMCCURPCPROC_Read called by fhem.pl (3752)
2019.10.03 18:58:53 1: main::CallFn called by fhem.pl (750)
2019.10.03 18:58:53 5: weekprofile_test_1(readDayProfile): TUESDAY_4
2019.10.03 18:58:53 1: PERL WARNING: Argument "" isn't numeric in division (/) at ./FHEM/98_weekprofile.pm line 77.
2019.10.03 18:58:53 1: stacktrace:
2019.10.03 18:58:53 1: main::__ANON__ called by ./FHEM/98_weekprofile.pm (77)
2019.10.03 18:58:53 1: main::weekprofile_minutesToTime called by ./FHEM/98_weekprofile.pm (235)
2019.10.03 18:58:53 1: main::weekprofile_readDayProfile called by ./FHEM/98_weekprofile.pm (275)
2019.10.03 18:58:53 1: main::weekprofile_readDevProfile called by ./FHEM/98_weekprofile.pm (1130)
2019.10.03 18:58:53 1: main::weekprofile_Notify called by fhem.pl (3752)
2019.10.03 18:58:53 1: main::CallFn called by fhem.pl (3672)
2019.10.03 18:58:53 1: main::DoTrigger called by fhem.pl (4735)
2019.10.03 18:58:53 1: main::readingsEndUpdate called by ./FHEM/88_HMCCU.pm (3415)
2019.10.03 18:58:53 1: main::HMCCU_UpdateSingleDevice called by ./FHEM/88_HMCCU.pm (3471)
2019.10.03 18:58:53 1: main::HMCCU_UpdateMultipleDevices called by ./FHEM/88_HMCCURPCPROC.pm (734)
2019.10.03 18:58:53 1: main::HMCCURPCPROC_Read called by fhem.pl (3752)
2019.10.03 18:58:53 1: main::CallFn called by fhem.pl (750)
2019.10.03 18:58:53 5: weekprofile_test_1(readDayProfile): TUESDAY_5
2019.10.03 18:58:53 1: PERL WARNING: Argument "" isn't numeric in division (/) at ./FHEM/98_weekprofile.pm line 77.
2019.10.03 18:58:53 1: stacktrace:
2019.10.03 18:58:53 1: main::__ANON__ called by ./FHEM/98_weekprofile.pm (77)
2019.10.03 18:58:53 1: main::weekprofile_minutesToTime called by ./FHEM/98_weekprofile.pm (235)
2019.10.03 18:58:53 1: main::weekprofile_readDayProfile called by ./FHEM/98_weekprofile.pm (275)
2019.10.03 18:58:53 1: main::weekprofile_readDevProfile called by ./FHEM/98_weekprofile.pm (1130)
2019.10.03 18:58:53 1: main::weekprofile_Notify called by fhem.pl (3752)
2019.10.03 18:58:53 1: main::CallFn called by fhem.pl (3672)
2019.10.03 18:58:53 1: main::DoTrigger called by fhem.pl (4735)
2019.10.03 18:58:53 1: main::readingsEndUpdate called by ./FHEM/88_HMCCU.pm (3415)
2019.10.03 18:58:53 1: main::HMCCU_UpdateSingleDevice called by ./FHEM/88_HMCCU.pm (3471)
2019.10.03 18:58:53 1: main::HMCCU_UpdateMultipleDevices called by ./FHEM/88_HMCCURPCPROC.pm (734)
2019.10.03 18:58:53 1: main::HMCCURPCPROC_Read called by fhem.pl (3752)
2019.10.03 18:58:53 1: main::CallFn called by fhem.pl (750)
2019.10.03 18:58:53 5: weekprofile_test_1(readDayProfile): TUESDAY_6
2019.10.03 18:58:53 1: PERL WARNING: Argument "" isn't numeric in division (/) at ./FHEM/98_weekprofile.pm line 77.
2019.10.03 18:58:53 1: stacktrace:
2019.10.03 18:58:53 1: main::__ANON__ called by ./FHEM/98_weekprofile.pm (77)
2019.10.03 18:58:53 1: main::weekprofile_minutesToTime called by ./FHEM/98_weekprofile.pm (235)
2019.10.03 18:58:53 1: main::weekprofile_readDayProfile called by ./FHEM/98_weekprofile.pm (275)
2019.10.03 18:58:53 1: main::weekprofile_readDevProfile called by ./FHEM/98_weekprofile.pm (1130)
2019.10.03 18:58:53 1: main::weekprofile_Notify called by fhem.pl (3752)
2019.10.03 18:58:53 1: main::CallFn called by fhem.pl (3672)
2019.10.03 18:58:53 1: main::DoTrigger called by fhem.pl (4735)
2019.10.03 18:58:53 1: main::readingsEndUpdate called by ./FHEM/88_HMCCU.pm (3415)
2019.10.03 18:58:53 1: main::HMCCU_UpdateSingleDevice called by ./FHEM/88_HMCCU.pm (3471)
2019.10.03 18:58:53 1: main::HMCCU_UpdateMultipleDevices called by ./FHEM/88_HMCCURPCPROC.pm (734)
2019.10.03 18:58:53 1: main::HMCCURPCPROC_Read called by fhem.pl (3752)
2019.10.03 18:58:53 1: main::CallFn called by fhem.pl (750)
2019.10.03 18:58:53 5: weekprofile_test_1(readDayProfile): TUESDAY_7
2019.10.03 18:58:53 1: PERL WARNING: Argument "" isn't numeric in division (/) at ./FHEM/98_weekprofile.pm line 77.
2019.10.03 18:58:53 1: stacktrace:
2019.10.03 18:58:53 1: main::__ANON__ called by ./FHEM/98_weekprofile.pm (77)
2019.10.03 18:58:53 1: main::weekprofile_minutesToTime called by ./FHEM/98_weekprofile.pm (235)
2019.10.03 18:58:53 1: main::weekprofile_readDayProfile called by ./FHEM/98_weekprofile.pm (275)
2019.10.03 18:58:53 1: main::weekprofile_readDevProfile called by ./FHEM/98_weekprofile.pm (1130)
2019.10.03 18:58:53 1: main::weekprofile_Notify called by fhem.pl (3752)
2019.10.03 18:58:53 1: main::CallFn called by fhem.pl (3672)
2019.10.03 18:58:53 1: main::DoTrigger called by fhem.pl (4735)
2019.10.03 18:58:53 1: main::readingsEndUpdate called by ./FHEM/88_HMCCU.pm (3415)
2019.10.03 18:58:53 1: main::HMCCU_UpdateSingleDevice called by ./FHEM/88_HMCCU.pm (3471)
2019.10.03 18:58:53 1: main::HMCCU_UpdateMultipleDevices called by ./FHEM/88_HMCCURPCPROC.pm (734)
2019.10.03 18:58:53 1: main::HMCCURPCPROC_Read called by fhem.pl (3752)
2019.10.03 18:58:53 1: main::CallFn called by fhem.pl (750)
2019.10.03 18:58:53 5: weekprofile_test_1(readDayProfile): TUESDAY_8
2019.10.03 18:58:53 1: PERL WARNING: Argument "" isn't numeric in division (/) at ./FHEM/98_weekprofile.pm line 77.
2019.10.03 18:58:53 1: stacktrace:
2019.10.03 18:58:53 1: main::__ANON__ called by ./FHEM/98_weekprofile.pm (77)
2019.10.03 18:58:53 1: main::weekprofile_minutesToTime called by ./FHEM/98_weekprofile.pm (235)
2019.10.03 18:58:53 1: main::weekprofile_readDayProfile called by ./FHEM/98_weekprofile.pm (275)
2019.10.03 18:58:53 1: main::weekprofile_readDevProfile called by ./FHEM/98_weekprofile.pm (1130)
2019.10.03 18:58:53 1: main::weekprofile_Notify called by fhem.pl (3752)
2019.10.03 18:58:53 1: main::CallFn called by fhem.pl (3672)
2019.10.03 18:58:53 1: main::DoTrigger called by fhem.pl (4735)
2019.10.03 18:58:53 1: main::readingsEndUpdate called by ./FHEM/88_HMCCU.pm (3415)
2019.10.03 18:58:53 1: main::HMCCU_UpdateSingleDevice called by ./FHEM/88_HMCCU.pm (3471)
2019.10.03 18:58:53 1: main::HMCCU_UpdateMultipleDevices called by ./FHEM/88_HMCCURPCPROC.pm (734)
2019.10.03 18:58:53 1: main::HMCCURPCPROC_Read called by fhem.pl (3752)
2019.10.03 18:58:53 1: main::CallFn called by fhem.pl (750)
2019.10.03 18:58:53 5: weekprofile_test_1(readDayProfile): TUESDAY_9
2019.10.03 18:58:53 1: PERL WARNING: Argument "" isn't numeric in division (/) at ./FHEM/98_weekprofile.pm line 77.
2019.10.03 18:58:53 1: stacktrace:
2019.10.03 18:58:53 1: main::__ANON__ called by ./FHEM/98_weekprofile.pm (77)
2019.10.03 18:58:53 1: main::weekprofile_minutesToTime called by ./FHEM/98_weekprofile.pm (235)
2019.10.03 18:58:53 1: main::weekprofile_readDayProfile called by ./FHEM/98_weekprofile.pm (275)
2019.10.03 18:58:53 1: main::weekprofile_readDevProfile called by ./FHEM/98_weekprofile.pm (1130)
2019.10.03 18:58:53 1: main::weekprofile_Notify called by fhem.pl (3752)
2019.10.03 18:58:53 1: main::CallFn called by fhem.pl (3672)
2019.10.03 18:58:53 1: main::DoTrigger called by fhem.pl (4735)
2019.10.03 18:58:53 1: main::readingsEndUpdate called by ./FHEM/88_HMCCU.pm (3415)
2019.10.03 18:58:53 1: main::HMCCU_UpdateSingleDevice called by ./FHEM/88_HMCCU.pm (3471)
2019.10.03 18:58:53 1: main::HMCCU_UpdateMultipleDevices called by ./FHEM/88_HMCCURPCPROC.pm (734)
2019.10.03 18:58:53 1: main::HMCCURPCPROC_Read called by fhem.pl (3752)
2019.10.03 18:58:53 1: main::CallFn called by fhem.pl (750)
2019.10.03 18:58:53 5: weekprofile_test_1(readDayProfile): TUESDAY_10
2019.10.03 18:58:53 1: PERL WARNING: Argument "" isn't numeric in division (/) at ./FHEM/98_weekprofile.pm line 77.
2019.10.03 18:58:53 1: stacktrace:
2019.10.03 18:58:53 1: main::__ANON__ called by ./FHEM/98_weekprofile.pm (77)
2019.10.03 18:58:53 1: main::weekprofile_minutesToTime called by ./FHEM/98_weekprofile.pm (235)
2019.10.03 18:58:53 1: main::weekprofile_readDayProfile called by ./FHEM/98_weekprofile.pm (275)
2019.10.03 18:58:53 1: main::weekprofile_readDevProfile called by ./FHEM/98_weekprofile.pm (1130)
2019.10.03 18:58:53 1: main::weekprofile_Notify called by fhem.pl (3752)
2019.10.03 18:58:53 1: main::CallFn called by fhem.pl (3672)
2019.10.03 18:58:53 1: main::DoTrigger called by fhem.pl (4735)
2019.10.03 18:58:53 1: main::readingsEndUpdate called by ./FHEM/88_HMCCU.pm (3415)
2019.10.03 18:58:53 1: main::HMCCU_UpdateSingleDevice called by ./FHEM/88_HMCCU.pm (3471)
2019.10.03 18:58:53 1: main::HMCCU_UpdateMultipleDevices called by ./FHEM/88_HMCCURPCPROC.pm (734)
2019.10.03 18:58:53 1: main::HMCCURPCPROC_Read called by fhem.pl (3752)
2019.10.03 18:58:53 1: main::CallFn called by fhem.pl (750)
2019.10.03 18:58:53 5: weekprofile_test_1(readDayProfile): TUESDAY_11
2019.10.03 18:58:53 1: PERL WARNING: Argument "" isn't numeric in division (/) at ./FHEM/98_weekprofile.pm line 77.
2019.10.03 18:58:53 1: stacktrace:
2019.10.03 18:58:53 1: main::__ANON__ called by ./FHEM/98_weekprofile.pm (77)
2019.10.03 18:58:53 1: main::weekprofile_minutesToTime called by ./FHEM/98_weekprofile.pm (235)
2019.10.03 18:58:53 1: main::weekprofile_readDayProfile called by ./FHEM/98_weekprofile.pm (275)
2019.10.03 18:58:53 1: main::weekprofile_readDevProfile called by ./FHEM/98_weekprofile.pm (1130)
2019.10.03 18:58:53 1: main::weekprofile_Notify called by fhem.pl (3752)
2019.10.03 18:58:53 1: main::CallFn called by fhem.pl (3672)
2019.10.03 18:58:53 1: main::DoTrigger called by fhem.pl (4735)
2019.10.03 18:58:53 1: main::readingsEndUpdate called by ./FHEM/88_HMCCU.pm (3415)
2019.10.03 18:58:53 1: main::HMCCU_UpdateSingleDevice called by ./FHEM/88_HMCCU.pm (3471)
2019.10.03 18:58:53 1: main::HMCCU_UpdateMultipleDevices called by ./FHEM/88_HMCCURPCPROC.pm (734)
2019.10.03 18:58:53 1: main::HMCCURPCPROC_Read called by fhem.pl (3752)
2019.10.03 18:58:53 1: main::CallFn called by fhem.pl (750)
2019.10.03 18:58:53 5: weekprofile_test_1(readDayProfile): TUESDAY_12
2019.10.03 18:58:53 1: PERL WARNING: Argument "" isn't numeric in division (/) at ./FHEM/98_weekprofile.pm line 77.
2019.10.03 18:58:53 1: stacktrace:
2019.10.03 18:58:53 1: main::__ANON__ called by ./FHEM/98_weekprofile.pm (77)
2019.10.03 18:58:53 1: main::weekprofile_minutesToTime called by ./FHEM/98_weekprofile.pm (235)
2019.10.03 18:58:53 1: main::weekprofile_readDayProfile called by ./FHEM/98_weekprofile.pm (275)
2019.10.03 18:58:53 1: main::weekprofile_readDevProfile called by ./FHEM/98_weekprofile.pm (1130)
2019.10.03 18:58:53 1: main::weekprofile_Notify called by fhem.pl (3752)
2019.10.03 18:58:53 1: main::CallFn called by fhem.pl (3672)
2019.10.03 18:58:53 1: main::DoTrigger called by fhem.pl (4735)
2019.10.03 18:58:53 1: main::readingsEndUpdate called by ./FHEM/88_HMCCU.pm (3415)
2019.10.03 18:58:53 1: main::HMCCU_UpdateSingleDevice called by ./FHEM/88_HMCCU.pm (3471)
2019.10.03 18:58:53 1: main::HMCCU_UpdateMultipleDevices called by ./FHEM/88_HMCCURPCPROC.pm (734)
2019.10.03 18:58:53 1: main::HMCCURPCPROC_Read called by fhem.pl (3752)
2019.10.03 18:58:53 1: main::CallFn called by fhem.pl (750)
2019.10.03 18:58:53 5: weekprofile_test_1(readDayProfile): TUESDAY_13
2019.10.03 18:58:53 1: PERL WARNING: Argument "" isn't numeric in division (/) at ./FHEM/98_weekprofile.pm line 77.
2019.10.03 18:58:53 1: stacktrace:
2019.10.03 18:58:53 1: main::__ANON__ called by ./FHEM/98_weekprofile.pm (77)
2019.10.03 18:58:53 1: main::weekprofile_minutesToTime called by ./FHEM/98_weekprofile.pm (235)
2019.10.03 18:58:53 1: main::weekprofile_readDayProfile called by ./FHEM/98_weekprofile.pm (275)
2019.10.03 18:58:53 1: main::weekprofile_readDevProfile called by ./FHEM/98_weekprofile.pm (1130)
2019.10.03 18:58:53 1: main::weekprofile_Notify called by fhem.pl (3752)
2019.10.03 18:58:53 1: main::CallFn called by fhem.pl (3672)
2019.10.03 18:58:53 1: main::DoTrigger called by fhem.pl (4735)
2019.10.03 18:58:53 1: main::readingsEndUpdate called by ./FHEM/88_HMCCU.pm (3415)
2019.10.03 18:58:53 1: main::HMCCU_UpdateSingleDevice called by ./FHEM/88_HMCCU.pm (3471)
2019.10.03 18:58:53 1: main::HMCCU_UpdateMultipleDevices called by ./FHEM/88_HMCCURPCPROC.pm (734)
2019.10.03 18:58:53 1: main::HMCCURPCPROC_Read called by fhem.pl (3752)
2019.10.03 18:58:53 1: main::CallFn called by fhem.pl (750)
2019.10.03 18:58:53 4: weekprofile_test_1(ReadDayProfile): temp 0
2019.10.03 18:58:53 4: weekprofile_test_1(ReadDayProfile): temp 1
2019.10.03 18:58:53 4: weekprofile_test_1(ReadDayProfile): temp 2
2019.10.03 18:58:53 4: weekprofile_test_1(ReadDayProfile): temp 3
2019.10.03 18:58:53 4: weekprofile_test_1(ReadDayProfile): temp 4
2019.10.03 18:58:53 4: weekprofile_test_1(ReadDayProfile): temp 5
2019.10.03 18:58:53 4: weekprofile_test_1(ReadDayProfile): temp 6
2019.10.03 18:58:53 4: weekprofile_test_1(ReadDayProfile): temp 7
2019.10.03 18:58:53 4: weekprofile_test_1(ReadDayProfile): temp 8
2019.10.03 18:58:53 4: weekprofile_test_1(ReadDayProfile): temp 9
2019.10.03 18:58:53 4: weekprofile_test_1(ReadDayProfile): temp 10
2019.10.03 18:58:53 4: weekprofile_test_1(ReadDayProfile): temp 11
2019.10.03 18:58:53 4: weekprofile_test_1(ReadDayProfile): temp 12
2019.10.03 18:58:53 5: weekprofile_test_1(readDayProfile): read from type HMCCU_HM
2019.10.03 18:58:53 5: weekprofile_test_1(readDayProfile): WEDNESDAY_1
2019.10.03 18:58:53 1: PERL WARNING: Argument "" isn't numeric in division (/) at ./FHEM/98_weekprofile.pm line 77.
2019.10.03 18:58:53 1: stacktrace:
2019.10.03 18:58:53 1: main::__ANON__ called by ./FHEM/98_weekprofile.pm (77)
2019.10.03 18:58:53 1: main::weekprofile_minutesToTime called by ./FHEM/98_weekprofile.pm (235)
2019.10.03 18:58:53 1: main::weekprofile_readDayProfile called by ./FHEM/98_weekprofile.pm (275)
2019.10.03 18:58:53 1: main::weekprofile_readDevProfile called by ./FHEM/98_weekprofile.pm (1130)
2019.10.03 18:58:53 1: main::weekprofile_Notify called by fhem.pl (3752)
2019.10.03 18:58:53 1: main::CallFn called by fhem.pl (3672)
2019.10.03 18:58:53 1: main::DoTrigger called by fhem.pl (4735)
2019.10.03 18:58:53 1: main::readingsEndUpdate called by ./FHEM/88_HMCCU.pm (3415)
2019.10.03 18:58:53 1: main::HMCCU_UpdateSingleDevice called by ./FHEM/88_HMCCU.pm (3471)
2019.10.03 18:58:53 1: main::HMCCU_UpdateMultipleDevices called by ./FHEM/88_HMCCURPCPROC.pm (734)
2019.10.03 18:58:53 1: main::HMCCURPCPROC_Read called by fhem.pl (3752)
2019.10.03 18:58:53 1: main::CallFn called by fhem.pl (750)
2019.10.03 18:58:53 5: weekprofile_test_1(readDayProfile): WEDNESDAY_2
2019.10.03 18:58:53 1: PERL WARNING: Argument "" isn't numeric in division (/) at ./FHEM/98_weekprofile.pm line 77.
2019.10.03 18:58:53 1: stacktrace:
2019.10.03 18:58:53 1: main::__ANON__ called by ./FHEM/98_weekprofile.pm (77)
2019.10.03 18:58:53 1: main::weekprofile_minutesToTime called by ./FHEM/98_weekprofile.pm (235)
2019.10.03 18:58:53 1: main::weekprofile_readDayProfile called by ./FHEM/98_weekprofile.pm (275)
2019.10.03 18:58:53 1: main::weekprofile_readDevProfile called by ./FHEM/98_weekprofile.pm (1130)
2019.10.03 18:58:53 1: main::weekprofile_Notify called by fhem.pl (3752)
2019.10.03 18:58:53 1: main::CallFn called by fhem.pl (3672)
2019.10.03 18:58:53 1: main::DoTrigger called by fhem.pl (4735)
2019.10.03 18:58:53 1: main::readingsEndUpdate called by ./FHEM/88_HMCCU.pm (3415)
2019.10.03 18:58:53 1: main::HMCCU_UpdateSingleDevice called by ./FHEM/88_HMCCU.pm (3471)
2019.10.03 18:58:53 1: main::HMCCU_UpdateMultipleDevices called by ./FHEM/88_HMCCURPCPROC.pm (734)
2019.10.03 18:58:53 1: main::HMCCURPCPROC_Read called by fhem.pl (3752)
2019.10.03 18:58:53 1: main::CallFn called by fhem.pl (750)
2019.10.03 18:58:53 5: weekprofile_test_1(readDayProfile): WEDNESDAY_3
2019.10.03 18:58:53 1: PERL WARNING: Argument "" isn't numeric in division (/) at ./FHEM/98_weekprofile.pm line 77.
2019.10.03 18:58:53 1: stacktrace:
2019.10.03 18:58:53 1: main::__ANON__ called by ./FHEM/98_weekprofile.pm (77)
2019.10.03 18:58:53 1: main::weekprofile_minutesToTime called by ./FHEM/98_weekprofile.pm (235)
2019.10.03 18:58:53 1: main::weekprofile_readDayProfile called by ./FHEM/98_weekprofile.pm (275)
2019.10.03 18:58:53 1: main::weekprofile_readDevProfile called by ./FHEM/98_weekprofile.pm (1130)
2019.10.03 18:58:53 1: main::weekprofile_Notify called by fhem.pl (3752)
2019.10.03 18:58:53 1: main::CallFn called by fhem.pl (3672)
2019.10.03 18:58:53 1: main::DoTrigger called by fhem.pl (4735)
2019.10.03 18:58:53 1: main::readingsEndUpdate called by ./FHEM/88_HMCCU.pm (3415)
2019.10.03 18:58:53 1: main::HMCCU_UpdateSingleDevice called by ./FHEM/88_HMCCU.pm (3471)
2019.10.03 18:58:53 1: main::HMCCU_UpdateMultipleDevices called by ./FHEM/88_HMCCURPCPROC.pm (734)
2019.10.03 18:58:53 1: main::HMCCURPCPROC_Read called by fhem.pl (3752)
2019.10.03 18:58:53 1: main::CallFn called by fhem.pl (750)
2019.10.03 18:58:53 5: weekprofile_test_1(readDayProfile): WEDNESDAY_4
2019.10.03 18:58:53 1: PERL WARNING: Argument "" isn't numeric in division (/) at ./FHEM/98_weekprofile.pm line 77.
2019.10.03 18:58:53 1: stacktrace:
2019.10.03 18:58:53 1: main::__ANON__ called by ./FHEM/98_weekprofile.pm (77)
2019.10.03 18:58:53 1: main::weekprofile_minutesToTime called by ./FHEM/98_weekprofile.pm (235)
2019.10.03 18:58:53 1: main::weekprofile_readDayProfile called by ./FHEM/98_weekprofile.pm (275)
2019.10.03 18:58:53 1: main::weekprofile_readDevProfile called by ./FHEM/98_weekprofile.pm (1130)
2019.10.03 18:58:53 1: main::weekprofile_Notify called by fhem.pl (3752)
2019.10.03 18:58:53 1: main::CallFn called by fhem.pl (3672)
2019.10.03 18:58:53 1: main::DoTrigger called by fhem.pl (4735)
2019.10.03 18:58:53 1: main::readingsEndUpdate called by ./FHEM/88_HMCCU.pm (3415)
2019.10.03 18:58:53 1: main::HMCCU_UpdateSingleDevice called by ./FHEM/88_HMCCU.pm (3471)
2019.10.03 18:58:53 1: main::HMCCU_UpdateMultipleDevices called by ./FHEM/88_HMCCURPCPROC.pm (734)
2019.10.03 18:58:53 1: main::HMCCURPCPROC_Read called by fhem.pl (3752)
2019.10.03 18:58:53 1: main::CallFn called by fhem.pl (750)
2019.10.03 18:58:53 5: weekprofile_test_1(readDayProfile): WEDNESDAY_5
2019.10.03 18:58:53 1: PERL WARNING: Argument "" isn't numeric in division (/) at ./FHEM/98_weekprofile.pm line 77.
2019.10.03 18:58:53 1: stacktrace:
2019.10.03 18:58:53 1: main::__ANON__ called by ./FHEM/98_weekprofile.pm (77)
2019.10.03 18:58:53 1: main::weekprofile_minutesToTime called by ./FHEM/98_weekprofile.pm (235)
2019.10.03 18:58:53 1: main::weekprofile_readDayProfile called by ./FHEM/98_weekprofile.pm (275)
2019.10.03 18:58:53 1: main::weekprofile_readDevProfile called by ./FHEM/98_weekprofile.pm (1130)
2019.10.03 18:58:53 1: main::weekprofile_Notify called by fhem.pl (3752)
2019.10.03 18:58:53 1: main::CallFn called by fhem.pl (3672)
2019.10.03 18:58:53 1: main::DoTrigger called by fhem.pl (4735)
2019.10.03 18:58:53 1: main::readingsEndUpdate called by ./FHEM/88_HMCCU.pm (3415)
2019.10.03 18:58:53 1: main::HMCCU_UpdateSingleDevice called by ./FHEM/88_HMCCU.pm (3471)
2019.10.03 18:58:53 1: main::HMCCU_UpdateMultipleDevices called by ./FHEM/88_HMCCURPCPROC.pm (734)
2019.10.03 18:58:53 1: main::HMCCURPCPROC_Read called by fhem.pl (3752)
2019.10.03 18:58:53 1: main::CallFn called by fhem.pl (750)
2019.10.03 18:58:53 5: weekprofile_test_1(readDayProfile): WEDNESDAY_6
2019.10.03 18:58:53 1: PERL WARNING: Argument "" isn't numeric in division (/) at ./FHEM/98_weekprofile.pm line 77.
2019.10.03 18:58:53 1: stacktrace:
2019.10.03 18:58:53 1: main::__ANON__ called by ./FHEM/98_weekprofile.pm (77)
2019.10.03 18:58:53 1: main::weekprofile_minutesToTime called by ./FHEM/98_weekprofile.pm (235)
2019.10.03 18:58:53 1: main::weekprofile_readDayProfile called by ./FHEM/98_weekprofile.pm (275)
2019.10.03 18:58:53 1: main::weekprofile_readDevProfile called by ./FHEM/98_weekprofile.pm (1130)
2019.10.03 18:58:53 1: main::weekprofile_Notify called by fhem.pl (3752)
2019.10.03 18:58:53 1: main::CallFn called by fhem.pl (3672)
2019.10.03 18:58:53 1: main::DoTrigger called by fhem.pl (4735)
2019.10.03 18:58:53 1: main::readingsEndUpdate called by ./FHEM/88_HMCCU.pm (3415)
2019.10.03 18:58:53 1: main::HMCCU_UpdateSingleDevice called by ./FHEM/88_HMCCU.pm (3471)
2019.10.03 18:58:53 1: main::HMCCU_UpdateMultipleDevices called by ./FHEM/88_HMCCURPCPROC.pm (734)
2019.10.03 18:58:53 1: main::HMCCURPCPROC_Read called by fhem.pl (3752)
2019.10.03 18:58:53 1: main::CallFn called by fhem.pl (750)
2019.10.03 18:58:53 5: weekprofile_test_1(readDayProfile): WEDNESDAY_7
2019.10.03 18:58:53 1: PERL WARNING: Argument "" isn't numeric in division (/) at ./FHEM/98_weekprofile.pm line 77.
2019.10.03 18:58:53 1: stacktrace:
Mehr Platz war nicht...
Kannst Du bitte dein letztes Post editieren, und die Log in code Tags einschliessen?
Es fehlt wahrscheinlich das /code am Ende, weil zu lang
Zitat von: kotaro am 29 September 2019, 09:56:47
Hallo,
leider kriege ich meine HM_Thermostat über hmccu nicht das Profile ausgelesen...
Meine Readings sind R_P1_
Leider kann weekprofile dies nicht auslesen.....
Könntet ihr mir da helfen?
Hallo kotaro,
der Grund ist, dass bei den mir bekannten HMCCU_HM Geräten bzw. was andere User beigetragen haben, die Readings "R-1.P1_ENDTIME_xxxx" oder "R-ENDTIME_xxxx" heißen.
Bei dir\diesem HMCCU_HM Gerät heißen sie aber "R-P1_ENDTIME_xxx".
Ich glaube, ich habe schon mehrfach mein Unmut darüber geäußert, warum der Modulentwickler von HM die Readings nicht gleich benennen kann.
Naja. Ich habe eine Testversion angehangen, wo diese Readingsname mit berücksichtigt werden.
Bitte mal testen.
Risiko
tut mir leid, aber dafür kann zap nichts...
das hat wohl was mit EQ-3 zu tun....
Ich habe in der devconfig Ansicht von CCU3 mir die gerät angeschaut. dort sind die REadings folgende:
Wandthermostat Homematic:
HM-TC-IT-WM-W-EU:
P1_ENDTIME_FRIDAY_1
Thermostat:
HM-CC-RT-DN:
ENDTIME_FRIDAY_1
Heizungsgruppe
HM-CC-VG-1:
P1_ENDTIME_FRIDAY_1
HmIP:
Wandthermostat:
HMIP-WTH
P1_ENDTIME_FRIDAY_1
Thermostat:
HMIP-eTRV
P1_ENDTIME_FRIDAY_1
Heizungsgruppe:
HmIP-HEATING
P1_ENDTIME_FRIDAY_1
Und ich habe von ZAP verstanden, das Readings immer mit einen R- voran betitelt werden...
Hoffe du kannst was mit den Infos anfangen.
Hab nämlich alle o.g. Geräte aktiv in Betrieb
Ich kann mal bei Gelegenheit nachsehen, wie die readings bei mir bei fhem aussehen
Edit:
Sag mal wie kommst du an die Infos des Wochenprogramms? Mit get config? Get configlist?
Es werden die Readings ausgelesen.
Wenn die Version im Anhang vom letzten Post funktioniert, würde ich diese einchecken.
Bitte ein kurzes Feedback.
Danke.
Hey,
ja, die Version im Anhang funktioniert. Es werden die Readings ausgelesen.
Ist es denn möglich, die Version so anzupassen, das die Werte direkt vom Gerät abgeholt werden könnten? man Bekommt ja mit get configlist P1 (HM) oder "get configlist 1 P1" bei HmIP-Geräten die Werte entsprechend ausgespuckt...
Wüsste nicht, warum man das auf get configlist ändern sollte. Sehe da keinen Vorteil.
Scheint ja auch nicht für alle HM gleich zu sein. Kann es eh nicht umsetzen, da ich wie gesagt keine HM habe.
Akutell ist es so, ich muss das Wochenprogramm manuell mit get config P1 oder, bei HmIP, get config 1 P1 ausführen, damit die Readings akutell sind, kann kann ich diese in den weektimer aktualisieren, um dies dann wiederum nutzen zu können...
Wenn ich die Daten wieder aufs Thermostat schicke, sind die Readings nicht mehr akutell...
So wären die Daten wenistens immer aktuell ;-)
aber wenn es zu viele Umstände macht... dann nicht.
Ich höre jetzt zum erstmal davon, dass die Readings nicht aktuell sind bzw. nicht das "richtige" Profil darstellen. Meiner Meinung nach ist das ein spezielles Problem bei dir oder HM. Meiner Meinung nach sollten/müssen die Reading nach set config ... richtig sein. Das kann auch verzögert passieren. Hauptsache die Readings ändern sich entsprechend.
Weekprofile sollte die Änderungen der Readings vom assoziiertem Device mit bekommen (jedenfalls ist es bei MAX so, da sich hier die Readings auch verzögert ändern).
Risiko.
Hi,
ich würde auch gern in den Genuss von Weekprofiles kommen, nur leider bekomme ich es nicht hin.
Gerät ist eine HMCCU und HM-TC-IT-WM-W-EU das wiederrum mit einer HM-CC-RT-DN direkt gepaired ist.
Wie muss ich Weekprofile nun genau anlegen? Nach der Homematicanleitung scheint es nicht zu funktionieren.
Folgende Meldungen habe ich im log:
2019.11.13 06:19:31 3: BAD_Heizung_Wand_Weekprofil(readDayProfile): unsupported readings
2019.11.13 06:19:31 3: BAD_Heizung_Wand_Weekprofil(readDayProfile): unsupported readings
2019.11.13 06:19:31 3: BAD_Heizung_Wand_Weekprofil(readDayProfile): unsupported readings
2019.11.13 06:19:31 3: BAD_Heizung_Wand_Weekprofil(readDayProfile): unsupported readings
2019.11.13 06:19:31 3: BAD_Heizung_Wand_Weekprofil(readDayProfile): unsupported readings
2019.11.13 06:19:31 3: BAD_Heizung_Wand_Weekprofil(readDayProfile): unsupported readings
2019.11.13 06:19:31 3: BAD_Heizung_Wand_Weekprofil(readDayProfile): unsupported readings
2019.11.13 06:19:31 3: WARNING master device BAD_Heizung_Wand has no week profile - create default
Was mache ich falsch?
Greetings Gordon
Hallo Gordon,
die Readings scheinen mal wieder einen anderen Namen zu haben. Daher werden die Profile nicht erkannt. Typisches HM Problem.
Hast du weekprofile mit HM-TC-IT-WM-W-EU oder HM-CC-RT-DN verbunden?
Benötige mal ein list von den Geräten.
Risiko
Hallo Risiko,
Ich habe sie mit dem HM-TC-IT-WM-W-EU verbunden.
P2_ENDTIME_FRIDAY_5=1440
P1_TEMPERATURE_TUESDAY_11=17.000000
P1_ENDTIME_MONDAY_2=540
GLOBAL_BUTTON_LOCK=0
P2_TEMPERATURE_THURSDAY_10=17.000000
DAYLIGHT_SAVING_TIME=1
P1_TEMPERATURE_FRIDAY_4=21.000000
P2_TEMPERATURE_THURSDAY_13=17.000000
P3_TEMPERATURE_MONDAY_11=17.000000
P3_ENDTIME_SATURDAY_2=1440
P3_TEMPERATURE_SATURDAY_10=17.000000
P2_ENDTIME_SUNDAY_6=1440
P2_ENDTIME_SUNDAY_1=1440
P3_ENDTIME_SATURDAY_1=1440
P1_TEMPERATURE_SUNDAY_1=17.000000
P1_ENDTIME_SATURDAY_8=1440
TEMPERATURE_OFFSET=7
P2_TEMPERATURE_TUESDAY_9=17.000000
P2_ENDTIME_TUESDAY_3=1440
P1_ENDTIME_TUESDAY_10=1440
P1_TEMPERATURE_WEDNESDAY_7=17.000000
P1_ENDTIME_FRIDAY_10=1440
P2_ENDTIME_FRIDAY_3=1440
P1_ENDTIME_WEDNESDAY_4=1320
P3_TEMPERATURE_FRIDAY_1=17.000000
P2_ENDTIME_TUESDAY_6=1440
P1_ENDTIME_THURSDAY_2=540
P3_ENDTIME_SUNDAY_10=1440
P2_TEMPERATURE_WEDNESDAY_6=17.000000
P1_ENDTIME_MONDAY_9=1440
SHOW_WEEKDAY=1
P1_ENDTIME_THURSDAY_1=360
P1_ENDTIME_MONDAY_11=1440
P1_ENDTIME_TUESDAY_13=1440
P3_TEMPERATURE_MONDAY_7=17.000000
P3_ENDTIME_THURSDAY_8=1440
P3_TEMPERATURE_MONDAY_8=17.000000
P3_TEMPERATURE_SUNDAY_4=17.000000
BUTTON_LOCK=0
P3_ENDTIME_WEDNESDAY_11=1440
P3_ENDTIME_SATURDAY_10=1440
P1_TEMPERATURE_SATURDAY_6=17.000000
P1_ENDTIME_TUESDAY_12=1440
P1_TEMPERATURE_THURSDAY_2=21.000000
P1_ENDTIME_SUNDAY_12=1440
P1_ENDTIME_TUESDAY_4=1320
P3_ENDTIME_WEDNESDAY_9=1440
P2_TEMPERATURE_SATURDAY_9=17.000000
P2_TEMPERATURE_WEDNESDAY_3=17.000000
P1_TEMPERATURE_MONDAY_4=21.000000
P3_ENDTIME_THURSDAY_9=1440
P3_TEMPERATURE_FRIDAY_11=17.000000
P1_TEMPERATURE_WEDNESDAY_5=17.000000
P1_TEMPERATURE_SUNDAY_8=17.000000
P3_ENDTIME_WEDNESDAY_10=1440
P1_ENDTIME_THURSDAY_3=1020
P1_TEMPERATURE_TUESDAY_4=21.000000
P1_TEMPERATURE_SUNDAY_7=17.000000
MANU_MODE_PRIORITIZATION=1
P3_ENDTIME_FRIDAY_12=1440
P1_ENDTIME_TUESDAY_11=1440
P2_ENDTIME_THURSDAY_6=1440
P1_ENDTIME_THURSDAY_10=1440
P3_TEMPERATURE_SATURDAY_8=17.000000
P3_TEMPERATURE_FRIDAY_7=17.000000
P3_TEMPERATURE_FRIDAY_8=17.000000
P2_ENDTIME_MONDAY_4=1440
P1_TEMPERATURE_SUNDAY_11=17.000000
P3_ENDTIME_TUESDAY_1=1440
P1_ENDTIME_FRIDAY_7=1440
P2_ENDTIME_SATURDAY_4=1440
P3_ENDTIME_SUNDAY_7=1440
P1_ENDTIME_SATURDAY_9=1440
P3_ENDTIME_MONDAY_8=1440
P3_TEMPERATURE_MONDAY_1=17.000000
P1_TEMPERATURE_WEDNESDAY_11=17.000000
TEMPERATURE_MAXIMUM=30.500000
P3_TEMPERATURE_WEDNESDAY_11=17.000000
P3_ENDTIME_SATURDAY_3=1440
P1_ENDTIME_WEDNESDAY_8=1440
P1_TEMPERATURE_THURSDAY_4=21.000000
P2_TEMPERATURE_WEDNESDAY_7=17.000000
P3_ENDTIME_SUNDAY_1=1440
P2_ENDTIME_SATURDAY_1=1440
P1_TEMPERATURE_WEDNESDAY_3=17.000000
P3_ENDTIME_SUNDAY_6=1440
P1_ENDTIME_SUNDAY_5=1440
P3_TEMPERATURE_WEDNESDAY_10=17.000000
P3_ENDTIME_FRIDAY_5=1440
SHOW_SET_TEMPERATUR=0
P2_TEMPERATURE_MONDAY_11=17.000000
P1_ENDTIME_FRIDAY_6=1440
P1_ENDTIME_FRIDAY_1=360
P1_ENDTIME_WEDNESDAY_6=1440
P2_ENDTIME_SATURDAY_2=1440
P2_ENDTIME_SUNDAY_10=1440
P1_ENDTIME_SUNDAY_3=1440
P2_TEMPERATURE_MONDAY_8=17.000000
P2_TEMPERATURE_MONDAY_7=17.000000
P2_ENDTIME_THURSDAY_8=1440
P2_TEMPERATURE_SUNDAY_4=17.000000
P2_ENDTIME_WEDNESDAY_11=1440
P3_TEMPERATURE_THURSDAY_4=17.000000
P3_TEMPERATURE_SATURDAY_3=17.000000
P3_TEMPERATURE_TUESDAY_9=17.000000
P2_TEMPERATURE_WEDNESDAY_4=17.000000
P3_ENDTIME_TUESDAY_3=1440
P2_TEMPERATURE_SATURDAY_10=17.000000
P3_ENDTIME_FRIDAY_3=1440
P2_TEMPERATURE_FRIDAY_1=17.000000
P3_ENDTIME_TUESDAY_6=1440
P2_TEMPERATURE_FRIDAY_11=17.000000
P2_ENDTIME_THURSDAY_9=1440
P1_TEMPERATURE_SATURDAY_5=17.000000
P1_TEMPERATURE_THURSDAY_11=17.000000
P2_ENDTIME_WEDNESDAY_10=1440
P2_ENDTIME_FRIDAY_12=1440
P3_ENDTIME_THURSDAY_6=1440
P3_TEMPERATURE_SATURDAY_2=17.000000
P2_ENDTIME_SATURDAY_10=1440
P2_TEMPERATURE_TUESDAY_10=17.000000
P1_ENDTIME_THURSDAY_4=1320
P2_TEMPERATURE_WEDNESDAY_2=17.000000
P2_ENDTIME_WEDNESDAY_9=1440
P2_ENDTIME_SUNDAY_7=1440
P2_TEMPERATURE_MONDAY_1=17.000000
P2_ENDTIME_MONDAY_8=1440
P2_ENDTIME_SATURDAY_3=1440
P1_TEMPERATURE_TUESDAY_1=17.000000
P1_TEMPERATURE_THURSDAY_12=17.000000
P1_ENDTIME_SATURDAY_6=1440
P1_ENDTIME_MONDAY_13=1440
P3_TEMPERATURE_SATURDAY_6=17.000000
HEATING_COOLING=0
P2_TEMPERATURE_FRIDAY_8=17.000000
P2_TEMPERATURE_FRIDAY_7=17.000000
P3_TEMPERATURE_THURSDAY_11=17.000000
P3_ENDTIME_MONDAY_4=1440
P2_ENDTIME_TUESDAY_1=1440
P3_ENDTIME_SATURDAY_4=1440
P2_ENDTIME_SATURDAY_7=1440
P3_ENDTIME_SATURDAY_13=1440
P3_TEMPERATURE_MONDAY_6=17.000000
P2_TEMPERATURE_SUNDAY_9=17.000000
P2_TEMPERATURE_SATURDAY_12=17.000000
P3_ENDTIME_THURSDAY_11=1440
P3_TEMPERATURE_SUNDAY_3=17.000000
P2_ENDTIME_MONDAY_12=1440
P2_TEMPERATURE_SUNDAY_10=17.000000
P2_TEMPERATURE_SUNDAY_2=17.000000
P2_ENDTIME_WEDNESDAY_5=1440
P2_ENDTIME_WEDNESDAY_2=1440
P2_TEMPERATURE_SATURDAY_7=17.000000
P3_TEMPERATURE_THURSDAY_12=17.000000
P1_ENDTIME_TUESDAY_9=1440
P1_ENDTIME_THURSDAY_13=1440
P3_TEMPERATURE_SATURDAY_12=17.000000
P1_TEMPERATURE_THURSDAY_5=17.000000
P2_ENDTIME_TUESDAY_8=1440
P1_ENDTIME_WEDNESDAY_13=1440
P1_TEMPERATURE_MONDAY_13=17.000000
P2_TEMPERATURE_MONDAY_5=17.000000
P3_ENDTIME_FRIDAY_4=1440
P1_ENDTIME_SATURDAY_11=1440
P3_ENDTIME_SUNDAY_13=1440
P3_TEMPERATURE_WEDNESDAY_7=17.000000
P1_ENDTIME_FRIDAY_13=1440
P3_TEMPERATURE_MONDAY_12=17.000000
P1_ENDTIME_SUNDAY_4=1440
P1_TEMPERATURE_FRIDAY_3=17.000000
P2_ENDTIME_FRIDAY_8=1440
P3_TEMPERATURE_TUESDAY_7=17.000000
P3_TEMPERATURE_TUESDAY_5=17.000000
P1_ENDTIME_MONDAY_1=360
P1_ENDTIME_MONDAY_6=1440
CYCLIC_INFO_MSG=1
P3_TEMPERATURE_SUNDAY_13=17.000000
P3_ENDTIME_MONDAY_5=1440
P3_TEMPERATURE_TUESDAY_10=17.000000
P1_TEMPERATURE_TUESDAY_8=17.000000
P2_ENDTIME_WEDNESDAY_1=1440
P2_TEMPERATURE_TUESDAY_13=17.000000
P3_ENDTIME_SATURDAY_5=1440
P2_ENDTIME_SUNDAY_2=1440
P2_TEMPERATURE_TUESDAY_3=17.000000
P1_TEMPERATURE_SUNDAY_12=17.000000
P3_TEMPERATURE_FRIDAY_6=17.000000
P3_ENDTIME_THURSDAY_12=1440
P2_ENDTIME_SUNDAY_9=1440
P1_TEMPERATURE_MONDAY_3=17.000000
P1_TEMPERATURE_SATURDAY_3=17.000000
P3_TEMPERATURE_SATURDAY_5=17.000000
P3_ENDTIME_MONDAY_3=1440
P1_ENDTIME_WEDNESDAY_7=1440
WEEK_PROGRAM_POINTER=0
P1_TEMPERATURE_SUNDAY_6=17.000000
P1_TEMPERATURE_THURSDAY_3=17.000000
P2_ENDTIME_SUNDAY_11=1440
P3_TEMPERATURE_FRIDAY_12=17.000000
P1_ENDTIME_THURSDAY_5=1440
P1_TEMPERATURE_FRIDAY_13=17.000000
P2_TEMPERATURE_FRIDAY_5=17.000000
P1_ENDTIME_TUESDAY_5=1440
P1_ENDTIME_SATURDAY_12=1440
P3_ENDTIME_MONDAY_12=1440
TEMPERATURE_COMFORT=21.000000
P3_TEMPERATURE_SUNDAY_10=17.000000
P1_TEMPERATURE_THURSDAY_8=17.000000
P3_TEMPERATURE_SUNDAY_2=17.000000
P3_ENDTIME_WEDNESDAY_2=1440
P3_ENDTIME_WEDNESDAY_5=1440
P2_TEMPERATURE_THURSDAY_5=17.000000
P3_TEMPERATURE_TUESDAY_13=17.000000
P3_ENDTIME_SATURDAY_7=1440
P2_TEMPERATURE_MONDAY_6=17.000000
P2_ENDTIME_SATURDAY_13=1440
P3_TEMPERATURE_SUNDAY_9=17.000000
P2_ENDTIME_THURSDAY_11=1440
P2_TEMPERATURE_SUNDAY_3=17.000000
TEMPERATURE_MINIMUM=4.500000
P1_TEMPERATURE_FRIDAY_9=17.000000
P2_TEMPERATURE_MONDAY_12=17.000000
P2_TEMPERATURE_THURSDAY_4=17.000000
P3_TEMPERATURE_THURSDAY_8=17.000000
P3_ENDTIME_FRIDAY_8=1440
P1_ENDTIME_WEDNESDAY_12=1440
P2_TEMPERATURE_TUESDAY_7=17.000000
P1_ENDTIME_THURSDAY_7=1440
P1_ENDTIME_MONDAY_7=1440
P1_TEMPERATURE_FRIDAY_10=17.000000
P3_ENDTIME_TUESDAY_8=1440
P1_ENDTIME_SUNDAY_8=1440
P3_TEMPERATURE_MONDAY_5=17.000000
P2_ENDTIME_FRIDAY_4=1440
P1_TEMPERATURE_FRIDAY_2=21.000000
P2_ENDTIME_SUNDAY_13=1440
P1_TEMPERATURE_SATURDAY_9=17.000000
P3_TEMPERATURE_SATURDAY_7=17.000000
P1_TEMPERATURE_WEDNESDAY_6=17.000000
P3_ENDTIME_SUNDAY_2=1440
P3_TEMPERATURE_TUESDAY_3=17.000000
P1_TEMPERATURE_SATURDAY_2=21.000000
P2_ENDTIME_THURSDAY_12=1440
P2_TEMPERATURE_FRIDAY_6=17.000000
P2_TEMPERATURE_TUESDAY_5=17.000000
P2_TEMPERATURE_THURSDAY_9=17.000000
P1_TEMPERATURE_TUESDAY_2=21.000000
P2_TEMPERATURE_SUNDAY_13=17.000000
P1_TEMPERATURE_SUNDAY_5=17.000000
P2_ENDTIME_MONDAY_5=1440
P1_TEMPERATURE_TUESDAY_6=17.000000
P1_ENDTIME_FRIDAY_2=540
P3_ENDTIME_WEDNESDAY_1=1440
P1_ENDTIME_TUESDAY_2=540
P2_ENDTIME_SATURDAY_5=1440
P1_ENDTIME_FRIDAY_11=1440
P3_TEMPERATURE_FRIDAY_5=17.000000
P1_TEMPERATURE_WEDNESDAY_9=17.000000
P3_TEMPERATURE_SATURDAY_4=17.000000
P1_TEMPERATURE_MONDAY_2=21.000000
P1_ENDTIME_FRIDAY_9=1440
P1_TEMPERATURE_MONDAY_10=17.000000
P3_TEMPERATURE_THURSDAY_6=17.000000
P3_ENDTIME_SUNDAY_9=1440
P1_ENDTIME_MONDAY_10=1440
P2_ENDTIME_MONDAY_3=1440
P1_ENDTIME_WEDNESDAY_3=1020
P3_ENDTIME_SUNDAY_11=1440
P1_TEMPERATURE_MONDAY_9=17.000000
P1_ENDTIME_TUESDAY_7=1440
P2_TEMPERATURE_FRIDAY_12=17.000000
P3_TEMPERATURE_FRIDAY_3=17.000000
P1_TEMPERATURE_TUESDAY_7=17.000000
P2_ENDTIME_WEDNESDAY_12=1440
P2_TEMPERATURE_FRIDAY_9=17.000000
P3_ENDTIME_SUNDAY_4=1440
P2_TEMPERATURE_SATURDAY_4=17.000000
P3_ENDTIME_FRIDAY_13=1440
P1_TEMPERATURE_MONDAY_12=17.000000
P3_TEMPERATURE_MONDAY_13=17.000000
P3_ENDTIME_WEDNESDAY_13=1440
P3_TEMPERATURE_THURSDAY_5=17.000000
P3_TEMPERATURE_WEDNESDAY_6=17.000000
P2_TEMPERATURE_FRIDAY_2=17.000000
P1_ENDTIME_SUNDAY_13=1440
P1_TEMPERATURE_WEDNESDAY_10=17.000000
P3_ENDTIME_SATURDAY_11=1440
P1_ENDTIME_FRIDAY_4=1320
P2_ENDTIME_MONDAY_7=1440
P3_ENDTIME_TUESDAY_9=1440
P2_TEMPERATURE_FRIDAY_10=17.000000
P2_ENDTIME_THURSDAY_7=1440
P2_ENDTIME_SUNDAY_8=1440
LOW_BAT_LIMIT=2.200000
P3_ENDTIME_THURSDAY_13=1440
P2_TEMPERATURE_SATURDAY_2=17.000000
P2_TEMPERATURE_THURSDAY_3=17.000000
P2_TEMPERATURE_TUESDAY_11=17.000000
P1_TEMPERATURE_THURSDAY_9=17.000000
P2_TEMPERATURE_WEDNESDAY_12=17.000000
P1_TEMPERATURE_SUNDAY_3=17.000000
P1_ENDTIME_THURSDAY_11=1440
P1_TEMPERATURE_TUESDAY_10=17.000000
P1_TEMPERATURE_MONDAY_6=17.000000
P1_ENDTIME_SATURDAY_13=1440
P2_ENDTIME_FRIDAY_9=1440
P2_TEMPERATURE_MONDAY_10=17.000000
P3_ENDTIME_TUESDAY_5=1440
P3_ENDTIME_SATURDAY_12=1440
P3_TEMPERATURE_FRIDAY_13=17.000000
P2_ENDTIME_FRIDAY_11=1440
P2_TEMPERATURE_MONDAY_2=17.000000
P3_TEMPERATURE_THURSDAY_7=17.000000
P3_TEMPERATURE_THURSDAY_2=17.000000
P2_TEMPERATURE_THURSDAY_6=17.000000
P2_TEMPERATURE_MONDAY_9=17.000000
P3_TEMPERATURE_SUNDAY_6=17.000000
P3_ENDTIME_THURSDAY_5=1440
P1_TEMPERATURE_FRIDAY_12=17.000000
P2_ENDTIME_TUESDAY_7=1440
P2_ENDTIME_MONDAY_10=1440
P1_ENDTIME_MONDAY_3=1020
P3_TEMPERATURE_MONDAY_3=17.000000
P3_TEMPERATURE_WEDNESDAY_5=17.000000
LOCAL_RESET_DISABLE=0
P2_ENDTIME_WEDNESDAY_3=1440
P3_ENDTIME_WEDNESDAY_7=1440
P3_TEMPERATURE_SUNDAY_12=17.000000
P1_TEMPERATURE_FRIDAY_6=17.000000
P1_ENDTIME_THURSDAY_12=1440
P3_TEMPERATURE_WEDNESDAY_9=17.000000
P2_TEMPERATURE_SATURDAY_8=17.000000
P2_ENDTIME_FRIDAY_2=1440
P2_TEMPERATURE_TUESDAY_6=17.000000
P2_TEMPERATURE_SATURDAY_3=17.000000
P1_ENDTIME_MONDAY_5=1440
P2_ENDTIME_TUESDAY_2=1440
P1_ENDTIME_SATURDAY_5=1440
P3_TEMPERATURE_TUESDAY_8=17.000000
P1_TEMPERATURE_SATURDAY_1=17.000000
P1_TEMPERATURE_TUESDAY_5=17.000000
P3_TEMPERATURE_TUESDAY_11=17.000000
P1_TEMPERATURE_SUNDAY_13=17.000000
P2_TEMPERATURE_TUESDAY_2=17.000000
P2_TEMPERATURE_SUNDAY_5=17.000000
P3_ENDTIME_MONDAY_6=1440
P3_ENDTIME_MONDAY_1=1440
P2_TEMPERATURE_MONDAY_13=17.000000
P1_TEMPERATURE_MONDAY_5=17.000000
P2_TEMPERATURE_WEDNESDAY_11=17.000000
P2_ENDTIME_WEDNESDAY_13=1440
P3_TEMPERATURE_FRIDAY_2=17.000000
P3_TEMPERATURE_WEDNESDAY_3=17.000000
P2_ENDTIME_SATURDAY_11=1440
P2_ENDTIME_TUESDAY_9=1440
P3_ENDTIME_MONDAY_7=1440
P3_TEMPERATURE_FRIDAY_10=17.000000
P3_ENDTIME_THURSDAY_7=1440
P2_TEMPERATURE_SATURDAY_5=17.000000
P2_TEMPERATURE_THURSDAY_8=17.000000
P3_ENDTIME_SUNDAY_8=1440
P2_ENDTIME_THURSDAY_13=1440
P1_ENDTIME_TUESDAY_8=1440
P2_TEMPERATURE_FRIDAY_3=17.000000
DISPLAY_INFORMATION=0
P3_TEMPERATURE_WEDNESDAY_8=17.000000
P1_ENDTIME_FRIDAY_8=1440
P3_ENDTIME_WEDNESDAY_12=1440
P3_TEMPERATURE_FRIDAY_9=17.000000
P1_TEMPERATURE_WEDNESDAY_8=17.000000
P2_ENDTIME_SUNDAY_4=1440
P2_ENDTIME_FRIDAY_13=1440
P1_TEMPERATURE_WEDNESDAY_4=21.000000
P1_TEMPERATURE_THURSDAY_10=17.000000
P1_ENDTIME_SATURDAY_7=1440
P1_TEMPERATURE_SUNDAY_9=17.000000
P2_TEMPERATURE_SATURDAY_6=17.000000
P3_TEMPERATURE_WEDNESDAY_2=17.000000
P1_TEMPERATURE_SUNDAY_2=21.000000
P2_TEMPERATURE_WEDNESDAY_1=17.000000
P1_ENDTIME_WEDNESDAY_5=1440
P1_ENDTIME_WEDNESDAY_2=540
MIN_MAX_VALUE_NOT_RELEVANT_FOR_MANU_MODE=0
P1_ENDTIME_MONDAY_12=1440
P1_TEMPERATURE_SUNDAY_10=17.000000
P3_TEMPERATURE_MONDAY_9=17.000000
P1_TEMPERATURE_WEDNESDAY_2=21.000000
P1_ENDTIME_SUNDAY_11=1440
P3_TEMPERATURE_SATURDAY_9=17.000000
P1_TEMPERATURE_THURSDAY_7=17.000000
P2_TEMPERATURE_SUNDAY_6=17.000000
P2_TEMPERATURE_WEDNESDAY_13=17.000000
P2_ENDTIME_THURSDAY_5=1440
P3_ENDTIME_TUESDAY_7=1440
P2_TEMPERATURE_MONDAY_3=17.000000
P3_ENDTIME_MONDAY_10=1440
P1_ENDTIME_SUNDAY_9=1440
P1_TEMPERATURE_SATURDAY_7=17.000000
P2_TEMPERATURE_THURSDAY_11=17.000000
P3_ENDTIME_WEDNESDAY_3=1440
P2_ENDTIME_WEDNESDAY_7=1440
P3_TEMPERATURE_MONDAY_10=17.000000
P3_ENDTIME_FRIDAY_9=1440
P1_TEMPERATURE_SATURDAY_11=17.000000
P2_ENDTIME_TUESDAY_5=1440
P1_TEMPERATURE_SATURDAY_4=17.000000
P2_ENDTIME_SATURDAY_12=1440
P2_TEMPERATURE_FRIDAY_13=17.000000
P1_TEMPERATURE_FRIDAY_5=17.000000
P3_ENDTIME_FRIDAY_11=1440
P3_TEMPERATURE_MONDAY_2=17.000000
P3_TEMPERATURE_TUESDAY_6=17.000000
P3_ENDTIME_FRIDAY_2=1440
P3_ENDTIME_TUESDAY_2=1440
P2_TEMPERATURE_TUESDAY_8=17.000000
P1_ENDTIME_WEDNESDAY_1=360
P3_TEMPERATURE_SUNDAY_5=17.000000
P3_TEMPERATURE_TUESDAY_2=17.000000
P2_ENDTIME_MONDAY_1=1440
P2_ENDTIME_MONDAY_6=1440
P1_TEMPERATURE_SATURDAY_12=17.000000
P1_TEMPERATURE_TUESDAY_3=17.000000
P2_TEMPERATURE_SUNDAY_12=17.000000
P1_TEMPERATURE_THURSDAY_6=17.000000
P1_TEMPERATURE_SATURDAY_8=17.000000
P3_TEMPERATURE_SATURDAY_13=17.000000
P1_ENDTIME_SUNDAY_2=1320
P1_TEMPERATURE_MONDAY_8=17.000000
P1_ENDTIME_THURSDAY_8=1440
P1_TEMPERATURE_MONDAY_7=17.000000
P2_TEMPERATURE_THURSDAY_2=17.000000
P3_ENDTIME_TUESDAY_13=1440
P3_ENDTIME_MONDAY_11=1440
P1_ENDTIME_WEDNESDAY_11=1440
P3_TEMPERATURE_THURSDAY_3=17.000000
P1_TEMPERATURE_TUESDAY_12=17.000000
P1_TEMPERATURE_SUNDAY_4=17.000000
P2_TEMPERATURE_SATURDAY_13=17.000000
P3_ENDTIME_MONDAY_9=1440
BOOST_AFTER_WINDOW_OPEN=0
P2_TEMPERATURE_WEDNESDAY_10=17.000000
P1_ENDTIME_SUNDAY_10=1440
P2_ENDTIME_SUNDAY_3=1440
P3_ENDTIME_THURSDAY_1=1440
P3_TEMPERATURE_WEDNESDAY_1=17.000000
P1_TEMPERATURE_THURSDAY_13=17.000000
P3_ENDTIME_FRIDAY_10=1440
P2_TEMPERATURE_WEDNESDAY_9=17.000000
P3_ENDTIME_THURSDAY_2=1440
P1_TEMPERATURE_FRIDAY_1=17.000000
P3_ENDTIME_WEDNESDAY_4=1440
P3_TEMPERATURE_THURSDAY_9=17.000000
P3_ENDTIME_TUESDAY_10=1440
P2_ENDTIME_SUNDAY_5=1440
P3_ENDTIME_SATURDAY_8=1440
P1_TEMPERATURE_TUESDAY_13=17.000000
P3_TEMPERATURE_SUNDAY_1=17.000000
P2_TEMPERATURE_SATURDAY_11=17.000000
P2_ENDTIME_WEDNESDAY_8=1440
P1_ENDTIME_SATURDAY_1=360
P1_TEMPERATURE_MONDAY_11=17.000000
P2_TEMPERATURE_THURSDAY_7=17.000000
P3_TEMPERATURE_THURSDAY_10=17.000000
P3_TEMPERATURE_FRIDAY_4=17.000000
P2_ENDTIME_WEDNESDAY_6=1440
P1_ENDTIME_SATURDAY_2=1320
P2_ENDTIME_FRIDAY_6=1440
P2_ENDTIME_FRIDAY_1=1440
P3_ENDTIME_MONDAY_2=1440
P1_TEMPERATURE_THURSDAY_1=17.000000
P2_TEMPERATURE_TUESDAY_1=17.000000
P2_ENDTIME_MONDAY_13=1440
P2_ENDTIME_SATURDAY_6=1440
P3_ENDTIME_SATURDAY_9=1440
P1_ENDTIME_SUNDAY_7=1440
P1_ENDTIME_SATURDAY_3=1440
P1_TEMPERATURE_MONDAY_1=17.000000
P1_ENDTIME_MONDAY_8=1440
P3_ENDTIME_FRIDAY_7=1440
P3_TEMPERATURE_SATURDAY_1=17.000000
PARTY_MODE_PRIORITIZATION=1
P1_TEMPERATURE_WEDNESDAY_1=17.000000
P2_TEMPERATURE_WEDNESDAY_5=17.000000
P1_TEMPERATURE_SATURDAY_10=17.000000
P1_TEMPERATURE_FRIDAY_8=17.000000
P1_TEMPERATURE_FRIDAY_7=17.000000
P2_TEMPERATURE_TUESDAY_12=17.000000
P3_ENDTIME_THURSDAY_10=1440
P2_TEMPERATURE_SATURDAY_1=17.000000
P1_ENDTIME_TUESDAY_1=360
P3_TEMPERATURE_SUNDAY_11=17.000000
P2_TEMPERATURE_THURSDAY_12=17.000000
P3_ENDTIME_TUESDAY_11=1440
P1_ENDTIME_FRIDAY_12=1440
P1_TEMPERATURE_FRIDAY_11=17.000000
P1_ENDTIME_THURSDAY_9=1440
P3_TEMPERATURE_MONDAY_4=17.000000
P3_ENDTIME_THURSDAY_3=1440
P3_TEMPERATURE_TUESDAY_4=17.000000
P3_TEMPERATURE_SUNDAY_7=17.000000
P3_TEMPERATURE_SUNDAY_8=17.000000
P1_ENDTIME_WEDNESDAY_10=1440
P3_ENDTIME_TUESDAY_4=1440
P1_TEMPERATURE_WEDNESDAY_12=17.000000
P1_ENDTIME_WEDNESDAY_9=1440
P2_ENDTIME_THURSDAY_4=1440
P3_ENDTIME_SUNDAY_12=1440
P3_ENDTIME_TUESDAY_12=1440
P3_TEMPERATURE_WEDNESDAY_13=17.000000
P3_TEMPERATURE_THURSDAY_13=17.000000
P1_ENDTIME_SATURDAY_10=1440
P1_ENDTIME_FRIDAY_3=1020
P2_ENDTIME_FRIDAY_10=1440
P1_ENDTIME_TUESDAY_6=1440
P2_ENDTIME_THURSDAY_2=1440
P2_ENDTIME_WEDNESDAY_4=1440
P1_ENDTIME_TUESDAY_3=1020
P1_TEMPERATURE_TUESDAY_9=17.000000
P1_TEMPERATURE_WEDNESDAY_13=17.000000
P2_ENDTIME_TUESDAY_10=1440
P2_ENDTIME_MONDAY_11=1440
P2_ENDTIME_TUESDAY_13=1440
P2_ENDTIME_MONDAY_9=1440
P3_ENDTIME_SUNDAY_3=1440
P2_ENDTIME_THURSDAY_1=1440
P2_TEMPERATURE_FRIDAY_4=17.000000
CYCLIC_INFO_MSG_DIS=0
P3_ENDTIME_WEDNESDAY_6=1440
P3_ENDTIME_FRIDAY_1=1440
P3_ENDTIME_FRIDAY_6=1440
P2_ENDTIME_MONDAY_2=1440
P1_ENDTIME_FRIDAY_5=1440
P3_TEMPERATURE_TUESDAY_12=17.000000
P2_ENDTIME_SATURDAY_8=1440
P3_ENDTIME_SUNDAY_5=1440
P2_TEMPERATURE_SUNDAY_1=17.000000
MODUS_BUTTON_LOCK=0
P3_ENDTIME_WEDNESDAY_8=1440
P3_TEMPERATURE_WEDNESDAY_12=17.000000
BURST_RX=1
P1_ENDTIME_SUNDAY_6=1440
P1_ENDTIME_SUNDAY_1=360
P2_ENDTIME_FRIDAY_7=1440
P1_TEMPERATURE_SATURDAY_13=17.000000
SHOW_HUMIDITY=0
P1_ENDTIME_SATURDAY_4=1440
P3_TEMPERATURE_WEDNESDAY_4=17.000000
P2_ENDTIME_THURSDAY_10=1440
P2_TEMPERATURE_SUNDAY_11=17.000000
P1_ENDTIME_MONDAY_4=1320
P3_TEMPERATURE_SATURDAY_11=17.000000
SENDE_WEATHER_DATA=1
P3_TEMPERATURE_TUESDAY_1=17.000000
P3_ENDTIME_SATURDAY_6=1440
P3_ENDTIME_MONDAY_13=1440
P2_TEMPERATURE_WEDNESDAY_8=17.000000
P2_ENDTIME_SATURDAY_9=1440
P3_TEMPERATURE_THURSDAY_1=17.000000
P2_ENDTIME_TUESDAY_4=1440
P2_TEMPERATURE_THURSDAY_1=17.000000
TEMPERATURE_LOWERING=17.000000
P3_ENDTIME_THURSDAY_4=1440
P2_ENDTIME_SUNDAY_12=1440
P2_ENDTIME_TUESDAY_12=1440
P2_ENDTIME_TUESDAY_11=1440
P1_ENDTIME_THURSDAY_6=1440
BOOST_TIME_PERIOD=1
P2_TEMPERATURE_MONDAY_4=17.000000
P2_TEMPERATURE_SUNDAY_8=17.000000
P2_TEMPERATURE_TUESDAY_4=17.000000
P2_ENDTIME_THURSDAY_3=1440
P2_TEMPERATURE_SUNDAY_7=17.000000
Für HM-CC-RT-DN das List:
TEMPERATURE_WEDNESDAY_3=18.000000
DECALCIFICATION_WEEKDAY=0
PARTY_MODE_PRIORITIZATION=1
TEMPERATURE_SATURDAY_9=5.000000
TEMPERATURE_MONDAY_10=5.000000
ENDTIME_SUNDAY_1=540
ENDTIME_SUNDAY_7=1440
ENDTIME_THURSDAY_3=1020
ENDTIME_THURSDAY_6=5
CYCLIC_INFO_MSG=1
TEMPERATURE_MONDAY_13=5.000000
TEMPERATURE_TUESDAY_13=5.000000
TEMPERATURE_SATURDAY_7=18.000000
I_VALUE_INTERN=15
TEMPERATURE_SATURDAY_10=5.000000
TEMPERATURE_FRIDAY_2=21.000000
TEMPERATURE_THURSDAY_12=5.000000
ENDTIME_THURSDAY_1=300
ENDTIME_THURSDAY_5=1440
ENDTIME_SUNDAY_9=5
TEMPERATURE_WEDNESDAY_1=18.000000
TEMPERATURE_SUNDAY_13=5.000000
ENDTIME_MONDAY_11=5
TEMPERATURE_TUESDAY_8=5.000000
TEMPERATURE_SUNDAY_10=5.000000
TEMPERATURE_FRIDAY_7=18.000000
TEMPERATURE_FRIDAY_6=21.000000
TEMPERATURE_FRIDAY_3=18.000000
TEMPERATURE_WEDNESDAY_13=5.000000
VALVE_MAXIMUM_POSITION=100
ENDTIME_SUNDAY_4=1080
TEMPERATURE_SUNDAY_11=5.000000
ENDTIME_SATURDAY_9=5
TEMPERATURE_WEDNESDAY_11=5.000000
ENDTIME_TUESDAY_1=300
TEMPERATURE_SUNDAY_12=5.000000
TEMPERATURE_TUESDAY_9=5.000000
TEMPERATURE_SATURDAY_13=5.000000
BOOST_AFTER_WINDOW_OPEN=0
TEMPERATURE_TUESDAY_5=18.000000
TEMPERATURE_SUNDAY_4=21.000000
VALVE_OFFSET=0
VALVE_ERROR_RUN_POSITION=15
TEMPERATURE_WEDNESDAY_7=5.000000
TEMPERATURE_WEDNESDAY_8=5.000000
TEMPERATURE_MONDAY_4=21.000000
ENDTIME_SUNDAY_12=5
ENDTIME_FRIDAY_11=5
TEMPERATURE_MONDAY_12=5.000000
ENDTIME_SATURDAY_11=5
ENDTIME_TUESDAY_9=5
TEMPERATURE_MONDAY_11=5.000000
TEMPERATURE_SATURDAY_11=5.000000
ENDTIME_WEDNESDAY_6=5
ENDTIME_WEDNESDAY_1=300
TEMPERATURE_THURSDAY_3=18.000000
ENDTIME_WEDNESDAY_8=5
ENDTIME_THURSDAY_10=5
ENDTIME_WEDNESDAY_7=5
TEMPERATURE_TUESDAY_7=5.000000
TEMPERATURE_WEDNESDAY_2=21.000000
TEMPERATURE_SATURDAY_3=18.000000
P_VALUE_EXTERN=31
TEMPERATURE_WEDNESDAY_10=5.000000
TEMPERATURE_THURSDAY_11=5.000000
ENDTIME_THURSDAY_9=5
ENDTIME_SUNDAY_5=1440
ENDTIME_MONDAY_13=1440
ENDTIME_FRIDAY_8=5
ENDTIME_MONDAY_10=5
TEMPERATURE_WEDNESDAY_9=5.000000
TEMPERATURE_SUNDAY_8=5.000000
ENDTIME_SUNDAY_6=1200
TEMPERATURE_FRIDAY_1=18.000000
TEMPERATURE_MONDAY_8=5.000000
ENDTIME_SATURDAY_10=5
TEMPERATURE_THURSDAY_13=5.000000
BOOST_TIME_PERIOD=1
TEMPERATURE_LOWERING=17.000000
ENDTIME_THURSDAY_11=5
ENDTIME_MONDAY_3=750
TEMPERATURE_FRIDAY_5=18.000000
ENDTIME_WEDNESDAY_10=5
TEMPERATURE_TUESDAY_6=5.000000
DECALCIFICATION_TIME=660
ENDTIME_TUESDAY_8=5
TEMPERATUREFALL_VALUE=1.400000
ENDTIME_SATURDAY_6=1200
ENDTIME_MONDAY_8=5
ENDTIME_FRIDAY_10=5
ENDTIME_SUNDAY_2=660
ENDTIME_FRIDAY_13=1440
TEMPERATURE_COMFORT=21.000000
ENDTIME_SATURDAY_3=900
ENDTIME_TUESDAY_11=5
TEMPERATURE_SATURDAY_12=5.000000
TEMPERATUREFALL_MODUS=0
ENDTIME_FRIDAY_3=750
TEMPERATURE_THURSDAY_10=5.000000
TEMPERATURE_FRIDAY_9=5.000000
TEMPERATURE_THURSDAY_7=5.000000
BURST_RX=1
ENDTIME_TUESDAY_4=1200
ENDTIME_TUESDAY_3=1020
MODUS_BUTTON_LOCK=0
ENDTIME_SATURDAY_5=1440
ENDTIME_TUESDAY_13=1440
CYCLIC_INFO_MSG_DIS=0
ENDTIME_TUESDAY_6=5
TEMPERATURE_MINIMUM=4.500000
ENDTIME_SATURDAY_1=540
TEMPERATURE_THURSDAY_9=5.000000
TEMPERATUREFALL_WINDOW_OPEN_TIME_PERIOD=15
ENDTIME_TUESDAY_10=5
ENDTIME_WEDNESDAY_4=1200
ENDTIME_WEDNESDAY_9=5
MANU_MODE_PRIORITIZATION=1
ENDTIME_THURSDAY_2=420
TEMPERATURE_TUESDAY_11=5.000000
TEMPERATURE_TUESDAY_1=18.000000
LOCAL_RESET_DISABLE=0
ENDTIME_WEDNESDAY_11=5
ENDTIME_MONDAY_5=1050
ENDTIME_SUNDAY_13=1440
TEMPERATURE_THURSDAY_8=5.000000
ENDTIME_FRIDAY_2=450
TEMPERATURE_MONDAY_9=5.000000
TEMPERATUREFALL_WINDOW_OPEN=12.000000
P_VALUE_INTERN=30
ENDTIME_SUNDAY_10=5
TEMPERATURE_THURSDAY_6=5.000000
BOOST_POSITION=80
ENDTIME_MONDAY_6=1260
TEMPERATURE_TUESDAY_2=21.000000
TEMPERATURE_MAXIMUM=30.500000
ENDTIME_SATURDAY_8=5
ENDTIME_SATURDAY_12=5
ENDTIME_WEDNESDAY_2=420
ENDTIME_TUESDAY_7=5
TEMPERATURE_WEDNESDAY_4=21.000000
TEMPERATURE_SUNDAY_9=5.000000
TEMPERATURE_THURSDAY_5=18.000000
TEMPERATURE_THURSDAY_2=21.000000
ENDTIME_SUNDAY_3=900
ENDTIME_WEDNESDAY_5=1440
ENDTIME_FRIDAY_6=1260
LOW_BAT_LIMIT=2.100000
TEMPERATURE_SUNDAY_1=18.000000
ENDTIME_SUNDAY_8=5
TEMPERATURE_OFFSET=7
TEMPERATURE_FRIDAY_8=5.000000
TEMPERATURE_TUESDAY_10=5.000000
DAYLIGHT_SAVING_TIME=1
ENDTIME_FRIDAY_5=1050
TEMPERATURE_MONDAY_5=18.000000
P_START_VALUE_INTERN=30
GLOBAL_BUTTON_LOCK=0
TEMPERATURE_TUESDAY_12=5.000000
ENDTIME_MONDAY_2=450
ENDTIME_SATURDAY_4=1080
TEMPERATURE_WEDNESDAY_6=5.000000
TEMPERATURE_SATURDAY_4=21.000000
SHOW_WEEKDAY=0
TEMPERATURE_TUESDAY_3=18.000000
BUTTON_LOCK=0
ENDTIME_WEDNESDAY_3=1020
TEMPERATURE_THURSDAY_1=18.000000
ADAPTIVE_REGULATION=2
TEMPERATURE_WEDNESDAY_12=5.000000
TEMPERATURE_SUNDAY_5=18.000000
ENDTIME_SATURDAY_13=1440
ENDTIME_SATURDAY_7=1440
TEMPERATURE_MONDAY_1=18.000000
I_VALUE_EXTERN=16
TEMPERATURE_FRIDAY_12=5.000000
ENDTIME_THURSDAY_4=1200
BACKLIGHT_ON_TIME=10
ENDTIME_MONDAY_7=1440
TEMPERATURE_FRIDAY_4=21.000000
ENDTIME_WEDNESDAY_12=5
ENDTIME_TUESDAY_2=420
ENDTIME_MONDAY_1=360
TEMPERATURE_SUNDAY_6=21.000000
TEMPERATURE_SATURDAY_1=18.000000
ENDTIME_FRIDAY_4=840
TEMPERATURE_FRIDAY_11=5.000000
TEMPERATURE_SUNDAY_3=18.000000
TEMPERATURE_THURSDAY_4=21.000000
TEMPERATURE_MONDAY_3=18.000000
TEMPERATURE_MONDAY_6=21.000000
ENDTIME_THURSDAY_7=5
ENDTIME_THURSDAY_13=1440
ENDTIME_MONDAY_9=5
ENDTIME_FRIDAY_12=5
ENDTIME_SUNDAY_11=5
DISPLAY_INFORMATION=0
TEMPERATURE_SATURDAY_2=21.000000
TEMPERATURE_SATURDAY_5=18.000000
TEMPERATURE_SUNDAY_2=21.000000
BUTTON_RESPONSE_WITHOUT_BACKLIGHT=0
ENDTIME_MONDAY_4=840
ENDTIME_FRIDAY_7=1440
TEMPERATURE_MONDAY_7=18.000000
ENDTIME_FRIDAY_1=360
P_START_VALUE_EXTERN=35
ENDTIME_WEDNESDAY_13=1440
ENDTIME_SATURDAY_2=660
MIN_MAX_VALUE_NOT_RELEVANT_FOR_MANU_MODE=0
TEMPERATURE_WEDNESDAY_5=18.000000
TEMPERATURE_FRIDAY_10=5.000000
ENDTIME_TUESDAY_5=1440
TEMPERATURE_SUNDAY_7=18.000000
TEMPERATURE_TUESDAY_4=21.000000
TEMPERATURE_SATURDAY_6=21.000000
ENDTIME_MONDAY_12=5
ENDTIME_THURSDAY_12=5
TEMPERATURE_SATURDAY_8=5.000000
TEMPERATURE_MONDAY_2=21.000000
ENDTIME_FRIDAY_9=5
TEMPERATURE_FRIDAY_13=5.000000
ENDTIME_TUESDAY_12=5
ENDTIME_THURSDAY_8=5
Hallo zusammen;
ich habe 3 HmIP-eTRV_B1 Thermostate erfolgreich mit Weekendprofilen versehen.
Bei einem ist mir aufgefallen daß die Zeitangabe 21:50 nicht richtig umgesetzt wird.
Mon 00:00-07:00 15.0 °C 07:00-11:00 21.0 °C 11:00-15:00 18.0 °C 15:00-21.8333333333333:00
R-1.P1_ENDTIME_FRIDAY_1
420
2019-11-14 12:26:13
R-1.P1_ENDTIME_FRIDAY_10
1440
2019-11-14 12:26:13
R-1.P1_ENDTIME_FRIDAY_11
1440
2019-11-14 12:26:13
R-1.P1_ENDTIME_FRIDAY_12
1440
2019-11-14 12:26:13
R-1.P1_ENDTIME_FRIDAY_13
1440
2019-11-14 12:26:13
R-1.P1_ENDTIME_FRIDAY_2
660
2019-11-14 12:26:13
R-1.P1_ENDTIME_FRIDAY_3
900
2019-11-14 12:26:13
R-1.P1_ENDTIME_FRIDAY_4
1320
2019-11-14 12:26:13
R-1.P1_ENDTIME_FRIDAY_5
1440
2019-11-14 12:26:13
R-1.P1_ENDTIME_FRIDAY_6
1440
2019-11-14 12:26:13
R-1.P1_ENDTIME_FRIDAY_7
1440
2019-11-14 12:26:13
R-1.P1_ENDTIME_FRIDAY_8
1440
2019-11-14 12:26:13
R-1.P1_ENDTIME_FRIDAY_9
1440
2019-11-14 12:26:13
R-1.P1_ENDTIME_MONDAY_1
420
2019-11-14 12:26:13
R-1.P1_ENDTIME_MONDAY_10
1440
2019-11-14 12:26:13
R-1.P1_ENDTIME_MONDAY_11
1440
2019-11-14 12:26:13
R-1.P1_ENDTIME_MONDAY_12
1440
2019-11-14 12:26:13
R-1.P1_ENDTIME_MONDAY_13
1440
2019-11-14 12:26:13
R-1.P1_ENDTIME_MONDAY_2
660
2019-11-14 12:26:13
R-1.P1_ENDTIME_MONDAY_3
900
2019-11-14 12:26:13
R-1.P1_ENDTIME_MONDAY_4
1320
2019-11-14 12:26:13
R-1.P1_ENDTIME_MONDAY_5
1440
2019-11-14 12:26:13
R-1.P1_ENDTIME_MONDAY_6
1440
2019-11-14 12:26:13
R-1.P1_ENDTIME_MONDAY_7
1440
2019-11-14 12:26:13
R-1.P1_ENDTIME_MONDAY_8
1440
2019-11-14 12:26:13
R-1.P1_ENDTIME_MONDAY_9
1440
2019-11-14 12:26:13
R-1.P1_ENDTIME_SATURDAY_1
420
2019-11-14 12:26:13
R-1.P1_ENDTIME_SATURDAY_10
1440
2019-11-14 12:26:13
R-1.P1_ENDTIME_SATURDAY_11
1440
2019-11-14 12:26:13
R-1.P1_ENDTIME_SATURDAY_12
1440
2019-11-14 12:26:13
R-1.P1_ENDTIME_SATURDAY_13
1440
2019-11-14 12:26:13
R-1.P1_ENDTIME_SATURDAY_2
660
2019-11-14 12:26:13
R-1.P1_ENDTIME_SATURDAY_3
900
2019-11-14 12:26:13
R-1.P1_ENDTIME_SATURDAY_4
1320
2019-11-14 12:26:13
R-1.P1_ENDTIME_SATURDAY_5
1440
2019-11-14 12:26:13
R-1.P1_ENDTIME_SATURDAY_6
1440
2019-11-14 12:26:13
R-1.P1_ENDTIME_SATURDAY_7
1440
2019-11-14 12:26:13
R-1.P1_ENDTIME_SATURDAY_8
1440
2019-11-14 12:26:13
R-1.P1_ENDTIME_SATURDAY_9
1440
2019-11-14 12:26:13
R-1.P1_ENDTIME_SUNDAY_1
420
2019-11-14 12:26:13
R-1.P1_ENDTIME_SUNDAY_10
1440
2019-11-14 12:26:13
R-1.P1_ENDTIME_SUNDAY_11
1440
2019-11-14 12:26:13
R-1.P1_ENDTIME_SUNDAY_12
1440
2019-11-14 12:26:13
R-1.P1_ENDTIME_SUNDAY_13
1440
2019-11-14 12:26:13
R-1.P1_ENDTIME_SUNDAY_2
660
2019-11-14 12:26:13
R-1.P1_ENDTIME_SUNDAY_3
900
2019-11-14 12:26:13
R-1.P1_ENDTIME_SUNDAY_4
1320
2019-11-14 12:26:13
R-1.P1_ENDTIME_SUNDAY_5
1440
2019-11-14 12:26:13
R-1.P1_ENDTIME_SUNDAY_6
1440
2019-11-14 12:26:13
R-1.P1_ENDTIME_SUNDAY_7
1440
2019-11-14 12:26:13
R-1.P1_ENDTIME_SUNDAY_8
1440
2019-11-14 12:26:13
R-1.P1_ENDTIME_SUNDAY_9
1440
2019-11-14 12:26:13
R-1.P1_ENDTIME_THURSDAY_1
420
2019-11-14 12:26:13
R-1.P1_ENDTIME_THURSDAY_10
1440
2019-11-14 12:26:13
R-1.P1_ENDTIME_THURSDAY_11
1440
2019-11-14 12:26:13
R-1.P1_ENDTIME_THURSDAY_12
1440
2019-11-14 12:26:13
R-1.P1_ENDTIME_THURSDAY_13
1440
2019-11-14 12:26:13
R-1.P1_ENDTIME_THURSDAY_2
Mache ich hier noch einen Fehler?
Gruß
Ulrich
Hallo zusammen,
ich habe für mich jetzt eine Lösung gefunden und folgende Zeilen ersetzt:
sub weekprofile_minutesToTime($)
{
my ($minutes) = @_;
# my $hours = $minutes / 60;
# $minutes = $minutes - $hours * 60;
my $hours =($minutes - $minutes % 60)/60;
$minutes = $minutes - $hours * 60;
ob das Auswirkungen (zB bei anderen Themostaten) hat kann ich nicht überprüfen.
Gruß
Ulrich
Zitat von: BM030 am 14 November 2019, 06:11:30
Hallo Risiko,
Ich habe sie mit dem HM-TC-IT-WM-W-EU verbunden.
Hallo Gordon,
anbei eine Testversion für das HM-TC-IT-WM-W-EU angebunden an eine CCU. Bitte kurzes Feedback.
Ich werde Homatic glaube nie verstehen. Bei Anbindung über CUL_HM heißen die Readings für das gleiche Gerät wieder anders.
Risiko.
Zitat von: UvG am 15 November 2019, 09:25:43
Gruß
Ulrich
Hallo Ulrich,
ich kann das Problem mit Perl 5.26.1 nicht nachvollziehen.
Könntest du bitte die minimale Änderung "
.0"
my $hours = $minutes / 60.0;
$minutes = $minutes - $hours * 60.0;
testen?
Danke
Ich verstehe nicht, was .0 bringen soll? Meiner Meinung nach muss irgendwo ein "modulo 60" sein.
Ich kenne das Modul nicht, aber mitmy $hours = $minutes / 60.0;
$minutes = $minutes - $hours * 60.0; hast am Ende immer $minutes = 0, oder? x/60*60 = x
Habe gerade den Test gemacht Bringt aber nichts.
Man muß die hours isolieren und die minutes dann als Rest durch 60 teilen mal 60.
Ich kann mir nicht vorstellen das es bei anderern Thermostaten geht.
Gruß
Ulrich
Vielleicht nochmal deutlicher:
590/60 = 9,833333333333333 (nur die 9 als hours nehmen)
590 - 9*60 = 50 (dies minutes)
Gruß
Ulrich
Zitat von: Risiko am 17 November 2019, 18:49:41
Hallo Gordon,
anbei eine Testversion für das HM-TC-IT-WM-W-EU angebunden an eine CCU. Bitte kurzes Feedback.
Ich werde Homatic glaube nie verstehen. Bei Anbindung über CUL_HM heißen die Readings für das gleiche Gerät wieder anders.
Risiko.
Leider keine Veränderung ...
Greetings Gordon
Zitat von: UvG am 17 November 2019, 21:52:26
Vielleicht nochmal deutlicher:
590/60 = 9,833333333333333 (nur die 9 als hours nehmen)
590 - 9*60 = 50 (dies minutes)
Gruß
Ulrich
Ja, hast ja Recht. Habe nicht weiter nachgedacht, da es bei mir keine Anwendung findet. Sorry.
In deiner obigen Angabe scheint Mo auch nicht der richtige Tag mit dem Fehler zu sein. Da ist 1320 angegeben und das ist ein Vielfaches von 60. Daher ist es auch nicht aufgefallen.
Der Code wurde von HM-Users beigetragen.
Habe es gefixt!
Zitat von: BM030 am 17 November 2019, 23:24:32
Leider keine Veränderung ...
Greetings Gordon
Dann benötige ich mal ein
vollständiges list vom HM-TC-IT-WM-W-EU
Zitat von: Risiko am 18 November 2019, 20:14:48
Dann benötige ich mal ein vollständiges list vom HM-TC-IT-WM-W-EU
list BAD_Heizung_Wand :
Internals:
.eventMapCmd Manu:noArg Auto:noArg Boost:noArg off:noArg on:noArg
DEF PEQ1186264
FUUID 5d908e90-f33f-398d-ab9f-0a1b2d0b60b989ab
IODev d_ccu
NAME BAD_Heizung_Wand
NR 251
STATE T: 20.7° H: 67% D: 20.5° P: 14.4°
TYPE HMCCUDEV
ccuaddr PEQ1186264
ccudevstate active
ccuif BidCos-RF
ccuname BAD_Heizung_Wand
ccutype HM-TC-IT-WM-W-EU
channels 6
firmware 1.4
statevals devstate
.attraggr:
.attreocr:
.*
.attrminint:
READINGS:
2019-11-19 06:30:49 1.HUMIDITY 67
2019-11-19 06:30:49 1.TEMPERATURE 20.7
2019-11-19 06:30:29 2.SET_TEMPERATURE 20.5
2019-11-19 06:20:31 2.WINDOW_OPEN_REPORTING closed
2019-11-19 06:30:49 DEWPOINT 14.4
2019-11-17 20:10:05 battery ok
2019-11-19 06:30:29 control 20.5
2019-11-19 06:30:49 hmstate 20.5
2019-11-19 06:30:29 state 20.5
hmccu:
devspec PEQ1186264
dp:
0.AES_KEY:
OVAL 0
VAL 0
0.CONFIG_PENDING:
OVAL false
VAL false
0.DEVICE_IN_BOOTLOADER:
OVAL false
VAL false
0.INHIBIT:
OVAL false
VAL false
0.LOWBAT:
OSVAL ok
OVAL false
SVAL ok
VAL false
0.RSSI_DEVICE:
OVAL 1
VAL 1
0.RSSI_PEER:
OVAL 201
VAL 201
0.STICKY_UNREACH:
OVAL false
VAL false
0.UNREACH:
OVAL false
VAL false
0.UPDATE_PENDING:
OVAL false
VAL false
1.HUMIDITY:
OSVAL 66
OVAL 66
SVAL 67
VAL 67
1.TEMPERATURE:
OSVAL 20.7
OVAL 20.700000
SVAL 20.7
VAL 20.700000
2.ACTUAL_HUMIDITY:
OVAL 66.000000
VAL 66.000000
2.ACTUAL_TEMPERATURE:
OVAL 20.700000
VAL 20.700000
2.BATTERY_STATE:
OVAL 3.000000
VAL 3.000000
2.BOOST_STATE:
OVAL 0
VAL 0
2.COMMUNICATION_REPORTING:
OVAL 0
VAL 0
2.CONTROL_MODE:
OVAL 1
VAL 1
2.LOWBAT_REPORTING:
OVAL 0
VAL 0
2.PARTY_START_DAY:
OVAL 1
VAL 1
2.PARTY_START_MONTH:
OVAL 1
VAL 1
2.PARTY_START_TIME:
OVAL 0
VAL 0
2.PARTY_START_YEAR:
OVAL 0
VAL 0
2.PARTY_STOP_DAY:
OVAL 1
VAL 1
2.PARTY_STOP_MONTH:
OVAL 1
VAL 1
2.PARTY_STOP_TIME:
OVAL 0
VAL 0
2.PARTY_STOP_YEAR:
OVAL 0
VAL 0
2.PARTY_TEMPERATURE:
OVAL 5.000000
VAL 5.000000
2.SET_TEMPERATURE:
OSVAL 20.5
OVAL 20.500000
SVAL 20.5
VAL 20.500000
2.WINDOW_OPEN_REPORTING:
OSVAL closed
OVAL 0
SVAL closed
VAL 0
7.DECISION_VALUE:
OVAL 0
VAL 0
Attributes:
IODev d_ccu
ccucalculate dewpoint:DEWPOINT:1.TEMPERATURE,1.HUMIDITY
ccureadingfilter (^HUMIDITY|^TEMPERATURE|^DEWPOINT|^SET_TEMPERATURE|^LOWBAT$|^WINDOW_OPEN)
cmdIcon Auto:sani_heating_automatic Manu:sani_heating_manual Boost:sani_heating_boost on:general_an off:general_aus
controldatapoint 2.SET_TEMPERATURE
devStateIcon OK:10px-kreis-gruen Error:10px-kreis-rot Initialized:10px-kreis-gelb
event-on-change-reading .*
eventMap /datapoint 2.MANU_MODE 20.0:Manu/datapoint 2.AUTO_MODE 1:Auto/datapoint 2.BOOST_MODE 1:Boost/datapoint 2.MANU_MODE 4.5:off/datapoint 2.MANU_MODE 30.5:on/
icon max_wandthermostat
room Homematic
stateFormat T: 1.TEMPERATURE° H: 1.HUMIDITY% D: 2.SET_TEMPERATURE° P: DEWPOINT°
statechannel 2
statedatapoint SET_TEMPERATURE
stripnumber 1
substexcl control
substitute CONTROL_MODE!0:AUTO,1:MANU,2:PARTY,3:BOOST;WINDOW_OPEN_REPORTING!(true|1):open,(false|0):closed;SET_TEMPERATURE!#0-3.5:off,#30.5-40:on
userattr weekprofile
webCmd control:Auto:Manu:Boost:on:off
weekprofile BAD_Winter
widgetOverride control:slider,4.5,0.5,30.5,1
Hm, ich kann keinen Fehler entdecken.
Ist der list sind keine Readings fürs Wochenprofil vorhanden. Hast du die Readings raus genommen? Ich interpretiere den ccureadingfilter so, als wenn die Readings gefiltert und nicht vorhanden sind.
Hast du wirklich die neue Version verwendet und dann FHEM neu gestartet?
Setze doch verbose vom weekprofile mal auf 4 und schaue\zeige mal das Log.
Risiko
Hi,
beim starten von FHEM:
2019.11.20 06:18:52 1: PERL WARNING: Use of uninitialized value $model in concatenation (.) or string at ./FHEM/98_weekprofile.pm line 158.
2019.11.20 06:18:52 1: PERL WARNING: Use of uninitialized value $model in pattern match (m//) at ./FHEM/98_weekprofile.pm line 159.
2019.11.20 06:18:52 1: PERL WARNING: Use of uninitialized value $model in pattern match (m//) at ./FHEM/98_weekprofile.pm line 160.
2019.11.20 06:18:52 2: BAD_Heizung_Wand_Weekprofil(assignDev): device BAD_Heizung_Wand not supported or defined
beim übertragen des Profils:
2019.11.20 06:29:31 4: BAD_Heizung_Wand_Weekprofil(getDeviceType): BAD_Heizung_Wand is type HMCCU_HM
2019.11.20 06:29:31 3: BAD_Heizung_Wand_Weekprofil(readDayProfile): unsupported readings
2019.11.20 06:29:31 3: BAD_Heizung_Wand_Weekprofil(readDayProfile): unsupported readings
2019.11.20 06:29:31 3: BAD_Heizung_Wand_Weekprofil(readDayProfile): unsupported readings
2019.11.20 06:29:31 3: BAD_Heizung_Wand_Weekprofil(readDayProfile): unsupported readings
2019.11.20 06:29:31 3: BAD_Heizung_Wand_Weekprofil(readDayProfile): unsupported readings
2019.11.20 06:29:31 3: BAD_Heizung_Wand_Weekprofil(readDayProfile): unsupported readings
2019.11.20 06:29:31 3: BAD_Heizung_Wand_Weekprofil(readDayProfile): unsupported readings
2019.11.20 06:29:31 3: WARNING master device BAD_Heizung_Wand has no week profile - create default
2019.11.20 06:29:31 4: BAD_Heizung_Wand_Weekprofil(sendDevProfile): set BAD_Heizung_Wand config TEMPERATURE_MONDAY_1=18.0 ENDTIME_MONDAY_1=360 TEMPERATURE_MONDAY_2=21.0 ENDTIME_MONDAY_2=450 TEMPERATURE_MONDAY_3=18.0 ENDTIME_MONDAY_3=750 TEMPERATURE_MONDAY_4=21.0 ENDTIME_MONDAY_4=840 TEMPERATURE_MONDAY_5=18.0 ENDTIME_MONDAY_5=1050 TEMPERATURE_MONDAY_6=21.0 ENDTIME_MONDAY_6=1260 TEMPERATURE_MONDAY_7=18.0 ENDTIME_MONDAY_7=1440 TEMPERATURE_TUESDAY_1=18.0 ENDTIME_TUESDAY_1=300 TEMPERATURE_TUESDAY_2=21.0 ENDTIME_TUESDAY_2=420 TEMPERATURE_TUESDAY_3=18.0 ENDTIME_TUESDAY_3=1020 TEMPERATURE_TUESDAY_4=21.0 ENDTIME_TUESDAY_4=1200 TEMPERATURE_TUESDAY_5=18.0 ENDTIME_TUESDAY_5=1440 TEMPERATURE_WEDNESDAY_1=18.0 ENDTIME_WEDNESDAY_1=300 TEMPERATURE_WEDNESDAY_2=21.0 ENDTIME_WEDNESDAY_2=420 TEMPERATURE_WEDNESDAY_3=18.0 ENDTIME_WEDNESDAY_3=1020 TEMPERATURE_WEDNESDAY_4=21.0 ENDTIME_WEDNESDAY_4=1200 TEMPERATURE_WEDNESDAY_5=18.0 ENDTIME_WEDNESDAY_5=1440 TEMPERATURE_THURSDAY_1=18.0 ENDTIME_THURSDAY_1=300 TEMPERATURE_THURSDAY_2=21.0 ENDTIME_THURSDAY_2=420 TEMPERATURE_THURSDAY_3=18.0 ENDTIME_THURSDAY_3=1020 TEMPERATURE_THURSDAY_4=21.0 ENDTIME_THURSDAY_4=1200 TEMPERATURE_THURSDAY_5=18.0 ENDTIME_THURSDAY_5=1440 TEMPERATURE_FRIDAY_1=18.0 ENDTIME_FRIDAY_1=360 TEMPERATURE_FRIDAY_2=21.0 ENDTIME_FRIDAY_2=450 TEMPERATURE_FRIDAY_3=18.0 ENDTIME_FRIDAY_3=750 TEMPERATURE_FRIDAY_4=21.0 ENDTIME_FRIDAY_4=840 TEMPERATURE_FRIDAY_5=18.0 ENDTIME_FRIDAY_5=1050 TEMPERATURE_FRIDAY_6=21.0 ENDTIME_FRIDAY_6=1260 TEMPERATURE_FRIDAY_7=18.0 ENDTIME_FRIDAY_7=1440 TEMPERATURE_SATURDAY_1=18.0 ENDTIME_SATURDAY_1=540 TEMPERATURE_SATURDAY_2=21.0 ENDTIME_SATURDAY_2=660 TEMPERATURE_SATURDAY_3=18.0 ENDTIME_SATURDAY_3=900 TEMPERATURE_SATURDAY_4=21.0 ENDTIME_SATURDAY_4=1080 TEMPERATURE_SATURDAY_5=18.0 ENDTIME_SATURDAY_5=1440 TEMPERATURE_SUNDAY_1=18.0 ENDTIME_SUNDAY_1=540 TEMPERATURE_SUNDAY_2=21.0 ENDTIME_SUNDAY_2=660 TEMPERATURE_SUNDAY_3=18.0 ENDTIME_SUNDAY_3=900 TEMPERATURE_SUNDAY_4=21.0 ENDTIME_SUNDAY_4=1080 TEMPERATURE_SUNDAY_5=18.0 ENDTIME_SUNDAY_5=1440
2019.11.20 06:29:31 4: BAD_Heizung_Wand_Weekprofil(Notify): reread master profile from BAD_Heizung_Wand
2019.11.20 06:29:31 3: BAD_Heizung_Wand_Weekprofil(readDayProfile): unsupported readings
2019.11.20 06:29:31 3: BAD_Heizung_Wand_Weekprofil(readDayProfile): unsupported readings
2019.11.20 06:29:31 3: BAD_Heizung_Wand_Weekprofil(readDayProfile): unsupported readings
2019.11.20 06:29:31 3: BAD_Heizung_Wand_Weekprofil(readDayProfile): unsupported readings
2019.11.20 06:29:31 3: BAD_Heizung_Wand_Weekprofil(readDayProfile): unsupported readings
2019.11.20 06:29:31 3: BAD_Heizung_Wand_Weekprofil(readDayProfile): unsupported readings
2019.11.20 06:29:31 3: BAD_Heizung_Wand_Weekprofil(readDayProfile): unsupported readings
2019.11.20 06:29:31 3: WARNING master device BAD_Heizung_Wand has no week profile - create default
die Geräteliste ist jetzt nicht mehr vorhanden(siehe Anhang)
Habe auch den ccufilter entfernt, bzw würde Ihn auf:
(^HUMIDITY|^TEMPERATURE^|^DEWPOINT|^SET_TEMPERATURE|^LOWBAT$|^WINDOW_OPEN|^ENDTIME^)
erweitern. Damit müssten alle Temperaturwerte und die Endzeit gelesen werden. Wird noch ein Wert zusätzlich benötigt?
Greetings Gordon
@UvG:
Könntest du mal bitte deine config für HmIP-eTRV_B1 hier posten?
Gruß
eurofinder
Ich weiß nicht genau was du mit config meinst.
Hier mal ein list:
Internals:
DEF 0012999395D0FA
FUUID 5dbb451d-f33f-d79e-d39e-95603b736284fc4f
FVERSION 88_HMCCUDEV.pm:v4.3.11-s20414/2019-10-27
IODev d_ccu
NAME HmIP_eTRV_B1_0012999395D0FA
NR 444
STATE Ist: 20.6° Soll: 21.0° Ventil: 100%
TYPE HMCCUDEV
ccuaddr 0012999395D0FA
ccudevstate active
ccuif HmIP-RF
ccuname HmIP-eTRV-B1 0012999395D0FA
ccutype HmIP-eTRV-B1
channels 8
firmware 1.0.20
statevals devstate
Helper:
DBLOG:
0.LOW_BAT:
logdb:
TIME 1574234447.5553
VALUE 0
1.ACTUAL_TEMPERATURE:
logdb:
TIME 1574234447.61513
VALUE 20.6
1.ACTUAL_TEMPERATURE_STATUS:
logdb:
TIME 1574234447.61513
VALUE 0
1.BOOST_MODE:
logdb:
TIME 1574234447.61513
VALUE 0
1.SET_POINT_MODE:
logdb:
TIME 1574234447.61513
VALUE 0
1.SET_POINT_TEMPERATURE:
logdb:
TIME 1574234447.61513
VALUE 21.0
1.WINDOW_STATE:
logdb:
TIME 1574234447.61513
VALUE closed
R-1.P1_ENDTIME_FRIDAY_1:
logdb:
TIME 1574167763.69694
VALUE 420
R-1.P1_ENDTIME_FRIDAY_10:
logdb:
TIME 1574167763.69694
VALUE 1440
R-1.P1_ENDTIME_FRIDAY_11:
logdb:
TIME 1574167763.69694
VALUE 1440
R-1.P1_ENDTIME_FRIDAY_12:
logdb:
TIME 1574167763.69694
VALUE 1440
R-1.P1_ENDTIME_FRIDAY_13:
logdb:
TIME 1574167763.69694
VALUE 1440
R-1.P1_ENDTIME_FRIDAY_2:
logdb:
TIME 1574167763.69694
VALUE 660
R-1.P1_ENDTIME_FRIDAY_3:
logdb:
TIME 1574167763.69694
VALUE 900
R-1.P1_ENDTIME_FRIDAY_4:
logdb:
TIME 1574167763.69694
VALUE 1320
R-1.P1_ENDTIME_FRIDAY_5:
logdb:
TIME 1574167763.69694
VALUE 1440
R-1.P1_ENDTIME_FRIDAY_6:
logdb:
TIME 1574167763.69694
VALUE 1440
R-1.P1_ENDTIME_FRIDAY_7:
logdb:
TIME 1574167763.69694
VALUE 1440
R-1.P1_ENDTIME_FRIDAY_8:
logdb:
TIME 1574167763.69694
VALUE 1440
R-1.P1_ENDTIME_FRIDAY_9:
logdb:
TIME 1574167763.69694
VALUE 1440
R-1.P1_ENDTIME_MONDAY_1:
logdb:
TIME 1574167763.69694
VALUE 420
R-1.P1_ENDTIME_MONDAY_10:
logdb:
TIME 1574167763.69694
VALUE 1440
R-1.P1_ENDTIME_MONDAY_11:
logdb:
TIME 1574167763.69694
VALUE 1440
R-1.P1_ENDTIME_MONDAY_12:
logdb:
TIME 1574167763.69694
VALUE 1440
R-1.P1_ENDTIME_MONDAY_13:
logdb:
TIME 1574167763.69694
VALUE 1440
R-1.P1_ENDTIME_MONDAY_2:
logdb:
TIME 1574167763.69694
VALUE 660
R-1.P1_ENDTIME_MONDAY_3:
logdb:
TIME 1574167763.69694
VALUE 900
R-1.P1_ENDTIME_MONDAY_4:
logdb:
TIME 1574167763.69694
VALUE 1320
R-1.P1_ENDTIME_MONDAY_5:
logdb:
TIME 1574167763.69694
VALUE 1440
R-1.P1_ENDTIME_MONDAY_6:
logdb:
TIME 1574167763.69694
VALUE 1440
R-1.P1_ENDTIME_MONDAY_7:
logdb:
TIME 1574167763.69694
VALUE 1440
R-1.P1_ENDTIME_MONDAY_8:
logdb:
TIME 1574167763.69694
VALUE 1440
R-1.P1_ENDTIME_MONDAY_9:
logdb:
TIME 1574167763.69694
VALUE 1440
R-1.P1_ENDTIME_SATURDAY_1:
logdb:
TIME 1574167763.69694
VALUE 420
R-1.P1_ENDTIME_SATURDAY_10:
logdb:
TIME 1574167763.69694
VALUE 1440
R-1.P1_ENDTIME_SATURDAY_11:
logdb:
TIME 1574167763.69694
VALUE 1440
R-1.P1_ENDTIME_SATURDAY_12:
logdb:
TIME 1574167763.69694
VALUE 1440
R-1.P1_ENDTIME_SATURDAY_13:
logdb:
TIME 1574167763.69694
VALUE 1440
R-1.P1_ENDTIME_SATURDAY_2:
logdb:
TIME 1574167763.69694
VALUE 660
R-1.P1_ENDTIME_SATURDAY_3:
logdb:
TIME 1574167763.69694
VALUE 705
R-1.P1_ENDTIME_SATURDAY_4:
logdb:
TIME 1574167763.69694
VALUE 765
R-1.P1_ENDTIME_SATURDAY_5:
logdb:
TIME 1574167763.69694
VALUE 900
R-1.P1_ENDTIME_SATURDAY_6:
logdb:
TIME 1574167763.69694
VALUE 1320
R-1.P1_ENDTIME_SATURDAY_7:
logdb:
TIME 1574167763.69694
VALUE 1440
R-1.P1_ENDTIME_SATURDAY_8:
logdb:
TIME 1574167763.69694
VALUE 1440
R-1.P1_ENDTIME_SATURDAY_9:
logdb:
TIME 1574167763.69694
VALUE 1440
R-1.P1_ENDTIME_SUNDAY_1:
logdb:
TIME 1574167763.69694
VALUE 420
R-1.P1_ENDTIME_SUNDAY_10:
logdb:
TIME 1574167763.69694
VALUE 1440
R-1.P1_ENDTIME_SUNDAY_11:
logdb:
TIME 1574167763.69694
VALUE 1440
R-1.P1_ENDTIME_SUNDAY_12:
logdb:
TIME 1574167763.69694
VALUE 1440
R-1.P1_ENDTIME_SUNDAY_13:
logdb:
TIME 1574167763.69694
VALUE 1440
R-1.P1_ENDTIME_SUNDAY_2:
logdb:
TIME 1574167763.69694
VALUE 660
R-1.P1_ENDTIME_SUNDAY_3:
logdb:
TIME 1574167763.69694
VALUE 705
R-1.P1_ENDTIME_SUNDAY_4:
logdb:
TIME 1574167763.69694
VALUE 765
R-1.P1_ENDTIME_SUNDAY_5:
logdb:
TIME 1574167763.69694
VALUE 900
R-1.P1_ENDTIME_SUNDAY_6:
logdb:
TIME 1574167763.69694
VALUE 1320
R-1.P1_ENDTIME_SUNDAY_7:
logdb:
TIME 1574167763.69694
VALUE 1440
R-1.P1_ENDTIME_SUNDAY_8:
logdb:
TIME 1574167763.69694
VALUE 1440
R-1.P1_ENDTIME_SUNDAY_9:
logdb:
TIME 1574167763.69694
VALUE 1440
R-1.P1_ENDTIME_THURSDAY_1:
logdb:
TIME 1574167763.69694
VALUE 420
R-1.P1_ENDTIME_THURSDAY_10:
logdb:
TIME 1574167763.69694
VALUE 1440
R-1.P1_ENDTIME_THURSDAY_11:
logdb:
TIME 1574167763.69694
VALUE 1440
R-1.P1_ENDTIME_THURSDAY_12:
logdb:
TIME 1574167763.69694
VALUE 1440
R-1.P1_ENDTIME_THURSDAY_13:
logdb:
TIME 1574167763.69694
VALUE 1440
R-1.P1_ENDTIME_THURSDAY_2:
logdb:
TIME 1574167763.69694
VALUE 660
R-1.P1_ENDTIME_THURSDAY_3:
logdb:
TIME 1574167763.69694
VALUE 900
R-1.P1_ENDTIME_THURSDAY_4:
logdb:
TIME 1574167763.69694
VALUE 1320
R-1.P1_ENDTIME_THURSDAY_5:
logdb:
TIME 1574167763.69694
VALUE 1440
R-1.P1_ENDTIME_THURSDAY_6:
logdb:
TIME 1574167763.69694
VALUE 1440
R-1.P1_ENDTIME_THURSDAY_7:
logdb:
TIME 1574167763.69694
VALUE 1440
R-1.P1_ENDTIME_THURSDAY_8:
logdb:
TIME 1574167763.69694
VALUE 1440
R-1.P1_ENDTIME_THURSDAY_9:
logdb:
TIME 1574167763.69694
VALUE 1440
R-1.P1_ENDTIME_TUESDAY_1:
logdb:
TIME 1574167763.69694
VALUE 420
R-1.P1_ENDTIME_TUESDAY_10:
logdb:
TIME 1574167763.69694
VALUE 1440
R-1.P1_ENDTIME_TUESDAY_11:
logdb:
TIME 1574167763.69694
VALUE 1440
R-1.P1_ENDTIME_TUESDAY_12:
logdb:
TIME 1574167763.69694
VALUE 1440
R-1.P1_ENDTIME_TUESDAY_13:
logdb:
TIME 1574167763.69694
VALUE 1440
R-1.P1_ENDTIME_TUESDAY_2:
logdb:
TIME 1574167763.69694
VALUE 660
R-1.P1_ENDTIME_TUESDAY_3:
logdb:
TIME 1574167763.69694
VALUE 900
R-1.P1_ENDTIME_TUESDAY_4:
logdb:
TIME 1574167763.69694
VALUE 1320
R-1.P1_ENDTIME_TUESDAY_5:
logdb:
TIME 1574167763.69694
VALUE 1440
R-1.P1_ENDTIME_TUESDAY_6:
logdb:
TIME 1574167763.69694
VALUE 1440
R-1.P1_ENDTIME_TUESDAY_7:
logdb:
TIME 1574167763.69694
VALUE 1440
R-1.P1_ENDTIME_TUESDAY_8:
logdb:
TIME 1574167763.69694
VALUE 1440
R-1.P1_ENDTIME_TUESDAY_9:
logdb:
TIME 1574167763.69694
VALUE 1440
R-1.P1_ENDTIME_WEDNESDAY_1:
logdb:
TIME 1574167763.69694
VALUE 420
R-1.P1_ENDTIME_WEDNESDAY_10:
logdb:
TIME 1574167763.69694
VALUE 1440
R-1.P1_ENDTIME_WEDNESDAY_11:
logdb:
TIME 1574167763.69694
VALUE 1440
R-1.P1_ENDTIME_WEDNESDAY_12:
logdb:
TIME 1574167763.69694
VALUE 1440
R-1.P1_ENDTIME_WEDNESDAY_13:
logdb:
TIME 1574167763.69694
VALUE 1440
R-1.P1_ENDTIME_WEDNESDAY_2:
logdb:
TIME 1574167763.69694
VALUE 660
R-1.P1_ENDTIME_WEDNESDAY_3:
logdb:
TIME 1574167763.69694
VALUE 900
R-1.P1_ENDTIME_WEDNESDAY_4:
logdb:
TIME 1574167763.69694
VALUE 1320
R-1.P1_ENDTIME_WEDNESDAY_5:
logdb:
TIME 1574167763.69694
VALUE 1440
R-1.P1_ENDTIME_WEDNESDAY_6:
logdb:
TIME 1574167763.69694
VALUE 1440
R-1.P1_ENDTIME_WEDNESDAY_7:
logdb:
TIME 1574167763.69694
VALUE 1440
R-1.P1_ENDTIME_WEDNESDAY_8:
logdb:
TIME 1574167763.69694
VALUE 1440
R-1.P1_ENDTIME_WEDNESDAY_9:
logdb:
TIME 1574167763.69694
VALUE 1440
R-1.P1_TEMPERATURE_FRIDAY_1:
logdb:
TIME 1574167763.69694
VALUE 14.0
R-1.P1_TEMPERATURE_FRIDAY_10:
logdb:
TIME 1574167763.69694
VALUE 17.0
R-1.P1_TEMPERATURE_FRIDAY_11:
logdb:
TIME 1574167763.69694
VALUE 17.0
R-1.P1_TEMPERATURE_FRIDAY_12:
logdb:
TIME 1574167763.69694
VALUE 17.0
R-1.P1_TEMPERATURE_FRIDAY_13:
logdb:
TIME 1574167763.69694
VALUE 17.0
R-1.P1_TEMPERATURE_FRIDAY_2:
logdb:
TIME 1574167763.69694
VALUE 21.0
R-1.P1_TEMPERATURE_FRIDAY_3:
logdb:
TIME 1574167763.69694
VALUE 14.0
R-1.P1_TEMPERATURE_FRIDAY_4:
logdb:
TIME 1574167763.69694
VALUE 21.0
R-1.P1_TEMPERATURE_FRIDAY_5:
logdb:
TIME 1574167763.69694
VALUE 14.0
R-1.P1_TEMPERATURE_FRIDAY_6:
logdb:
TIME 1574167763.69694
VALUE 17.0
R-1.P1_TEMPERATURE_FRIDAY_7:
logdb:
TIME 1574167763.69694
VALUE 17.0
R-1.P1_TEMPERATURE_FRIDAY_8:
logdb:
TIME 1574167763.69694
VALUE 17.0
R-1.P1_TEMPERATURE_FRIDAY_9:
logdb:
TIME 1574167763.69694
VALUE 17.0
R-1.P1_TEMPERATURE_MONDAY_1:
logdb:
TIME 1574167763.69694
VALUE 14.0
R-1.P1_TEMPERATURE_MONDAY_10:
logdb:
TIME 1574167763.69694
VALUE 17.0
R-1.P1_TEMPERATURE_MONDAY_11:
logdb:
TIME 1574167763.69694
VALUE 17.0
R-1.P1_TEMPERATURE_MONDAY_12:
logdb:
TIME 1574167763.69694
VALUE 17.0
R-1.P1_TEMPERATURE_MONDAY_13:
logdb:
TIME 1574167763.69694
VALUE 17.0
R-1.P1_TEMPERATURE_MONDAY_2:
logdb:
TIME 1574167763.69694
VALUE 21.0
R-1.P1_TEMPERATURE_MONDAY_3:
logdb:
TIME 1574167763.69694
VALUE 14.0
R-1.P1_TEMPERATURE_MONDAY_4:
logdb:
TIME 1574167763.69694
VALUE 21.0
R-1.P1_TEMPERATURE_MONDAY_5:
logdb:
TIME 1574167763.69694
VALUE 14.0
R-1.P1_TEMPERATURE_MONDAY_6:
logdb:
TIME 1574167763.69694
VALUE 17.0
R-1.P1_TEMPERATURE_MONDAY_7:
logdb:
TIME 1574167763.69694
VALUE 17.0
R-1.P1_TEMPERATURE_MONDAY_8:
logdb:
TIME 1574167763.69694
VALUE 17.0
R-1.P1_TEMPERATURE_MONDAY_9:
logdb:
TIME 1574167763.69694
VALUE 17.0
R-1.P1_TEMPERATURE_SATURDAY_1:
logdb:
TIME 1574167763.69694
VALUE 14.0
R-1.P1_TEMPERATURE_SATURDAY_10:
logdb:
TIME 1574167763.69694
VALUE 17.0
R-1.P1_TEMPERATURE_SATURDAY_11:
logdb:
TIME 1574167763.69694
VALUE 17.0
R-1.P1_TEMPERATURE_SATURDAY_12:
logdb:
TIME 1574167763.69694
VALUE 17.0
R-1.P1_TEMPERATURE_SATURDAY_13:
logdb:
TIME 1574167763.69694
VALUE 17.0
R-1.P1_TEMPERATURE_SATURDAY_2:
logdb:
TIME 1574167763.69694
VALUE 21.0
R-1.P1_TEMPERATURE_SATURDAY_3:
logdb:
TIME 1574167763.69694
VALUE 14.0
R-1.P1_TEMPERATURE_SATURDAY_4:
logdb:
TIME 1574167763.69694
VALUE 21.0
R-1.P1_TEMPERATURE_SATURDAY_5:
logdb:
TIME 1574167763.69694
VALUE 14.0
R-1.P1_TEMPERATURE_SATURDAY_6:
logdb:
TIME 1574167763.69694
VALUE 21.0
R-1.P1_TEMPERATURE_SATURDAY_7:
logdb:
TIME 1574167763.69694
VALUE 14.0
R-1.P1_TEMPERATURE_SATURDAY_8:
logdb:
TIME 1574167763.69694
VALUE 17.0
R-1.P1_TEMPERATURE_SATURDAY_9:
logdb:
TIME 1574167763.69694
VALUE 17.0
R-1.P1_TEMPERATURE_SUNDAY_1:
logdb:
TIME 1574167763.69694
VALUE 14.0
R-1.P1_TEMPERATURE_SUNDAY_10:
logdb:
TIME 1574167763.69694
VALUE 17.0
R-1.P1_TEMPERATURE_SUNDAY_11:
logdb:
TIME 1574167763.69694
VALUE 17.0
R-1.P1_TEMPERATURE_SUNDAY_12:
logdb:
TIME 1574167763.69694
VALUE 17.0
R-1.P1_TEMPERATURE_SUNDAY_13:
logdb:
TIME 1574167763.69694
VALUE 17.0
R-1.P1_TEMPERATURE_SUNDAY_2:
logdb:
TIME 1574167763.69694
VALUE 21.0
R-1.P1_TEMPERATURE_SUNDAY_3:
logdb:
TIME 1574167763.69694
VALUE 14.0
R-1.P1_TEMPERATURE_SUNDAY_4:
logdb:
TIME 1574167763.69694
VALUE 21.0
R-1.P1_TEMPERATURE_SUNDAY_5:
logdb:
TIME 1574167763.69694
VALUE 14.0
R-1.P1_TEMPERATURE_SUNDAY_6:
logdb:
TIME 1574167763.69694
VALUE 21.0
R-1.P1_TEMPERATURE_SUNDAY_7:
logdb:
TIME 1574167763.69694
VALUE 14.0
R-1.P1_TEMPERATURE_SUNDAY_8:
logdb:
TIME 1574167763.69694
VALUE 17.0
R-1.P1_TEMPERATURE_SUNDAY_9:
logdb:
TIME 1574167763.69694
VALUE 17.0
R-1.P1_TEMPERATURE_THURSDAY_1:
logdb:
TIME 1574167763.69694
VALUE 14.0
R-1.P1_TEMPERATURE_THURSDAY_10:
logdb:
TIME 1574167763.69694
VALUE 17.0
R-1.P1_TEMPERATURE_THURSDAY_11:
logdb:
TIME 1574167763.69694
VALUE 17.0
R-1.P1_TEMPERATURE_THURSDAY_12:
logdb:
TIME 1574167763.69694
VALUE 17.0
R-1.P1_TEMPERATURE_THURSDAY_13:
logdb:
TIME 1574167763.69694
VALUE 17.0
R-1.P1_TEMPERATURE_THURSDAY_2:
logdb:
TIME 1574167763.69694
VALUE 21.0
R-1.P1_TEMPERATURE_THURSDAY_3:
logdb:
TIME 1574167763.69694
VALUE 14.0
R-1.P1_TEMPERATURE_THURSDAY_4:
logdb:
TIME 1574167763.69694
VALUE 21.0
R-1.P1_TEMPERATURE_THURSDAY_5:
logdb:
TIME 1574167763.69694
VALUE 14.0
R-1.P1_TEMPERATURE_THURSDAY_6:
logdb:
TIME 1574167763.69694
VALUE 17.0
R-1.P1_TEMPERATURE_THURSDAY_7:
logdb:
TIME 1574167763.69694
VALUE 17.0
R-1.P1_TEMPERATURE_THURSDAY_8:
logdb:
TIME 1574167763.69694
VALUE 17.0
R-1.P1_TEMPERATURE_THURSDAY_9:
logdb:
TIME 1574167763.69694
VALUE 17.0
R-1.P1_TEMPERATURE_TUESDAY_1:
logdb:
TIME 1574167763.69694
VALUE 14.0
R-1.P1_TEMPERATURE_TUESDAY_10:
logdb:
TIME 1574167763.69694
VALUE 17.0
R-1.P1_TEMPERATURE_TUESDAY_11:
logdb:
TIME 1574167763.69694
VALUE 17.0
R-1.P1_TEMPERATURE_TUESDAY_12:
logdb:
TIME 1574167763.69694
VALUE 17.0
R-1.P1_TEMPERATURE_TUESDAY_13:
logdb:
TIME 1574167763.69694
VALUE 17.0
R-1.P1_TEMPERATURE_TUESDAY_2:
logdb:
TIME 1574167763.69694
VALUE 21.0
R-1.P1_TEMPERATURE_TUESDAY_3:
logdb:
TIME 1574167763.69694
VALUE 14.0
R-1.P1_TEMPERATURE_TUESDAY_4:
logdb:
TIME 1574167763.69694
VALUE 21.0
R-1.P1_TEMPERATURE_TUESDAY_5:
logdb:
TIME 1574167763.69694
VALUE 14.0
R-1.P1_TEMPERATURE_TUESDAY_6:
logdb:
TIME 1574167763.69694
VALUE 17.0
R-1.P1_TEMPERATURE_TUESDAY_7:
logdb:
TIME 1574167763.69694
VALUE 17.0
R-1.P1_TEMPERATURE_TUESDAY_8:
logdb:
TIME 1574167763.69694
VALUE 17.0
R-1.P1_TEMPERATURE_TUESDAY_9:
logdb:
TIME 1574167763.69694
VALUE 17.0
R-1.P1_TEMPERATURE_WEDNESDAY_1:
logdb:
TIME 1574167763.69694
VALUE 14.0
R-1.P1_TEMPERATURE_WEDNESDAY_10:
logdb:
TIME 1574167763.69694
VALUE 17.0
R-1.P1_TEMPERATURE_WEDNESDAY_11:
logdb:
TIME 1574167763.69694
VALUE 17.0
R-1.P1_TEMPERATURE_WEDNESDAY_12:
logdb:
TIME 1574167763.69694
VALUE 17.0
R-1.P1_TEMPERATURE_WEDNESDAY_13:
logdb:
TIME 1574167763.69694
VALUE 17.0
R-1.P1_TEMPERATURE_WEDNESDAY_2:
logdb:
TIME 1574167763.69694
VALUE 21.0
R-1.P1_TEMPERATURE_WEDNESDAY_3:
logdb:
TIME 1574167763.69694
VALUE 14.0
R-1.P1_TEMPERATURE_WEDNESDAY_4:
logdb:
TIME 1574167763.69694
VALUE 21.0
R-1.P1_TEMPERATURE_WEDNESDAY_5:
logdb:
TIME 1574167763.69694
VALUE 14.0
R-1.P1_TEMPERATURE_WEDNESDAY_6:
logdb:
TIME 1574167763.69694
VALUE 17.0
R-1.P1_TEMPERATURE_WEDNESDAY_7:
logdb:
TIME 1574167763.69694
VALUE 17.0
R-1.P1_TEMPERATURE_WEDNESDAY_8:
logdb:
TIME 1574167763.69694
VALUE 17.0
R-1.P1_TEMPERATURE_WEDNESDAY_9:
logdb:
TIME 1574167763.69694
VALUE 17.0
control:
logdb:
TIME 1574234447.61513
VALUE 21.0
hmstate:
logdb:
TIME 1574234447.61513
VALUE 21.0
state:
logdb:
TIME 1574234447.61513
VALUE 21.0
valve_position:
logdb:
TIME 1574234447.61513
VALUE 100
valve_position_STATUS:
logdb:
TIME 1574234447.61513
VALUE 0
READINGS:
2019-11-20 08:20:47 0.LOW_BAT 0
2019-11-20 08:20:47 1.ACTUAL_TEMPERATURE 20.6
2019-11-20 08:20:47 1.ACTUAL_TEMPERATURE_STATUS 0
2019-11-20 08:20:47 1.BOOST_MODE 0
2019-11-20 08:20:47 1.SET_POINT_MODE 0
2019-11-20 08:20:47 1.SET_POINT_TEMPERATURE 21.0
2019-11-20 08:20:47 1.WINDOW_STATE closed
2019-11-19 13:49:23 R-1.P1_ENDTIME_FRIDAY_1 420
2019-11-19 13:49:23 R-1.P1_ENDTIME_FRIDAY_10 1440
2019-11-19 13:49:23 R-1.P1_ENDTIME_FRIDAY_11 1440
2019-11-19 13:49:23 R-1.P1_ENDTIME_FRIDAY_12 1440
2019-11-19 13:49:23 R-1.P1_ENDTIME_FRIDAY_13 1440
2019-11-19 13:49:23 R-1.P1_ENDTIME_FRIDAY_2 660
2019-11-19 13:49:23 R-1.P1_ENDTIME_FRIDAY_3 900
2019-11-19 13:49:23 R-1.P1_ENDTIME_FRIDAY_4 1320
2019-11-19 13:49:23 R-1.P1_ENDTIME_FRIDAY_5 1440
2019-11-19 13:49:23 R-1.P1_ENDTIME_FRIDAY_6 1440
2019-11-19 13:49:23 R-1.P1_ENDTIME_FRIDAY_7 1440
2019-11-19 13:49:23 R-1.P1_ENDTIME_FRIDAY_8 1440
2019-11-19 13:49:23 R-1.P1_ENDTIME_FRIDAY_9 1440
2019-11-19 13:49:23 R-1.P1_ENDTIME_MONDAY_1 420
2019-11-19 13:49:23 R-1.P1_ENDTIME_MONDAY_10 1440
2019-11-19 13:49:23 R-1.P1_ENDTIME_MONDAY_11 1440
2019-11-19 13:49:23 R-1.P1_ENDTIME_MONDAY_12 1440
2019-11-19 13:49:23 R-1.P1_ENDTIME_MONDAY_13 1440
2019-11-19 13:49:23 R-1.P1_ENDTIME_MONDAY_2 660
2019-11-19 13:49:23 R-1.P1_ENDTIME_MONDAY_3 900
2019-11-19 13:49:23 R-1.P1_ENDTIME_MONDAY_4 1320
2019-11-19 13:49:23 R-1.P1_ENDTIME_MONDAY_5 1440
2019-11-19 13:49:23 R-1.P1_ENDTIME_MONDAY_6 1440
2019-11-19 13:49:23 R-1.P1_ENDTIME_MONDAY_7 1440
2019-11-19 13:49:23 R-1.P1_ENDTIME_MONDAY_8 1440
2019-11-19 13:49:23 R-1.P1_ENDTIME_MONDAY_9 1440
2019-11-19 13:49:23 R-1.P1_ENDTIME_SATURDAY_1 420
2019-11-19 13:49:23 R-1.P1_ENDTIME_SATURDAY_10 1440
2019-11-19 13:49:23 R-1.P1_ENDTIME_SATURDAY_11 1440
2019-11-19 13:49:23 R-1.P1_ENDTIME_SATURDAY_12 1440
2019-11-19 13:49:23 R-1.P1_ENDTIME_SATURDAY_13 1440
2019-11-19 13:49:23 R-1.P1_ENDTIME_SATURDAY_2 660
2019-11-19 13:49:23 R-1.P1_ENDTIME_SATURDAY_3 705
2019-11-19 13:49:23 R-1.P1_ENDTIME_SATURDAY_4 765
2019-11-19 13:49:23 R-1.P1_ENDTIME_SATURDAY_5 900
2019-11-19 13:49:23 R-1.P1_ENDTIME_SATURDAY_6 1320
2019-11-19 13:49:23 R-1.P1_ENDTIME_SATURDAY_7 1440
2019-11-19 13:49:23 R-1.P1_ENDTIME_SATURDAY_8 1440
2019-11-19 13:49:23 R-1.P1_ENDTIME_SATURDAY_9 1440
2019-11-19 13:49:23 R-1.P1_ENDTIME_SUNDAY_1 420
2019-11-19 13:49:23 R-1.P1_ENDTIME_SUNDAY_10 1440
2019-11-19 13:49:23 R-1.P1_ENDTIME_SUNDAY_11 1440
2019-11-19 13:49:23 R-1.P1_ENDTIME_SUNDAY_12 1440
2019-11-19 13:49:23 R-1.P1_ENDTIME_SUNDAY_13 1440
2019-11-19 13:49:23 R-1.P1_ENDTIME_SUNDAY_2 660
2019-11-19 13:49:23 R-1.P1_ENDTIME_SUNDAY_3 705
2019-11-19 13:49:23 R-1.P1_ENDTIME_SUNDAY_4 765
2019-11-19 13:49:23 R-1.P1_ENDTIME_SUNDAY_5 900
2019-11-19 13:49:23 R-1.P1_ENDTIME_SUNDAY_6 1320
2019-11-19 13:49:23 R-1.P1_ENDTIME_SUNDAY_7 1440
2019-11-19 13:49:23 R-1.P1_ENDTIME_SUNDAY_8 1440
2019-11-19 13:49:23 R-1.P1_ENDTIME_SUNDAY_9 1440
2019-11-19 13:49:23 R-1.P1_ENDTIME_THURSDAY_1 420
2019-11-19 13:49:23 R-1.P1_ENDTIME_THURSDAY_10 1440
2019-11-19 13:49:23 R-1.P1_ENDTIME_THURSDAY_11 1440
2019-11-19 13:49:23 R-1.P1_ENDTIME_THURSDAY_12 1440
2019-11-19 13:49:23 R-1.P1_ENDTIME_THURSDAY_13 1440
2019-11-19 13:49:23 R-1.P1_ENDTIME_THURSDAY_2 660
2019-11-19 13:49:23 R-1.P1_ENDTIME_THURSDAY_3 900
2019-11-19 13:49:23 R-1.P1_ENDTIME_THURSDAY_4 1320
2019-11-19 13:49:23 R-1.P1_ENDTIME_THURSDAY_5 1440
2019-11-19 13:49:23 R-1.P1_ENDTIME_THURSDAY_6 1440
2019-11-19 13:49:23 R-1.P1_ENDTIME_THURSDAY_7 1440
2019-11-19 13:49:23 R-1.P1_ENDTIME_THURSDAY_8 1440
2019-11-19 13:49:23 R-1.P1_ENDTIME_THURSDAY_9 1440
2019-11-19 13:49:23 R-1.P1_ENDTIME_TUESDAY_1 420
2019-11-19 13:49:23 R-1.P1_ENDTIME_TUESDAY_10 1440
2019-11-19 13:49:23 R-1.P1_ENDTIME_TUESDAY_11 1440
2019-11-19 13:49:23 R-1.P1_ENDTIME_TUESDAY_12 1440
2019-11-19 13:49:23 R-1.P1_ENDTIME_TUESDAY_13 1440
2019-11-19 13:49:23 R-1.P1_ENDTIME_TUESDAY_2 660
2019-11-19 13:49:23 R-1.P1_ENDTIME_TUESDAY_3 900
2019-11-19 13:49:23 R-1.P1_ENDTIME_TUESDAY_4 1320
2019-11-19 13:49:23 R-1.P1_ENDTIME_TUESDAY_5 1440
2019-11-19 13:49:23 R-1.P1_ENDTIME_TUESDAY_6 1440
2019-11-19 13:49:23 R-1.P1_ENDTIME_TUESDAY_7 1440
2019-11-19 13:49:23 R-1.P1_ENDTIME_TUESDAY_8 1440
2019-11-19 13:49:23 R-1.P1_ENDTIME_TUESDAY_9 1440
2019-11-19 13:49:23 R-1.P1_ENDTIME_WEDNESDAY_1 420
2019-11-19 13:49:23 R-1.P1_ENDTIME_WEDNESDAY_10 1440
2019-11-19 13:49:23 R-1.P1_ENDTIME_WEDNESDAY_11 1440
2019-11-19 13:49:23 R-1.P1_ENDTIME_WEDNESDAY_12 1440
2019-11-19 13:49:23 R-1.P1_ENDTIME_WEDNESDAY_13 1440
2019-11-19 13:49:23 R-1.P1_ENDTIME_WEDNESDAY_2 660
2019-11-19 13:49:23 R-1.P1_ENDTIME_WEDNESDAY_3 900
2019-11-19 13:49:23 R-1.P1_ENDTIME_WEDNESDAY_4 1320
2019-11-19 13:49:23 R-1.P1_ENDTIME_WEDNESDAY_5 1440
2019-11-19 13:49:23 R-1.P1_ENDTIME_WEDNESDAY_6 1440
2019-11-19 13:49:23 R-1.P1_ENDTIME_WEDNESDAY_7 1440
2019-11-19 13:49:23 R-1.P1_ENDTIME_WEDNESDAY_8 1440
2019-11-19 13:49:23 R-1.P1_ENDTIME_WEDNESDAY_9 1440
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_FRIDAY_1 14.0
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_FRIDAY_10 17.0
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_FRIDAY_11 17.0
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_FRIDAY_12 17.0
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_FRIDAY_13 17.0
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_FRIDAY_2 21.0
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_FRIDAY_3 14.0
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_FRIDAY_4 21.0
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_FRIDAY_5 14.0
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_FRIDAY_6 17.0
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_FRIDAY_7 17.0
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_FRIDAY_8 17.0
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_FRIDAY_9 17.0
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_MONDAY_1 14.0
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_MONDAY_10 17.0
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_MONDAY_11 17.0
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_MONDAY_12 17.0
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_MONDAY_13 17.0
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_MONDAY_2 21.0
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_MONDAY_3 14.0
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_MONDAY_4 21.0
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_MONDAY_5 14.0
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_MONDAY_6 17.0
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_MONDAY_7 17.0
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_MONDAY_8 17.0
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_MONDAY_9 17.0
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_SATURDAY_1 14.0
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_SATURDAY_10 17.0
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_SATURDAY_11 17.0
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_SATURDAY_12 17.0
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_SATURDAY_13 17.0
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_SATURDAY_2 21.0
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_SATURDAY_3 14.0
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_SATURDAY_4 21.0
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_SATURDAY_5 14.0
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_SATURDAY_6 21.0
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_SATURDAY_7 14.0
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_SATURDAY_8 17.0
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_SATURDAY_9 17.0
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_SUNDAY_1 14.0
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_SUNDAY_10 17.0
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_SUNDAY_11 17.0
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_SUNDAY_12 17.0
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_SUNDAY_13 17.0
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_SUNDAY_2 21.0
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_SUNDAY_3 14.0
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_SUNDAY_4 21.0
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_SUNDAY_5 14.0
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_SUNDAY_6 21.0
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_SUNDAY_7 14.0
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_SUNDAY_8 17.0
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_SUNDAY_9 17.0
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_THURSDAY_1 14.0
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_THURSDAY_10 17.0
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_THURSDAY_11 17.0
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_THURSDAY_12 17.0
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_THURSDAY_13 17.0
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_THURSDAY_2 21.0
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_THURSDAY_3 14.0
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_THURSDAY_4 21.0
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_THURSDAY_5 14.0
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_THURSDAY_6 17.0
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_THURSDAY_7 17.0
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_THURSDAY_8 17.0
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_THURSDAY_9 17.0
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_TUESDAY_1 14.0
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_TUESDAY_10 17.0
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_TUESDAY_11 17.0
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_TUESDAY_12 17.0
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_TUESDAY_13 17.0
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_TUESDAY_2 21.0
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_TUESDAY_3 14.0
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_TUESDAY_4 21.0
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_TUESDAY_5 14.0
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_TUESDAY_6 17.0
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_TUESDAY_7 17.0
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_TUESDAY_8 17.0
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_TUESDAY_9 17.0
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_WEDNESDAY_1 14.0
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_WEDNESDAY_10 17.0
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_WEDNESDAY_11 17.0
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_WEDNESDAY_12 17.0
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_WEDNESDAY_13 17.0
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_WEDNESDAY_2 21.0
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_WEDNESDAY_3 14.0
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_WEDNESDAY_4 21.0
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_WEDNESDAY_5 14.0
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_WEDNESDAY_6 17.0
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_WEDNESDAY_7 17.0
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_WEDNESDAY_8 17.0
2019-11-19 13:49:23 R-1.P1_TEMPERATURE_WEDNESDAY_9 17.0
2019-11-20 08:20:47 control 21.0
2019-11-20 08:20:47 hmstate 21.0
2019-11-20 08:20:47 state 21.0
2019-11-20 08:20:47 valve_position 100
2019-11-20 08:20:47 valve_position_STATUS 0
hmccu:
devspec 0012999395D0FA
dp:
0.CONFIG_PENDING:
OVAL 0
VAL 0
0.DUTY_CYCLE:
&n
Kann es sein das es mit ein Problem gibt hier im Forum.
Ich habe im obrigen Post die code tabs richtig gesetzt und noch einen Kommentar darunter gesetzt.
Beides ist wohl verschluckt worden.
Ulrich
@UvG:
Jupp, das meinte ich:-)
Danke
eurofinder
Zitat von: UvG am 20 November 2019, 09:12:58
Kann es sein das es mit ein Problem gibt hier im Forum.
Ich habe im obrigen Post die code tabs richtig gesetzt und noch einen Kommentar darunter gesetzt.
Beides ist wohl verschluckt worden.
Ulrich
Es ist einfach zu lang. Dann verschluckt er das Ende inkl. "/code" Tag
Du musst in 2 Teile teilen
und wie lang darf code tabs sein?
Ulrich
Zitat von: UvG am 20 November 2019, 18:57:16
und wie lang darf code tabs sein?
Ulrich
Kannst oben zählen ;)
EDIT: ah... nein. Kannst Du nicht mehr!
EDIT2: anscheinend um die 63.500 Zeichen
Zitat von: BM030 am 20 November 2019, 06:36:42
Hi,
beim starten von FHEM:
Es wird ccutype im Device 'BAD_Heizung_Wand' nicht gefunden! Keine Ahnung warum das beim Start nicht gesetzt ist.
Zitat von: BM030 am 20 November 2019, 06:36:42
beim übertragen des Profils:
Ich kann nur erkennen, dass keine passenden Readings zum Auslesen des Wochenprofils im Device 'BAD_Heizung_Wand' gefunden werden.
Sorry, bin da mit meinem Latein am Ende.
Anbei eine Version mit mehr Logs. Dazu verbose auf 5 stellen.
Risiko
Zitat von: Risiko am 21 November 2019, 19:14:21
Ich kann nur erkennen, dass keine passenden Readings zum Auslesen des Wochenprofils im Device 'BAD_Heizung_Wand' gefunden werden.
Sorry, bin da mit meinem Latein am Ende.
Anbei eine Version mit mehr Logs. Dazu verbose auf 5 stellen.
Risiko
Das finde ich auch sehr komisch, beim Thermostat sind die Reading da, ich habe im Unterforum https://forum.fhem.de/index.php/topic,51339.msg995333.html#msg995333 (https://forum.fhem.de/index.php/topic,51339.msg995333.html#msg995333) bei der Geräte Definition um Hilfe gefragt. Ich denke auch, dass das gerade mein Problem ist. Setze ich dem erzeugten Befehl
set BAD_Heizung_Wand config TEMPERATURE_MONDAY_1=18.0 ENDTIME_MONDAY_1=360 per Hand ein "P1_ " davor werden die Daten in der CCU richtig gesetzt, aber es kommen keine Readings in FHEM.
Ich würde erstmal ausschliessen, dass es an den fehlenden Readings liegt, bevor wir hier nach Fehlern im Weekprofile suchen.
Danke schonmal für Deine Hilfe
Greetings Gordon
Hallo Leute,
ab morgen gibt es eine neue Version, welche WeekdayTimer als Device zum Senden unterstützt.
So kann man Wochenprofile auch für den WDT erstellen.
Die neue passende Version von WeekdayTimer ist noch nicht im Svn. Kommt aber bald.
Siehe: https://forum.fhem.de/index.php/topic,105521.msg994590.html#msg994590
Risiko
Hallo!
Da wir heute mal wieder im kalten saßen, da die Heizung noch auf Werktag gestellt war, habe ich mir weekprofile mal wieder genauer angeschaut und die Funktion "useTopics" entdeckt.
Genau das, was ich gebrauchen kann :) Mal "eben schnell" alle Thermostate umprogrammieren.
2 kleine Probleme, die ich dabei nun hatte:
1.) Ich nutze nur 4 Zeitprogramme für jedes Profil. Schön wäre es, wenn man ein komplettes Topic kopieren könnte...würde etwas klickerei ersparen...gerade, wenn da mal mehrere Profile hinzukommen.
2.) Mir fehlt ein wenig die Kontrolle, ob ich bei allen Thermostaten den richtigen Plannamen vergeben habe. Ich hatte die Commandref so verstanden, dass diese Kontrolle mit
get <name> profile_references *
durchführen kann. Hier kommt jedoch nichts...und mit
get <name> profile_references <Planname>
kommt nur "0"
Habe ich etwas übersehen?
Gruß
Bismosa
Hallo Bismosa,
da ich aktuell im Urlaub bin nur kurz folgendes:
zu 1:
Eine Kopie erstellen geht doch ganz einfach. Zu kopierendes Profil auswählen und "+" Button in FHEMWEB drücken. Oder mit dem Befehl "set copy_profile"
zu 2:
Da hast du was falsch verstanden. Referenzen sind dafür dar, ein Profil mehrfach z.B. für zwei Thermostate ohne Kopie verwenden zu können. Die Zuordnung zum Thermostat erfolgt über das userAttr "weekprofile", was du in den Thermostatdefinitionen verwenden musst.
Hast du dir schon den wiki-Artikel https://wiki.fhem.de/wiki/Weekprofile durchgelesen?
Mehr dann ggf. im neuen Jahr.
Risiko.
Hallo!
Ist ja alles nicht so eilig. Ich wünsche einen schönen Urlaub!
zu 1) Ja...das erstellt eine Kopie von einem Profil. Ich würde mir eine Funktion wünschen, die gleich alle Profile eines Topics kopiert. :)
zu 2.) Stimmt. Gelesen habe ich den Wiki-Eintrag. Aber bin wohl mit den Begrifflichkeiten durcheinander geraten ::) Also würde ich mir hier noch eine Funktion wünschen, die anzeigt welche Geräte (ggf. mit welchem Profil) verbunden sind. Dann hat man noch eine Überprüfung, ob man sich vielleicht irgendwo vertippt hat :)
Und wo wir hier gerade bei "wünsch dir was" sind...
3.) Soweit ich weiß, könntest Du die "userAtrr" auch Global vorgeben, das man dies nicht mehr unter "userAttr" eintragen muss. Richtig genial (ich weiß aber nicht, ob FHEM das kann) wäre es, wenn es nur bei unterstützten Geräten des Moduls diese Attribute auftauchen.
Bitte nicht falsch verstehen! Ich finde das Modul SUPER! :) Ich bin da ein totaler Fan von. Es sind auch nur Vorschläge...ich weiß...besser wäre gleich einen Patch zu liefern...aber dazu komme ich leider derzeit nicht. Außerdem weiß ich nicht, ob diese Funktionen überhaupt von anderen Usern bzw. von Dir gewünscht wären :)
Schönen Urlaub weiterhin!
Gruß
Bismosa
Zitat von: bismosa am 26 Dezember 2019, 21:51:59
zu 1) Ich würde mir eine Funktion wünschen, die gleich alle Profile eines Topics kopiert. :)
Ok. Verstehe leider noch nicht wirklich den Sinn. Man muss dann doch ehe alle Profile noch bearbeiten. Vielleicht könntest du deinen Anwendungsfall etwas formulieren. Ggf. könnte ich mir einen Befehl "set copy_topic" vorstellen. In die GUI (FHEMWEB) wie beim "+" würde ich aber verzichten wollen.
Zitat von: bismosa am 26 Dezember 2019, 21:51:59
zu 2.) Also würde ich mir hier noch eine Funktion wünschen, die anzeigt welche Geräte (ggf. mit welchem Profil) verbunden sind. Dann hat man noch eine Überprüfung, ob man sich vielleicht irgendwo vertippt hat :)
Halte ich auch für sinnvoll. Muss ich mir mal überlegen, wie dass aussehen könnte. Wird aber etwas dauern.
Zitat von: bismosa am 26 Dezember 2019, 21:51:59
3.) Soweit ich weiß, könntest Du die "userAtrr" auch Global vorgeben, das man dies nicht mehr unter "userAttr" eintragen muss. Richtig genial (ich weiß aber nicht, ob FHEM das kann) wäre es, wenn es nur bei unterstützten Geräten des Moduls diese Attribute auftauchen.
Das würde ich nicht automatisch machen bzw. mache ich mit Absicht nicht, da nicht alle User diese Verbindung wollen\benötigen. UserAttr sollten jeweils explizit vom User gesetzt werden. Ggf. könnte ich mir aber ein Befehl wie "set add_userAttr_to_devices" vorstellen, der das Setzen übernimmt. Sehe ich aber nicht als wichtig.
Risiko.
Hallo!
ZitatVielleicht könntest du deinen Anwendungsfall etwas formulieren
Ich versuche es mal...
Topic "default" mit 4 Profilen (Wohnzimmer, Kinderzimmer, Bad, Schlafzimmer).
Nun habe ich ein neues Topic erstellt:
"Urlaub" ebenfalls mit diesen 4 Profilen, wo die Einstellungen zu den 4 Profilen (Default) aber sehr ähnlich sind.
Also quasi eine 1:1 Kopie des gesamten Topics mit allen Profilen, damit diese dann wieder angepasst werden können. Diese Profile benötige ich ja auch, da ja alle Heizkörper auf diese Profile reagieren.
ZitatMan muss dann doch ehe alle Profile noch bearbeiten
Auch wieder wahr. Vielleicht habe ich auch nur zu kompliziert dabei gedacht. Es ist halt auch ein wenig Einstellerei am Anfang einfach notwendig.
ZitatHalte ich auch für sinnvoll. Muss ich mir mal überlegen, wie dass aussehen könnte. Wird aber etwas dauern.
Ich hatte ja die Funktion "get <name> profile_references *" falsch verstanden. Ich hätte hier eher die Funktion "device_profiles" erhofft.
Hier mal Quick&Dirty was ich erwartet hätte:
$list .= ' device_profiles:noArg';
if($cmd eq "device_profiles") {
my $retHTML = "";
foreach my $dev (@{$hash->{SNDDEVLIST}}){
my $prfName = AttrVal($dev->{NAME},"weekprofile",undef);
next if (!defined($prfName));
Log3 $me, 5, "$me(Set): found device $dev->{NAME}";
$retHTML .= "$dev->{NAME} - $prfName <br>";
}
return $retHTML;
}
$list =~ s/ $//;
return "Unknown argument $cmd choose one of $list";
}
########################################### Hier wird nur eine Liste erzeugt mit Gerätename - Profilname. Ist auf jeden Fall schon mal sehr hilfreich :)
Schöner wäre es vielleicht, wenn diese Liste immer in den Internals auftaucht (Irgendwo hatte ich das neulich noch gesehen...finde es aber gerade nicht wieder).
Kann bestimmt auch noch verbessert werden....z.B. Geräte ohne das Reading mit anzeigen etc.
ZitatWird aber etwas dauern.
Ist ja alles nicht eilig :)
ZitatDas würde ich nicht automatisch machen bzw. mache ich mit Absicht nicht, da nicht alle User diese Verbindung wollen\benötigen. UserAttr sollten jeweils explizit vom User gesetzt werden. Ggf. könnte ich mir aber ein Befehl wie "set add_userAttr_to_devices" vorstellen, der das Setzen übernimmt. Sehe ich aber nicht als wichtig.
Ja...Nein. Nicht die Attribute per Code verändern. Das wäre zu gefährlich, das da was überschrieben bzw. ungewolltes verändert wird. Ich habe gerade mal versucht mich einzulesen. Wenn ich es richtig verstanden habe geht es so:
addToAttrList($attrib); -> Attribut zu Global hinzufügen -> in allen Geräten verfügbar
addToDevAttrList($name, $attrib); -> Attribut zu einem Device hinzufügen -> Nur bei dem Device verfügbar
Schade, schön wäre es, wenn man die Attribute für bestimmte Devices (gefiltert mittels Devspec oder so) festlegen könnte. Sonst muss man ja laufend prüfen, ob ein neues Gerät hinzugekommen ist? Keine Ahnung, wie das funktioniert.
Gruß
Bimsosa
Und was ich noch vergessen habe:
Ich finde das Modul wirklich super! Das soll kein Meckern sein, sondern sind alles nur "freie" Vorschläge :)
Und was ich noch vergessen habe:
Zitat(Irgendwo hatte ich das neulich noch gesehen...finde es aber gerade nicht wieder)
So etwas lässt mir ja keine Ruhe...aber ähnlich ist es z.B. im ReadingsWatcher gelöst. Allerdings über Readings:
Readings
alive 0 07.01.2020 21:47
devices 1 07.01.2020 21:47
readings 0 07.01.2020 21:47
state ok 07.01.2020 21:47
timeoutdevs none 07.01.2020 21:47
timeouts 0 07.01.2020 21:47Und die Devices erscheinen auch unter "Probably associated with"
Außerdem wird hier auch das Attribut in Global erstellt um es bei jedem Device hinzuzufügen. Vielleicht ist das ja eine gute Vorlage?
Gruß
Bismosa
Hallo Bismosa,
danke für deine Ausführungen.
Leider habe ich aktuell wenig Zeit.
Werde mir aber bei Gelegenheit mal Gedanken machen und mich dann wieder melden.
Risiko.
Hallo,
erstmal vielen Dank an Risiko und die vielen Tester und Ideengeber hier die dieses tolle Modul entwickelt haben.
Ich habe das gleiche Verhalten wie Vrob01 beobachtet, welches eine Nutzung von ON/OFF mit MAX! Thermostaten nicht erlaubt:
Zitat von: Vrob01 am 17 September 2018, 20:53:14
Das habe ich schon probiert, dann setzt er die Temperatur zwar korrekt auf 30.0°C (oder 5°C), aber eben nicht auf on/off. Bei MAX sind die Werte 4.5°C und 30.5°C spezielle Werte mit denen die Thermostate dauerhaft auf 0% bzw. 100% Öffnung gesetzt werden können
Da er das in seinem ersten Post gut erläutert hat mache ich das hier nicht noch mal.
Das Problem ist hier tatsächlich in dem Modul "MaxCommon.pm" welches den erlaubten Temperaturbereich zwischen 5 und 30 Grad, sowie den Schlüsselwörtern "on" und "off" festlegt.
Man kann leider nicht einfach diese Schlüsselwörter in die Attribute ,,tempON" und ,,tempOFF" übernehmen, da dann das Drop-Down Menü für die Temperaturauswahl im Widget nicht mehr gefüllt wird.
Auch wenn Risiko das Modul so entwickelt hat das es möglichst wenig Device-spezifische Optionen enthält, habe ich eine Eingebaut um dieses verhalten abzufangen (3 Zeilen ab Zeile 415).
Wenn die Werte für ON/OFF 4.5 bzw. 30.5 sind werden die entsprechenden Schlüsselwörter in die Temperatur übernommen (aber eben nur bei diesen beiden Werten und bei MAX!) und nicht mehr die hinterlegten Werte.
Dadurch kann man nun on und off nutzen, habe es getestet mit Heizungs- und Wandthermostaten.
Da ich nur die MAX! Geräte habe und keinen HM wäre es toll wenn das jemand noch mal einsetzen kann der HM hat um auszuschließen das es hier unerwünschte Nebeneffekte gibt.
Viele Grüße, Mirko
Hallo Moerk,
meiner Meinung nach ist es ein Fehler in MaxCommon.pm.
Ein
set <device> desiredTemperature 4.5
wird auch automatisch in off umgesetzt.
Bei
set <device> weekprofile Fri 4.5,6:00 ....
gibt es den beschriebenen Fehler. Ich habe die Erwartungshaltung, dass hier 4.5 (oder kleiner) auch automatisch in off umgesetzt wird. Natürlich äquivalent für on.
Wenn ich mal Zeit hätte, würde ich sogar einen Patch für den neuen Maintainer wzut bereitstellen :-\
Vielleicht kann es ja jemand anderes bei Ihm anbringen. Ich selbst nutze on|off nicht. ;)
Risiko
Zitat von: Risiko am 24 Januar 2020, 20:05:18
Ich habe die Erwartungshaltung, dass hier 4.5 (oder kleiner) auch automatisch in off umgesetzt wird
nur Erwartungen zu haben nützt nichts, da Wzut schon ein alter Mann ist beherrscht er die Kunst des Gedankenlesens nicht und so muss man mit ihm ganz altmodisch reden (bzw. schreiben) :)
So hier !? :)
https://forum.fhem.de/index.php/topic,107753.msg1017180.html#msg1017180
Guten Morgen,
vielen Dank an Risiko für die weitere Analyse und Einschätzung und an Wzut für die Aufnahme und den Fix.
Nun funktioniert die on/off Geschichte einwandfrei, ohne meinen Eingriff :)
Viele Grüße,
Mirko
kein Problem
Zitat von: Risiko am 24 Januar 2020, 20:05:18
dass hier 4.5 (oder kleiner) auch automatisch in off umgesetzt wird. Natürlich äquivalent für on.
erlaubt ist jetzt aber auch nur 4.5 bzw 30.5 zusätzlich. Ich kann natürlich noch vor dem senden auch kleiner 4.5 in 4.5 wandlen falls das in irgendeiner Form Sinn macht.
Bei on dann halt alles oberhalb 30.5
Ich denke, dass ist nicht so wichtig und zudem Ansichtssache. Werte kleiner off bzw. größer on kann über FHEMWEB keiner senden.
Wenn es trotzdem vorkommt, dann ist eine Fehlermeldung evtl. sogar angebrachter. Hier hat der User einen Fehler gemacht (Konfiguration, etc.)
Risiko.
Hallo.
Auf Grundlage von
Zitat von: bismosa am 07 Januar 2020, 21:02:53bismosa
Beitrag habe ich einen neuen get Befehl (nur bei Verwendung von Topics)
get <weekprofile> associations 0|1
eingebaut.
Der zweite Parameter steuert nur das Ausgabeformat (0 - HTML Tabelle, 1-json Liste).
In einer Ausbaustufe könnte ich mir auch vorstellen, dass man in der HTML Ansicht gleich die Verbindung setzen kann. Profil bei jedem Device dann als Dropdown auswählbar.
Dann macht\führt auch der Bediener die Verbindung explizit und das Atribut 'weekprofile' wird dann ins Device gesetzt.
Ob das an diese Stelle (FHEMWEB uiDialog) mgl. ist, weiß ich noch nicht.
Morgen dann per Update verfügbar.
Risiko
Hallo!
Gerade mal ausprobiert. Das sieht richtig gut aus! Vielen Dank!
Zur Temperatureinstellung:
ZitatIch denke, dass ist nicht so wichtig und zudem Ansichtssache. Werte kleiner off bzw. größer on kann über FHEMWEB keiner senden.
Meiner Ansicht nach würde ich es "praktisch" finden, wenn auch andere Werte (< 4.5 bzw. > 30.5) direkt in On bzw. Off umgesetzt werden.
Falls man z.B. ein Script in den MyUtils oder ein anderes Modul verwendet, das z.B. Dynamisch bzw. berechnet die Temperaturen setzt oder auch ein Modul, bei dem die Temperatureinstellungen etwas anderes erlauben sollten...wäre dies "praktisch". Die Fehlermeldungen könnte man schnell übersehen und wundert sich dann, warum nichts funktioniert.
Aber wichtig würde ich dies nicht einstufen :) Bisher ist mir kein Modul bekannt, das hier Pfuschen könnte (außer Max_Temperature ;) )
Gruß
Bismosa
@Risiko, ich nutze selbst weekprofile schon ewig, aber es gibt da einen Punkt der mich schon immer "gestört" hat.
Wenn ich ein MAX Device habe das bereits ein Wochenprofil in seinen Readings hat, habe aber noch kein Profil dafür in weekprofile (z.B. neu Anfang)
dann muss ich quasi einmal alle Werte abschreiben und damit das Grundprofil erstellen.
Eleganter wäre es IMHO wenn MAX entweder eine Exportfunktion hätte oder weekprofile eine Import.
Version A , Export MAX
neues Set Kommando in MAX export_weekprofile to <Ziel> , d.h. das Maxmodul würde ein set <name> profile_data <JSON> ausführe.
Hier ist mit Z.Z. noch unklar in welches Profil und wie genau der JSON String ausschauen müsste.
Edit : ich habe das set export_Weekprofile drin und klapp gut. Ziel ist ein Dropdown aller definierten weekprofile Geräte
Der zugefügte Profil Name ist gleich dem MAX Device Namen.
Version B , Import weekprofile
Wenig Arbeit für mich, dafür um so mehr für dich.
Zitat von: bismosa am 27 Januar 2020, 20:24:55
Bisher ist mir kein Modul bekannt, das hier Pfuschen könnte (außer Max_Temperature ;) )
Na dann weißt ja auch, an wen du dich wenden musst. ;D
Zitat von: Wzut am 28 Januar 2020, 09:35:47
Version A , Export MAX
Version B , Import weekprofile
Hallo wzut,
ich finde Variante B besser. Die Funktion habe ich implizit schon. Hole ja die Wochenprofile von den Devices, wenn man weekprofile mit einem Gerät assoziiert. Stichwort master-Profile. Weiterhin geht der Import dann auch für HM, etc.
Prinzipiell geht es auch jetzt schon (aber evtl. etwas umständlich).
Nämlich so 1):
weekprofile A mit Assoziation zu device anlegen
weekprofile B mit Topics und ohne Assoziation anlegen
Masterprofil von A nach B senden
ggf. in B kopieren
oder so 2):
weekprofile A mit Assoziation zu device anlegen
masterprofil in A kopieren
Assoziation wieder entfernen
Auf diesen Weg kann man jetzt schon Wochenprofile von einem Hersteller zum Anderen transferieren.
Natürlich wäre eine Importfunktion eleganter.
Ich denke der reine Importbefehl ist überschaubar. Das Ganze ggf. ins FHEM-Widget zu integrieren, ist schon aufwendiger.
Ein
set weekprofile import <device>
Sollte erstmal reichen!?
Risiko.
ok , wie du magst. Das aktuelle geprüfte Wochenprofil befindet sich beim nächsten 10_MAX Update im Reading .wp_json
Bsp
.wp_json {"Sat":{"time":["24:00"],"temp":["24.5"]},"Sun":{"time":["06:00","22:00","24:00"],"temp":["17","21","17"]},"Mon":{"time":["06:00","09:00","17:00","23:00","24:00"],"temp":["17","21","17","21","17"]},"Tue":{"time":["06:00","09:00","17:00","23:00","24:00"],"temp":["17","21","17","21","17"]},"Wed":{"time":["06:00","09:00","17:00","23:00","24:00"],"temp":["17","21","17","21","17"]},"Thu":{"time":["06:00","09:00","17:00","23:00","24:00"],"temp":["17","21","17","21","17"]},"Fri":{"time":["24:00"],"temp":["24.5"]}}
Das wäre aber nicht nötig gewesen. Lese doch das Profil jetzt schon aus den Readings aus!
Nunja , ich hatte ja bereits erfolgreich den Export getestet und dazu brauchte ich den fertigen String.
Da es eh ein verstecktes Reading ist wird ihn die Mehrheit eh nie zu Gesicht bekommen :)
Hallo.
Neuer Befehl
import_profile <device> [profilename]
ist ab morgen verfügbar.
profilename ist <topic>:<name des Profils>
Ist profilename nicht angegeben, wird default:device verwendet.
Im Nachgang zu unserer Diskussion dahingehend, ob man die Konfigurationsdaten von weekprofile bei configDB-Nutzung auch in der DB speichern könnte:
Zitat von: Beta-User am 09 Februar 2020, 18:50:20Was configDB angeht, kann ich den Code gerne mal durchsehen, vorab testen und dann einen patch zur Verfügung stellen?
Anbei eine Testversion als komplette .pm dazu.
Der Ausgangscode ist da im wesentlichen mal (auskommentiert) drin gelassen und das so ausgestaltet, dass erst versucht wird, in der DB zu lesen, und dann im Filesystem samt vorausgehender log-1-Meldung, wenn die Suche in der db fehlschlägt. Damit sollten heutige configDB-Nutzer kein Problem haben, weil eine evtl. vorhandene file auch gelesen wird. Allerdings ist es ggf. etwas irritierend, dass der Wechsel nach configDB danach automatisch erfolgt, sobald man das nächste mal speichert...
Habe dafür aber keine wirklich gute Idee, außer das eben so zu machen.
Im Testsystem ohne configDB war auf die Schnelle kein Problem zu erkennen, aber intensiver getestet habe ich das zugegebenermaßen nicht, daher an der Stelle auch die komplette pm mit der Bitte um weitere Mittester (ich lasse das jetzt mal unter configdB weiter laufen, bin aber (noch) kein intensiver weekprofile-Nutzer).
Gruß, Beta-User
Danke Beta-User.
Ich habe es fast so übernommen. Nur wenn "configFile" gesetzt ist, wird trotz configdb die Datei verwendet.
Risiko.
Danke für die Rückmeldung!
Macht vielleicht Sinn, das nur automatisch zu übertragen, wenn der user sich "nichts" dabei gedacht hatte.
Vielleicht noch ein paar Anmerkungen:
- Wenn der user die File (mit abweichendem Pfad) nach configDB importiert hatte, ist m.E. ein filewrite ins filesysstem falsch/gegen die Erwartung. Da sollte eine komplexere Prüfung hin, wie z.B. ab hier: https://svn.fhem.de/trac/browser/trunk/fhem/fhem.pl#L5364.
- Evtl. wäre es eine Idee, die Änderung auch mit einem gewissen Vorlauf zu machen bzw. erst später "scharf" zu schalten. Neulich habe ich was ähnliches für RandomTimer vorbereitet, der wird auch ab featurelevel 6.1 das Reading "state" berücksichtigen, und nicht mehr auf Value() abstellen...
- Ein kurzer Kommentar in der cref wäre noch gut, wenn es so bleiben sollte (sonst ist es (fast) egal).
Bei Bedarf liefere ich gerne entsprechenden Code (auch als Patch).
Zitat von: Beta-User am 19 Februar 2020, 17:54:00
Danke für die Rückmeldung!
- Wenn der user die File (mit abweichendem Pfad) nach configDB importiert hatte, ist m.E. ein filewrite ins filesysstem falsch/gegen die Erwartung. Da sollte eine komplexere Prüfung hin, wie z.B. ab hier: https://svn.fhem.de/trac/browser/trunk/fhem/fhem.pl#L5364.
Wie soll der user das den hinbekommen haben. Bei abweichendem Pfad wird configDB nicht verwendet. Wäre meiner Meinung nach nur mit der Testversion mgl.
Oder ich verstehe nicht ganz, was du meinst.
Zitat von: Beta-User am 19 Februar 2020, 17:54:00
- Evtl. wäre es eine Idee, die Änderung auch mit einem gewissen Vorlauf zu machen bzw. erst später "scharf" zu schalten. Neulich habe ich was ähnliches für RandomTimer vorbereitet, der wird auch ab featurelevel 6.1 das Reading "state" berücksichtigen, und nicht mehr auf Value() abstellen...
Ja, vielleicht. Denke aber, dass die Anzahl der "Betroffenen" gering ist. Die Meisten werden die Änderung nicht mitbekommen.
Ich sehe auch keine größere mögliche Probleme. Schauen wir mal.
Zitat von: Beta-User am 19 Februar 2020, 17:54:00
- Ein kurzer Kommentar in der cref wäre noch gut, wenn es so bleiben sollte (sonst ist es (fast) egal).
Steht doch im Changelog. Sollte doch reichen. Siehe auch vorherige Anmerkung. Sehe das auch eher als Anpassung\Fix
Zitat von: Beta-User am 19 Februar 2020, 17:54:00
Bei Bedarf liefere ich gerne entsprechenden Code (auch als Patch).
Danke. Wenn es größere Probleme oder Nachbesserungen (z.B. wenn sich Betateilchen nochmal meldet) gibt, komme ich gern auf das Angebot zurück.
Mal schauen...
Risiko
Zitat von: Risiko am 20 Februar 2020, 20:13:12
Wie soll der user das den hinbekommen haben.
Eine (beliebige) file in configDB zu importieren, ist kein Problem, siehe ersten Abschnitt von help zu configDB.
Vermutlich wäre es dann einfacher, wenn überhaupt configDB genutzt wird, erst zu sehen, ob die Datei in der db ist, und ansonsten nur fileread zu machen. Dann muß der Nutzer aktiv importieren; hat er es gemacht, kommt die file aus der db.
War wohl mein Gedankenfehler, automatisch in die db zu schreiben. Baue das gerne entsprechend um...
Die Funktionen FileRead(), FileWrite() und FileDelete() wurden seinerzeit exakt deshalb gebaut, damit sich Modulentwickler keine Gedanken darüber machen müssen, ob ein Anwender mit configDB arbeitet oder nicht. Was hier nun passiert ist: Man hat durch ziemlich abstrusen perl-Code dafür gesorgt, dass diese Automatismen unnötigerweise komplett gebrochen werden.
Bin im Hintergrund schon dabei, die entsprechende Unterstützung zu leisten, damit das Modul vielleicht doch noch configDB-kompatibel wird.
Zitat von: Risiko am 20 Februar 2020, 20:13:12
Wenn es größere Probleme oder Nachbesserungen (z.B. wenn sich Betateilchen nochmal meldet)
Wenn ich in einer email schreibe, dass ich mich am Wochenende ausführlich melde, dann mache ich das auch... :)
Mir ist noch eine Kleinigkeit aufgefallen, die allerdings nicht direkt was mit configDB zu tun hat.
if (!defined($hash->{PROFILES})) {
Log3 $me, 4, "$me(writeProfileToFile): no pofiles to save";
return;
}
pofiles sind vermutlich für den Ar... 8)
Zitat von: betateilchen am 23 Februar 2020, 13:45:47
Was hier nun passiert ist: Man hat durch ziemlich abstrusen perl-Code dafür gesorgt, dass diese Automatismen unnötigerweise komplett gebrochen werden.
Bin im Hintergrund schon dabei, die entsprechende Unterstützung zu leisten, damit das Modul vielleicht doch noch configDB-kompatibel wird.
Grund dafür war\ist die Kompatibilität für das Attribut "configFile" zu halten und auch nur wenn dieses gesetzt ist.
Werde das sicherlich zeitnah ändern. Siehe PN.
Hallo,
ich Dummerchen bin gerade der Anweisung im Fhem-Log please import your config file ./log/weekprofile-Heizprofile.cfg into configDB! gefolgt und habe beim ersten Versuch den Pfad weggelassen. Nach Neustart waren alle Profile weg. Hab den Import dann nochmal mit ./log/weekprofile..... gemacht. Selbes Ergebnis. Wenn ich im weekprofile-Device jetzt das Attribut "configFile" auf "./log/weekprofile...." setze, bekomme ich aber auch keine Profile mehr. Die cfg.Datei ist aber in Ordnung soweit ich das erkennen kann.
Was kann ich tun?
Hallo.
Die Datei auf Platte wird bei Verwendung von configDB nicht mehr verwendet.
Du musst die Datei mit configDB import ./log/weekprofile-Heizprofile.cfg importieren.
Ab morgen geht auch ein configDB migrate.
Risiko
Hallo
Nach meinem monatlichen Update von Fhem, gestern, habe ich die folgende Warnungen erhalten:
2020.02.29 11:26:57 1: VerwarmingBadkamer(readProfilesFromFile): Can't open ./log/weekprofile-VerwarmingBadkamer.cfg: No such file or directory
2020.02.29 11:26:58 1: VerwarmingKeuken(readProfilesFromFile): Can't open ./log/weekprofile-VerwarmingKeuken.cfg: No such file or directory
2020.02.29 11:26:58 1: VerwarmingVlieringAchter(readProfilesFromFile): Can't open ./log/weekprofile-VerwarmingVlieringAchter.cfg: No such file or directory
2020.02.29 11:26:58 1: VerwarmingVlieringVoor(readProfilesFromFile): Can't open ./log/weekprofile-VerwarmingVlieringVoor.cfg: No such file or directory
2020.02.29 11:26:58 1: VerwarmingWoonkamer(readProfilesFromFile): Can't open ./log/weekprofile-VerwarmingWoonkamer.cfg: No such file or directory
Ich habe diesen Thread durchsucht, bin aber nicht findig geworden.
Habe ich etwas übersehen?
Grüss
Sibbe
Hallo.
Da scheint im Zusammenhang mit der Umstellung auf FileRead zu tun zu haben. Ggf. werde hier relative Pfade anders behandelt.
Versuche da mal mehr Infos zu sammeln.
Prüfe du doch mal die Berechtigungen des log Ordners.
Risiko
Hallo Risiko
Ich habe Fhem seit ein paar Monaten nicht mehr geändert.
Mein Fhem arbeitet immer noch "altmodisch" mit fhem.cfg
Grüss
Sibbe
Ok. Könntest du bitte trotzdem mal schauen, ob es die Dateien im log-Ordner gibt.
Danke.
Die Dateien sind nicht im log-Ordner anwesent.
Grüss
Sibbe
Ok.
Dann hast du die Profile auch noch nie gespeichert und verwendest nur das Default-Profil 18° konstant an allen Tagen.
Dann kannst du die Meldungen ignorieren.
Ich schreibe ggf. das noch gleich in die Logmeldung mit rein.
Risiko
Hallo Risiko,
Ich habe vor ungefähr zwei Jahren WeekProfiles erstellt. Ich habe diese an die WTs und die HTs gesendet.
Dies hat (und jetzt auch noch) reibungslos funktioniert. Erst nach einem shutdown restartwurden die Fehlermeldungen angezeigt.
Ich habe also kein Dauerprofil von beispielsweise 18° erstellt.
Grüss
Sibbe
Ok.
Es wird aber nur das master-Profil verwendet. Weitere Profile gibt es nicht, richtig?
Ich passe die Logmeldung an bzw. überlege mir was für diesen Fall.
Es sollte trotz der Meldung alles funktionieren!
Ab morgen sollte die Meldung wieder weg sein.
Risiko
Das ist richtig, da wird nur ein Master-Profil verwendet.
Und wie oben angegeben, alles funktioniert.
Vielen Dank für das tolle Modul und die schnelle Unterstützung.
Viele Grüsse
Sibbe
Ich habe mich gewundert, dass meine Profile plötzlich nicht mehr da waren und nur noch das default-Profile angezeigt wurde. Nach einigem Suchen bin ich dann darüber gestolpert, dass eine Verlagerung der Profile in die ConfiDB stattfand. Eigentlich sehr schön. Allerdings geht der Hinweis im Log, dass die Profile in die ConfigDB importiert werden sollen, unter. Es wäre schön, wenn auch die Command-Ref und das Wiki entsprechende Hinweise enthalten würden.
Vlg
Karlheinz
@Risiko, noch einen kleinen Wunsch :
In meiner PopUp Liste der möglichen Ziel Geräte sind IMHO einige zuviel.
Du könntest z.B. in weekprofile_ getDeviceType für gültige $type noch folgende Extra Prüfungen zum ausfiltern machen :
für Typ HM und MAX (bzw vermutlich global für alle) -> IsIgnored(Devicename) und IsDummy(Devicename)
für Typ HM -> Attribut readOnly != 1
Hallo Risiko,
« am: 01 März 2020, 19:13:57 »
Ab morgen sollte die Meldung wieder weg sein.
Risiko
Es hat geklapt! Die Meldungen sind weg. Vielen Dank.
Sibbe
Zitat von: Wzut am 03 März 2020, 07:30:52
@Risiko, noch einen kleinen Wunsch :
In meiner PopUp Liste der möglichen Ziel Geräte sind IMHO einige zuviel.
Du könntest z.B. in weekprofile_ getDeviceType für gültige $type noch folgende Extra Prüfungen zum ausfiltern machen :
für Typ HM und MAX (bzw vermutlich global für alle) -> IsIgnored(Devicename) und IsDummy(Devicename)
für Typ HM -> Attribut readOnly != 1
Lässt sich sicherlich machen.
Hättest du auch ein list von solchen Geräten?
Wenn wir einmal dabei sind, was ist mit IsDisabled?
readOnly bei HM heißt, ich kann das Profile abfragen aber nicht setzen?
Risiko
Nachtrag:
Hier mal eine erste Testversion.
Zitat von: Risiko am 03 März 2020, 19:44:24
Wenn wir einmal dabei sind, was ist mit IsDisabled?
Hatte ich mit Absicht nicht gelistet da IsDisabled mehr als nur 0 und 1 zurückgeben kann und weder MAX noch HM dieses Attribut bei ihren Thermostaten haben.
HM hat dummy und readOnly , MAX nur dummy und ignore haben sie alle. Deine angehängte Version schaut gut aus, die PopUp Liste auf meinem Testsystem ist drastisch geschrumpft !
Zitat von: Wzut am 03 März 2020, 20:52:06
Deine angehängte Version schaut gut aus, die PopUp Liste auf meinem Testsystem ist drastisch geschrumpft !
Hab es so eingecheckt.
Besteht die Möglichkeit Weekprofile für Steckdosen (Zigbee/Homematic) zu nutzen und statt Temperatur on/off mitzugeben?
Finde dazu im Wiki nichts passendes.
@Gunther: Über den "Umweg" WeekdayTimer sollte das gehen; ich meine, es hätte dazu auch mal irgendwo einen Thread gegeben...
Hallo zusammen,
Bei mir gab es beim Umstellen auf den Heizbetrieb eine Fehlermeldung beim restore mit Weekprofile.
Buzzy hat das Problem hier bereits erläutert: https://forum.fhem.de/index.php?topic=114464.0 (https://forum.fhem.de/index.php?topic=114464.0)
ZitatCUL_HM reject-set Room_Thermostat_Climate_BedRoom tempListMon: param 1:'(p1|p2|p3)' => 24:00 does not match options
tempListMon: [(prep|{exec})] (p1|p2|p3) -HH:MM- -temp- [...]
Es scheint als ob sich der Syntax für "set tempListMon" geändert hat.
Früher konnte man an den Climate Channel einfach ein
set Room_Thermostat_Climate_GuestRoom tempListMon 24:00 6.0
schicken - so wie es Weekprofile auch tut.
Nun ist es plötzlich nötig explizit P1, P2 oder P3 beim set mit anzugeben:
set Room_Thermostat_Climate_GuestRoom tempListMon p1 24:00 6.0
Ich dachte mir ich schreibe das mal in den offiziellen Weekprofile Thread, in der Hoffnung, dass hier Abhilfe geschaffen werden kann. Besten Dank, bisher hat das Modul bei mir wunderbar funktioniert.
Viele Grüße
Max
Hallo.
Ich sehe hier kein Fehler von weekprofile.
Wenn sich der Syntax geändert hat, dann sollte es auch im entsprechenden Modul betreffs Kompatibilität behoben werden.
Weekprofile kann erstmal nicht wissen, ob p1 oder p2 oder pN.
Vielleicht meldet sich ja der Modulentwickler noch zu Wort.
Risiko
Der WAF litt und den anderen im Haus war ein klein wenig zu frisch in der Übergangszeit, daher haben wir uns beholfen und ausnahmsweise die 98_weekprofile.pm direkt angepasst... bitte nur nachmachen, wenn Ihr wisst, was Ihr tut und bis martinp876 und Risiko sich geeinigt haben :) - und auf jeden Fall eine Sicherungskopie anlegen...
nano /opt/fhem/FHEM/98_weekprofile.pm
sucht Euch den Beginn der Prozedur
sub weekprofile_sendDevProfile(@)
dort fügt Ihr eine neue Zeile ein (die mit dem Kommentar)...
} elsif ($type eq "CUL_HM") {
my $k=0;
my $dayCnt = scalar(@dayToTransfer);
foreach my $day (@dayToTransfer){
$cmd .= "set $device tempList";
$cmd .= $day;
$cmd .= ($k < $dayCnt-1) ? " prep": " exec";
$cmd .= " p1" if AttrVal($device,"model",0) =~ m/.*HM-TC-IT.*/ ; ### Quick'n'Dirty Patch für unsere HM-TC-IT-WM-W-EU, geschrieben wird bei uns hier immer bewusst nur in Liste p1
my $tmpCnt = scalar(@{$prfData->{$day}->{"temp"}});
for (my $i = 0; $i < $tmpCnt; $i++) {
$cmd .= " ".$prfData->{$day}->{"time"}[$i]." ".$prfData->{$day}->{"temp"}[$i];
}
$cmd .= ($k < $dayCnt-1) ? "; ": "";
$k++;
}
danach im Frontend noch ein
reload 98_weekprofile.pm
dann sollte das Topic-Restore mit dem T Button im Frontend auch für die Wandthermostate wieder gehen
und gut ist für diese Übergangsperiode...
danke, Risiko, für das schöne und komfortable Modul!
Danke Lanhydrock.
Leider hat sich Martin noch nicht zu Wort gemeldet.
Wenn es hilft, könnte ich es auch übernehmen.
Dazu aber noch ein paar Fragen (habe ja kein HM):
- Betrifft es alle Geräte vom Typ CUL_HM oder nur einzelne Geräte?
- Geht immer p1 oder muss es auch mal p2, ohne p oder sonst was sein?
Einen Fix auf HM Seite würde ich jedenfalls begrüßen.
Risiko
Hallo Risiko,
das wäre super!
Bei mir betrifft es nur die Wandthermostate (HM-TC-IT-WM-W-EU), wenn ich direkt die Heizkörperthermostate (HM-CC-RT-DN) nutze funktioniert es bei mir weiterhin.
Bei mir geht immer p1.
Hoffentlich hilfts! Viele Grüße
wie schon an anderer Stelle angemarkt war ich leider 2 Wochen abwesend.
Morgen sollte es wieder gehen.
Zum Kommando:
get cmdList zeigt die Syntax an. GENAU diese wird geparst. Der Parser wurde scharf geschaltet und rejected alles, was nicht ins schema passt.
Es ist also eigentlich einfach, nachzusehen, wie ein Kommando aussehen muss.
p1/2/3 war nicht optional. Jetzt ist (morgen) ist es optional und P1 ist der default
Zitat von: martinp876 am 15 Oktober 2020, 15:30:00
wie schon an anderer Stelle angemarkt war ich leider 2 Wochen abwesend.
Morgen sollte es wieder gehen.
Zum Kommando:
get cmdList zeigt die Syntax an. GENAU diese wird geparst. Der Parser wurde scharf geschaltet und rejected alles, was nicht ins schema passt.
Es ist also eigentlich einfach, nachzusehen, wie ein Kommando aussehen muss.
p1/2/3 war nicht optional. Jetzt ist (morgen) ist es optional und P1 ist der default
Super, danke schon mal dafür!
Hatte mir in der Zwischenzeit mit dem Workarround von Lanhydrock weitergeholfen von ein paar Post weiter oben.
$cmd .= " p1" if AttrVal($device,"model",0) =~ m/.*HM-TC-IT.*/ ; ### Quick'n'Dirty Patch für unsere HM-TC-IT-WM-W-EU, geschrieben wird bei uns hier immer bewusst nur in Liste p1
Sollte ich diesen vor dem Update wieder raus nehmen?
Hallo,
ich habe versucht einen Thermostat mit HM CCU über das weekprofile zu steuern und es hat nicht funktioniert.
In einem anderen Thread habe ich das bereits diskutiert: https://forum.fhem.de/index.php/topic,116110.msg1103797.html#msg1103797
Also der generierte set Befehl in der Routine weekprofile_sendDevProfile schickt den Präfix R- mit.
Wenn ich hier beim Aufbau der Variablen dpTime und dpTemp den ermittelten Präfix weglasse funktioniert es.
Mache ich in der Bedienung einen Fehler, oder ist das ein Bug im weekprofile?
Danke & Grüße,
Roger
Hallo.
Das Setzen ohne Präfix (bei dir 'R-') scheint aber wohl nicht für alle CCU Geräte zu stimmen, oder?
Benötige hier Feedback, da andere Leute z.B. bei HmIP wohl keine Probleme haben und ich wie schon öfters gesagt kein HM habe.
Anbei eine Testversion, ohne Präfix für "HMCCUDEV HM". Bei "HMCCUDEV HMIP" habe ich es so gelassen.
Risiko
Danke!
Habe bei zap nachgefragt. https://forum.fhem.de/index.php/topic,116110.msg1105626.html#msg1105626
Grüße, Roger
Hallo,
mein erster Forum-Eintrag, man möge mir bitte evtl. Fehler verzeihen. :)
Ich möchte auch über weekprofile Wandthermostate (HM-TC-IT-WM-W-EU) und Heizkörperthermostate (HM-CC-RT-DN) steuern. Die Devices sind vom Type HMCCUDEV.
Die Wandthermostate brauchen einen Präfix "P1_" (z.B. "P1_TEMPERATURE_MONDAY=") im Kommando die Heizkörperthermostate brauchen keinen Präfix ((z.B. "TEMPERATURE_MONDAY=").
Wenn ich den Code von weekprofile richtig verstanden habe (meine Perl-Kenntnisse sind quasi = 0) wird in der Funktion "sub weekprofile_get_prefix_HM" der Präfix anhand von bestehenden Readings gebildet. Wenn aber die Readings nicht vorhanden sind geht das schief. Muss ich als Anwender hier dafür sorgen das die Readings vorhanden sind, sprich mach ich da was falsch ?
Die Readings lassen sich ja per clear löschen.
Ich habe jetzt mal zum testen in der Funktion den Devicetype (ccutype) abgefragt und abhängig davon den Präfix direkt beschrieben. Beim Wandthermostaten benutze ich nur das Programm "P1".
Dann funktioniert es mal für meine beiden Devicetypen. Es gibt aber vermutlich noch viele andere Devicetypen.
Danke, schon mal für eine Antwort.
Grüße, Peter
Genau das war meine Frage im letzten Post https://forum.fhem.de/index.php/topic,46117.msg1105242.html#msg1105242, welche nicht beantwortet wurde.
Als Anwender soll man da nichts machen müssen!
Zitat von: spe am 07 Dezember 2020, 23:16:54
Es gibt aber vermutlich noch viele andere Devicetypen.
Genau das ist das Problem bei Homematic bzw. der Umsetzung im HM-Modul. Jedes Gerät scheint hier anders zu funktionieren. Meine Anfragen an den Modulentwickler blieben bis jetzt alle unbeantwortet.
Daher bin ich auf die Hinweise, wie jetzt von dir, angewiesen.
Kannst du bitte deine Version hier zur Verfügung stellen?
Risiko
Hallo,
ich habe lediglich in der Function den Devicetyp eingelesen und dann anhand von diesem den Prefix überschrieben.
So ist man von den Readings unabhängig.
Ich habe leider nur diese 2 Typen im Einsatz, so das ich leider nicht mehr Infos beitragen kann.
sub weekprofile_get_prefix_HM($@)
{
my ($device,$base_name,$me) = @_;
my @prefix_lst = ("","R-1.P1_","R-","R-P1_","P1_");
my $prefix = undef;
foreach (@prefix_lst) {
my $reading = "$_"."$base_name";
my $time = ReadingsVal($device, $reading, "");
Log3 $me, 5, "$me(weekprofile_get_prefix_HM): check: $reading $time";
if ($time ne "") {
$prefix = $_;
last;
}
}
################### SPE Anpassung Start ###########################
my $devHash = $main::defs{$device};
my $model = $devHash->{ccutype};
Log3 $me, 5, "$me(weekprofile_get_prefix_HM): SPE-Anpassung model=$model, prefix=$prefix";
if($model eq "HM-TC-IT-WM-W-EU") {
$prefix="P1_"
} elsif ($model eq "HM-CC-RT-DN") {
$prefix=""
}
Log3 $me, 5, "$me(weekprofile_get_prefix_HM): model=$model, prefix=$prefix";
################### SPE Anpassung Ende ###########################
return $prefix;
}
Grüße, Peter
Hi Risiko,
auch von mir vielen Dank an das super praktische Modul! Habe nach einigen Jahren mal wieder geupdated und mich gleich nach Durchlesen des Theads auf das Anlegen von Wochenprofilen gestürzt!
Topics hatte ich kurz definiert, aktuell ist "attr wp_Bad useTopics 1" aber aus kommentiert. Möglicherweise stört ja ',"TOPIC":"default","REF":null}' am Ende des JSON-Strings vom Weekprofile-Konfigfile von Raum Bad.
Mir ist klar, dass man beim Editieren des "masters" damit rechnen muss, dass nach ein paar Sekunden die Änderung durch das Neueinlesen der Werte weg sind. Ist auch schwer zu vermeiden, da die Masteranzeige auch die von anderer Stelle gemachten Änderungen aktuell anzeigen soll.
Nach spätestens 20s ist das aber auch bei einem mit "+" erstellten Profil der Fall. D.h. ich sollte nach jeder "Zeitzeile" gleich auf Speichern klicken.
Ich hätte einen Vorschlag: Nach Klicken der Zahnräder könnte dann oberhalb der editierbaren Zeittabellen der Profilname angezeigt werden. So kann man sicher sein, nicht das master erwischt zu haben.
Ist das Überschreiben so gewollt?
Zitat von: spe am 08 Dezember 2020, 22:57:55
Hallo,
ich habe lediglich in der Function den Devicetyp eingelesen und dann anhand von diesem den Prefix überschrieben.
So ist man von den Readings unabhängig.
Ich habe leider nur diese 2 Typen im Einsatz, so das ich leider nicht mehr Infos beitragen kann.
Danke Peter für die Infos.
Ich bin noch am überlegen, ob ich es in irgend einer Art aufnehme. So spezielle Anhängigkeiten wollte ich nie haben. Sehe aber leider aufgrund der aktuellen Umsetzung im HM-Modul auch so richtig keine Alternativen.
Risiko
Zitat von: onurbi am 13 Dezember 2020, 13:35:00
Hi Risiko,
auch von mir vielen Dank an das super praktische Modul!
Danke.
Zitat von: onurbi am 13 Dezember 2020, 13:35:00
Topics hatte ich kurz definiert, aktuell ist "attr wp_Bad useTopics 1" aber aus kommentiert. Möglicherweise stört ja ',"TOPIC":"default","REF":null}' am Ende des JSON-Strings vom Weekprofile-Konfigfile von Raum Bad.
Verstehe leider nicht, was du fragen\sagen willst
Zitat von: onurbi am 13 Dezember 2020, 13:35:00
Nach spätestens 20s ist das aber auch bei einem mit "+" erstellten Profil der Fall. D.h. ich sollte nach jeder "Zeitzeile" gleich auf Speichern klicken.
Nein, das ist meiner Meinung nach nicht sinnvoll. Komplett bearbeiten und speichern. Dann erst wieder bearbeiten, wenn die Änderungen vom Device übernommen wurden.
Während der Bearbeitung stattfindende Änderungen, werden im Bearbeitungsmodus nicht detektiert und folglich durch das Speichern ggf. wieder überschrieben.
Zitat von: onurbi am 13 Dezember 2020, 13:35:00
Ich hätte einen Vorschlag: Nach Klicken der Zahnräder könnte dann oberhalb der editierbaren Zeittabellen der Profilname angezeigt werden. So kann man sicher sein, nicht das master erwischt zu haben.
Kling sinnvoll. Mal schauen, wenn ich etwas Zeit habe, kommt es mit rein.
Zitat von: onurbi am 13 Dezember 2020, 13:35:00
Ist das Überschreiben so gewollt?
Ja, beim Speichern ist das überschreiben gewollt.
Zitat>Topics hatte ich kurz definiert, aktuell ist "attr wp_Bad useTopics 1" aber aus kommentiert. Möglicherweise stört ja ',"TOPIC":"default","REF":null}' am Ende des JSON-Strings vom Weekprofile-Konfigfile von Raum Bad.
Verstehe leider nicht, was du fragen\sagen willst
Sollte nur meine Konfiguration beschreiben, dachte wäre vielleicht wichtig.
ZitatNein, das ist meiner Meinung nach nicht sinnvoll
Da es sonst niemand als störend erwähnt hat, muss ich vielleicht anders vorgehen.
So sind Änderungen auf Dauer halt leicht "mühsam" weil ich immer wieder von vorne anfangen muss. Kann doch nicht im Sinne des Erfinders sein.
ZitatJa, beim Speichern ist das überschreiben gewollt.
Ich habe mich vielleicht unklar ausgedrückt. Ich meinte das Löschen der Änderungen auf die Uhrzeiten welche vorher dastanden. Ich habe ja noch
nicht nicht den "Speichern" Button geklickt.
Zitat von: onurbi am 14 Dezember 2020, 20:34:18
So sind Änderungen auf Dauer halt leicht "mühsam" weil ich immer wieder von vorne anfangen muss.
Verstehe ich leider nicht.
Zitat von: onurbi am 14 Dezember 2020, 20:34:18
Ich meinte das Löschen der Änderungen auf die Uhrzeiten welche vorher dastanden. Ich habe ja noch nicht nicht den "Speichern" Button geklickt.
Verstehe ich leider auch nicht.
Ich liste mal die Schritte auf, die zum Problem führen:
- Weekprofile master mit "+" kopieren
- Name des kopierten Profiles ist "HO"
- Auswählen von"HO"
- Zahnräder klicken
- Erste Uhrzeit Montag von 8:00 auf 8:05 ändern
- 30 Sekunden warten
- Die Uhrzeit springt wieder zurück auf 8:00
Ich kann natürlich vor Ablauf der 20s auf Speichern klicken. Dann wird auch gespeichert. So sind größere Änderungen mit unnötig viel Aufwand verbunden weil ich nach jeder Anpassung Speichern klicken muss, sie war sonst nicht wirksam. Nach 30 Sekunden war die Arbeit für die Katz.
Gibt es irgendeine Möglichkeit, dieses "Undo" zu verhindern?
Solange man im Edit mode ist, sollte das intervallgesteuerte Reading gestoppt sein.
Zitat von: onurbi am 15 Dezember 2020, 19:54:43
Ich liste mal die Schritte auf, die zum Problem führen:
....
Ich kann natürlich vor Ablauf der 20s auf Speichern klicken. Dann wird auch gespeichert. So sind größere Änderungen mit unnötig viel Aufwand verbunden weil ich nach jeder Anpassung Speichern klicken muss, sie war sonst nicht wirksam.
Gibt es irgendeine Möglichkeit, dieses "Undo" zu verhindern?
Solange man im Editmode ist, sollte das nicht passieren.
habe versucht das nachzustellen, ich habe den edit Mode jetzt 30 Minuten unberührt offen gehabt. Es ist nichts zurückgesprungen. Was aber die Werte löscht ist ein Refresh im Browser.
Schau mal was du in Device WEB (oder dem entsprechenden Web-Frontend) im Attribut longpoll hast. Teste mal 1 oder websocket ..
Zitat von: kadettilac89 am 16 Dezember 2020, 08:22:18Es ist nichts zurückgesprungen
Danke fürs Nachstellen. Das erklärt, warum es sonst niemandem aufgefallen ist.
Ich habe ein "list WEB" ausgeführt. Ich hoffe, das würde das Attribut logpoll auflisten. Es ist "leider" nicht dabei:
Internals:
BYTES_READ 8222737
BYTES_WRITTEN 6005549
CONNECTS 435
CSRFTOKEN csrf_283651142539926
DEF 8083 global
FD 7
FUUID 5fd1ce0d-f33f-cf93-543c-8d1654c7febef272
NAME WEB
NR 6
NTFY_ORDER 50-WEB
PORT 8083
STATE Initialized
TYPE FHEMWEB
READINGS:
2020-12-10 08:28:13 state Initialized
Attributes:
editConfig 1
stylesheetPrefix darkIm Sourcecode der Webseite (Ctrl-U) im Edit mode habe ich zumindest nicht das Wort "refresh" gefunden.
Nur weil es bis jetzt keiner gemeldet hat heißt es nicht, dass sonst keiner betroffen ist. Kann auch sein, dass alle anderen immer zwischendurch speichern.
Wähle das Attribut mal aus und setze es auf 1 oder longpoll ... sind ja nur 3 Werte möglich. Alle 3 mal testen sollte kein großer Aufwand sein.
Das mit dem Refresh hängt von Browser und auch davon ab, ob direkt oder über reverse Proxy o. ä. zugegriffen wird. Bei mir läuft es über einen reverse Proxy.
Zitat von: kadettilac89 am 16 Dezember 2020, 08:48:57
Kann auch sein, dass alle anderen immer zwischendurch speichern.
Klar!
Zitat von: kadettilac89 am 16 Dezember 2020, 08:48:57Alle 3 mal testen sollte kein großer Aufwand sein.
Nein, ist kein Problem. Teste ich heute Abend.
Kennst Du den Defaultwert von longpoll ?
Zitat von: kadettilac89 am 16 Dezember 2020, 08:48:57
Das mit dem Refresh hängt von Browser und auch davon ab, ob direkt oder über reverse Proxy o. ä. zugegriffen wird. Bei mir läuft es über einen reverse Proxy.
Bei mir geht es direkt.
default ist afaik "1", das aber v.a. aus Kompabilitätsgründen zu einigen älteren Browsern, die ws noch nicht unterstützen. Zu empfehen wäre mAn. "ws".
An der Stelle ein großes Danke an Risiko für's Einbauen der Unterstützung von MQTT2_DEVICE als neuen Client für weekprofile!
Bin mal gespannt, wie viele das Feature nutzen werden :) . Ist in der Umsetzung auf der MQTT2_DEVICE-Seite nicht ganz trivial, weil jedes Endgerät ein anderes Zielformat haben will und man das daher passend konvertieren muss, bevor man publisht.
Beispielcode ist ab heute auch im svn zu finden, die Kette beginnt mit dem attrTemplate zigbee2mqtt_thermostat_with_weekrofile und der zugehörigen myUtils-File.
Zitat von: onurbi am 15 Dezember 2020, 19:54:43
Ich liste mal die Schritte auf, die zum Problem führen:
Ich kann das auch nicht nachstellen.
Es kann nur mit der Verbindung zwischen FHEM und Browser zu tun haben.
Bei click auf die Zahnräder wird das Wochenprofil zum Browser gesendet. Die Bearbeitung erfolgt mir JavaScript vollständig clientseitig im Browser, welcher das vollständige Profil beim Speichern wieder an FHEM (weekprofile) sendet.
Ich weiß nicht, wer ein Refresh der Seite auslösen sollte.
Risiko
Zitat von: kadettilac89 am 16 Dezember 2020, 08:22:18
Schau mal was du in Device WEB (oder dem entsprechenden Web-Frontend) im Attribut longpoll hast. Teste mal 1 oder websocket ..
longpoll hatte den Wert 0. Der Versuch es auf 1 zu stellen, macht eigentlich keinen Sinn. Der Wert websocket im Grunde ebenso, hat aber, getestet, keine Verbesserungswirkung.
Die Zeit habe ich nochmal gestoppt: 50s. Mit dem Chrome und dem Edge ist es genauso.
Verstehe, ein refresh ist in der Software keiner drin. Dann ist das ist ja echt eine harte Nuss.
Wenn jemand noch eine Idee hat, was ich prüfen könnte...
Die Frage ob es lohnt hier lange zu analysieren. Die Profile erstellt man einmalig und dann ändert man ggf. mal einen Wert. Workaround immer wieder speichern.
Du kannst mal in der Entwicklerkonsole schauen ob du da irgend welche Daten siehst die gesendet oder empfangen werden. Konsole in Chrome <F12> Taste, wenn alle 50 Sekunden der Refresh gemacht wird siehst du das ggf. da.
Hast du das auch auf dem Handy, anderen PC? Addon installiert wie Autorefresh oder sowas?
Zitat von: Beta-User am 16 Dezember 2020, 12:34:02
An der Stelle ein großes Danke an Risiko für's Einbauen der Unterstützung von MQTT2_DEVICE als neuen Client für weekprofile!
Hallo Beta-User,
danke für die tolle Zuarbeit. Musste ja nicht viel machen.
Macht es Sinn, jetzt bereits was dazu im wiki zu schreiben?
Vielleicht hole ich mir ja auch mal so ein Teil. :)
Zitat von: kadettilac89 am 16 Dezember 2020, 19:18:50
Die Profile erstellt man einmalig und dann ändert man ggf. mal einen Wert. Workaround immer wieder speichern.
Eine Katastrophe ist nicht. Wie es halt so ist, nach Wochen kommt eine Anpassung, man denkt nicht dran und ist gefrustet...
Zitat von: kadettilac89 am 16 Dezember 2020, 19:18:50
Du kannst mal in der Entwicklerkonsole schauen
Gute Idee. In der JS-Konsole sieht man den Refresh (refresh.log)
Auch im Wireshark ist es gut verfolgbar (2020-12-16 23_02_51-_WLAN.png) alle 44s.
Mir fällt auf, dass es POSTs sind. Bei einem manuellen Refresh mit F5 ist es ein GET und die Seite zeigt wieder die Zusammenfassung des Weekprofiles und ich verlasse damit den Editmode.
Der Autorefresh (fühlt sich echt wie einer an, ist aber kein solches Addon installiert)
Zitat von: kadettilac89 am 16 Dezember 2020, 19:18:50
Hast du das auch auf dem Handy, anderen PC? Addon installiert wie Autorefresh oder sowas?
Ja, tritt auch auf dem Android Handy auf (Chrome).
Zitat von: Risiko am 16 Dezember 2020, 20:24:31
Vielleicht hole ich mir ja auch mal so ein Teil. :)
Eine Hardware-Empfehlung kann ich dazu nicht wirklich aussprechen, die firmware scheint irgendwie noch nicht ausgereift zu sein, und der Code auf der FHEM-Seite, was Profile betrifft, ist es möglicherweise auch noch nicht...
Und ob die Funktionsweise der Profile (auf den Thermostaten) an sich schon klar ist, da bin ich mir auch noch nicht wirklich sicher ;D .
(Falls es jemanden interessiert, es geht um diese Thermostate: https://www.zigbee2mqtt.io/devices/TS0601_thermostat.html, eingebunden via zigbee2mqtt/MQTT2_DEVICE, Thread dazu: https://forum.fhem.de/index.php/topic,116535.0.html.
Tendenziell halte ich das Profilkonzept 5+2/6+1/7 (bzw. das, was ich meine, was es bedeuten soll) für etwas beschränkt, aber der Markt für Thermostate, die eigenständig nach Profil fahren können, ist andererseits eben auch ziemlich beschränkt.
Die neueren Fibaro "knobs" können das (ZWave), und (afaik) das eqiva-BTLE-Modell. Beides aber noch "nicht wirklich" von FHEM unterstützt (bei ZWave gibt es die Option, Wochenprofile zu versenden, aber effektiv scheint das kaum einer zu nutzen und das Format scheint "komisch" zu sein).
Tendenziell wäre es aber m.E. wünschenswert, zumindest auch noch die Interaktion mit ZWave hinzubekommen (für die Hardware, die die Class CLIMATE_CONTROL_SCHEDULE kennt). Da muss man aber vorher einen Referenzwert ermitteln und dann einzelne Tage rausschicken. Sollte aber an sich auch nicht das Hexenwerk sein, das in weekprofile direkt zu integrieren; bin mal gespannt, wann sich der erste findet, der passende Hardware+Interesse mitbringt...
Eine Sache ist mir jetzt allerdings aufgefallen:
Zumindest das ZigBee-Thermostat "denkt" scheinbar nicht in Tagesabläufen (also "von bis"), sondern nur in Schaltzeitpunkten, es gilt eben auch über Nacht/00:00 Uhr hinaus das, was am Vorabend zuletzt gültig war. Vermutlich kann man auch einen 00:00-Uhr-Schaltzeitpunkt setzen, aber man "verbrät" damit dann eben speichertechnisch gesehen auch einen Datenpunkt. Das ist dann nicht optimal, wenn nur eine gewisse Zahl von Schaltzeitpunkten übermittelt/gespeichert werden können.
Eventuell wäre es für manche Implementierungen hilfreich, die JSON-Daten hierzu passend aufbereitet (und ohne "ab 00:00 Uhr") abfragen zu können, denn diese Transformation ist etwas tricky und wäre ggf. im Detail auch noch zu diskutieren...
Etwas OT @all: Es gibt für ebus@MQTT2_DEVICE eine m.E. nicht ganz optimale Lösung, was on/off-Profile angeht (k.A., was das eigentliche Zielgerät angeht, das ganze wird über
eBus_Calormatic_TimeProgramm konfiguriert, und am Ende wir eigentlich nur für jeden Wochentag eine Anweisung wie diese abgesetzt: "set ebusMQTT publish ebusd/BASE_DEV/hcTimer.Wednesday/set 07:00;;10:00;;12:00;;16:30;;18:00;;22:00;;Mo-Fr").
Also falls da jemand noch der Überzeugung ist, dass das mit weekprofile einfacher zu verwalten ginge: einfach im ebus-attrTemplate-Thread einen Link zu einem neuen Thread in MQTT aufmachen, dann entwickeln wir da was ;) .
Zitat von: Risiko am 16 Dezember 2020, 20:24:31
Macht es Sinn, jetzt bereits was dazu im wiki zu schreiben?
Bin grade erst mal noch dabei, jemanden zu coachen, der dann den WDT-Teil bzw. auch das mit der Topic-Benutzung etwas im Wiki ausbaut.
Für das, was jetzt für den Thermostaten im svn ist, fehlt noch eine commandref, und wenn die dann steht und die Tests von den beiden, die diesen Thermostaten haben passen, dann kommt es in den "MQTT-workshop", erst danach wäre dann ein (vermutlich separater) Artikel im Wiki sinnvoll, auf den man dann von allen Seiten her verlinken würde? Oder wie siehst du das?
Hallo Risiko,
dank der Arbeit von Beta-User lässt sich ja nun über WDT auch weekprofile für meine Z-Wave Thermostate nutzen. Beta-User hat nun in einer Testversion WDT_eventMap eingeführt, so dass man auch andere Werte statt Temperaturen an die Thermostate senden kann. Also z.B. "eco", "comfort" oder bei den Z-Wave Thermostaten von Eurotronic "tmHeating" und "tmEnergySaveHeating".
Ich würde das gerne nutzen in Kombination mit weekprofile und dem widget. Soweit ich es versucht und verstanden habe, kann ich per json auch nicht numerische Werte z.B. "eco" in einem weekprofile anstelle einer Temperatur eintragen. Das wird dann sogar sauber im FHEMWEB Widget angezeigt.
Wäre es denn möglich, anstelle der Dropdowns mit den Temperaturen auch eine vordefinierte Auswahl an Texten anzuzeigen und auszuwählen? Vielleicht gesteuert über ein Attribut zum Wechseln zwischen Temperaturen und "individuellen" Werten, wobei diese ja vielleicht über ein weiteres Attribut kommasepariert definiert werden können.
Bin auf Deine Antwort gespannt...
Beste Grüße
Torsten
Ähm, nur zur Klarstellung: Anlass für das mapping in WDT (siehe diesen Beitrag (https://forum.fhem.de/index.php/topic,111401.msg1113061.html#msg1113061)/Thread) war eher die Überlegung, dass weekprofile typischerweise Temperaturen liefert, es aber manche Hardware gerne "anders "hätte. Man kann also mit der Testversion mAn. sehr gut einfach auf der weekpofile-Seite bei Temperaturen bleiben und "übersetzt" das dann im WDT über das Mapping in "andere" Anweisungen, so dass die Profile in weekprofile gerade reine Temperaturlisten bleiben können ;) .
Davon abgesehen kann ich mir vorstellen, dass es einen gewissen Bedarf an weiteren "keywords" neben "on" und "off" gibt, aber das hat auch nur am Rande was mit WDT zu tun...
(OT: Hier gabe es User, die das logging von weekprofile gerne anders hätten: Max & Weekprofile Log-Einträge (https://forum.fhem.de/index.php/topic,116031.0.html)).
Zitat von: Beta-User am 22 Dezember 2020, 12:06:19
(OT: Hier gabe es User, die das logging von weekprofile gerne anders hätten: Max & Weekprofile Log-Einträge (https://forum.fhem.de/index.php/topic,116031.0.html)).
Danke. Erledigt.
Zitat von: ToKa am 22 Dezember 2020, 11:55:37
Bin auf Deine Antwort gespannt...
Vorstellbar wäre es schon. Sehe es persönlich aber aktuell nicht für sinnvoll (Aufwand vs. Nutzen) und weil unterschiedliche Geräte mit unterschiedlichen Temperaturbezeichnungen arbeiten und es keinen "Standard" gibt ("tmHeating" und "tmEnergySaveHeating" zeigen das gleich auf).
Aktuell wird sogar explizit 'on' bzw 'off' durch eine entsprechende Temperatur ersetzt (siehe Attribut tempOn, tempOff).
Wegen der Geräteabhängigkeit siehe ich das Mapping (so wie auch Beta-User) eher beim Gerät als bei weekprofile.
Wenn es mehr Leute mit so einem Wünsch gibt\gäbe, würde ich ggf. nochmal darüber nachdenken (daher vorstellbar ;))
Risiko
Hmm, viele unterschiedliche Gerätetypen mit "keywords" unterstützen zu wollen, sehe ich im Moment auch nicht als zielführend an, zumal man das dann wohl nicht als "Profil" an das eigentliche Endgerät senden kann.
ABER: es gibt bzgl. diverser Modi schon eine Art Standard - nämlich das, was bei Sprachsteuerung "typischerweise" gemappt wird. Da scheint sowas wie COOL, HEAT, usw. üblich zu sein (ca. etwas mehr wie eine Handvoll einschl. ON und OFF). Wenn man diese "keywords" unterstützen könnte, wäre "wenigstens" das Profil sprechend - allerdings müsste man sich dann einen würgaround finden für die Geräte, die dann "Direktadressaten" wären (CUL_HM etc.)...
Na ja, eine 100% passende Lösung für die Gesamtproblematik gibt es nun mal leider eher nicht; bei Interesse suche ich aber gerne den Link für die keywords.
Hallo Ihr Beiden,
entweder ich habe mich falsch ausgedrückt oder Ihr denkt an eine eierlegende Wollmichsau ;D
Um es noch einmal verständlicher zu machen. Es geht mir gar nicht darum, dass weekprofile ein Mapping macht, sondern nur darum, anstelle der Temperaturen "im widget" auch alpha-Werte benutzen zu können. Hierzu war mein Vorschlag gedacht, ein Attribut in weekprofile einzuführen, das es erlaubt individuelle Werte zu benutzen. Wenn 0, dann Verhalten wie bisher, wenn 1, dann benutze die Werte aus dem zweiten Attribut z.B.: "on", "off" oder "eco", "comfort" und diese werden dann an das verknüpfte Gerät gesendet (was aktuell wahrscheinlich nur für WDT Sinn macht, aber das bleibt ja dem Anwender überlassen).
Beispiel:
- weekprofile mit dem Attribut für indiv. Werte = 1 und Atribut indiv. Werte = eco, comfort ==> im widget kann ich zwischen eco und comfort für die einzelnen Schaltzeiten wählen und dies wird entsprechend gespeichert
- weekprofile verknüpft mit WDT ==> weekprofile überträgt an den WDT die Schaltzeiten mit eco oder comfort
- WDT mapt über WDT_eventMap eco ==> tmEnergySaveHeating und comfort ==> tm Heating und sendet dies dann an mein Z-Wave Thermostat
Das ganze funktioniert jetzt schon, wenn ich weekprofile per json z.B. mit eco befülle. Schöner wäre es eben über das widget.
Beste Grüße
Torsten
Hallo Torsten,
ich habe dich denke ich schon richtig verstanden.
Den Nutzen gegenüber dem Implementierungsaufwand sehe ich aktuell überhaupt nicht. Sondern eher Probleme - gerade in Verbindung mit Topics, wo man ja allgemein Profile verwaltet und an
unterschiedliche Geräte unterschiedlicher Hersteller senden kann. Jedes Gerät interpretiert die "alpha-Werte" anders oder kennt sie nicht.
Zitat von: ToKa am 23 Dezember 2020, 10:36:31
und diese werden dann an das verknüpfte Gerät gesendet (was aktuell wahrscheinlich nur für WDT Sinn macht, aber das bleibt ja dem Anwender überlassen).
Ich glaube du überblickst die Komplexität nicht und siehst nur deinen Anwendungsfall (Stichwort Nutzen). Klingt für mich wie eine 1:1 Zuordnung und nur ein Hersteller.
Zitat von: ToKa am 23 Dezember 2020, 10:36:31
Das ganze funktioniert jetzt schon, wenn ich weekprofile per json z.B. mit eco befülle. Schöner wäre es eben über das widget.
Das ist bis jetzt nicht gewollt und funktioniert eben nicht richtig im Zusammenhang mit der Anzeige und ggf. anderen Sachen. Also keine Garantie!
Wenn sich wie gesagt mehrere Leute dafür interessieren, sich Tester und ggf. Mitentwickler finden, wäre ich ggf. bereit über eine mögliche Umsetzung nachzudenken.
Trotzdem Danke für deine Mühe.
Danke, dass Du Dir die Mühe machst, Dich damit zu beschäftigen.
Ich habe mir tempOn und tempOff mal angeschaut und das ist ja schon fast, das was ich mir vorstelle. Da Du ja für die "json"-Variante Deine Hand nicht ins Feuer legst, zur Sicherheit noch die Frage zur Funktionsweise mit tempOn / tempOff.
Wenn ich das Intervall auf mit tempOn / tempOff auf 18 - 18.5 einschränke, zeigt mir das Widget nur noch off und on zur Auswahl an. Dies wird auch gespeichert und an meinen WDT übertragen. Dort kann ich dann das mapping machen. Oder gibt es hierbei auch Funktionseinschränkungen?
Beste Grüße
Torsten
Hallo Torsten,
ja so ist es (leider) im Moment. tempOn sollte aber größer als tempOFF sein. Sollte auch eine Warnung im Log geben.
Da WDT (und MQTT2_DEVICE) das Profil holt und nicht weekprofile das Profil sendet, bekommt WDT die Keywords 'on/off zu "sehen".
Beim Senden eines Profils, wird on/off durch die Werte der Attribute ersetzt.
Ist leider aktuell inkonsistent und zwingt mich wohl doch jetzt nochmal darüber nachzudenken ???
Ich werde mit Beta-User Rücksprache halten, ob weekprofile aktuell immer nur Temperaturen liefern sollte! Wäre meines Erachtens richtiger.
Risiko.
Hallo Risiko,
ich habe aus einem weekprofile Device heraus mit "set send_to_device" mein WDT Device (Testversion von Beta-User) mit den Werte versorgt. Und im WDT steht nun on und off... oder habe ich da mit dem "holen" etwas falsch verstanden? Das Ergebnis bleibt das gleiche, wenn ich vom WDT aus ein "set weekprofile" aufrufe. Die Daten werden aktualisiert und on / off verwendet.
Einen kleinen "Schönheitsfehler" gibt es beim Ändern der Daten im weekprpfile widget. Dort wird immer Off angezeigt auch wenn vorher On eingestellt war und beim Speichern dann auch mit Off überschrieben. TempOff 18.0 / TempOn 18.5.
Beste Grüße
Torsten
Guten Morgen,
wie im Anfänger- bzw. Homematic-Forum schonmal angesprochen (https://forum.fhem.de/index.php/topic,115155.0.html) versuche ich einen HmIP eTRV-2 Heizkörperthermostat mit weekprofile zu verkuppeln. Bis jetzt bekomme ich aber nur die Daten ausgelesen. Hat das schon jemand im Einsatz oder kann mir sonst jemand weiterhelfen? Ich habe piVCCU auf einem Raspi mit HM-MOD-RPI-PCB laufen.
Erstmal die lists:
- Device:
Internals:
DEF 000A18A996XXXX
FUUID 5f7876c1-f33f-6319-a7ab-xxxxxxxx
IODev d_ccu
NAME HmIP_eTRV_2_000A18A996XXXX
NR 405
STATE 17.0
TYPE HMCCUDEV
ccuaddr 000A18A996XXXX
ccudevstate active
ccuif HmIP-RF
ccuname Heizung WC
ccutype HmIP-eTRV-2
channels 8
firmware 2.2.8
statevals devstate
Helper:
DBLOG:
1.ACTUAL_TEMPERATURE:
logdb:
TIME 1603260207.87943
VALUE 22.2
1.BOOST_MODE:
logdb:
TIME 1603260207.87943
VALUE 0
1.SET_POINT_TEMPERATURE:
logdb:
TIME 1603260207.87943
VALUE 17.0
valve_position:
logdb:
TIME 1603260207.87943
VALUE 0
READINGS:
2020-10-17 19:13:09 0.CONFIG_PENDING 0
2020-10-17 18:41:46 0.DUTY_CYCLE 0
2020-10-16 10:57:30 0.INSTALL_TEST true
2020-10-21 08:03:27 0.LOW_BAT 0
2020-10-17 18:41:46 0.OPERATING_VOLTAGE 3.0
2020-10-17 18:41:46 0.OPERATING_VOLTAGE_STATUS 0
2020-10-17 18:41:46 0.RSSI_DEVICE -44
2020-10-16 10:57:30 0.RSSI_PEER 202
2020-10-17 18:41:46 0.UNREACH 0
2020-10-16 10:57:30 0.UPDATE_PENDING false
2020-10-17 18:41:46 1.ACTIVE_PROFILE 1
2020-10-21 08:03:27 1.ACTUAL_TEMPERATURE 22.2
2020-10-21 08:03:27 1.ACTUAL_TEMPERATURE_STATUS 0
2020-10-21 08:03:27 1.BOOST_MODE 0
2020-10-17 18:41:46 1.BOOST_TIME 0
2020-10-17 18:41:46 1.FROST_PROTECTION 0
2020-10-17 18:41:46 1.PARTY_MODE 0
2020-10-16 10:57:30 1.PARTY_SET_POINT_TEMPERATURE 0.0
2020-10-16 10:57:30 1.PARTY_TIME_END
2020-10-16 10:57:30 1.PARTY_TIME_START
2020-10-17 18:41:46 1.QUICK_VETO_TIME 0
2020-10-21 08:03:27 1.SET_POINT_MODE 0
2020-10-21 08:03:27 1.SET_POINT_TEMPERATURE 17.0
2020-10-17 18:41:46 1.SWITCH_POINT_OCCURED 0
2020-10-16 10:57:30 1.VALVE_ADAPTION false
2020-10-17 18:41:46 1.VALVE_STATE 4
2020-10-21 08:03:27 1.WINDOW_STATE closed
2020-10-16 13:37:12 R-1.ADAPTIVE_REGULATION 2
2020-10-16 13:37:12 R-1.BOOST_AFTER_WINDOW_OPEN 0
2020-10-16 13:37:12 R-1.BOOST_POSITION 80
2020-10-16 13:37:12 R-1.BOOST_TIME_PERIOD 5
2020-10-16 13:37:12 R-1.BUTTON_RESPONSE_WITHOUT_BACKLIGHT 0
2020-10-16 13:37:12 R-1.CHANNEL_OPERATION_MODE 0
2020-10-16 13:37:12 R-1.DECALCIFICATION_TIME 22
2020-10-16 13:37:12 R-1.DECALCIFICATION_WEEKDAY 6
2020-10-16 13:37:12 R-1.DURATION_5MIN 0
2020-10-16 13:37:12 R-1.MANU_MODE_PRIORITIZATION 1
2020-10-16 13:37:12 R-1.MIN_MAX_VALUE_NOT_RELEVANT_FOR_MANU_MODE 0
2020-10-16 13:37:12 R-1.OPTIMUM_START_STOP 0
2020-10-16 13:37:12 R-1.P1_ENDTIME_FRIDAY_1 360
2020-10-16 13:37:12 R-1.P1_ENDTIME_FRIDAY_10 1440
2020-10-16 13:37:12 R-1.P1_ENDTIME_FRIDAY_11 1440
2020-10-16 13:37:12 R-1.P1_ENDTIME_FRIDAY_12 1440
2020-10-16 13:37:12 R-1.P1_ENDTIME_FRIDAY_13 1440
2020-10-16 13:37:12 R-1.P1_ENDTIME_FRIDAY_2 480
2020-10-16 13:37:12 R-1.P1_ENDTIME_FRIDAY_3 1020
2020-10-16 13:37:12 R-1.P1_ENDTIME_FRIDAY_4 1200
2020-10-16 13:37:12 R-1.P1_ENDTIME_FRIDAY_5 1440
2020-10-16 13:37:12 R-1.P1_ENDTIME_FRIDAY_6 1440
2020-10-16 13:37:12 R-1.P1_ENDTIME_FRIDAY_7 1440
2020-10-16 13:37:12 R-1.P1_ENDTIME_FRIDAY_8 1440
2020-10-16 13:37:12 R-1.P1_ENDTIME_FRIDAY_9 1440
2020-10-16 13:37:12 R-1.P1_ENDTIME_MONDAY_1 360
2020-10-16 13:37:12 R-1.P1_ENDTIME_MONDAY_10 1440
2020-10-16 13:37:12 R-1.P1_ENDTIME_MONDAY_11 1440
2020-10-16 13:37:12 R-1.P1_ENDTIME_MONDAY_12 1440
2020-10-16 13:37:12 R-1.P1_ENDTIME_MONDAY_13 1440
2020-10-16 13:37:12 R-1.P1_ENDTIME_MONDAY_2 480
2020-10-16 13:37:12 R-1.P1_ENDTIME_MONDAY_3 1020
2020-10-16 13:37:12 R-1.P1_ENDTIME_MONDAY_4 1200
2020-10-16 13:37:12 R-1.P1_ENDTIME_MONDAY_5 1440
2020-10-16 13:37:12 R-1.P1_ENDTIME_MONDAY_6 1440
2020-10-16 13:37:12 R-1.P1_ENDTIME_MONDAY_7 1440
2020-10-16 13:37:12 R-1.P1_ENDTIME_MONDAY_8 1440
2020-10-16 13:37:12 R-1.P1_ENDTIME_MONDAY_9 1440
2020-10-16 13:37:12 R-1.P1_ENDTIME_SATURDAY_1 540
2020-10-16 13:37:12 R-1.P1_ENDTIME_SATURDAY_10 1440
2020-10-16 13:37:12 R-1.P1_ENDTIME_SATURDAY_11 1440
2020-10-16 13:37:12 R-1.P1_ENDTIME_SATURDAY_12 1440
2020-10-16 13:37:12 R-1.P1_ENDTIME_SATURDAY_13 1440
2020-10-16 13:37:12 R-1.P1_ENDTIME_SATURDAY_2 1200
2020-10-16 13:37:12 R-1.P1_ENDTIME_SATURDAY_3 1440
2020-10-16 13:37:12 R-1.P1_ENDTIME_SATURDAY_4 1440
2020-10-16 13:37:12 R-1.P1_ENDTIME_SATURDAY_5 1440
2020-10-16 13:37:12 R-1.P1_ENDTIME_SATURDAY_6 1440
2020-10-16 13:37:12 R-1.P1_ENDTIME_SATURDAY_7 1440
2020-10-16 13:37:12 R-1.P1_ENDTIME_SATURDAY_8 1440
2020-10-16 13:37:12 R-1.P1_ENDTIME_SATURDAY_9 1440
2020-10-16 13:37:12 R-1.P1_ENDTIME_SUNDAY_1 540
2020-10-16 13:37:12 R-1.P1_ENDTIME_SUNDAY_10 1440
2020-10-16 13:37:12 R-1.P1_ENDTIME_SUNDAY_11 1440
2020-10-16 13:37:12 R-1.P1_ENDTIME_SUNDAY_12 1440
2020-10-16 13:37:12 R-1.P1_ENDTIME_SUNDAY_13 1440
2020-10-16 13:37:12 R-1.P1_ENDTIME_SUNDAY_2 1200
2020-10-16 13:37:12 R-1.P1_ENDTIME_SUNDAY_3 1440
2020-10-16 13:37:12 R-1.P1_ENDTIME_SUNDAY_4 1440
2020-10-16 13:37:12 R-1.P1_ENDTIME_SUNDAY_5 1440
2020-10-16 13:37:12 R-1.P1_ENDTIME_SUNDAY_6 1440
2020-10-16 13:37:12 R-1.P1_ENDTIME_SUNDAY_7 1440
2020-10-16 13:37:12 R-1.P1_ENDTIME_SUNDAY_8 1440
2020-10-16 13:37:12 R-1.P1_ENDTIME_SUNDAY_9 1440
2020-10-16 13:37:12 R-1.P1_ENDTIME_THURSDAY_1 360
2020-10-16 13:37:12 R-1.P1_ENDTIME_THURSDAY_10 1440
2020-10-16 13:37:12 R-1.P1_ENDTIME_THURSDAY_11 1440
2020-10-16 13:37:12 R-1.P1_ENDTIME_THURSDAY_12 1440
2020-10-16 13:37:12 R-1.P1_ENDTIME_THURSDAY_13 1440
2020-10-16 13:37:12 R-1.P1_ENDTIME_THURSDAY_2 480
2020-10-16 13:37:12 R-1.P1_ENDTIME_THURSDAY_3 1020
2020-10-16 13:37:12 R-1.P1_ENDTIME_THURSDAY_4 1200
2020-10-16 13:37:12 R-1.P1_ENDTIME_THURSDAY_5 1440
2020-10-16 13:37:12 R-1.P1_ENDTIME_THURSDAY_6 1440
2020-10-16 13:37:12 R-1.P1_ENDTIME_THURSDAY_7 1440
2020-10-16 13:37:12 R-1.P1_ENDTIME_THURSDAY_8 1440
2020-10-16 13:37:12 R-1.P1_ENDTIME_THURSDAY_9 1440
2020-10-16 13:37:12 R-1.P1_ENDTIME_TUESDAY_1 360
2020-10-16 13:37:12 R-1.P1_ENDTIME_TUESDAY_10 1440
2020-10-16 13:37:12 R-1.P1_ENDTIME_TUESDAY_11 1440
2020-10-16 13:37:12 R-1.P1_ENDTIME_TUESDAY_12 1440
2020-10-16 13:37:12 R-1.P1_ENDTIME_TUESDAY_13 1440
2020-10-16 13:37:12 R-1.P1_ENDTIME_TUESDAY_2 480
2020-10-16 13:37:12 R-1.P1_ENDTIME_TUESDAY_3 1020
2020-10-16 13:37:12 R-1.P1_ENDTIME_TUESDAY_4 1200
2020-10-16 13:37:12 R-1.P1_ENDTIME_TUESDAY_5 1440
2020-10-16 13:37:12 R-1.P1_ENDTIME_TUESDAY_6 1440
2020-10-16 13:37:12 R-1.P1_ENDTIME_TUESDAY_7 1440
2020-10-16 13:37:12 R-1.P1_ENDTIME_TUESDAY_8 1440
2020-10-16 13:37:12 R-1.P1_ENDTIME_TUESDAY_9 1440
2020-10-16 13:37:12 R-1.P1_ENDTIME_WEDNESDAY_1 360
2020-10-16 13:37:12 R-1.P1_ENDTIME_WEDNESDAY_10 1440
2020-10-16 13:37:12 R-1.P1_ENDTIME_WEDNESDAY_11 1440
2020-10-16 13:37:12 R-1.P1_ENDTIME_WEDNESDAY_12 1440
2020-10-16 13:37:12 R-1.P1_ENDTIME_WEDNESDAY_13 1440
2020-10-16 13:37:12 R-1.P1_ENDTIME_WEDNESDAY_2 480
2020-10-16 13:37:12 R-1.P1_ENDTIME_WEDNESDAY_3 1020
2020-10-16 13:37:12 R-1.P1_ENDTIME_WEDNESDAY_4 1200
2020-10-16 13:37:12 R-1.P1_ENDTIME_WEDNESDAY_5 1440
2020-10-16 13:37:12 R-1.P1_ENDTIME_WEDNESDAY_6 1440
2020-10-16 13:37:12 R-1.P1_ENDTIME_WEDNESDAY_7 1440
2020-10-16 13:37:12 R-1.P1_ENDTIME_WEDNESDAY_8 1440
2020-10-16 13:37:12 R-1.P1_ENDTIME_WEDNESDAY_9 1440
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_FRIDAY_1 17.0
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_FRIDAY_10 17.0
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_FRIDAY_11 17.0
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_FRIDAY_12 17.0
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_FRIDAY_13 17.0
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_FRIDAY_2 21.0
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_FRIDAY_3 17.0
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_FRIDAY_4 21.0
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_FRIDAY_5 17.0
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_FRIDAY_6 17.0
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_FRIDAY_7 17.0
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_FRIDAY_8 17.0
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_FRIDAY_9 17.0
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_MONDAY_1 17.0
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_MONDAY_10 17.0
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_MONDAY_11 17.0
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_MONDAY_12 17.0
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_MONDAY_13 17.0
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_MONDAY_2 21.0
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_MONDAY_3 17.0
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_MONDAY_4 21.0
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_MONDAY_5 17.0
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_MONDAY_6 17.0
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_MONDAY_7 17.0
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_MONDAY_8 17.0
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_MONDAY_9 17.0
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_SATURDAY_1 17.0
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_SATURDAY_10 17.0
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_SATURDAY_11 17.0
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_SATURDAY_12 17.0
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_SATURDAY_13 17.0
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_SATURDAY_2 21.0
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_SATURDAY_3 17.0
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_SATURDAY_4 17.0
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_SATURDAY_5 17.0
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_SATURDAY_6 17.0
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_SATURDAY_7 17.0
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_SATURDAY_8 17.0
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_SATURDAY_9 17.0
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_SUNDAY_1 17.0
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_SUNDAY_10 17.0
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_SUNDAY_11 17.0
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_SUNDAY_12 17.0
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_SUNDAY_13 17.0
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_SUNDAY_2 21.0
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_SUNDAY_3 17.0
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_SUNDAY_4 17.0
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_SUNDAY_5 17.0
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_SUNDAY_6 17.0
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_SUNDAY_7 17.0
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_SUNDAY_8 17.0
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_SUNDAY_9 17.0
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_THURSDAY_1 17.0
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_THURSDAY_10 17.0
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_THURSDAY_11 17.0
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_THURSDAY_12 17.0
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_THURSDAY_13 17.0
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_THURSDAY_2 21.0
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_THURSDAY_3 17.0
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_THURSDAY_4 21.0
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_THURSDAY_5 17.0
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_THURSDAY_6 17.0
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_THURSDAY_7 17.0
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_THURSDAY_8 17.0
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_THURSDAY_9 17.0
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_TUESDAY_1 17.0
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_TUESDAY_10 17.0
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_TUESDAY_11 17.0
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_TUESDAY_12 17.0
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_TUESDAY_13 17.0
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_TUESDAY_2 21.0
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_TUESDAY_3 17.0
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_TUESDAY_4 21.0
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_TUESDAY_5 17.0
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_TUESDAY_6 17.0
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_TUESDAY_7 17.0
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_TUESDAY_8 17.0
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_TUESDAY_9 17.0
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_WEDNESDAY_1 17.0
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_WEDNESDAY_10 17.0
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_WEDNESDAY_11 17.0
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_WEDNESDAY_12 17.0
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_WEDNESDAY_13 17.0
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_WEDNESDAY_2 21.0
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_WEDNESDAY_3 17.0
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_WEDNESDAY_4 21.0
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_WEDNESDAY_5 17.0
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_WEDNESDAY_6 17.0
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_WEDNESDAY_7 17.0
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_WEDNESDAY_8 17.0
2020-10-16 13:37:12 R-1.P1_TEMPERATURE_WEDNESDAY_9 17.0
2020-10-16 13:37:12 R-1.P2_ENDTIME_FRIDAY_1 360
2020-10-16 13:37:12 R-1.P2_ENDTIME_FRIDAY_10 1440
2020-10-16 13:37:12 R-1.P2_ENDTIME_FRIDAY_11 1440
2020-10-16 13:37:12 R-1.P2_ENDTIME_FRIDAY_12 1440
2020-10-16 13:37:12 R-1.P2_ENDTIME_FRIDAY_13 1440
2020-10-16 13:37:12 R-1.P2_ENDTIME_FRIDAY_2 1320
2020-10-16 13:37:12 R-1.P2_ENDTIME_FRIDAY_3 1440
2020-10-16 13:37:12 R-1.P2_ENDTIME_FRIDAY_4 1440
2020-10-16 13:37:12 R-1.P2_ENDTIME_FRIDAY_5 1440
2020-10-16 13:37:12 R-1.P2_ENDTIME_FRIDAY_6 1440
2020-10-16 13:37:12 R-1.P2_ENDTIME_FRIDAY_7 1440
2020-10-16 13:37:12 R-1.P2_ENDTIME_FRIDAY_8 1440
2020-10-16 13:37:12 R-1.P2_ENDTIME_FRIDAY_9 1440
2020-10-16 13:37:12 R-1.P2_ENDTIME_MONDAY_1 360
2020-10-16 13:37:12 R-1.P2_ENDTIME_MONDAY_10 1440
2020-10-16 13:37:12 R-1.P2_ENDTIME_MONDAY_11 1440
2020-10-16 13:37:12 R-1.P2_ENDTIME_MONDAY_12 1440
2020-10-16 13:37:12 R-1.P2_ENDTIME_MONDAY_13 1440
2020-10-16 13:37:12 R-1.P2_ENDTIME_MONDAY_2 1320
2020-10-16 13:37:12 R-1.P2_ENDTIME_MONDAY_3 1440
2020-10-16 13:37:12 R-1.P2_ENDTIME_MONDAY_4 1440
2020-10-16 13:37:12 R-1.P2_ENDTIME_MONDAY_5 1440
2020-10-16 13:37:12 R-1.P2_ENDTIME_MONDAY_6 1440
2020-10-16 13:37:12 R-1.P2_ENDTIME_MONDAY_7 1440
2020-10-16 13:37:12 R-1.P2_ENDTIME_MONDAY_8 1440
2020-10-16 13:37:12 R-1.P2_ENDTIME_MONDAY_9 1440
2020-10-16 13:37:12 R-1.P2_ENDTIME_SATURDAY_1 360
2020-10-16 13:37:12 R-1.P2_ENDTIME_SATURDAY_10 1440
2020-10-16 13:37:12 R-1.P2_ENDTIME_SATURDAY_11 1440
2020-10-16 13:37:12 R-1.P2_ENDTIME_SATURDAY_12 1440
2020-10-16 13:37:12 R-1.P2_ENDTIME_SATURDAY_13 1440
2020-10-16 13:37:12 R-1.P2_ENDTIME_SATURDAY_2 1320
2020-10-16 13:37:12 R-1.P2_ENDTIME_SATURDAY_3 1440
2020-10-16 13:37:12 R-1.P2_ENDTIME_SATURDAY_4 1440
2020-10-16 13:37:12 R-1.P2_ENDTIME_SATURDAY_5 1440
2020-10-16 13:37:12 R-1.P2_ENDTIME_SATURDAY_6 1440
2020-10-16 13:37:12 R-1.P2_ENDTIME_SATURDAY_7 1440
2020-10-16 13:37:12 R-1.P2_ENDTIME_SATURDAY_8 1440
2020-10-16 13:37:12 R-1.P2_ENDTIME_SATURDAY_9 1440
2020-10-16 13:37:12 R-1.P2_ENDTIME_SUNDAY_1 360
2020-10-16 13:37:12 R-1.P2_ENDTIME_SUNDAY_10 1440
2020-10-16 13:37:12 R-1.P2_ENDTIME_SUNDAY_11 1440
2020-10-16 13:37:12 R-1.P2_ENDTIME_SUNDAY_12 1440
2020-10-16 13:37:12 R-1.P2_ENDTIME_SUNDAY_13 1440
2020-10-16 13:37:12 R-1.P2_ENDTIME_SUNDAY_2 1320
2020-10-16 13:37:12 R-1.P2_ENDTIME_SUNDAY_3 1440
2020-10-16 13:37:12 R-1.P2_ENDTIME_SUNDAY_4 1440
2020-10-16 13:37:12 R-1.P2_ENDTIME_SUNDAY_5 1440
2020-10-16 13:37:12 R-1.P2_ENDTIME_SUNDAY_6 1440
2020-10-16 13:37:12 R-1.P2_ENDTIME_SUNDAY_7 1440
2020-10-16 13:37:12 R-1.P2_ENDTIME_SUNDAY_8 1440
2020-10-16 13:37:12 R-1.P2_ENDTIME_SUNDAY_9 1440
2020-10-16 13:37:12 R-1.P2_ENDTIME_THURSDAY_1 360
2020-10-16 13:37:12 R-1.P2_ENDTIME_THURSDAY_10 1440
2020-10-16 13:37:12 R-1.P2_ENDTIME_THURSDAY_11 1440
2020-10-16 13:37:12 R-1.P2_ENDTIME_THURSDAY_12 1440
2020-10-16 13:37:12 R-1.P2_ENDTIME_THURSDAY_13 1440
2020-10-16 13:37:12 R-1.P2_ENDTIME_THURSDAY_2 1320
2020-10-16 13:37:12 R-1.P2_ENDTIME_THURSDAY_3 1440
2020-10-16 13:37:12 R-1.P2_ENDTIME_THURSDAY_4 1440
2020-10-16 13:37:12 R-1.P2_ENDTIME_THURSDAY_5 1440
2020-10-16 13:37:12 R-1.P2_ENDTIME_THURSDAY_6 1440
2020-10-16 13:37:12 R-1.P2_ENDTIME_THURSDAY_7 1440
2020-10-16 13:37:12 R-1.P2_ENDTIME_THURSDAY_8 1440
2020-10-16 13:37:12 R-1.P2_ENDTIME_THURSDAY_9 1440
2020-10-16 13:37:12 R-1.P2_ENDTIME_TUESDAY_1 360
2020-10-16 13:37:12 R-1.P2_ENDTIME_TUESDAY_10 1440
2020-10-16 13:37:12 R-1.P2_ENDTIME_TUESDAY_11 1440
2020-10-16 13:37:12 R-1.P2_ENDTIME_TUESDAY_12 1440
2020-10-16 13:37:12 R-1.P2_ENDTIME_TUESDAY_13 1440
2020-10-16 13:37:12 R-1.P2_ENDTIME_TUESDAY_2 1320
2020-10-16 13:37:12 R-1.P2_ENDTIME_TUESDAY_3 1440
2020-10-16 13:37:12 R-1.P2_ENDTIME_TUESDAY_4 1440
2020-10-16 13:37:12 R-1.P2_ENDTIME_TUESDAY_5 1440
2020-10-16 13:37:12 R-1.P2_ENDTIME_TUESDAY_6 1440
2020-10-16 13:37:12 R-1.P2_ENDTIME_TUESDAY_7 1440
2020-10-16 13:37:12 R-1.P2_ENDTIME_TUESDAY_8 1440
2020-10-16 13:37:12 R-1.P2_ENDTIME_TUESDAY_9 1440
2020-10-16 13:37:12 R-1.P2_ENDTIME_WEDNESDAY_1 360
2020-10-16 13:37:12 R-1.P2_ENDTIME_WEDNESDAY_10 1440
2020-10-16 13:37:12 R-1.P2_ENDTIME_WEDNESDAY_11 1440
2020-10-16 13:37:12 R-1.P2_ENDTIME_WEDNESDAY_12 1440
2020-10-16 13:37:12 R-1.P2_ENDTIME_WEDNESDAY_13 1440
2020-10-16 13:37:12 R-1.P2_ENDTIME_WEDNESDAY_2 1320
2020-10-16 13:37:12 R-1.P2_ENDTIME_WEDNESDAY_3 1440
2020-10-16 13:37:12 R-1.P2_ENDTIME_WEDNESDAY_4 1440
2020-10-16 13:37:12 R-1.P2_ENDTIME_WEDNESDAY_5 1440
2020-10-16 13:37:12 R-1.P2_ENDTIME_WEDNESDAY_6 1440
2020-10-16 13:37:12 R-1.P2_ENDTIME_WEDNESDAY_7 1440
2020-10-16 13:37:12 R-1.P2_ENDTIME_WEDNESDAY_8 1440
2020-10-16 13:37:12 R-1.P2_ENDTIME_WEDNESDAY_9 1440
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_FRIDAY_1 17.0
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_FRIDAY_10 17.0
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_FRIDAY_11 17.0
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_FRIDAY_12 17.0
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_FRIDAY_13 17.0
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_FRIDAY_2 21.0
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_FRIDAY_3 17.0
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_FRIDAY_4 17.0
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_FRIDAY_5 17.0
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_FRIDAY_6 17.0
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_FRIDAY_7 17.0
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_FRIDAY_8 17.0
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_FRIDAY_9 17.0
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_MONDAY_1 17.0
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_MONDAY_10 17.0
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_MONDAY_11 17.0
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_MONDAY_12 17.0
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_MONDAY_13 17.0
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_MONDAY_2 21.0
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_MONDAY_3 17.0
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_MONDAY_4 17.0
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_MONDAY_5 17.0
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_MONDAY_6 17.0
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_MONDAY_7 17.0
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_MONDAY_8 17.0
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_MONDAY_9 17.0
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_SATURDAY_1 17.0
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_SATURDAY_10 17.0
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_SATURDAY_11 17.0
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_SATURDAY_12 17.0
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_SATURDAY_13 17.0
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_SATURDAY_2 21.0
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_SATURDAY_3 17.0
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_SATURDAY_4 17.0
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_SATURDAY_5 17.0
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_SATURDAY_6 17.0
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_SATURDAY_7 17.0
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_SATURDAY_8 17.0
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_SATURDAY_9 17.0
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_SUNDAY_1 17.0
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_SUNDAY_10 17.0
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_SUNDAY_11 17.0
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_SUNDAY_12 17.0
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_SUNDAY_13 17.0
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_SUNDAY_2 21.0
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_SUNDAY_3 17.0
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_SUNDAY_4 17.0
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_SUNDAY_5 17.0
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_SUNDAY_6 17.0
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_SUNDAY_7 17.0
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_SUNDAY_8 17.0
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_SUNDAY_9 17.0
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_THURSDAY_1 17.0
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_THURSDAY_10 17.0
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_THURSDAY_11 17.0
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_THURSDAY_12 17.0
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_THURSDAY_13 17.0
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_THURSDAY_2 21.0
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_THURSDAY_3 17.0
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_THURSDAY_4 17.0
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_THURSDAY_5 17.0
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_THURSDAY_6 17.0
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_THURSDAY_7 17.0
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_THURSDAY_8 17.0
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_THURSDAY_9 17.0
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_TUESDAY_1 17.0
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_TUESDAY_10 17.0
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_TUESDAY_11 17.0
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_TUESDAY_12 17.0
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_TUESDAY_13 17.0
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_TUESDAY_2 21.0
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_TUESDAY_3 17.0
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_TUESDAY_4 17.0
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_TUESDAY_5 17.0
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_TUESDAY_6 17.0
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_TUESDAY_7 17.0
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_TUESDAY_8 17.0
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_TUESDAY_9 17.0
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_WEDNESDAY_1 17.0
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_WEDNESDAY_10 17.0
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_WEDNESDAY_11 17.0
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_WEDNESDAY_12 17.0
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_WEDNESDAY_13 17.0
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_WEDNESDAY_2 21.0
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_WEDNESDAY_3 17.0
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_WEDNESDAY_4 17.0
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_WEDNESDAY_5 17.0
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_WEDNESDAY_6 17.0
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_WEDNESDAY_7 17.0
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_WEDNESDAY_8 17.0
2020-10-16 13:37:12 R-1.P2_TEMPERATURE_WEDNESDAY_9 17.0
2020-10-16 13:37:12 R-1.P3_ENDTIME_FRIDAY_1 360
2020-10-16 13:37:12 R-1.P3_ENDTIME_FRIDAY_10 1440
2020-10-16 13:37:12 R-1.P3_ENDTIME_FRIDAY_11 1440
2020-10-16 13:37:12 R-1.P3_ENDTIME_FRIDAY_12 1440
2020-10-16 13:37:12 R-1.P3_ENDTIME_FRIDAY_13 1440
2020-10-16 13:37:12 R-1.P3_ENDTIME_FRIDAY_2 1320
2020-10-16 13:37:12 R-1.P3_ENDTIME_FRIDAY_3 1440
2020-10-16 13:37:12 R-1.P3_ENDTIME_FRIDAY_4 1440
2020-10-16 13:37:12 R-1.P3_ENDTIME_FRIDAY_5 1440
2020-10-16 13:37:12 R-1.P3_ENDTIME_FRIDAY_6 1440
2020-10-16 13:37:12 R-1.P3_ENDTIME_FRIDAY_7 1440
2020-10-16 13:37:12 R-1.P3_ENDTIME_FRIDAY_8 1440
2020-10-16 13:37:12 R-1.P3_ENDTIME_FRIDAY_9 1440
2020-10-16 13:37:12 R-1.P3_ENDTIME_MONDAY_1 360
2020-10-16 13:37:12 R-1.P3_ENDTIME_MONDAY_10 1440
2020-10-16 13:37:12 R-1.P3_ENDTIME_MONDAY_11 1440
2020-10-16 13:37:12 R-1.P3_ENDTIME_MONDAY_12 1440
2020-10-16 13:37:12 R-1.P3_ENDTIME_MONDAY_13 1440
2020-10-16 13:37:12 R-1.P3_ENDTIME_MONDAY_2 1320
2020-10-16 13:37:12 R-1.P3_ENDTIME_MONDAY_3 1440
2020-10-16 13:37:12 R-1.P3_ENDTIME_MONDAY_4 1440
2020-10-16 13:37:12 R-1.P3_ENDTIME_MONDAY_5 1440
2020-10-16 13:37:12 R-1.P3_ENDTIME_MONDAY_6 1440
2020-10-16 13:37:12 R-1.P3_ENDTIME_MONDAY_7 1440
2020-10-16 13:37:12 R-1.P3_ENDTIME_MONDAY_8 1440
2020-10-16 13:37:12 R-1.P3_ENDTIME_MONDAY_9 1440
2020-10-16 13:37:12 R-1.P3_ENDTIME_SATURDAY_1 360
2020-10-16 13:37:12 R-1.P3_ENDTIME_SATURDAY_10 1440
2020-10-16 13:37:12 R-1.P3_ENDTIME_SATURDAY_11 1440
2020-10-16 13:37:12 R-1.P3_ENDTIME_SATURDAY_12 1440
2020-10-16 13:37:12 R-1.P3_ENDTIME_SATURDAY_13 1440
2020-10-16 13:37:12 R-1.P3_ENDTIME_SATURDAY_2 1320
2020-10-16 13:37:12 R-1.P3_ENDTIME_SATURDAY_3 1440
2020-10-16 13:37:12 R-1.P3_ENDTIME_SATURDAY_4 1440
2020-10-16 13:37:12 R-1.P3_ENDTIME_SATURDAY_5 1440
2020-10-16 13:37:12 R-1.P3_ENDTIME_SATURDAY_6 1440
2020-10-16 13:37:12 R-1.P3_ENDTIME_SATURDAY_7 1440
2020-10-16 13:37:12 R-1.P3_ENDTIME_SATURDAY_8 1440
2020-10-16 13:37:12 R-1.P3_ENDTIME_SATURDAY_9 1440
2020-10-16 13:37:12 R-1.P3_ENDTIME_SUNDAY_1 360
2020-10-16 13:37:12 R-1.P3_ENDTIME_SUNDAY_10 1440
2020-10-16 13:37:12 R-1.P3_ENDTIME_SUNDAY_11 1440
2020-10-16 13:37:12 R-1.P3_ENDTIME_SUNDAY_12 1440
2020-10-16 13:37:12 R-1.P3_ENDTIME_SUNDAY_13 1440
2020-10-16 13:37:12 R-1.P3_ENDTIME_SUNDAY_2 1320
2020-10-16 13:37:12 R-1.P3_ENDTIME_SUNDAY_3 1440
2020-10-16 13:37:12 R-1.P3_ENDTIME_SUNDAY_4 1440
2020-10-16 13:37:12 R-1.P3_ENDTIME_SUNDAY_5 1440
2020-10-16 13:37:12 R-1.P3_ENDTIME_SUNDAY_6 1440
2020-10-16 13:37:12 R-1.P3_ENDTIME_SUNDAY_7 1440
2020-10-16 13:37:12 R-1.P3_ENDTIME_SUNDAY_8 1440
2020-10-16 13:37:12 R-1.P3_ENDTIME_SUNDAY_9 1440
2020-10-16 13:37:12 R-1.P3_ENDTIME_THURSDAY_1 360
2020-10-16 13:37:12 R-1.P3_ENDTIME_THURSDAY_10 1440
2020-10-16 13:37:12 R-1.P3_ENDTIME_THURSDAY_11 1440
2020-10-16 13:37:12 R-1.P3_ENDTIME_THURSDAY_12 1440
2020-10-16 13:37:12 R-1.P3_ENDTIME_THURSDAY_13 1440
2020-10-16 13:37:12 R-1.P3_ENDTIME_THURSDAY_2 1320
2020-10-16 13:37:12 R-1.P3_ENDTIME_THURSDAY_3 1440
2020-10-16 13:37:12 R-1.P3_ENDTIME_THURSDAY_4 1440
2020-10-16 13:37:12 R-1.P3_ENDTIME_THURSDAY_5 1440
2020-10-16 13:37:12 R-1.P3_ENDTIME_THURSDAY_6 1440
2020-10-16 13:37:12 R-1.P3_ENDTIME_THURSDAY_7 1440
2020-10-16 13:37:12 R-1.P3_ENDTIME_THURSDAY_8 1440
2020-10-16 13:37:12 R-1.P3_ENDTIME_THURSDAY_9 1440
2020-10-16 13:37:12 R-1.P3_ENDTIME_TUESDAY_1 360
2020-10-16 13:37:12 R-1.P3_ENDTIME_TUESDAY_10 1440
2020-10-16 13:37:12 R-1.P3_ENDTIME_TUESDAY_11 1440
2020-10-16 13:37:12 R-1.P3_ENDTIME_TUESDAY_12 1440
2020-10-16 13:37:12 R-1.P3_ENDTIME_TUESDAY_13 1440
2020-10-16 13:37:12 R-1.P3_ENDTIME_TUESDAY_2 1320
2020-10-16 13:37:12 R-1.P3_ENDTIME_TUESDAY_3 1440
2020-10-16 13:37:12 R-1.P3_ENDTIME_TUESDAY_4 1440
2020-10-16 13:37:12 R-1.P3_ENDTIME_TUESDAY_5 1440
2020-10-16 13:37:12 R-1.P3_ENDTIME_TUESDAY_6 1440
2020-10-16 13:37:12 R-1.P3_ENDTIME_TUESDAY_7 1440
2020-10-16 13:37:12 R-1.P3_ENDTIME_TUESDAY_8 1440
2020-10-16 13:37:12 R-1.P3_ENDTIME_TUESDAY_9 1440
2020-10-16 13:37:12 R-1.P3_ENDTIME_WEDNESDAY_1 360
2020-10-16 13:37:12 R-1.P3_ENDTIME_WEDNESDAY_10 1440
2020-10-16 13:37:12 R-1.P3_ENDTIME_WEDNESDAY_11 1440
2020-10-16 13:37:12 R-1.P3_ENDTIME_WEDNESDAY_12 1440
2020-10-16 13:37:12 R-1.P3_ENDTIME_WEDNESDAY_13 1440
2020-10-16 13:37:12 R-1.P3_ENDTIME_WEDNESDAY_2 1320
2020-10-16 13:37:12 R-1.P3_ENDTIME_WEDNESDAY_3 1440
2020-10-16 13:37:12 R-1.P3_ENDTIME_WEDNESDAY_4 1440
2020-10-16 13:37:12 R-1.P3_ENDTIME_WEDNESDAY_5 1440
2020-10-16 13:37:12 R-1.P3_ENDTIME_WEDNESDAY_6 1440
2020-10-16 13:37:12 R-1.P3_ENDTIME_WEDNESDAY_7 1440
2020-10-16 13:37:12 R-1.P3_ENDTIME_WEDNESDAY_8 1440
2020-10-16 13:37:12 R-1.P3_ENDTIME_WEDNESDAY_9 1440
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_FRIDAY_1 17.0
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_FRIDAY_10 17.0
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_FRIDAY_11 17.0
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_FRIDAY_12 17.0
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_FRIDAY_13 17.0
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_FRIDAY_2 21.0
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_FRIDAY_3 17.0
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_FRIDAY_4 17.0
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_FRIDAY_5 17.0
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_FRIDAY_6 17.0
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_FRIDAY_7 17.0
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_FRIDAY_8 17.0
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_FRIDAY_9 17.0
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_MONDAY_1 17.0
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_MONDAY_10 17.0
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_MONDAY_11 17.0
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_MONDAY_12 17.0
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_MONDAY_13 17.0
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_MONDAY_2 21.0
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_MONDAY_3 17.0
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_MONDAY_4 17.0
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_MONDAY_5 17.0
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_MONDAY_6 17.0
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_MONDAY_7 17.0
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_MONDAY_8 17.0
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_MONDAY_9 17.0
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_SATURDAY_1 17.0
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_SATURDAY_10 17.0
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_SATURDAY_11 17.0
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_SATURDAY_12 17.0
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_SATURDAY_13 17.0
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_SATURDAY_2 21.0
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_SATURDAY_3 17.0
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_SATURDAY_4 17.0
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_SATURDAY_5 17.0
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_SATURDAY_6 17.0
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_SATURDAY_7 17.0
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_SATURDAY_8 17.0
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_SATURDAY_9 17.0
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_SUNDAY_1 17.0
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_SUNDAY_10 17.0
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_SUNDAY_11 17.0
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_SUNDAY_12 17.0
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_SUNDAY_13 17.0
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_SUNDAY_2 21.0
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_SUNDAY_3 17.0
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_SUNDAY_4 17.0
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_SUNDAY_5 17.0
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_SUNDAY_6 17.0
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_SUNDAY_7 17.0
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_SUNDAY_8 17.0
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_SUNDAY_9 17.0
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_THURSDAY_1 17.0
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_THURSDAY_10 17.0
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_THURSDAY_11 17.0
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_THURSDAY_12 17.0
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_THURSDAY_13 17.0
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_THURSDAY_2 21.0
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_THURSDAY_3 17.0
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_THURSDAY_4 17.0
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_THURSDAY_5 17.0
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_THURSDAY_6 17.0
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_THURSDAY_7 17.0
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_THURSDAY_8 17.0
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_THURSDAY_9 17.0
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_TUESDAY_1 17.0
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_TUESDAY_10 17.0
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_TUESDAY_11 17.0
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_TUESDAY_12 17.0
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_TUESDAY_13 17.0
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_TUESDAY_2 21.0
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_TUESDAY_3 17.0
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_TUESDAY_4 17.0
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_TUESDAY_5 17.0
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_TUESDAY_6 17.0
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_TUESDAY_7 17.0
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_TUESDAY_8 17.0
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_TUESDAY_9 17.0
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_WEDNESDAY_1 17.0
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_WEDNESDAY_10 17.0
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_WEDNESDAY_11 17.0
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_WEDNESDAY_12 17.0
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_WEDNESDAY_13 17.0
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_WEDNESDAY_2 21.0
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_WEDNESDAY_3 17.0
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_WEDNESDAY_4 17.0
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_WEDNESDAY_5 17.0
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_WEDNESDAY_6 17.0
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_WEDNESDAY_7 17.0
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_WEDNESDAY_8 17.0
2020-10-16 13:37:12 R-1.P3_TEMPERATURE_WEDNESDAY_9 17.0
2020-10-16 13:37:12 R-1.PARTY_MODE_PRIORITIZATION 1
2020-10-16 13:37:12 R-1.TEMPERATUREFALL_MODUS 4
2020-10-16 13:37:12 R-1.TEMPERATUREFALL_VALUE 1.4
2020-10-16 13:37:12 R-1.TEMPERATUREFALL_WINDOW_OPEN_TIME_PERIOD 15
2020-10-16 13:37:12 R-1.TEMPERATURE_COMFORT 21.0
2020-10-16 13:37:12 R-1.TEMPERATURE_LOWERING 17.0
2020-10-16 13:37:12 R-1.TEMPERATURE_MAXIMUM 30.5
2020-10-16 13:37:12 R-1.TEMPERATURE_MINIMUM 4.5
2020-10-16 13:37:12 R-1.TEMPERATURE_OFFSET 0.0
2020-10-16 13:37:12 R-1.TEMPERATURE_WINDOW_OPEN 12.0
2020-10-16 13:37:12 R-1.VALVE_ERROR_RUN_POSITION 0.1
2020-10-16 13:37:12 R-1.VALVE_MAXIMUM_POSITION 1.0
2020-10-16 13:37:12 R-1.VALVE_OFFSET 0.0
2020-10-21 08:03:27 control 17.0
2020-10-21 08:03:28 hmstate 17.0
2020-10-21 08:03:27 state 17.0
2020-10-21 08:03:27 valve_position 0
2020-10-21 08:03:27 valve_position_STATUS 0
hmccu:
devspec 000A18A996XXXX
dp:
0.CONFIG_PENDING:
OSVAL 0
OVAL 1
SVAL 0
VAL 1
0.DUTY_CYCLE:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
0.INSTALL_TEST:
OSVAL true
OVAL true
SVAL true
VAL true
0.LOW_BAT:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
0.OPERATING_VOLTAGE:
OSVAL 3.0
OVAL 3.0
SVAL 3.0
VAL 3.0
0.OPERATING_VOLTAGE_STATUS:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
0.RSSI_DEVICE:
OSVAL -44
OVAL -42
SVAL -44
VAL -42
0.RSSI_PEER:
OSVAL 202
OVAL 201
SVAL 202
VAL -53
0.UNREACH:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
0.UPDATE_PENDING:
OSVAL false
OVAL false
SVAL false
VAL false
1.ACTIVE_PROFILE:
OSVAL 1
OVAL 1
SVAL 1
VAL 1
1.ACTUAL_TEMPERATURE:
OSVAL 22.2
OVAL 22.2
SVAL 22.2
VAL 22.2
1.ACTUAL_TEMPERATURE_STATUS:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
1.BOOST_MODE:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
1.BOOST_TIME:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
1.FROST_PROTECTION:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
1.LEVEL:
OSVAL 0
OVAL 0.0
SVAL 0
VAL 0.0
1.LEVEL_STATUS:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
1.PARTY_MODE:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
1.PARTY_SET_POINT_TEMPERATURE:
OSVAL 0.0
OVAL 0.000000
SVAL 0.0
VAL 0.000000
1.PARTY_TIME_END:
OSVAL
OVAL
SVAL
VAL
1.PARTY_TIME_START:
OSVAL
OVAL
SVAL
VAL
1.QUICK_VETO_TIME:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
1.SET_POINT_MODE:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
1.SET_POINT_TEMPERATURE:
OSVAL 17.0
OVAL 17.0
SVAL 17.0
VAL 17.0
1.SWITCH_POINT_OCCURED:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
1.VALVE_ADAPTION:
OSVAL false
OVAL false
SVAL false
VAL false
1.VALVE_STATE:
OSVAL 4
OVAL 4
SVAL 4
VAL 4
1.WINDOW_STATE:
OSVAL closed
OVAL 0
SVAL closed
VAL 0
Attributes:
DbLogInclude 1.ACTUAL_TEMPERATURE,1.SET_POINT_TEMPERATURE,1.BOOST_MODE,valve_position
IODev d_ccu
alias Heizung WC
ccureadingfilter ^ACTUAL_TEMPERATURE|^BOOST_MODE|^SET_POINT_MODE|^SET_POINT_TEMPERATURE|^LEVEL|^WINDOW_STATE|^LOW_BAT.*
ccureadingname 1.LEVEL:valve_position
ccuscaleval LEVEL:0:1:0:100
controldatapoint 1.SET_POINT_TEMPERATURE
eventMap /datapoint 1.BOOST_MODE true:Boost/datapoint 1.CONTROL_MODE 0:Auto/datapoint 1.CONTROL_MODE 1:Manual/datapoint 1.CONTROL_MODE 2:Holiday/datapoint 1.CONTROL_MODE 1 1.SET_POINT_TEMPERATURE 4.5:off/datapoint 1.CONTROL_MODE 0 1.SET_POINT_TEMPERATURE 30.5:on/datapoint 1.WINDOW_STATE 0:WindowClosed/datapoint 1.WINDOW_STATE 1:WindowOpen
group Heizung
room EG->WC
statedatapoint 1.SET_POINT_TEMPERATURE
stripnumber 1
substexcl control
substitute SET_POINT_TEMPERATURE!#0-4.5:off,#30.5-40:on;WINDOW_STATE!(0|false):closed,(1|true):open
webCmd control:Boost:Auto:Manual:Holiday:on:off
widgetOverride control:slider,4.5,0.5,30.5,1
- Weekprofile:
Internals:
CONFIGFILE ./log/weekprofile-wp_HeizWC.cfg
DEF HmIP_eTRV_2_000A18A996XXXX
FUUID 5f8944aa-f33f-6319-9c0e-xxxxxx
NAME wp_HeizWC
NR 408
NTFY_ORDER 50-wp_HeizWC
STATE assigned
TYPE weekprofile
MASTERDEV:
NAME HmIP_eTRV_2_000A18A996XXXX
TYPE HMCCU_IP
PROFILES:
HASH(0x6af30cd)
HASH(0x6ac3cd8)
HASH(0x7579dc0)
READINGS:
2020-10-21 08:03:28 profile_count 3
2020-10-16 10:57:21 state assigned
SNDDEVLIST:
HASH(0x6aebcf0)
HASH(0x1d2a010)
HASH(0x8760710)
HASH(0x86804d8)
HASH(0x831d650)
HASH(0x88865a0)
HASH(0x881f8c0)
HASH(0x87c9230)
HASH(0x85780b8)
HASH(0x8721890)
HASH(0x8eb6170)
HASH(0x8779f68)
HASH(0x88afec8)
HASH(0x7055430)
HASH(0x8944f20)
HASH(0x8aa88b0)
HASH(0x8a9dab0)
HASH(0x6f4aa90)
HASH(0x7405a88)
HASH(0x70660d0)
HASH(0x75a5520)
HASH(0x8991020)
HASH(0x6a1eba0)
HASH(0x68b5658)
HASH(0x6a87660)
HASH(0x6df4a70)
HASH(0x6df3198)
HASH(0x6a598b0)
HASH(0x7ecce60)
HASH(0x7e8ecf0)
HASH(0x6c3a860)
HASH(0x6abd180)
HASH(0x6ccd7d0)
TOPICS:
default
Attributes:
room Steuerung->Heizung->Generell
Wenn ich das Master-Profil bearbeite und auf speichern klicke werden die Änderungen nicht übernommen. Bei send-to-device kommt der Fehler: "HMCCUDEV: HmIP_eTRV_2_000A18A996XXXX Execution of CCU script or command failed".
Im Wiki steht was von den Kanälen Clima bzw. Climate, das scheint bei mir aber nicht zu funktionieren, oder mir fehlt da noch etwas Verständnis, wie ich das umsetzen muss. Jedenfalls kann ich nicht auf den Thermostat zugreifen, wenn ich ein _Clima bzw. _Climate beim define an den Devicenamen anhänge.
Mir fehlt hier der Ansatzpunkt, woran es liegen könnte. HMCCU, weekprofile, ...
Vielen Dank für eure Hilfe
Sascha
@ToKa: Auch wenn du "send to device" aus weekprofile ausführst, holt sich WDT effektiv die Daten via "get" ab. Versendet wird nur die Info, auf welches Profil von welchem weekprofile gewechselt werden soll.
@Risiko: M.E. darf das Verhalten, dass "Klartext" gesendet wird auch gerne so bleiben, es gibt einige wenige User, die das für ihre Thermostate so nutzen (afaik jedenfalls, solche, die eQ-3-BT-Thermostate haben). Mit der Testversion von WDT könnte man es auf der Seite "reparieren", von daher (wenn das mal final ist), wäre es aber auch verschmerzbar, wenn du das unbedingt umstellen wolltest.
Für MQTT2_DEVICE wäre es (noch) egal, wobei ich tendenziell auch dort speziell die Schlüsselworte "on" und "off" durchaus hilfreich finde.
Dem Bauchgefühl nach ist alles, was man an Mapping auf der weekprofile-Seite generiert, eher geeignet, die User zu verwirren. Solange man die relativ klare Sichtweise hat: "weekprofile sendet eine Temperaturliste", ist es auch logisch, dass man sich um die Umsetzung von nummerischen Werten auf "irgendwas anderes" außerhalb weekprofile kümmern muß, was es dann eben im Ergebnis erleichtert, die Funktionsweise an sich zu erklären.
Und ich vermute auch, dass man an Hardware im Ergebnis eigentlich auch für die Dinge, die uns bisher unbekannt sind, immer "einfache" (=nummerische) Temperaturen wird versenden müssen, die spannende Frage ist eigentlich nur, wie man das verpacken muss...
@ToKa: Ich teile den Eindruck von Risiko, dass du sehr spezifisch in den ZWave-Kategorieren denkst. Wir werden aber vor der Aufgabe stehen, ggf. "echte" ZWave-Temperaturlisten (auf der Hardware ausgeführt) zu integrieren und das ggf. mindestens für ZigBee@HUEDevice auch noch irgendwie umzusetzen. Jede weitere Abweichung in Richtung Text könnte da hinderlich sein - und bezogen auf das "Hilfsdevice" WeekdayTimer die Aussage verwässern, dass man eben dort dann Temperaturen nach "was auch immer" mappen muss...
Ggf. solltest du auch nochmal sehen, ob du deine ganze Logik nicht umstellen willst; es gibt seit neuestem ja eine bessere Unterstützung des Readings "desired-temp" bei ZWave, das macht eventuell solche Klimmzüge mit tmHeating etc. eher zum "Auslaufmodell".
Und sorry, falls ich da was übersehen haben sollte. Das ganze Thema ist jedenfalls für meinen Horizont ziemlich unübersichtlich; was ich bisher gemacht habe, hat eben die vorhandenen Optionen auszunutzen, wobei das immer irgendwie auch so generisch gestaltet war (hoffentlich?), dass man es auf das eigentliche Zieldevice dann jeweils irgendwie angepaßt bekommt...
Zitat von: phoenix-anasazi am 23 Dezember 2020, 13:22:44
Wenn ich das Master-Profil bearbeite und auf speichern klicke werden die Änderungen nicht übernommen. Bei send-to-device kommt der Fehler: "HMCCUDEV: HmIP_eTRV_2_000A18A996XXXX Execution of CCU script or command failed".
Im Wiki steht was von den Kanälen Clima bzw. Climate, das scheint bei mir aber nicht zu funktionieren, oder mir fehlt da noch etwas Verständnis, wie ich das umsetzen muss. Jedenfalls kann ich nicht auf den Thermostat zugreifen, wenn ich ein _Clima bzw. _Climate beim define an den Devicenamen anhänge.
Mir fehlt hier der Ansatzpunkt, woran es liegen könnte. HMCCU, weekprofile, ...
Hallo Sascha,
hast du das mit der letzten Version von weekprofile nochmal probiert?
Was ist denn bei deinem HmIP eTRV-2 ein korrekter Befehl um das Profil zu ändern\setzen? Wichtig, es muss erstmal so (ohne weekprofile) funktionieren.
Es sieht so aus, als wenn der Syntax des Befehls, den weekprofile sendet nicht i.O. ist. Erhöhe doch mal den Loglevel (verbose=4) von weekprofile.
Da sieht man den erzeugten Befehl im Log. Es sollte auch geprüft werden, ob das Device richtig als HmIP erkannt wird. Steht dann auch im Log.
Risiko
Hallo Ihr Beiden,
ok, habe jetzt das Zusammenspiel verstanden. weekprofil ist ja nun auch historisch in einem ganz anderen Kontext entstanden und sehr mächtig.
Da meine Installation schon sehr lange mit Z-Wave (inkl. dem bisherigen Verhalten von desired-temp) und WDT wunderbar funktioniert, muss es keine Anpassungen an weekrpofile geben. Ich bin halt nur durch die aktuellen Änderungen und Forenbeiträge darüber gestolpert und finde es auch super, dass WDT jetzt damit zusammen arbeitet. Aber wie gesagt, ich brauche das nicht. Und ja, mein Fokus liegt auf Z-Wave, da ich das fast ausschließlich nutze.
Mein fhem werkelt auch still im Hintergrund und ist sehr stark automatisiert (DOIF, WDT, presence, Kalender...). Speziell in die Heizungssteuerung greife ich selten manuell ein und insofern läuft das vorwiegend über tmHeating und tmEnergySaveHeating. Einen Raum steuere ich über desired-temp oder mal am Thermostat selbst, aber das habe ich auch alles im Griff (user reading bzw. DOIF).
@Beta-User: Ich meine Du hast auch die Z-Wave Eurotronic Spirit im Einsatz, wie ich im Z-Wave Forum gelesen habe. Wir können uns gerne dazu mal anderweitig austauschen.
Beste Grüße
Torsten
Hallo,
danke für die Rückmeldung. Ja habe die aktuelle Version von Weekprofile. Hier mal ein Auszug aus dem log mit Verbose 4 im wp_HeizBuero beim send to device default.
2020.12.23 15:10:27 1: HMCCURPCPROC: [d_rpc002246HmIP_RF : 1027] Unknown Paramset: MASTER
2020.12.23 15:10:27 1: HMCCUDEV: [HmIP_eTRV_2_000A18A996XXXX : 1027] HMCCUDEV: HmIP_eTRV_2_000A18A996XXXX Execution of CCU script or command failed
2020.12.23 15:10:34 1: HMCCURPCPROC: [d_rpc002246HmIP_RF : 1027] Invalid parameter or value
2020.12.23 15:10:34 1: HMCCUDEV: [HmIP_eTRV_2_000A18A996XXXX : 1027] HMCCUDEV: HmIP_eTRV_2_000A18A996XXXX Execution of CCU script or command failed
2020.12.23 15:10:34 4: wp_HeizBueroUG(Notify): reread master profile from HmIP_eTRV_2_000A18A996XXXX
2020.12.23 15:17:46 4: wp_HeizBueroUG(getDeviceType): HmIP_eTRV_2_000A18A996XXXX is type HMCCU_IP
2020.12.23 15:17:46 4: wp_HeizBueroUG(sendDevProfile): set HmIP_eTRV_2_000A18A996XXXX config 1 R-1.P1_TEMPERATURE_MONDAY_1=17.0 R-1.P1_ENDTIME_MONDAY_1=360 R-1.P1_TEMPERATURE_MONDAY_2=17.0 R-1.P1_ENDTIME_MONDAY_2=1440
2020.12.23 15:17:46 1: HMCCURPCPROC: [d_rpc002246HmIP_RF : 1027] Invalid parameter or value
2020.12.23 15:17:46 1: HMCCUDEV: [HmIP_eTRV_2_000A18A996XXXX : 1027] HMCCUDEV: HmIP_eTRV_2_000A18A996XXXX Execution of CCU script or command failed
2020.12.23 15:17:46 1: wp_HeizBueroUG(Set): HMCCUDEV: HmIP_eTRV_2_000A18A996XXXX Execution of CCU script or command failed
2020.12.23 15:17:46 4: wp_HeizBueroUG(Notify): reread master profile from HmIP_eTRV_2_000A18A996XXXX
Scheint mir auch so, als ob der Befehl nicht funktioniert. Ich meine mal gelesen zu haben, dass es ohne R-1 funktioniert, tut es aber bei mir auch nicht. Hat noch jemand eine Idee wie der Befehl aussehen muss, bzw. wo könnte ich das finden? Den ccutype-Fehler bekomme ich jetzt auch wieder (Log-Level auf 4). Im Thermostat-Device ist ccutype aber ja gesetzt auf HmIP-eTRV-2 (s.o.). Ich hab jetzt nach neu anlegen des Weekprofiles auch nur das Profil "default" vorher hatte ich "master".
Ich bin für jede Hilfe/Schubser dankbar.
Zitat von: ToKa am 23 Dezember 2020, 14:16:36
@Beta-User: Ich meine Du hast auch die Z-Wave Eurotronic Spirit im Einsatz, wie ich im Z-Wave Forum gelesen habe. Wir können uns gerne dazu mal anderweitig austauschen.
Na ja, ich habe derzeit genau einen. Den habe ich besorgt, weil mir schleierhaft war, was da teilweise an workarounds zu diversen Teilaspekten rund um den Spirit so im Umlauf war. Leider bin ich noch intensiver nicht dazu gekommen, mich mit den Auswirkungen der Änderung von Rudi (auch am besten zum Mitdiskutieren ab hier: https://forum.fhem.de/index.php/topic,112955.msg1098942.html#msg1098942) zu befassen, meine aber, dass "setReadingOnAck" deutlich zur Transparenz grade bei diesen Geräten beiträgt...
(Aber jetzt lassen wir Risiko wieder mit diesen "Spezialitäten" in Ruhe ;) ).
Zitat von: phoenix-anasazi am 23 Dezember 2020, 15:19:47
Scheint mir auch so, als ob der Befehl nicht funktioniert. Ich meine mal gelesen zu haben, dass es ohne R-1 funktioniert, tut es aber bei mir auch nicht. Hat noch jemand eine Idee wie der Befehl aussehen muss, bzw. wo könnte ich das finden? Den ccutype-Fehler bekomme ich jetzt auch wieder (Log-Level auf 4). Im Thermostat-Device ist ccutype aber ja gesetzt auf HmIP-eTRV-2 (s.o.). Ich hab jetzt nach neu anlegen des Weekprofiles auch nur das Profil "default" vorher hatte ich "master".
Ich bin für jede Hilfe/Schubser dankbar.
Da kein master-Profil da ist, liegt es wohl an dem nicht erkennen von ccutype. Das habe ich in der letzten Version geändert (vorher wurde default HM, also nicht IP angenommen).
Warum ccutype nicht erkannt wird, kann ich leider nicht erkennen. Das müssen wir aber klären, sonst geht es eh nicht weiter (anbei eine Testversion mit erweitertem Log und ggf. Erkennung aus NAME)
Den richtigen Befehl muss ich natürlich wissen und dieser
muss ohne weekprofile funktionieren. Erst dann macht es Sinn da weiter zu machen. Du musst du dich schon belesen oder im HM-Thread nachfragen.
Danke nochmal. Also deine Testversion hat immerhin schonmal dazu geführt, dass ich das master-Profil wieder bekomme. Anbei mal ein Log-Auszug mit der Testversion:
2020.12.23 17:39:19 4: wp_HeizBueroUG(getDeviceType): ccutype not defined
2020.12.23 17:39:19 4: wp_HeizBueroUG(getDeviceType): ccutype not defined
2020.12.23 17:39:19 4: wp_HeizBueroUG(getDeviceType): ccutype not defined
2020.12.23 17:39:19 4: wp_HeizBueroUG(getDeviceType): ccutype not defined
2020.12.23 17:39:32 4: wp_HeizBueroUG(getDeviceType): HmIP_eTRV_2_000A18A996XXXX is type HMCCU_IP
2020.12.23 17:39:32 4: wp_HeizBueroUG(sendDevProfile): set HmIP_eTRV_2_000A18A996XXXX config 1 R-1.P1_TEMPERATURE_TUESDAY_1=17.0 R-1.P1_ENDTIME_TUESDAY_1=360 R-1.P1_TEMPERATURE_TUESDAY_2=21.0 R-1.P1_ENDTIME_TUESDAY_2=1200 R-1.P1_TEMPERATURE_TUESDAY_3=17.0 R-1.P1_ENDTIME_TUESDAY_3=1440 R-1.P1_TEMPERATURE_WEDNESDAY_1=17.0 R-1.P1_ENDTIME_WEDNESDAY_1=360 R-1.P1_TEMPERATURE_WEDNESDAY_2=21.0 R-1.P1_ENDTIME_WEDNESDAY_2=1200 R-1.P1_TEMPERATURE_WEDNESDAY_3=17.0 R-1.P1_ENDTIME_WEDNESDAY_3=1440
2020.12.23 17:39:32 1: HMCCURPCPROC: [d_rpc002246HmIP_RF : 1027] Invalid parameter or value
2020.12.23 17:39:32 1: HMCCUDEV: [HmIP_eTRV_2_000A18A996XXXX : 1027] HMCCUDEV: HmIP_eTRV_2_000A18A996XXXX Execution of CCU script or command failed
2020.12.23 17:39:32 4: wp_HeizBueroUG(Notify): reread master profile from HmIP_eTRV_2_000A18A996XXXX
2020.12.23 17:39:37 4: wp_HeizBueroUG(Set): reread master profile from HmIP_eTRV_2_000A18A996XXXX
2020.12.23 17:39:37 4: wp_HeizBueroUG(getDeviceType): ccutype not defined
2020.12.23 17:39:37 4: wp_HeizBueroUG(getDeviceType): ccutype not defined
2020.12.23 17:39:37 4: wp_HeizBueroUG(getDeviceType): ccutype not defined
2020.12.23 17:39:37 4: wp_HeizBueroUG(getDeviceType): ccutype not defined
2020.12.23 17:39:44 4: wp_HeizBueroUG(getDeviceType): HmIP_eTRV_2_000A18A996XXXX is type HMCCU_IP
2020.12.23 17:39:44 4: wp_HeizBueroUG(sendDevProfile): nothing to do
2020.12.23 17:39:44 4: wp_HeizBueroUG(getDeviceType): ccutype not defined
2020.12.23 17:39:44 4: wp_HeizBueroUG(getDeviceType): ccutype not defined
2020.12.23 17:39:44 4: wp_HeizBueroUG(getDeviceType): ccutype not defined
2020.12.23 17:39:44 4: wp_HeizBueroUG(getDeviceType): ccutype not defined
2020.12.23 17:40:06 4: wp_HeizBueroUG(Notify): reread master profile from HmIP_eTRV_2_000A18A996XXXX
2020.12.23 17:40:06 4: wp_HeizBueroUG(Notify): reread master profile from HmIP_eTRV_2_000A18A996XXXX
2020.12.23 17:40:06 4: wp_HeizBueroUG(Notify): reread master profile from HmIP_eTRV_2_000A18A996XXXX
2020.12.23 17:40:06 4: wp_HeizBueroUG(Notify): reread master profile from HmIP_eTRV_2_000A18A996XXXX
2020.12.23 17:40:06 4: wp_HeizBueroUG(Notify): reread master profile from HmIP_eTRV_2_000A18A996XXXX
2020.12.23 17:40:06 4: wp_HeizBueroUG(Notify): reread master profile from HmIP_eTRV_2_000A18A996XXXX
2020.12.23 17:40:44 4: wp_HeizBueroUG(getDeviceType): HmIP_eTRV_2_000A18A996XXXX is type HMCCU_IP
2020.12.23 17:40:44 4: wp_HeizBueroUG(sendDevProfile): set HmIP_eTRV_2_000A18A996XXXX config 1 R-1.P1_TEMPERATURE_TUESDAY_1=17.0 R-1.P1_ENDTIME_TUESDAY_1=360 R-1.P1_TEMPERATURE_TUESDAY_2=21.0 R-1.P1_ENDTIME_TUESDAY_2=1200 R-1.P1_TEMPERATURE_TUESDAY_3=17.0 R-1.P1_ENDTIME_TUESDAY_3=1440 R-1.P1_TEMPERATURE_WEDNESDAY_1=17.0 R-1.P1_ENDTIME_WEDNESDAY_1=360 R-1.P1_TEMPERATURE_WEDNESDAY_2=21.0 R-1.P1_ENDTIME_WEDNESDAY_2=1200 R-1.P1_TEMPERATURE_WEDNESDAY_3=17.0 R-1.P1_ENDTIME_WEDNESDAY_3=1440
2020.12.23 17:40:44 1: HMCCURPCPROC: [d_rpc002246HmIP_RF : 1027] Invalid parameter or value
2020.12.23 17:40:44 1: HMCCUDEV: [HmIP_eTRV_2_000A18A996XXXX : 1027] HMCCUDEV: HmIP_eTRV_2_000A18A996XXXX Execution of CCU script or command failed
2020.12.23 17:40:44 1: wp_HeizBueroUG(Set): HMCCUDEV: HmIP_eTRV_2_000A18A996XXXX Execution of CCU script or command failed
2020.12.23 17:40:44 4: wp_HeizBueroUG(Notify): reread master profile from HmIP_eTRV_2_000A18A996XXXX
2020.12.23 17:40:49 4: wp_HeizBueroUG(getDeviceType): ccutype not defined
2020.12.23 17:40:49 4: wp_HeizBueroUG(getDeviceType): ccutype not defined
2020.12.23 17:40:49 4: wp_HeizBueroUG(getDeviceType): ccutype not defined
2020.12.23 17:40:49 4: wp_HeizBueroUG(getDeviceType): ccutype not defined
Der Befehl funktioniert immer noch nicht (wie auch ;) , habe im Homematic Forum nachgefragt), aber sonst kann ich in dem Log-Auszug nicht viel erkennen. Ich hoffe, das ich im HM-Forum eine Antwort kriege oder vielleicht finde ich selbst noch etwas raus...
Der Log-Auszug passt aber nicht zur Testversion! Bist du dir da wirklich sicher? Hast du ein reload weekprofile gemacht oder FHEM neu gestartet?
Zitat von: ToKa am 23 Dezember 2020, 13:06:52
Hallo Risiko,
Einen kleinen "Schönheitsfehler" gibt es beim Ändern der Daten im weekprpfile widget. Dort wird immer Off angezeigt auch wenn vorher On eingestellt war und beim Speichern dann auch mit Off überschrieben. TempOff 18.0 / TempOn 18.5.
Hallo Risiko,
ich habe mir mal den Quellcode angeschaut und glaube, den Fehler in der fhemweb_weekprofile.js gefunden zu haben. Ich bin zwar kein Javascript Programmierer, aber da Du die Werte "on" und "off" in der weekprofile cfg speicherst, muss auch der Vergleich auf diese Werte gehen und nicht auf die Temperaturen:
for (var k=tempOff; k <= tempOn; k+=.5)
{
if (k == tempOff) {
var selected = (temps[i] == "off") ? "selected " : "";
html += "<option "+selected+"value=\"off\">off</option>";
}
else if (k == tempOn) {
var selected = (temps[i] == "on") ? "selected " : "";
html += "<option "+selected+"value=\"on\">on</option>";
}
else
html += "<option "+selected+"value=\""+k.toFixed(1)+"\">"+k.toFixed(1)+"</option>";
}
Falls Du alles umbaust und die zu on / off korrespondierenden Temperaturen speicherst, vergiss meine Korrektur.
Beste Grüße
Torsten
Hallo Torsten,
vielen Dank. Deine Version funktioniert aber nicht mehr mit Zahlen.
Könntest du bitte meine Version im Anhang testen. Sollte jetzt auch so gehen.
Ja, solange die die Keywords im internen json-Format mit gespeichert werden, ist das leider so und ich werde den Fix dann so einchecken.
Perspektivisch werde ich das aber vermutlich ändern. Zumindest was das interne Speichern angeht. Bin mit meinen Überlegungen aber noch nicht am Ende.
Lassen wir erstmal Weihnachten vorbei sein ;)
Hallo Risiko,
habe mit Deiner Version getestet und es sieht gut aus. Sowohl nur mit on / off, als auch mit Temperaturwerte bzw. Kombination aus beidem.
Würde mich freuen, wenn es dabei bliebe, dass on / off gespeichert werden und damit im WDT "ankommen".
Besten Dank und schöne Weihnachtstage!
Torsten
Nur Temperaturen mit weekprofile?
Hallo beisammen
ich wollte mir mit weekprofile und WeekDayTimer eine Zeitsteuerung für meine Lüftung basteln.
Mir ist jetzt aufgefallen, daß ich im widget ja nur Temperaturen von 18.0 bis 30.0 °C eingeben kann.
Ich bräuchte allerdings Werte von 0-100 (%).
Eine Einstellmöglichkeit für diesen Range konnte ich nicht finden.
Ist der Eingaberange "fest im Widget verdrahtet"?
Wenn ja, dann wäre mein Vorschlag dies evt. durch ein Attribut "zugänglich" zu machen.
Gruß Martin
Zitat von: alpine310 am 27 Dezember 2020, 16:42:50
Nur Temperaturen mit weekprofile?
Im Prinzip: Ja.
ABER: Zum einen kann man den zulässigen Wertebereich (in weekprofile) ändern.
Zum anderen gibt es seit ein paar Tagen eine Testversion von WeekdayTimer, mit der man Werte "mappen" kann. Das funktioniert aber nur mit festen Zuordnungen (bei Interesse bitte suchen).
Und zu guter Letzt kann man ja auch noch schlicht $EVENT mit einer Perl-Funktion als Anweisung in WeekdayTimer weiterverarbeiten und dann z.B. aus 10°C 0% errechnen, aus 30°C 100% und aus Werten dazwischen irgendeinen anderen linearen Wert, das ganze an eine log-Funktion übergeben, oder was einem sonst noch so einfällt.
Von daher braucht weekprofile mAn. auch nichts anderes an WDT übergeben wie ein Temperaturprofil...
ZitatABER: Zum einen kann man den zulässigen Wertebereich (in weekprofile) ändern.
..das würde mir reichen (Wertebereich 0-100)
..nur wo stelle ich den Wertebereich ein? Kann es nicht finden... ::)
Mein Bauchgefühl sagt zwar, dass Rechnen die bessere Lösung wäre, aber here you are:
attr weekprofiles tempOFF -0.5
(Seite refreshen vor dem Bearbeiten der Profile nicht vergessen...).
ZitatMein Bauchgefühl sagt zwar, dass Rechnen die bessere Lösung wäre
...könnte natürlich 18-30 auf 0-100 interoplieren.. nur wie groß wäre da der WAF?
Bei mir bräuchte ich noch ein Loch im Kellerboden um den WAF darstellen zu können. :)
Aber mit dem tempOFF und tempON komme ich weiter.
Danke
Bei mir wäre die Akzeptanz der Mitbewohner im Keller, wenn die überhaupt irgendwas anfassen müssten ;) . Und die Lüftung arbeitet doch vermutlich nicht irgendwie isoliert von allem anderen, sondern irgendeine "Logik" des Zusammenwirkens mit anderen "Heizungsgeräten" dürfte doch gegeben sein?
Na ja, ist eigentlich auch kein weekprofile-Thema mehr...
Zitat von: kadettilac89 am 16 Dezember 2020, 08:48:57
Nur weil es bis jetzt keiner gemeldet hat heißt es nicht, dass sonst keiner betroffen ist. Kann auch sein, dass alle anderen immer zwischendurch speichern.
Inzwischen habe ich FHEM auf einem Raspi 4 neu installiert. fhem.cfg und die 2 weekprofiles habe ich vom alten RSP2 auf den neuen kopiert. Läuft nach checken der Logs, wie die alte Installation. Nur schneller ;D
Incl. dem Effekt, meine Eingaben im Editmodus eines Weekprofiles nach 40s überschrieben zu bekommen :'(
Ich schließe jetzt messerscharf daraus, dass offenbar ein Eintrag der Konfig die Ursache liefern muss. Ich hänge sie mal an. Mir springt nichts ins Auge, was darin mit einem Zeitfaktor zu tun haben könnte.
Wäre sehr dankbar, wenn mal jemand drüberschauen könnte...
Hallo.
Ist wohl ein gleicher Effekt wie hier beginnend beschrieben
https://forum.fhem.de/index.php/topic,46117.msg1110712.html#msg1110712 !?
Leider kann ich das immer noch nicht nachstellen.
Kann aber wie gesagt nur ein Refresh durch den Browser sein. Warum auch immer
Zitat von: Risiko am 06 Januar 2021, 15:57:09
Kann aber wie gesagt nur ein Refresh durch den Browser sein. Warum auch immer
Ja, es es macht fast den Eindruck. Aber nur fast.
2 Fakten sprechen dagegen:
- Ein Standard refresh mit F5 beendet den Editmode. Bei mir bleibt er erhalten.
- Andere Browser (auch unter Android) verhalten sich identisch.
Zitat von: Risiko am 06 Januar 2021, 15:57:09
Ist wohl ein gleicher Effekt wie hier beginnend beschrieben
https://forum.fhem.de/index.php/topic,46117.msg1110712.html#msg1110712 !?
Mit dem Link lande ich bei Antwort #591. Da ist von keinem Effekt die Rede. Link evtl. falsch?
Nee richtig. Einfach die Kommunikation mit onurbi verfolgen ;)
Habe gerade nochmal in den Code gesehen.
Einzige Seiteneffekt wäre ggf. wenn sich das Reading profile_count während der Bearbeitung ändert bzw. aktualisiert wird. Dann sollte das im Browser-Consolen-Log durch FHEMWEB auch erkennbar sein
Rcvd: ["<devicename>-profile_count-ts" ...
Bitte mal beobachten. Danke.
Weekprofile ist mit einem Gerät verbunden?
Anbei eine Testversion, die die Änderung von profile_count im Editmode ignoriert.
Zitat von: Risiko am 06 Januar 2021, 16:57:09
Habe gerade nochmal in den Code gesehen.
Einzige Seiteneffekt wäre ggf. wenn sich das Reading profile_count während der Bearbeitung ändert bzw. aktualisiert wird. Dann sollte das im Browser-Consolen-Log durch FHEMWEB auch erkennbar sein
Rcvd: ["<devicename>-profile_count-ts" ...
Bitte mal beobachten. Danke.
Weekprofile ist mit einem Gerät verbunden?
Im JS-Consolen Log kommt die Zeile im Refreshintervall nicht vor.
D.h. dass das Problem nicht mit einer Änderung des profile_counts zusammenhängt.
Habe die neue Version von fhemweb_weekprofile.js getauscht: Eine Änderung bleibt jetzt erhalten, bedanke mich und bin begeistert ;D
Wenn die Änderung
# diff /opt/fhem/www/pgm2/fhemweb_weekprofile.js /opt/fhem/www/pgm2/fhemweb_weekprofile.js.orig
887,890d886
< if (widget.MODE == 'EDIT') {
< // do not actualize in edit mode
< return;
< }
keine Nebenwirkungen hat, würde ich es direkt so lassen. Eine Editierung wurde auch auf das Thermostat übertragen bzw. das JSON File wurde korrekt editiert.
Zitat von: Risiko am 06 Januar 2021, 16:57:09
Weekprofile ist mit einem Gerät verbunden?
Ja, mit dem virtuellen Device Wandthermostat
define wp_Wohnzimmer weekprofile Wandthermostat
Hallo.
Neues Feature "Temperaturworte" !!!
Aufgrund der Diskussionen mit ToKa (https://forum.fhem.de/index.php/topic,46117.msg1113150.html#msg1113150 ff) betreffs der "Temperaturworte" wie 'on', 'off', 'eco', etc. und der damit verbundenen Inkonsistenz im Modul, habe ich hier aufgeräumt und den indirekten Feature Request umgesetzt.
Man kann nun mittels dem Attribut 'tempMap' beliebige Wort-Temperaturpaare vergeben.
Die Attribute 'tempOn' und 'tempOff' entfallen. Eine automatische Konvertierung in tempMap erfolgt auch.
Neu ist auch das Attribut 'widgetTempRange', mit dem man den Wertebereich der Dropdown-Liste im FHEM widget beeinflussen kann.
Achtung an die Anwender von WeekdayTimer:
Diese müssen jetzt das Attribut 'sendKeywordsToDevices' setzen, wenn Sie die neue Version von WDT von gestern verwenden.
Da es doch recht umfangreiche Änderungen sind, würde ich mich über zahlreiche Testung freuen, bevor es offiziell wird.
Danke.
Risiko
Hallo Risiko,
zunächst vielen Dank, dass Du das "FeatureRequest" umgesetzt hast. Die ersten Tests sehen super aus und das weekprofile wird im Weekdaytimer mit den Texten übernommen. Lediglich im weekprofile stört das "°C" bei den Textwerten etwas. Im Test habe ich jetzt sogar mit 3 Textwerten gearbeitet, was über das neue Attribut "widgetTempRange" und tempMap prima funktioniert.
Mon 00:00-05:50 comfort_nite °C 05:50-18:50 eco °C 18:50-22:00 comfort °C 22:00-24:00 comfort_nite °C
Tue 00:00-05:50 comfort_nite °C 05:50-18:50 eco °C 18:50-22:00 comfort °C 22:00-24:00 comfort_nite °C
Wed 00:00-05:50 comfort_nite °C 05:50-18:50 eco °C 18:50-22:00 comfort °C 22:00-24:00 comfort_nite °C
Thu 00:00-05:50 comfort_nite °C 05:50-18:50 eco °C 18:50-22:00 comfort °C 22:00-24:00 comfort_nite °C
Fri 00:00-05:50 comfort_nite °C 05:50-18:50 eco °C 18:50-23:50 comfort °C 23:50-24:00 comfort_nite °C
Sat 00:00-08:10 comfort_nite °C 08:10-19:50 eco °C 19:50-23:50 comfort °C 23:50-24:00 comfort_nite °C
Sun 00:00-08:10 comfort_nite °C 08:10-19:50 eco °C 19:50-23:50 comfort °C 23:50-24:00 comfort_nite °C
Ich beobachte mal noch weiter und muss mal noch mit verschiedenen Topics testen.
Viele Grüße
Torsten
Zitat von: ToKa am 07 Februar 2021, 20:28:25
Hallo Risiko,
zunächst vielen Dank, dass Du das "FeatureRequest" umgesetzt hast. Die ersten Tests sehen super aus und das weekprofile wird im Weekdaytimer mit den Texten übernommen. Lediglich im weekprofile stört das "°C" bei den Textwerten etwas. Im Test habe ich jetzt sogar mit 3 Textwerten gearbeitet, was über das neue Attribut "widgetTempRange" und tempMap prima funktioniert.
Hallo Thorsten,
danke fürs Testen und dem Feedback.
Habe die Version heute eingecheckt.
Das mit den "°C" verstehe ich aber leider nicht. Weekprofile liefert in den json-Daten kein "°C" mit. Das kommt dann wohl eher vom WDT? Frag doch mal bei Beta-User an.
Risiko.
Hallo Risiko,
nein es geht um die Darstellung des weekprofile Device (siehe Screenshot). Ist aber kosmetisch, damit kann ich leben.
VG
Torsten
Ah ok. Verstanden ;D
Lässt sich bestimmt noch was machen ;)
Hallo Risiko,
mir ist heute nach dem Neustart von fhem noch ein Fehler im Log aufgefallen:
2021.02.17 08:18:23 2: ST_sz_THKV_Heizkoerper_Wand_wp_01(weekprofile_createTempMap): create map from eco:18.0,comfort:18.5,comfort_nite:19.0
2021.02.17 08:18:29 1: Including ./log/fhem.save
2021.02.17 08:18:29 1: PERL WARNING: Use of uninitialized value $attrMap in concatenation (.) or string at ./FHEM/98_weekprofile.pm line 1412.
2021.02.17 08:18:29 2: ST_sz_THKV_Heizkoerper_Wand_wp_01(weekprofile_createTempMap): create map from
Falls Du ein List vom device benötigst, sag Bescheid.
Viele Grüße
Torsten
Danke.
Behoben und die Anzeige von '°C' bei Wörtern auch.
Hallo Risiko,
vielen Dank für Änderung und Fehlerbegebung. Funktioniert!
VG
Torsten
Hallo,
zur Zeit wird in mehreren Threads zum eBus die Nutzung des weekprofile-Moduls für die Konfiguration von Zeitplänen in Heizungssteuerungen diskutiert. Ich habe mir das mal genauer für meine Vaillant-Anlage angesehen, und einige grundlegende Unterschiede in der Anwendung/Erwartungshaltung festgestellt:
- Bei der direkten Ansteuerung von Ventilen usw. ist fhem der ,,Master", der die Zeitprofile verwaltet und auf mehrere Geräte verteilt. Bei einer Heizungsanlage ist fhem nur das Vehikel, um Zeitpläne einzugeben. Die Verwaltung und Auswertung liegt weiterhin in der Heizungsanlage selbst.
- Bei der direkten fhem-Steuerung gibt man zu jedem Zeitintervall eine Soll-Temperatur ein. Bei Heizungsanlagen ist die Soll-Temperatur aber zentral verwaltet; die Zeitintervalle steuern nur, ob die Heizung im Normalbetrieb oder im Nachabsenkungsbetrieb läuft. Man konfiguriert dort also keine Temperaturwerte im Rahmen der Zeitprofile, und zeigt auch nur die ,,on"-Intervalle an, in denen die Heizung im Normalbetrieb läuft.
- Die Anzahl der möglichen Zeitintervalle ist durch die Heizungssteuerung fest vorgegeben; man kann nicht beliebig viele definieren.
- Die möglichen Profile (=Heizkreise bzw. Warmwasserbereitung) sind ebenfalls fest durch die Installation vorgegeben.
Man könnte jetzt sagen, die beiden Szenarien unterscheiden sich so stark, dass man dafür auch verschiedene Eingabemodule braucht. Es ist auch bestimmt nicht gut, zu viele Verzweigungen in ein Modul zu packen. Ich glaube aber in diesem Fall, dass es nicht so schwierig ist, beides in einem Modul zu vereinen, und hab einfach mal einen entsprechenden Vorschlag gemacht. Sieht auf den ersten Blick viel aus, war im Grunde aber relativ einfach, und ist von der Implementierung her sehr überschaubar. Hab alle auskommentierten oder hinzugefügten Zeilen mit ,,beaune" kommentiert. Mit diesen Erweiterungen lässt sich weekprofile perfekt als Eingabemaske für eine Heizungssteuerung verwenden, behält aber auch alle vorhandenen Möglichkeiten, die man für eine szenenbasierte Einzelraumregelung o.ä. braucht. Aus meiner Sicht eine sinnvolle und kompatible Ergänzung des Moduls. Bin gespannt was Ihr dazu sagt, und ob meine Anregungen vielleicht sogar ins Einzug ins Repository finden ;-)
Neue Attribute:
- maxNumInterval: limitiert die Anzahl eingebbarer Zeitintervalle zwischen 1 und 10; Default: 0 (=unlimitiert)
- fixedProfileSettings: Verhindert das Hinzufügen und Löschen von Profilen über die Oberfläche. Die Option ist sinnvoll in Verbindung mit Geräten, die über eine feste Anzahl und Typen von Profile verfügen, z.B. Heizungen. Default: 0
- hideTemperatureSettings: Blendet die Temperatureinstellungen sowohl in der Übersicht aus auch beim Editieren aus, und trägt stattdessen automatisch ,,on" bzw. ,,off" als Temperaturwert ein. In der Übersicht werden die Off-Intervalle ausgeblendet.
Die Option ist sinnvoll in Verbindung mit Geräten, die globale Temperatureinstellungen unabhängig vom Intervall verwalten, und bei den Intervallen nur die on-Intervalle konfiguriert werden, z.B. bei Heizungen. Default: 0 - showLoadButton: Wenn auf 1 gesetzt, blendet FHEM einen zusätzlichen Button ein, bei dessen Aufruf das Event LOAD_FROM_DEVICE getriggert wird.
Die Option ist sinnvoll, wenn man direkt aus dem WeekProfile Control heraus ermöglichen will, vor dem Editieren Daten aus einem Gerät zu lesen. Das gewählte Profil wird im Event mit übertragen. Default: 0. - hideTransferButton: Wenn auf 1 gesetzt, wird der Button zum Transfer des gewählten Profils auf auswählbare FHEM-Devices ausgeblendet. Die Option ist sinnvoll, wenn direkt nach der Eingabe neuer Daten die weitere Verarbeitung ohne weitere User-Interaktion durchgeführt werden soll. Dies kann über Auswertung des Events WRITE_TO_DEVICE geschehen. Default: 0
- nolink: Wenn auf 1 gesetzt wird verhindert, dass der rechts neben dem Edit-Icon stehende Modulname ein Link ist (wie bei readingsGroups). Default: 0
- noheadings: Wenn auf 1 gesetzt wird verhindert, dass oberhalb des Controls nochmal der Modulname ausgegeben wird (wie bei readingsGroups). Default: 0
Neue Events:
- LOAD_FROM_DEVICE: wird aufgerufen, wenn der durch showLoadButton eingeblendete zusätzliche Button betätigt wird. Das aktuell ausgewählte Profil wird mit übergeben.
- WRITE_TO_DEVICE: wird aufgerufen, nachdem neue Daten gespeichert wurden. Das aktuell ausgewählte Profil wird mit übergeben, so dass der Anwender per notify entscheiden kann, welche Geräte automatisch mit neuen Daten versorgt werden sollen.
Sieht viel aus, war im Grunde aber relativ einfach, und ist von der Implementierung her sehr überschaubar. Hab alle auskommentierten oder hinzugefügten Zeilen mit ,,beaune" kommentiert. Mit diesen Erweiterungen lässt sich weekprofile perfekt als Eingabemaske für ein spezifisches Gerät spezialisieren, und wird damit auch ,,kleinen" Anlagen gerecht, wo man wirklich nur die Heizung einstellen will und keine szenenbasierte Einzelraumregelung o.ä. braucht. Aus meiner Sicht eine sinnvolle Ergänzung des Moduls. Bin gespannt, ob sich jemand dafür interessiert, oder was Ihr noch verbessern würdet. Die Implementierung und zwei Screenshots sind hier angehängt.
Hallo beaune,
finde deine Erweiterungen interessant und hilfreich.
Ich habe seit ein paar Monaten ebenfalls eine Vaillant Anlage und will die noch in FHEM integrieren.
Momentan habe ich überhaupt noch kein Ebus integriert. Deswegen wäre es für mich interessant wie genau du deine Vaillant integriert hast. Ein paar Stellen zum Einlesen reichen mir, bin bislang nur nicht dazu gekommen mich damit eingehender zu befassen.
Die Nutzung von weekprofile reduziert sich bei mir auf die Thermostatsteuerung mit HM Classic.
Deswegen werde ich deine Moduländerung erstmal auf Kompatibilität testen und melden wenn mir etwas auffallen sollte.
Gleich jetzt der Hinweis, dass die Umlaute in der Hilfe schon direkt im Modul falsch geschrieben sind und natürlich auch so dargestellt werden, z.B.
Mit dem Modul 'weekprofile' können mehrere Wochenprofile verwaltet und an unterschiedliche Geräte
übertragen werden. Aktuell wird folgende Hardware unterstützt:
.....
Generell würde ich mir wünschen, dass die Commandref etwas lesbarer gestaltet wird und die Einblendung der Hilftexte bei Auswahl eines Attributes mit angezeigt werden. Dieses hat sich m.M. nach inzwischen als Standard etabliert.
Aber das ist eher ein Wunsch in Richtung Risiko. ;)
An dieser Stelle ein großer Dank an Risiko für dieses Modul !!
Grüße,
Heiko
Zitat von: DS_Starter am 05 September 2021, 09:47:42
Generell würde ich mir wünschen, dass die Commandref etwas lesbarer gestaltet wird und die Einblendung der Hilftexte bei Auswahl eines Attributes mit angezeigt werden. Dieses hat sich m.M. nach inzwischen als Standard etabliert.
Ok. Muss ich mich mal damit beschäftigen. Noch keine Ahnung wie das geht...
Aber danke für den Hinweis
Zitat von: beaune am 02 September 2021, 10:35:35
Sieht viel aus, war im Grunde aber relativ einfach, und ist von der Implementierung her sehr überschaubar. Hab alle auskommentierten oder hinzugefügten Zeilen mit ,,beaune" kommentiert. Mit diesen Erweiterungen lässt sich weekprofile perfekt als Eingabemaske für ein spezifisches Gerät spezialisieren, und wird damit auch ,,kleinen" Anlagen gerecht, wo man wirklich nur die Heizung einstellen will und keine szenenbasierte Einzelraumregelung o.ä. braucht. Aus meiner Sicht eine sinnvolle Ergänzung des Moduls. Bin gespannt, ob sich jemand dafür interessiert, oder was Ihr noch verbessern würdet. Die Implementierung und zwei Screenshots sind hier angehängt.
Hallo beaune,
ich schaue es mir bei Gelegenheit an und wenn es mit in das Konzept passt, habe ich nichts gegen eine Aufnahme.
Risiko
Zitat von: Risiko am 05 September 2021, 18:59:30
Ok. Muss ich mich mal damit beschäftigen. Noch keine Ahnung wie das geht...
Aber danke für den Hinweis
Anbei die auf "id" umgestellte Fassung von beaune. Die kaputten Umlaute sind (hoffentlich) auch wieder ok, es wäre ggf. nett, wenn "jemand" sich dann noch die Mühe machen könnte, die noch fehlenden setter, getter und Attribute (in DE und EN) zu ergänzen. Bitte dazu einen Editor verwenden, der die Umlaute (und ggf. Zeilenumbrüche) nicht wieder kaputt macht (unter Wind.* z.B. notepad++).
Das beinhaltet keine Aussage, ob ich den Vorschlag jetzt gut finde oder nicht - dazu habe ich mir schlicht noch keine Meinung gebildet. Wollte nur "nichts wegwerfen", was schon da ist.
Allerdings finde ich die Zahl der Attribute ziemlich hoch und würde ggf. mal die Überlegung in den Raum werfen, ob es nicht einfacher wäre, diese "speziellen" Darstellungseinstell-Optionen einfach in ein "Einheitsattribut" zu packen und dann "option1=x option2=y bla=1" als Syntax (via parseParams) zu verwenden.
@Risiko:
Zwei Dinge schwirren mir noch im Kopf rum:
- zum einen hatte ich irgendwann abgespeichert, dass man FHEM neu starten muss, wenn man neue Clients erkennen lassen will. Wäre ggf. möglich, das im Rahmen der NotifyFn mit abzufangen;
- zum anderen ist das userAttr "weekprofile" ja (aus Sicht der commandref) eigentlich eines, das zu weekprofile gehört. Dazu müsste man aber den betreffenden "fremden Modul-Instanzen" mitteilen, dass die Hilfe aus weekprofile kommt. Da es nur einzelne Instanzen betrifft (und nicht alle), müsste für diese Fälle dann addToDevAttrList aufgerufen werden, siehe Link unten (erster commit, die Schleife war da aber schon da).
@DS_Starter:
Falls du DbLog auch auf "id'" umstellen willst (was ich v.a. für die globalen Attribute klasse fände!) hier der Link zu den patches, die bzgl. AutoShuttersControl dafür erforderlich sind - https://github.com/fhem/AutoShuttersControl/pull/96 (https://github.com/fhem/AutoShuttersControl/pull/96)
Vielen Dank schon mal für Euer Interesse!
@Risiko:
Wenn Du Fragen zu meinen Änderungsvorschlägen hast oder ich noch irgendwas zuliefern kann, sag einfach Bescheid! Vielleicht hast Du ja auch noch Ideen, wie man es noch besser machen kann. Ist ja nur ein erster Vorschlag, der allerdings auch praktisch schon im Einsatz ist und da ganz gut funktioniert.
@Beta-User:
Du hast Recht, es sind relativ viele neue Attribute. Ich hatte auch überlegt, das zusammenzufassen, mich am Ende aber dagegen entschieden, da viele der Erweiterungen auch für sich genommen Sinn machen und nicht zwingend in der Kombination nötig sind. Z.B. so etwas wie ,,nolink" oder ,,noheadings": Das hat wenig mit weekprofile zu tun und ist einfach analog zu Readingsgroup so gemacht, weil man es von da halt schon kennt. Ich fand es charmant, hier möglichst wenig Abhängigkeiten zu schaffen und den Code damit überschaubar zu halten. Aber das ist natürlich alles Geschmackssache.
Die fehlenden getter/setter/Attribute hab ich versucht zu ergänzen und hoffentlich nichts vergessen. Sonst sag nochmal Bescheid. Die neue Version ist beigefügt.
@DS_Starter:
Ich schreib mal ein paar Stichpunkte zum Thema eBus-Integration zusammen.
- Meine Heizungsanlage besteht aus Therme ecoTEC plus VC DE 206/5-5 R2 , Mischermodul VR61 für die Fußbodenheizung, Funk-Bedienterminal und Regler calorMATIC 470f und Funkaußenfühler VR21.
- Den eBUS hab ich über den eBus-Adapter 3 angekoppelt. Ich nutze dabei aktuell die WLAN-Option.
- Infos zum Adapter, Anschluß, Optionen usw. findest Du unter https://adapter.ebusd.eu/.
- Zur softwaremäßigen Integration braucht Du den eBUS-Dämon. Den findest Du nebst Doku und Installationsanleitung hier: https://github.com/john30/ebusd. Damit kannst Du dann schon mal über die Kommandozeile Parameter lesen und schreiben.
- Im Git findest Du auch csv-Dateien, die quasi Gerätebeschreibungsdateien der eBUS-Geräte darstellen. Die werden zwar automatisch geladen, es empfiehlt sich dennoch, sie lokal abzulegen, falls das Internet mal nicht geht, oder falls man was ändern/ergänzen will, was nicht ganz abwegig ist.
- Zur FHEM-Integration gibt es Wiki-Dokus, die allerdings nicht sehr übersichtlich und teilweise veraltet sind. Da muß man dann sich dann doch manchmal durch aktuelle Threads wühlen, was manchmal etwas mühsam ist, weil die einfach schon sehr lang sind.
- Es gibt hier mehrere Integrationswege (ECMD, GAEBUS, MQTT, siehe https://wiki.fhem.de/wiki/EBUS), wobei ich mich persönlich nur mit MQTT beschäftigt habe, weil ich glaube, dass dieser Weg am wenigsten spezifisch ist und auch am besten gepflegt werden kann, weil er einfach standardisiert ist. Ganz intuitiv ist der Anfang dann aber leider doch nicht.
- Zum MQTT-Weg liest Du am besten hier nach: https://wiki.fhem.de/wiki/EBUS-MQTT2. Auch das ist nicht mehr zu 100% aktuell. Wichtig ist hier das Grundverständnis, dass man ein eBUS-Bridge-Device braucht, dass dann die Nachrichten sortiert und weiteren MQTT-Devices zuordnet, die dann stellvertretend für die oben genannten Komponenten der Heizung sind. Und dass man das Autocreate zunächst abschalten muß, bis man das Bridge Device hat. Um das zu installieren gibt es ein attrTemplate, das allerdings nur so ähnlich heißt wie in der Doku beschrieben, irgendwas mit eBUS und Splitter.
- Anschließend kannst Du noch weitere Templates installieren, die allerdings meiner Meinung nach allesamt nicht wirklich für den produktiven Einsatz brauchbar sind. Da ist dann auch so etwas wie ein Vorläufer des weekprofiles dabei, aber wirklich noch weit weg von dem, was wir hier jetzt vorliegen haben. Man kann da mal rein schauen und kann da Anregungen und Infos rausziehen, die man braucht, um sich eine eigene Lösung zu bauen. Aber mehr als Beispielcharakter hat das nicht, funktioniert teilweise auch nicht oder wirft Warnings.
- Was Du nur verstehen mußt ist, wie lesen und schreiben funktioniert, also wie die MQTT-Topics aufgebaut sind. Vieles wird schon automatisch angelegt, aber zumindest im aktuellen Stand muß man dann doch schon mal Hand anlegen, unsinniges löschen, Dinge umbenennen usw. Da gibt's zwar auch Ansätze, alles weiter zu automatisieren (https://forum.fhem.de/index.php/topic,122048.0.html) , aber ich stehe dem etwas skeptisch gegenüber. Das Ganze ist schon recht komplex, und bis zu einem gewissen Grade muß man einfach einsteigen, um es zu verstehen und damit auch Anpassungen durchführen zu können. Heizungsanlagen sind halt auch immer sehr individuell, insbesondere was man wirklich ständig sehen oder einstellen können will/muß. Da läßt sich nicht alles generisch lösen. Eine etwas geschlossenere Doku würde da schon helfen.
So viel fürs Erste... Ich füge als Anregung noch einen Screenshot bei, wie sich die Heizung bei mir im Dashboard auf nem iPhone darstellt, sehr kompakt, aber das Wichtige ist da, natürlich mit gepatchtem weekprofile ;) . Wenn Du irgendwo weitere Details brauchst frag einfach nach.
Dank zurück für's Erweitern/Ergänzen.
Das mit den settern (Event) finde ich spontan inhaltlich nicht so gelungen - der Event ist aus meiner Perspektive nur "Nebensache".
"parseParams" hatte ich deswegen genannt, weil es ermöglicht, eine beliebige (Teil-) Auswahl zu setzen und dabei keine bestimmte Reihenfolge einhalten zu müssen. Daher ist das ideal, wenn man einen ganzen Stall von "ein/aus"-Möglichkeiten hat, die man beliebig kombinieren kann, das ganze an sich aber eher selten gebraucht wird. Es macht dann ggf. aber Sinn, eine Verifizierung durchzuführen um dem User gleich beim Setzen mitzuteilen, wenn er was falsch geschrieben hat usw.. (Wer RHASSPY kennt: da habe ich das relativ exzessiv so gemacht, code ist in contrib zu finden).
Bzgl. ebus und Heizungen: Das ist hier m.E. ziemlich OT, und beaune hat wohl auch recht, wenn er darauf hinweist, dass das ganze (teilweise) ziemlich Kraut und Rüben ist. Das liegt aber - soweit ich das beurteilen kann - v.a. daran, dass die Konfiguration auf der ebus-Seite (csv's) irgendwie (je nachdem, wer welches Gerät mit welchem Kenntnisstand hat) "unfertig" ist. Ich kann nur den Versuch anbieten, das ganze auf der FHEM-Seite einigermaßen komfortabel bedien- und auswertbar zu machen, was unerfreulich viel Coding braucht...
Aber auch da: je mehr sich damit auseinandersetzen, desto besser ist am Ende das Ergebnis für alle....
Zitat von: Beta-User am 06 September 2021, 10:07:41
@Risiko:
Zwei Dinge schwirren mir noch im Kopf rum:
- zum einen hatte ich irgendwann abgespeichert, dass man FHEM neu starten muss, wenn man neue Clients erkennen lassen will. Wäre ggf. möglich, das im Rahmen der NotifyFn mit abzufangen;
Das ist eigentlich schon drin. ???
Zitat von: Beta-User am 06 September 2021, 10:07:41
- zum anderen ist das userAttr "weekprofile" ja (aus Sicht der commandref) eigentlich eines, das zu weekprofile gehört. Dazu müsste man aber den betreffenden "fremden Modul-Instanzen" mitteilen, dass die Hilfe aus weekprofile kommt. Da es nur einzelne Instanzen betrifft (und nicht alle), müsste für diese Fälle dann addToDevAttrList aufgerufen werden, siehe Link unten (erster commit, die Schleife war da aber schon da).
Kommt mit auf die ToDo-Liste ;) Danke dafür
Zitat von: Risiko am 06 September 2021, 19:18:09
Das ist eigentlich schon drin. ???
Ups, sorry, hatte ich wohl nicht aus meinem internen Speicher gelöscht ::) ...
Zitat
Kommt mit auf die ToDo-Liste ;) Danke dafür
Gerne!
Zitat von: Beta-User am 06 September 2021, 10:07:41
Anbei die auf "id" umgestellte Fassung von beaune. Die kaputten Umlaute sind (hoffentlich) auch wieder ok, es wäre ggf. nett, wenn "jemand" sich dann noch die Mühe machen könnte, die noch fehlenden setter, getter und Attribute (in DE und EN) zu ergänzen. Bitte dazu einen Editor verwenden, der die Umlaute (und ggf. Zeilenumbrüche) nicht wieder kaputt macht (unter Wind.* z.B. notepad++).
Habe heute die Version mit der Umstellung auf id's eingecheckt. Nochmal Danke.
@beaune, vielen Dank für die ausführliche Auflistung !! 8)
Ich nehme mir es mal für den Herbst vor und komme gerne auf dich und dein Wissen zurück.
Grüße,
Heiko
Zitat von: beaune am 06 September 2021, 14:54:43
Vielen Dank schon mal für Euer Interesse!
@Risiko:
Wenn Du Fragen zu meinen Änderungsvorschlägen hast oder ich noch irgendwas zuliefern kann, sag einfach Bescheid! Vielleicht hast Du ja auch noch Ideen, wie man es noch besser machen kann. Ist ja nur ein erster Vorschlag, der allerdings auch praktisch schon im Einsatz ist und da ganz gut funktioniert.
@beaune
Danke für die Erweiterung und die Beschreibung. Ich habe mich heute ein wenig damit beschäftigt.
Wenn ich es richtig verstehe, möchtest du nur Zeitpläne für Heizung ist AN verwalten. Zeitpläne für AUS und Temperaturen gibt es nicht. Die Keywords ON,OFF sind unter der Haube auch Temperaturen.
Das ist meiner Meinung nach schon eine gewaltige Vergewaltigung des Moduls! Viele Funktionen gehen dann nicht (auch wenn du die ggf. auch gar nicht verwendest). Wäre hier weekdaytimer oder was Anderes nicht besser?
Ich muss mich noch weiter damit beschäftigen, um entscheiden zu können, ob eine Integration wirklich Sinn macht. Wenn ja, wäre meiner Meinung nach ein konkreter Modus sinnvoll. Also wenn man explizit diesen Modus ohne Temperaturen verwendet, dann würden auch einige Attribute, Befehle, etc. wegfallen. Sonst gibt es viele ungültige Kombinationsmöglichkeiten\Varianten.
Was machst du denn eigentlich mit den Zeitplänen in weekprofile - nur visualisieren?
Du schreibst, die "Temperaturen werden Zentral verwaltet". Das verstehe ich leider nicht. Wäre es denn nicht sinnvoll, diese Temperaturen mit einstellen zu können? Wie\wer stellt diese Temperatur denn ein?
Die Anzahl der neuen Attribute halte ich auch für hoch. Die Bündelung zusammengehöriger Attribute (bspw. Visualisierungsoptionen) in ein Attribut, halte ich auch für sinnvoll.
Risiko
Vorab mal: Danke für's Einchecken und das feedback!
Um Wiederholungen zu vermeiden: Betr. das Anliegen von beaune hatten wir an einer Stelle, von der ich nicht weiß, ob die hier schon explizit verlinkt war, schon eine etwas ausgiebigere Diskussion: https://forum.fhem.de/index.php/topic,122120.0.html
Vielleicht wird dann klarer, auf welche Weise beaune weekprofile nutzen will. Und evtl. ist das auch für DS_Starter ein guter Einstieg (zusammen mit dem "Weishaupt-MQTT2"-Thread)
(Das war ausdrücklich kein Votum in irgendeine Richtung!)
(Falls Beispiele zur parseParams-Verwendung im Zusammenhang mit der Auswertung von Attributen gewünscht ist: RHASSPY (in contrib) macht das recht exzessiv; ggf. einfach fragen oder die Beispiele in der commandref/help ansehen (da reicht es, das Modul ins Modulverzeichnis zu ziehen...)
Hallo,
Danke schon mal dass Du Dir das anschaust. ich möchte kurz zu ein paar Punkten Stellung nehmen:
Zitat von: Risiko am 12 September 2021, 20:40:30
Was machst du denn eigentlich mit den Zeitplänen in weekprofile - nur visualisieren?
Du schreibst, die "Temperaturen werden Zentral verwaltet". Das verstehe ich leider nicht. Wäre es denn nicht sinnvoll, diese Temperaturen mit einstellen zu können? Wie\wer stellt diese Temperatur denn ein?
Das ist glaube ich der zentrale Verständnispunkt: Es gibt eine Heizungssteuerung, die ihre Aufgabe auch zukünftig haben soll. Nicht fhem steuert, sondern die Heizungssteuerung. Fhem dient zur alternativen Eingabe der Konfiguration, und zur Visualisierung. Fällt fhem oder der eBUS-Adapter aus, läuft trotzdem alles weiter.
Das Vorgehen ist so:
- Man konfiguriert in einer Heizungssteuerung einen Sollwert für die Tagestemperatur und einen für die Nachttemperatur (Absenkbetrieb).
- Anschließend konfiguriert man den Wochen-Zeitplan, d.h. man gibt an, wann kein Absenkbetrieb sein soll.
- Manchmal kann man dann noch Datum-Intervalle für Ausnahmen vorgeben, aber das hat dann nichts mehr mit einem regelmäßigen Wochenprofil zu tun und ist hier OT.
Und daraus resultieren dann eben einige Anforderungen:
- Man konfiguriert nur die ON-Intervalle. Die OFF-Intervalle sind dann automatisch alles dazwischen.
- Die Intervallanzahl ist durch die Heizungssteuerung begrenzt.
- Innerhalb des Wochenplans braucht man keine Temperaturangabe
Zitat von: Risiko am 12 September 2021, 20:40:30
Wenn ich es richtig verstehe, möchtest du nur Zeitpläne für Heizung ist AN verwalten. Zeitpläne für AUS und Temperaturen gibt es nicht. Die Keywords ON,OFF sind unter der Haube auch Temperaturen.
Ja genau. Wichtig war mir hier insbesondere, dass die JSON-Struktur gleich bleibt. Klar hätte man anstatt ON und OFF dort auch die an anderer Stelle konfigurierten Temperaturwerte eintragen können. Würde aber heißen, dass man immer dann, wenn jemand den Tages- oder Nachtsollwert ändert, alle Wochenprofile nachführen muß. Das schien mir nicht gut zu sein. Da Du aber an anderer Stelle schon erlaubst, dass Temperaturwerte zu einem Namen gemappt werden können, bin ich darauf gekommen, dann eben direkt die Namen ins JSON einzutragen. Das kann man natürlich auch anders lösen, indem man z.B. 0° als OFF und 100° als ON definiert. Mir schien es so das Konsequenteste zu sein, aber vielleicht läßt sich das auch geschickter lösen oder hat Nebeneffekte, die ich nicht gesehen habe.
Zitat von: Risiko am 12 September 2021, 20:40:30
Ich muss mich noch weiter damit beschäftigen, um entscheiden zu können, ob eine Integration wirklich Sinn macht. Wenn ja, wäre meiner Meinung nach ein konkreter Modus sinnvoll. Also wenn man explizit diesen Modus ohne Temperaturen verwendet, dann würden auch einige Attribute, Befehle, etc. wegfallen. Sonst gibt es viele ungültige Kombinationsmöglichkeiten\Varianten.
Die Bedenken kann ich gut nachvollziehen. Ich habe mich deswegen zunächst gegen einen dedizierten Modus entschieden, weil mir schien, dass manches eben nicht spezifisch für den Einsatz mit einer Heizungssteuerung ist, sondern auch in anderem Umfeld sinnvoll sein könnte, und die Vermischung mehrerer unabhängiger Themen das Verständnis der Ergänzungsvorschläge erschweren könnte. z.B.
- nolink, noheadings: hat gar nichts mit dem Wochenprofil selbst zu tun, sondern ist lediglich ein UI-Thema, angelehnt an die entsprechenden Attribute einer readingsGroup.
- maxNumInterval: auch bei anderen Geräten mag es Begrenzungen geben, wieviele Intervalle man verwalten kann/möchte. Dennoch muß dann nicht zwingend eine konstante Anzahl an eingebbaren Intervallen vorliegen (fixedProfileSettings).
Aber das ist sicher Geschmackssache. Ich kann auch gut mit einem dedizierten Modus leben. Oder vielleicht ist auch parseParams ne gute Idee, das hab ich mir bislang noch gar nicht angeschaut.
Bin gespannt zu welche Ergebnis Du kommst.
Zitat von: beaune am 13 September 2021, 16:57:03
Das ist glaube ich der zentrale Verständnispunkt: Es gibt eine Heizungssteuerung, die ihre Aufgabe auch zukünftig haben soll. Nicht fhem steuert, sondern die Heizungssteuerung. Fhem dient zur alternativen Eingabe der Konfiguration, und zur Visualisierung. Fällt fhem oder der eBUS-Adapter aus, läuft trotzdem alles weiter.
Unabhängig von allem anderen nochmal der Hinweis, der anscheinend bisher nicht bei dir angekommen ist: Dass die Steuerung dann mit den übertragenen Werten autark auf der Hardware läuft, ist kein "ebus"-Alleinstellungsmerkmal. Das ist bei MAX! und CUL_HM-Thermostaten so, und auch manche zigbee-Geräte sowie einige ZWave-Typen kennen sowas (und der MQTT2-zigbee-Code dazu kann das auch entsprechend codiert an die Geräte weitergeben).
Der einzige Unterschied ist der, dass man an Ebus eben nur An (= setpointHeating im ZWave-Spreech) bzw. Aus (=setpointEnergySaveHeating (? oder so ähnlich) sendet.
Auch das ist nicht komplett neu, sowas kann man - neben der "echten" Teperaturweitergabe auch dann via WeekdayTimer - erreichen (muss da aber ggf. eben im WDT mappen).
Effektiv ist es also auch bei Ebus nicht an und aus, was übermittelt wird, sondern eben nur die Grenzzeiten für "Temperaturwert 1" bzw. "Temperaturwert 2". Im Ebus-Code ist der Grenzwert (default) bei 20°, also könntest du auch on- und off-Value entsprechend in weekprofile setzen (?), das wäre in der Anzeige dann vermutlich dann nahe dem, was du dir vorstellst.
Bzgl. der "Modus"-Frage noch folgende spontanen Gedanken:
Wenn man parseParams auf zwei Attribute loslassen würde, könnte man das eine für "allgemein sinnvolle Tweaks am UI" verwenden, und mit dem anderen die "Modusumstellung" machen.
Generell finde ich persönlich weiter die Vorstellung "ein Endgerät, eine UI" verquer bzw. schlecht mit dem "verwalte und verteile zentral eine Vielzahl von Profilen (@Topics: für eine Vielzahl von Endgeräten)"-Prinzip vereinbar und glaube, dass das für die meisten FHEM-User eher verwirrend sein wird, wenn man das aufweicht.
Zitat von: beaune am 13 September 2021, 16:57:03
Hallo beaune,
danke für die Ausführungen. Vieles davon hattest du bereits geschrieben.
Wie Beta-User richtig sagt, ist da bei ebus bzw. deiner Heizungssteuerung nicht anders. Auch andere Systeme laufen ohne FHEM autark. Man nutz FHEM zur Visualisierung und zur Verstellung der Parameter\Eigenschaften
Was ich leider immer noch nicht verstehe, wieso macht man bei ebus das verstellen der Solltemperatur mittels FHEM nicht möglich?
Dann würde sich gegenüber den anderen Systemen vom Prinzip nichts unterscheiden und man müsste bei weekprofile nicht diesen Sonderweg ohne Temperaturen gehen.
Soll heißen, wenn es ein Modul für ebus gäbe (oder besser für die Heizungssteuerung) , was die Zeitpläne + Solltemperatur (auch wenn Solltemperatur nur AN\AUS oder feste Temperaturwerte sind) akzeptiert, dann würde es prima passen. Auch "Topics", "master device", etc. könnte man dann einfach verwenden.
Risiko
Zitat von: Beta-User am 13 September 2021, 17:23:51
Generell finde ich persönlich weiter die Vorstellung "ein Endgerät, eine UI" verquer bzw. schlecht mit dem "verwalte und verteile zentral eine Vielzahl von Profilen (@Topics: für eine Vielzahl von Endgeräten)"-Prinzip vereinbar und glaube, dass das für die meisten FHEM-User eher verwirrend sein wird, wenn man das aufweicht.
Verstehe ich leider gerade nicht (könnte an der Uhrzeit liegen ;)).
Könntest du es ggf. anders formulieren?
Zitat von: Risiko am 14 September 2021, 22:19:59
wieso macht man bei ebus das verstellen der Solltemperatur mittels FHEM nicht möglich?
Na ja, zum einen KANN man das afaik prinzipiell schon von FHEM aus (für verschiedenste Temperaturvorgaben), das ist nur eben eine ganz andere Baustelle, die nichts mit Temperaturprofilen (oder Tag/Nacht-ON/OFF-Profilen) zu tun hat. Wenn man da zeitabhängig was machen wollte (was mir aber nicht sinnvoll erscheint), dann wäre eher WeekdayTimer (iVm. weekprofile) ein geeignetes Zwischendevice.
Zitat von: Risiko am 14 September 2021, 22:23:52
Verstehe ich leider gerade nicht (könnte an der Uhrzeit liegen ;) ).
Könntest du es ggf. anders formulieren?
Schwierig, da ich selbst weekprofile mit Topics im Einsatz habe. Dabei reicht mit eine weekprofile-Instanz, um alle (Hardware-) Zielgeräte zentral zu verwalten, ganz egal, ob das CUL_HM-Instanzen sind oder ZWave (vermittelt durch WeekdayTimer). Nicht alle Zielgeräte kennen alle Topics. Hätte ich ebus im Einsatz, würde ich einfach die betreffenden Profile* noch in die zentrale weekprofile-Instanz mit reinnehmen, um dann alles zentral umschalten zu können.
*Für ebus sehe ich dann mehrere MQTT2_DEVICE-Instanzen für jedes (Teil-) Gerät, das für sich ein Profil intern (auf der Hardware) verwalten kann, also für das zentrale Heizgerät, die Warmwasser-Umwälzpumpe, etc pp (bei der Weishaupt waren das 3-4 Instanzen). Damit würden dann die Zeiträume für das zentrale Heizgerät dann immer auch passend zu den Heizprofil-Anforderungen der Thermostate passen...
beaune scheint eher sowas haben zu wollen:
- "weekprofile-Instanz A" (mit genau einem Profil) -> ein Endgerät A,
- "weekprofile-Instanz B" (mit genau einem Profil) -> ein Endgerät B.
Hoffe, das ist jetzt etwas besser verständlich?
Zitat von: Risiko am 14 September 2021, 22:19:59
Was ich leider immer noch nicht verstehe, wieso macht man bei ebus das verstellen der Solltemperatur mittels FHEM nicht möglich?
Dann würde sich gegenüber den anderen Systemen vom Prinzip nichts unterscheiden und man müsste bei weekprofile nicht diesen Sonderweg ohne Temperaturen gehen.
Mein Punkt ist der:
- Natürlich kann man die Sollwerte per fhem verstellen. Das mache ich auch. Ist aber eine ganz andere Stelle, also aus eBUS-Sicht andere Variablen.
- Man könnte die Sollwerte in der UI darstellen. Allerdings "passt" die Eingabemöglichkeit nicht zu dem, was die Heizungssteuerung speichern kann. Es gibt dort einfach keine Möglichkeit, jedem Intervall einen individuellen Temperaturwert mitzugeben. Würde man die Eingabemöglichkeit anbieten, müßte man die eingegebenen Werte spätestens bei der Übertragung zur Heizungssteuerung verwerfen bzw sich für einen (welchen?) davon entscheiden, wenn der User verschiedene Werte für verschiedene Intervalle eingestellt hat.
- Ich fänd es aber blöd Dinge einstellbar anzuzeigen, die man im Gerät faktisch gar nicht einstellen kann. Das verwirrt und braucht einfach nur Platz in der Darstellung.
- Um aber hier die Unterschiede zu anderen Geräten nicht zu groß zu machen, war meine Idee ja, nur die Anzeige zu beeinflussen, die Speicherstruktur aber unverändert zu lassen. Bis eben auf die Tatsache, dass ich Bezeichner anstatt Temperaturen speichere, was man ja auch anders lösen könnte.
Zitat von: Beta-User am 15 September 2021, 10:04:29
beaune scheint eher sowas haben zu wollen:
- "weekprofile-Instanz A" (mit genau einem Profil) -> ein Endgerät A,
- "weekprofile-Instanz B" (mit genau einem Profil) -> ein Endgerät B.
Ne das hab ich nicht gemeint (siehe Screenshot aus früherem Post). Ich nutze genau eine weekprofile-Instanz. Als Profile nutze ich aber keine Teilgeräte wie Brenner, Pumpe usw., sondern die logischen Heizkreise. Das sind bei mir: Fußbodenheizung, konventionelle Heizkörper und Warmwasser. Genau für die kann man in der Heizungssteuerung Sollwerte und Wochenprofile hinterlegen, und das wollte ich analog in fhem darstellen, also Auswahl des Heizkreises über die Combobox des weekprofiles.
Zitat von: Beta-User am 15 September 2021, 10:04:29
Dabei reicht mit eine weekprofile-Instanz, um alle (Hardware-) Zielgeräte zentral zu verwalten, ganz egal, ob das CUL_HM-Instanzen sind oder ZWave (vermittelt durch WeekdayTimer). Nicht alle Zielgeräte kennen alle Topics. Hätte ich ebus im Einsatz, würde ich einfach die betreffenden Profile* noch in die zentrale weekprofile-Instanz mit reinnehmen, um dann alles zentral umschalten zu können.
*Für ebus sehe ich dann mehrere MQTT2_DEVICE-Instanzen für jedes (Teil-) Gerät, das für sich ein Profil intern (auf der Hardware) verwalten kann, also für das zentrale Heizgerät, die Warmwasser-Umwälzpumpe, etc pp (bei der Weishaupt waren das 3-4 Instanzen). Damit würden dann die Zeiträume für das zentrale Heizgerät dann immer auch passend zu den Heizprofil-Anforderungen der Thermostate passen...
Joh, so oder so ähnlich meinte ich es auch.
Zitat von: beaune am 15 September 2021, 12:09:07
Genau für die kann man in der Heizungssteuerung Sollwerte und Wochenprofile hinterlegen, und das wollte ich analog in fhem darstellen, also Auswahl des Heizkreises über die Combobox des weekprofiles.
Ja, aber die Sollwerte hast du doch in weekprofile entfernt.
Wäre es nicht richtiger für die logischen Heizkreise ein entsprechendes Device\Modul zu haben?
Zitat von: beaune am 15 September 2021, 12:02:06
- Natürlich kann man die Sollwerte per fhem verstellen. Das mache ich auch. Ist aber eine ganz andere Stelle, also aus eBUS-Sicht andere Variablen.
Liegt da nicht das Problem bzw. sollte man sich da nicht was anderes einfallen lassen? Kann ich aber nicht wirklich beurteilen, kenne das ebus System nicht. Aber auch Beta-User schlägt dies ja vor.
- Man könnte die Sollwerte in der UI darstellen. Allerdings "passt" die Eingabemöglichkeit nicht zu dem, was die Heizungssteuerung speichern kann. Es gibt dort einfach keine Möglichkeit, jedem Intervall einen individuellen Temperaturwert mitzugeben. Würde man die Eingabemöglichkeit anbieten, müßte man die eingegebenen Werte spätestens bei der Übertragung zur Heizungssteuerung verwerfen bzw sich für einen (welchen?) davon entscheiden, wenn der User verschiedene Werte für verschiedene Intervalle eingestellt hat.
Verstehe ich leider nicht wirklich. Wenn man die Solltemperatur prinzipiell ändern kann, dann kann man doch für eine Zeitspanne A die Solltemperatur auf X stellen und für eine Zeitspanne B auf Y. Jetzt muss nur noch festgelegt werden, wer dies macht (glaube, das geht mit weekdaytimer). Weekdaytimer und weekprofile arbeiten bereits zusammen.
- Ich fänd es aber blöd Dinge einstellbar anzuzeigen, die man im Gerät faktisch gar nicht einstellen kann. Das verwirrt und braucht einfach nur Platz in der Darstellung.
Das verstehe ich, aber man könnte ja auch die einstellbaren Werte begrenzen (geht übrigens schon).
- Um aber hier die Unterschiede zu anderen Geräten nicht zu groß zu machen, war meine Idee ja, nur die Anzeige zu beeinflussen, die Speicherstruktur aber unverändert zu lassen. Bis eben auf die Tatsache, dass ich Bezeichner anstatt Temperaturen speichere, was man ja auch anders lösen könnte.
Das passt eben nicht zur Philosophie. Es werden die Temperaturen gespeichert und durch tempMap kann man diese zur Keywords mappen. Bein Übertragen kann man festlegen, ob man die Werte oder die Keywords an ein Device sendet.
Ich versuchs nochmal anders zu erklären.
- Die Heizungssteuerung kennt täglich drei Intervalle ("ON"), in denen die Tagessolltemperatur gilt.
- Zwischen diesen 3 Intervallen sowie davor und danach gilt die Nachtsollwerttemperatur.
- Würde man das konventionell im weekprofile darstellen, müßte man täglich 7 Intervalle anzeigen, zu denen man jeweils auch einen Temperaturwert angeben könnte. Pro Woche also 49 Temperaturwerte.
- Die Heizungssteuerung kennt aber nur genau 2 Werte (Soll Tag und Soll Nacht). Mehr kennt sie einfach nicht und kann auch nicht mehr speichern.
Würde man die 49 Einstellmöglichkeiten zulassen, müßte man aus den 49 Werten die "richtigen" 2 ermitteln (z.B. erster Wert am Montag ist Nacht-Soll, zweiter Wert ist Tag-Soll), und diese dann in die entsprechenden Readings eintragen. Aber dann müßte man konsequenterweise an den anderen Stellen andere Eingaben verhindern, bzw. den zulässigen Wert auf genau diese beiden einschränken. Denn was sollte fhem tun, wenn man jetzt im dritten Intervall eine andere Temperatur einstellt, als die im ersten Intervall? Könnte man nur verwerfen. Das wäre für mein Empfinden eine ziemlich dynamische und auch nicht wirklich intuitive Auswertung, die es aktuell nicht gibt.
Alternativ könnte man die Temperatureingabe im weekprofile-Editor optional verhindern und nur anzeigen. Dann könnte man die beiden anderswo eingestellten Wert im Hintergrund als Speicherwert nehmen. Geht, hätte aber den Nachteil, dass man sämtliche gespeicherten Profile immer dann automatisch abändern müßte, wenn einer der beiden Sollwerte geändert wird. Das wäre dann irgendwie zu lösen, gibt es so heute ja auch nicht. Und ich finde es zumindest für die Übersichts-Darstellung des weekprofile auch nicht glücklich, wenn da immer wieder derselbe Temperaturwert steht. Das kostet Platz, bietet aber keine Information. Die Heizungssteuerung beschränkt sich darauf, nur die On-Intervalle darzustellen, und davon auch nur die konfigurierten. Das ist sehr kompakt, enthält aber dieselben Informationen. Deshalb der Ansatz, die Darstellung optinal auf die konfigurierten ON-Intervalle ohne Temperaturangabe einzuschränken. Ist aber auch unabhängig davon, was man jetzt wirklich speichert.
Die Tatsache, dass man in der Heizungssteuerung die beiden Sollwerte außerhalb der Zeitintervalle einstellt, kann man beklagen, macht irgendwo aber auch Sinn. Zumindest der Tagessollwert ist wahrscheinlich der Parameter, den man am häufigsten ändert, und der daher auch sehr prominent ist (bei Vaillant: einfach am Rädchen drehen). Dementsprechend prominent wünsche ich es mir dann eben auch in fhem, und nicht versteckt in einem Wochenprofil, dass wahrscheinlich eher selten geändert wird.
Ist es jetzt klarer geworden?
Vielleicht mal etwas anders betrachtet... Ich bin jetzt mal im Schnelldurchlauf durch die Änderungsvorschläge am .pm-Code.
Eigentlich sind es "nur" zwei Themenkreise:
Dass es sehr viele Attribute/Einstellmöglichkeiten sind, die man aber meinem Eindruck nach wirklich relativ einfach in weniger Attributen (eigentlich: einem einzigen?) untergebracht werden könnten. Alles, was da an Schlüsselwort drinsteht, ist aktiv, alles andere aus der "Zusatzliste" nicht:
attr <wp> uiTweaks fixedNumInterval fixedProfileSetting hideTransferButton
Dann bräuchte man das ganze nur nach $me->{helper} schieben (was da ist mit Wert 1, der Rest nicht), und könnte/müsste dann halt durch direkten Hash-Zugriff abfragen (defined $me->{helper} && defined $me->{helper}->{<tweak>}).
Zum anderen scheint mir weekprofile grundsätzlich etwas sehr schweigsam zu sein, was seine eigenen Aktivitäten angeht. Die (aus dem Code übernommene) konkrete Lösung über den DoTrigger finde ich nicht so gelungen, aber was spricht dagegen, alle "Aktionen" (triggernd) in ein (einziges) Reading zu schreiben und dann noch etwas mehr Info reinzupacken?
Also statt
DoTrigger($me,"WRITE_TO_DEVICE $name",1);
dann:
readingsSingleUpdate($me, 'lastAction', "WRITE_TO_DEVICE $name $topic:$profile",1);
Evtl. müßte man sich anschauen, ob bzw. wie lange (im Sinne von $feature_level) es sinnvoll ist, die alten Events zusätzlich zu generieren, und wie man das so gestaltet, dass es dann auch zusammenpaßt; evtl. wäre es eine Idee, das "restore"-Event auch da reinzupacken?
Dem Gefühl nach wäre es so oder so sinnvoll, sich den 2. Punkt mal anzuschauen, und für den ersten Punkt müßte man halt entscheiden, ob man das haben will. Aber da der Eingriff in den Code überschaubar ist...
Das ganze ändert ja soweit erkennbar nichts an der Art und Weise, wie weekprofile intern seine Daten speichert, oder übersehe ich was?
(Ich finde diese Art der Bedienung immer noch "eigen", aber das muss ja nichts heißen, "there's more than...".)
@Risiko: Zwischendurch mal noch ganz was anderes...
Wir haben vermutlich eine etwas größere Baustelle: https://forum.fhem.de/index.php/topic,118985.msg1134287.html#msg1134287. Dachte, ich mache einen Reparaturvorschlag dazu, aber das ist was größeres, wenn man nicht einfach an den betreffenden Stellen dann schlicht den korrekten package-Verweis davorknallen will. Außerdem habe ich irgendwie im Ohr, dass data::Dumper möglichst außerhalb von echtem debugging vermieden werden sollte, würde daher die JSON-Evaluierung auch eher anders notieren und das ausbauen. (muss nicht richtig sein).
Danke Beta-User für den Link.
Ist völlig an mir vorbei gegangen. Habs gefixt.
data::Dumper wird doch nur im Fehlerfall verwendet, um die Daten auszugeben und nicht zur JSON-Evaluierung selbst.
Zitat von: beaune am 17 September 2021, 12:37:50
Hallo beaune,
mir geht es nicht um den Aufwand und die größer der Änderung in weekprofile. Mir geht es um einen einheitlichen Ansatz, welcher hier meiner Meinung nach verletzt wird, welcher für alle mir bekannten Heizsysteme aber passt. Weekprofile wurde designed um Wochenprofile (Zeit + Temperatur) zu verwalten und diese einfach um\einstellen zu können. Ein Wochenprofil legt fest, welche Temperatur an welchem Tag zu welcher Uhrzeit vorliegen soll. Zum ein- bzw verstellen eines Profils schickt weekprofile das Profil an ein Modul, welches die Einstellung dann vornimmt (hier ist ja nicht gesagt, dass die Hardware z.B. Thermostat das Profil direkt annimmt\speichert).
Meiner Meinung nach fehlt eben hier an ein Modul, was das "Sonderverhalten" von ebus gegenüber einer Homatic, MAX, "normalen Thermostaten" ausgleicht.
Ich habe verstanden, dass dein System keine Verwaltung Zeit + Temperatur kann. ABER man kann Sollwerte einstellen. Bei Homatic oder MAX stellt das Gerät\Thermostat selbst den Sollwert entsprechend Zeitintervall ein. Das müsste hier meiner Meinung nach ein FHEM-Modul machen. Also eine Übersetzung von einem Wochenprofil in die ebus Logik.
Bei all mir bekannten Systemen kann man die Solltemperatur unabhängig vom Profil\Zeitplan einstellen. Das hat aber überhaupt nichts mit weekprofile zu tun.
Wenn es so nicht passt, dann ist weekprofile nicht das richtige Modul (auch wenn ggf. vieles verwendet werden könnte).
Wenn es eben nur um Zeitpläne geht, dann wäre meiner Meinung nach ein anderes Modul notwendig.
Risiko
Zitat von: Risiko am 18 September 2021, 20:39:23
Habs gefixt.
Danke!
Jetzt hoffen wir mal, dass die Änderung nicht "komische" Nebenwirkungen hat - das Problem ist, dass weekprofile damit möglicherweise die Funktionen aus 99_Utils überschrieben hatte und _andere_ Module/myUtils-Funktionen, die min/max haben wollen, plötzlich anders funktionieren, falls weekprofile das einzige Modul war, das an der Stelle so gestrickt war.
Zitat
data::Dumper wird doch nur im Fehlerfall verwendet, um die Daten auszugeben und nicht zur JSON-Evaluierung selbst.
Auch hier besteht m.E. nach wie vor das Problem, dass Data::Dumper durch dieses use in main verfügbar wird. also wenn überhaupt, sollte man vermutlich das use nur im Fehlerfall (in der konkreten Teilfunktion) absetzen. Muss aber zugeben, dass ich das auch nicht in der letzten Verästelung verstanden habe, vielleicht schaust du mal in https://forum.fhem.de/index.php/topic,109755.0.html rein. Da ist btw. auch noch "Storable" als Kritikpunkt zu finden.
Zitat von: Beta-User am 06 September 2021, 10:07:41
@Risiko:
- zum anderen ist das userAttr "weekprofile" ja (aus Sicht der commandref) eigentlich eines, das zu weekprofile gehört. Dazu müsste man aber den betreffenden "fremden Modul-Instanzen" mitteilen, dass die Hilfe aus weekprofile kommt. Da es nur einzelne Instanzen betrifft (und nicht alle), müsste für diese Fälle dann addToDevAttrList aufgerufen werden, siehe Link unten (erster commit, die Schleife war da aber schon da).
Habe das heute mal eingebaut. Das userattr wird auch angelegt, doch die Hilfe wird bei der Selektion von weekprfofile im fremden Device nicht angezeigt. Muss man da noch was beachten z.B. abweichende ID-Syntax? Finde zu dem Thema leider auch (mal wieder) keine Dokumentation.
Zitat von: Risiko am 19 September 2021, 20:50:34
Habe das heute mal eingebaut. Das userattr wird auch angelegt, doch die Hilfe wird bei der Selektion von weekprfofile im fremden Device nicht angezeigt. Muss man da noch was beachten z.B. abweichende ID-Syntax? Finde zu dem Thema leider auch (mal wieder) keine Dokumentation.
Na ja, die "Doku" sind nachfolgender Beitrag von Rudi und entsprechende Beispiele, auf die ja verlinkt war:
Zitat von: rudolfkoenig am 09 Juli 2021, 19:38:02
Das funktioniert mit data-pattern="o.*Cmd" (gerade getestet).
Wichtig: das ID der ersten <a> in der Hilfe dient als Modulbezeichner, d.h. die Hilfe sollte mit <a id="RandomTimer"></a> anfangen.
Um das zu wissen, muss FHEM wissen, wer dieses Attribut spendiert hat.
Ich habe jetzt addToDevAttrList und addToAttrList mit einem optionalen $module Parameter erweitert, damit kann man die Quelle spezifizieren.
Damit erscheinen in der Liste die FHEMWEB Attribute im FHEMWEB-Abschnitt (und nicht mehr unter "global userattr") und die Modul eigenen Attribute unter dem Abschnitt mit dem Modulnamen (nicht mehr "Module").
Letzteres kann man als Nachteil empfinden, weil damit die Modulattribute je nach Modulnamen ganz nach unten rutschen koennen.
Benötigt wird also ein entsprechender Abschnitt in der commandref, z.B.:
Zitat
<a id="weekprofile-attr-weekprofile"></a>
Helps weekprofile to identify it's client devices at the time a <i>restore_topi</i> command is issued.
Und in den (CUL_HM, MAX, ....-) Client-Instanzen muss das userattr eben über addToDevAttrList() nicht "allgemein" vohanden sein, sondern dort muss ergänzend das "weekprofile" (als Modulkenner) gesetzt sein, wie hier für AutoShuttersControl:
- addToDevAttrList( $shuttersDev, $attrib )
+ addToDevAttrList( $shuttersDev, $attrib, 'AutoShuttersControl' )
Ergo müßte in der Schleife für alle Clients dann eben sowas stehen:
addToDevAttrList( $clientDev, 'weekprofile', 'weekprofile' )
Danke. So ausführlich wäre es garnicht notwendig gewesen ;). Mein Fehler war der optionale Parameter in addToDevAttrList
Gerne. Hatte nur gesehen, dass der Link auf den commit irgendwie kaputt ist, und dann ist es in der Tat etwas schwierig nachzuvollziehen, an was es hängt bzw. wie das konkret aussehen muss...
Danke für's Aufgreifen der Anregung!
@Risiko
Ich nutze das Modul "weekprofile" schon länger, vielen Dank für Deine Arbeit!
Im Moment habe ich gerade den Überblick verloren welche Arten von Devices unterstützt werden.
Ich bin auf das Modul "HMCCU" (Raspberymatic) umgestiegen und nutze die Version 5.0 von HMCCU.
Die meisten Devices in FHEM (z.B. HM-CC-RT-DN) werden jetzt in Version 5.0 als TYPE=HMCCUCHN angelegt, beim Übertragen des profils (send to device) kommt die Fehlermeldung "Error device type not supported"
Ich habe mehrere Thermostate zu Heizgruppen in der CCU (Raspberymatic) zusammengefügt, daraus wird in FHEM ein Device mit dem TYPE=HMCCUDEV, allerdings ein VirtualDevices ccutype=HM-CC-VG-1.
Beim Übertragen des profils (send to device) kommt die Fehlermeldung: "KEL.Wohnen.Heizgruppe Invalid parameter specified. Valid parameters are HASH(0x55fe5e9b1328)"
Hier komme ich leider alleine nicht weiter und benötige eine Rat.
Hallo stolus,
ich habe von dieser Hardware keine Ahnung, bekomme das auch nicht mit und kann daher immer nur hinterher programmieren, wenn es auf der Seite (von Homatic, Raspberymatic, etc.) was Neues gibt. Dazu benötige ich natürlich die Informationen von euch Usern (list vom Device, Readings, Befehl zum setzen des Profils).
Leider hält sich der Homatic-Entwickler aus meiner Sicht nicht an irgend eine Konvention bzw. Logik (jedenfalls mir nicht ersichtlich).
Also wenn du mir die notwendigen Informationen zur Verfügung stellen kannst, dann kann ich mal schauen was sich machen lässt.
Risiko
@Risiko
HMCCU ist das Modul welches eine originale CCU2 / CCU3 (und Derivate wie Raspberrymatic) anspricht. Das ist eine eigene Homematic Zentrale die mit den Thermostaten kommuniziert. Es ist ein alternatives Setup mit eigenen Readings und Verhalten. Da wirst du kaum etwas aus der vorhandenen Homematic Implementierung übernehmen können. Bei der aktuellen Implementierung ist Fhem die Zentrale und Thermostate sind in Fhem angebunden. Bei einer CCU sind die Thermostate an die CCU angelernt und angebunden. Fhem kommuniziert dann mit der CCU
@stolus, welche Hardware nutzt du, hast du HOmematic IP im Einsatz?
@Risiko
ich habe drei Lists der Devices HM-CC-RT-DN (Homematic Heizkörperthermostat), HM-TC-IT-WM-W-EU (Homematic Wandthermostat) und von dem virtuellen Device HM-CC-VG angehängt.
Die ersten beiden sind jetzt Device vom TYPE=HMCCUCHN, ich vermute das dort der Unterschied liegt.
Hallo stolus,
HMCCUCHN kannte weekprofile noch nicht. Anbei eine Testversion, wo es hoffentlich geht.
Das HM-CC-VG-1 vom Typ HMCCUDEV sollte eigentlich funktionieren. Dann bräuchte ich mal ein Log von weekprofile mit verbose 4 beim Senden\Übertragen des Profils
Da es ein virtuelles Device ist, ist vermutlich der Befehlssyntax anders!? Wie ist denn der genaue Befehl zum Setzen eines Profils bei diesem virtuellen Device?
Kann man ccuif zur Erkennung eines virtuellen Devices nehmen?
Risiko
Hallo beaune, @all
dank deinen Hinweisen und natürlich der Vorleistung weiterer User im Umfeld eBus (Adapter) habe ich jetzt meine Vaillant in FHEM + Dashboard über MQTT2 eingebunden und kann schon ganz hervorragend auswerten und steuern.
Bekanntlich kommt der Appetit beim Essen und ich möchte das Thema bei mir weitertreiben.
Jetzt kommt weekprofile ins Spiel was ich schon lange hervorragend zur Steuerung meiner Homematic classic Steuerelemente nutze.
Für die Ansteuerung von MQTT2 wird zusätzlicher Code benötigt. Die jeweiligen MQTT Topics zum publishen sind mir inzwischen geläufig. Ich frage mich momentan nur wo ich weekprofile am besten mitteile welche Topics zum MQTT_DEVICE gesendet werden sollen.
Ich hatte vermutet es gibt so eine Art Attribut für setList, also etwa wenn eine Temp von 50°C eingestellt werden soll:
50 => 1_RadiatorenHK_Tagtemperatur_Soll 50
Das würde dann ein
set <MQTT2_DEVICE> 1_RadiatorenHK_Tagtemperatur_Soll 50
senden. Es gibt ja das Userattr weekprofile um die Verknüpfung des Zieldevices mit weekprofile vorzunehmen.
Im <MQTT2_DEVICE> würde dann ein setList die Übersetzung in das MQTT Topic vornehmen, z.B.:
1_RadiatorenHK_Tagtemperatur_Soll ebusd/700/z1DayTemp/set $EVTPART1
Habe ich etwas übersehen ? Wie implementiert du/ihr so etwas ?
Grüße,
Heiko
@DS_Starter: Du solltest dazu einen separaten Thread starten (oder dich in einen der bestehenden einklinken).
Kurzfassung:
- weekprofile (direkt) mit MQTT2_DEVICE ist dazu gedacht, das komplette Profil an das Zieldevice zu übertragen (Zusatzcode zur Umwandlung in das "passende" Profilformat ist erforderlich). Das Profil läuft dann aber unmittelbar auf dem Zieldevice.
- um "nur" zum richtigen Zeitpunkt eine neue Temperatur an das Gerät zu senden, bist du bei WeekdayTimer besser aufgehoben. Das kann auch über weekprofile "ad hoc" umgestellt werden, die Überwachung der Schaltzeiten übernimmt dann aber FHEM.
Was du hier zu wollen scheinst, ist imo weekprofile => WeekdayTimer => MQTT2_DEVICE => Zielgerät
PS: Willkommen an Bord!
Zitat@DS_Starter: Du solltest dazu einen separaten Thread starten (oder dich in einen der bestehenden einklinken).
Ja passt, ich dachte das wäre der passende. Aber dann schaue ich mal ob es einen besseren gibt.
Zitat
- weekprofile (direkt) mit MQTT2_DEVICE ist dazu gedacht, das komplette Profil an das Zieldevice zu übertragen (Zusatzcode zur Umwandlung in das "passende" Profilformat ist erforderlich). Das Profil läuft dann aber unmittelbar auf dem Zieldevice.
An so etwas dachte ich. In der Heizung wird für jeden Tag ein Verlaufsprofil gespeichert, z.B.:
ebusd_700_hwcTimer.Friday
{
"0": {"name": "from", "value": "05:30"},
"1": {"name": "to", "value": "22:00"},
"2": {"name": "from", "value": "-:-"},
"3": {"name": "to", "value": "-:-"},
"4": {"name": "from", "value": "-:-"},
"5": {"name": "to", "value": "-:-"}
}Jetzt muß man "nur" noch das MQTT Topic "ebusd/700/hwcTimer/set ..." an das FHEM MQTT2 Device senden um den Plan in der Heizung zu setzen. Die Stelle suche ich um weekprofile dies mitzuteilen. Eigener Code ist kein Problem ... nur wo das weekprofile mitteilen ?
Sorry wenn das hier vllt. wieder OT ist ... evtl. mache ich doch einen neuen Thread auf ;)
LG
Dazu muss "Friday" gesetzt werden können. Diskussion/Anleitung dazu gibt es bereits unter https://forum.fhem.de/index.php/topic,122120.0.html ;)
Perfekt, danke, das ist der richtige Thread. Schaue ich mir an und bringe mich auch gerne ein wenn ich etwas beitragen kann.
LG
Hallo Risiko!
Ich bin begeisterter Nutzer des Weekprofile, da somit die ganze Familie den Heizplan für das Zimmer selbst pflegen kann - DANKE dafür :-)
Leider habe ich nun mit der Homematic Version 5 das gleiche Problem wie stolus dem TYPE=HMCCUCHN.
Du hast hierzu bereits eine Testversion hochgeladen, die ich getestet habe.
Verbesserung ist, dass in dem Popup beim Send to Device nun die entsprechenden Thermostate wieder angezeigt werden.
Allerdings bekomme ich beim Senden an das Device den folgenden Fehler:
HMCCUCHN: HM_Leon_Thermostat Paramset MASTER not supported by device or channel
Hier mal ein list vom Thermostat:
Internals:
DEF OEQ2095054:4
FUUID 61a74bb8-f33f-0fde-5452-11fac1e811ad5e3a
IODev ccu
NAME HM_Leon_Thermostat
NR 581
STATE 21.8
TYPE HMCCUCHN
ccuaddr OEQ2095054:4
ccudevstate active
ccuif BidCos-RF
ccuname HM-CC-RT-DN OEQ2095054:4
ccurolectrl CLIMATECONTROL_RT_TRANSCEIVER
ccurolestate CLIMATECONTROL_RT_TRANSCEIVER
ccusubtype HM-CC-RT-DN
ccutype HM-CC-RT-DN
chntype ?
firmware 1.4
readonly no
READINGS:
2021-12-02 15:10:47 ACTUAL_TEMPERATURE 21.8
2021-12-02 14:31:10 AES_KEY off
2021-12-02 15:10:47 BATTERY_STATE 2.2
2021-12-02 15:10:47 BOOST_STATE 0
2021-12-02 14:31:10 CONFIG_PENDING false
2021-12-02 15:10:47 CONTROL_MODE AUTO-MODE
2021-12-02 14:31:10 DEVICE_IN_BOOTLOADER false
2021-12-02 15:10:47 FAULT_REPORTING LOWBAT
2021-12-02 14:31:10 INHIBIT false
2021-12-02 14:30:48 IODev ccu
2021-12-02 14:31:10 LOWBAT ok
2021-12-02 00:00:16 LastLowBattMailSent 1
2021-12-02 15:10:47 PARTY_START_DAY 1
2021-12-02 15:10:47 PARTY_START_MONTH 1
2021-12-02 15:10:47 PARTY_START_TIME 0
2021-12-02 15:10:47 PARTY_START_YEAR 0
2021-12-02 15:10:47 PARTY_STOP_DAY 1
2021-12-02 15:10:47 PARTY_STOP_MONTH 1
2021-12-02 15:10:47 PARTY_STOP_TIME 0
2021-12-02 15:10:47 PARTY_STOP_YEAR 0
2021-12-02 15:10:47 PARTY_TEMPERATURE 5.0
2021-12-02 14:31:10 RSSI_DEVICE -255
2021-12-02 14:31:10 RSSI_PEER -77
2021-12-02 15:10:47 SET_TEMPERATURE 20.0
2021-12-02 14:31:10 STICKY_UNREACH false
2021-12-02 14:31:10 UNREACH alive
2021-12-02 14:31:10 UPDATE_PENDING false
2021-12-02 15:10:47 VALVE_STATE 0
2021-12-02 15:10:47 activity alive
2021-12-02 15:10:47 battery ok
2021-12-02 15:10:47 control 20.0
2021-12-02 15:10:47 desired-temp 20.0
2021-12-02 15:10:47 devstate ok
2021-12-02 15:10:47 hmstate 21.8
2021-12-02 15:10:47 measured-temp 21.8
2021-12-02 15:10:47 rssidevice -255
2021-12-02 15:10:47 rssipeer -77
2021-12-02 15:10:47 sign off
2021-12-02 15:10:47 state 21.8
hmccu:
channels 1
detect 1
devspec OEQ2095054:4
nodefaults 1
role 4:CLIMATECONTROL_RT_TRANSCEIVER
setDefaults 0
cmdlist:
get
set boost:noArg manu desired-temp on:noArg off:noArg auto:noArg toggle:noArg
control:
chn 4
dpt SET_TEMPERATURE
dp:
0.AES_KEY:
VALUES:
NVAL 0
ONVAL 0
OSVAL off
OVAL 0
SVAL off
VAL 0
0.CONFIG_PENDING:
VALUES:
NVAL false
ONVAL false
OSVAL false
OVAL false
SVAL false
VAL false
0.DEVICE_IN_BOOTLOADER:
VALUES:
NVAL false
ONVAL false
OSVAL false
OVAL false
SVAL false
VAL false
0.INHIBIT:
VALUES:
NVAL false
ONVAL false
OSVAL false
OVAL false
SVAL false
VAL false
0.LOWBAT:
VALUES:
NVAL false
ONVAL false
OSVAL ok
OVAL false
SVAL ok
VAL false
0.RSSI_DEVICE:
VALUES:
NVAL -255
ONVAL -255
OSVAL -255
OVAL 1
SVAL -255
VAL 1
0.RSSI_PEER:
VALUES:
NVAL -77
ONVAL -77
OSVAL -77
OVAL 179
SVAL -77
VAL 179
0.STICKY_UNREACH:
VALUES:
NVAL false
ONVAL false
OSVAL false
OVAL false
SVAL false
VAL false
0.UNREACH:
VALUES:
NVAL false
ONVAL false
OSVAL alive
OVAL false
SVAL alive
VAL false
0.UPDATE_PENDING:
VALUES:
NVAL false
ONVAL false
OSVAL false
OVAL false
SVAL false
VAL false
4.ACTUAL_TEMPERATURE:
VALUES:
NVAL 21.800000
ONVAL 21.900000
OSVAL 21.9
OVAL 21.900000
SVAL 21.8
VAL 21.800000
4.BATTERY_STATE:
VALUES:
NVAL 2.200000
ONVAL 2.200000
OSVAL 2.2
OVAL 2.200000
SVAL 2.2
VAL 2.200000
4.BOOST_STATE:
VALUES:
NVAL 0
ONVAL 0
OSVAL 0
OVAL 0
SVAL 0
VAL 0
4.CONTROL_MODE:
VALUES:
NVAL 0
ONVAL 0
OSVAL AUTO-MODE
OVAL 0
SVAL AUTO-MODE
VAL 0
4.FAULT_REPORTING:
VALUES:
NVAL 6
ONVAL 6
OSVAL LOWBAT
OVAL 6
SVAL LOWBAT
VAL 6
4.PARTY_START_DAY:
VALUES:
NVAL 1
ONVAL 1
OSVAL 1
OVAL 1
SVAL 1
VAL 1
4.PARTY_START_MONTH:
VALUES:
NVAL 1
ONVAL 1
OSVAL 1
OVAL 1
SVAL 1
VAL 1
4.PARTY_START_TIME:
VALUES:
NVAL 0
ONVAL 0
OSVAL 0
OVAL 0
SVAL 0
VAL 0
4.PARTY_START_YEAR:
VALUES:
NVAL 0
ONVAL 0
OSVAL 0
OVAL 0
SVAL 0
VAL 0
4.PARTY_STOP_DAY:
VALUES:
NVAL 1
ONVAL 1
OSVAL 1
OVAL 1
SVAL 1
VAL 1
4.PARTY_STOP_MONTH:
VALUES:
NVAL 1
ONVAL 1
OSVAL 1
OVAL 1
SVAL 1
VAL 1
4.PARTY_STOP_TIME:
VALUES:
NVAL 0
ONVAL 0
OSVAL 0
OVAL 0
SVAL 0
VAL 0
4.PARTY_STOP_YEAR:
VALUES:
NVAL 0
ONVAL 0
OSVAL 0
OVAL 0
SVAL 0
VAL 0
4.PARTY_TEMPERATURE:
VALUES:
NVAL 5.000000
ONVAL 5.000000
OSVAL 5.0
OVAL 5.000000
SVAL 5.0
VAL 5.000000
4.SET_TEMPERATURE:
VALUES:
NVAL 20.000000
ONVAL 20.000000
OSVAL 20.0
OVAL 20.000000
SVAL 20.0
VAL 20.000000
4.VALVE_STATE:
VALUES:
NVAL 0
ONVAL 0
OSVAL 0
OVAL 0
SVAL 0
VAL 0
roleCmds:
get:
set:
auto:
channel 4
role CLIMATECONTROL_RT_TRANSCEIVER
subcount 1
syntax V:AUTO_MODE:1
usage auto
subcmd:
000:
args 1
dpt AUTO_MODE
fnc
max 1
min 0
parname AUTO_MODE
partype 3
ps VALUES
scn 000
unit
boost:
channel 4
role CLIMATECONTROL_RT_TRANSCEIVER
subcount 1
syntax V:BOOST_MODE:1
usage boost
subcmd:
000:
args 1
dpt BOOST_MODE
fnc
max 1
min 0
parname BOOST_MODE
partype 3
ps VALUES
scn 000
unit
desired-temp:
channel 4
role CLIMATECONTROL_RT_TRANSCEIVER
subcount 1
syntax V:SET_TEMPERATURE:?temperature
usage desired-temp temperature
subcmd:
000:
args
dpt SET_TEMPERATURE
fnc
max 30.500000
min 4.500000
parname temperature
partype 2
ps VALUES
scn 000
unit �C
manu:
channel 4
role CLIMATECONTROL_RT_TRANSCEIVER
subcount 1
syntax V:MANU_MODE:?temperature=20
usage manu [temperature]
subcmd:
000:
args 20
dpt MANU_MODE
fnc
max 30.500000
min 4.500000
parname temperature
partype 2
ps VALUES
scn 000
unit �C
off:
channel 4
role CLIMATECONTROL_RT_TRANSCEIVER
subcount 1
syntax V:MANU_MODE:4.5
usage off
subcmd:
000:
args 4.5
dpt MANU_MODE
fnc
max 30.500000
min 4.500000
parname MANU_MODE
partype 3
ps VALUES
scn 000
unit �C
on:
channel 4
role CLIMATECONTROL_RT_TRANSCEIVER
subcount 1
syntax V:MANU_MODE:30.5
usage on
subcmd:
000:
args 30.5
dpt MANU_MODE
fnc
max 30.500000
min 4.500000
parname MANU_MODE
partype 3
ps VALUES
scn 000
unit �C
state:
chn 4
dpt ACTUAL_TEMPERATURE
Attributes:
alias Ist-/Soll-Temperatur Leon
ccuflags showMasterReadings,showDeviceReadings
cmdIcon auto:sani_heating_automatic manu:sani_heating_manual boost:sani_heating_boost on:general_an off:general_aus
genericDeviceType thermostat
group Leon
room Leon,OG
sortby 90
substexcl desired-temp
userattr weekprofile
webCmd desired-temp:auto:manu:boost:on:off
weekprofile Temperatur_Weekprofile:default:Leon
widgetOverride desired-temp:slider,4.5,0.5,30.5,1
Ich wäre für Tipps sehr dankbar!
Grüße, Roger
Hallo Roger,
da passt vermutlich der Befehlssyntax nicht. Dieser scheint für HMCCUCHN dann wohl wieder anders zu sein. :-\
Kannst du mir sagen, wie man richtiger Weise ein Profil an das Device sendet!?
Wenn du verbose von weekprofile auf 4 setzt, siehst du im Log, was gesendet wird.
Risiko.
Hallo Risiko,
es wird folgender String gesendet:
set Leon_Thermostat config TEMPERATURE_MONDAY_1=16.0 ENDTIME_MONDAY_1=540 TEMPERATURE_MONDAY_2=19.0 ENDTIME_MONDAY_2=1140 TEMPERATURE_MONDAY_3=16.0 ENDTIME_MONDAY_3=1440 TEMPERATURE_TUESDAY_1=16.0 ENDTIME_TUESDAY_1=540 TEMPERATURE_TUESDAY_2=19.0 ENDTIME_TUESDAY_2=1140 TEMPERATURE_TUESDAY_3=16.0 ENDTIME_TUESDAY_3=1440 TEMPERATURE_WEDNESDAY_1=16.0 ENDTIME_WEDNESDAY_1=540 TEMPERATURE_WEDNESDAY_2=19.0 ENDTIME_WEDNESDAY_2=1140 TEMPERATURE_WEDNESDAY_3=16.0 ENDTIME_WEDNESDAY_3=1440 TEMPERATURE_THURSDAY_1=16.0 ENDTIME_THURSDAY_1=540 TEMPERATURE_THURSDAY_2=19.0 ENDTIME_THURSDAY_2=1140 TEMPERATURE_THURSDAY_3=16.0 ENDTIME_THURSDAY_3=1440 TEMPERATURE_FRIDAY_1=16.0 ENDTIME_FRIDAY_1=540 TEMPERATURE_FRIDAY_2=19.0 ENDTIME_FRIDAY_2=1140 TEMPERATURE_FRIDAY_3=16.0 ENDTIME_FRIDAY_3=1440 TEMPERATURE_SATURDAY_1=16.0 ENDTIME_SATURDAY_1=540 TEMPERATURE_SATURDAY_2=19.0 ENDTIME_SATURDAY_2=1140 TEMPERATURE_SATURDAY_3=16.0 ENDTIME_SATURDAY_3=1440 TEMPERATURE_SUNDAY_1=16.0 ENDTIME_SUNDAY_1=540 TEMPERATURE_SUNDAY_2=19.0 ENDTIME_SUNDAY_2=1140 TEMPERATURE_SUNDAY_3=16.0 ENDTIME_SUNDAY_3=1440
Im Log taucht dann folgendes auf:
HMCCUCHN [Leon_Thermostat] HMCCUCHN: Leon_Thermostat Paramset MASTER not supported by device or channel
Ich habe in dem Homematic Beitrag mal nach dem korrekten String gefragt: https://forum.fhem.de/index.php/topic,124504.msg1190886.html#msg1190886
Grüße, Roger
Hm. Das hilft mir nicht und ich habe keine Zeit mir das alles durchzulesen.
Melde dich hier wieder, wenn du weist, wie die Befehl richtig ist und funktioniert.
Das ist leider wieder eben so typisch bei dem HM Zeug ;)
Risiko.
Hallo Risiko,
ich habe ja in dem Homematic Forum einen Beitrag https://forum.fhem.de/index.php/topic,124504.msg1190886.html#msg1190886 zu dem Problem gepostet.
Weekprofile wird angeblich nicht unterstützt, aber ich habe mit etlichen Tests herausgefunden, wie der String auszusehen hat.
set Leon_Thermostat config device TEMPERATURE_MONDAY_1=16.0 ENDTIME_MONDAY_1=540: TEMPERATURE_MONDAY_2=19.0 ENDTIME_MONDAY_2=1140: TEMPERATURE_MONDAY_3=16.0 ENDTIME_MONDAY_3=1440:
Hierzu habe ich Testweise in deiner hier hochgeladenen Testversion für HMCCUCHN noch 2 Änderungen vorgenommen:
1. In Zeile 493 habe ich nach set $device config noch das wort "device" eingefügt.
} elsif ($type =~ /HMCCU.*/){
$cmd .= "set $device config device" if ($type eq "HMCCU_HM");
2. In Zeile 511 habe ich nach den Minuten noch einen Doppelpunkt angehängt, da sonst die Minuten ignoriert werden - das hat gedauert :-) ...also nicht das Programmieren, sondern das Rausfinden, dass der Doppelpunkt mit muss.
for (my $i = 0; $i < $tmpCnt; $i++) {
$cmd .= " " . $dpTemp . "_" . ($i + 1) . "=" . $prfData->{$day}->{"temp"}[$i];
$cmd .= " " . $dpTime . "_" . ($i + 1) . "=" . weekprofile_timeToMinutes($prfData->{$day}->{"time"}[$i]) . ":";
}
Solltest Du die Änderungen für korrekt ansehen, dann wäre ich für ein langfristiges Update von weekprofile sehr dankbar.
Im Moment läuft es ja mit meiner Änderung.
Danke nochmal für den Support!
Roger
Hallo Roger,
habe es fast so übernommen. Den Doppelpunkt natürlich auch nur beim Typ HMCCU_HM.
Anbei nochmal eine Version zum Testen. Würde es dann so einchecken.
Risiko
Hallo Risiko,
hab es getestet. Läuft wie früher :-)
Habe zap geschrieben, sollte er hier was anpassen, dann wäre es gut, wenn er Bescheid sagt.
Es gab allerdings keine Antwort.
Danke & Grüße,
Roger
Hallo Zusammen,
ich habe die angepasste Version von weekprofile eben auch einmal angetestet.
Das Schreiben des Profils scheint gut zu funktionieren.
Allerdings kann ich aus den Thermostaten die aktuellen Profile nicht auslesen.
Könnt ihr mir hierzu vielleicht einen Tipp geben ?
Mein Thermostat ist wie folgt definiert:
Internals
DEF KEQ07XXXXX:4
FUUID 61ec2a78-f33f-0029-71e0-3fb1dd2eea812446
IODev myCCU2
NAME HM_Schlafzimmer_Heizungsthermostat
NR 22
STATE 18.1
TYPE HMCCUCHN
ccuaddr KEQ07XXXXX:4
ccudevstate active
ccuif BidCos-RF
ccuname Schlafzimmer Heizungsthermostat
ccurolectrl CLIMATECONTROL_RT_TRANSCEIVER
ccurolestate CLIMATECONTROL_RT_TRANSCEIVER
ccusubtype HM-CC-RT-DN
ccutype HM-CC-RT-DN
firmware 1.5
readonly no
sender HM_Schlafzimmer_Wandthermostat,HM_Schlafzimmer_Balkontuer
Readings
ACTUAL_TEMPERATURE 18.1 2022-01-23 13:51:26
BATTERY_STATE 2.7 2022-01-23 13:51:26
BOOST_STATE 0 2022-01-23 13:51:26
CONTROL_MODE AUTO-MODE 2022-01-23 13:51:26
FAULT_REPORTING NO_FAULT 2022-01-23 13:51:26
IODev myCCU 2022-01-23 11:47:42
PARTY_START_DAY 1 2022-01-23 13:51:26
PARTY_START_MONTH 1 2022-01-23 13:51:26
PARTY_START_TIME 00:00 2022-01-23 13:51:26
PARTY_START_YEAR 0 2022-01-23 13:51:26
PARTY_STOP_DAY 1 2022-01-23 13:51:26
PARTY_STOP_MONTH 1 2022-01-23 13:51:26
PARTY_STOP_TIME 00:00 2022-01-23 13:51:26
PARTY_STOP_YEAR 0 2022-01-23 13:51:26
PARTY_TEMPERATURE 5.0 2022-01-23 13:51:26
SET_TEMPERATURE 18.0 2022-01-23 13:51:26
VALVE_STATE 11 2022-01-23 13:51:26
activity alive 2022-01-23 11:48:32
battery ok 2022-01-23 11:48:32
control 18.0 2022-01-23 13:51:26
desired-temp 18.0 2022-01-23 13:51:26
devstate ok 2022-01-23 13:51:26
hmstate 18.1 2022-01-23 13:51:26
measured-temp 18.1 2022-01-23 13:51:26
rssidevice -255 2022-01-23 11:48:32
rssipeer -63 2022-01-23 11:48:32
sign on 2022-01-23 11:48:32
state 18.1 2022-01-23 13:51:26
Attributes
cmdIcon auto:sani_heating_automatic manu:sani_heating_manual boost:sani_heating_boost on:general_an off:general_aus
group Heizung
room Homematic
substexcl desired-temp
webCmd desired-temp:auto:manu:boost:on:off
widgetOverride desired-temp:slider,4.5,0.5,30.5,1
RAW:
defmod HM_Schlafzimmer_Heizungsthermostat HMCCUCHN KEQ07XXXX:4
attr HM_Schlafzimmer_Heizungsthermostat cmdIcon auto:sani_heating_automatic manu:sani_heating_manual boost:sani_heating_boost on:general_an off:general_aus
attr HM_Schlafzimmer_Heizungsthermostat group Heizung
attr HM_Schlafzimmer_Heizungsthermostat room Homematic
attr HM_Schlafzimmer_Heizungsthermostat substexcl desired-temp
attr HM_Schlafzimmer_Heizungsthermostat webCmd desired-temp:auto:manu:boost:on:off
attr HM_Schlafzimmer_Heizungsthermostat widgetOverride desired-temp:slider,4.5,0.5,30.5,1
setstate HM_Schlafzimmer_Heizungsthermostat 18.1
setstate HM_Schlafzimmer_Heizungsthermostat 2022-01-23 13:51:26 ACTUAL_TEMPERATURE 18.1
setstate HM_Schlafzimmer_Heizungsthermostat 2022-01-23 13:51:26 BATTERY_STATE 2.7
setstate HM_Schlafzimmer_Heizungsthermostat 2022-01-23 13:51:26 BOOST_STATE 0
setstate HM_Schlafzimmer_Heizungsthermostat 2022-01-23 13:51:26 CONTROL_MODE AUTO-MODE
setstate HM_Schlafzimmer_Heizungsthermostat 2022-01-23 13:51:26 FAULT_REPORTING NO_FAULT
setstate HM_Schlafzimmer_Heizungsthermostat 2022-01-23 11:47:42 IODev myCCU2
setstate HM_Schlafzimmer_Heizungsthermostat 2022-01-23 13:51:26 PARTY_START_DAY 1
setstate HM_Schlafzimmer_Heizungsthermostat 2022-01-23 13:51:26 PARTY_START_MONTH 1
setstate HM_Schlafzimmer_Heizungsthermostat 2022-01-23 13:51:26 PARTY_START_TIME 00:00
setstate HM_Schlafzimmer_Heizungsthermostat 2022-01-23 13:51:26 PARTY_START_YEAR 0
setstate HM_Schlafzimmer_Heizungsthermostat 2022-01-23 13:51:26 PARTY_STOP_DAY 1
setstate HM_Schlafzimmer_Heizungsthermostat 2022-01-23 13:51:26 PARTY_STOP_MONTH 1
setstate HM_Schlafzimmer_Heizungsthermostat 2022-01-23 13:51:26 PARTY_STOP_TIME 00:00
setstate HM_Schlafzimmer_Heizungsthermostat 2022-01-23 13:51:26 PARTY_STOP_YEAR 0
setstate HM_Schlafzimmer_Heizungsthermostat 2022-01-23 13:51:26 PARTY_TEMPERATURE 5.0
setstate HM_Schlafzimmer_Heizungsthermostat 2022-01-23 13:51:26 SET_TEMPERATURE 18.0
setstate HM_Schlafzimmer_Heizungsthermostat 2022-01-23 13:51:26 VALVE_STATE 11
Weekprofile ist angelegt mit :
defmod Heizungsthermostat_weekprofile weekprofile
attr Heizungsthermostat_weekprofile verbose 5
beim ausführen von:
set Heizungsthermostat_weekprofile import_profile HM_Schlafzimmer_Heizungsthermostat
wird ein entsprechendes Profil angelegt, allerdings nur ein Standarprofil (immer 18 Grad) .
Das Log sagt folgendes:
2022.01.23 14:11:29 5: Heizungsthermostat_weekprofile(readDayProfile): read from type HMCCU_HM
2022.01.23 14:11:29 5: Heizungsthermostat_weekprofile(weekprofile_get_prefix_HM): check: ENDTIME_MONDAY_1
2022.01.23 14:11:29 5: Heizungsthermostat_weekprofile(weekprofile_get_prefix_HM): check: R-1.P1_ENDTIME_MONDAY_1
2022.01.23 14:11:29 5: Heizungsthermostat_weekprofile(weekprofile_get_prefix_HM): check: R-ENDTIME_MONDAY_1
2022.01.23 14:11:29 5: Heizungsthermostat_weekprofile(weekprofile_get_prefix_HM): check: R-P1_ENDTIME_MONDAY_1
2022.01.23 14:11:29 5: Heizungsthermostat_weekprofile(weekprofile_get_prefix_HM): check: P1_ENDTIME_MONDAY_1
2022.01.23 14:11:29 2: Heizungsthermostat_weekprofile(readDayProfile): no readings for MONDAY found
2022.01.23 14:11:29 5: Heizungsthermostat_weekprofile(readDayProfile): read from type HMCCU_HM
2022.01.23 14:11:29 5: Heizungsthermostat_weekprofile(weekprofile_get_prefix_HM): check: ENDTIME_TUESDAY_1
2022.01.23 14:11:29 5: Heizungsthermostat_weekprofile(weekprofile_get_prefix_HM): check: R-1.P1_ENDTIME_TUESDAY_1
2022.01.23 14:11:29 5: Heizungsthermostat_weekprofile(weekprofile_get_prefix_HM): check: R-ENDTIME_TUESDAY_1
2022.01.23 14:11:29 5: Heizungsthermostat_weekprofile(weekprofile_get_prefix_HM): check: R-P1_ENDTIME_TUESDAY_1
2022.01.23 14:11:29 5: Heizungsthermostat_weekprofile(weekprofile_get_prefix_HM): check: P1_ENDTIME_TUESDAY_1
2022.01.23 14:11:29 2: Heizungsthermostat_weekprofile(readDayProfile): no readings for TUESDAY found
2022.01.23 14:11:29 5: Heizungsthermostat_weekprofile(readDayProfile): read from type HMCCU_HM
2022.01.23 14:11:29 5: Heizungsthermostat_weekprofile(weekprofile_get_prefix_HM): check: ENDTIME_WEDNESDAY_1
2022.01.23 14:11:29 5: Heizungsthermostat_weekprofile(weekprofile_get_prefix_HM): check: R-1.P1_ENDTIME_WEDNESDAY_1
2022.01.23 14:11:29 5: Heizungsthermostat_weekprofile(weekprofile_get_prefix_HM): check: R-ENDTIME_WEDNESDAY_1
2022.01.23 14:11:29 5: Heizungsthermostat_weekprofile(weekprofile_get_prefix_HM): check: R-P1_ENDTIME_WEDNESDAY_1
2022.01.23 14:11:29 5: Heizungsthermostat_weekprofile(weekprofile_get_prefix_HM): check: P1_ENDTIME_WEDNESDAY_1
2022.01.23 14:11:29 2: Heizungsthermostat_weekprofile(readDayProfile): no readings for WEDNESDAY found
2022.01.23 14:11:29 5: Heizungsthermostat_weekprofile(readDayProfile): read from type HMCCU_HM
2022.01.23 14:11:29 5: Heizungsthermostat_weekprofile(weekprofile_get_prefix_HM): check: ENDTIME_THURSDAY_1
2022.01.23 14:11:29 5: Heizungsthermostat_weekprofile(weekprofile_get_prefix_HM): check: R-1.P1_ENDTIME_THURSDAY_1
2022.01.23 14:11:29 5: Heizungsthermostat_weekprofile(weekprofile_get_prefix_HM): check: R-ENDTIME_THURSDAY_1
2022.01.23 14:11:29 5: Heizungsthermostat_weekprofile(weekprofile_get_prefix_HM): check: R-P1_ENDTIME_THURSDAY_1
2022.01.23 14:11:29 5: Heizungsthermostat_weekprofile(weekprofile_get_prefix_HM): check: P1_ENDTIME_THURSDAY_1
2022.01.23 14:11:29 2: Heizungsthermostat_weekprofile(readDayProfile): no readings for THURSDAY found
2022.01.23 14:11:29 5: Heizungsthermostat_weekprofile(readDayProfile): read from type HMCCU_HM
2022.01.23 14:11:29 5: Heizungsthermostat_weekprofile(weekprofile_get_prefix_HM): check: ENDTIME_FRIDAY_1
2022.01.23 14:11:29 5: Heizungsthermostat_weekprofile(weekprofile_get_prefix_HM): check: R-1.P1_ENDTIME_FRIDAY_1
2022.01.23 14:11:29 5: Heizungsthermostat_weekprofile(weekprofile_get_prefix_HM): check: R-ENDTIME_FRIDAY_1
2022.01.23 14:11:29 5: Heizungsthermostat_weekprofile(weekprofile_get_prefix_HM): check: R-P1_ENDTIME_FRIDAY_1
2022.01.23 14:11:29 5: Heizungsthermostat_weekprofile(weekprofile_get_prefix_HM): check: P1_ENDTIME_FRIDAY_1
2022.01.23 14:11:29 2: Heizungsthermostat_weekprofile(readDayProfile): no readings for FRIDAY found
2022.01.23 14:11:29 5: Heizungsthermostat_weekprofile(readDayProfile): read from type HMCCU_HM
2022.01.23 14:11:29 5: Heizungsthermostat_weekprofile(weekprofile_get_prefix_HM): check: ENDTIME_SATURDAY_1
2022.01.23 14:11:29 5: Heizungsthermostat_weekprofile(weekprofile_get_prefix_HM): check: R-1.P1_ENDTIME_SATURDAY_1
2022.01.23 14:11:29 5: Heizungsthermostat_weekprofile(weekprofile_get_prefix_HM): check: R-ENDTIME_SATURDAY_1
2022.01.23 14:11:29 5: Heizungsthermostat_weekprofile(weekprofile_get_prefix_HM): check: R-P1_ENDTIME_SATURDAY_1
2022.01.23 14:11:29 5: Heizungsthermostat_weekprofile(weekprofile_get_prefix_HM): check: P1_ENDTIME_SATURDAY_1
2022.01.23 14:11:29 2: Heizungsthermostat_weekprofile(readDayProfile): no readings for SATURDAY found
2022.01.23 14:11:29 5: Heizungsthermostat_weekprofile(readDayProfile): read from type HMCCU_HM
2022.01.23 14:11:29 5: Heizungsthermostat_weekprofile(weekprofile_get_prefix_HM): check: ENDTIME_SUNDAY_1
2022.01.23 14:11:29 5: Heizungsthermostat_weekprofile(weekprofile_get_prefix_HM): check: R-1.P1_ENDTIME_SUNDAY_1
2022.01.23 14:11:29 5: Heizungsthermostat_weekprofile(weekprofile_get_prefix_HM): check: R-ENDTIME_SUNDAY_1
2022.01.23 14:11:29 5: Heizungsthermostat_weekprofile(weekprofile_get_prefix_HM): check: R-P1_ENDTIME_SUNDAY_1
2022.01.23 14:11:29 5: Heizungsthermostat_weekprofile(weekprofile_get_prefix_HM): check: P1_ENDTIME_SUNDAY_1
2022.01.23 14:11:29 2: Heizungsthermostat_weekprofile(readDayProfile): no readings for SUNDAY found
2022.01.23 14:11:29 3: WARNING master device HM_Schlafzimmer_Heizungsthermostat has no week profile - create default
2022.01.23 14:11:29 3: profile default:HM_Schlafzimmer_Heizungsthermostat from HM_Schlafzimmer_Heizungsthermostat imported
In dem File von stolus habe ich gesehen, dass es bei seinem Device deutlich mehr readings gibt, als bei meinem.
Hier vermute ich den Grund.
Könnt ihr mir hierzu vielleicht einen Hinweis geben, was zu tun ist ?
Hallo mephisto,
bin jetzt hier auch kein Profi, aber ich kann mich erinnern, dass ich auch keine Readings hatte, wie Du auch.
Ich denke Du musst hier noch das Attribut ccuflags setzen.
ccuflags showMasterReadings,showDeviceReadings
Hoffe das hilft.
Grüße, Roger
Hi Roger,
vielen Dank für die Hilfe ! Das war in der Tat der Grund warum es nicht funktioniert hat !
Jetzt wird das aktuelle (mit der CCU2 angelegte) Profil ausgelesen.
Allerdings sieht da in Weekprofile ausgelesene Profil doch deutlich anders aus, als es sollte.
Die 3 unterschiedlichen Intervalle werden korrekt erkannt, allerdings werden die Zeiten scheinbar falsch umgerechnet.
Anbei mal die Screenshots.
Vielleicht habe ich hier auch etwas übersehen ?
hmmm vielleicht das gleiche Problem, wie beim Schreiben und da fehlt evtl. noch etwas. Ich pflege die Wochenprofile nicht in der ccu, sondern nur mit weekprofile.
Überschreib doch mal das Profil in FHEM und sende es an die ccu und prüfe das Ergebnis in der ccu Weboberfläche.
So habe ich den Schreibvorgang geprüft.
Hallo Risiko,
nachdem ich grade wieder Anlass hatte, etwas an meiner Heizungsregelung rumzubasteln, wollte ich u.a. auch auf ein "referenzierendes Profil" referenzieren. Es kam zwar keine Fehlermeldung oder irgend sonst ein Hinweis, dass das nicht klappt, aber geklappt scheint es eben auch nicht zu haben.
Anbei daher ein paar Zeilen Code dazu als Vorschlag, die dazu führen, dass das 2. referenzierende Profil dann auch die Referenz aus dem 1. Profil bekommt. Im Ergebnis entsteht weiter keine Mehrstufigkeit, der Befehl bewirkt aber im Ergebnis, was beabsichtigt war, nämlich dass das sachlich richtige Zeilpfofil wirksam wird.
Allzu intensiv getestet habe ich es bisher nicht, aber Nebenwirkungen scheint es auch keine zu haben.
Hi.
Danke. Ich schaue bei Gelegenheit mal darüber.
Habe aber auch schon lange nichts mehr daran gemacht ;)
Kein Ding. Im Moment ist die Datei ja gepatcht, und solange du nichts updatest, passiert ja auch nichts.
Grüße!
Habe es so übernommen und eingecheckt.
Ich habe noch ein Verständnisproblem mit tempMap.
die über das Attribut eingestellten Mappings werden irgendwie nicht zuverlässig übernommen und teilweise lassen sich auch Texte (wie zum Beispiel "tmHeating") manchmal im Weekprofile nicht abspeichern, es erfolgt dann die Meldung: Error parsing profile data. No valid json format
Gibt es hier nur bestimmte keywords die erlaubt sind?
Ich habe nach vielen Versuchen aktuell mit tempMap zwei Mappings eingestellt:
attr weekprofile_Konoba tempMap off:5.0,on:5.5 trotzdem erscheint in der Auswahl im default Profil bei 5.0 und 5.5 ein tmOff und tmHeating (anstatt off und on)
Beides sind Textwerte die ich irgendwann vorher mal ausprobiert habe, die anscheinend aber noch irgendwo gespeichert bleiben. Wie kann man diese Tabelle einmal komplett löschen oder gibt es einen anderen Grund warum diese Zuordnung nicht überschrieben wird wenn das Attribut tempMap neu gesetzt wird?
Hier noch ein List meines weekprofiles:
Internals:
CFGFN
CONFIGFILE ./log/weekprofile-weekprofile_Konoba.cfg
DEF Timer_HZ_Konobat
FUUID 63b923d1-f33f-5aeb-707d-4fef4ee60d4560c8
NAME weekprofile_Konoba
NR 2492
NTFY_ORDER 50-weekprofile_Konoba
STATE created
TYPE weekprofile
eventCount 60
MASTERDEV:
NAME Timer_HZ_Konobat
PROFILES:
HASH(0x4412a90)
READINGS:
2023-01-07 09:55:09 profile_count 2
2023-01-07 08:48:33 state created
SNDDEVLIST:
HASH(0x45510a0)
TEMPMAP:
tmHeating 5.5
5.0 0.0
5.5 0.0
EnergySaveHeating 0.0
Heating 5.5
off 5.0
on 5.5
ot 5.5
tmEnergySaveHeating 5.0
tmHeating 5.5
tmOff 5.0
tmoff 5.0
tmon 5.5
TOPICS:
default
Attributes:
room Heizung,Konoba
sendKeywordsToDevices 1
tempMap off:5.0,on:5.5
widgetTempRange 5:28:0.5
widgetWeekdays Montag, Dienstag, Mittwoch, Donnerstag, Freitag, Samstag, Sonntag
Zitat von: omnior am 07 Januar 2023, 13:13:40
attr weekprofile_Konoba tempMap off:5.0,on:5.5 trotzdem erscheint in der Auswahl im default Profil bei 5.0 und 5.5 ein tmOff und tmHeating (anstatt off und on)
Da hast du einen Fehler gefunden. Gerade behoben.
Da hilft aktuell nur ein Neustart von FHEM.
Hallo,
seit einiger Zeit habe ich folgende Fehlermeldung im LOG:
2023.01.09 11:40:53 3: WARNING master device Wandthermostat_Buero_Climate has no week profile - create default
2023.01.09 11:40:56 3: WARNING master device Wandthermostat_GaesteWC_Climate has no week profile - create default
2023.01.09 11:40:59 3: WARNING master device Wandthermostat_Flur_Climate has no week profile - create default
2023.01.09 11:41:53 3: WARNING master device Wandthermostat_Ankleidezimmer_Climate has no week profile - create default
2023.01.09 11:42:17 3: WARNING master device Wandthermostat_Dachgeschoss_Climate has no week profile - create default
2023.01.09 11:42:23 3: WARNING master device Wandthermostat_Bad_Climate has no week profile - create default
2023.01.09 11:42:30 3: WARNING master device Wandthermostat_Wohnzimmer_Climate has no week profile - create default
2023.01.09 11:42:39 3: WARNING master device Wandthermostat_Kueche_Climate has no week profile - create default
2023.01.09 11:43:09 3: WARNING master device Wandthermostat_GaesteWC_Climate has no week profile - create default
2023.01.09 11:43:12 3: WARNING master device Wandthermostat_Schlafzimmer_Climate has no week profile - create default
2023.01.09 11:43:40 3: WARNING master device Wandthermostat_Flur_Climate has no week profile - create default
2023.01.09 11:43:42 3: WARNING master device Wandthermostat_Buero_Climate has no week profile - create default
2023.01.09 11:44:05 3: WARNING master device Wandthermostat_Ankleidezimmer_Climate has no week profile - create default
2023.01.09 11:44:46 3: WARNING master device Wandthermostat_Kueche_Climate has no week profile - create default
2023.01.09 11:45:02 3: WARNING master device Wandthermostat_Bad_Climate has no week profile - create default
2023.01.09 11:45:09 3: WARNING master device Wandthermostat_Wohnzimmer_Climate has no week profile - create default
2023.01.09 11:45:16 3: WARNING master device Wandthermostat_Dachgeschoss_Climate has no week profile - create default
Ich habe mehrere HM-TC-IT-WM-W-EU Wandthermostate, bei allen wird der Master nicht ausgelesen, ich habe auch ein HM-CC-RT-DN ohne Wandthermostat, hier wird der Master ausgelesen.
Habt Ihr eine Idee wo der Fehler sein kann ?
Internals:
CONFIGFILE ./log/weekprofile-Heizprofil_Ankleidezimmer.cfg
DEF Wandthermostat_Ankleidezimmer_Climate
FUUID 5c4d5af5-f33f-8133-fdc5-cc0fb603261e3e86
NAME Heizprofil_Ankleidezimmer
NR 238
NTFY_ORDER 50-Heizprofil_Ankleidezimmer
STATE assigned
TYPE weekprofile
eventCount 32
MASTERDEV:
NAME Wandthermostat_Ankleidezimmer_Climate
TYPE CUL_HM
PROFILES:
HASH(0x5599072748)
HASH(0x5597796728)
HASH(0x5597795bc0)
READINGS:
2023-01-09 11:59:46 profile_count 3
2023-01-09 10:40:28 state assigned
SNDDEVLIST:
HASH(0x55989fdfb8)
HASH(0x5598d298b8)
HASH(0x5598a1e0d0)
HASH(0x5598818198)
HASH(0x5598c28608)
HASH(0x5598db0430)
HASH(0x559939e098)
HASH(0x5597281668)
HASH(0x559885d5c8)
HASH(0x5598d01f90)
HASH(0x5598ec7d08)
HASH(0x5599037980)
HASH(0x55989044c8)
HASH(0x5598cbc648)
HASH(0x5598d58208)
HASH(0x5598d8d4b0)
HASH(0x559a650d10)
HASH(0x559a0cf428)
HASH(0x5598eb61e0)
HASH(0x559889fdd8)
HASH(0x5598858330)
HASH(0x559a618560)
HASH(0x55989c6210)
HASH(0x5599189448)
HASH(0x5598bed550)
HASH(0x55988dac60)
HASH(0x5598a068f8)
HASH(0x5598b84788)
HASH(0x5598be2900)
HASH(0x5598cb6a38)
HASH(0x5598cdd2f0)
HASH(0x5598dad410)
TEMPMAP:
TOPICS:
default
Attributes:
alias Heizprofil_Ankleidezimmer
room 80_Heizung
Zitat von: Risiko am 08 Januar 2023, 19:54:01
Da hast du einen Fehler gefunden. Gerade behoben.
Da hilft aktuell nur ein Neustart von FHEM.
Jetzt ist mir noch etwas aufgefallen:
Ich stelle mein weekprofile auf topics und benutze aber im Moment nur default:default.
Wenn ich nun ein Profil speichere und dann versuche zu übertragen mit:
set weekprofile_Gartenblick send_to_device default:default WDT_Gartenblick, erhalte ich folgende Fehlermeldung:
no valid switchingtime found in <>, check parameters or make sure weekprofile device exists and returns valid data.Danach ist die Definition meiner Zeiten im weekprofile verschwunden, es ist kein Klick mehr auf die Zahnräder möglich und es erscheint dort beim Klicken die Meldung:
fhemweb_weekprofile.js line 559:
Uncaught TypeError: Cannot read properties of undefined (reading 'time')Was mache ich noch falsch?
Hier das List des weekprofiles:
Internals:
CONFIGFILE ./log/weekprofile-weekprofile_Gartenblick.cfg
DEF WDT_Gartenblick
FUUID 63bbb03d-f33f-5aeb-73a9-56d812480dd7c5e3
NAME weekprofile_Gartenblick
NR 294
NTFY_ORDER 50-weekprofile_Gartenblick
STATE created
TYPE weekprofile
eventCount 10
MASTERDEV:
NAME WDT_Gartenblick
PROFILES:
HASH(0x356f948)
READINGS:
2023-01-09 13:00:46 active_topic default
2023-01-09 14:13:29 profile_count 1
2023-01-09 14:11:28 state created
2023-01-09 14:13:29 topics default
SNDDEVLIST:
HASH(0x3816ec8)
HASH(0x3819c70)
HASH(0x381f138)
TEMPMAP:
boost 7.0
heat 6.0
off 4.0
save 5.0
TOPICS:
default
Attributes:
forceCompleteProfile 0
sendKeywordsToDevices 1
tempMap off:4.0,save:5.0,heat:6.0,boost:7.0
useTopics 1
userattr weekprofile
widgetTempRange 4:28:1
widgetWeekdays Montag, Dienstag, Mittwoch, Donnerstag, Freitag, Samstag, Sonntagund hier der weekdayTimer:
Internals:
COMMAND
CONDITION
DEF ZWave_THERMOSTAT_40 weekprofile:weekprofile_Gartenblick
DEVICE ZWave_THERMOSTAT_40
FUUID 63bb282c-f33f-5aeb-bd2d-f114692630826baf
GlobalDaylistSpec
LANGUAGE en
NAME WDT_Gartenblick
NR 293
Profil 0: Sunday 00:10:00 18.0,
Profil 1: Monday 00:10:00 18.0,
Profil 2: Tuesday 00:10:00 18.0,
Profil 3: Wednesday 00:10:00 18.0,
Profil 4: Thursday 00:10:00 18.0,
Profil 5: Friday 00:10:00 18.0,
Profil 6: Saturday 00:10:00 18.0,
STATE 18.0
STILLDONETIME 0
TYPE WeekdayTimer
eventCount 6
setModifier desired-temp
READINGS:
2023-01-09 14:02:46 currValue 18.0
2023-01-09 12:29:46 disabled 0
2023-01-09 14:02:46 nextUpdate 2023-01-10 00:10:00
2023-01-09 14:02:46 nextValue 18.0
2023-01-09 14:02:46 state 18.0
2023-01-09 14:19:55 weekprofiles weekprofile_Gartenblick:default:default
SWITCHINGTIMES:
TIMER:
WDT_Gartenblick_midnight:
HASH WDT_Gartenblick
MODIFIER midnight
NAME WDT_Gartenblick_midnight
SETTIMERATMIDNIGHT 1
WDT_EVENTMAP:
10.0 desired-temp 10.0
11.0 desired-temp 11.0
12.0 desired-temp 12.0
13.0 desired-temp 13.0
14.0 desired-temp 14.0
15.0 desired-temp 15.0
16.0 desired-temp 16.0
17.0 desired-temp 17.0
18.0 desired-temp 18.0
19.0 desired-temp 19.0
20.0 desired-temp 20.0
21.0 desired-temp 21.0
22.0 desired-temp 22.0
23.0 desired-temp 23.0
24.0 desired-temp 24.0
8.0 desired-temp 8.0
9.0 desired-temp 9.0
boost thermostate FullPower
heat thermostate Heating
off thermostate Off
save thermostate EnergySaveHeating
helper:
daysRegExp (su|mo|tu|we|th|fr|sa|\$we|\!\$we)
daysRegExpMessage (su|mo|tu|we|th|fr|sa|$we|!$we)
SWITCHINGTIME:
WEDAYS:
5 1
6 1
profil:
profile_IDX:
0:
00:10:00 4
1:
00:10:00 2
2:
00:10:00 6
3:
00:10:00 7
4:
00:10:00 5
5:
00:10:00 1
6:
00:10:00 3
weekprofiles:
weekprofile_Gartenblick:
PROFILE default:default
PROFILE_JSON {"Fri":{"temp":["18.0"],"time":["24:00"]},"Sun":{"temp":["18.0"],"time":["24:00"]},"Tue":{"time":["24:00"],"temp":["18.0"]},"Sat":{"temp":["18.0"],"time":["24:00"]},"Mon":{"temp":["18.0"],"time":["24:00"]},"Thu":{"temp":["18.0"],"time":["24:00"]},"Wed":{"time":["24:00"],"temp":["18.0"]}}
SunAsWE 0
PROFILE_DATA:
Fri:
temp:
18.0
time:
24:00
Mon:
temp:
18.0
time:
24:00
Sat:
temp:
18.0
time:
24:00
Sun:
temp:
18.0
time:
24:00
Thu:
temp:
18.0
time:
24:00
Tue:
temp:
18.0
time:
24:00
Wed:
temp:
18.0
time:
24:00
Attributes:
WDT_eventMap off:thermostate+Off
save:thermostate+EnergySaveHeating
heat:thermostate+Heating
boost:thermostate+FullPower
8.0:desired-temp+8.0
9.0:desired-temp+9.0
10.0:desired-temp+10.0
11.0:desired-temp+11.0
12.0:desired-temp+12.0
13.0:desired-temp+13.0
14.0:desired-temp+14.0
15.0:desired-temp+15.0
16.0:desired-temp+16.0
17.0:desired-temp+17.0
18.0:desired-temp+18.0
19.0:desired-temp+19.0
20.0:desired-temp+20.0
21.0:desired-temp+21.0
22.0:desired-temp+22.0
23.0:desired-temp+23.0
24.0:desired-temp+24.0
commandTemplate set $NAME $EVENT;get $NAME thermostatMode;get $NAME setpoint 1
disable 0
userattr weekprofile
weekprofile weekproilfe_Gartenblick
Ich habe ein Thermostat mit folgender definition:
Internals:
CID wthermostat_3343395
DEF wthermostat_3343395
FUUID 63ba976e-f33f-333b-77ce-6b01a9f74ecc3359
IODev myBroker
LASTInputDev myBroker
MSGCNT 72
NAME Thermostat_JulZi
NR 379
STATE on
TYPE MQTT2_DEVICE
eventCount 32
myBroker_CONN myBroker_IP_61275
myBroker_MSGCNT 72
myBroker_TIME 2023-01-11 12:23:23
JSONMAP:
targetTemperature 0
READINGS:
2023-01-11 12:19:01 IODev myBroker
2023-01-11 12:19:23 LWT Online
2023-01-10 19:38:56 a1h 06:00
2023-01-10 19:38:56 a1t 20.00
2023-01-10 19:38:56 a2h 08:00
2023-01-10 19:38:56 a2t 21.00
2023-01-10 19:38:56 a3h 11:30
2023-01-10 19:38:56 a3t 22.00
2023-01-10 19:38:56 a4h 13:30
2023-01-10 19:38:56 a4t 22.00
2023-01-10 19:38:56 a5h 17:00
2023-01-10 19:38:56 a5t 22.00
2023-01-10 19:38:56 a6h 22:00
2023-01-10 19:38:56 a6t 15.00
2023-01-11 12:22:52 action heating
2023-01-09 19:36:16 attrTemplateVersion 20220108
2023-01-11 12:20:00 clock_epochTime 1673436000
2023-01-11 12:20:00 clock_epochTimeLocalFormatted 2023-01-11 12:20:00
2023-01-11 12:20:00 clock_ntpServer pool.ntp.org
2023-01-11 12:20:00 clock_offset 3600
2023-01-11 12:20:00 clock_timeDST 0,3,0,2,120
2023-01-11 12:20:00 clock_timeSTD 0,10,0,3,60
2023-01-11 12:20:00 clock_timeZone 99
2023-01-11 12:20:00 clock_uptime 71437
2023-01-11 12:20:00 clock_validTime true
2023-01-11 06:55:25 desired-temp 23.00
2023-01-11 12:22:51 deviceOn true
2023-01-11 12:22:51 ecoMode false
2023-01-11 12:22:51 firmware v1.22-fas
2023-01-11 12:22:51 holdState manual
2023-01-11 12:22:51 idx Thermostat_JulZi
2023-01-11 12:22:51 ip IP
2023-01-11 12:22:52 locked false
2023-01-10 11:58:42 log warning: NTP sync failed.
2023-01-11 12:20:00 log_logLevel trace
2023-01-11 12:22:52 mcuId IAYz2WK1th0cMLmL1.0.0
2023-01-11 12:22:52 mode heat
2023-01-11 12:23:23 net_rssi -75
2023-01-11 12:22:52 preset none
2023-01-11 12:22:51 schedulesMode off
2023-01-11 12:22:52 state on
2023-01-11 12:22:51 switchBackToAuto false
2023-01-11 12:22:51 targetTemperature 23.00
2023-01-11 12:19:51 temp_mean 22.50
2023-01-11 12:22:51 temperature 22.50
2023-01-10 19:38:56 u1h 06:00
2023-01-10 19:38:56 u1t 20.00
2023-01-10 19:38:56 u2h 08:00
2023-01-10 19:38:56 u2t 21.00
2023-01-10 19:38:56 u3h 11:30
2023-01-10 19:38:56 u3t 22.00
2023-01-10 19:38:56 u4h 13:30
2023-01-10 19:38:56 u4t 22.00
2023-01-10 19:38:56 u5h 17:00
2023-01-10 19:38:56 u5t 22.00
2023-01-10 19:38:56 u6h 22:00
2023-01-10 19:38:56 u6t 15.00
2023-01-10 19:38:56 w1h 06:00
2023-01-10 19:38:56 w1t 20.00
2023-01-10 19:38:56 w2h 08:00
2023-01-10 19:38:56 w2t 21.00
2023-01-10 19:38:56 w3h 11:30
2023-01-10 19:38:56 w3t 22.00
2023-01-10 19:38:56 w4h 13:30
2023-01-10 19:38:56 w4t 21.00
2023-01-10 19:38:56 w5h 17:00
2023-01-10 19:38:56 w5t 22.00
2023-01-10 19:38:56 w6h 22:00
2023-01-10 19:38:56 w6t 15.00
Attributes:
devStateIcon <a href="http://ip" target="_blank">
LWT
</a>
state
event-min-interval .*:300
event-on-change-reading .*
getList desired-temp:noArg desired-temp Thermostat_JulZi/cmnd/things/thermostat/properties/targetTemperature
icon hm-tc-it-wm-w-eu
jsonMap targetTemperature:0
model WThermostatBHT002
readingList Thermostat_JulZi/tele/LWT:.* LWT
devices/(network|clock|thermostat|logging):.* {}
Thermostat_JulZi/stat/things/network/properties:.* { json2nameValue($EVENT,'net_',$JSONMAP) }
Thermostat_JulZi/stat/things/thermostat/properties:.* { $EVENT =~ s/true/"on"/g;; $EVENT =~ s/false/"off"/g;; json2nameValue($EVENT,'',$JSONMAP) }
Thermostat_JulZi/stat/things/logging/properties:.* { json2nameValue($EVENT,'log_',$JSONMAP) }
Thermostat_JulZi/stat/things/clock/properties:.* { json2nameValue($EVENT,'clock_',$JSONMAP) }
Thermostat_JulZi/stat/things/thermostat/targetTemperature:.* desired-temp
Thermostat_JulZi/stat/things/thermostat/properties/state:.* {{state => $EVENT eq 'heating' ? 'on' : 'off'}}
wthermostat_3343395:Thermostat_JulZi/tele/log:.* log
wthermostat_3343395:Thermostat_JulZi/stat/things/thermostat/schedules:.* { json2nameValue($EVENT) }
room MQTT2_DEVICE
setList on:noArg Thermostat_JulZi/cmnd/things/thermostat/properties/deviceOn true
off:noArg Thermostat_JulZi/cmnd/things/thermostat/properties/deviceOn false
desired-temp:slider,5.0,0.5,35.0,1 Thermostat_JulZi/cmnd/things/thermostat/properties/targetTemperature $EVTPART1
mode:heat,auto,off Thermostat_JulZi/cmnd/things/thermostat/properties/mode $EVTPART1
weekprofile { FHEM::attrT_z2m_thermostat_Utils::z2t_send_Beca_weekprofile($NAME, $EVTPART1, $EVTPART2, 'Thermostat_JulZi/cmnd/things/thermostat/schedules') }
x_send_mcucommand:textField { my $payload = $EVENT;$payload =~ s/$EVTPART0 //g; qq(Thermostat_JulZi/cmnd/things/thermostat/mcucommand $payload)}
setStateList on off weekprofile
userReadings temp_mean:temperature:.* {ReadingsVal($name,"temperature",0)}
userattr weekprofile
webCmd mode:desired-temp
weekprofile Thermostat_JulZi_Plan
Jetzt habe ich mal versucht ein Modul weekprofile anzulegen:
Internals:
CONFIGFILE ./log/weekprofile-Thermostat_JulZi_WEEKPROFILE.cfg
DEF Thermostat_JulZi
FUUID 63be9b14-f33f-333b-2d28-b8321ab4ac94c3c9
NAME Thermostat_JulZi_WEEKPROFILE
NR 381
NTFY_ORDER 50-Thermostat_JulZi_WEEKPROFILE
STATE created
TYPE weekprofile
eventCount 68
MASTERDEV:
NAME Thermostat_JulZi
PROFILES:
HASH(0x32fd360)
READINGS:
2023-01-11 12:27:53 profile_count 1
2023-01-11 12:19:01 state created
SNDDEVLIST:
HASH(0x2b26ba8)
TEMPMAP:
TOPICS:
default
Attributes:
Im logfile erscheint immer die Meldung:
Thermostat_JulZi_WEEKPROFILE(assignDev): device Thermostat_JulZi not supported or defined
Meine Frage ist: Was ist die Ursache? Das Gerät ist defined und hat Attribute und userattr. Welches Kriterium muß vorhanden sein für den Support für das weekprofile Module?
Hast du FHEM nach Anlage des Attributs mal neu gestartet? (oder die DEF des weekprofile angefasst?)
Verstehe jetzt nicht ganz die Frage. Sollte ich neu starten? Nach welchem Schritt?
Jetz habe ich mal das weekprofile device gelöscht und neu gestartet:
2023.01.11 17:46:35 0: Server shutdown
2023.01.11 17:46:37 1: Including fhem.cfg
2023.01.11 17:46:37 3: telnetPort: port 7072 opened
2023.01.11 17:46:37 3: WEB: port 8083 opened
2023.01.11 17:46:37 3: WEBphone: port 8084 opened
2023.01.11 17:46:37 3: WEBtablet: port 8085 opened
2023.01.11 17:46:37 2: eventTypes: loaded 1181 lines from ./log/eventTypes.txt
2023.01.11 17:46:42 3: Opening EBUS device IP:PORT
2023.01.11 17:46:42 3: EBUS device opened
2023.01.11 17:46:43 3: tablet_ui: new ext defined infix:ftui/: dir:./www/tablet:
2023.01.11 17:46:43 3: Registering HTTPSRV tablet_ui for URL /ftui and assigned link ftui/ ...
2023.01.11 17:46:43 3: Opening myDuoFernStick device /dev/ttyUSB0
2023.01.11 17:46:43 3: Setting myDuoFernStick serial parameters to 115200,8,N,1
2023.01.11 17:46:43 3: myDuoFernStick device opened
2023.01.11 17:46:44 3: FUIP: Registering ui for URL /ui
2023.01.11 17:46:44 3: myBroker: port 1883 opened
2023.01.11 17:46:44 1: Including ./log/fhem.save
2023.01.11 17:46:44 3: ESPEasy ESPBridge: Bridge v2.18 port [TCP:IPV4:8383] opened.
2023.01.11 17:46:44 0: Featurelevel: 6.1
2023.01.11 17:46:44 0: Server started with 154 defined entities (fhem.pl:26868/2022-12-18 perl:5.028001 os:linux user:fhem pid:13614)
Dann habe ich weekprofile neu angelegt - log:
2023.01.11 17:48:55 2: Thermostat_JulZi_WEEKPROFILE(assignDev): device Thermostat_JulZi not supported or defined
Nach Anlegen erscheint die Tabelle ganz kurz, dann kommt ein profile_count = 1 Reading in weekprofile und die Wochentabelle verschwindet.
Jetzt weiß ich nicht weiter, vermute weekprofile muß sich vom Thermostat die Information holen wie die timeslots aussehen. Und das kommt nicht. Weil keine entsprechende get Funktion im Thermostat Modul vorhanden ist. Wir habe ja nur die Schreibfkt. in 99_attrT_z2m_thermostat_Utils.pm. Alles nur Vermutung!
Ah, ok, jetzt verstehe ich die Frage: Man kann ein Device vom TYPE MQTT2_DEVICE nicht als Masterdevice verwenden. Zitat aus der commandref:
ZitatHinweis: Geräte des Typs WeekdayTimer und MQTT2_DEVICE können nicht als 'Master-Gerät' verwendet werden.
Und ja, das liegt daran, dass man (jedenfalls nicht ohne weiteres) die Profile nicht abfragen kann.
OK, geht nicht. Seltsam - die Profile (topic, timeslots und Namen) der beiden Geräte sind ja bekannt. Ich habe auch schon mit mosquitto tools abgefragt und gesetzt.
Zitat von: mirror am 12 Januar 2023, 08:17:44
OK, geht nicht. Seltsam - die Profile (topic, timeslots und Namen) der beiden Geräte sind ja bekannt. Ich habe auch schon mit mosquitto tools abgefragt und gesetzt.
Finde ich nur bedingt seltsam: Man müßte vermutlich im Code nachschauen, aber da dürfte irgendeine Art Abfrage an die jeweilige "master"-Modul-Instanz stattfinden, die eine genau definierte Rückmeldung erwartet. Jedenfalls solange es diese nicht gibt, ist es für diese beiden Module eben "one way", also weekprofile=>MQTT2_DEVICE (bzw. WeekdayTimer). Finde ich aber nicht schlimm, weil man eigentlich die Profile sowieso einfacher mit weekprofile editiert, und wenn man Topics nutzt (und nicht für jedes Einzeldevice eine eigene weekprofile-Instanz anlegt), geht das auch super-easy... (Man kann afaik aber auch von weekprofile zu weekprofile transferieren).
Wir meinen wahrscheinlich das Gleiche - aber drücken uns nur anders aus.
Der entscheidende Hinweis aus diesem thread war Antwort #330 einfach das Modul weekprofile ohne device aufrufen und dann mit send_to_device ein Profil hinschicken. Dank Deiner Transferfunktion aus 99_attrT_z2m_thermostat_Utils.pm klappt das wunderbar. Nur ein timeslot shift um +1 ist noch drin. Vielleicht krieg ich das noch hin. Nach gleichem Schema werde ich den anderen Thermostaten ME81AH (8 timeslots) auch noch mit weekprofile versorgen.
Interesse das in Deiner template lib mit aufzunehmen?
Hallo Risiko!
Ich hatte in #695 schon einmal Code Vorschläge für HMCCU Thermostate geschickt, die auch eingebaut wurden.
Nun habe ich einen HM IP Thermostat und da haben die Weekprofiles leider nicht mehr funktioniert.
Nach einigen Analysen habe ich es nun hinbekommen, dass es auch mit dem HM IP funktioniert und wollte die Änderungen hier teilen. Es wäre schön, wenn Du prüfen könntest, ob sie evtl. in deine Lösung wandern könnten.
Hier die Anpassungen in der Funktion weekprofile_sendDevProfile (ca. Zeile 492):
} elsif ($type =~ /HMCCU.*/){
$cmd .= "set $device config device" if ($type eq "HMCCU_HM");
#CHANGED: device oder 1 geht nicht
$cmd .= "set $device config" if ($type eq "HMCCU_IP");
my $k=0;
my $dayCnt = scalar(@dayToTransfer);
my $prefix = weekprofile_get_prefix_HM($device,"ENDTIME_SUNDAY_1",$me);
#CHANGED: Präfix ist R-P1_ aber das R- darf nicht mitgeschickt werden
if ($type eq "HMCCU_IP") {
$prefix =~ s/R-//;
}
else {
$prefix = ""; # always no prefix by set #msg1113658
}
if (!defined($prefix)) {
...
Es waren 2 Probleme:
Einmal hinter dem config ging weder device noch 1. Weglassen hat funktioniert.
Und die Readings haben alle den Präfix R-P1_ aber beim Senden darf man nur P1_ verwenden.
Kannst Du das bitte prüfen?
Danke & Grüße,
Roger
Hallo nach dem Umstieg nach debmatic, zuvor CUL_HM, geht in meinem Testsystem für den Gerätetyp HM-TC-IT-WM-W-EU das besagte weekprofil leider nicht mehr. Das Wochenprofil kann ich lesen über das Device welches über HMCCUCHN in Fhem eingebunden ist. Nachdem ich die ccuflags
showMasterReadings,showDeviceReadings,showServiceReadings gesetzt habe bekomme ich die Werte auch im Device anzeigt
Internals:
DEF REQ0838507:2
FUUID 651d829a-f33f-e238-a739-aae64fb6b0453801
IODev Homematic
NAME xx_th_Testsystem_Climate
NR 354
STATE 22.3 °C |
52.0 %
MANU-MODE
TYPE HMCCUCHN
ccuaddr REQ0838507:2
ccudevstate active
ccuif BidCos-RF
ccuname HM-TC-IT-WM-W-EU REQ0838507:2
ccurolectrl THERMALCONTROL_TRANSMIT
ccurolestate THERMALCONTROL_TRANSMIT
ccusubtype HM-TC-IT-WM-W-EU
ccutype HM-TC-IT-WM-W-EU
eventCount 166
firmware 1.4
readonly no
OLDREADINGS:
READINGS:
2023-10-27 15:20:13 ACTUAL_HUMIDITY 52.0
2023-10-27 15:20:13 ACTUAL_TEMPERATURE 22.3
2023-10-27 13:41:55 AES_KEY on
2023-10-27 15:15:06 BATTERY_STATE 3.0
2023-10-27 15:15:06 BOOST_STATE 0
2023-10-27 15:15:06 COMMUNICATION_REPORTING false
2023-10-27 13:41:55 CONFIG_PENDING false
2023-10-27 15:15:06 CONTROL_MODE MANU-MODE
2023-10-27 13:41:55 DEVICE_IN_BOOTLOADER false
2023-10-27 13:41:55 INHIBIT false
2023-10-27 13:41:55 LOWBAT ok
2023-10-27 15:15:06 LOWBAT_REPORTING false
2023-10-27 15:20:33 Mode MANU-MODE
2023-10-27 15:15:06 PARTY_START_DAY 1
2023-10-27 15:15:06 PARTY_START_MONTH 1
2023-10-27 15:15:06 PARTY_START_TIME 00:00
2023-10-27 15:15:06 PARTY_START_YEAR 0
2023-10-27 15:15:06 PARTY_STOP_DAY 1
2023-10-27 15:15:06 PARTY_STOP_MONTH 1
2023-10-27 15:15:06 PARTY_STOP_TIME 00:00
2023-10-27 15:15:06 PARTY_STOP_YEAR 0
2023-10-27 15:15:06 PARTY_TEMPERATURE 5.0
2023-10-27 15:02:18 R-BOOST_AFTER_WINDOW_OPEN 1
2023-10-27 15:02:18 R-BOOST_TIME_PERIOD 4
2023-10-27 15:02:18 R-BURST_RX 1
2023-10-27 15:02:18 R-BUTTON_LOCK 1
2023-10-27 15:02:18 R-CYCLIC_INFO_MSG 1
2023-10-27 15:02:18 R-CYCLIC_INFO_MSG_DIS 0
2023-10-27 15:02:18 R-DAYLIGHT_SAVING_TIME 1
2023-10-27 15:02:18 R-DISPLAY_INFORMATION 0
2023-10-27 15:02:18 R-GLOBAL_BUTTON_LOCK 0
2023-10-27 15:02:18 R-HEATING_COOLING 0
2023-10-27 15:02:18 R-LOCAL_RESET_DISABLE 0
2023-10-27 15:02:18 R-LOW_BAT_LIMIT 2.2
2023-10-27 15:02:18 R-MANU_MODE_PRIORITIZATION 1
2023-10-27 15:02:18 R-MIN_MAX_VALUE_NOT_RELEVANT_FOR_MANU_MODE 0
2023-10-27 15:02:18 R-MODUS_BUTTON_LOCK 0
2023-10-27 15:02:18 R-P1_ENDTIME_FRIDAY_1 06:00
2023-10-27 15:02:18 R-P1_ENDTIME_FRIDAY_10 24:00
2023-10-27 15:02:18 R-P1_ENDTIME_FRIDAY_11 24:00
2023-10-27 15:02:18 R-P1_ENDTIME_FRIDAY_12 24:00
2023-10-27 15:02:18 R-P1_ENDTIME_FRIDAY_13 24:00
2023-10-27 15:02:18 R-P1_ENDTIME_FRIDAY_2 09:00
2023-10-27 15:02:18 R-P1_ENDTIME_FRIDAY_3 18:00
2023-10-27 15:02:18 R-P1_ENDTIME_FRIDAY_4 22:30
2023-10-27 15:02:18 R-P1_ENDTIME_FRIDAY_5 24:00
2023-10-27 15:02:18 R-P1_ENDTIME_FRIDAY_6 24:00
2023-10-27 15:02:18 R-P1_ENDTIME_FRIDAY_7 24:00
2023-10-27 15:02:18 R-P1_ENDTIME_FRIDAY_8 24:00
2023-10-27 15:02:18 R-P1_ENDTIME_FRIDAY_9 24:00
2023-10-27 15:02:18 R-P1_ENDTIME_MONDAY_1 06:00
2023-10-27 15:02:18 R-P1_ENDTIME_MONDAY_10 24:00
2023-10-27 15:02:18 R-P1_ENDTIME_MONDAY_11 24:00
2023-10-27 15:02:18 R-P1_ENDTIME_MONDAY_12 24:00
2023-10-27 15:02:18 R-P1_ENDTIME_MONDAY_13 24:00
2023-10-27 15:02:18 R-P1_ENDTIME_MONDAY_2 09:00
2023-10-27 15:02:18 R-P1_ENDTIME_MONDAY_3 18:00
2023-10-27 15:02:18 R-P1_ENDTIME_MONDAY_4 22:30
2023-10-27 15:02:18 R-P1_ENDTIME_MONDAY_5 24:00
2023-10-27 15:02:18 R-P1_ENDTIME_MONDAY_6 24:00
2023-10-27 15:02:18 R-P1_ENDTIME_MONDAY_7 24:00
2023-10-27 15:02:18 R-P1_ENDTIME_MONDAY_8 24:00
2023-10-27 15:02:18 R-P1_ENDTIME_MONDAY_9 24:00
2023-10-27 15:02:18 R-P1_ENDTIME_SATURDAY_1 06:00
2023-10-27 15:02:18 R-P1_ENDTIME_SATURDAY_10 24:00
2023-10-27 15:02:18 R-P1_ENDTIME_SATURDAY_11 24:00
2023-10-27 15:02:18 R-P1_ENDTIME_SATURDAY_12 24:00
2023-10-27 15:02:18 R-P1_ENDTIME_SATURDAY_13 24:00
2023-10-27 15:02:18 R-P1_ENDTIME_SATURDAY_2 09:00
2023-10-27 15:02:18 R-P1_ENDTIME_SATURDAY_3 18:00
2023-10-27 15:02:18 R-P1_ENDTIME_SATURDAY_4 22:30
2023-10-27 15:02:18 R-P1_ENDTIME_SATURDAY_5 24:00
2023-10-27 15:02:18 R-P1_ENDTIME_SATURDAY_6 24:00
2023-10-27 15:02:18 R-P1_ENDTIME_SATURDAY_7 24:00
2023-10-27 15:02:18 R-P1_ENDTIME_SATURDAY_8 24:00
2023-10-27 15:02:18 R-P1_ENDTIME_SATURDAY_9 24:00
2023-10-27 15:02:18 R-P1_ENDTIME_SUNDAY_1 06:00
2023-10-27 15:02:18 R-P1_ENDTIME_SUNDAY_10 24:00
2023-10-27 15:02:18 R-P1_ENDTIME_SUNDAY_11 24:00
2023-10-27 15:02:18 R-P1_ENDTIME_SUNDAY_12 24:00
2023-10-27 15:02:18 R-P1_ENDTIME_SUNDAY_13 24:00
2023-10-27 15:02:18 R-P1_ENDTIME_SUNDAY_2 09:00
2023-10-27 15:02:18 R-P1_ENDTIME_SUNDAY_3 18:00
2023-10-27 15:02:18 R-P1_ENDTIME_SUNDAY_4 22:30
2023-10-27 15:02:18 R-P1_ENDTIME_SUNDAY_5 24:00
2023-10-27 15:02:18 R-P1_ENDTIME_SUNDAY_6 24:00
2023-10-27 15:02:18 R-P1_ENDTIME_SUNDAY_7 24:00
2023-10-27 15:02:18 R-P1_ENDTIME_SUNDAY_8 24:00
2023-10-27 15:02:18 R-P1_ENDTIME_SUNDAY_9 24:00
2023-10-27 15:02:18 R-P1_ENDTIME_THURSDAY_1 06:00
2023-10-27 15:02:18 R-P1_ENDTIME_THURSDAY_10 24:00
2023-10-27 15:02:18 R-P1_ENDTIME_THURSDAY_11 24:00
2023-10-27 15:02:18 R-P1_ENDTIME_THURSDAY_12 24:00
2023-10-27 15:02:18 R-P1_ENDTIME_THURSDAY_13 24:00
2023-10-27 15:02:18 R-P1_ENDTIME_THURSDAY_2 09:00
2023-10-27 15:02:18 R-P1_ENDTIME_THURSDAY_3 18:00
2023-10-27 15:02:18 R-P1_ENDTIME_THURSDAY_4 22:30
2023-10-27 15:02:18 R-P1_ENDTIME_THURSDAY_5 24:00
2023-10-27 15:02:18 R-P1_ENDTIME_THURSDAY_6 24:00
2023-10-27 15:02:18 R-P1_ENDTIME_THURSDAY_7 24:00
2023-10-27 15:02:18 R-P1_ENDTIME_THURSDAY_8 24:00
2023-10-27 15:02:18 R-P1_ENDTIME_THURSDAY_9 24:00
2023-10-27 15:02:18 R-P1_ENDTIME_TUESDAY_1 06:00
2023-10-27 15:02:18 R-P1_ENDTIME_TUESDAY_10 24:00
2023-10-27 15:02:18 R-P1_ENDTIME_TUESDAY_11 24:00
2023-10-27 15:02:18 R-P1_ENDTIME_TUESDAY_12 24:00
2023-10-27 15:02:18 R-P1_ENDTIME_TUESDAY_13 24:00
2023-10-27 15:02:18 R-P1_ENDTIME_TUESDAY_2 09:00
2023-10-27 15:02:18 R-P1_ENDTIME_TUESDAY_3 18:00
2023-10-27 15:02:18 R-P1_ENDTIME_TUESDAY_4 22:30
2023-10-27 15:02:18 R-P1_ENDTIME_TUESDAY_5 24:00
2023-10-27 15:02:18 R-P1_ENDTIME_TUESDAY_6 24:00
2023-10-27 15:02:18 R-P1_ENDTIME_TUESDAY_7 24:00
2023-10-27 15:02:18 R-P1_ENDTIME_TUESDAY_8 24:00
2023-10-27 15:02:18 R-P1_ENDTIME_TUESDAY_9 24:00
2023-10-27 15:02:18 R-P1_ENDTIME_WEDNESDAY_1 06:00
2023-10-27 15:02:18 R-P1_ENDTIME_WEDNESDAY_10 24:00
2023-10-27 15:02:18 R-P1_ENDTIME_WEDNESDAY_11 24:00
2023-10-27 15:02:18 R-P1_ENDTIME_WEDNESDAY_12 24:00
2023-10-27 15:02:18 R-P1_ENDTIME_WEDNESDAY_13 24:00
2023-10-27 15:02:18 R-P1_ENDTIME_WEDNESDAY_2 09:00
2023-10-27 15:02:18 R-P1_ENDTIME_WEDNESDAY_3 18:00
2023-10-27 15:02:18 R-P1_ENDTIME_WEDNESDAY_4 22:30
2023-10-27 15:02:18 R-P1_ENDTIME_WEDNESDAY_5 24:00
2023-10-27 15:02:18 R-P1_ENDTIME_WEDNESDAY_6 24:00
2023-10-27 15:02:18 R-P1_ENDTIME_WEDNESDAY_7 24:00
2023-10-27 15:02:18 R-P1_ENDTIME_WEDNESDAY_8 24:00
2023-10-27 15:02:18 R-P1_ENDTIME_WEDNESDAY_9 24:00
2023-10-27 15:02:18 R-P1_TEMPERATURE_FRIDAY_1 17.0
2023-10-27 15:02:18 R-P1_TEMPERATURE_FRIDAY_10 17.0
2023-10-27 15:02:18 R-P1_TEMPERATURE_FRIDAY_11 17.0
2023-10-27 15:02:18 R-P1_TEMPERATURE_FRIDAY_12 17.0
2023-10-27 15:02:18 R-P1_TEMPERATURE_FRIDAY_13 17.0
2023-10-27 15:02:18 R-P1_TEMPERATURE_FRIDAY_2 19.0
2023-10-27 15:02:18 R-P1_TEMPERATURE_FRIDAY_3 19.5
2023-10-27 15:02:18 R-P1_TEMPERATURE_FRIDAY_4 19.0
2023-10-27 15:02:18 R-P1_TEMPERATURE_FRIDAY_5 18.0
2023-10-27 15:02:18 R-P1_TEMPERATURE_FRIDAY_6 17.0
2023-10-27 15:02:18 R-P1_TEMPERATURE_FRIDAY_7 17.0
2023-10-27 15:02:18 R-P1_TEMPERATURE_FRIDAY_8 17.0
2023-10-27 15:02:18 R-P1_TEMPERATURE_FRIDAY_9 17.0
2023-10-27 15:02:18 R-P1_TEMPERATURE_MONDAY_1 17.0
2023-10-27 15:02:18 R-P1_TEMPERATURE_MONDAY_10 17.0
2023-10-27 15:02:18 R-P1_TEMPERATURE_MONDAY_11 17.0
2023-10-27 15:02:18 R-P1_TEMPERATURE_MONDAY_12 17.0
2023-10-27 15:02:18 R-P1_TEMPERATURE_MONDAY_13 17.0
2023-10-27 15:02:18 R-P1_TEMPERATURE_MONDAY_2 19.0
2023-10-27 15:02:18 R-P1_TEMPERATURE_MONDAY_3 19.5
2023-10-27 15:02:18 R-P1_TEMPERATURE_MONDAY_4 19.0
2023-10-27 15:02:18 R-P1_TEMPERATURE_MONDAY_5 18.0
2023-10-27 15:02:18 R-P1_TEMPERATURE_MONDAY_6 17.0
2023-10-27 15:02:18 R-P1_TEMPERATURE_MONDAY_7 17.0
2023-10-27 15:02:18 R-P1_TEMPERATURE_MONDAY_8 17.0
2023-10-27 15:02:18 R-P1_TEMPERATURE_MONDAY_9 17.0
2023-10-27 15:02:18 R-P1_TEMPERATURE_SATURDAY_1 17.0
2023-10-27 15:02:18 R-P1_TEMPERATURE_SATURDAY_10 17.0
2023-10-27 15:02:18 R-P1_TEMPERATURE_SATURDAY_11 17.0
2023-10-27 15:02:18 R-P1_TEMPERATURE_SATURDAY_12 17.0
2023-10-27 15:02:18 R-P1_TEMPERATURE_SATURDAY_13 17.0
2023-10-27 15:02:18 R-P1_TEMPERATURE_SATURDAY_2 19.0
2023-10-27 15:02:18 R-P1_TEMPERATURE_SATURDAY_3 19.5
2023-10-27 15:02:18 R-P1_TEMPERATURE_SATURDAY_4 19.0
2023-10-27 15:02:18 R-P1_TEMPERATURE_SATURDAY_5 18.0
2023-10-27 15:02:18 R-P1_TEMPERATURE_SATURDAY_6 17.0
2023-10-27 15:02:18 R-P1_TEMPERATURE_SATURDAY_7 17.0
2023-10-27 15:02:18 R-P1_TEMPERATURE_SATURDAY_8 17.0
2023-10-27 15:02:18 R-P1_TEMPERATURE_SATURDAY_9 17.0
2023-10-27 15:02:18 R-P1_TEMPERATURE_SUNDAY_1 17.0
2023-10-27 15:02:18 R-P1_TEMPERATURE_SUNDAY_10 17.0
2023-10-27 15:02:18 R-P1_TEMPERATURE_SUNDAY_11 17.0
2023-10-27 15:02:18 R-P1_TEMPERATURE_SUNDAY_12 17.0
2023-10-27 15:02:18 R-P1_TEMPERATURE_SUNDAY_13 17.0
2023-10-27 15:02:18 R-P1_TEMPERATURE_SUNDAY_2 19.0
2023-10-27 15:02:18 R-P1_TEMPERATURE_SUNDAY_3 19.5
2023-10-27 15:02:18 R-P1_TEMPERATURE_SUNDAY_4 19.0
2023-10-27 15:02:18 R-P1_TEMPERATURE_SUNDAY_5 18.0
2023-10-27 15:02:18 R-P1_TEMPERATURE_SUNDAY_6 17.0
2023-10-27 15:02:18 R-P1_TEMPERATURE_SUNDAY_7 17.0
2023-10-27 15:02:18 R-P1_TEMPERATURE_SUNDAY_8 17.0
2023-10-27 15:02:18 R-P1_TEMPERATURE_SUNDAY_9 17.0
2023-10-27 15:02:18 R-P1_TEMPERATURE_THURSDAY_1 17.0
2023-10-27 15:02:18 R-P1_TEMPERATURE_THURSDAY_10 17.0
2023-10-27 15:02:18 R-P1_TEMPERATURE_THURSDAY_11 17.0
2023-10-27 15:02:18 R-P1_TEMPERATURE_THURSDAY_12 17.0
2023-10-27 15:02:18 R-P1_TEMPERATURE_THURSDAY_13 17.0
2023-10-27 15:02:18 R-P1_TEMPERATURE_THURSDAY_2 19.0
2023-10-27 15:02:18 R-P1_TEMPERATURE_THURSDAY_3 19.5
2023-10-27 15:02:18 R-P1_TEMPERATURE_THURSDAY_4 19.0
2023-10-27 15:02:18 R-P1_TEMPERATURE_THURSDAY_5 18.0
2023-10-27 15:02:18 R-P1_TEMPERATURE_THURSDAY_6 17.0
2023-10-27 15:02:18 R-P1_TEMPERATURE_THURSDAY_7 17.0
2023-10-27 15:02:18 R-P1_TEMPERATURE_THURSDAY_8 17.0
2023-10-27 15:02:18 R-P1_TEMPERATURE_THURSDAY_9 17.0
2023-10-27 15:02:18 R-P1_TEMPERATURE_TUESDAY_1 17.0
2023-10-27 15:02:18 R-P1_TEMPERATURE_TUESDAY_10 17.0
2023-10-27 15:02:18 R-P1_TEMPERATURE_TUESDAY_11 17.0
2023-10-27 15:02:18 R-P1_TEMPERATURE_TUESDAY_12 17.0
2023-10-27 15:02:18 R-P1_TEMPERATURE_TUESDAY_13 17.0
2023-10-27 15:02:18 R-P1_TEMPERATURE_TUESDAY_2 19.0
2023-10-27 15:02:18 R-P1_TEMPERATURE_TUESDAY_3 19.5
2023-10-27 15:02:18 R-P1_TEMPERATURE_TUESDAY_4 19.0
2023-10-27 15:02:18 R-P1_TEMPERATURE_TUESDAY_5 18.0
2023-10-27 15:02:18 R-P1_TEMPERATURE_TUESDAY_6 17.0
2023-10-27 15:02:18 R-P1_TEMPERATURE_TUESDAY_7 17.0
2023-10-27 15:02:18 R-P1_TEMPERATURE_TUESDAY_8 17.0
2023-10-27 15:02:18 R-P1_TEMPERATURE_TUESDAY_9 17.0
2023-10-27 15:02:18 R-P1_TEMPERATURE_WEDNESDAY_1 17.0
2023-10-27 15:02:18 R-P1_TEMPERATURE_WEDNESDAY_10 17.0
2023-10-27 15:02:18 R-P1_TEMPERATURE_WEDNESDAY_11 17.0
2023-10-27 15:02:18 R-P1_TEMPERATURE_WEDNESDAY_12 17.0
2023-10-27 15:02:18 R-P1_TEMPERATURE_WEDNESDAY_13 17.0
2023-10-27 15:02:18 R-P1_TEMPERATURE_WEDNESDAY_2 19.0
2023-10-27 15:02:18 R-P1_TEMPERATURE_WEDNESDAY_3 19.5
2023-10-27 15:02:18 R-P1_TEMPERATURE_WEDNESDAY_4 19.0
2023-10-27 15:02:18 R-P1_TEMPERATURE_WEDNESDAY_5 18.0
2023-10-27 15:02:18 R-P1_TEMPERATURE_WEDNESDAY_6 17.0
2023-10-27 15:02:18 R-P1_TEMPERATURE_WEDNESDAY_7 17.0
2023-10-27 15:02:18 R-P1_TEMPERATURE_WEDNESDAY_8 17.0
2023-10-27 15:02:18 R-P1_TEMPERATURE_WEDNESDAY_9 17.0
2023-10-27 15:02:18 R-P2_ENDTIME_FRIDAY_1 24:00
2023-10-27 15:02:18 R-P2_ENDTIME_FRIDAY_10 24:00
2023-10-27 15:02:18 R-P2_ENDTIME_FRIDAY_11 24:00
2023-10-27 15:02:18 R-P2_ENDTIME_FRIDAY_12 24:00
2023-10-27 15:02:18 R-P2_ENDTIME_FRIDAY_13 24:00
2023-10-27 15:02:18 R-P2_ENDTIME_FRIDAY_2 24:00
2023-10-27 15:02:18 R-P2_ENDTIME_FRIDAY_3 24:00
2023-10-27 15:02:18 R-P2_ENDTIME_FRIDAY_4 24:00
2023-10-27 15:02:18 R-P2_ENDTIME_FRIDAY_5 24:00
2023-10-27 15:02:18 R-P2_ENDTIME_FRIDAY_6 24:00
2023-10-27 15:02:18 R-P2_ENDTIME_FRIDAY_7 24:00
2023-10-27 15:02:18 R-P2_ENDTIME_FRIDAY_8 24:00
2023-10-27 15:02:18 R-P2_ENDTIME_FRIDAY_9 24:00
2023-10-27 15:02:18 R-P2_ENDTIME_MONDAY_1 24:00
2023-10-27 15:02:18 R-P2_ENDTIME_MONDAY_10 24:00
2023-10-27 15:02:18 R-P2_ENDTIME_MONDAY_11 24:00
2023-10-27 15:02:18 R-P2_ENDTIME_MONDAY_12 24:00
2023-10-27 15:02:18 R-P2_ENDTIME_MONDAY_13 24:00
2023-10-27 15:02:18 R-P2_ENDTIME_MONDAY_2 24:00
2023-10-27 15:02:18 R-P2_ENDTIME_MONDAY_3 24:00
2023-10-27 15:02:18 R-P2_ENDTIME_MONDAY_4 24:00
2023-10-27 15:02:18 R-P2_ENDTIME_MONDAY_5 24:00
2023-10-27 15:02:18 R-P2_ENDTIME_MONDAY_6 24:00
2023-10-27 15:02:18 R-P2_ENDTIME_MONDAY_7 24:00
2023-10-27 15:02:18 R-P2_ENDTIME_MONDAY_8 24:00
2023-10-27 15:02:18 R-P2_ENDTIME_MONDAY_9 24:00
2023-10-27 15:02:18 R-P2_ENDTIME_SATURDAY_1 24:00
2023-10-27 15:02:18 R-P2_ENDTIME_SATURDAY_10 24:00
2023-10-27 15:02:18 R-P2_ENDTIME_SATURDAY_11 24:00
2023-10-27 15:02:18 R-P2_ENDTIME_SATURDAY_12 24:00
2023-10-27 15:02:18 R-P2_ENDTIME_SATURDAY_13 24:00
2023-10-27 15:02:18 R-P2_ENDTIME_SATURDAY_2 24:00
2023-10-27 15:02:18 R-P2_ENDTIME_SATURDAY_3 24:00
2023-10-27 15:02:18 R-P2_ENDTIME_SATURDAY_4 24:00
2023-10-27 15:02:18 R-P2_ENDTIME_SATURDAY_5 24:00
2023-10-27 15:02:18 R-P2_ENDTIME_SATURDAY_6 24:00
2023-10-27 15:02:18 R-P2_ENDTIME_SATURDAY_7 24:00
2023-10-27 15:02:18 R-P2_ENDTIME_SATURDAY_8 24:00
2023-10-27 15:02:18 R-P2_ENDTIME_SATURDAY_9 24:00
2023-10-27 15:02:18 R-P2_ENDTIME_SUNDAY_1 24:00
2023-10-27 15:02:18 R-P2_ENDTIME_SUNDAY_10 24:00
2023-10-27 15:02:18 R-P2_ENDTIME_SUNDAY_11 24:00
2023-10-27 15:02:18 R-P2_ENDTIME_SUNDAY_12 24:00
2023-10-27 15:02:18 R-P2_ENDTIME_SUNDAY_13 24:00
2023-10-27 15:02:18 R-P2_ENDTIME_SUNDAY_2 24:00
2023-10-27 15:02:18 R-P2_ENDTIME_SUNDAY_3 24:00
2023-10-27 15:02:18 R-P2_ENDTIME_SUNDAY_4 24:00
2023-10-27 15:02:18 R-P2_ENDTIME_SUNDAY_5 24:00
2023-10-27 15:02:18 R-P2_ENDTIME_SUNDAY_6 24:00
2023-10-27 15:02:18 R-P2_ENDTIME_SUNDAY_7 24:00
2023-10-27 15:02:18 R-P2_ENDTIME_SUNDAY_8 24:00
2023-10-27 15:02:18 R-P2_ENDTIME_SUNDAY_9 24:00
2023-10-27 15:02:18 R-P2_ENDTIME_THURSDAY_1 24:00
2023-10-27 15:02:18 R-P2_ENDTIME_THURSDAY_10 24:00
2023-10-27 15:02:18 R-P2_ENDTIME_THURSDAY_11 24:00
2023-10-27 15:02:18 R-P2_ENDTIME_THURSDAY_12 24:00
2023-10-27 15:02:18 R-P2_ENDTIME_THURSDAY_13 24:00
2023-10-27 15:02:18 R-P2_ENDTIME_THURSDAY_2 24:00
2023-10-27 15:02:18 R-P2_ENDTIME_THURSDAY_3 24:00
2023-10-27 15:02:18 R-P2_ENDTIME_THURSDAY_4 24:00
2023-10-27 15:02:18 R-P2_ENDTIME_THURSDAY_5 24:00
2023-10-27 15:02:18 R-P2_ENDTIME_THURSDAY_6 24:00
2023-10-27 15:02:18 R-P2_ENDTIME_THURSDAY_7 24:00
2023-10-27 15:02:18 R-P2_ENDTIME_THURSDAY_8 24:00
2023-10-27 15:02:18 R-P2_ENDTIME_THURSDAY_9 24:00
2023-10-27 15:02:18 R-P2_ENDTIME_TUESDAY_1 24:00
2023-10-27 15:02:18 R-P2_ENDTIME_TUESDAY_10 24:00
2023-10-27 15:02:18 R-P2_ENDTIME_TUESDAY_11 24:00
2023-10-27 15:02:18 R-P2_ENDTIME_TUESDAY_12 24:00
2023-10-27 15:02:18 R-P2_ENDTIME_TUESDAY_13 24:00
2023-10-27 15:02:18 R-P2_ENDTIME_TUESDAY_2 24:00
2023-10-27 15:02:18 R-P2_ENDTIME_TUESDAY_3 24:00
2023-10-27 15:02:18 R-P2_ENDTIME_TUESDAY_4 24:00
2023-10-27 15:02:18 R-P2_ENDTIME_TUESDAY_5 24:00
2023-10-27 15:02:18 R-P2_ENDTIME_TUESDAY_6 24:00
2023-10-27 15:02:18 R-P2_ENDTIME_TUESDAY_7 24:00
2023-10-27 15:02:18 R-P2_ENDTIME_TUESDAY_8 24:00
2023-10-27 15:02:18 R-P2_ENDTIME_TUESDAY_9 24:00
2023-10-27 15:02:18 R-P2_ENDTIME_WEDNESDAY_1 24:00
2023-10-27 15:02:18 R-P2_ENDTIME_WEDNESDAY_10 24:00
2023-10-27 15:02:18 R-P2_ENDTIME_WEDNESDAY_11 24:00
2023-10-27 15:02:18 R-P2_ENDTIME_WEDNESDAY_12 24:00
2023-10-27 15:02:18 R-P2_ENDTIME_WEDNESDAY_13 24:00
2023-10-27 15:02:18 R-P2_ENDTIME_WEDNESDAY_2 24:00
2023-10-27 15:02:18 R-P2_ENDTIME_WEDNESDAY_3 24:00
2023-10-27 15:02:18 R-P2_ENDTIME_WEDNESDAY_4 24:00
2023-10-27 15:02:18 R-P2_ENDTIME_WEDNESDAY_5 24:00
2023-10-27 15:02:18 R-P2_ENDTIME_WEDNESDAY_6 24:00
2023-10-27 15:02:18 R-P2_ENDTIME_WEDNESDAY_7 24:00
2023-10-27 15:02:18 R-P2_ENDTIME_WEDNESDAY_8 24:00
2023-10-27 15:02:18 R-P2_ENDTIME_WEDNESDAY_9 24:00
2023-10-27 15:02:18 R-P2_TEMPERATURE_FRIDAY_1 17.0
2023-10-27 15:02:18 R-P2_TEMPERATURE_FRIDAY_10 17.0
2023-10-27 15:02:18 R-P2_TEMPERATURE_FRIDAY_11 17.0
2023-10-27 15:02:18 R-P2_TEMPERATURE_FRIDAY_12 17.0
2023-10-27 15:02:18 R-P2_TEMPERATURE_FRIDAY_13 17.0
Nach dem ich dann das weekprofile aufrufe passiert das Folgende: siehe weekprofile.png Bild
Was auffällt ist das die Stundenangabe zu Minuten werden und natürlich kann ich auch kein Profil schreiben.
Im Device siehe "list" Code werden die Stunden und Temperaturangaben aber richtig angezeigt.
Vielleicht hilft das bei der Fehlersuche.
Eigentlich nutze ich nur aufgrund der Erweiterung auf HM-IP die CCU.
Dabei sind mir noch ein paar Dinge aufgefallen.
Es wird kein Model angezeigt, auch kann man kein MAX/Min oder Komfort/ECO Temp und auch keine Tastensperre setzen. Im "list" sieht man die Parameter doch leider kann man diese nicht über fhem setzen in Verbindung mit debmatic, oder doch? Mit meiner jetzigen Installation CUL_HM (VCCU) geht das. Vielleicht kann mir jemand einen Tipp geben, wo ich das Thema platzieren kann oder hat sogar eine Lösung für mich. Jedenfalls schonmal Danke euch Alle
Zitat von: rogerknop am 15 Oktober 2023, 19:33:48Hallo Risiko!
Ich hatte in #695 schon einmal Code Vorschläge für HMCCU Thermostate geschickt, die auch eingebaut wurden.
Nun habe ich einen HM IP Thermostat und da haben die Weekprofiles leider nicht mehr funktioniert.
Nach einigen Analysen habe ich es nun hinbekommen, dass es auch mit dem HM IP funktioniert und wollte die Änderungen hier teilen. Es wäre schön, wenn Du prüfen könntest, ob sie evtl. in deine Lösung wandern könnten.
Hier die Anpassungen in der Funktion weekprofile_sendDevProfile (ca. Zeile 492):
} elsif ($type =~ /HMCCU.*/){
$cmd .= "set $device config device" if ($type eq "HMCCU_HM");
#CHANGED: device oder 1 geht nicht
$cmd .= "set $device config" if ($type eq "HMCCU_IP");
my $k=0;
my $dayCnt = scalar(@dayToTransfer);
my $prefix = weekprofile_get_prefix_HM($device,"ENDTIME_SUNDAY_1",$me);
#CHANGED: Präfix ist R-P1_ aber das R- darf nicht mitgeschickt werden
if ($type eq "HMCCU_IP") {
$prefix =~ s/R-//;
}
else {
$prefix = ""; # always no prefix by set #msg1113658
}
if (!defined($prefix)) {
...
Es waren 2 Probleme:
Einmal hinter dem config ging weder device noch 1. Weglassen hat funktioniert.
Und die Readings haben alle den Präfix R-P1_ aber beim Senden darf man nur P1_ verwenden.
Kannst Du das bitte prüfen?
Danke & Grüße,
Roger
Bei mir war das ähnlich, allerdings haben die Readings bei mir den Präfix "R-1.P1_" und ich brauche die 1... bei mir also nur folgende Ergänzung:
my $prefix = weekprofile_get_prefix_HM($device,"ENDTIME_SUNDAY_1",$me);
#CHANGED: Präfix ist R-P1_ aber das R- darf nicht mitgeschickt werden
if ($type eq "HMCCU_IP") {
$prefix =~ s/R-1\.//;
}
else {
$prefix = ""; # always no prefix by set #msg1113658
}
Was steht bei dir in "ccureadingfilter"?
Sorry für die späte Reaktion.
Habe leider nicht viel Zeit für das Thema und es ist leider für mich auch sehr unwichtig geworden.
Es sieht ja wieder mal so aus, dass es bei HM nicht eindeutig ist. Wie kann/soll man das genau unterscheiden können?
Reading: R-1.P1_ vs R-P1_ was ist richtig bei diesem Typ und was ist mit der aktuell umgesetzten Variante?
Zitat von: rogerknop am 15 Oktober 2023, 19:33:48Bei mir war das ähnlich, allerdings haben die Readings bei mir den Präfix "R-1.P1_" und ich brauche die 1...
Also wa ist nun "richtig"?
Evtl. weil ich die CCU2 nutze!?
Oder Firmware Update?
Die alte Änderung für die nicht IP Geräte #msg1191311 musste ich nun nämlich wieder ausbauen :-(
Das mit der Homematic API erscheint mir nicht gerade sehr stabil.
Grüße, Roger
Zitat von: KernSani am 30 November 2023, 23:18:00Zitat von: rogerknop am 15 Oktober 2023, 19:33:48Hallo Risiko!
Ich hatte in #695 schon einmal Code Vorschläge für HMCCU Thermostate geschickt, die auch eingebaut wurden.
Nun habe ich einen HM IP Thermostat und da haben die Weekprofiles leider nicht mehr funktioniert.
Nach einigen Analysen habe ich es nun hinbekommen, dass es auch mit dem HM IP funktioniert und wollte die Änderungen hier teilen. Es wäre schön, wenn Du prüfen könntest, ob sie evtl. in deine Lösung wandern könnten.
Hier die Anpassungen in der Funktion weekprofile_sendDevProfile (ca. Zeile 492):
} elsif ($type =~ /HMCCU.*/){
$cmd .= "set $device config device" if ($type eq "HMCCU_HM");
#CHANGED: device oder 1 geht nicht
$cmd .= "set $device config" if ($type eq "HMCCU_IP");
my $k=0;
my $dayCnt = scalar(@dayToTransfer);
my $prefix = weekprofile_get_prefix_HM($device,"ENDTIME_SUNDAY_1",$me);
#CHANGED: Präfix ist R-P1_ aber das R- darf nicht mitgeschickt werden
if ($type eq "HMCCU_IP") {
$prefix =~ s/R-//;
}
else {
$prefix = ""; # always no prefix by set #msg1113658
}
if (!defined($prefix)) {
...
Es waren 2 Probleme:
Einmal hinter dem config ging weder device noch 1. Weglassen hat funktioniert.
Und die Readings haben alle den Präfix R-P1_ aber beim Senden darf man nur P1_ verwenden.
Kannst Du das bitte prüfen?
Danke & Grüße,
Roger
Bei mir war das ähnlich, allerdings haben die Readings bei mir den Präfix "R-1.P1_" und ich brauche die 1... bei mir also nur folgende Ergänzung:
my $prefix = weekprofile_get_prefix_HM($device,"ENDTIME_SUNDAY_1",$me);
#CHANGED: Präfix ist R-P1_ aber das R- darf nicht mitgeschickt werden
if ($type eq "HMCCU_IP") {
$prefix =~ s/R-1\.//;
}
else {
$prefix = ""; # always no prefix by set #msg1113658
}
Was steht bei dir in "ccureadingfilter"?
Hi KernSani,
das mit der 1 beim config ist jetzt natürlich unschön.
Ich nutze die HmIP-eTRV-B-2 R4M Thermostate und die haben die Firmware 1.2.26 - auf der CCU3 Version 3.67.10
Ich habe auch noch eine 2. Installation in einem anderen Haushalt mit HM-CC-RT-DN Thermostaten mit Firmware 1.5 - auf einer CCU2 Version 2.61.7
Vielleicht bekommen wir ja die Unterschiede raus?
Grüße, Roger
Zitat von: KernSani am 30 November 2023, 23:18:00Zitat von: rogerknop am 15 Oktober 2023, 19:33:48Hallo Risiko!
Ich hatte in #695 schon einmal Code Vorschläge für HMCCU Thermostate geschickt, die auch eingebaut wurden.
Nun habe ich einen HM IP Thermostat und da haben die Weekprofiles leider nicht mehr funktioniert.
Nach einigen Analysen habe ich es nun hinbekommen, dass es auch mit dem HM IP funktioniert und wollte die Änderungen hier teilen. Es wäre schön, wenn Du prüfen könntest, ob sie evtl. in deine Lösung wandern könnten.
Hier die Anpassungen in der Funktion weekprofile_sendDevProfile (ca. Zeile 492):
} elsif ($type =~ /HMCCU.*/){
$cmd .= "set $device config device" if ($type eq "HMCCU_HM");
#CHANGED: device oder 1 geht nicht
$cmd .= "set $device config" if ($type eq "HMCCU_IP");
my $k=0;
my $dayCnt = scalar(@dayToTransfer);
my $prefix = weekprofile_get_prefix_HM($device,"ENDTIME_SUNDAY_1",$me);
#CHANGED: Präfix ist R-P1_ aber das R- darf nicht mitgeschickt werden
if ($type eq "HMCCU_IP") {
$prefix =~ s/R-//;
}
else {
$prefix = ""; # always no prefix by set #msg1113658
}
if (!defined($prefix)) {
...
Es waren 2 Probleme:
Einmal hinter dem config ging weder device noch 1. Weglassen hat funktioniert.
Und die Readings haben alle den Präfix R-P1_ aber beim Senden darf man nur P1_ verwenden.
Kannst Du das bitte prüfen?
Danke & Grüße,
Roger
Bei mir war das ähnlich, allerdings haben die Readings bei mir den Präfix "R-1.P1_" und ich brauche die 1... bei mir also nur folgende Ergänzung:
my $prefix = weekprofile_get_prefix_HM($device,"ENDTIME_SUNDAY_1",$me);
#CHANGED: Präfix ist R-P1_ aber das R- darf nicht mitgeschickt werden
if ($type eq "HMCCU_IP") {
$prefix =~ s/R-1\.//;
}
else {
$prefix = ""; # always no prefix by set #msg1113658
}
Was steht bei dir in "ccureadingfilter"?
Sorry... diese Frage hatte ich völlig übersehen.
ccuflags: showMasterReadings,showLinkReadings,showDeviceReadings
Hallo!
Jetzt ist bei mir noch ein anderes Problem dazugekommen.
Wenn ich über weekprofile ein neues Profil an HMCCU_HM oder HMCCU_IP Devices sende, dann werden die Readings nicht geändert!
Ich muss manuell ein get config ausführen.
Wenn ich von Auto zu Manuell oder Temperaturen ändere, dann ändern sich die Reading direkt (ausser Wochenprofil Readings)
Grüße, Roger
PS: Habe gerade nochmal in beiden Installationen ein Update durchgeführt und neu getestet.
Das config 1 bei IP geht nicht! Invalid parameter.