HM-CC-RT-DN

[Jojo11]

@jo
die templist sollte sich nicht aendern. es könnte einen reset gegeben haben (warum auch immer). dann sollte die liste auf default stehen. Alles andere kann ich mir nicht erklären.

Ok, das könnte passen. Irgendwie will die Liste bei mir aber immer noch nicht so richtig. Wenn ich alles auf einmal übertrage, bekomme ich irgendwann ein "verified" bei tempList_State, aber die Werte für Freitag, Samstag und Sonntag sind trotzdem falsch. Jetzt versuche ich gerade mal wieder, die Tage einzeln zu schicken. Müsste dann der tempList_State nicht unmittelbar auf "set" wechseln (habe auch ein "set xxx getConfig" geschickt)? Oder gibt es einen Trick, die Werte ans Gerät zu schicken (manuell oder automatisch), so dass sie auch alle ankommen?

schöne Grüße
Jo

[martinp876]

@Buri
gut, dass es klappt. sicher müsste ich nur mehrfach das peeren probieren.
bei sauber gepeerten fensterkontakten (mit jeden RT) sollte es auch keine Probleme geben - ich denke, da wird die desired-temp auch nicht ausgetauscht. das passiert wohl nur bei internen aenderngen.
=> wird die temp auch übertragen, wenn du nur einen vn der Zentrale aus aenderst?

da getConfig liegt am attribut
autoReadReg
kannst du, wenn nicht gewünscht, auf 0 setzen. ansonsten wird der default (=4) gesetzt. Das attribut wird nur im Device gesetzt.


@jo,
zum einen: kannst du einmal rohmessages aufzeichnen? dann kann ich noch einmal durchsehen.

2) verified setze ich, wenn die Werte,die in den Readings angezeigt werden auch "frisch" aus den registern gelesen wurden. "set" kommt wenn nach dem letzten lesen eine Änderung vorgenommen wurde.
nach den setzen sollte der zustand sofort auf set gehen. Verified kommt, sobald die register eingelesen und abgeglichen sind
Achtung: es findet kein vergleich statt. es werden IMMER die werte ausgegeben, die im Register stehen.
Ob die Übertragung funktioniert hat steht in den "Proto" variablen.

[BuRi]

Hallo,,
Noch ein kurzer Erfahrungsbericht zum peeren.  Es kommt auf die richtige reihenfolge beim anlernen an!  
Erst wenn nan den Sensor zuerst anlernt ist es ok. ansonsten taucht er zwar in der peer liste auf funzt aber nicht!

Gruß
Burchard

[Jojo11]

@jo,
zum einen: kannst du einmal rohmessages aufzeichnen? dann kann ich noch einmal durchsehen.

2) verified setze ich, wenn die Werte,die in den Readings angezeigt werden auch "frisch" aus den registern gelesen wurden. "set" kommt wenn nach dem letzten lesen eine Änderung vorgenommen wurde.
nach den setzen sollte der zustand sofort auf set gehen. Verified kommt, sobald die register eingelesen und abgeglichen sind
Achtung: es findet kein vergleich statt. es werden IMMER die werte ausgegeben, die im Register stehen.
Ob die Übertragung funktioniert hat steht in den "Proto" variablen.

Danke erstmal. Es ist wie verhext. Kaum setze ich

Code Auswählen Erweitern

attr global verbose 1
attr mseclog 1
attr HMLAN1 loglevel 1
scheint es zu funktionieren. Zumindest scheinen die Werte jetzt in der Warteschleife zu sein.

Der Auszug sieht so aus:

Code Auswählen Erweitern


