FHEM Forum

Hallo,

ich habe ein Problem mit den Temperaturprofilen, vermutlich habe ich einfach nur was falsch verstanden, ... bitte um Hilfe.

Ich habe die aktuellen werte erfolgreich in eine Datei gespeichert.
set hm tempList save tempList.cfg

Diese liegt auch im selben Verzeichnis wie die fhem.cfg

Nun habe ich noch eine eigene Datei angelegt mit neuen werten ,,meintempprofil.cfg". Dieses lässt sich aber nicht einspielen. Der Befehl:
   set hm tempList restore meintempprofil.cfg
bringt immer folgende Fehler:
fail  : ./tempList.cfg:hz01_Wohnzimmer_Clima for hz01_Wohnzimmer_Clima: unused

Warum???

Mein Temp Profil zur Sicherheit nochmal:
entities:hz01_Wohnzimmer_Clima
R_0_tempListSat>07:00 17.0 08:00 20.0 24:00 21.0
R_1_tempListSun>07:00 17.0 08:00 20.0 23:30 20.0 24:00 18.00
R_2_tempListMon>05:30 17.0 07:00 18.0 15:30 18.0 22:30 20.0 24:00 18.00
R_3_tempListTue>05:30 17.0 07:00 18.0 15:30 18.0 22:30 20.0 24:00 18.00
R_4_tempListWed>05:30 17.0 07:00 18.0 15:30 18.0 22:30 20.0 24:00 18.00
R_5_tempListThu>05:30 17.0 07:00 18.0 15:30 18.0 22:30 20.0 24:00 18.00
R_6_tempListFri>05:30 17.0 07:00 18.0 15:30 18.0 22:30 20.0 24:00 18.00

Was mache ich falsch?

Und wenn ich das Wiki richtig verstanden habe, sollte tempList.cfg und meintempprofil.cfg, nach dem anlegen auch unter Edit Files angezeigt werden oder? – Passiert leider auch nicht. Ich sehe die Datei nur, wenn ich via SFTP auf meinen Pi schaue (/opt/fhem).

Viele Grüße
Alexander

Ich habe genau das gleiche Problem. Scheint wohl ein generelles Problem zu sein.
Selbst ein verify der frisch geschriebenen Liste schlägt fehl  :(

Herr 3x

seit ihr auf der aktuellen Version?
bislang musste die templist Linux Line-end haben.
jetzt sollte es auch mit Windows "cr" gehen

Version 6794 beim HMInfo. Rest hat auch ein Update hinter sich.
Die tempList.cfg hat HMInfo selbst geschrieben und ich habe ein verify ohne jede Änderung probiert. Fehler wie oben. Server ist OSX.

Herr 3x

Hallo,

hier sind die Installierten Versionen:

# $Id: fhem.pl 6782 2014-10-18 06:14:57Z rudolfkoenig $
# $Id: 00_CUL.pm 6755 2014-10-12 13:12:10Z rudolfkoenig $
# $Id: 10_CUL_HM.pm 6794 2014-10-19 16:48:14Z martinp876 $
# $Id: 01_FHEMWEB.pm 6812 2014-10-26 17:12:41Z rudolfkoenig $
# $Id: 10_FS20.pm 5326 2014-03-26 07:15:25Z rudolfkoenig $
# $Id: 92_FileLog.pm 6769 2014-10-15 17:03:30Z rudolfkoenig $
# $Id: 00_HMLAN.pm 6471 2014-08-27 12:32:38Z martinp876 $
# $Id: 12_HMS.pm 5097 2014-03-02 15:25:08Z rudolfkoenig $
# $Id: 98_HMinfo.pm 6794 2014-10-19 16:48:14Z martinp876 $
# $Id: 99_SUNRISE_EL.pm 6765 2014-10-14 18:24:29Z rudolfkoenig $
# $Id: 98_SVG.pm 6756 2014-10-12 13:13:26Z rudolfkoenig $
# $Id: 99_Utils.pm 6660 2014-10-03 06:35:43Z rudolfkoenig $
# $Id: 90_at.pm 6797 2014-10-21 12:32:19Z rudolfkoenig $
# $Id: 98_autocreate.pm 6505 2014-09-06 12:24:48Z rudolfkoenig $
# $Id: 91_eventTypes.pm 6792 2014-10-19 16:03:13Z rudolfkoenig $
# $Id: 91_notify.pm 6371 2014-08-07 05:33:37Z rudolfkoenig $
# $Id: 98_telnet.pm 6611 2014-09-24 07:48:32Z rudolfkoenig $

Bei Notepad, steht hinter den Zeilen als Umbruch "LF" ist das richtig?

Alexander

Das zeilenende ist mittlerweile egal.
Wenns immer noch nicht klappt, das file poster - als attachement

Hallo,

anbei das File.

bekomme bei abstezen dieses befehls:
set hm tempList restore meintempprofil.cfg

diese Fehlermeldungen:
fail  : ./tempList.cfg:ab_hz01_Clima for ab_hz01_Clima: unused
fail  : ./tempList.cfg:hz01_Kueche_Essen_Clima for hz01_Kueche_Essen_Clima: unused
fail  : ./tempList.cfg:hz01_Wohnzimmer_Clima for hz01_Wohnzimmer_Clima: unused
fail  : ./tempList.cfg:hz01_kegelbahn_Vorraum_Clima for hz01_kegelbahn_Vorraum_Clima: unused
fail  : ./tempList.cfg:hz01_schalfzimmer_Clima for hz01_schalfzimmer_Clima: unused
fail  : ./tempList.cfg:hz02_Kueche_Kueche_Clima for hz02_Kueche_Kueche_Clima: unused
fail  : ./tempList.cfg:hz02_kegelbahn_HrWC_Clima for hz02_kegelbahn_HrWC_Clima: unused
fail  : ./tempList.cfg:hz03_Kegelbahn_DWC_Clima for hz03_Kegelbahn_DWC_Clima: unused
fail  : ./tempList.cfg:hz04_Kegelbahn_Bahn_Clima for hz04_Kegelbahn_Bahn_Clima: unused

habe gerade noch mal update gemacht, leider liegt das Problem immer noch vor.

Bitte um Hilfe.

Viele Grüße
Alexander

war ein bug - liegt an der 0 im Namen.
ist korrigiert in 6863 (bitte testen)

Namen ohne die "0" und ohne "none"  irgendwo im templatenamen hätten geklappt.

Hallo,

jetzt steht überall passed da =)
Danke =)

aber irgendwas stimmt totzdem noch nicht.

Mit diesem Befehl sollten doch alle meine Zeiten, in die dazugehöroigen Geräte übertragen werden oder?

set hm tempList restore meintempprofil.cfg

leider funktionier das nicht bei allen! Bei manchen stehen nun die Zeiten aus meinem Tempprofil und bei den anderen irgendwelche anderen Zeiten.


entities:hz01_Wohnzimmer_Clima,hz01_Kueche_Essen_Clima,hz02_Kueche_Kueche_Clima
R_0_tempListSat>07:00 17.0 08:00 20.0 24:00 21.0
R_1_tempListSun>07:00 17.0 08:00 20.0 23:30 20.0 24:00 18.00
R_2_tempListMon>05:30 17.0 07:00 18.0 15:30 18.0 22:30 20.0 24:00 18.00
R_3_tempListTue>05:30 17.0 07:00 18.0 15:30 18.0 22:30 20.0 24:00 18.00
R_4_tempListWed>05:30 17.0 07:00 18.0 15:30 18.0 22:30 20.0 24:00 18.00
R_5_tempListThu>05:30 17.0 07:00 18.0 15:30 18.0 22:30 20.0 24:00 18.00
R_6_tempListFri>05:30 17.0 07:00 18.0 15:30 18.0 22:30 20.0 24:00 18.00
entities:hz01_schalfzimmer_Clima
R_0_tempListSat>07:00 17.0 10:00 18.0 24:00 17.0
R_1_tempListSun>07:00 17.0 10:00 18.0 24:00 17.0
R_2_tempListMon>05:30 17.0 07:00 19.0 24:00 17.0
R_3_tempListTue>05:30 17.0 07:00 19.0 24:00 17.0
R_4_tempListWed>05:30 17.0 07:00 19.0 24:00 17.0
R_5_tempListThu>05:30 17.0 07:00 19.0 24:00 17.0
R_6_tempListFri>05:30 17.0 07:00 19.0 24:00 17.0
entities:ab_hz01_Clima
R_0_tempListSat>09:00 17.0 20:00 18.0 24:00 17.0
R_1_tempListSun>09:00 17.0 20:00 18.0 24:00 17.0
R_2_tempListMon>14:30 17.0 20:00 18.0 24:00 17.0
R_3_tempListTue>14:30 17.0 20:00 18.0 24:00 17.0
R_4_tempListWed>14:30 17.0 20:00 18.0 24:00 17.0
R_5_tempListThu>14:30 17.0 20:00 18.0 24:00 17.0
R_6_tempListFri>13:30 17.0 20:00 18.0 24:00 17.0
entities:hz01_kegelbahn_Vorraum_Clima,hz02_kegelbahn_HrWC_Clima,hz03_Kegelbahn_DWC_Clima,hz04_Kegelbahn_Bahn_Clima
R_0_tempListSat>24:00 12.0
R_1_tempListSun>24:00 12.0
R_2_tempListMon>24:00 12.0
R_3_tempListTue>24:00 12.0
R_4_tempListWed>24:00 12.0
R_5_tempListThu>24:00 12.0
R_6_tempListFri>24:00 12.0


set hm tempList restore
sendet prüft alle. Gesendet wird nur, wenn es einen Unterschied gibt zwischen gelesenen Daten und dem "Template" aus dem File.
das Konfigfile - oder besser das selektierte template sollte man am besten am Thermostat als attribut eintragen.

Hallo martin,

ich habe ebenfalls das eingangs angesprochene Problem.

Der Befehl set hm tempList save /volumeUSB1/usbshare/fhem/hm_tempList.txt erzeugt wurderbar die Config-Datei.

Die Befehle set hm tempList verify /volumeUSB1/usbshare/fhem/hm_tempList.txt und set hm tempList restore /volumeUSB1/usbshare/fhem/hm_tempList.txt aquf die per FHEM erstellte Datei (ohne Änderung) enden jeweils mit der folgenden Meldung für jedes meiner Devices:
fail  : ./tempList.cfg:MG.AZ.HT_Clima for MG.AZ.HT_Clima: file: ./tempList.cfg for MG.AZ.HT_Clima does not exist

Wird es hier auch am DeviceName liegen?

Hallo zusammen,

das sieht bei mir auch immer noch so aus.

Kann es sein, dass die Änderungen nicht im update sind? Bei mir steht immer noch
# $Id: 98_HMinfo.pm 6794 2014-10-19 16:48:14Z martinp876 $

Wie komme ich an die Version 6863?

Herr 3x

update force

