Hallo zusammen,
ich habe hier einige HM-TC-IT-WM-W-EU im Betrieb und habe jetzt bei einem festgestellt, dass im Laufe der FHEM Updates (aktuell: 98_HMinfo.pm 5240 2014-03-16 19:03:09Z martinp876 $) sich die Wochenschaltprogramme verändert haben. Ich habe jetzt bei einem Thermostat folgende Wochenlisten:
state
T: 18.5 desired: 21.0
2014-03-19 07:55:09
tempListFri
05:30 16.0 06:30 18.0 08:00 21.0 17:00 16.0 22:00 19.0 24:00 16.0
2014-03-18 20:56:52
tempListMon
05:30 16.0 06:30 18.0 08:00 21.0 17:00 16.0 22:00 19.0 24:00 16.0
2014-03-18 20:56:52
tempListP1Fri
05:30 18.0 06:30 21.0 08:00 16.0 17:00 19.0 22:00 16.0 24:00 16.0
2014-03-13 19:12:44
tempListP1Mon
05:30 18.0 06:30 21.0 08:00 16.0 17:00 19.0 22:00 16.0 24:00 16.0
2014-03-13 19:12:44
tempListP1Sat
05:30 18.0 06:30 21.0 08:00 16.0 17:00 19.0 22:00 16.0 24:00 16.0
2014-03-13 19:12:44
tempListP1Sun
05:30 18.0 06:30 21.0 08:00 16.0 17:00 19.0 22:00 16.0 24:00 16.0
2014-03-13 19:12:44
tempListP1Thu
05:30 18.0 06:30 21.0 08:00 16.0 17:00 19.0 22:00 16.0 24:00 16.0
2014-03-13 19:12:44
tempListP1Tue
05:30 18.0 06:30 21.0 08:00 16.0 17:00 19.0 22:00 16.0 24:00 16.0
2014-03-13 19:12:44
tempListP1Wed
05:30 18.0 06:30 21.0 08:00 16.0 17:00 19.0 22:00 16.0 24:00 16.0
Bei der Definition in der Dropdownliste SET habe ich allerdings die Wochenprogramme tempListFri bis tempListWed (Kann man die mal in die richtige Reihenfolge bringen, z.b. mit 01tempListMon bis 07tempListSun?) Dadurch lassen sich jetzt nur noch die ersten beiden Listen ändern, der Rest bleibt, wie er ist.
Wie bekomme ich das Durcheinander jetzt wieder weg? Einmal neu pairen? Was muss dann vorher gelöscht bzw. rückgesetzt werden?
Vielen Dank für eure Hilfe,
TomWest
Hi TomWest,
nicht immer gleich pairen... das Bringt nichts..
du hast
tempListFri
tempListFriP1
tempListFriP2
tempListFriP3
Beim TC gibt es
tempListFri
eigentlich nicht. Lösche es und lese es noch einmal
set <tc> clear Register
set <tc> getConfig
Die Register solltest du setzen können 'wie immer'
set <tc>_Climate tempListFri 06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 16.0
oder
set h_abCtrl_Climate tempListFri p1 06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 16.0
für die erste Liste
ZitatKann man die mal in die richtige Reihenfolge bringen, z.b. mit 01tempListMon bis 07tempListSun?
hm - gerne.... aber ich muss erst einmal über die Konsequenzen für die Allgemeinheit nachdenken
Es wird jetzt so aussehen:
R_P1_tempList_State: verified
R_P1_0_tempListSat: 06:00 17.0 22:00 21.0 24:00 17.0
R_P1_1_tempListSun: 06:00 17.0 22:00 21.0 24:00 17.0
R_P1_2_tempListMon: 06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0
R_P1_3_tempListTue: 06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0
R_P1_4_tempListWed: 06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0
R_P1_5_tempListThu: 06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0
R_P1_6_tempListFri: 06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 16.0
R_P2_tempList_State: verified
R_P2_0_tempListSat: 08:00 14.0 15:00 18.0 21:30 19.0 24:00 14.0
R_P2_1_tempListSun: 08:00 14.0 15:00 18.0 21:30 19.0 24:00 14.0
R_P2_2_tempListMon: 07:00 14.0 16:00 18.0 21:00 19.0 24:00 14.0
R_P2_3_tempListTue: 07:00 14.0 13:00 16.0 16:00 18.0 21:00 19.0 24:00 15.0
R_P2_4_tempListWed: 07:00 14.0 16:00 18.0 21:00 19.0 24:00 14.0
R_P2_5_tempListThu: 07:00 14.0 16:00 18.0 21:00 19.0 24:00 14.0
R_P2_6_tempListFri: 07:00 14.0 13:00 16.0 16:00 18.0 21:00 19.0 24:00 14.0
R_P3_tempList_State: verified
R_P3_0_tempListSat: 06:00 17.0 12:00 21.0 23:00 21.0 24:00 17.0
R_P3_1_tempListSun: 06:00 17.0 12:00 21.0 23:00 21.0 24:00 17.0
R_P3_2_tempListMon: 06:00 17.0 12:00 21.0 23:00 21.0 24:00 17.0
R_P3_3_tempListTue: 06:00 17.0 12:00 21.0 23:00 21.0 24:00 17.0
R_P3_4_tempListWed: 06:00 17.0 12:00 21.0 23:00 21.0 24:00 17.0
R_P3_5_tempListThu: 06:00 17.0 12:00 21.0 23:00 21.0 24:00 17.0
R_P3_6_tempListFri: 06:00 17.0 12:00 21.0 23:00 21.0 24:00 17.0
beim RT oder CC_TC ohne P1_
Zitat von: martinp876 am 19 März 2014, 09:57:07
tempListFri
tempListFriP1
tempListFriP2
tempListFriP3
Bei mir sind seit dem gestrigen Update auch die *P1* verschwunden. Stattdessen habe ich die tempListMon bis tempListSun.
Register wurden gelöscht und per getConfig neu eingelesen.
Zitat von: martinp876 am 19 März 2014, 09:57:07hm - gerne.... aber ich muss erst einmal über die Konsequenzen für die Allgemeinheit nachdenken
Die Reihenfolge ist doch völlig wurscht - vor allem ist sie jetzt alphabetisch, was nicht die schlechteste Lösung ist. Zudem werden die tempList ja nicht regelmäßig verändert, sondern einmal eingetragen und gut. Ausserdem ist es viel einfacher, das Setzen der tempList bei Bedarf für jede Jahreszeit getrennt in der 99_myUtils zu verankern und dann nur noch per Funktion aufzurufen, anstatt jedesmal alles manuell einzutippen. Und in der 99_myUtils ist die Reihenfolge der Ausführung ebenfalls beliebig, dort kann man dann auch nach Wochentagen sortieren.
Zitat von: betateilchen am 19 März 2014, 12:10:52
Die Reihenfolge ist doch völlig wurscht - vor allem ist sie jetzt alphabetisch, was nicht die schlechteste Lösung ist. Zudem werden die tempList ja nicht regelmäßig verändert, sondern einmal eingetragen und gut. Ausserdem ist es viel einfacher, das Setzen der tempList bei Bedarf für jede Jahreszeit getrennt in der 99_myUtils zu verankern und dann nur noch per Funktion aufzurufen, anstatt jedesmal alles manuell einzutippen. Und in der 99_myUtils ist die Reihenfolge der Ausführung ebenfalls beliebig, dort kann man dann auch nach Wochentagen sortieren.
Sehe ich auch so.
Hallo,
danke für den Tipp. Wenn ich aber bei meinem TC sowohl beim Device als auch beim Climate Channel set <...> clear register (über das Webfrontend) aufrufe, erscheint dies zwar im Logfile:
2014.03.19 14:10:37 2: CUL_HM set KH_Bad_Therm_Climate clear register
2014.03.19 14:11:27 2: CUL_HM set KH_Bad_Therm clear register
aber bei den Readings habe ich immer noch tempListFri usw. drin. Auch ein set <..> getConfig brachte hier keine Änderung.
Hat vielleicht noch jemand einen Tipp, wie ich die Dinger wieder los werde?
Vielen Dank,
TomWest
Hi,
Zitat von: betateilchen am 19 März 2014, 12:10:52
Die Reihenfolge ist doch völlig wurscht - vor allem ist sie jetzt alphabetisch, was nicht die schlechteste Lösung ist. Zudem werden die tempList ja nicht regelmäßig verändert, sondern einmal eingetragen und gut. Ausserdem ist es viel einfacher, das Setzen der tempList bei Bedarf für jede Jahreszeit getrennt in der 99_myUtils zu verankern und dann nur noch per Funktion aufzurufen, anstatt jedesmal alles manuell einzutippen. Und in der 99_myUtils ist die Reihenfolge der Ausführung ebenfalls beliebig, dort kann man dann auch nach Wochentagen sortieren.
Ich wüßte nicht viele schlechtere Lösungen, als alphabetisch ... ;)
Bei mir ist es so, dass es sich um eine Ferienwohnung mit wechselnden Bewohnern handelt. Diese sind zu unterschiedliche Zeiten außer Haus, so dass ich hier doch öfter Einstellungen ändern muss. Für jeden, der die Listen per Code ändert, bleibt nach der einmaligen Programmanpassung ja alles beim Alten. Für alle, die manuell ändern, fällt eine mögliche Fehlerquelle weg.
Bis dann,
TomWest
Zitat von: TomWest am 19 März 2014, 14:19:31Bei mir ist es so, dass es sich um eine Ferienwohnung mit wechselnden Bewohnern handelt. Diese sind zu unterschiedliche Zeiten außer Haus, so dass ich hier doch öfter Einstellungen ändern muss.
ich wüsste nicht viele schlechtere Lösungen, als solch eine Aufgabenstellung mittels der tempList umsetzen zu wollen...
ZitatBei mir sind seit dem gestrigen Update auch die *P1* verschwunden
sollte nicht sein.
ZitatDie Reihenfolge ist doch völlig wurscht
nun ja, jedenfalls nicht optimal
ZitatAusserdem ist es viel einfacher, das Setzen der tempList bei Bedarf für jede Jahreszeit getrennt in der 99_myUtils zu verankern und dann nur noch per Funktion aufzurufen, anstatt jedesmal alles manuell einzutippen.
prinzipiell richtig. Der User muss aber code hinterlegen... und kann nur ändern, wenn er reloaded oder neu Bootet.
Da es eigentlich UserConfig daten sind sollte es anders laufen....
Wer will kann die templist Funktionen aus HMInfo nutzen. Man kann
- templisten aus FHEM abspeichern
- templisten wieder laden/programmieren
- templisten für mehrere RTs /TCs nutzen (template).
- das templist Config file ändern (mit editor)
- prüfen, ob die Thermostate korrekt prgrammiert sind.
=> FHEM reboot ist nicht notwendig
ZitatHat vielleicht noch jemand einen Tipp, wie ich die Dinger wieder los werde?
set KH_Bad_Therm_Climate clear readings
set KH_Bad_Therm clear readings
Zitat von: martinp876 am 19 März 2014, 15:02:59und kann nur ändern, wenn er reloaded oder neu Bootet.
Jein... wenn die 99_myUtils.pm über das FHEMWEB Frontend geändert wird, erfolgt das Neuladen der Datei automatisch nach dem Abspeichern der Änderung.
Ganz ohne weiteres Zutun des Benutzers und ganz ohne Reboot.
Danke für eure Mithilfe! :)
Zitat von: martinp876 am 19 März 2014, 15:02:59
set KH_Bad_Therm_Climate clear readings
set KH_Bad_Therm clear readings
Klappt leider nicht ???
Nach dem clear readings und einem anschließenden getconfig sind jetzt alle P1 Listen weg, jetzt habe ich nur noch P2, P3 und eine ganze Wochenliste ohne P (also tempListSat etc.)
Hast Du vielleicht noch eine Idee? Sonst setzt ich die doch noch mal zurück, der andere TC läuft ja ohne Probleme.
Zitat von: martinp876 am 19 März 2014, 15:02:59
Wer will kann die templist Funktionen aus HMInfo nutzen. Man kann
- templisten aus FHEM abspeichern
- templisten wieder laden/programmieren
- templisten für mehrere RTs /TCs nutzen (template).
- das templist Config file ändern (mit editor)
- prüfen, ob die Thermostate korrekt prgrammiert sind.
=> FHEM reboot ist nicht notwendig
Da werde ich mal genauer hinsehen. Ist für mich aber derzeit noch schwierig, ich fange ja erst an.
Zitat von: betateilchen am 19 März 2014, 14:38:12
ich wüsste nicht viele schlechtere Lösungen, als solch eine Aufgabenstellung mittels der tempList umsetzen zu wollen...
Ich finde es gar nicht so schlecht. Das ist ja alles noch nicht fertig, am Ende möchte ich über das Frontend eine Templiste eintragen und programmieren können. Ich bin ja nicht der Einzige, der mit dem System umgehen soll, das sollen am Ende auch weniger "PCaffine" Leute erledigen können. Bei der templist habe ich auch kein Empfangsproblem, da der HM-LC-SW1 ja in der Wand eingebaut ist und das Themostat zwei Meter daneben hängt. Wenn ich alles von der Zentrale steuern will, könnte ich nicht garantieren, dass da immer alles ankommt. Aber wie würdest Du das denn lösen?
Zitat von: TomWest am 20 März 2014, 08:26:29Aber wie würdest Du das denn lösen?
Mit einem Google Kalender.
Hi TomWest,
habe es gerade getestet - und Funktioniert bei mir.
Du hast heute einen update gemacht?
Die Templisten heissen nun
R_P1_0_tempListSat
um eine Sortierung im web-frontend hin zu bekommen.
Templisten verwalten:
Die allgemein genutzte Variante, templisten in myUtils in den Code zu hämmern werde ich nie unterstützen. Da stellen sich bei mir die Nackenhaare auf. Es ist eine unselige Vermischung von Code und Daten - definitiv schlechter Programmierstil. Die Daten gehören in ein Daten-directory in dem man eben alle Daten verwaltet.
Hier geben ich schon einmal betateilchens kommenden Kommentar recht, dass ich hier wieder einmal eine Entwicklerbrille auf habe - kann schon sein.
Es steht - besonderen in FHEM und der offenen Bertiebsart - jedem Frei die nach seinem Gusto zu arbeiten - darüber müssen wir nicht streiten.
Fakt ist, dass ein halbwegs professionelles System den Angang NIE mit der myUtil-Methode machen würde. Konfig-daten werden NIE im Code verwaltet, auch wenn es machbar ist. So lange dies aber so in Wiki steht wird es die erste Wahl von Anfängern bleiben.
Für Anwender, die Templisten als Daten verwalten wollen, gibt es HMInfo. ggf. werden hier weitere methoden zur verwaltung/test,...bereitgestelle oder korrigiert. Wenn es also ideen gibt...
Gruss Martin
Zitat von: martinp876 am 20 März 2014, 09:50:57
gibt es HMInfo. ggf. werden hier weitere methoden zur verwaltung/test,...bereitgestelle oder korrigiert. Wenn es also ideen gibt...
Ja. Eine Idee hab ich.
Um künftig die Problematik im Frontend mit get/set bei HMinfo zu umgehen,
wie sie hier beschrieben wurde: http://forum.fhem.de/index.php/topic,21565.0.html
könntest Du vielleicht darüber nachdenken, HMinfo komplett als Befehl in fhem einzubauen anstatt als Modul, das erst ein define braucht.
Ich stand bei meiner configDB genau vor der gleichen Fragstellung ("wie configDB für den Anwender nutzbar/parametriebar machen?") und habe mindestens drei verschiedene Varianten durchprobiert. Die mit dem define, um ein Pseudo-Device zu generieren, war dabei die mit Abstand schlechteste. Inzwischen gibts configdb als fhem Befehl, und das funktioniert bisher astrein.
Grundsätzlich gebe ich Dir bei der Verwaltung der tempListen schon recht. Aber die Vorgehensweise über die myUtils hat sich etabliert und ist für Einsteiger am einfachsten zu verstehen. Diese Vorgehensweise wirst Du nie wieder loswerden. Allerdings könnte man darüber diskutieren, ob die tempList überhaupt Konfigurationsdaten darstellt ;)
Ich brauch die tempList generell nicht - wozu auch, wenn ich fhem als Zentrale habe?
Aber die jetzt gewählte neue Benennung ist m.E. Lichtjahre davon entfernt, intuitiv oder gar anwenderfreundlich zu sein.
Zitatkönntest Du vielleicht darüber nachdenken, HMinfo komplett als Befehl in fhem einzubauen anstatt als Modul, das erst ein define braucht.
HMInfo wurde falsch genutzt - habe eine Antwort geschrieben.
Die Einschränkung hat aber nichts mit HM zu tun sondern mit Rudi, webCmd, set und get handling.
Zitatkönntest Du vielleicht darüber nachdenken, HMinfo komplett als Befehl in fhem einzubauen anstatt als Modul, das erst ein define braucht.
eigentlich nicht.
- es gehört nicht in allgemeine Kommandos - bei weitem nicht jeder nutzt HM. Die wollen (mit recht) keine HM kommandos sehen.
- HMInfo repräsentiert eigentich eine Instanz "HM". Eine korrekte Architektur sollte ein "HM" istanziieren und auch ein frontend zu Verfügung stellen. FHEM hat hier den quick-and-dirty weg gewählt, dass dies implizit und ohne frontend (entity) gemacht wird. Dies aufzuräumen würde einige Probleme bereiten. HMInfo ist quasi einfach der weg, dies nachträglich zu machen. Es ist (wird) "quasi" die HM-Instanz.
ZitatAber die Vorgehensweise über die myUtils hat sich etabliert
ja
Zitatund ist für Einsteiger am einfachsten zu verstehen
nein - man hat ihnen einfach nicht andere erklärt - bis jetzt.
ZitatDiese Vorgehensweise wirst Du nie wieder loswerden.
komplett nicht - muss ich auch nicht, es darf jeder rumsauen wie es ihm gefällt
ZitatAllerdings könnte man darüber diskutieren, ob die tempList überhaupt Konfigurationsdaten darstellt
sorry? Was den sonst? Alle Register sind daten, die das Device konfigurieren. Darüber lässt sich nun wirklich nicht streiten.
ZitatIch brauch die tempList generell nicht - wozu auch, wenn ich fhem als Zentrale habe?
Frage der Philosophie - darüber streite ich definitiv nicht.
ZitatAber die jetzt gewählte neue Benennung ist m.E. Lichtjahre davon entfernt, intuitiv oder gar anwenderfreundlich zu sein.
hm.
er sind Register "R_" ist gerechtfertigt.
Die Listen heissen P1 bis P3 - sollte in Ordnung gehen - gibt es alternativen?
die Nummer des Tages zum Sortieren... finde ich gut. Das könnte ein Streitpunkt sein - geschmackssache.
Was wäre intuitiv?
Gruss Martin
Zitat von: martinp876 am 20 März 2014, 10:24:34
- es gehört nicht in allgemeine Kommandos - bei weitem nicht jeder nutzt HM. Die wollen (mit recht) keine HM kommandos sehen.
- HMInfo repräsentiert eigentich eine Instanz "HM". Eine korrekte Architektur sollte ein "HM" istanziieren und auch ein frontend zu Verfügung stellen.
Du hast noch nicht ganz verstanden, wie ich das mit der Implementierung des Befehls meine und wie das in fhem passiert. Genau DAS was Du da beschreibst, passiert nämlich, wenn Du HMinfo als eigenen Befehl implementierst. Jemand, der kein HM nutzt, wird den Befehl niemals zu Gesicht bekommen (er taucht nichtmal in der Hilfe auf!). Das zugehörige perl-Modul für den Befehl wird erst dann geladen, wenn hminfo zum ersten Mal
benutzt wird. Du kannst das mit configdb testen: Den Befehl siehst Du nicht bei "help", aber Du kannst ihn trotzdem aufrufen, z.B. "configdb info" - danach steht er dann auch in help (bis zum nächsten fhem Start)
Zitat von: martinp876 am 20 März 2014, 10:24:34Register "R_" ist gerechtfertigt.
Die Listen heissen P1 bis P3 - sollte in Ordnung gehen - gibt es alternativen?
die Nummer des Tages zum Sortieren... finde ich gut.
Und wer maßt sich dabei an, festzulegen, ob der Wochenbeginn (0) nun am Sonntag oder Montag ist? Tagesnamen sind eindeutig, auch in ihrer Kurzform. Noch dazu, wo hier immer wieder Wert darauf gelegt wird, dass fhem auch international verwendet werden können muss (deshalb commandref in englisch Pflicht) und es durchaus viele Kulturkreise gibt, in denen der erste Tag der Woche eben nicht der Montag ist.
Hi Martin,
Zitat von: martinp876 am 20 März 2014, 09:50:57
habe es gerade getestet - und Funktioniert bei mir.
Du hast heute einen update gemacht?
Die Templisten heissen nun
R_P1_0_tempListSat
um eine Sortierung im web-frontend hin zu bekommen.
Ja, jetzt passt es. Nach einem clear readings auf dem Climate und danach clear readings auf dem Device und einem GetConfig auf dem Device ist nun alles, wie es soll! Vielen Dank! :D
Im Web Frontend habe ich aber jetzt unter Set Climate immer noch TempListFri etc. kommt das noch von selbst?
Bis dann,
Thomas
Es gibt kein separates Kommando für für die einzelnen Listen (p1,p2...) Das P123 ist ein Parameter im jeweiligen Kommando.
Es gibt mittlerweile ein
get cmdList
was eine "schnell-Hilfe" geben soll. da erhältst du die erwarteten Parameter zu einem Kommando
tempListFri [prep|exec] [p1|p2|p3] HH:MM temp ...
tempListMon [prep|exec] [p1|p2|p3] HH:MM temp ...
tempListSat [prep|exec] [p1|p2|p3] HH:MM temp ...
tempListSun [prep|exec] [p1|p2|p3] HH:MM temp ...
tempListThu [prep|exec] [p1|p2|p3] HH:MM temp ...
tempListTue [prep|exec] [p1|p2|p3] HH:MM temp ...
tempListWed [prep|exec] [p1|p2|p3] HH:MM temp ...
war das die Frage oder habe ich es falsch verstanden?
Gruss Martin
Hi Martin,
ja das war die Frage. Ein eigener Parameter ist ja auch sinnvoll, wieviele Kommandos würden es denn sonst werden.
Vielen Dank für die Hilfe, ich denke, das wäre es dann (im Moment ... ;) )
eigentlich ist der Wochentag der erste Parameter... das Kommando ist tempList. 7 Kommandos sind nicht sinnvoll (aber historisch...)