2013.10.05 17:57:08.289 1: HMLAN_Send:  HMLAN1 I:K
2013.10.05 17:57:08.307 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0314688 d:1C69A4 O:123ABC t:4346E8CC IDcnt:0014
2013.10.05 17:57:33.303 1: HMLAN_Send:  HMLAN1 I:K
2013.10.05 17:57:33.310 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0314688 d:1C69A4 O:123ABC t:43474A86 IDcnt:0014
Use of uninitialized value in hash element at ./FHEM/01_FHEMWEB.pm line 1088.
Use of uninitialized value in split at ./FHEM/01_FHEMWEB.pm line 1093.
2013.10.05 17:57:58.711 1: HMLAN_Send:  HMLAN1 I:K
2013.10.05 17:57:58.722 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0314688 d:1C69A4 O:123ABC t:4347ADC9 IDcnt:0014
2013.10.05 17:58:13.432 1: HMLAN_Parse: HMLAN1 R:E21CFF2   stat:0000 t:4347E741 d:FF r:FFBA     m:6D 8610 21CFF2 000000 0A88DE100019
2013.10.05 17:58:13.534 1: HMLAN_Send:  HMLAN1 S:S89572D08 stat:  00 t:00000000 d:01 r:89572D08 m:7E A112 123ABC 21CFF2
2013.10.05 17:58:13.727 1: HMLAN_Parse: HMLAN1 R:R89572D08 stat:0001 t:4347E84B d:FF r:FFB9     m:7E 8002 21CFF2 123ABC 00
2013.10.05 17:58:13.737 1: HMLAN_Send:  HMLAN1 S:S89572E2A stat:  00 t:00000000 d:01 r:89572E2A m:7F A001 123ABC 21CFF2 00050000000007
2013.10.05 17:58:14.095 1: HMLAN_Parse: HMLAN1 R:R89572E2A stat:0001 t:4347E9DE d:FF r:FFBA     m:7F 8002 21CFF2 123ABC 00
2013.10.05 17:58:14.108 1: HMLAN_Send:  HMLAN1 S:S89572F9C stat:  00 t:00000000 d:01 r:89572F9C m:80 A001 123ABC 21CFF2 00081444154E1654176C184419FC1A55
2013.10.05 17:58:14.498 1: HMLAN_Parse: HMLAN1 R:R89572F9C stat:0001 t:4347EB71 d:FF r:FFBA     m:80 8002 21CFF2 123ABC 00
2013.10.05 17:58:14.509 1: HMLAN_Send:  HMLAN1 S:S8957312D stat:  00 t:00000000 d:01 r:8957312D m:81 A001 123ABC 21CFF2 00081B141C451D20
2013.10.05 17:58:14.901 1: HMLAN_Parse: HMLAN1 R:R8957312D stat:0001 t:4347ED04 d:FF r:FFBA     m:81 8002 21CFF2 123ABC 00
2013.10.05 17:58:14.922 1: HMLAN_Send:  HMLAN1 S:S895732CB stat:  00 t:00000000 d:01 r:895732CB m:82 A001 123ABC 21CFF2 0006
2013.10.05 17:58:15.304 1: HMLAN_Parse: HMLAN1 R:R895732CB stat:0001 t:4347EE97 d:FF r:FFBA     m:82 8002 21CFF2 123ABC 00
2013.10.05 17:58:15.325 1: HMLAN_Send:  HMLAN1 S:+21CFF2,00,01,
2013.10.05 17:58:15.326 1: HMLAN_Send:  HMLAN1 S:S8957345E stat:  00 t:00000000 d:01 r:8957345E m:83 A001 123ABC 21CFF2 04040000000001
2013.10.05 17:58:16.154 1: HMLAN_Parse: HMLAN1 R:R8957345E stat:0008 t:00000000 d:FF r:7FFF     m:83 A001 123ABC 21CFF2 04040000000001
2013.10.05 17:58:16.155 1: HMLAN_Parse: HMLAN1 no ACK from 21CFF2
2013.10.05 17:58:19.704 1: HMLAN_Send:  HMLAN1 S:S89574578 stat:  00 t:00000000 d:01 r:89574578 m:83 A001 123ABC 21CFF2 04040000000001
2013.10.05 17:58:20.310 1: HMLAN_Parse: HMLAN1 R:R89574578 stat:0008 t:00000000 d:FF r:7FFF     m:83 A001 123ABC 21CFF2 04040000000001
2013.10.05 17:58:20.311 1: HMLAN_Parse: HMLAN1 no ACK from 21CFF2
2013.10.05 17:58:23.724 1: HMLAN_Send:  HMLAN1 I:K
2013.10.05 17:58:23.741 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0314688 d:1C69A4 O:123ABC t:43480F8B IDcnt:0014
2013.10.05 17:58:25.669 1: HMLAN_Send:  HMLAN1 S:S89575CC5 stat:  00 t:00000000 d:01 r:89575CC5 m:83 A001 123ABC 21CFF2 04040000000001
2013.10.05 17:58:26.275 1: HMLAN_Parse: HMLAN1 R:R89575CC5 stat:0008 t:00000000 d:FF r:7FFF     m:83 A001 123ABC 21CFF2 04040000000001
2013.10.05 17:58:26.276 1: HMLAN_Parse: HMLAN1 no ACK from 21CFF2
2013.10.05 17:58:35.997 1: HMLAN_Send:  HMLAN1 S:S8957851E stat:  00 t:00000000 d:01 r:8957851E m:83 A001 123ABC 21CFF2 04040000000001
2013.10.05 17:58:40.228 1: HMLAN_Parse: HMLAN1 R:R8957851E stat:0008 t:00000000 d:FF r:7FFF     m:83 A001 123ABC 21CFF2 04040000000001
2013.10.05 17:58:40.229 1: HMLAN_Parse: HMLAN1 no ACK from 21CFF2
Use of uninitialized value in hash element at ./FHEM/01_FHEMWEB.pm line 1088.
Use of uninitialized value in split at ./FHEM/01_FHEMWEB.pm line 1093.
2013.10.05 17:58:50.777 1: HMLAN_Send:  HMLAN1 I:K
2013.10.05 17:58:50.784 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0314688 d:1C69A4 O:123ABC t:43487932 IDcnt:0014
2013.10.05 17:59:10.356 1: HMLAN_Parse: HMLAN1 R:E21CFB0   stat:0000 t:4348C5A3 d:FF r:FFCD     m:4E 8610 21CFB0 000000 0A88D5100021
2013.10.05 17:59:15.791 1: HMLAN_Send:  HMLAN1 I:K
2013.10.05 17:59:15.799 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0314688 d:1C69A4 O:123ABC t:4348DAEC IDcnt:0014
2013.10.05 17:59:35.851 1: HMLAN_Send:  HMLAN1 S:S89586EEB stat:  00 t:00000000 d:01 r:89586EEB m:84 B112 123ABC 21CFB0
2013.10.05 17:59:40.712 1: HMLAN_Parse: HMLAN1 R:R89586EEB stat:0008 t:00000000 d:FF r:7FFF     m:84 B112 123ABC 21CFB0
2013.10.05 17:59:40.713 1: HMLAN_Parse: HMLAN1 no ACK from 21CFB0
2013.10.05 17:59:40.801 1: HMLAN_Send:  HMLAN1 I:K
2013.10.05 17:59:40.808 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0314688 d:1C69A4 O:123ABC t:43493CA1 IDcnt:0014
Use of uninitialized value in hash element at ./FHEM/01_FHEMWEB.pm line 1088.
Use of uninitialized value in split at ./FHEM/01_FHEMWEB.pm line 1093.