Nope  :-\
update force, shutdown restart, ver gibt
# $Id: fhem.pl 6913 2014-11-08 10:32:44Z rudolfkoenig $
# $Id: 10_CUL_HM.pm 6863 2014-11-02 09:04:57Z martinp876 $
# $Id: 72_FB_CALLMONITOR.pm 6852 2014-11-01 17:23:29Z markusbloch $
# $Id: 01_FHEMWEB.pm 6884 2014-11-04 22:03:52Z rudolfkoenig $
# $Id: 95_FLOORPLAN.pm 6174 2014-06-29 05:51:28Z ulimaass $
# $Id: 92_FileLog.pm 6769 2014-10-15 17:03:30Z rudolfkoenig $
# $Id: 00_HMLAN.pm 6471 2014-08-27 12:32:38Z martinp876 $
# $Id: 98_HMinfo.pm 6794 2014-10-19 16:48:14Z martinp876 $
# $Id: 98_HourCounter.pm 6802 2014-10-23 18:00:00Z john $
# $Id: 99_SUNRISE_EL.pm 6765 2014-10-14 18:24:29Z rudolfkoenig $
# $Id: 98_SVG.pm 6756 2014-10-12 13:13:26Z rudolfkoenig $
# $Id: 99_Utils.pm 6660 2014-10-03 06:35:43Z rudolfkoenig $
# $Id: 59_Weather.pm 6705 2014-10-07 17:41:42Z borisneubert $
# $Id: 90_at.pm 6797 2014-10-21 12:32:19Z rudolfkoenig $
# $Id: 98_autocreate.pm 6505 2014-09-06 12:24:48Z rudolfkoenig $
# $Id: 98_dewpoint.pm 6757 2014-10-12 18:58:57Z joachim09876 $
# $Id: 98_dummy.pm 4934 2014-02-15 08:23:12Z rudolfkoenig $
# $Id: 99_myUtils.pm
# $Id: 99_myUtilsTelefon.pm 1932 2012-10-06 20:15:33Z ulimaass $
# $Id: 91_notify.pm 6371 2014-08-07 05:33:37Z rudolfkoenig $
# $Id: 33_readingsGroup.pm 6262 2014-07-16 07:46:03Z justme1968 $
# $Id: 98_telnet.pm 6611 2014-09-24 07:48:32Z rudolfkoenig $
# $Id:
# $Id: 98_weblink.pm 5608 2014-04-23 10:57:16Z rudolfkoenig $

Kein Ahnung, was da los ist.

Edit: Auf http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/FHEM/98_HMinfo.pm (http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/FHEM/98_HMinfo.pm) steht auch die 6794, siehe Screenshot.

Herr 3x

Ich kann das nur bestätigen. Trotz update force & shutdown restart gibt ver mir ebenfalls
$Id: 98_HMinfo.pm 6794 2014-10-19 16:48:14Z martinp876 $ aus.
Vor dem update force wurde mir die hminfo.pm auch im update check aufgelistet. Seit dem update meldet update check mittlerweile "nothing to do".

Entweder du machst den update manuell aus svn oder du wendest dich an den update-teil im forum. Hier ist die frage falsch eingetragen

Zitat von: Herr 3x am 12 November 2014, 18:54:48
Hallo zusammen,

das sieht bei mir auch immer noch so aus.

Kann es sein, dass die Änderungen nicht im update sind? Bei mir steht immer noch

Code Auswählen Erweitern

# $Id: 98_HMinfo.pm 6794 2014-10-19 16:48:14Z martinp876 $

Wie komme ich an die Version 6863?

Herr 3x

Habt ihr aneinander vorbei geredet? Du hast doch die 6863, ist allerdings die CUL_HM.

Zitat von: Deudi am 13 November 2014, 21:48:55
Habt ihr aneinander vorbei geredet? Du hast doch die 6863, ist allerdings die CUL_HM.

Das will ich nicht ausschließen. Ich ging eigentlich davon aus, dass es um HMINFO geht und nicht um CUL_HM geht.  Die Fehlermeldungen kommen jedenfalls beim Benutzen von HMINFO.
Ich habe aber erstmal aufgegeben was tempListen zu machen. is ja auch nicht so ganz wichtig, denn es gibt ja noch andere Wege und der Rest läuft.

Herr 3x

Edit: Ich hab das aktuelle Modul von Hand aus der SVN geholt, lief aber auch nicht. Scheit eher kein Update-Problem zu sein, oder?

mache einmal ein leerzeichen an das Ende jeder Zeile. Wenn es klappt werde ich einmal in diese Richtung forschen

Hallo Martin,

nein, das hilft auch nicht.

Mir ist aber aufgefallen, dass die Angabe des Dateinamens ignoriert wird.

set hm tempList verify tempList2.cfg


gibt als Ausgabe

fail  : ./tempList.cfg:HK01_Clima for HK01_Clima: file: ./tempList.cfg for HK01_Clima does not exist
...


Es wird also evtl. die falsche Datei geöffnet? Oder der falsche Pfad? Ich habe keinen explizit mit Attribut gesetzt, die tempList.cfg wird ins root der fhem-Installation geschrieben.

Herr 3x

ZitatMir ist aber aufgefallen, dass die Angabe des Dateinamens ignoriert wird.

=> commandref

attr tempListTmpl
Sets the default template for a heating controller. If not given the detault template is taken from file tempList.cfg using the enitity name as template name (e.g. ./tempLict.cfg:RT1_Clima
To avoid template usage set this attribut to '0'.
Format is <file>:<templatename>. lt

Hallo,

ich schließ mich hier auch an. Die Angabe eines Dateinamens für die tempList funktioniert nur beim save, nicht aber beim verify oder restore:

Sichern der tempList für ein Thermostat in die Datei az_tempList.cfg:
fhem> set hm tempList -f az_Thermostat save az_tempList.cfg

Kontrolle, ob File geschrieben wird:
root@raspbmc:/opt/fhem# cat az_tempList.cfg

entities:az_Thermostat_Clima
R_0_tempListSat>09:00 17.0 16:00 18.0 24:00 17.0
R_1_tempListSun>09:00 17.0 16:00 18.0 24:00 17.0
R_2_tempListMon>07:30 17.0 16:00 18.0 24:00 17.0
R_3_tempListTue>07:30 17.0 16:00 21.0 24:00 17.0
R_4_tempListWed>07:30 17.0 16:00 21.0 24:00 17.0
R_5_tempListThu>07:30 17.0 16:00 21.0 24:00 17.0
R_6_tempListFri>07:00 17.0 16:00 18.0 24:00 17.0root@raspbmc:/opt/fhem#

In der letzten Zeile fehlt ein LF bzw CR vollständig. Scheint aber nicht die Ursache zu sein, daß verify / restore die Datei ignoriert.

Verify der eben geschriebenen tempList: => FEHLER
fhem> set hm tempList -f az_Thermostat verify az_tempList.cfg
fail  : ./tempList.cfg:az_Thermostat_Clima for az_Thermostat_Clima: file: ./tempList.cfg for az_Thermostat_Clima does not exist


Restore der eben geschriebenen tempList: => FEHLER
fhem> set hm tempList -f az_Thermostat restore az_tempList.cfg
fail  : ./tempList.cfg:az_Thermostat_Clima for az_Thermostat_Clima: file: ./tempList.cfg for az_Thermostat_Clima does not exist


Die Default tempList.cfg habe ich absichtlich vorher gelöscht.

FHEM Update ist gerade gelaufen - relevante Versionen sind aktuell:
fhem> version
# $Id: fhem.pl 6913 2014-11-08 10:32:44Z rudolfkoenig $
...
# $Id: 10_CUL_HM.pm 7003 2014-11-16 18:01:53Z martinp876 $
# $Id: 98_HMinfo.pm 6794 2014-10-19 16:48:14Z martinp876 $


Gruß
Tobias

der Pfad ist relativ zu FHEM. Dazu muss man noch global modpath berücksichtigen. Relativ ist eben so eine Sache.


man sollte
attr global modpath .
setzen. Was steht bei euch so?

So ganz check ich das jetzt nicht mehr...
Wenn der Pfad falsch sein sollte, warum funktioniert dann der save? Save, verify und restore sollten doch der selben pfad-logik unterliegen..??

Um deine Frage zu beantworten:
Global-modpath:    /usr/local/FHEM/share/fhem
Pfad für config, state, log, templisten:    /volumeUSB1/usbshare/fhem
(Bin auf einer synology diskstation)

ja, alle sollten den selben Pfad nutzen. save geht, verify nicht?
nutzt du beide male HMInfo? oder am device selbst?

Ich spreche von Hminfo.
Siehe mein post vom 9.11. (letzter auf der ersten Seite).

Die "normalen" device Befehle funktionieren, so setze ich die templisten jetzt alternativ...

Zitat von: martinp876 am 22 November 2014, 08:33:03
ja, alle sollten den selben Pfad nutzen. save geht, verify nicht?
nutzt du beide male HMInfo? oder am device selbst?

Bei mir steht
attr global modpath /usr/local/share/fhem

Genau da speichert HMINFO die tempList.cfg auch hin, wenn ich save mache.
Benutze ich verify kommen die oben genannten Fehlermeldungen.

Verändere ich den Dateinamen z.B. Auf Temperatur.cfg wird bei Save die Datei mit dem Namen angelegt.
Ein verify scheint trotz Angabe des Dateinamens nach tempList.cfg zu suchen. Fehler ist oben beschrieben und identisch zu dem von snx.

Herr 3x

schauen wir einmal, was wir sehen:

{my ($d,$l) = ("./","nix");; opendir(D, "$d") || die "Can't open directory $d: $!\n";;$l ="test:".join("\n",readdir(D));;closedir(D);;return $l}

liest das Direktory ".", also das working dir. ist dies das, was ihr sucht? Ist euer file dabei?

Hallo Martin,

schau dir bitte noch einmal meinen Beitrag etwas weiter oben an: http://forum.fhem.de/index.php/topic,28211.msg220531.html#msg220531 (http://forum.fhem.de/index.php/topic,28211.msg220531.html#msg220531)

Ich glaube, nicht das Directory sondern ein eingens gewählter Filename für die tempList ist möglicherweise das Problem. save geht und schreibt das File, verify / restore suchen aber hartverdrahtet eine tempList.cfg...

modpath ist bei mir Default und somit /opt/fhem:
   modpath    .


Tobias

sollte erledigt sein (morgen oder SVN)

Danke!

Hallo,

bei mir funktioniere soweit nun auch alles Danke dafür =).
Ein Problem, habe ich allerdings noch, ein Thermostat wehrt sich gegen das Tempprofil.

set hm tempList restore meintempprofil.cfg
nach diesem Befehl, steh überall passed.
nach einem verify, steht fail.

Wenn ich in das Thermostat reingehe über die Oberfläche, dann schaut alles anders aus als normal und bei Templist steht incomplete:

R-boostPeriod

set_5 min

2014-11-25 11:48:55
R-boostPos

set_80 %

2014-11-25 11:48:55
R-btnNoBckLight

set_off

2014-11-25 11:48:55
R-dayTemp

set_21 C

2014-11-25 11:48:55
R-daylightSaveTime

set_on

2014-11-25 11:48:55
R-decalcTime

set_11:00

2014-11-25 11:48:55
R-decalcWeekday

set_Sat

2014-11-25 11:48:55
R-modePrioManu

set_all

2014-11-25 11:48:55
R-modePrioParty

set_all

2014-11-25 11:48:55
R-nightTemp

set_17 C

2014-11-25 11:48:55
R-noMinMax4Manu

set_off

2014-11-25 11:48:55
R-regAdaptive

set_on

2014-11-25 11:48:55
R-reguExtI

set_15

2014-11-25 11:48:55
R-reguExtP

set_30

2014-11-25 11:48:55
R-reguExtPstart

set_30

2014-11-25 11:48:55
R-reguIntI

set_15

2014-11-25 11:48:55
R-reguIntP

set_30

2014-11-25 11:48:55
R-reguIntPstart

set_30

2014-11-25 11:48:55
R-showInfo

set_time

2014-11-25 11:48:55
R-showWeekday

set_off

2014-11-25 11:48:55
R-sign

off

2014-10-19 11:04:58
R-tempMax

set_30.5 C

2014-11-25 11:48:55
R-tempMin

set_4.5 C

2014-11-25 11:48:55
R-tempOffset

set_0.0K

