Hallo,
ich habe einen Fensterkontakt mit fhem gepairt und dann mit einem TC gepeert (hoffentlich habe ich mich da richtig ausgedrückt):
set threestatesensor_kueche_fenster_links peerChan 0 thermostat_kueche_windowrec single set
Jetzt ist dieser Fensterkontakt defekt und ich habe keine ahnung, wie ich pairing und peerings wieder rückgängig machen soll.
Folgendes habe ich ausprobiert, leider ohne Erfolg:
set threestatesensor_kueche_fenster_links peerChan 0 thermostat_kueche_windowrec single unset
Grüße ins Forum
Thorsten
hallo Thorsten,
wenn der Fensterkontakt defekt ist wird er doch weggeworfen, oder? Also musst du nur den TC bearbeiten. Der muss aber nicht "unpaired" werden, der soll doch bleiben.
Es muss also nur der peer in TC_winrec eliminiert werden. Dein Kommando war korrekt, was hat nicht funktioniert? Wichtig ist, dass der Fensterkontakt noch die orginal-HMid hat, also noch nicht der neue ist.
Ansonsten
set <tc_winrec> peerBulk <hmid2detele> unset
Gruss Martin
Woran erkenne ich denn, ob es funktioniert hat? Ich habe noch den peerBulk Befehl ausgeführt, keine Fehlermeldung, aber was jetzt?
--
Auf der Seite des thermostat_kueche_windowrec steht unter Readings:
peerIDs 00000000
--
Auf der Seite des threestatesensor_kueche_fenster_links steht
unter Attr:
peerIDs 00000000,1CE12303,
und unter Readings:
peerList thermostat_kueche_windowrec,
--
Zum Vergleich: threestatesensor_kueche_fenster_rechts hat die gleichen Werte. Es hat sich also irgendwie nichts verändert.
ZitatWoran erkenne ich denn, ob es funktioniert hat?
die wahrheit kommt IMMER mit getConfig. wenn dann kein peer im tcwinrec steht ist da auch keiner.
peerBulk musst du getrennt für tcwinrec und fenster durchführen. hast du
set thermostat_kueche_windowrec peerBulk <threestatesensor_kueche_fenster_links-hmid>
gemacht?
gruss Martin
Zitatset thermostat_kueche_windowrec peerBulk <threestatesensor_kueche_fenster_links-hmid>
gemacht?
Habe ich gemacht, wenn hmid die Zeichenkette neben "Def" ist.
Bringt peerBulk für den kaputten Fensterkontakt etwas? Der reagiert ja nicht mehr auf gepufferte Befehle (getconfig, Anlernen drücken usw.). Ich würde das entsprechende fhem Objekt "threestatesensor_kueche_fenster_links" jetzt einfach löschen. Dann den neuen Kontakt anlernen umbenennen in "threestatesensor_kueche_fenster_links" und peeren.
rename CUL_HM_HM_SEC_SC_1D0059 threestatesensor_kueche_fenster_links
set thermostat_kueche_climate peerChan 0 hm_cc_vd_kueche_links single set
set threestatesensor_kueche_fenster_links peerChan 0 thermostat_kueche_windowrec single set
So richtig?
Komisch ist nur, dass auf der Seite des thermostat_kueche_windowrec unter Readings steht:
peerIDs 00000000
Da sollte doch eigentlich der Fensterkontakt "rechts" stehen (der noch funktioniert), oder? Den habe ich wie oben beschrieben gepeert. Im Gerät sehe ich den Fensterkontakt auch, nur nicht in den peerIDs des windowsrec. Sollte ich das nochmal machen (peerbulk unset)?
Was ist eigentlich besser "peerBulk" oder "peerChan"?
Ich habe die ganze Küche nochmal zurückgesetzt (reset). Dann habe ich Fensterkontakt und VD gepairt (waitforsec und anlerntaste). Jetzt steht da:
PairedTo
invalid
2013-09-16 23:20:30
R-pairCentral
0xDE7474
2013-09-16 23:20:30
Sind VD und Fensterkontakt jetzt gepairt mit fhem oder nicht??? Ich verzweifele langsam.
EDIT:
Nach einem update development und shutdown restart ist das invalid weg, und die Zentrale steht da.
hi,
sicher ist(ganz im Detail):
- nach einem getConfig stehen alle gepeerten IDs in peerIDs. Im Klartext auch in peerList.
- getConfig muss fehlerfrei durchgelaufen sein, klar.
peerChan ist das ältere Kommando mit mehr komfort. es werden aktor und sensor mit einem kommando geschrieben. option single und dual sind möglich, was unterschiedliche setups im aktor auslöst
peerbulk setzt mehrere peers in einem channel. Es ist gedacht zum Recovery zusammen mit regBulk
Am ende sollten also immer die peers im peerList stehen!
Gruss Martin
Jetzt habe ich das Wohnzimmer auch kontrolliert. Die Fensterkontakte hatten alle einen winrec, aber dem winrec fehlte ein Fensterkontakt. Das ließ sich weder mit peerChan noch mit regBulk beheben, irgendwas ist da durcheinandergelaufen.
Also alle VDs, Fensterkontakte und TCs zurückgesetzt mittels "reset". Ging teilweise nicht über die Anlerntaste, aber immer über fhem.
Dann alles wieder gepairt, mit anschließendem getconfig.
Dann mittels peerChan die TC-Fensterkontakt und TC-VD Verknüpfungen (peering) erstellt.
Dann wieder auf alles ein getconfig.
War ein ganz schönes Gerenne, hat schlussendlich aber ohne Fehler funktioniert. Jetzt bin ich mal gespannt, wie lange das hält. Im letzten Winter hatte ich das schon einmal gemacht, dann fingen die TCs irgendwann an zu piepen (Störungen der VDs und Fensterkontakten) und die peers verschwanden (irgendwann, erst die Tage bemerkt).
Danke Martin :)
hm...
also die prozedur funktioniert im Prinzip. Aber dein TC war in einem zustand, in dem er kein peering zuließ.....
den zustand hatte ich noch nicht...
zu deinem gerenne - wenn du es optimieren willst kannst du
alle peerings abschicken (alle!)
bei allen ein getConfig schicken(ausnahme: autoreadreg ist gesetzt)
rundgang, anlernen bei fensterkontakt und evtl vd.
die tcs werden automatisch nach 3min bearbeitet, kein anlernen notwendig
da fhem die kommandos queued ist dies kein Problem.
zum Schluss prüfen, ob etwas schief gegangen ist. hier bietet sich hminfo an:
zu beginn ein
set hm clear Protocol
##jetzt die messages wie oben
set hm protoEvents #kontrolle auf fehler
set hm peerXref # übersicht, ob alles gepeert ist wie gewünscht
set hm configCheck # mal eine übersicht erstellen
aufgetretene Fehler untersuchen
Gruss Martin
Jetzt piept es hin und wieder mal. Alles sieht aber richtig gepeert aus, in beiden Kommunikationspartnern steht jeweils immer noch der andere in der peerlist.
Komisch dabei: ich hatte vorher immer erst die SCs an die TCs angelernt (ohne fhem) und ganz zum Schluss den TC/SC an fhem. Da hat nie etwas gepiept. Ich hatte den anderen Weg (erst alles an fhem pairen und dann peeren) ausprobiert, weil hin und wieder die Heizung anging, obwohl das Fenster offen war. Ausserdem fand ich das peeren über die fhem Zentrale logischer.
In Schlafzimmer und Kinderzimmer ist noch alles mit der ersten Methode angelernt: Kein Piepen.
In Wohnzimmer und Küche über fhem angelernt und gepeert: Piepen.
Batterien habe ich schon überall getauscht, auch wenn die alten eigentlich noch voll sein müssten und auch keine Batteriewarnung anstand oder angezeigt wurde.
das piepen kenne ich, habe ich irnogiert,da der TC ausschliesslich zum Testen ist - und meist nicht komplett konfiguriert.
das piepen kommt immer zur vollen Stunde - korrekt?
ich dachte immer, es kommt da mein VD nicht korrekt reagiert (war keine Batterie drin).
kannst du einmal ein statusRequest machen und die rohmessages dazu schicken?
was ist im Display zu sehen.
Gruss Martin
Mist, jetzt habe ich gerade die Fenster alle mal aufgemacht. Dann verschwindet das Piepen (ja, zur vollen Stunde) und das blinkende Funksymbol. Wenn es wieder auftritt sammel ich die Rohdaten ein.
das Piepen hatte ich noch nie.
das piepen scheint einen Alarm zu signalisieren (was sonst)
es könnte ein fehlen eines peers sein. beim VD verstehe ich den machanismus. Bein SC ist mir unklar, wie oft der TC diesen sehen will - einmal am Tag?
Jetzt piept's wieder. Im Statusdisplay sieht man ein blinkendes Funksymbol und ein "S". Bedeutet laut Doku Kommunikationsproblem mit einem Fensterkontakt. Wenn ich am TC allerdings in die Konfiguration gehe und die Fensterkontakte durchlaufe, dann blinkt bei keinem das Funksymbol. Normalerweise sollte bei dem Verursacher das Symbol ebenfalls blinken.
Hier der Auszug nach einem statusRequest:
2013.10.02 18:07:13.630 1: HMLAN_Send: HMLAN1 I:K
2013.10.02 18:07:13.633 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:IEQ0061959 d:139779 O:DE7474 t:182DB978 IDcnt:000B
2013.10.02 18:07:36.928 1: HMLAN_Send: HMLAN1 S:S79ECB221 stat: 00 t:00000000 d:01 r:79ECB221 m:1A B112 DE7474 1BF932
2013.10.02 18:07:37.443 1: HMLAN_Parse: HMLAN1 R:R79ECB221 stat:0001 t:182E167C d:FF r:FFC0 m:1A 8002 1BF932 DE7474 00
2013.10.02 18:07:37.444 1: HMLAN_Send: HMLAN1 S:+1BF932,00,01,
2013.10.02 18:07:37.444 1: HMLAN_Send: HMLAN1 S:S79ECB425 stat: 00 t:00000000 d:01 r:79ECB425 m:1B A001 DE7474 1BF932 010E
2013.10.02 18:07:37.853 1: HMLAN_Parse: HMLAN1 R:R79ECB425 stat:0001 t:182E1816 d:FF r:FFC0 m:1B 8002 1BF932 DE7474 01020B0045
2013.10.02 18:07:37.854 1: HMLAN_Send: HMLAN1 S:+1BF932,00,01,
2013.10.02 18:07:37.854 1: HMLAN_Send: HMLAN1 S:S79ECB5BF stat: 00 t:00000000 d:01 r:79ECB5BF m:1C A001 DE7474 1BF932 020E
2013.10.02 18:07:38.262 1: HMLAN_Parse: HMLAN1 R:R79ECB5BF stat:0001 t:182E19B0 d:FF r:FFBE m:1C 8002 1BF932 DE7474 01020B0045
2013.10.02 18:07:38.264 1: HMLAN_Send: HMLAN1 S:+1BF932,00,01,
2013.10.02 18:07:38.264 1: HMLAN_Send: HMLAN1 S:S79ECB759 stat: 00 t:00000000 d:01 r:79ECB759 m:1D A001 DE7474 1BF932 030E
2013.10.02 18:07:38.632 1: HMLAN_Send: HMLAN1 I:K
2013.10.02 18:07:38.635 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:IEQ0061959 d:139779 O:DE7474 t:182E1B25 IDcnt:000B
2013.10.02 18:07:38.681 1: HMLAN_Parse: HMLAN1 R:R79ECB759 stat:0001 t:182E1B4A d:FF r:FFBB m:1D 8002 1BF932 DE7474 01020B0049
Was mir noch aufgefallen ist: der actiondetector zeigt alle meine Fensterkontakte (zumindest die im Wohnzimmer) plötzlich als "dead" an:
state alive:14 dead:4 unkn:0 off:0
2013-10-02 18:06:36 status_hm_cc_vd_kueche_links alive
2013-10-02 18:06:36 status_hm_cc_vd_kueche_rechts alive
2013-10-02 18:06:36 status_hm_cc_vd_lilith alive
2013-10-02 18:06:36 status_hm_cc_vd_schlafzimmer alive
2013-10-02 18:06:36 status_hm_cc_vd_wohnzimmer_fenster_mitte alive
2013-10-02 18:06:36 status_hm_cc_vd_wohnzimmer_fenster_schrank alive
2013-10-02 18:06:36 status_hm_cc_vd_wohnzimmer_fenster_terasse alive
2013-10-02 18:06:36 status_thermostat_kinderzimmer_lilith alive
2013-10-02 18:06:36 status_thermostat_kueche alive
2013-10-02 18:06:36 status_thermostat_schlafzimmer alive
2013-10-02 18:06:36 status_thermostat_wohnzimmer alive
2013-10-02 18:06:36 status_threestatesensor_kueche_fenster_links dead
2013-10-02 18:06:36 status_threestatesensor_kueche_fenster_rechts alive
2013-10-02 18:06:36 status_threestatesensor_schlafzimmer_fenster_velux_gross alive
2013-10-02 18:06:36 status_threestatesensor_test alive
2013-10-02 18:06:36 status_threestatesensor_wohnzimmer_fenster_mitte dead
2013-10-02 18:06:36 status_threestatesensor_wohnzimmer_fenster_schrank dead
2013-10-02 18:06:36 status_threestatesensor_wohnzimmer_fenster_terasse dead
Das passiert nur bei den TCs, die ich über fhem gepeert habe. Peere ich per TC und paire den TC anschliessend mit fhem, piepts nicht.
schau einmal den SC an.
ist dort cyclicInfoMsg auf on?
der action-detector will alle 24h (28h als puffer) eine nachricht den SC sehen. Wenn du das Fenster jeden Tag auf machst ist dies ok ansonsten musst du sicherstellen, dass das device selbständig sendet, dafür das Register.
du kannst im SC "protLastRcv" nachsehen, wann das letzte mal etwas vom SC gesehen wurde. Ist dies älter also 28h (24h plus puffer) sollte das Device auf dead gehen.
Ansonsten hat der ActionDetector einen bug, dann bitte die Daten senden.
Der TC wird ähnlich arbeiten - evtl ignoriert er sogar die Fenster-auf messages und will nur die Statusmessages.
Gruss Martin
Ich kann gar kein cyclicInfoMsg finden.
protLastRcv steht auf "2013-09-30 11:23:20".
Wie stelle ich das cyclicInfoMsg ein? In der Weboberfläche sehe ich keine Möglichkeit dazu.
EDIT: nach einem getconfig sehe ich:
R-cyclicInfoMsg off
Aber wie auf on setzen?
EDIT: So?
Link (http://forum.fhem.de/index.php?topic=11563.msg68193#msg68193)
Hi Thorsten,
genau. das ist ein "register", wird also IM device gesetzt. in Readings sind register mit dem prefix "R-" versehen und werden mit regSet gesetzt.
set Fenster_WC regSet cyclicInfoMsg on
beim Fensterkontakt musst du dann anlernen drücken. also am besten gleich ein getConfig hinterher und dann anlernen. Dann musst du nur einmal gehen. (es sein den du hast attr autoReadReg gesetzt, dann geht es automatisch)
Übrigens: wenn die cyclicInfo an ist werden kommandos automatisch übertragen - einmal am Tag, ohne Anlernen.
Gruss Martin
Ich habe im Wohnzimmer die SCs entsprechend verarztet. Aber in der Küche will es nicht klappen. Ich habe schon ein update und einen Neustart von fhem ausprobiert, aber keine Chance.
Nachdem ich den SC geöffnet habe, steht da "cmds processing" und bleibt so stehen. Ein nachgeschobenes getConfig und AnlernButtonDrücken hat nichts geändert, ausser dass jetzt mehr CMDs in der Warteschlange stehen.
Auszug aus dem Log nach Neustart und Versuch eines getConfig:
2013.10.03 13:14:56.297 0: Server started with 104 defined entities (version $Id: fhem.pl 3872 2013-09-07 11:58:33Z rudolfkoenig $, os linux, user root, pid 21489)
2013.10.03 13:14:56.298 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:IEQ0061959 d:139779 O:DE7474 t:1C48A17F IDcnt:000B
2013.10.03 13:15:00.253 1: HMLAN_Parse: HMLAN1 R:E1CE123 stat:0000 t:1C48B24F d:FF r:FFC0 m:59 A258 1CE123 1CF1E3 0000
2013.10.03 13:15:00.388 1: HMLAN_Parse: HMLAN1 R:E1CF1E3 stat:0000 t:1C48B2D4 d:FF r:FFBB m:59 8202 1CF1E3 1CE123 010100002E
2013.10.03 13:15:03.213 1: HMLAN_Parse: HMLAN1 R:E1BF932 stat:0000 t:1C48BDDF d:FF r:FFBD m:94 8670 1BF932 000000 00DD33
2013.10.03 13:15:20.945 1: HMLAN_Send: HMLAN1 I:K
2013.10.03 13:15:20.948 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:IEQ0061959 d:139779 O:DE7474 t:1C49032E IDcnt:000B
2013.10.03 13:15:23.213 1: HMLAN_Parse: HMLAN1 R:E1BF932 stat:0000 t:1C490C02 d:FF r:FFBC m:94 A258 1BF932 1BFC15 0000
2013.10.03 13:15:23.347 1: HMLAN_Parse: HMLAN1 R:E1BFC15 stat:0000 t:1C490C86 d:FF r:FFBF m:94 8202 1BFC15 1BF932 010100002D
2013.10.03 13:15:33.287 1: HMLAN_Parse: HMLAN1 R:E1E7E14 stat:0000 t:1C49335D d:FF r:FFC0 m:EC 8400 1E7E14 000000 20002F4A45513037313939323280810101
2013.10.03 13:15:33.288 1: HMLAN_Send: HMLAN1 I:+1E7E14,00,00,
2013.10.03 13:15:33.288 1: HMLAN_Send: HMLAN1 S:S7E07AA69 stat: 00 t:00000000 d:01 r:7E07AA69 m:01 A001 DE7474 1E7E14 00040000000000
2013.10.03 13:15:34.095 1: HMLAN_Parse: HMLAN1 R:R7E07AA69 stat:0408 t:00000000 d:FF r:7FFF m:01 A001 DE7474 1E7E14 00040000000000
2013.10.03 13:15:34.095 1: HMLAN_Parse: HMLAN1 new condition ERROR-Overload
2013.10.03 13:15:34.101 1: HMLAN_Parse: HMLAN1 no ACK from 1E7E14
2013.10.03 13:15:45.947 1: HMLAN_Send: HMLAN1 I:K
2013.10.03 13:15:45.950 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:IEQ0061959 d:139779 O:DE7474 t:1C4964DC IDcnt:000B
2013.10.03 13:16:01.770 1: HMLAN_Parse: HMLAN1 R:E1CDFBA stat:0000 t:1C49A2A5 d:FF r:FFD2 m:0F 8670 1CDFBA 000000 00A833
2013.10.03 13:16:10.957 1: HMLAN_Send: HMLAN1 I:K
EDIT:
Im WebInterface steht jetzt:
Fensterkontakt Kueche Links MISSING ACK
Fensterkontakt Kueche Rechts RESPONSE TIMEOUT:RegisterRead
Die Overload Nachricht ist seit heute neu. Soviel Verkehr verursache ich doch gar nicht...?!? Oder hängt das mit dem cyclic Messages zusammen? Ich hoffe, da wird wirklich nur einmal am Tag etwas gesendet...
EDIT:
Jetzt kam ein "overload release", da dachte ich, mach mal ein getConfig, vielleicht klappt es wieder:
2013.10.03 13:21:34.105 1: HMLAN_Parse: HMLAN1 new condition Overload-released
2013.10.03 13:21:36.096 1: HMLAN_Send: HMLAN1 I:K
2013.10.03 13:21:36.099 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:IEQ0061959 d:139779 O:DE7474 t:1C4EBCD3 IDcnt:000B
2013.10.03 13:21:46.017 1: HMLAN_Parse: HMLAN1 R:E1CE123 stat:0000 t:1C4EE38D d:FF r:FFBF m:5C A258 1CE123 1C494E 0000
2013.10.03 13:21:46.152 1: HMLAN_Parse: HMLAN1 R:E1C494E stat:0000 t:1C4EE411 d:FF r:FFBA m:5C 8202 1C494E 1CE123 0101000032
2013.10.03 13:22:01.103 1: HMLAN_Send: HMLAN1 I:K
2013.10.03 13:22:01.106 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:IEQ0061959 d:139779 O:DE7474 t:1C4F1E85 IDcnt:000B
2013.10.03 13:22:26.106 1: HMLAN_Send: HMLAN1 I:K
2013.10.03 13:22:26.109 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:IEQ0061959 d:139779 O:DE7474 t:1C4F8034 IDcnt:000B
2013.10.03 13:22:30.644 1: HMLAN_Parse: HMLAN1 R:E1CE75F stat:0000 t:1C4F91E6 d:FF r:FFC5 m:48 A258 1CE75F 1CED2A 0000
2013.10.03 13:22:30.777 1: HMLAN_Parse: HMLAN1 R:E1CED2A stat:0000 t:1C4F9269 d:FF r:FFC0 m:48 8202 1CED2A 1CE75F 010100003D
2013.10.03 13:22:51.110 1: HMLAN_Send: HMLAN1 I:K
2013.10.03 13:22:51.113 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:IEQ0061959 d:139779 O:DE7474 t:1C4FE1E3 IDcnt:000B
2013.10.03 13:23:03.785 1: HMLAN_Parse: HMLAN1 R:E1CDFBA stat:0000 t:1C501360 d:FF r:FFD2 m:12 8670 1CDFBA 000000 00A833
2013.10.03 13:23:16.123 1: HMLAN_Send: HMLAN1 I:K
2013.10.03 13:23:16.126 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:IEQ0061959 d:139779 O:DE7474 t:1C50439C IDcnt:000B
2013.10.03 13:23:23.785 1: HMLAN_Parse: HMLAN1 R:E1CDFBA stat:0000 t:1C506183 d:FF r:FFD2 m:12 A258 1CDFBA 1CF1FC 0200
2013.10.03 13:23:23.919 1: HMLAN_Parse: HMLAN1 R:E1CF1FC stat:0000 t:1C506206 d:FF r:FFBF m:12 8202 1CF1FC 1CDFBA 0101000037
2013.10.03 13:23:28.483 1: HMLAN_Parse: HMLAN1 R:E1BF932 stat:0000 t:1C5073DD d:FF r:FFBC m:97 8670 1BF932 000000 00DC33
2013.10.03 13:23:41.125 1: HMLAN_Send: HMLAN1 I:K
2013.10.03 13:23:41.128 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:IEQ0061959 d:139779 O:DE7474 t:1C50A549 IDcnt:000B
2013.10.03 13:23:48.483 1: HMLAN_Parse: HMLAN1 R:E1BF932 stat:0000 t:1C50C200 d:FF r:FFBC m:97 A258 1BF932 1BFC15 0000
2013.10.03 13:23:48.617 1: HMLAN_Parse: HMLAN1 R:E1BFC15 stat:0000 t:1C50C284 d:FF r:FFC0 m:97 8202 1BFC15 1BF932 010100002C
2013.10.03 13:24:06.138 1: HMLAN_Send: HMLAN1 I:K
2013.10.03 13:24:06.141 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:IEQ0061959 d:139779 O:DE7474 t:1C510702 IDcnt:000B
2013.10.03 13:24:16.524 1: HMLAN_Parse: HMLAN1 R:E1CE123 stat:0000 t:1C512F8D d:FF r:FFBF m:5D 8670 1CE123 000000 00D237
2013.10.03 13:24:25.399 1: HMLAN_Parse: HMLAN1 R:E1CE75F stat:0000 t:1C515239 d:FF r:FFC5 m:49 8670 1CE75F 000000 00B034
2013.10.03 13:24:31.145 1: HMLAN_Send: HMLAN1 I:K
2013.10.03 13:24:31.148 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:IEQ0061959 d:139779 O:DE7474 t:1C5168B5 IDcnt:000B
2013.10.03 13:24:36.524 1: HMLAN_Parse: HMLAN1 R:E1CE123 stat:0000 t:1C517DB0 d:FF r:FFBF m:5D A258 1CE123 1CF1E3 0000
2013.10.03 13:24:36.658 1: HMLAN_Parse: HMLAN1 R:E1CF1E3 stat:0000 t:1C517E34 d:FF r:FFBA m:5D 8202 1CF1E3 1CE123 010100002E
2013.10.03 13:24:45.399 1: HMLAN_Parse: HMLAN1 R:E1CE75F stat:0000 t:1C51A05C d:FF r:FFC5 m:49 A258 1CE75F 1CED2A 0000
2013.10.03 13:24:45.531 1: HMLAN_Parse: HMLAN1 R:E1CED2A stat:0000 t:1C51A0DE d:FF r:FFC1 m:49 8202 1CED2A 1CE75F 010100003D
2013.10.03 13:24:56.147 1: HMLAN_Send: HMLAN1 I:K
2013.10.03 13:24:56.150 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:IEQ0061959 d:139779 O:DE7474 t:1C51CA62 IDcnt:000B
2013.10.03 13:25:21.172 1: HMLAN_Send: HMLAN1 I:K
2013.10.03 13:25:21.175 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:IEQ0061959 d:139779 O:DE7474 t:1C522C27 IDcnt:000B
2013.10.03 13:25:46.186 1: HMLAN_Send: HMLAN1 I:K
2013.10.03 13:25:46.189 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:IEQ0061959 d:139779 O:DE7474 t:1C528DE0 IDcnt:000B
2013.10.03 13:25:59.541 1: HMLAN_Parse: HMLAN1 R:E1CDFBA stat:0000 t:1C52C205 d:FF r:FFD2 m:13 8670 1CDFBA 000000 00A933
2013.10.03 13:26:07.988 1: HMLAN_Parse: HMLAN1 R:E1BF932 stat:0000 t:1C52E305 d:FF r:FFBC m:98 A258 1BF932 1C4DD3 0000
2013.10.03 13:26:08.120 1: HMLAN_Parse: HMLAN1 R:E1C4DD3 stat:0000 t:1C52E387 d:FF r:FFBE m:98 8202 1C4DD3 1BF932 0101000033
2013.10.03 13:26:11.191 1: HMLAN_Send: HMLAN1 I:K
2013.10.03 13:26:11.194 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:IEQ0061959 d:139779 O:DE7474 t:1C52EF91 IDcnt:000B
2013.10.03 13:26:13.868 1: HMLAN_Parse: HMLAN1 R:E1E7E14 stat:0000 t:1C52F9FD d:FF r:FFBE m:ED 8400 1E7E14 000000 20002F4A45513037313939323280810101
2013.10.03 13:26:13.964 1: HMLAN_Send: HMLAN1 S:S7E1170AD stat: 00 t:00000000 d:01 r:7E1170AD m:02 A001 DE7474 1E7E14 00040000000000
2013.10.03 13:26:14.567 1: HMLAN_Parse: HMLAN1 R:R7E1170AD stat:0408 t:00000000 d:FF r:7FFF m:02 A001 DE7474 1E7E14 00040000000000
2013.10.03 13:26:14.567 1: HMLAN_Parse: HMLAN1 new condition ERROR-Overload
2013.10.03 13:26:14.573 1: HMLAN_Parse: HMLAN1 no ACK from 1E7E14
Schon kam das nächste Overload. So schnell?
EDIT:
Ich habe jetzt ein paar Minuten länger gewartet und dann ein getConfig gemacht. Hat funktioniert. Vorsichtshalber das ganze nochmal, also regSet, Anlerntaste, getconfig, Anlerntaste. Ging gut. Allerdings steht im WebInterface jetzt:
R-cyclicInfoMsg set_on
anstelle von (wie bei den SCs im Wohnzimmer):
R-cyclicInfoMsg on
Was heisst das jetzt?
EDIT:
Ich habe versucht, cyclicInfoMsg wieder auf off zu stellen, bleibt aber alles auf set_on, auch nach getConfig:
set threestatesensor_kueche_fenster_rechts regSet cyclicInfoMsg off
Hallo Thorsten,
wenn du einen Ovlerload hast braucht HMLAN min 6 min um wieder kommandos zu akzeptieren.
Alternative: einmal strom ziehen/stecken.
ein FHEM-restart nutzt nichts, liegt am HMLAN
wenn commands processing sind nutzt ein neues nachsenden eines kommandos nichts. Du kannst es stoppen mit
set <device> clear msgEvents
versuche noch einmal das register zu setzen, wenn alles i.O. ist, also insbesondere der HMLAN
Gruss Martin
Ich habe gerade noch einen Versuch gestartet.
set threestatesensor_kueche_fenster_links clear msgEvents
set threestatesensor_kueche_fenster_links clear readings
set threestatesensor_kueche_fenster_links regSet cyclicInfoMsg on
<AnlernTaste>
set threestatesensor_kueche_fenster_links getConfig
<AnlernTaste>
Die CMD liefen ohne Fehler durch, aber: kein cyclicInfoMsg zu sehen. Weder on noch off, einfach keines da.
hi thorsten,
die info-message des SC kommt nur einmal am tag. da musst du lange warten, klar.
Dass das register sauber gesetzt ist hast du geprüft.
bei meinem test-TC hatte ich auch das piepsen, da ich immer hin und her peeren (ist ja nur zum testen). das "S" in der anzeige war auch da. ich habe den simulierten fensterkontakt gelöscht - keine aenderung. dann habe ich die Batterie rausgekommen und wieder engelegt - das "S" ist weg, der TC ist glücklich.
wenn ich nichts übersehen habe ist es einfach ein bug im TC - der hat die aenderung nicht eingearbeitet.
Gruss Martin
Man kann im webinterface immer noch kein R-cyclicInfoMsg sehen. Allerdings habe ich folgendes per telnet abgesetzt:
get threestatesensor_kueche_fenster_rechts reg cyclicInfoMsg
Da kommt ein "on" zurück.
Ein Bug im WebInterface? Ich werde mal eines der Fenster 28h zulassen und sehen, ob es wieder auf dead gesetzt wird.
das ist seltsam, wenn es nicht zu sehen ist. kann ich mir nicht erklären. Sollte so nicht sein, besonders wenn es auch mit "get" angezeigt wird...
hast du expert einmal auf '1' gesetzt?
Wo stelle ich das ein? Hab's irgendwo mal gesehen, kann mich aber nicht erinnern.
attr <dev> expert 1
Die SCs stehen schon auf
expert 2_full
genauso wie die SCs aus dem Wohnzimmer, wo cyclicInfoMsg ganz normal angezeigt wird.
es war einmal ein bug drin, der die List0 nicht korrekt interpretiert hat. Also bitte
- update machen (ich weiss nicht welche Version du hast)
- noch einmal getConfig machen
wenn es immer noch nicht drin steht die roh-register schicken
version $Id: fhem.pl 3872 2013-09-07 11:58:33Z rudolfkoenig $
steht zumindest so im log, letzter neustart.
Ein update habe ich schon angestossen, heute nachmittag versuche ich nochmal ein getconfig. Kannst du mir schon mal sagen, wie ich rohregister abrufe?
die rohdaten aus denen die 'lesbaren' erzeugt werden sind in den readings
RegL_...
die lesbaren sind in
R-...
die Version von 10_CUL_HM erhältst du mit
"version"
die RegL sind normal als nicht sichtbar geschaltet. sichtbar bekommst du es entweder je device mit
attr expert 2
(wenn im device gesetzt ist es auch default für channels)
oder für ALLES in FHEM mit
attr global showInternalValues 1
Gruss Martin
Hallo Martin,
ich habe endlich wieder etwas Zeit gehabt. Ich habe jetzt einfach mal die fhem.save gelöscht und fhem neu gestartet. Dann waren die R-cyclicInfoMsg nach einem getconfig zu sehen.
Danke für die Hilfe :)
Thorsten