ClimaControl Modul um Wochenprogramme zu setzen

Begonnen von Brun, 30 Dezember 2014, 12:53:26

Vorheriges Thema - Nächstes Thema

Brun

Hallo,

ich habe mal ein Modul gebaut womit man einfach die Temperaturlisten zu setzen.



define <name> ClimaControl <type> <device> (<device> ...)


Es können mehrere Devices angesprochen werden. Bei HM Geräten müssen die Clima bzw. Climate devices genutzt werden.

Über die "set" Befehle kann dann das Wochenprogramm konfiguriert werden und an schliesend mit einen "update" die Temperaturlisten gepusht werden.
Es kann die komplette Woche gesetzt werden oder einzelne Bereiche oder Tage. Auch in Kombination.

Dies ist momentan noch eine frühe Beta und es kann auch noch auf andere Typen erweitert werden.


Gruß Brun

(https://www.dropbox.com/s/5duycgd9khc4q6h/Screenshot%20-%2030.12.2014%20-%2012%3A49%3A30.png?dl=0)

Da der Upload momentan nicht geht, hier ein Link:
https://www.dropbox.com/s/z0p5dd2ysz33cx0/98_ClimaControl.pm?dl=0

rapster

Danke!, wird sobald etwas Zeit zum basteln da ist gleich mal getestet  ;)

DerFrickler

erste Tests waren durchaus positiv...

über "all_period_<nr>_<begin/end>" ein "default"-Wochenprogramm einstellen

und dann über..."monday_period_<nr>_<begin/end>" individuelle Abweichungen angeben

was macht set - verify?


eine Bitte hätte ich dann noch... und zwar... eine Funktion, bei der man die Dauer seiner Abwesenheit eingeben kann (z.B. in Stunden oder bis zu einem bestimmten Datum.. wie auch immer) und dabei die Party Funktion aktiviert wird.


das währe dann z.B. (für die Dauer von x Stunden) das Reading: absentTime mit dem Kommando: setLeavingDuration


PartyStart würde dabei die aktuelle Uhrzeit bekommen, partyEnd dann die Aktuelle Uhrzeit + x Stunden und PatyTemp die Nachttemperatur


ich denke das man das ganze dann recht schön in eine ReadingsGroup darstellen kann, die zwar händisch über das definieren neuer ClimaControls zu erweitern ist, aber dann auch hoffentlich ohne großartige wissenschaftliche Aufwände funktioniert.


Gruß!

martinp876

im könntest du noch ein paar dinge streamlinen. Klar, ist erst eine beta.
- beim schreiben eines Registerblocks unbedingt "prep" und "exec" nutzen. In dieser Form ist es sehr unschön und fehlerträchtig bei der Übertragung
- das generieren von Listen sollte man nur machen, wenn man sie braucht. $attrlist kannst du bei der initialisierung erstellen. So wird es bei jedem set gemacht - kostet perfromance und jede menge speicher allocation/release.
- attrList ist ein relativ langer string. $setList ist dann noch einmal eine kopie des ganzen - noch einmmal so lange. bleibe bei einer Variablen
- frage erst ab, ob es ein Fehler ist, bevor du die daten generierst um den Fehler auszugeben. Sache der performance
- wenn du readings blockweise setzt nutze readingsbulk. single ist high-performant  wenn man es 7mal hintereinander aufruft.
    readingsBeginUpdate($hash);
   readingsBulkUpdate($hash,"tempListSat",$tmplList[5]);
   readingsBulkUpdate($hash,"tempListSun",$tmplList[6]);
   ...
    readingsEndUpdate($hash,0);
- logge einen block nur einmal - kostet alles...
  Log3 $hash->{NAME}, 4, "ClimaControl tempListSat $tmplList[5]"
        ."\nClimaControl tempListSun $tmplList[6]"
        ."\nClimaControl tempListMon $tmplList[0]";

Inhaltlich:
wenn ich es richtig sehe, speicherst du die templisten in readings. hm, für mich ein nogo. warum? weil readings nicht sicher gespeichert werden. Sicher sind attribute, sonst nichts. Und noch files, die du selbst verwaltest.