2014-11-25 11:48:55
R-valveErrPos

set_15 %

2014-11-25 11:48:55
R-valveMaxPos

set_100 %

2014-11-25 11:48:55
R-valveOffsetRt

set_0 %

2014-11-25 11:48:55
R-winOpnBoost

set_off

2014-11-25 11:48:55
R-winOpnDetFall

set_1.4 K

2014-11-25 11:48:55
R-winOpnMode

set_on

2014-11-25 11:48:55
R-winOpnPeriod

set_15 min

2014-11-25 11:48:55
R-winOpnTemp

set_12 C

2014-11-25 11:48:55
R_0_tempListSat

incomplete

2014-11-25 20:30:59
R_1_tempListSun

incomplete

2014-11-25 20:30:59
R_2_tempListMon

incomplete

2014-11-25 20:30:59
R_3_tempListTue

incomplete

2014-11-25 20:30:59
R_4_tempListWed

incomplete

2014-11-25 20:30:59
R_5_tempListThu

incomplete

2014-11-25 20:30:59
R_6_tempListFri

incomplete

2014-11-25 20:30:59
R_tempList_State

incomplete

2014-11-25 20:30:59
ValvePosition

100

2014-11-25 20:18:19
boostTime

-

2014-11-25 20:18:19
controlMode

auto

2014-11-25 20:18:19
desired-temp

13.0

2014-11-25 20:18:19
measured-temp

8.6

2014-11-25 20:18:19
motorErr

ok

2014-11-25 20:18:19
partyEnd

-

2014-11-25 20:18:19
partyStart

-

2014-11-25 20:18:19
partyTemp

-

2014-11-25 20:18:19
state

T: 8.6 desired: 13.0 valve: 100

2014-11-25 20:18:19

Warum steht hier vor jeder Zeile "set_..." davor? Das bei keinem anderen so!
Kann mir einer Helfen woran liegt das?

Viele Grüße
Alexander

der registerwert sollte geändert werden - aber es ist eben nicht der aus dem device gelesene wert. ein getconfig wird da set_ verschwinden lassen. Den Wert kannst du danach prüfen - hoffentlich on

Hallo,

bin auch gerade bei meinen ersten Schritten mit FHEM und habe scheinbar das gleiche Problem (welches ja eigentlich behoben sein sollte): Wenn ich mittels
set hm tempList restore FHEM/heizung_urlaub.cfg ein anderes Temperaturprofil setzen will, bekomme ich die Fehlermeldung

Zitat
fail  : schlafzimmer for Schlafzimmer_Klima: file: tempList.cfg for Schlafzimmer_Klima does not exist
fail  : wohnzimmer for CUL_HM_HM_CC_RT_DN_2E7F2C_Clima: file: tempList.cfg for CUL_HM_HM_CC_RT_DN_2E7F2C_Clima does not exist
fail  : wohnzimmer for CUL_HM_HM_CC_RT_DN_2E7FA3_Clima: file: tempList.cfg for CUL_HM_HM_CC_RT_DN_2E7FA3_Clima does not exist
fail  : wohnzimmer for Wohnzimmer_Klima: file: tempList.cfg for Wohnzimmer_Klima does not exist

FHEM sucht also immer noch nach der Datei tempList.cfg statt nach FHEM/heizung_urlaub.cfg. Meine Versionsstände lauten:

Zitat
# $Id: fhem.pl 7283 2014-12-21 16:14:16Z rudolfkoenig $
# $Id: 10_CUL_HM.pm 7293 2014-12-21 18:09:32Z martinp876 $
# $Id: 01_FHEMWEB.pm 7284 2014-12-21 16:18:32Z rudolfkoenig $
# $Id: 92_FileLog.pm 7135 2014-12-05 21:11:17Z rudolfkoenig $
# $Id: 00_HMLAN.pm 7104 2014-11-30 18:55:56Z martinp876 $
# $Id: 98_HMinfo.pm 7086 2014-11-29 09:40:41Z martinp876 $
# $Id: 99_SUNRISE_EL.pm 6765 2014-10-14 18:24:29Z rudolfkoenig $
# $Id: 98_SVG.pm 7245 2014-12-17 16:13:07Z rudolfkoenig $
# $Id: 99_Utils.pm 6660 2014-10-03 06:35:43Z rudolfkoenig $
# $Id: 98_autocreate.pm 6505 2014-09-06 12:24:48Z rudolfkoenig $
# $Id: 98_dummy.pm 4934 2014-02-15 08:23:12Z rudolfkoenig $
# $Id: 91_eventTypes.pm 7221 2014-12-15 10:02:49Z rudolfkoenig $
# $Id: 91_notify.pm 7260 2014-12-19 12:50:49Z rudolfkoenig $
# $Id: 98_statistics.pm 7251 2014-12-18 06:24:55Z tpoitzsch $
# $Id: 98_telnet.pm 6611 2014-09-24 07:48:32Z rudolfkoenig $
# $Id: 98_update.pm 6784 2014-10-18 09:12:57Z rudolfkoenig $

Mache ich etwas falsch oder existiert der Bug immer noch?

Gruß,
Chris

hm - das ist doch etwas komplex. Es gibt viele einstellungen.
zum einen HMInfo mit dem config directory
dann das attribut tempListTempl
dann die Daten aus dem File.

Evtl zu viele optionen.

was steht in tempListtemplate des einzelnen device? Wenn darin nichts steht ist bei mir alles i.o.

Sorry, hat etwas länger gedauert, da ich die Tage unterwegs war...

In meinen "tempListTempl" stehen die jeweiligen entities drin. Also in "Schlafzimmer_Clima" steht "schlafzimmer". Diese entity ist natürlich auch im cfg-File enthalten. modpath steht bei mir auf "." (default), die cfg-Datei liegt im Unterverzeichnis FHEM/

Zitatdie cfg-Datei liegt im Unterverzeichnis FHEM/

dort ist nicht "."
setze sie nach "fhem".

probiere auch einfach saveConfig, dann sollte FHEM ggf ein file anlegen. Dort ist es richtig.

nebenbei: ich habe ein dir "setup" angelegt, in das ich all diese File schreibe.
attr <Clima> tempListTmpl setup/tempList.cfg:Bad

Schon klar, aber ich verwende doch folgenden Parameter:

set hm tempList restore FHEM/heizung_urlaub.cfg

das Verzeichnis "FHEM" liegt in "/opt/fhem", sollte also passen. Ich probiere es mal im übergeordneten Verzeichnis...

Zitat
nebenbei: ich habe ein dir "setup" angelegt, in das ich all diese File schreibe.
attr <Clima> tempListTmpl setup/tempList.cfg:Bad

Mein Ansatz ist, nirgendwo explizit den Dateinamen anzugeben, um diesen nur als Parameter von restore/verify zu verwenden. Dazu möchte ich verschiedene cfg-Files für verschiedene Basiszustände verwenden, also default.cfg, urlaub.cfg, anwesend.cfg etc. Sollte doch gehen, oder?

Zitat
dort ist nicht "."
setze sie nach "fhem".

Habe ich auch probiert, funktioniert leider auch nicht.

hast du schon ein
set hm tempList save
probiert?

sollte dein file abspeichern.

Ja, man sollte mit den Kommandos immer ein tempalte nutzen können ohne das attribut zu setzen. Natürlich reicht das file nicht, du muss es dann immer komplett eingeben. also file:templatename.

Zitat
hast du schon ein
set hm tempList save
probiert?

Ja. set hm tempList save erzeugt, wie erwartet eine entsprechende Datei in /opt/fhem/. Verwende ich
set hm tempList save FHEM/testfile.cfg, wird wie erwartet das file testfile.cfg im Verzeichnis /opt/fhem/FHEM/ erzeugt.

Ein anschliessendes set hm tempList restore FHEM/testfile.cfg führt wieder zu obiger Fehlermeldung:

Zitat
fail  : schlafzimmer for Schlafzimmer_Clima: schlafzimmer not found in file tempList.cfg
fail  : wohnzimmer for CUL_HM_HM_CC_RT_DN_2E7F2C_Clima: wohnzimmer not found in file tempList.cfg
fail  : wohnzimmer for CUL_HM_HM_CC_RT_DN_2E7FA3_Clima: wohnzimmer not found in file tempList.cfg
fail  : wohnzimmer for Wohnzimmer_Climate: wohnzimmer not found in file tempList.cfg

Es wird, so wie ich die Fehlermeldung verstehe, wieder nach tempList.cfg gesucht anstatt nach FHEM/testfile.cfg

Zitat
Ja, man sollte mit den Kommandos immer ein tempalte nutzen können ohne das attribut zu setzen. Natürlich reicht das file nicht, du muss es dann immer komplett eingeben. also file:templatename.

Ich probiere das ja etwas anders: In den Attributen gebe ich nur den Templatenamen an, z.B. "schlafzimmer" und beim restore gebe ich das file an, z.B. "heizung_urlaub.cfg".

BTW: Mir ist noch aufgefallen, dass die erzeugten cfg-Files als Entities die Namen der jeweiligen Geräte verwenden und nicht die unter dem Attribut tempListTmpl angegebenen Namen. Das ist so gewollt? Denn dadurch funktioniert ein "store" mit anschliessendem "restore" ja auch nicht, unabhängig vom verwendeten Filenamen.

habe es überarbeitet. Sollte jetzt funktionieren.
Im Attribut kann man angeben:
0 oder none: kein template genutzt
templateName : filename wird aus default genommen
file:templateName: filename und template ist fix

Kommando inHMInfo:
tempList: man kann einen filenamen angeben. Der wird genommen, wenn im attribut keiner steht
tempListTmpl: man gibt ein template an - das overruled das Attribut.

teste einmal. Version 7388 cul_hm und hminfo werden benötigt

Prima. Habe es gerade ausprobiert und scheint zu funktionieren. Muss aber noch etwas intensiver testen.

Nun kann man sehr einfach zwischen verschiedenen Temperaturprofilen wechseln, indem man eine Datei pro Profil verwendet. In dieser Datei können, wenn gewünscht, mittels Entities für jedes Thermostat andere Temperaturen vorgegeben werden. Umschalten kann man einfach, indem mit "restore" eine andere Datei ausgewählt wird. Klappt auch prima z.B. mit dem LightScene Modul.

Hallo!

Ich nutzen das HMInfo Modul für die Temperaturlistenverwaltung.

Mit Jörgs fronthem-Schnittstelle habe ich smartVISU angebunden.
Zunächst habe ich ein homematic-widget für smartvisu erstellt, das die einzelnen timer readings anzeigen und bearbeiten kann.
Darauf habe ich nun Buttons angeordnet, um die folgenden Aktionen auszulösen:

- init: Zurück zur Einstellung, die in tmpList.cfg gespeichert ist
- save: aktuellen Stand in eine Datei speichern, die den Namen des Device hat
- restore: zuletzt gespeicherten STand aus o. g. Datei wieder einlesen

Mir gelingt es, eine Liste zu speichern. Sie wird im Verzeichnis fhem erzeugt.

Datei ../fhem/Ventil_Raum_1.cfg






entities:Ventil_Raum1_Clima
R_0_tempListSat> 06:00 17.0 22:00 21.0 24:00 17.0
R_1_tempListSun> 06:00 17.0 22:00 21.0 24:00 17.0
R_2_tempListMon> 06:00 17.0 09:00 21.0 17:00 17.0 22:00 20.0 24:00 17.0
R_3_tempListTue> 06:00 17.0 09:00 21.0 17:00 17.0 22:00 20.0 24:00 17.0
R_4_tempListWed> 06:00 17.0 09:00 21.0 17:00 17.0 22:00 20.0 24:00 17.0
R_5_tempListThu> 06:00 17.0 09:00 21.0 17:00 17.0 22:00 20.0 24:00 17.0
R_6_tempListFri> 06:00 17.0 09:00 21.0 17:00 17.0 22:00 20.0 24:00 17.0