schöne Grüße
Jo

[martinp876]

Hi,

ok - ich denke es ist klar. Problem ist, dass der RT nach dem Schreiben ein päuschen braucht. da sind wir (normales senden) zu schnell. Das Bringt mich in ein (kleines) Dilemma.
ich kann warten. wenn du burst nutzt (bei dir nicht) dann werden die Kommandos noch abgearbeitet. wenn du wakeup nutzt (dein mode) wird der RT wahrscheinlich einschlafen - und man muss zum nächsten Aufwachen Warten. bei 7 Tagen sind dies 7*3min = 21 min dauer (wenn alles gut läuft).
ich habe noch einige Ideen im Kopf, wie man es machen könnte... aber das wird alles recht kompliziert und der User wird am Ende keinen Überblick mehr haben, das Verständnis verlieren. Mal sehen, was mir einfällt. In HM habe ich eine Variante mit templates...

mal nachdenken.
das ist jedenfalls der Grund - RT blocktiert nach dem (beim) Schreiben und FHEM timed aus.

p.s. noch einmal nachgetestet. Wenn man den RT in den burst mode versetzt funktioniert es ohne Probleme - jedenfalls bei mir.
Gruss Martin

[BuRi]

Hallo liebe Fachleute,

ich habe seit heute Mittag weiterhin massive Probleme. Entweder liegt es an den neuen Dateien, die ich heute Mittag installiert habe, oder an den RTs oder beides im Zusammenspiel.
Nachdem die RTs im Wohnzimmer einwandfrei funktionierten, habe ich alle RTs im Haus mit fhem gepairt. Seit dem Update hängt sich mein HMLAN regelmäßig auf und es geht dann nichts mehr.
Ich habe für alle Devices
attr Device autoReadReg 0_reqStatus gesetzt und nur bei dem RT, dessen tempList ich ändern will
attr Device autoReadReg 4_reqStatus