Vielleicht habe ich den sinn nicht verstanden, aber du willst verschiedene temperaturprofile anlegen und einspielen. Nebenbei (warum auch immer) day und night temp.

nach meiner vorgabe (meine! muss nicht beide sein, nur zumnachdenken) müsstest du die Daten zu aller erst einmal in einem File ablegen. Attribute sind möglich aber unschön. Du könntest sie sichtbar machen in readings, wenn du willst... geschmackssache.
CUL_HM unterstützt bereits temperaturfiles. Du könntest das nutzen. Du kannst eigene files gleichen Formats anlegen oder vorhandene - von CUL_HM erstelle manipulieren. Wenn du er mit dem attribut tempListTmpl kombiniert kannst du mit tempListTmpl auch das setzen in einem Kommando nutzen.

Defacto wäre ein frontend für das tempListtemplate file eien Funktion, die mir fehlt. Anzeigen, Ändern, Visualisieren eines profils, anzeigen der Nutzer-RT und prüfung, ob die Listen korrekt eingespielt sind.

Vielleicht hast du auch ein anderes Ziel, dann vergiss alles.

DerFrickler

Den rein Programmiertechnischen Teil werde ich als Halblaie mal nicht kommentieren.
Zitat von: martinp876 am 30 Dezember 2014, 20:01:54
Inhaltlich:
wenn ich es richtig sehe, speicherst du die templisten in readings. hm, für mich ein nogo. warum? weil readings nicht sicher gespeichert werden. Sicher sind attribute, sonst nichts. Und noch files, die du selbst verwaltest.
Vielleicht habe ich den sinn nicht verstanden, aber du willst verschiedene temperaturprofile anlegen und einspielen. Nebenbei (warum auch immer) day und night temp.

Wie viele unterschiedliche Temperaturprofile möchte man als File verwalten?. Zugegeben, diese Profile könnte man durchaus in Files abspeichern und bei Bedarf einlesen; möglicherweise ändern sich diese ja auch mit dem Alter der Kinder... aber sicherlich nicht so häufig. Und bevor sich mir wieder die Haare kräuseln weil wegen eines Leerzeichens zuviel die ganze Schose nicht läuft, würde ich diesen Aufwand eher klein halten wollen.

Eine sicherlich sinnvolle Nutzung von Files währe wenn man das Temperaturprofil abspeichern kann, für den (hoffentlich) unwahrscheinlichen Fall dass man das Thermostat mal komplett zurücksetzen muss. Dazu muss man es aber auch konsequent bei jeder Änderung speichern.

Zur day und night Temperatur, die ist bei mir daheim schon Etagenabhängig unterschiedlich, ändern sich aber eher selten... finde ich aber trotzdem klasse das man die auch gleich pro Thermostat bzw. Raum mit einstellen kann. Lass es ruhig als kleines Extra drin.

Zitat von: martinp876 am 30 Dezember 2014, 20:01:54
nach meiner vorgabe (meine! muss nicht beide sein, nur zumnachdenken) müsstest du die Daten zu aller erst einmal in einem File ablegen. Attribute sind möglich aber unschön. Du könntest sie sichtbar machen in readings, wenn du willst... geschmackssache.
CUL_HM unterstützt bereits temperaturfiles. Du könntest das nutzen. Du kannst eigene files gleichen Formats anlegen oder vorhandene - von CUL_HM erstelle manipulieren. Wenn du er mit dem attribut tempListTmpl kombiniert kannst du mit tempListTmpl auch das setzen in einem Kommando nutzen.

Ob Attribute oder Readings kann ich nicht beurteilen, ich persönlich sehe das Modul als Vehikel zwischen dem Thermostat und dem Anwender. Optimaler weise liest das Modul das Temperaturprofil aus dem Thermostat aus und schreibt es modifiziert zurück, wie kompliziert das zu realisieren ist kann ich nicht abschätzen. Entgegen meiner obigen Abneigung gegenüber Temperaturfiles könnte man diese aber einsetzten wenn man das Profil gänzlich ändern möchte... z.B. von "Normalprogramm" zu "Feiertagsprogramm", "Urlaub-mit-Anwesenheit" oder "Urlaub-mit-Abwesenheit", wobei letzteres über die Abwesenheit bzw. Party-Funktion gesteuert werden kann.