Auffällig hier, dass die Liste bei jedem Speichern eine Leerzeile oben ergänzt. Habt Ihr das auch?

Mir gelingt es nur selten, diese wieder zu restoren.

Wenn ich das manuell mit

set Ventil_Raum1_clima tmpList -f Ventil restore Ventil_Raum_1.cfg

versuche, bekomme ich oft die Meldung


fail  : ././Ventil_Raum_1.cfg:Ventil_Raum1_Clima for Ventil_Raum1_Clima:
Ventil_Raum1_Clima: tempList not verified


Was bedeutet das?

ZitatVentil_Raum1_Clima: tempList not verified

die Liste ist nicht bestätigt. du musst die Liste aus dem RT zurücklesen, dann ist die ím FHEM "verifiziert". Dies e kannst du dann über HMInfo mit dem file vergleichen.
autoReadReg sollte das Lesen automatisch machen - dauert natürlich ein paar minuten, systembedigt.

Oh. Was genau ist die Bedeutung von "bestätigt" und warum braucht man das?

Ich habe ja die Liste per tmpList save erzeugt. Was muss ich da noch tun?

das prinzip hast du schon verstanden - von HM allgemein?
IM device werden daten (register) gespeichert. Auch die templisten gehören in die Kategorie.
in FHEM werden readings dargestellt - auch register kann man darstellen
im File (templisten) kann man konfigurationen speichern.

Das lesen der Register aus devices ist nicht "kostenfrei" - und manchmal umständlich. Je nach device kostet es resourcen in der Luft sowie Zeit. Daher kann der User das Lesen steuern. Über das Attribut autoReadReg kann man es automatisieren - man hat aber einen Delay.
Für das Schreiben gilt das gleiche - sogar noch mehr.
=> man kann kein file beim starten immer "schreiben". die templisten müssen manuell geschrieben werden (also das schreiben anstossen).
=> wenn man geschrieben hat kann man die daten wieder aus dem Device lesen - zur sicherheit. mache ich IMMER. nur dann bin ich wirklich sicher, dass das, was in FHEM dargestellt wird ein Abbild des device ist.

nach einem Schreiben - wenn man nicht gelesen hat - sind die Daten denmach nicht verifiziert. Wenn man noch einmal gelesen hat sollte alles stimmen.
man kann in HMInfo zusätzlich prüfen, dass alle Daten komplett geladen sind (aus den Devices gelesen).

Wenn du die Daten mit getConfig gelesen hast sollten die Daten auf verified stehen. Du kannst ein save machen, das ändert nichts am Zustand verified. wenn du ein restore machst willst du etwas schreiben - danach wird FHEM wieder nachsehen wollen, was passiert. ist.

Vielen Dank für die umfängliche Erklärung, das hilft mir weiter.

Ich habe verstanden, dass es vier Stellen von Informationen gibt, die im Takt bleiben müssen:
- die Register im HM Gerät
- die Register in Fhem (getconfig)
- die Readings aus den Registern (Modulsache)
- die files, die wir speichern

Ist es nun richtig, dass ich ein neues tmpList- File, dass ich jetzt per Save erzeugt habe, nicht direkt per restore wieder einlesen kann? Was muss denn da erst verifiziert werden?

Wenn aber zwischendurch eine Änderung an den Settings des Devices gemacht wurde, warum muss dann vor dem Schreiben aus einer tmpList Datei irgendwas verifiziert werden? Hinterher wäre mir einleuchtend, aber vorher? Also warum kommt beim restore ein fail mit dem Grund fehlende Verifizierung? Was genau wird gegen was verifiziert?

Wenn ich vorher ein getconfig mache, was bringt das vor dem Schreiben?

Sorry, ich steh da auf dem Schlauch...


Gesendet von iPhone mit Tapatalk

Zitat- die Register in Fhem (getconfig)

ist ein kommando, der die register aus dem Device liest und in den Readings darstellt.
Die Register werden in hex auch in den Readings gespeichert - kannst du sehen, wenn expert auf 2 steht.

ZitatIst es nun richtig, dass ich ein neues tmpList- File, dass ich jetzt per Save erzeugt habe, nicht direkt per restore wieder einlesen kann?

falsch. Das file wird gelesen, es werden die kommmandos generiert und geschickt. wenn autoReadReg entsprechend gesetzt ist (ich setze immer 5) werden die Daten auch automatisch rückgelesen. Das kanze kann schon 6-10min dauern. wenn es probleme gibt auch länger. Grund ist, dass sich ein rt nur alle 3min meldet - und idR 2-3 Zyklen gebraucht werden.
bei autoReadReg läuft ein background timer von 30min, der - falls etwas nicht komplett erscheint - ein getCondfig triggert.

Zitat
Wenn aber zwischendurch eine Änderung an den Settings des Devices gemacht wurde, warum muss dann vor dem Schreiben aus einer tmpList Datei irgendwas verifiziert werden?

FHEM schreibt nicht immer alles. Es werden änderungen von Registern geschrieben - alles andere kostet zu viel Performance. wenn also register-readings vorhanden sind werden die Ändeerungen mit den vorhandenen verglichen und unterschiede geschreiben.
Es ist demnach essentiell, dass die daten konsistent gehalten werden.

Einfach ist es:
setze autoReadReg auf 5 (immer ... setze ich überall)
ich würde immer das attribut tempListTmpl entsprechend setzen ...
setze deine templist im file wie gewünscht

jetzt kannst du mit restore die daten in die rts schreiben.
dann kannst du warten, wenn du gedult hast (schwierig, weiss ich)

nun würde ich mein system mit HMInfo überwachen - das ist dafür gemacht
danach verifizieren

wenn also die attribute stimmen, kannst du dein system in einem zug syncen
set hm tempListTmpl status
set hm tempListTmpl restore
set hm tempListTmpl verify

so weit klar?
mir wäre es zu blöd, jeden rt einzeln zu setzen.

Um sicherzugehen, dass ich das richtig verstanden habe:

Wenn ich also in einer Routine zum automatischen Setzen von tempLists

set Hzg_Gaestezimmer_Clima tempListTmpl restore /opt/fhem/tempList.cfg:Gaestezimmer

stehen habe und das im Logfile dann führt zu

2015.02.08 20:03:46 3: CUL_HM set Hzg_Gaestezimmer_Clima tempListMon prep 06:00 17.0 09:00 21.0 21:00 17.0 23:00 21.0 24:00 17.0
2015.02.08 20:03:46 3: CUL_HM set Hzg_Gaestezimmer_Clima tempListTue prep 06:00 17.0 09:00 21.0 21:00 17.0 23:00 21.0 24:00 17.0
2015.02.08 20:03:46 3: CUL_HM set Hzg_Gaestezimmer_Clima tempListWed prep 06:00 17.0 09:00 21.0 21:00 17.0 23:00 21.0 24:00 17.0
2015.02.08 20:03:46 3: CUL_HM set Hzg_Gaestezimmer_Clima tempListThu prep 06:00 17.0 09:00 21.0 21:00 17.0 23:00 21.0 24:00 17.0
2015.02.08 20:03:46 3: CUL_HM set Hzg_Gaestezimmer_Clima tempListFri prep 06:00 17.0 09:00 21.0 21:00 17.0 23:00 21.0 24:00 17.0
2015.02.08 20:03:46 3: CUL_HM set Hzg_Gaestezimmer_Clima tempListSat prep 06:30 17.0 09:00 21.0 21:00 17.0 23:00 21.0 24:00 17.0
2015.02.08 20:03:46 3: CUL_HM set Hzg_Gaestezimmer_Clima tempListSun prep 06:30 17.0 09:00 21.0 21:00 17.0 23:00 21.0 24:00 17.0
2015.02.08 20:03:46 3: CUL_HM set Hzg_Gaestezimmer_Clima tempListSun exec 06:30 17.0 09:00 21.0 21:00 17.0 23:00 21.0 24:00 17.0
2015.02.08 20:03:46 3: set Hzg_Gaestezimmer_Clima tempListTmpl restore /opt/fhem/tempList.cfg:Gaestezimmer :
Hzg_Gaestezimmer_Clima: tempList not verified

... dann heißt das, das nicht sichergestellt ist, dass die TempList angekommen ist.

Gibt es eine Möglichkeit, ein Skript so zu schreiben, dass das richtige Setzen der tempLists sichergestellt ist? Müsste ich jeweils noch ein verify dahintersetzen?

set Hzg_Gaestezimmer_Clima tempListTmpl restore /opt/fhem/tempList.cfg:Gaestezimmer
set Hzg_Gaestezimmer_Clima tempListTmpl verify /opt/fhem/tempList.cfg:Gaestezimmer

Oder müsste ich dann auch noch auf die Rückmeldung von verify irgendwie reagieren? Das soll, wie gesagt, automatisch ablaufen - und idealerweise so zuverlässig wie möglich.

Mit dem restore werden die komandos in die q gehaengt. Damit ist es nicht gesendet, das dauert etwa 3 min. Wenn autoreadreg eingestellt ist wird die liste automatisch ruckgelesen. Dann steht verified drin... also die werte in fhem sind die im device. Nun kannst du ein temllisttemplate verify machen.
Wenn du es automatisieren willst kannst du ein verify nach dem empfang des verified triggern.

Uber hminfo - wie gesagt - kannst du das ganze system mit einem kommando verifizieren.

Danke für die Erläuterung!

Verify (hminfo oder einzelnes Gerät) sendet aber keine Befehle neu, wenn die im Gerät nicht richtig verarbeitet wurden, d.h. das müsste ich dann auch irgendwie automatisieren, damit ein automatisiertes verify Sinn macht?

sollte schon automatisch funktionieren. wäre daneben, wenn es nicht unterstützt wäre

set tempListTmpl[<typeFilter>][templateName][verify|restore|status|genPlot] [<filename>]# program a templist from a template in the file to one or multiple devices

verify: prüfen, dass das File mit den Readings übereinstimmt - und der status korrekt (verified) ist.
status: welches template wird wo genutzt
restore: schreiben der unterschiedlichen werte vom File in das Device.


Also:
optional
- Readings sind korrekt? besser ist das.
- set hm tempListTmpl status # prüfen, dass auch das template entsprechend gesetzt ist
- attribut autoReadReg im Device auf 5 (meine Empfehlung...)

notwendig
- template im File setzen, wie man mag. so viele templates ändern, wie man will.
- set hm tempListTmpl restore
### warten... ~10min. dann sind 3 Perioden des Sendens vorbei. Alternativ burst nutzen und burstXmit absetzen...

nach 10 min sollte
- alle Kommandos abgearbeitet sein
- autoReadReg dafür gesorgt haben, dass das device nach dem Schreiben automatisch gelesen wurde
- templistStatus auf verified stehen

man kann am Ende und immer zwischendurch ein
- set hm tempListTmpl verify
durchführen
Auch interessant: prüfen, ob die Verarbeitung abgeschlossen ist
- set hm protoEvents



Noch ein Tip: ich würde die ConfigFile nie in das Directory FHEM legen. Aber das eingebaute edit der files verlangt dies. Also lege ich meine files in ein Directory "setup" neben FHEM und erzeuge einen softlink im Verzeichniss FHEM auf das ConfigFile. Klappt prima.

Hi !

Sry das ich hier nochmal einsteige.... ich habe eine tempList.cfg angelegt und das Ganze mit

beim Regler ist alles richtig eingetragen
tempListTmpl   setup/tempList.cfg:aufenthalt