Trotzdem treten nach dem Senden eines set Templist weiterhin Fehler auf.
u.a steht folgende Fehlermeldung im logfile:

2013.10.05 21:13:51 1: 192.168.178.48:1000 disconnected, waiting to reappear
2013.10.05 21:13:51 1: 192.168.178.48:1000 reappeared (HMLAN1)
2013.10.05 21:13:51 2: HMLAN_Parse: HMLAN1 new condition init
2013.10.05 21:13:51 2: HMLAN_Parse: HMLAN1 new condition ok

oder es tritt ein Overload auf.

Hat jemand eine Idee oder ähnliche Probleme. Ich werde langsam etwas frustiert.
Im derzeitigen Stand kann man keine Templisten an die RT senden?!

Allen vielen Dank für die Unterstützung

Burchard

[unimatrix]

also seit dem autoreadreg 4 überall habe ich auch beim Neustarten von FHEM eine ganze Zeit ständig Overloads bis es sich dann beruhigt.

Habe hmLanQlen = 3_min und wdTimer=25. K.a. ob das noch tunebar ist. Habe ungefähr 30 Devices, dessen Config auslesbar ist.
   
ich finde das Feature mit dem autoreadreg prinzipiell gut. Man hat immer alle aktuellen Werte zur Hand und muss manuell nix machen.

GGf. wäre aber ein Tuning beim Timing möglich. Z.B. gerade wenn ich an meinen Scripten bastle, muss ich ständig FHEM neu starten (um die neuen Utils-Dateien zu laden) und dann kutz testen und dann wieder neu starten. Vll. sollte man nach dem Start das Auslesen der COnfigs nochmal verzögern? Außerdem vll den Abstand zwischen dem Auslesen aller Devices. Also k.a. nur ein device pro Minute. Dauert dann bis alles durch ist - aber das sollte normalerweise ja nicht stören...

Aber vll liegts bei mir auch an anderen Gründen, k.a. Wenn ich dasautoreadreg aber überall abschalte, dann habe ich keine Overloads mehr.

[martinp876]

HI,

der abstand zwischen devices beim lesen ist aktuell 15 sec. eine kurze einschaltverzögeung gibt es auch.

beim testen von scripts kannst du auch ein ein reload deines geaenderten moduls ins auge fassen. geht deutlich schneller und die register werden nicht neu geladen.
reload myutil.pm

@Burchard,
ich kann schon templisten senden - ohne Probleme.
Ein Problem stellt tatsächlich ein wenn man mehrere templisten an ein device senden will UND burstRx=off ist. da der RT nach schreiben immer eine EEPROM-gedenk-minute einlegt timed der "wakeup" aus und das schreiben der 2. Liste wird nicht funktionieren. da muss ich mir noch etwas einfallen lassen. Sonstige Probleme habe ich nicht - bitte logs schicken, wenn du welche hast.

Ich schiebe gerade noch eine kleien änderung nach, damit comfort und lower jetzt day und night heisen (passend zum TC und den Symbolen am LCD display

Gruss Martin

[martinp876]

Hallo,

allen leidenden am temp-list setzen - es gibt jetzt einen "compress mode" => V 4013.

man kann die Daten vorbereiten mit prep
mit exec werden dann alle Daten geschrieben. man hat also nur noch eine atomare msg-sequenz

Code Auswählen Erweitern

set <devClima> tempListSav prep 07:00 14.0 09:00 16.0 17:00 18.0 22:00 19.0 24:00 14.0
set <devClima> tempListTue prep 07:00 14.0 09:00 16.0 17:00 18.0 22:00 19.0 24:00 14.0
set <devClima> tempListWed exec 07:00 14.0 09:00 16.0 17:00 18.0 22:00 19.5 24:00 14.0


- ohne parameter werden nur die gelieferten daten im kommando geshrieben
- nach lesen des registers (getConfig) sind alle "wartenden" Daten wieder verloren.

Mit dieser Methode sollten auch die "wakeup" freunde erfolge erzielen können.

Achtung: nach dem schreiben macht der RT immer noch ein schläfchen - folgenden kommandos können also ggf abgebrochen/nicht beantwortet werden

Gruss Martin

[energy]

Und wieder eine Anfängerfrage ich möchte einen Fensterkontakt mit den HM-CC-RT-DN über Fhem peeren dazu habe ich set WZ_Fenster_links peerChan 0 WZ__WindowRec single
Eingetragen, das scheint grundsätzlich auch funktioniert zu haben im _WindowRec kann man den Fensterkontakt auch sehen.
Nur ob nun das Fenster offen oder zu ist macht das am Regler keinen Unterschied, was habe ich vergessen? was muss ich noch konfigurieren?

Code Auswählen Erweitern



Internals:
   DEF        21CF1B03
   NAME       WZ__WindowRec
   NR         80
   STATE      last:trigLast
   TYPE       CUL_HM
   chanNo     03
   device     WZ_Thermostat
   peerList   WZ_Fenster_links,
   Readings:
     2013-10-06 16:53:48   R-sign          off
     2013-10-06 17:01:41   peerList        WZ_Fenster_links,
   Helper:
     peerIDsRaw ,219C7001,00000000
     Prt:
       awake      1
     Role:
       chn        1
     Shadowreg:
Attributes:
   expert     1
   model      HM-CC-RT-DN
   peerIDs    00000000,219C7001,
   room       CUL_HM



Gruß
energy

[dusti64]

Der Auto-Mode macht ja noch weniger Sinn, dann greift ja womöglich kurz nach dem Setzen das Automatikprogramm des Ventils.

Automatikprogramm abschalten...

Hallo Leutz :)