Aber letztendlich ist aus meiner Sicht das Thermostat der primäre Speicherort für ein Temperaturprofil, nicht irgendein File... natürlich muss das auch realisierbar sein.

Zitat von: martinp876 am 30 Dezember 2014, 20:01:54
Defacto wäre ein frontend für das tempListtemplate file eien Funktion, die mir fehlt. Anzeigen, Ändern, Visualisieren eines profils, anzeigen der Nutzer-RT und prüfung, ob die Listen korrekt eingespielt sind.

Vielleicht hast du auch ein anderes Ziel, dann vergiss alles.

Dem schliesse ich mich an, ein Frontend mit dem ich die Wochenprofile meiner Thermostate einsehen und individuell anpassen kann.

Was ich mir dann aber noch wünschen würde ist ist eine Abwesenheitsfunktion, die bestimmte Heizkörper für einen bestimmten Zeitraum ausserhalb des normalen Wochenprogramms auf Absenktemperatur bzw. Nachttemperatur schaltet. Solche Situationen ergeben sich schon mal beruflich bedingt; z.B. bei Dienstreisen muss mein Arbeitszimmer nicht konstant beheizt werden.

Auch das hier ist lediglich meine Meinung zum Thema, die nicht unbedingt mit deinem Vorhaben übereinstimmen muss.

Brun

Hallo,

ich bin leider kein Programmierer sondern nur ein Netzwerker. Daher ist ein den Modul schon einiges verbesserungswürdig und ich lerne gerne dazu.


Zitat von: martinp876 am 30 Dezember 2014, 20:01:54
im könntest du noch ein paar dinge streamlinen. Klar, ist erst eine beta.
- beim schreiben eines Registerblocks unbedingt "prep" und "exec" nutzen. In dieser Form ist es sehr unschön und fehlerträchtig bei der Übertragung

Das werde ich mir mal anschauen und umstellen

Zitat von: martinp876 am 30 Dezember 2014, 20:01:54
- das generieren von Listen sollte man nur machen, wenn man sie braucht. $attrlist kannst du bei der initialisierung erstellen. So wird es bei jedem set gemacht - kostet perfromance und jede menge speicher allocation/release.

Wie macht man es am besten? Wo finde ich denn ein Beispiel?

Zitat von: martinp876 am 30 Dezember 2014, 20:01:54
- attrList ist ein relativ langer string. $setList ist dann noch einmal eine kopie des ganzen - noch einmmal so lange. bleibe bei einer Variablen

Das werde ich verbessern

Zitat von: martinp876 am 30 Dezember 2014, 20:01:54
- frage erst ab, ob es ein Fehler ist, bevor du die daten generierst um den Fehler auszugeben. Sache der performance

Gute Idee. Werde ich auch mal umstellen

Zitat von: martinp876 am 30 Dezember 2014, 20:01:54
- wenn du readings blockweise setzt nutze readingsbulk. single ist high-performant  wenn man es 7mal hintereinander aufruft.
    readingsBeginUpdate($hash);
   readingsBulkUpdate($hash,"tempListSat",$tmplList[5]);
   readingsBulkUpdate($hash,"tempListSun",$tmplList[6]);
   ...
    readingsEndUpdate($hash,0);

Werde die ganze passage nochmal umbauen. Dann wird das auch mit geändert

Zitat von: martinp876 am 30 Dezember 2014, 20:01:54
- logge einen block nur einmal - kostet alles...
  Log3 $hash->{NAME}, 4, "ClimaControl tempListSat $tmplList[5]"
        ."\nClimaControl tempListSun $tmplList[6]"
        ."\nClimaControl tempListMon $tmplList[0]";

Das Logging ist eher nur für mich gewesen.