set hm tempListTmpl verify
set hm tempListTmpl status
und  set hm tempListTmpl restore klappt auch ganze gut
nach einem restore stehn die Werte in den Reglern.. soweit so gut

Ich hab hm autoupdate eingeschaltet und bei allen Devices AutoReadReg auf 5 stehen.

also set hm tempListTmpl status sagt bei allen OK
set hm tempListTmpl verify ist bei allem auf passed

jetzt aendere ich die Datei tempList.cfg  aber die Register werden nicht upgedatet...

Hab ich da was vergessen oder einen Denkfehler ?

Gruss Gerd

so weit gehe ich nicht - bis jetzt zumindest.
autoreadreg 5 stellt (bestmöglich) sicher dass die Registerwerte-Kopie in FHEM den Werten aus dem Device entsprechen.
ein templistverify wird nur manuell angestossen. Hier werden die Werte der Kopie mit den Werten im File verglichen.

Ich könnte jetzt einbauen, das beim Ändern des templates ein automatisches verify durchgeführt wird und ein templateStatus gesetzt wird (ok/deviation/TemplateNotFound/RegisterNotComplete).
templates kann man im Prinzip für alle Devices anlegen - man könnte es also generell machen. Das würde die Archivierung von Registern kompletieren: auslesen, archivieren, verifizieren.
Das automatische Schreiben bei Abweichungen.... könnte man auch einbauen.... wäre ich aber vorsichtig.

Dauert aber sicher etwas. Aktuell leider noch handarbeit.

Hi !

kommt drauf an... man kanns ja auch extern per cronjob ueberwachen..
sprich wenn die Datei innerhalb der letzten 10 minuten geaendert wuerde führe den Befehl aus...

Die Frage ist nur geht das fhem telnet in einem script ?

Gruss Gerd

Du kannst es zumindest umgekehrt machen und Skripte aus fhem ausführen. Die Ausgabe des Skeipts kannst Du in eine Variable einlesen und weiterverarbeiten. Dazu gibt's Beispiele, die das System erklären sollten. Wenn Du nichts findest, melde Sich gerne nochmals, dann gehe ich mal meinen Code durchsuchen.

Gruß, Christian

Klar kannst du fhem mit einem script von extern steuern. Kommt auf dein script an.
Ist aber ein fragwuerdiges vorgehen... fhem script per script zu steuern.

Hallo, ist es möglich, dass im HM-Modul die Funktion "tempListTmpl" rausgenommen wurde?

"set hm tempListTmpl -f Schlafzimmer sru restore tempList.cfg"

Ich bekommen nun die Fehlermeldung:
Unknown argument tempListTmpl, choose one of archConfig autoReadReg clear cpRegs loadConfig purgeConfig saveConfig tempList templateDef templateDel templateExe templateSet update verifyConfig

Ich hab mehrere Heizprogramme in einem Templatefile und setze diese je nach Anforderung .. z. B. Homeoffice und das Büro wird geheizt. Es gibt zwar die Möglichkeit einzelne Templatefiles per "set hm tempList" zu setzen, aber dann müsste ich für jedes Thermostat ein File haben was ich verhindern möchte.

Ich hab an den Definitionen nichts geändert und es lief letzten Winter problemlos. Es wurde scheinbar durch ein Update irgendwann zwischen März und jetzt geändert.

Danke schon mal!

Edit:
Version die das Update gezogen hat und nicht mehr funktioniert:
98_HMinfo.pm 9697 2015-10-27 12:31:35Z martinp876

Version aus einem Backup das noch funktioniert:
98_HMinfo.pm 9300 2015-09-25 10:58:46Z martinp876

Attr Schlafzimmer templist sru
Set hm templist -f Schlafzimmer restore

Zitat von: martinp876 am 30 Oktober 2015, 21:41:41
Attr Schlafzimmer templist sru
Set hm templist -f Schlafzimmer restore

Für einzelne Files würde das gehen aber ich hab ein Template, in dem mehrere Profile enthalten sind. Ein Profil ist das sru neben etlichen mehr. Würde ich deinem Vorschlag folgen, muss ich dann alle Profile jedem Thermostat als Attribut zuweisen? Dann weiß aber das restore nicht welches nun verwendet werden soll.

Wie schon oben geschrieben, will ich nicht für jedes Thermostat ein eigenes File haben. Als Workaround habe ich das Modul mit "exclude-from-update" ausgenommen und bleibe auf der, für mich funktionierenden, Version.

Wenn du als Entwickler des Modules entschlossen hast, den Befehl "setTempTempl" obsolet zu setzen akzeptiere ich das. Sollte es aber durch einen Fehler nicht funktionieren kann ich dir auch Logs oder was auch immer liefern, wenn du genaue Anweisungen gibst.


Unten ein Auszug aus entsprechendem Template.

Danke schon mal.


entities:wza,sra
R_0_tempListSat>06:00 12.0 24:00 12.0
R_1_tempListSun>06:00 12.0 24:00 12.0
R_2_tempListMon>06:00 12.0 24:00 12.0
R_3_tempListTue>06:00 12.0 24:00 12.0
R_4_tempListWed>06:00 12.0 24:00 12.0
R_5_tempListThu>06:00 12.0 24:00 12.0
R_6_tempListFri>06:00 12.0 24:00 12.0

entities:srho
R_0_tempListSat>10:00 17.5 20:00 16.5 23:00 17.5 24:00 17.5
R_1_tempListSun>10:00 17.5 24:00 12.0
R_2_tempListMon>06:00 12.0 24:00 12.0
R_3_tempListTue>06:00 12.0 24:00 12.0
R_4_tempListWed>06:00 12.0 24:00 12.0
R_5_tempListThu>20:00 12.0 20:00 16.5 23:00 17.5 24:00 17.5
R_6_tempListFri>10:00 17.5 20:00 16.5 23:00 17.5 24:00 17.5

entities:sru
R_0_tempListSat>10:00 17.5 20:00 16.5 23:00 17.5 24:00 17.5
R_1_tempListSun>10:00 17.5 20:00 16.5 23:00 17.5 24:00 17.5
R_2_tempListMon>10:00 17.5 20:00 16.5 23:00 17.5 24:00 17.5
R_3_tempListTue>10:00 17.5 20:00 16.5 23:00 17.5 24:00 17.5
R_4_tempListWed>10:00 17.5 20:00 16.5 23:00 17.5 24:00 17.5
R_5_tempListThu>10:00 17.5 20:00 16.5 23:00 17.5 24:00 17.5
R_6_tempListFri>10:00 17.5 20:00 16.5 23:00 17.5 24:00 17.5

entities:srw
R_0_tempListSat>10:00 17.5 20:00 16.5 23:00 17.5 24:00 17.5
R_1_tempListSun>10:00 17.5 24:00 12.0
R_2_tempListMon>06:00 12.0 24:00 12.0
R_3_tempListTue>06:00 12.0 24:00 12.0
R_4_tempListWed>06:00 12.0 24:00 12.0
R_5_tempListThu>06:00 12.0 24:00 12.0
R_6_tempListFri>20:00 12.0 20:00 16.5 23:00 17.5 24:00 17.5


ZitatFür einzelne Files würde das gehen aber ich hab ein Template, in dem mehrere Profile enthalten sind

Begriffsbestimmung: ein templatefile kann mehrere Templates enthalten. Ein template enthält ein Profil

ZitatEin Profil ist das sru neben etlichen mehr. Würde ich deinem Vorschlag folgen, muss ich dann alle Profile jedem Thermostat als Attribut zuweisen?

verstehe ich nicht. Du solltest jedem RT EIN profil zuordnen. Mehrere RTs können das selbe template nutzen. In welchen File die tempaltes liegen ist egal, können alle in einem liegen. Mehrere Files zu haben würden ich nur empfehlen, wenn man Erfahrung hat.

Was jetzt nicht mehr geht ist das dynamische Zuweisen per Kommando - man muss jetzt über das Attribut gehen. Ansonsten ist alles gleich.

Das Attribut tempList kann auch ein file beinhalten
attr schlZ tempList templistautlistung.cfg:sru
attr schlZ tempList ./setup/templistautlistung.cfg:sru

Die Vorteile sind, dass nach dem Zuweisen der Attribute HMInfo alle templisten prüfen und korrigieren kann, da für jeden RT die individuelle Liste definiert wurde. Systemweit.

set hm tempList restore
set hm tempList verify
set hm tempList status

Falls noch Fragen bestehen, gerne.

Hallo,

ich frage noch etwas weiter ...

Meine Wohnung soll entsprechend meinen Projekten beheizt werden. Wenn ich normal arbeite bin ich die ganze Woche unterwegs, im FAlle Homeoffice bin ich zu Hause, Urlaub auch aber dann heizt das Büro nicht und dafür das Schlafzimmer länger, das Bad später ....

Was ich möchte ist einfach per Dropdown das Heizprofil umzustellen (oder per Google Kalender). Das File ist einfach zu editieren, das ganze in fhem direkt wären etliche notify und viel mehr Programmieraufwand.

So wie ich das jetzige lese bekommt das Thermostat ein festes Programm zugewiesen das nur geändert wird wenn ich das zugeordnete File anpasse und neu einlese. Ich ändere aktuell das Programm ggf. mehrfach in der Woche.

Ich häng mal die config an damit du siehst wie ich das aktuell handhabe. Habe das irgendwo hier im Forum gefunden und angepasst.


#### Schlafzimmer
define Programm_SR dummy
attr Programm_SR group Steuerung
attr Programm_SR room HomeMatic
attr Programm_SR setList state:Urlaub,Homeoffice,Arbeit,Aus
attr Programm_SR webCmd state

define Programm_SR_Urlaub notify Programm_SR:Urlaub set hm tempListTmpl -f Schlafzimmer sru restore tempList.cfg
define Programm_SR_HO notify Programm_SR:Homeoffice set hm tempListTmpl -f Schlafzimmer srho restore tempList.cfg
define Programm_SR_Work notify Programm_SR:Arbeit   set hm tempListTmpl -f Schlafzimmer srw restore tempList.cfg
define Programm_SR_Aus notify Programm_SR:Aus       set hm tempListTmpl -f Schlafzimmer sra restore tempList.cfg


Wo liegt mein Fehler? Wenn ich set hm tempList save tempList.cfg eingebe kommt die Meldung "Please define hm first".

Was mache ich falsch?

Ich denke da sollte in HM nachgebessert werden.
Aktuell kannst du

define Programm_SR_Urlaub notify Programm_SR:Urlaub attr Schlafzimmer tempListTmpl sru; set hm tempList -f Schlafzimmer restore

was offen ist, ist ein ordentliches Filehandling. Man kann das tempListfile im attribut angeben
attr hv_Clima tempListTmpl setup/tempList.cfg:Verena
Im Dir ./setup (also fhem/setup) wird das File tempList.cfg gesucht und in diesem das template "verena".

Das Dir hat einen default, der in HMInfo festgelegt werden kann. Für den Filenamen muss ich das ergänzen. Dann wäre ein korrektes Vorgehen
attr hm configDir setup
attr hm configTempListFile myTempList.cfg

ich will meine setup files in einem eigenen Dir haben. setzt man das dir nicht ist der default ./fhem.

Wenn du nun Modi im Haus umstellen willst kannst du für jeden Fall ein File anlegen
TmplUrlaub.cfg
TmplHomeoffice.cfg
TmplArbeit.cfg   
TmplAus.cfg       
mit den jeweiligen templates.
Häufig will man die RTs in der ganzen Wohnung umstellen, das geht dann auf einmal
attr hm configTempListFile TmplAus.cfg
Mit dem Ändern des Files sollte dann automatisch ein
set hm tempList restore
ausgeführt werden.
Aber das ist Zukunft - würde dir das passen?

