Hallo,
ich habe mir eine Datei angelegt mit folgender Funktion:
SetTempList_Bad()
{
{ fhem ("set CUL_HM_HM_CC_RT_DN_22C0AA_Clima tempListMon prep 05:40 21.0 08:00 18.0 24:00 18.0")};
{ fhem ("set CUL_HM_HM_CC_RT_DN_22C0AA_Clima tempListTue prep 05:40 21.0 08:00 18.0 24:00 18.0")};
{ fhem ("set CUL_HM_HM_CC_RT_DN_22C0AA_Clima tempListWed prep 05:40 21.0 08:00 18.0 24:00 18.0")};
{ fhem ("set CUL_HM_HM_CC_RT_DN_22C0AA_Clima tempListThu prep 05:40 21.0 08:00 18.0 24:00 18.0")};
{ fhem ("set CUL_HM_HM_CC_RT_DN_22C0AA_Clima tempListFri prep 05:40 21.0 08:00 18.0 24:00 18.0")};
{ fhem ("set CUL_HM_HM_CC_RT_DN_22C0AA_Clima tempListSat prep 24:00 18.0")};
{ fhem ("set CUL_HM_HM_CC_RT_DN_22C0AA_Clima tempListSun exec 24:00 18.0")};
}
Meine Absicht ist, von 05:40 - 08:00 21.0° zu haben und ab 08:00 wieder 18.0°. Das sollte doch mit diesem Codeschnipsel passen, oder?
Am Wochenende soll immer nur 18.0° sein.
Grüße und Danke schonmal,
herrmie
Das ist so nicht richtig.
Jetzt machst du von 0.00 bis 05.40 21,0° dann bis 8.00 18°
die zeit ist immer bis xx.xx xx,x°
richtig für dich wäre z.b.
5:40 18.0 08:00 21.0 24:00 18.0
beispiel wie es bei mir ist
{ fhem ("set Bad_Clima tempListMon prep 05:00 10.0 06:30 20.0 16:00 10.0 21:00 20.0 24:00 10.0")};
Hi,
nein, das geht so nicht. So wäre es IMHO richtig:
fhem ("set CUL_HM_HM_CC_RT_DN_22C0AA_Clima tempListMon prep 05:40 18.0 08:00 21.0 24:00 18.0")
Die Uhrzeit ist die bis-Zeit vom jeweiligen Intervall. Das erste Intervall startet implizit immer um 00:00.
D.h. da Du irgendwo sagst "Bis 08:00 soll es 21:00 Grad haben", muss irgendwo "08:00 21.0" stehen.
Gruß,
Thorsten
Hallo,
ahhh, nun verstehe ich das. Naja komische Schreibweise aber macht nun auch Sinn. Denn in meinem FileLog von heute Nacht, habe ich mich schon gewundert, dass er ~00.00 auf 21° geheizt hat. ;D
Aber dann macht das Sinn. Somit müsste meine Funktion folgendermaßen aussehen:
SetTempList_Bad()
{
{ fhem ("set CUL_HM_HM_CC_RT_DN_22C0AA_Clima tempListMon prep 05:40 18.0 08:00 21.0 24:00 18.0")};
{ fhem ("set CUL_HM_HM_CC_RT_DN_22C0AA_Clima tempListTue prep 05:40 18.0 08:00 21.0 24:00 18.0")};
{ fhem ("set CUL_HM_HM_CC_RT_DN_22C0AA_Clima tempListWed prep 05:40 18.0 08:00 21.0 24:00 18.0")};
{ fhem ("set CUL_HM_HM_CC_RT_DN_22C0AA_Clima tempListThu prep 05:40 18.0 08:00 21.0 24:00 18.0")};
{ fhem ("set CUL_HM_HM_CC_RT_DN_22C0AA_Clima tempListFri prep 05:40 18.0 08:00 21.0 24:00 18.0")};
{ fhem ("set CUL_HM_HM_CC_RT_DN_22C0AA_Clima tempListSat prep 24:00 18.0")};
{ fhem ("set CUL_HM_HM_CC_RT_DN_22C0AA_Clima tempListSun exec 24:00 18.0")};
}
Grüße,
herrmie
Abgesehen davon, dass dieser Thread ja eigentlich in den Homematic Bereich gehört, frage ich mich, wieso sich jemand umständlich eine Funktion für etwas bastelt, das man genau einmal braucht.
evtl nervt es ja -aber so ganz verstehe ich nicht, warum ihr nicht die templist Implementierung aus HMInfo nutzt. Da muss man keine Funktionen schreiben, kann fuer alle sensoren templisten ablegen und verwalten.
Zitat von: martinp876 am 11 Februar 2014, 14:53:39aber so ganz verstehe ich nicht, warum ihr nicht die templist Implementierung aus HMInfo nutzt
1. weil man das schon immer mit einer Funktion macht
2. weil die Verwendung von HMinfo für diesen Zweck nicht im Wiki zum RT zu finden ist
3. weil der Unfug mit der Funktion immer noch im fhemwiki steht und einfach gedankenlos kopiert wird
4. weil das fhemwiki bezüglich des RT-DN inzwischen ziemlich veraltet ist (da steht z.B. immer noch ClimRT_tr als Channel...)
(nein, ich habe keine Zeit, mich um das wiki zu kümmern!)
Jetzt mal ohne Sarkasmus:
...und weil für manche ein bisschen programmieren einfacher ist, als die "Sprache" eines neuen Befehls mitsamt einem neuen Dateiformat zu lernen.
...und weil man mit einer Funktion flexibler ist. Ich baue mir z.B. eine Templist-Funktion für jeden RT. Dann eine für jedes Stockwerk und eine für's ganze Haus. So kann ich gezielt nur das aufrufen, was ich ändern will.
...weil es einfacher ist, nur in einer Datei etwas zu ändern und das nur an einer Stelle. (Die tatsächliche tempList eines RT ist nur einmal als Variable definiert. So muss ich nur an einer einzigen Stelle was ändern, wenn ich für alle Tage einer Woche eine Temperatur ändern will.)
Vielleicht fällt mir noch mehr ein. Natürlich könnte man das alles auch in eine Funktion einer "höheren Sprache" implementieren, aber dann wird das mindestens so kompliziert wie eine einfache Perl-Routine.
Gruß,
Thorsten
hm - ??? nun ja - muss ich nicht alles verstehen
@Martin: Versteh' mich nicht falsch, ich habe nichts gegen die HMInfo-Vorgehensweise. Vielleicht sollte ich auch damit mal ein bisschen herumspielen. Ich glaube nur, dass mein Weg zu mir besser passt.
Vielleicht finde ich mal ein bisschen Zeit, das RT-Wiki anzupassen, wenn niemand was dagegen hat. (Dann auch mit HMInfo tempList.)
Jeder hat seinen Weg - klar. Verbessern kann man sicher noch etwas an den templisten... beispielsweise mehrere Optionen für ein Device abspeichern - das geht gerade nicht
Nur mit ein paar der Argumente verstehe ich gerade nicht:
- warum mehrere Files?
- was ist an der Syntax schwer? Ist fast identisch
- Identische Programme für mehrere Regler sind möglich (etage/haus,...)
Store und verify Option sind vorhanden.
lade geht einfacher, den es muss nicht geladen werden
Was du betreibst ist eher die "template" vorgehensweise?
Aber gut jetzt - jeden das seine.
Hi,
Mehrere Files, damit man getrennt die Einstellungen zu einem bestimmten Device behandeln kann. Ok, ich habe nochmal nachgelesen, das geht auch mit <filter> (wahrscheinlich). Allerdings muss ich dann eine bestimmte Namensgebung einhalten.
Die Syntax ist nicht schwierig, aber das gilt für alle "Syntaxen". Es geht ja nicht nur um die Datei, sondern auch im die Befehle dazu, also wie man die Datei verwendet. Ich persönlich tue mir mit einer richtigen Programmiersprache einfacher. (Nicht jeder entwickelt aber Software seit 30 Jahren. Möglicherweise setzt auch der Altersstarrsinn ein.)
Identische Programme für mehrere Regler will ich gar nicht. Bei mir hat jeder RT ein anderes Programm, bis auf zwei, die haben dasselbe, aber die werden sowieso nach dem Taupunkt geführt, da in nicht wirklich genutzten Räumen.
Das ganze ist sowieso eher eine Frage des Geschmacks. Ich werde aber auch mal die HMInfo-Version ausprobieren, vielleicht gefällt sie mir dann sogar am Ende besser.
Gruß,
Thorsten
Zitataber so ganz verstehe ich nicht, warum ihr nicht die templist Implementierung aus HMInfo nutzt
Mmmm, hät ich nicht interessehalber diesenBeitrag gelesen wüsst ich bis jetzt nicht das es HMInfo gibt.....
Geht denke ich vielen "Neuen" so
Thorsten,
Ist Geschmackssache - korrekt. Daher nur zur Klarstellung (und nutzen musst du es immer noch nicht!)
- mit dem Filter filtert man Devices. Man kann also alle RT/TC in einem File speichern. Mit filter wählt man aus (regexp) welche devices man programmieren/speichern/prüfen will.
=> man kann keine unterschiedlichen Programme in einem File für einen RT/TC ablegen. Das ist auch eine gute Idee und sinnvolle ergänzung- und evtl baue ich dies nach. Generell entspricht dies eine "template" Ansatz, den es in HMINFO für treppenhausschaltern und andere Aktoren gibt -liegt eigentlich auf der Linie.
Wer lieber programmieren mag kann das natürlich.
@chris
HMInfo ist gedacht als ein layer über CUL_HM und soll die Überwachung und bedienung mehrerer/aller Devices sicherstellen. m.E. tut man sich schwer HM in FHEM ohne HMInfo zu überwachen - es sei den man schreibt sich etwas ähnliches selbst.
Gruss Martin
Kann es sein das
set hmDevices tempList save nicht funktioniert wie es dokumentiert ist? Laut cmdref wird ein file wie folgt angelegt
Zitatfilename is the name of the file to be used. Default ist tempList.cfg
. Er legt bei mit nur ein File "save" im fhem-Ordner (/opt/fhem/save) an. Mach ich ein
set hmDevices tempList save tempList.cfg legt er auch nur das file save an.
Das dürfte eigentlich so gar nicht gehen, oder ist tempList irgendwie als Device definiert? Ich hätte eigentlich so etwas wie das erwartet:
define hm HMInfo
set hm tempList save
Sry, ein Wort vergessen, hmDevices ist das Device und es wurde natürlich vorher definiert. Die "Befehle" waren quasi das was man dann im Device zusammenklickt. Ändert aber nichts daran das nur eine "save" Datei am ende raus kommt.
muss ich mir ansehen.
es wird, wenn kein Pfadnahme angegeben ist, immer die default-directory genommen. Setzt man das Attribut
configDir
wird dorthin geschrieben.
- Die Templisten waren in FHEM vorhanden, also aus den Devices gelesen?
- was sagt ein configCheck zu den Devices?
Gruss Martin
Äh, er legt die Datei an, sie enthält auch die Listen, aber sie heißt halt "save" und nicht wie in der Doku geschrieben per Default "tempList.cfg". Setzt man den Namen händisch im Befehl wird auch in einer "save" gesichert und nicht in <filename>
zu den Fragen
- Listen sind vorhanden
- configCheck wirft nichts raus (also wirklich nichts. Weder Fehler noch so was wie "alles i.o") Bin gerade nicht zu Haus, kann es also nicht testen. Habe nur "set <bla> configCheck " geklickt, ohne Parameter.
Hi,
das ist bei mir genauso, die Datei heißt "save". Das Problem scheint das Parsen des Kommandos zu sein. Ich habe das hier im Verdacht:
elsif($cmd eq "tempList") {##handle thermostat templist from file ---------
my $fn = $a[0]?$a[0]:"tempList.cfg";
$fn = AttrVal($name,"configDir",".")."\/".$fn if ($fn !~ m/\//);
$ret = HMinfo_tempList($filter,$a[0],$fn);
}
Das ist aus 98_HMInfo.pm, sub HMinfo_SetFn.
Müsste es statt $a[0] nicht jeweils $a[1] heißen?
...nur so eine Vermutung.
Gruß,
Thorsten
korrekt
Das Wiki zum RT anpassen wäre echt super ;) :-*
Hallo zusammen,
eine kleine Zusatzfrage von mir. Ich denke das passt ganz gut hier rein:
Bin ich bei der Programmierung über FHEM auch auf zwei Temperaturen limitiert, wie an allen mir bekannten programmierbaren Thermostaten (Tag/Nacht). Oder wäre hier auch eine Programmzeile
5:40 18.0 08:00 21.0 24:00 12.0
möglich? Ich habe das Problem, dass ichz.B. am Wochenende andere Tag/Nacht Werte fahren möchte als unter der Woche. Danke für jede Antwort.
Direkt am RT nicht meine ich. Du kannst aber in fhem prüfen ob WE ist und die Werte am RT entsprechend am WE ändern wenn du unbedingt nur mit Tag/Nacht-temp arbeiten willst (täglicher at ob we, wenn ja setzte we-tag/we-nacht temp, wenn nicht setzte Wochen-temp Tag/Nacht wenn nicht schon gesetzt).
Oder du nutzt einfach die temp-liste des rt (Wochenprogramm), steht halt mo-fr das selbe drinnen und am we was anderes.
du kannst auch das Modul nehmen http://fhem.de/commandref.html#Heating_Control
sowohl am RT selbst alsauch ueber FHEM kann man ein wochenprogramm einstellen mit 13 Werte je Tag. Die Werte sind frei waehlbar. 'at' ist nicht notwendig und auch nicht unbedingt sinnvoll.
heating_controll bietet nicht viel mehr als der RT bereits intern selbst - und somit mit geringerer Systembelastung zu Verfuegung stellt. zudem unterstuetzt es naturgemaess nur ein geringes subset der features eines RT
Hallo Chris und Martin,
danke für eure Antworten.
@Chris
Ich würde am liebsten nicht mit Tag/Nacht fahren, sondern wie in meiner "Programmzeile" einfach mehr als nur zwei Temperaturwerte vorgeben. Gibt FHEM das so weiter und setzt den Sollwert am Thdrmostat immer anders?
@Martin
Kann ich jedem der 13 Programme eine eigene Temperatur geben? Oder nur 13x am Tag zwischen zwei Werten hin und her schalten?
Nochmal genauer zum Hintergrund. Bei den mir bekannten programmierbaren Thermostaten kann ich eine Tag und eine Nachttemperatur vorgeben. Dann kann ich x mal am Tag zwischen den beiden Werten hin und her schalten. Ich möchte jedoch 3,4 oder 5 verschiedene Temperaturen über den Tag und am WE nochmal andere. Kann das FHEM mit HM?
13 man am tag kannst du eine beliebige temp festlegen - im 0.5 Grad Schritten
und am, naechsten tag kannst du 13 neue Werte nehmen.
so in der Art
tempListFri>07:00 5.0 13:00 6.0 16:00 6.5 21:00 7.0 24:00 8.0
tempListMon>07:00 9.0 16:00 10.5 21:00 13.5 19.0 24:00 14.0
.....
Zitat von: dan1180Kann das FHEM mit HM?
Da ist fhem sogar erst mal zu vernachlässigen. Ein HM-CC-RT-DN kann das ganz ohne Zentrale/FHEM/Zusatzkomponenten.
Die Templiste kannst du direkt am RT konfigurieren, sogar sehr komfortabel.
Hallo Martin,
zunächst vielen Dank für die großartige Arbeit die Du für die FHEM community leistest!
ich hätte eine frage zum Thema HMinfo und tempList:
webb ich in der Kommandozeile "set HM tempList save" eingebe bekomme ich "incomplete data for CUL_HM_HM_TC_IT_WM_W_EU_261916_Climate" zurückgemeldet. Muß ich vorbereitend ein anderes Kommando ausführen?
Danke,
Uwe
Hi Uwe,
das ist eine kleine sicherheitsabfrage - es sollen keine korupten Listen abgespeichert werden. Aber bitte beachten, die checks sind begrenzt in ihrem Umfang.
Ein getConfig sollte die Liste, wie sie in FHEM vorliegt komplettieren, danach sollte es funktionieren. Da ich keinen TC-IT habe kann ich es nicht testen...
Du kannst auch einen der Checks ausfuehren. Da sollte ein Report kommen, dass eine der Registerlisten nicht oder nicht komplett bereit steht.
Gruss Martin
Danke für die Antwort. Dann werd ich mir mal so ein Teil bestellen...
Grüße Dan
Hallo Martin,
stimmt:
incomplete register list
CUL_HM_HM_TC_IT_WM_W_EU_261916_Climate: RegL_07:,RegL_08:,RegL_09:
auch nach mehrmaligen get Configs.
allerdings habe ich eine Besonderheit: ich betreibe im Netz einen CUNO und einen HMLAN mit unterschiedlichen hmId und den entsprechenden Zuordnungen. beim CUL_HM_HM_TC_IT_WM_W_EU_261916 habe ich das erste mal einen Meldung protErrIoAttack
8 last_at:2014-02-22 20:21:05 gesehen. könnte das der Grund sein?
Danke,
Uwe.
Hi Uwe,
die Überwachung nach zugriffen auf ein Device von verschiedenen Quellen (Attack) prüft, dass dass nur von zugelassenen IOs gesendet wird.
Wenn die Zuordnung korrekt ist sollte es kein Problem sein: attr IODev sollte festgelegt sein und nur dieses IO sendet an dein Device. (trigger Buttons, sensoren dürfen auch, die Konfigurieren aber nichts)
Sendest du an dieses Device von beiden IOs?, Ist attribut IODev gesetzt?
Gruss Martin
Hallo Martin!
Zitat von: thunder am 19 Februar 2014, 19:06:39
webb ich in der Kommandozeile "set HM tempList save" eingebe bekomme ich "incomplete data for CUL_HM_HM_TC_IT_WM_W_EU_261916_Climate" zurückgemeldet. Muß ich vorbereitend ein anderes Kommando ausführen?
Das Problem habe ich leider auch. getConfig hat auch erwartungsgemäß keine Besserung gebracht. Kann es sein, dass die tempList-Funktion noch nicht damit klar kommt, dass der TC tempListP1Mon statt tempListMon benutzt?
Hier ein Auszug aus der tempList.cfg:
entities:OG.WZ.Heizung
tempListFri>24:00 15.0
tempListMon>24:00 15.0
tempListSat>24:00 15.0
tempListSun>24:00 15.0
tempListThu>24:00 15.0
tempListTue>24:00 15.0
tempListWed>24:00 15.0
entities:OG.WZ.Thermostat_Climate
incomplete:OG.WZ.Thermostat_Climate only data for tempListP1Fri,tempListP1Mon,tempListP1Sat,tempListP1Sun,tempListP1Thu,tempListP1Tue,tempListP1Wed,tempListP2Fri,tempListP2Mon,tempListP2Sat,tempListP2Sun,tempListP2Thu,tempListP2Tue,tempListP2Wed,tempListP3Fri,tempListP3Mon,tempListP3Sat,tempListP3Sun,tempListP3Thu,tempListP3Tue,tempListP3Wed
Patrick
ja, falsch gezählt.
jetzt gehts (hmInfo version 5029)
Hallo Martin,
ja IOdev ist auf den HMLAN gesetzt...
ich wüsste gar nicht wie ich an FHEM corbai über den CUNO senden könnte....
Viele Grüße,
Uwe.
Hallo Uwe,
im normal Fall sollte es nicht passieren. wenn es haeufiger passiert melde dich noch einmal.
Gruss Martin
Zitat von: martinp876 am 23 Februar 2014, 16:40:41
ja, falsch gezählt.
jetzt gehts (hmInfo version 5029)
Stimmt! Danke!