Zitat von: martinp876 am 30 Dezember 2014, 20:01:54
Inhaltlich:
wenn ich es richtig sehe, speicherst du die templisten in readings. hm, für mich ein nogo. warum? weil readings nicht sicher gespeichert werden. Sicher sind attribute, sonst nichts. Und noch files, die du selbst verwaltest.

Vielleicht habe ich den sinn nicht verstanden, aber du willst verschiedene temperaturprofile anlegen und einspielen. Nebenbei (warum auch immer) day und night temp.

Ob nun readings oder Attribute ist wahrscheinlich relativ egal. Beides hat Vor- und Nachteile.
Day und night temp benutze ich um das Wochenprogramm zu generieren. Da ich die Temperatur im Wochenprogramm auch immer gleich mit der day und night temp halte, wird die halt auch mit gesetzt.
Außerdem ist die Logik von FHT ja so. Da kann man das Programm nur auf day und night temp setzen.

Zitat von: martinp876 am 30 Dezember 2014, 20:01:54

nach meiner vorgabe (meine! muss nicht beide sein, nur zumnachdenken) müsstest du die Daten zu aller erst einmal in einem File ablegen. Attribute sind möglich aber unschön. Du könntest sie sichtbar machen in readings, wenn du willst... geschmackssache.
CUL_HM unterstützt bereits temperaturfiles. Du könntest das nutzen. Du kannst eigene files gleichen Formats anlegen oder vorhandene - von CUL_HM erstelle manipulieren. Wenn du er mit dem attribut tempListTmpl kombiniert kannst du mit tempListTmpl auch das setzen in einem Kommando nutzen.

Ich habe das Modul erstmal so gestaltet, dass man es nicht nur mit HM Komponenten nehmen kann sondern auch später mit MAX! oder FHT Komponenten.
Das mit den Template Dateien wäre noch ein Feature.

Zitat von: martinp876 am 30 Dezember 2014, 20:01:54
Defacto wäre ein frontend für das tempListtemplate file eien Funktion, die mir fehlt. Anzeigen, Ändern, Visualisieren eines profils, anzeigen der Nutzer-RT und prüfung, ob die Listen korrekt eingespielt sind.

So ähnlich habe ich es ja vor. Es sollte halt nur später universell genutzt werden können.

Zitat von: martinp876 am 30 Dezember 2014, 20:01:54
Vielleicht hast du auch ein anderes Ziel, dann vergiss alles.

So einiges habe ich ja erstmal mit genommen und versuche es mal um zu setzen.
Das dauert nur eine weile. Da dies von mir nur ein Hobby ist.


Gruß Brun

martinp876

ZitatWie viele unterschiedliche Temperaturprofile möchte man als File verwalten?.
ich? alle. Du? was du willst.
Zitatnd bevor sich mir wieder die Haare kräuseln weil wegen eines Leerzeichens
so kompliziert? Leerzeichen sollten kein problem darstellen.
ZitatEine sicherlich sinnvolle Nutzung von Files währe wenn man das Temperaturprofil abspeichern kann
dann mach - geht doch schon. war eine der ersten Funktionen.
ZitatZur day und night Temperatur, die ist bei mir daheim schon Etagenabhängig unterschiedlich, ändern sich aber eher selten... finde ich aber trotzdem klasse das man die auch gleich pro Thermostat bzw. Raum mit einstellen kann. Lass es ruhig als kleines Extra drin.
hm - das kann man mit CUL_HM schon. ein front-end fürs front-end? das ist mit den anderen einstellungen? die nicht?
ZitatAber letztendlich ist aus meiner Sicht das Thermostat der primäre Speicherort für ein Temperaturprofil,
ach so. hm dann kannst du nicht: ein profil für mehrere nutzen, vergleichen, sichern, 2. profil anlegen. wenn du da alles niht brauchst, ist es doch schon in CUL_HM da steht das profil.
ZitatEntgegen meiner obigen Abneigung gegenüber Temperaturfiles
hier muss ich aussteigen. genau das gibt es schon. Ob das config-file in frontend bekommt ist eine 2. Frage - warum nicht. aber deinem widerspruch in sich kann ich nicht folgen.