Heute kannst du es ähnlich machen
define Programm_SR_Urlaub notify Programm_SR:Urlaub set hm tempList -f Schlafzimmer sru restore UrlaubtempList.cfg
define Programm_SR_HO notify Programm_SR:Homeoffice set hm tempList -f Schlafzimmer sru restore HOtempList.cfg
define Programm_SR_Work notify Programm_SR:Arbeit   set hm tempList -f Schlafzimmer sru restore WorktempList.cfg
define Programm_SR_Aus notify Programm_SR:Aus       set hm tempList -f Schlafzimmer sru restore AustempList.cfg

Meinungen?

define hm HMinfo

Ich bin inzwischen nicht mehr sicher, ob man nicht lieber einfache weekdaytimer definiert und auf den ganzen komplizierten und sperrigen  tmplist Kram verzichten sollte. Das geht immer, reagiert sofort, ist einfach und flexibel, was meint Ihr?

Ich benutze einfach nur eine Datei. In der habe ich dann Unterschiedliches definiert, z.B.:

entities:Gaestezimmer
tempListMon>24:00 17.0
tempListTue>24:00 17.0
tempListWed>24:00 17.0
tempListThu>24:00 17.0
tempListFri>24:00 17.0
tempListSat>24:00 17.0
tempListSun>24:00 17.0
entities:Gaestezimmer_abwesend
tempListMon>06:00 17.0 09:00 19.0 21:00 17.0 23:00 19.0 24:00 17.0
tempListTue>06:00 17.0 09:00 19.0 21:00 17.0 23:00 19.0 24:00 17.0
tempListWed>06:00 17.0 09:00 19.0 21:00 17.0 23:00 19.0 24:00 17.0
tempListThu>06:00 17.0 09:00 19.0 21:00 17.0 23:00 19.0 24:00 17.0
tempListFri>06:00 17.0 09:00 19.0 21:00 17.0 23:00 19.0 24:00 17.0
tempListSat>06:30 17.0 09:00 19.0 21:00 17.0 23:00 19.0 24:00 17.0
tempListSun>06:30 17.0 09:00 19.0 21:00 17.0 23:00 19.0 24:00 17.0
entities:Gaestezimmer_Gaeste
tempListMon>06:00 17.0 23:00 21.0 24:00 17.0
tempListTue>06:00 17.0 23:00 21.0 24:00 17.0
tempListWed>06:00 17.0 23:00 21.0 24:00 17.0
tempListThu>06:00 17.0 23:00 21.0 24:00 17.0
tempListFri>06:00 17.0 23:00 21.0 24:00 17.0
tempListSat>06:30 17.0 23:00 21.0 24:00 17.0
tempListSun>06:30 17.0 23:00 21.0 24:00 17.0

Je nach Bedarf kann ich den passenden Modus setzen, z.B. wenn Besuch da ist:

set Hzg_Gaestezimmer_Clima tempListTmpl restore /opt/fhem/tempList.cfg:Gaestezimmer_Gaeste

Fröhlichen Sonntag,
Christian

Zitat von: martinp876 am 01 November 2015, 11:30:48

Aber das ist Zukunft - würde dir das passen?

Hi Martin,

schöne ausführliche Antwort, hab verstanden. Da muss ich wohl oder übel mein single Tempfile anpassen bzw. aufteilen. Ich überlege mir noch was ich mache. Aktuell hab ich das Modul vom Update ausgenommen und es funktioniert ohne dass ich was ändern muss. Vielleicht nehme ich es als Anlass meine ganzen Dinge die aktuell in der Config rumliegen in ein eigenes Modul zu packen, dann kann ich mir über die Steuerung nochmal Gedanken machen wenn ich sowieso schon rumprogrammiere.

Danke für deine Zeit und Geduld :)

Zitat von: bgewehr am 01 November 2015, 11:55:48
Ich bin inzwischen nicht mehr sicher, ob man nicht lieber einfache weekdaytimer definiert und auf den ganzen komplizierten und sperrigen  tmplist Kram verzichten sollte. Das geht immer, reagiert sofort, ist einfach und flexibel, was meint Ihr?

Irgend einen Tod muss man sterben. Wenn man die Tempfiles mal verstanden hat ist es schön da alles in einer Textdatei liegt die man im Editor bearbeiten kann ohne FHEM anzufassen. Irgend wo muss man hinterlegen wann die Thermostate schalten sollen. Weekdaytimer müssen irgendwo definiert werden. Wenn man mehrere Programme pro Thermostat haben will (wie ich) dann kann es schnell unübersichtlich werden.

Für Programme die starr sind wäre es sicherlich eine Alternative.

ich habe es soweit implementiert - werde es nachher einchecken. Es gibt der Optionen viele.

schon länger vorhanden ist

Zitatset Schlafzimmer tempListTmpl sru
set Schlafzimmer tempListTmpl sru verify
set Schlafzimmer tempListTmpl verify sru
set Schlafzimmer tempListTmpl verify tempList.cfg:sru
set Schlafzimmer tempListTmpl verify ./tempList.cfg:sru

Macht alles das gleiche. Neu wird sein, dass das template, bestehend aus <dir>/<file>:<templatename> mit HMinfo synchronisiert wird (wenn es HMInfo gibt). Will sagen man kann den Default für das File sowie das Dir in HMInfo setzen. Existiert es nicht ist default dir . und file tempList.cfg.

DeFacto überschreibt das template im Kommando das attribut tempListTmpl für die Dauer des Kommandos.
set Schlafzimmer tempListTmpl
macht ein Verify und nutzt das Attribut anstelle des expliziten templates.

Die angekündigten Möglichkeiten über das Attribut im HMInfo templates im großen Stil umzusetzen besteht damit auch.
Das kann man nun nach Gusto nutzen.

Selbstverständlich kann man auch alles über notifies u.ä. machen. auch wenn es nie mein Weg sein wird - eben nach Gusto.

Zitat von: martinp876 am 01 November 2015, 18:13:40
Die angekündigten Möglichkeiten über das Attribut im HMInfo templates im großen Stil umzusetzen besteht damit auch.
Das kann man nun nach Gusto nutzen.

Ich habe auch vor, mehrere Heizprofile im mehreren Config-Files zu verwalten.
Habe mir gerade das Update gezogen. Das Attribut, um ein Template-File zu "aktivieren" heßt nun configTempFile, oder?
Ein verify/restore, etc. ist nich mehr nötig?

Noch ist das restore verify notwendig.
Auch sind die Möglichkeiten der Automatik begrenzt. Wenn es eingebaut ist kann beim setzen ein restore stattfinden. Sollten Änderungen im betrieb oder beim gestartet,..... Stattfinden wird nichts passieren. Fhem müsste es sonst zyklisch prüfen. Wenn du dies wünschst mache das z.b. täglich mit einem at, ein restore. Wenn nichts zu tun ist wird nichts getan

Ja, habe ich gestern probiert, nur das Setzen des configTempFile reicht hier nicht.
Sehe ich das dann richtig, dass dieses Attibut nur dafür gedacht ist, wenn man die TempList-Datei anders benennen will wie tempList.cfg?

Wenn dem so ist, dann muss ich dieses Attribut ja gar nicht setzen, wenn ich das Heizprofil umschalten will, dann müsste ein restore neueTempList.cfg reicht.
Sehe ich das richtig?

So, habe nun ein wenig rumprobiert, bekomme es aber nicht so hin wie gewünscht. Ich wälze schon seit Tagen Wiki-Einträge, komme aber nicht weiter. Wäre daher über jeden Tipp dankbar.

Folgende Situation:
Bei den verwendeten HM Geräten (siehe Signatur) ist autoReadReg auf 5_readMissing konfiguriert (in den Devices, nicht in den Channels).

Nun habe ich zwei TempListen (ich Liste hier nur die Einträge für einen Raum auf, die anderen Räume sind analog konfiguriert):

tempList.cfg (Normalbetrieb):

entities:Buero.Heizung_Clima
R_0_tempListSat>24:00 0.0
R_1_tempListSun>24:00 0.0
R_2_tempListMon>24:00 0.0
R_3_tempListTue>24:00 0.0
R_4_tempListWed>24:00 0.0
R_5_tempListThu>24:00 0.0
R_6_tempListFri>24:00 0.0
entities:Buero.Thermostat_Climate
R_P1_0_tempListSat>10:00 17.0 20:00 21.0 24:00 17.0
R_P1_1_tempListSun>10:00 17.0 20:00 21.0 24:00 17.0
R_P1_2_tempListMon>16:00 17.0 20:00 21.0 24:00 17.0
R_P1_3_tempListTue>16:00 17.0 20:00 21.0 24:00 17.0
R_P1_4_tempListWed>16:00 17.0 20:00 21.0 24:00 17.0
R_P1_5_tempListThu>16:00 17.0 20:00 21.0 24:00 17.0
R_P1_6_tempListFri>16:00 17.0 20:00 21.0 24:00 17.0
R_P2_0_tempListSat>24:00 17.0
R_P2_1_tempListSun>24:00 17.0
R_P2_2_tempListMon>24:00 17.0
R_P2_3_tempListTue>24:00 17.0
R_P2_4_tempListWed>24:00 17.0
R_P2_5_tempListThu>24:00 17.0
R_P2_6_tempListFri>24:00 17.0
R_P3_0_tempListSat>24:00 17.0
R_P3_1_tempListSun>24:00 17.0
R_P3_2_tempListMon>24:00 17.0
R_P3_3_tempListTue>24:00 17.0
R_P3_4_tempListWed>24:00 17.0
R_P3_5_tempListThu>24:00 17.0
R_P3_6_tempListFri>24:00 17.0


tempListAbsent.cfg (Heizungen sollen komplett aus sein):

entities:Buero.Heizung_Clima
R_0_tempListSat>24:00 0.0
R_1_tempListSun>24:00 0.0
R_2_tempListMon>24:00 0.0
R_3_tempListTue>24:00 0.0
R_4_tempListWed>24:00 0.0
R_5_tempListThu>24:00 0.0
R_6_tempListFri>24:00 0.0
entities:Buero.Thermostat_Climate
R_P1_0_tempListSat>24:00 0.0
R_P1_1_tempListSun>24:00 0.0
R_P1_2_tempListMon>24:00 0.0
R_P1_3_tempListTue>24:00 0.0
R_P1_4_tempListWed>24:00 0.0
R_P1_5_tempListThu>24:00 0.0
R_P1_6_tempListFri>24:00 0.0
R_P2_0_tempListSat>24:00 17.0
R_P2_1_tempListSun>24:00 17.0
R_P2_2_tempListMon>24:00 17.0
R_P2_3_tempListTue>24:00 17.0
R_P2_4_tempListWed>24:00 17.0
R_P2_5_tempListThu>24:00 17.0
R_P2_6_tempListFri>24:00 17.0
R_P3_0_tempListSat>24:00 17.0
R_P3_1_tempListSun>24:00 17.0
R_P3_2_tempListMon>24:00 17.0
R_P3_3_tempListTue>24:00 17.0
R_P3_4_tempListWed>24:00 17.0
R_P3_5_tempListThu>24:00 17.0
R_P3_6_tempListFri>24:00 17.0


Zu beachten: Ich lasse die Thermostate an der Heizung immer auf 0°C eingestellt, um die Last am HMlan möglichst gering zu halten, wenn zwischen den Heizprofilen hin und her geschaltet wird. Diese werden dann über die Wandthermostate gesteuert (Channels ,,Clima" am Heizungsthermostat und ,,Climate" am Wandthermostat sind gepeert).