nachdem ich mir nun auch so ein Teil zugelegt habe und es auch eingerichtet bekommen habe, ergeben sich natürlich für einen blutigen Neuling auf diesem Gebiet ein Haufen Fragen...
Die Templisten sind programmiert und auch verified. Mein Problem ist, dass am Thermostat nichts geändert wird, d.h. weder im Manu noch im Auto-Modus. Ich liege doch richtig, wenn ich annehme, dass der HMLAN nur regeln kann, wenn der Thermostat in Auto steht? Und jetzt zu dem Zitat oben...wie schalte ich denn die interne Programmierung aus, damit die Steuerung durch FHEM erfolgen kann? Wahrscheinlich ne sehr dumme Frage ;) aber ich find nirgends eine Einstellung dazu und bitte mal um Schützenhilfe...
Die zweite Frage ist, wie ich im WEBGUI mobile ein Kontrollfeld bekomme, damit ich über FHEMMobile auch steuern kann?

Großes Danke schon mal vorweg, vor allem an all die Leute hier, die sich ständig die zeit um die Ohren hauen, damit der ganze Krams auch funktioniert :)

Gruß Dusti

[martinp876]

Hallo energy,

du hast das Kommando auch für den SC abgesetzt - aber der SZ schläft gerne und viel. du musst noch anlernen drücken, damit er aufwacht und wir senden können.

nächster Schritt ist, dass der RT auch im bust mode ist. Schaue einmal nach, dass burstRx=on gesetzt ist.
und 3. Schritt sind, dass im SC peerneedsburst gesetzt ist. dass sollte eigentlich automatisch passieren, kannst du aber prüfen.

Gruss Martin

[Stefan M.]

Hallo Martin
ich hatte heute sehr viel Overload mit reconnects auf dem HMLan. Kann man da was dagegen tun außer zu warten. Was ist eigentlich die Ursache, liegt die im HMLan oder im FHEM? Kannst Du da noch einen Schutz einbauen ?

Version : 4010, 4005, HM aktuell auf der Fritzbox

lg
Stefan

[martinp876]

hm - scheint vermehrt aufzutreten.

ein autoReadReg konnte etwas dazu beitragen - aber nach dem booten spätestens sollte es geklärt sein. Und ständig aenderungen machst du ja nicht - oder?

Evtl doch einmal einen längernlog schicken

Gruss Martin

[energy]

Hallo Martin,

<du hast das Kommando auch für den SC abgesetzt - aber der SZ schläft gerne und viel. du musst noch anlernen drücken, damit er aufwacht und wir senden können.

was ist ein SZ ?

<nächster Schritt ist, dass der RT auch im bust mode ist. Schaue einmal nach, dass burstRx=on gesetzt ist.

ist angeschaltet !

<und 3. Schritt sind, dass im SC peerneedsburst gesetzt ist. dass sollte eigentlich automatisch passieren, kannst du aber prüfen.

ist auch an !

ich habe jetzt immer bei den Fensterkontakt ein MISSING ACK bei fenster offen nach den peeren ?


Gruß
energy