Zitatich bin leider kein Programmierer sondern nur ein Netzwerker.
kein problem, ist nur ein vorschlag zur verbesserung. deine Sache, etwas zu ändern oder nicht.
ZitatWie macht man es am besten? Wo finde ich denn ein Beispiel?
im wiki natürlich
http://www.fhemwiki.de/wiki/HM-CC-RT-DN_Funk-Heizk%C3%B6rperthermostat#Manuelle_.C3.84nderung
ZitatOb nun readings oder Attribute ist wahrscheinlich relativ egal.
sehe ich überhaupt nicht so. ein riesiger unterschied.
ZitatIch habe das Modul erstmal so gestaltet, dass man es nicht nur mit HM Komponenten nehmen kann
ok - musst du wissen. da gibt es schon eine ganze reihe heating control systems. hier noch eins?

ich werde mir wohl auch eins basteln - werde es aber auf HM beschränken. hat also nicht deinen Anspruch. Deins ist mir zu weit weg.

viel Spass noch


DerFrickler

#7
Zitat von: martinp876 am 31 Dezember 2014, 17:11:37
da gibt es schon eine ganze reihe heating control systems. hier noch eins?

ich werde mir wohl auch eins basteln - werde es aber auf HM beschränken. hat also nicht deinen Anspruch. Deins ist mir zu weit weg.

und da fängt es an absurd zu werden... warum findet man sich nicht mal zusammen, bespricht grundlegende Anforderungen und entwickelt "ein" Modul, welches dann wirklich für die Mehrheit brauchbar ist?

EDIT:
Zitat
hm - das kann man mit CUL_HM schon. ein front-end fürs front-end? das ist mit den anderen einstellungen? die nicht?

Was Du hier als Front-end bezeichnest kannst Du mir zumuten, nicht aber dem Rest der Familie. CUL_HM ist für mich eher eine Zwischenstation und weit von "Nutzerfreundlichkeit" entfernt. Wenn es dabei bleibt wird sich mein fhem Projekt auf mein Arbeitszimmer beschränken und in den weiteren Etagen nur auf Widerstand stossen.

Ein Front-end würde ich mir in etwa ähnlich wie die ReadingsGroup (hier im Forum und im Wiki) vorstellen. So in etwa... wobei Default für die Tage steht, die kein separates Profil besitzen.

Thermostat/Heizung     Tagestemperatur Nachttemperatur Default          Montag    Dienstag    Mittwoch    Donnerstag    Freitag      Samstag      Sonntag
Heizung Arbeitszimmer   19,0 °C        16,0 °C         6:00-12:30       off-off   off-off     off-off     off-off       5:30-12:30   8:00-23:00   9:00-23:00
                                                       13:30-23:00      off-off   off-off     off-off     off-off       13:30-22:00  off-off      off-off   
<Profil speichern> <Profil als Template speichern> <Profil laden> <Profil übertragen>

Brun

Hallo Martin,

mal kurz zu meiner ursprünglichen Intention. 
Ich habe momentan FHT und HM Komponenten. In der Ecke liegen noch MAX! Komponenten. Bei jeden System ist das Einstellen vom Wochenprogramm anders. Ich wollte einfach nur die Möglichkeit haben alle Systeme einheitlich zu konfigurieren. Mit den Temperatur Template habe ich auch erst eine ganze weile gebraucht. Und wenn ich in ein paar Jahren mal was ändern muss hab ich es schon wieder vergessen.

Mit HM habe ich einfach mal angefangen und wollte mir nun mal ein paar Meinungen holen.

Momentan ist es nur eine andere Art das Wochenprogramm zu generieren. Es greift nicht aktiv in die Heizungsteuerung ein.
Mann kann jetzt noch viel am Konzept ändern.

Wie würdest du das denn machen?


@DerFrickler

aus diesen Grund gibt es ja das Forum. Hier kann ja jeder seine Anforderungen schreiben und man kann dan so gut wie Möglich versuchen alle Anforderungen ab zu decken.


Gruß und einen guten Rutsch

Brun

frank

mit logProxy kannst du das dann alles schön visualisieren.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

martinp876

