Hallo zusammen,
ich habe insgesamt 5 ActionDetectoren im Einsatz, einen Bewegungsmelder, einen Drehgriffkontakt und drei optische Fenster/Tür-Sensoren. Alle fünf sind dem device ActionDetector zugeordnet, der ActionDetector hat das attr Event-on-Change-reading .* soweit so gut.
Bei keinem der Sensoren ist dieses attr selbst eingetragen. bei dem Drehgriffkontakt und bei dem optischen haustürsensor läuft ein notify, der mir eine Pushnachricht schickt, wenn der Zustand Haustuer:open .* eintritt. Bei diesem optischen Sensor kommt die Nachricht 2-4 mal wenn die Haustür aufbleibt. Die Haustür kann das ruhig weiter aufbleiben, es kommen keine neuen Nachrichten.
Der notify auf dem Drehgriffkontakt läuft auf Terrassentuer:open.* Hier kommt dann die Pushnachricht genau einmal, egal wie lange die Terrassentür auf ist.
Reagieren die beiden Typen von Sensoren unterschiedlich? Wie gesagt, bei keinem der Sensoren ist das attr event-on-Change-reading .* selbst gesetzt.
entweder du hast etwas missverstanden oder ich verstehe deine aussage nicht. das device actiondetector ist nicht für die events der devices zuständig. der meldet sich nur, wenn ein device in festgelegter zeit nichts mehr meldet.
Du hast Recht, das event-on-changing-reading beim ActionDetectoer überwacht nur die zugeordneten Sensoren, so weit dachte ich das auch.
Ich habe probeweise einen gleichen notify bei einem weiteren optischen Sensor eingebaut. Auch hier wird 4 mal die Nachricht gesendet. Danach ist Ruhe, egal wie lange die Tür aufbleibt.
Trotzdem bleibt dann die Frage offen, warum bei dem einen Sensor der notify 2-4 mal ausgelöst wird und bei dem anderen nur einmal. Einen Eintrag in Form von event-on... irgendwas steht bei keinem Sensor drin. Oder sind die nur in internen Registern sichtbar und ich müsste zunächst die internen Readings sichtbar machen wie auch die internen Peers von Schaltaktoren erst sichtbar gemacht werden müssen?
Ein attr Eintrag mit event-on... bei einem der optischen Sensoren führt natürlich dazu, dass der notify nur einmal ausgelöst wird.
Irgendeinen Grund muss es doch für das unterschiedliche Verhalten geben.
Kann jemand dies Verhalten bei sich nachvollziehen?
nicht nur "überfliegen", sondern "aufmerksam" lesen und wenigstens versuchen zu verstehen.
Zitatdas event-on-changing-reading beim ActionDetectoer überwacht nur die zugeordneten Sensoren,
falsch, denn
Zitatdas device actiondetector ist nicht für die events der devices zuständig.
ZitatAuch hier wird 4 mal die Nachricht gesendet.
schau im eventmonitor dort siehst du sämtliche events. was du dann damit in deinen notifys tust, weist nur du.
Im eventmonitor steht viermal das open drin, komischerweise aber viermal mit derselben count-Nr. deshalb wird auch viermal der notify ausgelöst.
der sensor kann doch nicht "prellen" wie ein mechanischer Schalter. anbei auch der Auszug vom Event-Monitor mit den entsprechenden Einträgen aus mehr oder weniger 1-2 sec.
dann sniffe mal die raw-messages => wiki: homematic sniffen.
ist dein fhem aktuell?
Meine fhem.pl ist die 9002 vom 29.07.2015
Das sniffen mache ich dann sobald ich das wiki dazu gelesen habe.
Um sicher zu gehen, die LogID ist die hexadezimale ID der bei mir zwei HMLan? also z.B. AAAAAA wenn diese ID bei der VCCU, HMLan1 und HMLan2 eingetragen sind, oder?
ZitatMeine fhem.pl ist die 9002 vom 29.07.2015
entscheidend für hm sind 10_cul_hm.pm, 00_hmlan.pm, hmconfig.pm. das sollte aber wohl ok sein.
Zitatdie LogID ist die hexadezimale ID
vom device. oder der devicename. kommagetrennte liste aller devices, die du loggen willst.
So, hier der Logfile mit den gesnifften Daten. Um diese zu erzeugen habe bei meinen beiden HMLan (HMlan1 und HMLan2, beide AAAAAA als ID) das LogIDs gesetzt auf das device Tuer_Terrasse mit dem Zusatz all,sys.
logfile siehe zwei Beiträge weiter, dann in code tag
3BC00F ist die Nummer des Tür/Fenster-Kontaktes. Diese Nummer steht unter DEF im device drin. Ich kann mit diesen Zahlenreihen natürlich noch gar nix anfangen.
Die Meldung über die geöffnete Tür kam zweimal.
Zitatbei meinen beiden HMLan
und du nutzt keine vccu? wenn nicht, gleich eine definieren.
hast du ausserdem noch einen repeater?
es wäre sehr augenfreundlich, die logzeilen im post mit code tags einzuschliessen.
Mit codetag habe ich es nicht so geschafft, weil ich den Eventmonitor auf einem Tablet laufen gelassen habe und den Text hier über ein Handy eingetragen habe.
Ja ich habe eine VCCU definiert und alle device sind mit der VCCU gepairt, kein device ist mit einen der beiden HMLAN gepairt. Bei allen device ist die IOGrp:VCCU gepflegt, keine HMLan direkt. Habe mich schön an die Empfehlung im Wiki gehalten und umgesetzt.
Beide HMLAN tragen dieselbe ID wie auch die VCCU (AAAAAA). Die optischen Sensoren Haustuer, Fenster_Fitness, Tuer_Terrasse sind mit dem VCCU_Btn4 gepeert. Mitgesnifft hatte ich bei beiden HMLan jeweils den Tuer_Terrasse Kontakt.
2015.08.06 20:24:13.671 0: HMLAN_Send: HMLAN1 I:K
2015.08.06 20:24:13.676 0: HMLAN_Parse: HMLAN1 V:03C4 sNo:KEQ1024189 d:23D58D O:AAAAAA t:16FB504E IDcnt:000B L:2 %
2015.08.06 20:24:38.687 0: HMLAN_Send: HMLAN1 I:K
2015.08.06 20:24:38.757 0: HMLAN_Parse: HMLAN1 V:03C4 sNo:KEQ1024189 d:23D58D O:AAAAAA t:16FBB209 IDcnt:000B L:2 %
2015.08.06 20:25:03.688 0: HMLAN_Send: HMLAN1 I:K
2015.08.06 20:25:03.693 0: HMLAN_Parse: HMLAN1 V:03C4 sNo:KEQ1024189 d:23D58D O:AAAAAA t:16FC13B7 IDcnt:000B L:2 %
2015.08.06 20:25:28.691 0: HMLAN_Send: HMLAN1 I:K
2015.08.06 20:25:28.695 0: HMLAN_Parse: HMLAN1 V:03C4 sNo:KEQ1024189 d:23D58D O:AAAAAA t:16FC7565 IDcnt:000B L:2 %
2015.08.06 20:25:53.237 0: HMLAN_Send: HMLAN2 I:K
2015.08.06 20:25:53.241 0: HMLAN_Parse: HMLAN2 V:03C4 sNo:LEQ0578979 d:2BACF0 O:AAAAAA t:52DED0ED IDcnt:0003 L:2 %
2015.08.06 20:25:53.693 0: HMLAN_Send: HMLAN1 I:K
2015.08.06 20:25:53.697 0: HMLAN_Parse: HMLAN1 V:03C4 sNo:KEQ1024189 d:23D58D O:AAAAAA t:16FCD713 IDcnt:000B L:2 %
2015.08.06 20:25:54.062 0: HMLAN_Parse: HMLAN1 R:E3BC00F stat:0000 t:16FCD876 d:FF r:FFBE m:A8 A641 3BC00F AAAAAA 019000
2015.08.06 20:25:54.153 0: HMLAN_Send: HMLAN1 S:S044328E3 stat: 00 t:00000000 d:01 r:044328E3 m:A8 8002 AAAAAA 3BC00F 0101C800
2015.08.06 20:25:54.165 0: HMLAN_Parse: HMLAN2 R:E3BC00F stat:0000 t:52DED418 d:FF r:FFBD m:A8 A641 3BC00F AAAAAA 019000
2015.08.06 20:25:54.186 0: HMLAN_Parse: HMLAN2 R:EAAAAAA stat:0000 t:52DED493 d:FF r:FF9E m:A8 8002 AAAAAA 3BC00F 00
2015.08.06 20:25:54.446 0: HMLAN_Parse: HMLAN1 R:R044328E3 stat:0002 t:00000000 d:FF r:7FFF m:A8 8002 AAAAAA 3BC00F 0101C800
2015.08.06 20:25:54.453 0: HMLAN_Parse: HMLAN2 R:EAAAAAA stat:0000 t:52DED59E d:FF r:FF9D m:A8 8002 AAAAAA 3BC00F 0101C800
2015.08.06 20:25:54.624 0: HMLAN_Parse: HMLAN1 R:E3BC00F stat:0000 t:16FCDAA9 d:FF r:FFC2 m:A9 A241 3BC00F AAAAAA 019000
2015.08.06 20:25:54.715 0: HMLAN_Send: HMLAN1 S:S04432B14 stat: 00 t:00000000 d:01 r:04432B14 m:A9 8002 AAAAAA 3BC00F 0101C800
2015.08.06 20:25:54.728 0: HMLAN_Parse: HMLAN2 R:E3BC00F stat:0000 t:52DED64B d:FF r:FFBD m:A9 A241 3BC00F AAAAAA 019000
2015.08.06 20:25:54.748 0: HMLAN_Parse: HMLAN2 R:EAAAAAA stat:0000 t:52DED6C5 d:FF r:FF9E m:A9 8002 AAAAAA 3BC00F 00
2015.08.06 20:25:55.008 0: HMLAN_Parse: HMLAN1 R:R04432B14 stat:0002 t:00000000 d:FF r:7FFF m:A9 8002 AAAAAA 3BC00F 0101C800
2015.08.06 20:25:55.015 0: HMLAN_Parse: HMLAN2 R:EAAAAAA stat:0000 t:52DED7D0 d:FF r:FF9D m:A9 8002 AAAAAA 3BC00F 0101C800
2015.08.06 20:26:00.086 0: HMLAN_Parse: HMLAN1 R:E1676EF stat:0000 t:16FCF000 d:FF r:FFB7 m:AA A441 1676EF AAAAAA 01A700
2015.08.06 20:26:00.100 0: HMLAN_Parse: HMLAN2 R:E1676EF stat:0000 t:52DEEBA1 d:FF r:FFA5 m:AA A441 1676EF AAAAAA 01A700
2015.08.06 20:26:00.210 0: HMLAN_Parse: HMLAN2 R:EAAAAAA stat:0000 t:52DEEC1C d:FF r:FF95 m:AA 8002 AAAAAA 1676EF 00
2015.08.06 20:26:08.156 0: HMLAN_Parse: HMLAN1 R:E3BC00F stat:0000 t:16FD0F87 d:FF r:FFCA m:AA A641 3BC00F AAAAAA 0191C8
2015.08.06 20:26:08.247 0: HMLAN_Send: HMLAN1 S:S04435FF0 stat: 00 t:00000000 d:01 r:04435FF0 m:AA 8002 AAAAAA 3BC00F 0101C800
2015.08.06 20:26:09.068 0: HMLAN_Parse: HMLAN2 R:E3BC00F stat:0000 t:52DF0B28 d:FF r:FFB6 m:AA A641 3BC00F AAAAAA 0191C8
2015.08.06 20:26:09.072 0: HMLAN_Parse: HMLAN2 R:EAAAAAA stat:0000 t:52DF0BA3 d:FF r:FF9D m:AA 8002 AAAAAA 3BC00F 00
2015.08.06 20:26:09.078 0: HMLAN_Parse: HMLAN2 R:EAAAAAA stat:0000 t:52DF0CAE d:FF r:FF9C m:AA 8002 AAAAAA 3BC00F 0101C800
2015.08.06 20:26:09.084 0: HMLAN_Parse: HMLAN2 R:E3BC00F stat:0000 t:52DF0D5D d:FF r:FFB3 m:AB A241 3BC00F AAAAAA 0191C8
2015.08.06 20:26:09.088 0: HMLAN_Send: HMLAN1 I:-3BC00F
2015.08.06 20:26:09.090 0: HMLAN_Send: HMLAN2 I:+3BC00F,00,00,
2015.08.06 20:26:09.091 0: HMLAN_Send: HMLAN2 S:+3BC00F,00,00,00
2015.08.06 20:26:09.091 0: HMLAN_Send: HMLAN2 S:S04436391 stat: 00 t:00000000 d:01 r:04436391 m:AB 8002 AAAAAA 3BC00F 0101C800
2015.08.06 20:26:09.902 0: HMLAN_Parse: HMLAN2 R:EAAAAAA stat:0000 t:52DF0DD7 d:FF r:FF9C m:AB 8002 AAAAAA 3BC00F 00
2015.08.06 20:26:09.908 0: HMLAN_Parse: HMLAN1 R:R04435FF0 stat:0002 t:00000000 d:FF r:7FFF m:AA 8002 AAAAAA 3BC00F 0101C800
2015.08.06 20:26:09.909 0: HMLAN_Parse: HMLAN1 R:E3BC00F stat:0000 t:16FD11BB d:FF r:FFC9 m:AB A241 3BC00F AAAAAA 0191C8
2015.08.06 20:26:09.913 0: HMLAN_Parse: HMLAN1 R:EAAAAAA stat:0000 t:16FD1354 d:FF r:FFA0 m:AB 8002 AAAAAA 3BC00F 0101C800
2015.08.06 20:26:09.918 0: HMLAN_Parse: HMLAN1 R:E1676EF stat:0000 t:16FD1423 d:FF r:FFC2 m:AB A441 1676EF AAAAAA 01A8C8
2015.08.06 20:26:10.761 0: HMLAN_Parse: HMLAN2 R:R04436391 stat:0002 t:00000000 d:FF r:7FFF m:AB 8002 AAAAAA 3BC00F 0101C800
2015.08.06 20:26:10.762 0: HMLAN_Parse: HMLAN2 R:E1676EF stat:0000 t:52DF0FC5 d:FF r:FFA4 m:AB A441 1676EF AAAAAA 01A8C8
2015.08.06 20:26:10.766 0: HMLAN_Parse: HMLAN2 R:EAAAAAA stat:0000 t:52DF103F d:FF r:FF9A m:AB 8002 AAAAAA 1676EF 00
2015.08.06 20:26:18.246 0: HMLAN_Send: HMLAN2 I:K
2015.08.06 20:26:18.250 0: HMLAN_Parse: HMLAN2 V:03C4 sNo:LEQ0578979 d:2BACF0 O:AAAAAA t:52DF32A2 IDcnt:0004 L:2 %
2015.08.06 20:26:18.695 0: HMLAN_Send: HMLAN1 I:K
2015.08.06 20:26:18.699 0: HMLAN_Parse: HMLAN1 V:03C4 sNo:KEQ1024189 d:23D58D O:AAAAAA t:16FD38C2 IDcnt:000A L:1 %
2015.08.06 20:27:02.804 1: PERL WARNING: Use of uninitialized value $aVal in split at ./FHEM/00_HMLAN.pm line 254.
2015.08.06 20:27:08.699 0: HMLAN_Send: HMLAN1 I:K
2015.08.06 20:27:08.703 0: HMLAN_Parse: HMLAN1 V:03C4 sNo:KEQ1024189 d:23D58D O:AAAAAA t:16FDFC1E IDcnt:000A L:1 %
2015.08.06 20:27:17.050 0: HMLAN_Parse: HMLAN1 R:E2F2DB6 stat:0000 t:16FE1CB0 d:FF r:FFC6 m:D7 8410 2F2DB6 AAAAAA 06013E00
2015.08.06 20:27:33.701 0: HMLAN_Send: HMLAN1 I:K
2015.08.06 20:27:33.705 0: HMLAN_Parse: HMLAN1 V:03C4 sNo:KEQ1024189 d:23D58D O:AAAAAA t:16FE5DCC IDcnt:000A L:1 %
Use of uninitialized value in numeric gt (>) at fhem.pl line 798.
Zeig mal bitte ein list von deinem türsensor,
2015.08.06 20:25:54.062 0: HMLAN_Parse: HMLAN1 R:E3BC00F stat:0000 t:16FCD876 d:FF r:FFBE m:A8 A641 3BC00F AAAAAA 019000
2015.08.06 20:25:54.165 0: HMLAN_Parse: HMLAN2 R:E3BC00F stat:0000 t:52DED418 d:FF r:FFBD m:A8 A641 3BC00F AAAAAA 019000
2015.08.06 20:25:54.624 0: HMLAN_Parse: HMLAN1 R:E3BC00F stat:0000 t:16FCDAA9 d:FF r:FFC2 m:A9 A241 3BC00F AAAAAA 019000
2015.08.06 20:25:54.728 0: HMLAN_Parse: HMLAN2 R:E3BC00F stat:0000 t:52DED64B d:FF r:FFBD m:A9 A241 3BC00F AAAAAA 019000
pro ereignis werden 2x2 msgs empangen. je 2 von hmlan1 und hmlan2. ich denke du könntest die anzahl halbieren, wenn du das peering mit dem vccu_button wieder rückgängig machst. hattest du das eingerichtet, weil du es gelesen hast, oder gab es sonst keine rückmeldung? denn es wird auf alles geantwortet. ausserdem solltest du preffered io definieren, und zwar das mit den besseren rssi. das device wird ja fest verbaut sein, denke ich. teste doch mal für das device 3BC00F. dann noch ein event-on-change attr am kontakt und alles sollte passen.
ein list der vccu wäre auch noch interessant.
Hallo,
hier zunächst das list VCCU:
Internals:
DEF AAAAAA
HMLAN1_MSGCNT 684
HMLAN1_RAWMSG EAAAAAA,0000,1BBF0155,FF,FFA8,288002AAAAAA30A6E800
HMLAN1_RSSI -88
HMLAN1_TIME 2015-08-07 18:36:14
HMLAN2_MSGCNT 769
HMLAN2_RAWMSG EAAAAAA,0000,57C27696,FF,FFAE,428440AAAAAA0000000401
HMLAN2_RSSI -82
HMLAN2_TIME 2015-08-07 19:12:47
IODev HMLAN1
LASTInputDev HMLAN2
MSGCNT 1453
NAME VCCU
NR 22
STATE CMDs_done
TYPE CUL_HM
assignedIOs HMLAN1,HMLAN2
channel_01 VCCU_Btn1
channel_02 VCCU_Btn2
channel_03 VCCU_Btn3
channel_04 VCCU_Btn4
channel_05 VCCU_Btn5
channel_06 VCCU_Btn6
channel_07 VCCU_Btn7
channel_08 VCCU_Btn8
channel_09 VCCU_Btn9
channel_0A VCCU_Btn10
channel_0B VCCU_Btn11
channel_0C VCCU_Btn12
channel_0D VCCU_Btn13
channel_0E VCCU_Btn14
channel_0F VCCU_Btn15
channel_10 VCCU_Btn16
channel_11 VCCU_Btn17
channel_12 VCCU_Btn18
channel_13 VCCU_Btn19
lastMsg No:42 - t:40 s:AAAAAA d:000000 0401
protLastRcv 2015-08-07 19:12:47
protSnd 1 last_at:2015-08-07 19:12:47
protState CMDs_done
rssi_at_HMLAN1 avg:-85.57 min:-103 max:-79 lst:-88 cnt:684
rssi_at_HMLAN2 avg:-90.35 min:-107 max:-81 lst:-82 cnt:769
Readings:
2015-08-07 19:09:14 CommandAccepted yes
2015-08-07 19:12:47 state CMDs_done
2015-08-01 15:24:57 unknown_30D433 received
2015-08-01 15:25:22 unknown_30D727 received
2015-08-03 00:15:20 unknown_377770 received
Helper:
HM_CMDNR 66
mId FFF0
rxType 1
Io:
nextSend 1438967567.4525
prefIO
vccu
ioList:
HMLAN1
HMLAN2
Mrssi:
mNo 42
Io:
HMLAN2 -82
Prt:
bErr 0
sProc 0
Rspwait:
Q:
qReqConf
qReqStat
Role:
dev 1
Rssi:
At_hmlan1:
avg -85.5774853801169
cnt 684
lst -88
max -79
min -103
At_hmlan2:
avg -90.3511053315995
cnt 769
lst -82
max -81
min -107
Attributes:
IODev HMLAN1
IOList HMLAN1,HMLAN2
model CCU-FHEM
room system
subType virtual
webCmd virtual:update
Ich habe die Sensoren gepeert, weil ich das a) gelesen hatte und damit angebl. den Eintrag trigDst no config beseitigen könne. Dem war aber nicht so. Die Meldungen aus den Tür/Fensterkontakten kam auch ohne das Peering. Ich nehme es mal raus. Ein event-on-change attr habe ich nun eh gesetzt, damit die Meldung zunächst nur einmal gesendet wird. Die interne Verarbeitung über beide HMLANs ist damit natürlich nicht verändert.
Ich hatte bisher kein preferred IO eingetragen weil dann auch beim Ausfall des preferred IO das VCCU das ander HMLAN verwendet. Ich hatte das so verstanden mit setzen von IOGrp mit/ohne Doppelpunkt und Nennung eines preferred.
Die in der Liste des VCCU aufgeführten unknown devices sind nach dem letzten update entstanden. Ich hatte nach dem update einen UP-Schalter neu angelernt. Es funktionierte alles, bis ich ein rename durchgeführt habe. direkt danach tauchte das device als unknown auf und mein Logfile wurde vollgemüllt mit error-Meldungen. das umbenante device hat aber trotzdem vollständig funktioniert. und es lag nicht am dazugehörigen log-file geprüft. Das war auch umbenannt. Ich habe dann das Pairing zurückgenommen und wiederholt. Irgenwann hat dann das rename komplett geklappt.
im state der vccu sollte eigentlich so etwas in der art stehen:
2015-08-06 08:03:40 state hmlan1:ok,hmusb1:ok, vielleicht liegt es an den vielen channel, die du hast. ich habe keine. aber mach mal set vccu update und kontrolliere.
ZitatIch hatte bisher kein preferred IO eingetragen weil dann auch beim Ausfall des preferred IO das VCCU das ander HMLAN verwendet. Ich hatte das so verstanden mit setzen von IOGrp mit/ohne Doppelpunkt und Nennung eines preferred.
nur beim attr IOgrp
kann man preffered io angeben. wenn man ein oder mehrere angibt,
immer mit doppelpunkt. solange das preffered io ok ist, wird es benutzt. wenn nicht, dann das nächste preffered. wenn keine perffered io mehr da sind, dann kommt das mit dem besten rssi von den noch möglichen. mit preffered io muss nicht ständig berechnet und umassigned werden. da io und device fest verbaut sind, wird sich bei dir auch nicht viel verändern, besonders wenn die rssi auch noch dicht beieinander liegen.
ZitatDie Meldungen aus den Tür/Fensterkontakten kam auch ohne das Peering. Ich nehme es mal raus.
dann halten die batterien sicher doppelt so lange. post noch ein log davon, zum vergleichen.
ZitatEin event-on-change attr habe ich nun eh gesetzt, damit die Meldung zunächst nur einmal gesendet wird.
ich habe überall "event-on-change .*". das gilt dann für alle readings. wenn ich doch mal ein reading mit jeglichen events benötige, setze ich zusätzlich "event-on-update my_reading". das gilt dann nur für dieses reading.
ZitatDie in der Liste des VCCU aufgeführten unknown devices sind nach dem letzten update entstanden. Ich hatte nach dem update einen UP-Schalter neu angelernt.
jedes neue device müsste eigentlich ein reading erzeugen, da die erste anlernmessage vom device immer von einem unbekannten device ist. erst anschliessend wird es gepaired und dadurch bekannt gemacht. danach sollte man das reading vielleicht mal löschen. ausserdem die wirklich unbekannten definieren und auf ignore setzen. dafür gibt es sogar einen befehl.
gruss frank
Hallo Frank,
danke fur die vielen Erklärungen. das ist immer gut für mich als Einsteiger. denn ich neige eh immer dazu, dass ich so weit möglich alles selber erklären kann und vieles hinterfrage.
ich werde deine Tipps nutzen. ich fliege aber Sonntag meinem Motorrad hinterher nach Barcelona. fahren dann 14 Tage von dort durch die Pyrenäen und Frankreich wieder heim. also bitte nicht wundern wenn ich nix über die Änderungen schreibe.
Danke.
Zitat14 Tage von dort durch die Pyrenäen
cool, das lohnt sich. aber immer damit rechnen, dass der gegenverkehr gelegendlich die kurven schneidet!!!
Zitat von: frank am 07 August 2015, 22:42:30
cool, das lohnt sich. aber immer damit rechnen, dass der gegenverkehr gelegendlich die kurven schneidet!!!
Das passiert auch im Schwarzwald ...
Und ändert nichts daran das Fragen zu HM besser im Homematic-Bereich aufgehoben wären - ich komm mir bei den leseresistenten Neulingen wie ein Papagei vor.
die Pyrenäen sind im Sommer echt leer. wir waren letztes Jahr schon dort und haben fast dieselbe Tour gemacht.
im Schwarzwald waren wir ende Juni. da ist auch schön und es gibt überall blöde Autofahrer.
fahrt ihr beide auch Motorrad?
Internals:
DEF AAAAAA
HMLAN1_MSGCNT 702
HMLAN1_RAWMSG EAAAAAA,0000,1C97A923,FF,FFB0,1CA011AAAAAA3777D10201C80000
HMLAN1_RSSI -80
HMLAN1_TIME 2015-08-07 22:32:51
HMLAN2_MSGCNT 801
HMLAN2_RAWMSG EAAAAAA,0000,5879FD7C,FF,FFAE,2FA011AAAAAA24077C0201000000
HMLAN2_RSSI -82
HMLAN2_TIME 2015-08-07 22:33:12
IODev HMLAN1
LASTInputDev HMLAN2
MSGCNT 1503
NAME VCCU
NR 22
STATE HMLAN1:ok,HMLAN2:ok,
TYPE CUL_HM
assignedIOs HMLAN1,HMLAN2
channel_01 VCCU_Btn1
channel_02 VCCU_Btn2
channel_03 VCCU_Btn3
channel_04 VCCU_Btn4
channel_05 VCCU_Btn5
channel_06 VCCU_Btn6
channel_07 VCCU_Btn7
channel_08 VCCU_Btn8
channel_09 VCCU_Btn9
channel_0A VCCU_Btn10
channel_0B VCCU_Btn11
channel_0C VCCU_Btn12
channel_0D VCCU_Btn13
channel_0E VCCU_Btn14
channel_0F VCCU_Btn15
channel_10 VCCU_Btn16
channel_11 VCCU_Btn17
channel_12 VCCU_Btn18
channel_13 VCCU_Btn19
lastMsg No:2F - t:11 s:AAAAAA d:24077C 0201000000
protLastRcv 2015-08-07 22:33:12
protSnd 1 last_at:2015-08-07 19:12:47
protState CMDs_done
rssi_at_HMLAN1 avg:-85.56 min:-103 max:-79 lst:-80 cnt:702
rssi_at_HMLAN2 avg:-90.24 min:-107 max:-81 lst:-82 cnt:801
Readings:
Helper:
HM_CMDNR 47
mId FFF0
rxType 1
Io:
nextSend 1438979593.04814
prefIO
vccu
ioList:
HMLAN1
HMLAN2
Mrssi:
mNo 2F
Io:
HMLAN2 -82
Prt:
bErr 0
sProc 0
Rspwait:
Q:
qReqConf
qReqStat
Role:
dev 1
Rssi:
At_hmlan1:
avg -85.5641025641025
cnt 702
lst -80
max -79
min -103
At_hmlan2:
avg -90.2446941323345
cnt 801
lst -82
max -81
min -107
Attributes:
IODev HMLAN1
IOList HMLAN1,HMLAN2
model CCU-FHEM
room system
subType virtual
webCmd virtual:update
hier nun die list VCCU nach update. sieht alles schöner aus. Die ehemaligen unknown device sind jetzt weg.
die preffered baue ich dann wieder ein.was mich allerdings wundert sind die schlechten rssi Werte der HMLAN. ich verstehe die Werte wenn sie hier im list vccu sind, wie die vccu die HMLAN sieht. ich hätte Top werte für rssi erwartet weil VCCU und die HMLAN ja über das ethernet "reden" und nicht über Funk.
bei einem fenstersensor steht folgende Einträge:
rssi_at_HMLAN1
avg:-94.4 min:-106 max:-85 lst:-89 cnt:115
rssi_at_HMLAN2
avg:-54.67 min:-56 max:-53 lst:-55 cnt:126
Die Differenzen sind logisch, da der Kontakt im Keller direkt neben dem HMLAN2 installiert ist, dort ist auch der fhem auf dem raspi2 installiert. der HMLAN1 ist hier oben im Wohnzimmer.
was sagen nun die rssi Werte im list VCCU?
Zitates gibt überall blöde Autofahrer.
Und Fussgeher und Fahradfahrer und Motorradfahrer aka "Töfffahrer" und und aber das hat mit FHEM nichts zu tun.
Wir können uns gern drüber unterhalten aber dann bitte unter Off-Topic.
Die Frage gehört dennoch weiterhin unter Homematic gestellt.
Wozu haben wir Unterbereiche?
Weil wir die "Probleme" aufteilen wollten um sie effizienter abarbeiten zu können.
Warum?
Weil martin im Homematicbereich eher mitliest (und das war nun das letzte Mal das ich das erwähne).
@misave
Willst du eine Lösung oder passende Hilfe?
Dann verschieb deinen Beitrag nach Homematic.
Wenn Rätselraten oder warten auf eine hilfreiche Antwort eher zu dir passt dann lass es hier stehen.
Verschieben kannst du selbst.
gelesen habe ich schon Unmengen.....
Aber wie lange ist eine Frage eine Anfängerfrage (zu einem device) und ab wann gehört die Frage in den Bereich des Device? Das Doku dazu oben im Forum gibt da keine so klare Linie. Ich nehme mir aber ab nun mehr vor, Fragen in die passenden Unterforen zu plazieren, wenn sie schon von mehr Detailwissen auf meiner Seite geprägt sind.
meine peerings hatte ich gemacht um Einträge wie diese wegzubekommen:
HMinfo:
configCheck done:
missing register list
HM_2051D2_Btn_01: RegL_01:,RegL_04:WZ_Terrasse_chn:01
HM_2051D2_Btn_02: RegL_01:,RegL_04:WZ_Terrasse_chn:01
Terrasentuer: RegL_00:
Ich hatte vorh dem peering mehr dieser Einträge. der HM_2051D2 ist ein HM Taster mit dem ich die Deckenlampe WZ_Terrasse schalte. die Terrassentuer ist der Drehgriffkontakt. diese beiden Sensoren sind als einzige nicht gepeert. es funktioniert aber alles. peering hatte ich nicht gemacht, weil ich halt einige andere device gepeert haben will und diese nicht, um eventuell unterschiedliche Verhalten entdecken zu können und dann nach den Ursachen suche. und manchmal mündet diese Suche dann in den Fragen, die ich hier stelle.
und wirklich schon mal Leute hier nerven könnte.
ich verschiebe dann mal meinen Beitrag hier weg.
ZitatAber wie lange ist eine Frage eine Anfängerfrage (zu einem device) und ab wann gehört die Frage in den Bereich des Device?
Wenn es von Anfang an klar ist das es sich um ein Device handelt und nicht um einen Code für irgendwas sollte die Frage im richtigen Forenbereich gestellt werden.
Hilfe würde im Anfängerbereich Rudis angepinnter Beitrag sowie mein angepinnter Beitrag geben.
Diese wären nur zu lesen.
Äh den Rest von deinem Kauderwelsch - keine Ahnung was du damit sagen willst.
Aber danke fürs richtige verschieben evtl. hat ja martin den Durchblick.
Aber du darfst auch gerne die Tags verwenden :P (wobei wir wieder ... ok, ich lass das vielleicht wird dir hier ja geholfen).
ist jetzt noch etwas offen?