Nun habe ich in 99_myUtils.pm zwei Funktionen definiert, die die Heizungsprofile umschalten sollen:

sub
SetTempListHeizung()
{
   { fhem ("set HMinfo tempList restore tempList.cfg")};
}
# End SetTempListHeizung

sub
SetTempListHeizungAbsence()
{
   { fhem ("set HMinfo tempList restore tempListAbsent.cfg")};
}
# End SetTempListHeizungAbsence


Ich habe gerade FHEM neu gestartet und dem HMlan kurz vom Strom getrennt (wegen Overload). Die Heizungen befanden sich im Zustand "anwesend" (tempList.cfg).
Sobald ich nun {SetTempListHeizungAbsence} aufrufe, würde ich erwarten, dass FHEM lediglich die Wochenprogramme 1 der Wandthermostate "umprogrammiert".

Im Log erscheint dann zunächst folgendes (für alle entsprechenden Channels):

2015.11.03 16:48:20 3: CUL_HM set Buero.Thermostat_Climate tempListSat prep p1 24:00 0.0
2015.11.03 16:48:20 3: CUL_HM set Buero.Thermostat_Climate tempListSun prep p1 24:00 0.0
2015.11.03 16:48:20 3: CUL_HM set Buero.Thermostat_Climate tempListMon prep p1 24:00 0.0
2015.11.03 16:48:20 3: CUL_HM set Buero.Thermostat_Climate tempListTue prep p1 24:00 0.0
2015.11.03 16:48:20 3: CUL_HM set Buero.Thermostat_Climate tempListWed prep p1 24:00 0.0
2015.11.03 16:48:20 3: CUL_HM set Buero.Thermostat_Climate tempListThu prep p1 24:00 0.0
2015.11.03 16:48:20 3: CUL_HM set Buero.Thermostat_Climate tempListFri prep p1 24:00 0.0
2015.11.03 16:48:20 3: CUL_HM set Buero.Thermostat_Climate tempListSat prep p2 24:00 17.0
2015.11.03 16:48:20 3: CUL_HM set Buero.Thermostat_Climate tempListSun prep p2 24:00 17.0
2015.11.03 16:48:20 3: CUL_HM set Buero.Thermostat_Climate tempListMon prep p2 24:00 17.0
2015.11.03 16:48:20 3: CUL_HM set Buero.Thermostat_Climate tempListTue prep p2 24:00 17.0
2015.11.03 16:48:20 3: CUL_HM set Buero.Thermostat_Climate tempListWed prep p2 24:00 17.0
2015.11.03 16:48:20 3: CUL_HM set Buero.Thermostat_Climate tempListThu prep p2 24:00 17.0
2015.11.03 16:48:20 3: CUL_HM set Buero.Thermostat_Climate tempListFri prep p2 24:00 17.0
2015.11.03 16:48:20 3: CUL_HM set Buero.Thermostat_Climate tempListSat prep p3 24:00 17.0
2015.11.03 16:48:20 3: CUL_HM set Buero.Thermostat_Climate tempListSun prep p3 24:00 17.0
2015.11.03 16:48:20 3: CUL_HM set Buero.Thermostat_Climate tempListMon prep p3 24:00 17.0
2015.11.03 16:48:20 3: CUL_HM set Buero.Thermostat_Climate tempListTue prep p3 24:00 17.0
2015.11.03 16:48:20 3: CUL_HM set Buero.Thermostat_Climate tempListWed prep p3 24:00 17.0
2015.11.03 16:48:20 3: CUL_HM set Buero.Thermostat_Climate tempListThu prep p3 24:00 17.0
2015.11.03 16:48:20 3: CUL_HM set Buero.Thermostat_Climate tempListFri prep p3 24:00 17.0
2015.11.03 16:48:20 3: CUL_HM set Buero.Thermostat_Climate tempListFri exec p3 24:00 17.0


Anschließend:

passed: ./././FHEM/tempListAbsent.cfg:Buero.Thermostat_Climate for Buero.Thermostat_Climate
passed: ./././FHEM/tempListAbsent.cfg:Kueche.Heizung_Clima for Kueche.Heizung_Clima
passed: ./././FHEM/tempListAbsent.cfg:Kueche.Thermostat_Climate for Kueche.Thermostat_Climate
passed: ./././FHEM/tempListAbsent.cfg:Schlafzimmer.Heizung_Clima for Schlafzimmer.Heizung_Clima
passed: ./././FHEM/tempListAbsent.cfg:Schlafzimmer.Thermostat_Climate for Schlafzimmer.Thermostat_Climate
passed: ./././FHEM/tempListAbsent.cfg:Wohnzimmer.HeizungFenster_Clima for Wohnzimmer.HeizungFenster_Clima
passed: ./././FHEM/tempListAbsent.cfg:Wohnzimmer.HeizungTv_Clima for Wohnzimmer.HeizungTv_Clima
passed: ./././FHEM/tempListAbsent.cfg:Wohnzimmer.Thermostat_Climate for Wohnzimmer.Thermostat_Climate


get hm configCheck: Hier gibt's mismatches, soweit logisch.

incomplete register list
    Buero.Thermostat_Climate: RegL_07:
    Schlafzimmer.Thermostat_Climate: RegL_07:

Register changes pending
    Buero.Thermostat_Climate
    Kueche.Thermostat_Climate
    Schlafzimmer.Thermostat_Climate
    Wohnzimmer.Thermostat_Climate

trigger sent to undefined device
    triggerUndefined: Wohnzimmer.Killswitch_ButtonOff:2BAC0F
    triggerUndefined: Wohnzimmer.Killswitch_ButtonOn:2BAC0F

templist mismatch
    Buero.Thermostat_Climate: failed Entries:
     Buero.Thermostat_Climate :R_P1_0_tempListSat mismatch 10:00 17.0 20:00 21.0 24:00 17.0 ne 24:00 0.0 ##
     Buero.Thermostat_Climate :R_P1_1_tempListSun mismatch 10:00 17.0 20:00 21.0 24:00 17.0 ne 24:00 0.0 ##
     Buero.Thermostat_Climate :R_P1_2_tempListMon mismatch 16:00 17.0 20:00 21.0 24:00 17.0 ne 24:00 0.0 ##
     Buero.Thermostat_Climate :R_P1_3_tempListTue mismatch 16:00 17.0 20:00 21.0 24:00 17.0 ne 24:00 0.0 ##
     Buero.Thermostat_Climate :R_P1_4_tempListWed mismatch 16:00 17.0 20:00 21.0 24:00 17.0 ne 24:00 0.0 ##
     Buero.Thermostat_Climate :R_P1_5_tempListThu mismatch 16:00 17.0 20:00 21.0 24:00 17.0 ne 24:00 0.0 ##
     Buero.Thermostat_Climate :R_P1_6_tempListFri mismatch 16:00 17.0 20:00 21.0 24:00 17.0 ne 24:00 0.0 ##
Buero.Thermostat_Climate: tempList not verified
    Kueche.Thermostat_Climate: failed Entries:
     Kueche.Thermostat_Climate :R_P1_0_tempListSat mismatch 24:00 17.0 ne 24:00 0.0 ##
     Kueche.Thermostat_Climate :R_P1_1_tempListSun mismatch 24:00 17.0 ne 24:00 0.0 ##
     Kueche.Thermostat_Climate :R_P1_2_tempListMon mismatch 24:00 17.0 ne 24:00 0.0 ##
     Kueche.Thermostat_Climate :R_P1_3_tempListTue mismatch 24:00 17.0 ne 24:00 0.0 ##
     Kueche.Thermostat_Climate :R_P1_4_tempListWed mismatch 24:00 17.0 ne 24:00 0.0 ##
     Kueche.Thermostat_Climate :R_P1_5_tempListThu mismatch 24:00 17.0 ne 24:00 0.0 ##
     Kueche.Thermostat_Climate :R_P1_6_tempListFri mismatch 24:00 17.0 ne 24:00 0.0 ##
Kueche.Thermostat_Climate: tempList not verified
    Schlafzimmer.Thermostat_Climate: failed Entries:
     Schlafzimmer.Thermostat_Climate :R_P1_0_tempListSat mismatch 06:00 16.0 10:00 18.0 18:00 16.0 22:00 18.0 24:00 16.0 ne 24:00 0.0 ##
     Schlafzimmer.Thermostat_Climate :R_P1_1_tempListSun mismatch 06:00 16.0 10:00 18.0 18:00 16.0 22:00 18.0 24:00 16.0 ne 24:00 0.0 ##
     Schlafzimmer.Thermostat_Climate :R_P1_2_tempListMon mismatch 06:00 16.0 10:00 18.0 18:00 16.0 22:00 18.0 24:00 16.0 ne 24:00 0.0 ##
     Schlafzimmer.Thermostat_Climate :R_P1_3_tempListTue mismatch 06:00 16.0 10:00 18.0 18:00 16.0 22:00 18.0 24:00 16.0 ne 24:00 0.0 ##
     Schlafzimmer.Thermostat_Climate :R_P1_4_tempListWed mismatch 06:00 16.0 10:00 18.0 18:00 16.0 22:00 18.0 24:00 16.0 ne 24:00 0.0 ##
     Schlafzimmer.Thermostat_Climate :R_P1_5_tempListThu mismatch 06:00 16.0 10:00 18.0 18:00 16.0 22:00 18.0 24:00 16.0 ne 24:00 0.0 ##
     Schlafzimmer.Thermostat_Climate :R_P1_6_tempListFri mismatch 06:00 16.0 10:00 18.0 18:00 16.0 22:00 18.0 24:00 16.0 ne 24:00 0.0 ##
Schlafzimmer.Thermostat_Climate: tempList not verified
    Wohnzimmer.Thermostat_Climate: failed Entries:
     Wohnzimmer.Thermostat_Climate :R_P1_0_tempListSat mismatch 15:00 19.0 22:00 21.5 24:00 19.0 ne 24:00 0.0 ##
     Wohnzimmer.Thermostat_Climate :R_P1_1_tempListSun mismatch 15:00 19.0 22:00 21.5 24:00 19.0 ne 24:00 0.0 ##
     Wohnzimmer.Thermostat_Climate :R_P1_2_tempListMon mismatch 15:00 19.0 22:00 21.5 24:00 19.0 ne 24:00 0.0 ##
     Wohnzimmer.Thermostat_Climate :R_P1_3_tempListTue mismatch 15:00 19.0 22:00 21.5 24:00 19.0 ne 24:00 0.0 ##
     Wohnzimmer.Thermostat_Climate :R_P1_4_tempListWed mismatch 15:00 19.0 22:00 21.5 24:00 19.0 ne 24:00 0.0 ##
     Wohnzimmer.Thermostat_Climate :R_P1_5_tempListThu mismatch 15:00 19.0 22:00 21.5 24:00 19.0 ne 24:00 0.0 ##
     Wohnzimmer.Thermostat_Climate :R_P1_6_tempListFri mismatch 15:00 19.0 22:00 21.5 24:00 19.0 ne 24:00 0.0 ##
Wohnzimmer.Thermostat_Climate: tempList not verified


Nun passiert es aber: Innerhalb von Sekunden gibt es einen Overload am HMlan (msgLoadHistory 5min steps: 0/0/0/100/0/-/-/-/-/-/-/- )

get hm protoEvents liefert dann folgendes (hier hat er sich schon ein wenig erholt, nur noch HighLoad):