Vorab: ich denke nur an HM - wenn es für dich nicht passt musst du es anders machen. Nicht negativ, nur eine Feststellung.
Grundsätzlich sollte man temperturlisten in files verwalten. Readings sind nicht geeignet. Du könntest attribute nehmen, passen meiner Ansicht nach nicht. Insbesondere denke ich an Wochenprogramme, die IN den devices stehen. FHEM hat hier eine Lücke prinzipieller art - das Problem habe ich mit allen "registern" und peers. Templisten sind in diesem Fall register.
==> wenn du bei templisten an Daten denkst, mit denen FHEM manuell Thermostate steuert, lese nicht weiter ;)

Attribute sind Einstellungen,  mit denen man Entites IN FHEM steuert. Sie werden "sauber" gespeichert.
Readings sind messwerte, die das Device ausgibt. gespeichert wird "nur leiblos" - daten können verloren gehen!

Register sind Einstellungen, die man in ein Device schreibt und aus dem Device ausliest. Passt weder in die eine noch die andere Gruppe perfekt. I.a. werden diese in CUL_HM aus dem Device gelesen. wenn man sie ändert liest man sie wieder aus dem Device. das soll sicher stellen, dass man immer mit aktuellen Daten arbeitet. Nicht ganz straight forward, da das lesen nicht immer einfacht ist (funklast, transmision-modes,...). Man kann die Regsiter archivieren - in separate files. HMInfo unterstützt das. Damit kann man diese Daten verwalten, sichern und ggf wiederherstellen. Muss der User aber selbst aktivieren.

Templisten sind in meinem Fall (siehe meine Definition oben) register, die ich aber wegen ihrer ausnahmestellung anders verwalte. Zum einen ist es die Datenmenge und zum anderen die Nutzung, die es erforderlich machen.

So, langer rede kurzer Sinn:
- die Listen werden in Files gespeichert
- listen haben Namen (daher nenne ich sie templates). damit kann ich Listen mehreren Devices zuordnen
- das Device selektiert eine tempListe
Das Prinzip und auch das Format der templist-file lässt sich problemlos auf andere Familien ausdehnen.

Was offen ist, ist m.E. ein frontend für
- eingabe
- modifikation
- zuordnung
- darstellung
- verifikation

hierzu wäre mein ansatz, vorhandene FHEM-module einzubinden. Frontend ist eine heikle Sache - da hat jeder eigene Vorstellungen. Aber das Prinzip ist klar.

Ich würde also erst einmal anfangen, den Iststand darzustellen: welche tempfiles gibt es, welche templates gibt es in den files, welche Thermostate gibt es, welche templates nutzen die Thermostate.
2. Ändern eines templates: lesen aus dem File, ändern, file wieder schreiben
3. ändern der template-zuordnung (das attribut am Device, würde ich sagen)
4. Anzeige der templates per Kommando - graphisch versteht sich

in groben Zügen mein Ansatz.

Brun

Hallo Martin,

danke für deine Hilfe.
Das Template nicht die Thermostate steuern sollte ja jeden klar sein. Das macht mein Modul auch nicht.

Also wäre es doch sinvoll die Templates zu nutzen. Später könnte man dann eventuell auch andere Devices darüber konvertieren.
Kann man in den Templates Files auch andere Informationen stecken? So das man das Template auch normal für das HM Device nutzen kann?
Dann würde ich das was ich jetzt als Readings habe mit in die Template Datei stecken.
Zum Thema Frontend würde ich jetzt erstamal meine Idee beibehalten. Die gefällt mir momentan noch am besten.

Gruß Brun

martinp876

Hallo Brun
zu den tempList templates arbeite ich an der visualisuerung
- set hm tempListTmpl status => ist fertig - wird eingecheckt. Es zeigt die verwendeten tempList Template files. Ausserdem zeigt es die verwendung der templates durch die Komponenten sowie den Status.
- die graphische darstellung des Wochenprogramms habe ich schon seit einiger zeit am laufen - zur veröffentlichung muss ich es noch etwas tunen. Prinzip ist, dass aus den templates ein pseudo-logfile erstellt wird. Es spiegelt einen virtuellen Verlauf gemäß templates wieder. dann erzeuge ich noch ein gplot file - dass stellt das temp-profil dann prima da. Offen ist ein allgemeines handling, so man mehrere tempList templates nutzt - und wenn man viele templates hat. die Grafik ist auf 8 einträge beschränkt. da muss ich noch einmal nachdenken. Sonst funktioniert es prima.