protoEvents done:
    name                      :State           |CmdPend   |Snd       |Resnd     #CmdDel    |ResndFail |Nack      |IOerr
    Buero.Heizung             :  -             | -        | -        | -        # -        | -        | -        | -
    Buero.Thermostat          : done_Errors:1  | -        |14:       |1:        #3         |1:        | -        | -
    Kueche.Heizung            :  -             | -        | -        | -        # -        | -        | -        | -
    Kueche.Thermostat         : pending        |5 pending |5:        | -        # -        | -        | -        | -
    Schlafzimmer.Heizung      :  -             | -        | -        | -        # -        | -        | -        | -
    Schlafzimmer.Thermostat   : done_Errors:1  | -        |13:       |3:        #3         |1:        | -        | -
    Wohnzimmer.HeizungFenster :  -             | -        | -        | -        # -        | -        | -        | -
    Wohnzimmer.HeizungTv      :  -             | -        | -        | -        # -        | -        | -        | -
    Wohnzimmer.Killswitch     :  -             | -        | -        | -        # -        | -        | -        | -
    Wohnzimmer.Thermostat     : done_Errors:1  | -        |5:        |59022:    #5         | -        | -        |1:
================================================================================================================
    sum                       3                |5         |37        |59026     #11        |2         |0         |1

    CUL_HM queue length:0

    requests pending
    ----------------
    autoReadReg          : Wohnzimmer.Thermostat
        recent           : none
    status request       :
    autoReadReg wakeup   :
    status request wakeup:
    autoReadTest         : Buero.Thermostat Buero.Heizung Schlafzimmer.Heizung Schlafzimmer.Thermostat Kueche.Heizung Kueche.Thermostat Wohnzimmer.HeizungTv Wohnzimmer.HeizungFenster Wohnzimmer.Thermostat Wohnzimmer.Killswitch Buero.Thermostat_Climate Kueche.Thermostat_Climate Schlafzimmer.Thermostat_Climate

    IODevs:HMLAN1:opened pending=0 condition:Warning-HighLoad


Die Register R_P1_tempList_State der Climate-Channels der Wandthermostate stehen nun alle auf "set".

Wenn ich nun noch einmal den Stecker vom HMlan ziehe und FHEM neu starte, fängt er sich soweit wieder. Das loadLvl des HMlan bleibt bei low. Allerdings werden nicht alle TempListen verified. Diese bleiben nach wie vor auf "set" stehen. Es wird auch kein automatisches getConfig aufgerufen.

Meine Fragen sind nun:

• Was kann der Auslöser dieser Message-Flut sein, die dann zum Overload führt? Ich meine, es werden ja eigentlich nur die Wochenprogramme von 4 Wandthermostaten umprogrammiert, das sollte mit dem HMlan doch auch ohne Overload möglich sein.
  
• Habe ich hier evtl. etwas offensichtlich falsch gemacht?
  
• Falls es mal halbwegs funktioniert, bleibt meist ein Gerät mit "CMDs_done_Errors:1" hängen. Weder das Log, noch der Eventmonitor gibt Auskunft darüber, was hier schief gelaufen ist. Gibt es hier eine Möglichkeit, die ich bis jetzt nicht gefunden habe?
  

Sorry für den langen Post, habe versucht, alle notwendigen Infos mit anzufügen. Falls noch was fehlt, reiche ich das gerne nach.

Das Attribut ist der default filename. Wenn im template ein filename angegeben ist hatmdermvorrang.
Wenn du nun ein restore ausführen wird der unterschied zwischen template und fhem gelesenen Registern geschrieben.
Danach, wenn die message load es zulässt kommt ein getconfig.
Fhem schreibt wenn der RT erwacht. Solltest du mit burst arbeiten ist dies sicher tötlich.
Wieviele RTS hast du?

Zitat von: martinp876 am 03 November 2015, 20:00:08
Wieviele RTS hast du?

4x TC und 5x RT.

Das mit burst kam mir auch schon in den Sinn. Aber habe schon an verschiedenen Stellen gelesen, dass Burst standardmäßig nicht aktiviert ist.

Der Wert "R-burstRx" steht in allen Devices auf "on": Das sagt doch aber nur aus, dass das Device durch Burst weckbar ist, oder? Dieser Wert lässt sich übrigens nicht mit set <Device> regSet burstRx off abschalten. Das Register wird auf "set_off" gesetzt, ist anschließend  (nach getConfig) wieder "on".
Attribut "burstAccess" ist in keinem Device gesetzt.

Mehr Einstellungen zu Burst, oder wie ich es aktivieren/deaktivieren kann, habe ich nicht gefunden. Kann ich den burst mode gezielt unterbinden?

set HMinfo param -d protCondBurst R-burstRx liefert:

param done:
param list
    entity              : protCondBurst        |R-burstRx            |
    Buero.Heizung        :  -              |on
    Buero.Thermostat    :  -              |on
    Kueche.Heizung      :  -              |on
    Kueche.Thermostat    : on              |on
    Schlafzimmer.Heizung :  -              |on
    Schlafzimmer.Thermostat :  -              |on
    Wohnzimmer.HeizungFenster :  -              |on
    Wohnzimmer.HeizungTv :  -              |on
    Wohnzimmer.Thermostat :  -              |on


Wenn ich das richtig interpretiere, läuft Kueche.Thermostat im conditional Burst, die anderen Devices nicht. Ich wüsste allerdings nicht, was ich bei diesem Device anders gemacht hätte.

Edit: protCondBurst steht bei allen Devices auf "forced_off" (set HMinfo param -d protCondBurst R-burstRx). Ich habe nun mal burstAccess auf "0_off" gestellt und FHEM neu gestartet. Hat diese einstellung protCondBurst = forced_off  bewirkt?
Ist das die Einstellung, ob Burst verwendet werden soll oder nicht?
Was war da vorher los (siehe oben), so bei protCondBurst bei (fast) allen Devices "-" stand?

Zitat von: martinp876 am 01 November 2015, 11:31:20

Code Auswählen Erweitern

define hm HMinfo

Normal ist das bestimmt nicht daß dann folgende Meldung erscheint:

sumERROR: battery:ok,sabotageError:off,powerError:ok,overload:off,overheat:off,reduced:off,motorErr:ok,error:none,uncertain:[no|yes],smoke_detect:none,cover:closed

Oder?

So, noch ein kleines Status-Update, habe gerade wieder etwas herumprobiert.

Nachdem ich burstAccess bei allen Devices auf 0_off gestellt habe und so den Burst-Mode "mit Gewalt" ausgeschaltet habe (zumindest interpretiere ich die Wiki- und Foren-Einträge bzgl. burstAccess so), scheint das nun auch ohne Overload zu funktionieren.
Auch ein Löschen des Attributs in allen Devices lässt den HMlan nicht mehr überhitzen.

Keine Ahnung, was da vorher schief gelaufen ist. Ich dachte eigentlich, das HMinfo selbst auf die Last am HMlan achtet und ggf. das Senden weiterer Befehle verzögert, wenn bereits Last am HMlan vorhanden ist. Das scheint in meinem Fall allerdings nicht wirklich funktioniert zu haben.

Aber eine Frage bleibt noch (trotz langer Suche um Forum und im Wiki):
Was ist der "offizielle" Weg, um den Burst-Modus auszuschalten bzw. einzuschalten?

Ohne Deine Frage beantworten zu können: Ist ohne burst die Reaktionszeit merklich länger?

Zitat von: Motivierte linke Hände am 04 November 2015, 17:59:20
Ohne Deine Frage beantworten zu können: Ist ohne burst die Reaktionszeit merklich länger?

Jein.
Also ich gehe mal davon aus, dass in meiner ursprünglichen Konfiguration "geburstet" wurde. Hier hatte ich innerhalb von Sekunden einen Overload. Dann heißt es entweder warten, bis sich der HMlan erholt hat oder den HMlan kurz vom Strom trennen (was unpraktisch ist, wenn man nicht zu Hause ist).
Ohne Burst dauert das Umschalten der Heizprofile nun ca. 20 Min., es gibt aber keinen Overload.

Also ja, es dauert länger, was aber immer noch besser ist, also mit einem Overload festzustecken.

ein Device meldet sich so alle 2,5min. Wenn es sich Meldet werden die Daten übertragen.
Ändert man die desiredtemp wird beim darauffolgenden melden (also nach 5 min) die korrektur gemeldet - der RT hatte das schon 2,5 min eher.

Es kann nun zu Kollosionen kommen, wenn viele RTs sich gleichzeitig melden. Dann werden evtl. nicht alle Daten übertragen, es wird beim nächsten Auswachen wiederholt.
Burstet man viele Devices gleichzeitig kommt es auch zu kollisionen - und zwar sicher. Das warten entzerrt also auch die Situation.

=> wer so etwas burstet ist selbst schuld. So schnell muss man keine templist ändern.

Bei einem Einzelnen Device oder beim testen ist das hilfreich.

Habe gerade eine Korrektur zum Attribut eingecheckt. Das mit HMInfo hat nicht komplett funktioniert.

Zitat von: DecaTec am 04 November 2015, 17:29:49
Aber eine Frage bleibt noch (trotz langer Suche um Forum und im Wiki):
Was ist der "offizielle" Weg, um den Burst-Modus auszuschalten bzw. einzuschalten?

Diese Frage habe ich nach wie vor. Gibt es hier einen offiziellen Weg?

Zitat von: martinp876 am 04 November 2015, 20:31:57
Habe gerade eine Korrektur zum Attribut eingecheckt. Das mit HMInfo hat nicht komplett funktioniert.

Was genau wurde hier geändert?

Was meinst du mit offiziellem weg?
Es liegt bei dir, es zu verwenden wie es dir passt. Burst ist hinreichend in der doku erklärt. Eben nochmal: man kann sofort senden ohne auf das aufwachen zu warten. Device2device Kommunikation braucht burst da ein Sender nie wartet. Die zentrale kann warten.
Du kannst einschalten, dass immer sofort, automatisch mit burst gesendet wird. Ist definitiv nicht empfohlen. Du kannst mit Kommando gezielt burst senden. Nutze ich beim testen, weil es schneller geht. Baue ich nie in Automatismen wie notifies ein. Die müssen warten.
Du kannst warten. Das sollte der normale weg sein, meine ich.
Burst brauchen ein vielfaches der sendekapazitaet der message. Sie verbrauchen Batterie in ALLEN burst sensitiven devices¡, auch wenn sie nicht adressiert werden.

Was genau geändert wurde... Es wurden bugs beseitigt. Die Vorversion war Schrott in Hinsicht auf das einstellen von templistfile. Jetzt hoffe ich, dass es passt. Details im code

Ich habe das selbe Problem wie im Post
http://forum.fhem.de/index.php/topic,28211.msg354441.html#msg354441 (http://forum.fhem.de/index.php/topic,28211.msg354441.html#msg354441)

Mit
set RT regSet burstRx off
lässt sich das nicht setzen. Nach "set_off" geht das Register immer wieder auf den Wert "on".

Ich hoffe mal dass das Attribut "burstAccess" mit dem Wert "0_off" den gewünschten Effekt liefert.

das Verhalten kann ich bestätigen.
Fakt: Das Ändern des Register wird komplett abgearbeitet und bestätigt. Es hat jedoch einen Erfolg, sprich das Bit bleibt stehen. Ferner bleicht auch der Mode bestehen.
=> Das Register zeigt den Aktuellen Stand an, ist aber nicht (mehr) änderbar.
In den frühen FW- Versionen war es änderbar. Es kann a) an der FW-Version liegen oder b) am peeren/pairen. Das habe ich nicht probiert, kann es also nicht ausschliessen.

Meine Bewertung (auch wenn ich es sowieso nicht ändern kann): schlimm ist dies nicht, man sollte einfach mit der Nutzng von Burst (sowieso) vorsichtig sein.