Wie man das editieren machen soll ist mir aktuell unklar. Warum? Weil ich gerne frei editieren mag, tempaltes kopieren, mehrfach benennen, zeilen kopieren,... das ist am einfachsten in einem Editor. Das speichern eines vorhandenen templates in ein File geht schon.  Wenn du also ein front-end zum editieren machen willst und eine gute idee hast..... baue es.

Die tempList files achten aktuell nur auf Zeilen mit den Schlüsselwörten am Anfang. Man kann es also erweitern wie man will.

Registersettings zu anderen aktoren (templates) gibt es schon - hast du vielleicht gesehen. Die Stehen nicht in files. Es gibt ein paar vorgegebenen, man kann (soll) aber eigene erstellen. So war meine Idee. Nutzen wollte ich, dass man Long und Short quasi "gleich" programmieren kann. Also erstellt man ein "verhalten" unabhängig. Man definiert also, in welche Register welche werte geschrieben werden sollen (auch variablen...) - das ergibt das template. Nun kann man das template anwenden, es also einem Aktor zuweisen. dazu muss man angeben: den aktor, short oder long und für welchen peer man es nutzen will. Ggf noch parametern (einschaltdauern...).
Man kann sich also tempaltes definieren, dies anwenden (in das Device programmieren) und es verifizieren.
Die tempaltes würde ich in einem "post-init-config" ablegen. So ein Config würde ich sowieso immer anlegen.

Was meinst du? Schon einmal die template-optionen aus HMInfo gecheckt? Anregungen?

Gruß
Martin

Brun

Hallo Martin,

ich bin noch am basteln. Ich habe es jetzt mal so umgebaut, dass ich damit Templates Files erstellen kann. Zusätzlich speicher ich noch ein paar andere Infos ab.
Doch leider sind meine Kenntnisse noch etwas begrenzt.

Die Datei sieht momentan so aus:

dayTemp 22.0
nightTemp 19.0
all_period_1 5:00 7:00
all_period_2 16:00 22:00
workday_period_1 6:00 20:00
wednesday_period_1 5:30 10:00 26.0
entities:Bad_WandThermostat_Climate,Bad_Thermostat_Clima
tempListMon 6:00 19.0 20:00 22.0 24:00 19.0
tempListTue 6:00 19.0 20:00 22.0 24:00 19.0
tempListWed 5:30 19.0 10:00 26.0 24:00 19.0
tempListThu 6:00 19.0 20:00 22.0 24:00 19.0
tempListFri 6:00 19.0 20:00 22.0 24:00 19.0
tempListSat 5:00 19.0 7:00 22.0 16:00 19.0 22:00 22.0 24:00 19.0
tempListSun 5:00 19.0 7:00 22.0 16:00 19.0 22:00 22.0 24:00 19.0


Ich würde jetzt gerne diese Datei wieder einlesen. Doch wie kann ich denn alle Readings am besten löschen?


Das mit den Templates für andere HM devices habe ich mir schon mal angeschaut. Allerdings habe ich nicht so viele HM Devices. Aber die Idee finde ich schon genialst. Ein wenig habe ich schon damit gespielt. Werden die Templates komplett an die HM Device übergeben oder macht dann FHEM noch was?


Gruß Brun

martinp876

wäre schön, wenn du dich bei der Nomenklatur der templisten an die vorhandenen tempaltefiles halten würdest.

ZitatDoch wie kann ich denn alle Readings am besten löschen?
set entity clear readings

ZitatWerden die Templates komplett an die HM Device übergeben oder macht dann FHEM noch was?
wie meinst du das? Ein Template beschreibt register - die muss FHEM in hex-werte umsetzen, die Addressen suchen usw. geschriebenwird dann nur, was das template wünscht.