Hallo zusammen,
dank meiner neuen Heizungsthermostate und eine HM-SEC-SC2 (siehe hier (http://forum.fhem.de/index.php/topic,35413.0.html)) habe ich den leisen Verdacht, das irgendetwas bei uns nicht stimmt.
Die Fensterkontakte haben häufig das Problem, das sie beim öffnen und schließen erst orange und dann rot (statt grün) blinken. Bei dem neuen Sensor ging das Pairing garnicht und bei den Fenstersensoren scheint ein getConfig auch nicht richtig zu funktionieren. Die Register füllen sich zwar nach und nach, aber es braucht einiges an rumgespiele (programmier-taste betätigen, sabotage-schalter betätigen) bis ich keinen Fehler mehr angezeigt bekomme.
Hinzu kommt, das ich von meinem PC, der per Kabel auf den HMLAN zugreifen können müsste, mich mit der Homematic eigenen Software nicht mit dem HMLAN verbinden kann. Beim Laptop über WLAN bekomme ich über "Find and Setup Lan Interfaces" den Adapter angezeigt und kann auch die Firmware aktualisieren, über "HomeMatic-Komponenten konfigurieren" komme ich aber auch nicht drauf.
Was mich noch etwas irritiert ist der HMLAN im (db-)log:
| 2015-04-09 08:37:02 | HMLAN1 | HMLAN | DISCONNECTED | state | DISCONNECTED | |
| 2015-04-09 08:37:04 | HMLAN1 | HMLAN | CONNECTED | state | CONNECTED | |
| 2015-04-09 08:46:06 | HMLAN1 | HMLAN | DISCONNECTED | state | DISCONNECTED | |
| 2015-04-09 08:46:08 | HMLAN1 | HMLAN | CONNECTED | state | CONNECTED | |
| 2015-04-09 09:02:24 | HMLAN1 | HMLAN | DISCONNECTED | state | DISCONNECTED | |
| 2015-04-09 09:02:27 | HMLAN1 | HMLAN | CONNECTED | state | CONNECTED | |
| 2015-04-09 09:03:26 | HMLAN1 | HMLAN | DISCONNECTED | state | DISCONNECTED | |
| 2015-04-09 09:03:28 | HMLAN1 | HMLAN | CONNECTED | state | CONNECTED | |
| 2015-04-09 09:18:11 | HMLAN1 | HMLAN | DISCONNECTED | state | DISCONNECTED | |
| 2015-04-09 09:18:13 | HMLAN1 | HMLAN | CONNECTED | state | CONNECTED | |
| 2015-04-09 09:21:21 | HMLAN1 | HMLAN | DISCONNECTED | state | DISCONNECTED | |
| 2015-04-09 09:21:29 | HMLAN1 | HMLAN | CONNECTED | state | CONNECTED | |
| 2015-04-09 09:35:34 | HMLAN1 | HMLAN | DISCONNECTED | state | DISCONNECTED | |
| 2015-04-09 09:35:47 | HMLAN1 | HMLAN | CONNECTED | state | CONNECTED | |
| 2015-04-09 09:39:29 | HMLAN1 | HMLAN | DISCONNECTED | state | DISCONNECTED | |
| 2015-04-09 09:39:38 | HMLAN1 | HMLAN | CONNECTED | state | CONNECTED | |
| 2015-04-09 09:43:11 | HMLAN1 | HMLAN | DISCONNECTED | state | DISCONNECTED | |
| 2015-04-09 09:43:16 | HMLAN1 | HMLAN | CONNECTED | state | CONNECTED | |
| 2015-04-09 09:46:11 | HMLAN1 | HMLAN | DISCONNECTED | state | DISCONNECTED | |
| 2015-04-09 09:46:19 | HMLAN1 | HMLAN | CONNECTED | state | CONNECTED | |
| 2015-04-09 09:48:58 | HMLAN1 | HMLAN | DISCONNECTED | state | DISCONNECTED | |
| 2015-04-09 09:48:59 | HMLAN1 | HMLAN | CONNECTED | state | CONNECTED | |
| 2015-04-09 09:50:39 | HMLAN1 | HMLAN | DISCONNECTED | state | DISCONNECTED | |
| 2015-04-09 09:50:41 | HMLAN1 | HMLAN | CONNECTED | state | CONNECTED | |
| 2015-04-09 09:51:53 | HMLAN1 | HMLAN | DISCONNECTED | state | DISCONNECTED | |
| 2015-04-09 09:52:00 | HMLAN1 | HMLAN | CONNECTED | state | CONNECTED | |
| 2015-04-09 09:53:52 | HMLAN1 | HMLAN | DISCONNECTED | state | DISCONNECTED | |
| 2015-04-09 09:53:54 | HMLAN1 | HMLAN | CONNECTED | state | CONNECTED | |
| 2015-04-09 10:06:09 | HMLAN1 | HMLAN | DISCONNECTED | state | DISCONNECTED | |
| 2015-04-09 10:06:11 | HMLAN1 | HMLAN | CONNECTED | state | CONNECTED | |
| 2015-04-09 10:16:22 | HMLAN1 | HMLAN | DISCONNECTED | state | DISCONNECTED | |
| 2015-04-09 10:16:24 | HMLAN1 | HMLAN | CONNECTED | state | CONNECTED | |
| 2015-04-09 10:24:15 | HMLAN1 | HMLAN | DISCONNECTED | state | DISCONNECTED | |
| 2015-04-09 10:24:17 | HMLAN1 | HMLAN | CONNECTED | state | CONNECTED | |
| 2015-04-09 10:34:09 | HMLAN1 | HMLAN | DISCONNECTED | state | DISCONNECTED | |
| 2015-04-09 10:34:11 | HMLAN1 | HMLAN | CONNECTED | state | CONNECTED | |
| 2015-04-09 10:41:40 | HMLAN1 | HMLAN | DISCONNECTED | state | DISCONNECTED | |
| 2015-04-09 10:41:42 | HMLAN1 | HMLAN | CONNECTED | state | CONNECTED | |
| 2015-04-09 10:58:10 | HMLAN1 | HMLAN | DISCONNECTED | state | DISCONNECTED | |
| 2015-04-09 10:58:13 | HMLAN1 | HMLAN | CONNECTED | state | CONNECTED | |
| 2015-04-09 11:02:35 | HMLAN1 | HMLAN | DISCONNECTED | state | DISCONNECTED | |
| 2015-04-09 11:02:37 | HMLAN1 | HMLAN | CONNECTED | state | CONNECTED | |
| 2015-04-09 11:05:53 | HMLAN1 | HMLAN | DISCONNECTED | state | DISCONNECTED | |
| 2015-04-09 11:06:02 | HMLAN1 | HMLAN | CONNECTED | state | CONNECTED | |
| 2015-04-09 11:11:58 | HMLAN1 | HMLAN | DISCONNECTED | state | DISCONNECTED | |
| 2015-04-09 11:12:00 | HMLAN1 | HMLAN | CONNECTED | state | CONNECTED | |
| 2015-04-09 11:22:02 | HMLAN1 | HMLAN | DISCONNECTED | state | DISCONNECTED | |
| 2015-04-09 11:22:05 | HMLAN1 | HMLAN | CONNECTED | state | CONNECTED | |
| 2015-04-09 11:24:26 | HMLAN1 | HMLAN | DISCONNECTED | state | DISCONNECTED | |
| 2015-04-09 11:24:30 | HMLAN1 | HMLAN | CONNECTED | state | CONNECTED | |
| 2015-04-09 11:25:37 | HMLAN1 | HMLAN | DISCONNECTED | state | DISCONNECTED | |
| 2015-04-09 11:25:39 | HMLAN1 | HMLAN | CONNECTED | state | CONNECTED | |
| 2015-04-09 11:27:00 | HMLAN1 | HMLAN | DISCONNECTED | state | DISCONNECTED | |
| 2015-04-09 11:27:05 | HMLAN1 | HMLAN | CONNECTED | state | CONNECTED | |
| 2015-04-09 11:33:37 | HMLAN1 | HMLAN | DISCONNECTED | state | DISCONNECTED | |
| 2015-04-09 11:33:39 | HMLAN1 | HMLAN | CONNECTED | state | CONNECTED | |
| 2015-04-09 11:40:27 | HMLAN1 | HMLAN | DISCONNECTED | state | DISCONNECTED | |
| 2015-04-09 11:40:29 | HMLAN1 | HMLAN | CONNECTED | state | CONNECTED | |
| 2015-04-09 11:42:28 | HMLAN1 | HMLAN | DISCONNECTED | state | DISCONNECTED | |
| 2015-04-09 11:42:30 | HMLAN1 | HMLAN | CONNECTED | state | CONNECTED | |
| 2015-04-09 11:46:53 | HMLAN1 | HMLAN | DISCONNECTED | state | DISCONNECTED | |
| 2015-04-09 11:46:55 | HMLAN1 | HMLAN | CONNECTED | state | CONNECTED | |
| 2015-04-09 11:52:08 | HMLAN1 | HMLAN | DISCONNECTED | state | DISCONNECTED | |
| 2015-04-09 11:52:15 | HMLAN1 | HMLAN | CONNECTED | state | CONNECTED | |
| 2015-04-09 11:57:31 | HMLAN1 | HMLAN | DISCONNECTED | state | DISCONNECTED | |
| 2015-04-09 11:57:41 | HMLAN1 | HMLAN | CONNECTED | state | CONNECTED | |
| 2015-04-09 12:16:22 | HMLAN1 | HMLAN | DISCONNECTED | state | DISCONNECTED | |
| 2015-04-09 12:16:24 | HMLAN1 | HMLAN | CONNECTED | state | CONNECTED | |
| 2015-04-09 12:22:38 | HMLAN1 | HMLAN | DISCONNECTED | state | DISCONNECTED | |
| 2015-04-09 12:22:40 | HMLAN1 | HMLAN | CONNECTED | state | CONNECTED | |
| 2015-04-09 12:27:13 | HMLAN1 | HMLAN | DISCONNECTED | state | DISCONNECTED | |
| 2015-04-09 12:27:17 | HMLAN1 | HMLAN | CONNECTED | state | CONNECTED | |
| 2015-04-09 12:40:37 | HMLAN1 | HMLAN | DISCONNECTED | state | DISCONNECTED | |
| 2015-04-09 12:40:39 | HMLAN1 | HMLAN | CONNECTED | state | CONNECTED | |
| 2015-04-09 12:45:32 | HMLAN1 | HMLAN | DISCONNECTED | state | DISCONNECTED | |
| 2015-04-09 12:45:34 | HMLAN1 | HMLAN | CONNECTED | state | CONNECTED | |
| 2015-04-09 12:50:05 | HMLAN1 | HMLAN | DISCONNECTED | state | DISCONNECTED | |
| 2015-04-09 12:50:10 | HMLAN1 | HMLAN | CONNECTED | state | CONNECTED | |
| 2015-04-09 12:58:19 | HMLAN1 | HMLAN | DISCONNECTED | state | DISCONNECTED | |
| 2015-04-09 12:58:21 | HMLAN1 | HMLAN | CONNECTED | state | CONNECTED | |
| 2015-04-09 13:01:20 | HMLAN1 | HMLAN | DISCONNECTED | state | DISCONNECTED | |
| 2015-04-09 13:01:29 | HMLAN1 | HMLAN | CONNECTED | state | CONNECTED | |
| 2015-04-09 13:05:36 | HMLAN1 | HMLAN | DISCONNECTED | state | DISCONNECTED | |
| 2015-04-09 13:05:38 | HMLAN1 | HMLAN | CONNECTED | state | CONNECTED | |
| 2015-04-09 13:08:31 | HMLAN1 | HMLAN | DISCONNECTED | state | DISCONNECTED | |
| 2015-04-09 13:08:33 | HMLAN1 | HMLAN | CONNECTED | state | CONNECTED | |
| 2015-04-09 13:21:10 | HMLAN1 | HMLAN | DISCONNECTED | state | DISCONNECTED | |
| 2015-04-09 13:21:17 | HMLAN1 | HMLAN | CONNECTED | state | CONNECTED | |
| 2015-04-09 13:22:40 | HMLAN1 | HMLAN | DISCONNECTED | state | DISCONNECTED | |
| 2015-04-09 13:22:46 | HMLAN1 | HMLAN | CONNECTED | state | CONNECTED | |
| 2015-04-09 13:31:07 | HMLAN1 | HMLAN | DISCONNECTED | state | DISCONNECTED | |
| 2015-04-09 13:31:13 | HMLAN1 | HMLAN | CONNECTED | state | CONNECTED | |
| 2015-04-09 13:44:57 | HMLAN1 | HMLAN | DISCONNECTED | state | DISCONNECTED | |
| 2015-04-09 13:45:01 | HMLAN1 | HMLAN | CONNECTED | state | CONNECTED | |
| 2015-04-09 13:50:31 | HMLAN1 | HMLAN | DISCONNECTED | state | DISCONNECTED | |
| 2015-04-09 13:50:33 | HMLAN1 | HMLAN | CONNECTED | state | CONNECTED | |
| 2015-04-09 13:51:13 | HMLAN1 | HMLAN | DISCONNECTED | state | DISCONNECTED | |
| 2015-04-09 13:51:20 | HMLAN1 | HMLAN | CONNECTED | state | CONNECTED | |
| 2015-04-09 13:53:21 | HMLAN1 | HMLAN | DISCONNECTED | state | DISCONNECTED | |
| 2015-04-09 13:53:23 | HMLAN1 | HMLAN | CONNECTED | state | CONNECTED | |
| 2015-04-09 13:56:29 | HMLAN1 | HMLAN | DISCONNECTED | state | DISCONNECTED | |
| 2015-04-09 13:56:31 | HMLAN1 | HMLAN | CONNECTED | state | CONNECTED | |
| 2015-04-09 14:03:02 | HMLAN1 | HMLAN | DISCONNECTED | state | DISCONNECTED | |
| 2015-04-09 14:03:04 | HMLAN1 | HMLAN | CONNECTED | state | CONNECTED | |
| 2015-04-09 14:03:54 | HMLAN1 | HMLAN | DISCONNECTED | state | DISCONNECTED | |
| 2015-04-09 14:03:59 | HMLAN1 | HMLAN | CONNECTED | state | CONNECTED | |
| 2015-04-09 14:05:28 | HMLAN1 | HMLAN | DISCONNECTED | state | DISCONNECTED | |
| 2015-04-09 14:05:38 | HMLAN1 | HMLAN | CONNECTED | state | CONNECTED | |
| 2015-04-09 14:06:38 | HMLAN1 | HMLAN | DISCONNECTED | state | DISCONNECTED | |
| 2015-04-09 14:06:42 | HMLAN1 | HMLAN | CONNECTED | state | CONNECTED | |
| 2015-04-09 14:11:42 | HMLAN1 | HMLAN | DISCONNECTED | state | DISCONNECTED | |
| 2015-04-09 14:11:44 | HMLAN1 | HMLAN | CONNECTED | state | CONNECTED | |
| 2015-04-09 14:26:42 | HMLAN1 | HMLAN | DISCONNECTED | state | DISCONNECTED | |
| 2015-04-09 14:26:44 | HMLAN1 | HMLAN | CONNECTED | state | CONNECTED | |
| 2015-04-09 14:28:37 | HMLAN1 | HMLAN | DISCONNECTED | state | DISCONNECTED | |
| 2015-04-09 14:28:39 | HMLAN1 | HMLAN | CONNECTED | state | CONNECTED | |
| 2015-04-09 14:52:50 | HMLAN1 | HMLAN | DISCONNECTED | state | DISCONNECTED | |
| 2015-04-09 14:52:59 | HMLAN1 | HMLAN | CONNECTED | state | CONNECTED | |
| 2015-04-09 14:57:26 | HMLAN1 | HMLAN | DISCONNECTED | state | DISCONNECTED | |
| 2015-04-09 14:57:28 | HMLAN1 | HMLAN | CONNECTED | state | CONNECTED | |
| 2015-04-09 15:02:58 | HMLAN1 | HMLAN | DISCONNECTED | state | DISCONNECTED | |
| 2015-04-09 15:03:06 | HMLAN1 | HMLAN | CONNECTED | state | CONNECTED | |
| 2015-04-09 15:07:48 | HMLAN1 | HMLAN | DISCONNECTED | state | DISCONNECTED | |
| 2015-04-09 15:07:50 | HMLAN1 | HMLAN | CONNECTED | state | CONNECTED | |
| 2015-04-09 15:11:45 | HMLAN1 | HMLAN | DISCONNECTED | state | DISCONNECTED | |
| 2015-04-09 15:11:47 | HMLAN1 | HMLAN | CONNECTED | state | CONNECTED | |
| 2015-04-09 15:22:45 | HMLAN1 | HMLAN | DISCONNECTED | state | DISCONNECTED | |
| 2015-04-09 15:22:57 | HMLAN1 | HMLAN | CONNECTED | state | CONNECTED | |
| 2015-04-09 15:27:06 | HMLAN1 | HMLAN | DISCONNECTED | state | DISCONNECTED | |
| 2015-04-09 15:27:08 | HMLAN1 | HMLAN | CONNECTED | state | CONNECTED | |
| 2015-04-09 15:46:42 | HMLAN1 | HMLAN | DISCONNECTED | state | DISCONNECTED | |
| 2015-04-09 15:46:44 | HMLAN1 | HMLAN | CONNECTED | state | CONNECTED | |
oder ist dieser Statuswechsel normal?
Ich weiß nicht genau, wo ich bei der Ursachenforschung ansetzen soll. Insgesamt funktioniert der Großteil meiner Automatisierung (Flurlicht, Alarmanlage, Thermostate, 2 Fenstersensoren, die mit je einem Thermostat gepeered sind). Aber irgendwas scheint ja nicht zu stimmen, oder ist es normal, das die Fenstersensoren so launisch sind?
Vielen Dank schonmal im voraus!
Moin,
ich habe das gleiche Problem mit den Sensoren :-\, außerdem fressen einige die Batterien. Die neueren mit optischem Sensor scheinen besser zu laufen, habe mir einen zu testzweckend besorgt.
Gruß aus HH
Hi
Ich habe einen von den besagten im Einsatz und kann bis jetzt nicht klagen.
Bei optischen möchte ich allerdings etwas warnen .. die scheinen Schwierigkeiten mit der Sonneneinstrahlung zu haben.
Ich habe dieses open/closed-Toggle-Phänomen bei zwei von meinen 10 optischen Sensoren gehabt obwohl sie nicht dem direkten Sonnenlicht ausgesetzt waren.
Ich vermute daher Reflexionen von irgendwelchen Gegenständen im Raum.
Von den Bausätzen kann ich im Moment nur abraten ... hatte 75 Prozent Rückläufer !
Wobei zwei Probleme mit Streulicht hatten ... hat ELV sogar zugegeben ... es soll angeblich abgeänderte Modelle geben.
Wenn die LED Rot blinkt deutet das auf eine schlechte Funkverbindung hin un das der Sender kein ACK vom Empfänger bekommt.
Schau dir mal die RSS-Werte an.
Hast Du frische Batterien eingelegt?
die Dinger scheinen bei Lieferung nicht mehr ganz so fir auf der Brust zu sein
Nein, neue Batterien habe ich nicht versucht. Ich hätte das eher ausgeschlossen, wenn er meldet, battery ok
Macht ihr das Peering generell direkt über FHEM oder nutzt ihr die Homematic-Software?
Ich habe jetzt einen neuen Dimmer und da ein ähnliches Problem wie mit den Fenstersensoren (der Dimmer ist im selben Zimmer wie HMLAN).
Im Status steht: RESPONSE TIMEOUT:RegisterRead
Im anderen Thread wurde mir empfohlen die Fenstersensoren (bzw. alles *SEC*) über die HM-Software anzulernen und auch die gleiche HMID für FHEM und die Homematic-SW zu verwenden. Das Problem ist: Bisher war sie unterschiedlich. Würde ich nun die HMID in FHEM verändern, müsste ich alle pairings noch einmal neu machen. Gibt es eine Möglichkeit, die HMID von FHEM in die Homematic-SW zu übernehmen?
Bin ich nicht sicher. Es gibt ein config file..... probieren.
Du kannst aber auch anders rum. Setze die paired register auf die winsw um. Dann setze die id des hmlan um
Ich habe es heute mal geprüft, die ID in der winsw ist die selbe wie die, die ich bei FHEM eingestellt habe aber nicht die originale (reading D-HMIdOriginal).
Hatte vorhin mal versucht, den Haustür-Kontakt mit der winsw zu pairen, das hat irgendwie nicht hingehauen.
Unter FHEM scheint das Pairing zwar zu funktionieren, allerdings setzt er es nicht korrekt, denn im Reading steht:
R-pairCentral set_0x0B0B0B
ZitatUnter FHEM scheint das Pairing zwar zu funktionieren, allerdings setzt er es nicht korrekt, denn im Reading steht:
R-pairCentral set_0x0B0B0B
also, eins geht nur. wenn das pairing funktioniert, muss natürlich auch richtig gesetzt sein. deine anzeige besagt doch nur, dass das register gesetzt wurde. nun solltest du mal das setzen kontrollieren, zb mit getconfig. solange du nicht verifizierst, bleibt das "set_".
Mit funktioniert meinte ich im Endeffekt, das der Sensor sich zu pairen scheint. Also bei der winsw blinkte er ewig und am Ende rot und bei firm blinkte er Orange und hörte aber recht schnell wieder auf. Das Problem ist nur, das getConfig irgendwie nicht korrekt durch läuft. Das scheint bei mir ein generelles Problem zu sein. Entweder kriege ich so was wie missing ack oder diesen RESPONSE TIMEOUT:RegisterRead
hast du denn dein disconnect problem vom hmlan gelöst?
Nein, ich wusste oder weiß nicht, ob das normal ist, dachte mir, er geht vielleicht in nen ruhemodus oder so... Dürften diese ständigen reconnects nicht sein, oder?
optimalerweise gibt es gar kein disconnect. wenn er disconnected ist, kann fhem keine messages über ihn senden und bekommt natürlich auch keine empfangsdaten.
wenn das immer noch so häufig vorkommt wie hier im thread gepostet, solltest du dringend dem problem auf die spur kommen. häufig sind es netzwerkprobleme oder fhem wird blockiert, sodass fhem den hmlan nicht regelmässig "streicheln" kann.
zb mit apptime und/oder performancemonitor kann man verschiedene probleme erkennen.
Okay, danke, ich versuche mich da mal.
Kann das auch die Ursache für diesen Response Timeout sein? Ich hatte immer vermutet, das es am Funk-Verkehr liegt, das da irgendwo auf dem "Kabelweg" zwischen HMLAN und Raspberry was nicht stimmt, hatte ich garnicht auf dem Schirm.
ZitatKann das auch die Ursache für diesen Response Timeout sein?
schon denkbar. oder während des pairings gab es probleme. am besten du loggst mal die rawmessages (siehe wiki sniffen) vom pairen und getconfig. dann kann man das genauer erkennen.
die rssi-werte sind aber ok?
Ich werde mal versuchen, beide Geräte direkt an die Fritzbox, bzw. den selben switch zu hängen, vielleicht löst sich dann das Disconnect Problem.
Wie komme ich an die rssi-werte?
Ich hatte bei dem "defekten" hm-sec-sc2 auch versucht gehabt, ihn zu pairen, bzw. getConfig "auszuführen" als ich direkt neben dem HMLAN-Adapter stand um auszuschließen, das es die Reichweite ist.
ZitatWie komme ich an die rssi-werte?
zb get rssi über hminfo.
Zitatals ich direkt neben dem HMLAN-Adapter stand um auszuschließen, das es die Reichweite ist.
zu dicht ist auch schlecht. zum testen am besten 2-3 meter abstand.
Hier wären die rssi-werte schon mal:
Device receive from last avg min<max count
CUL_HM_HM_CC_RT_DN_236BCB HMLAN1 CUL_HM_HM_CC_RT_DN_236BCB -82.0 -85.6 -102.0< -78.0 458
CUL_HM_HM_CC_RT_DN_31354C CUL_HM_HM_CC_RT_DN_31354C HMLAN1 -78.0 -77.0 -78.0< -76.0 2
CUL_HM_HM_CC_RT_DN_31354C HMLAN1 CUL_HM_HM_CC_RT_DN_31354C -78.0 -78.6 -101.0< -74.0 458
CUL_HM_HM_CC_RT_DN_3136CC CUL_HM_HM_CC_RT_DN_3136CC HMLAN1 -69.0 -69.0 -69.0< -69.0 2
CUL_HM_HM_CC_RT_DN_3136CC HMLAN1 CUL_HM_HM_CC_RT_DN_3136CC -68.0 -67.7 -71.0< -64.0 472
CUL_HM_HM_CC_RT_DN_313CC3 HMLAN1 CUL_HM_HM_CC_RT_DN_313CC3 -58.0 -57.6 -63.0< -57.0 450
CUL_HM_HM_TC_IT_WM_W_EU_2D3145 CUL_HM_HM_TC_IT_WM_W_EU_2D3145 HMLAN1 -42.0 -42.0 -42.0< -42.0 4
CUL_HM_HM_TC_IT_WM_W_EU_2D3145 HMLAN1 CUL_HM_HM_TC_IT_WM_W_EU_2D3145 -51.0 -51.0 -51.0< -51.0 930
HM_1A959E HMLAN1 HM_1A959E -59.0 -62.8 -72.0< -59.0 4
LED16 HMLAN1 LED16 -73.0 -76.0 -88.0< -72.0 288
LED16 LED16 HMLAN1 -74.0 -76.2 -80.0< -72.0 255
fl_fenster HMLAN1 fl_fenster -84.0 -88.8 -101.0< -80.0 15
fl_licht HMLAN1 fl_licht -80.0 -80.2 -82.0< -79.0 16
fl_licht fl_licht HMLAN1 -81.0 -81.5 -83.0< -81.0 11
fl_taster HMLAN1 fl_taster -80.0 -80.0 -80.0< -80.0 1
spz_fenster HMLAN1 spz_fenster -95.0 -95.0 -95.0< -95.0 1
Edit: Sorry, Formatierung war verloren gegangen...
die 2 fenster devices sehen nicht gut aus. ein rt ebenfalls.
grob gesagt, würde ich behaupten, alles kleiner -80 könnte problematisch werden. gerade wenn der avg deutlich tiefer liegt. wenn dein problem-fenster dabei ist, solltest du die werte verbessern.
ich habe bei meinem hmlan ein kleines loch ins gehäuse gebohrt und dort den antennendraht gerade nach aussen geführt. zusätzlich noch etwas zentraler aus dem regal an die wand gehängt. das brachte fast bei allen devices 10-20 punkte bessere rssi. bei meinen fensterkontakten habe ich das auch gemacht.
Ok. Gut zu wissen. Zwischeninfo: das Umstecken vom Raspberry hat leider nichts geholfen. Ich habe immernoch die Disconnects obwohl HMLAN und Raspberry direkt an der Fritzbox hängen.
Zum Thema Empfang habe ich mich jetzt mal mit dem Dimmer versucht (HM_1A959E) der sollte ja vom rssi Wert er ok sein. Allerdings kriege ich hier auch (wieder) ein response timeout bei einem getConfig.
So, mit apptime habe ich jetzt mal ein performancefresser rausgenommen (TV-Programm).
Im Moment sieht mein Log nicht sehr berauschend aus, was den performancemonitor angeht:
2015.04.14 21:15:12 0: Server shutdown
2015.04.14 21:15:36 2: Perfmon: ready to watch out for delays greater than one second
2015.04.14 21:15:42 3: telnetPort: port 7072 opened
2015.04.14 21:15:43 3: WEB: port 8083 opened
2015.04.14 21:15:43 3: WEBphone: port 8084 opened
2015.04.14 21:15:43 3: WEBtablet: port 8085 opened
2015.04.14 21:15:45 1: HMLAN_Parse: HMLAN1 new condition disconnected
2015.04.14 21:15:45 3: Opening HMLAN1 device 192.168.150.11:1000
2015.04.14 21:15:45 3: HMLAN1 device opened
2015.04.14 21:15:45 1: HMLAN_Parse: HMLAN1 new condition init
2015.04.14 21:15:50 3: Allguth: Defined with URL http://www.clever-tanken.de/tankstelle_details/98 and interval 600
2015.04.14 21:15:50 3: Shell: Defined with URL http://www.clever-tanken.de/tankstelle_details/6564 and interval 600
2015.04.14 21:15:50 3: HundH: Defined with URL http://www.clever-tanken.de/tankstelle_details/28645 and interval 600
2015.04.14 21:15:51 3: Opening FritzBoxCallMonitor device 192.168.150.1:1012
2015.04.14 21:15:51 3: FritzBoxCallMonitor device opened
2015.04.14 21:15:51 3: FB_CALLMONITOR (FritzBoxCallMonitor) - loading cache file /opt/fhem/callmoncache.txt
2015.04.14 21:15:51 2: FB_CALLMONITOR (FritzBoxCallMonitor) - read 6 contacts from Cache
2015.04.14 21:15:57 2: eventTypes: loaded 2012 events from log/eventTypes.txt
2015.04.14 21:15:58 3: Connecting to database mysql:database=fhem;host=localhost;port=3306 with user fhemuser
2015.04.14 21:15:58 3: Connection to db mysql:database=fhem;host=localhost;port=3306 established for pid 3708
2015.04.14 21:15:58 3: Connection to db mysql:database=fhem;host=localhost;port=3306 established
2015.04.14 21:16:01 3: Registering HTTPSRV tablet_ui for URL /tablet...
2015.04.14 21:16:04 3: DBPlan_Define (SBahnMuenchen) - defined with interval 60 (sec)
2015.04.14 21:16:04 3: DBPlan_Define (SBahnNeufahrn) - defined with interval 60 (sec)
2015.04.14 21:16:07 3: NTFY return: FritzBoxCallMonitor:Could not read FritzBox phonebook file - Error on reading /opt/fhem/fb_phonebook.xml from database!
2015.04.14 21:16:07 0: Server started with 274 defined entities (version $Id: fhem.pl 8430 2015-04-13 17:03:56Z rudolfkoenig $, os linux, user fhem, pid 3708)
2015.04.14 21:16:07 1: Perfmon: possible freeze starting at 21:15:37, delay is 30.798
2015.04.14 21:16:08 3: telnetForBlockingFn: port 53455 opened
2015.04.14 21:16:16 1: HMLAN_Parse: HMLAN1 new condition ok
2015.04.14 21:16:22 1: Perfmon: possible freeze starting at 21:16:08, delay is 14.936
2015.04.14 21:16:22 3: Device CUL_HM_HM_CC_RT_DN_236BCB added to ActionDetector with 000:10 time
2015.04.14 21:16:25 3: Device CUL_HM_HM_CC_RT_DN_31354C added to ActionDetector with 000:10 time
2015.04.14 21:16:25 3: Device CUL_HM_HM_CC_RT_DN_3136CC added to ActionDetector with 000:10 time
2015.04.14 21:16:26 3: Device CUL_HM_HM_CC_RT_DN_313CC3 added to ActionDetector with 000:10 time
2015.04.14 21:16:27 3: Device CUL_HM_HM_TC_IT_WM_W_EU_2D3145 added to ActionDetector with 000:10 time
2015.04.14 21:16:28 3: Device az_fenster added to ActionDetector with 028:00 time
2015.04.14 21:16:29 3: CUL_HM set LED16_11_Alarm_Arbeitszimmer led green
2015.04.14 21:16:29 3: CUL_HM set LED16_03_Alarm_Status_EG led green
2015.04.14 21:16:30 3: Device fl_fenster added to ActionDetector with 028:00 time
2015.04.14 21:16:31 3: CUL_HM set LED16_07_Alarm_Status_Haustuere led green
2015.04.14 21:16:32 3: CUL_HM set LED16_03_Alarm_Status_EG led green
2015.04.14 21:16:33 3: Device fl_rauchmelder added to ActionDetector with 099:00 time
2015.04.14 21:16:34 3: Device k_fenster added to ActionDetector with 028:00 time
2015.04.14 21:16:34 3: CUL_HM set LED16_14_Alarm_Kueche led green
2015.04.14 21:16:35 3: CUL_HM set LED16_04_Alarm_Status_ZG led green
2015.04.14 21:16:43 3: Device spz_fenster added to ActionDetector with 028:00 time
2015.04.14 21:16:44 3: CUL_HM set LED16_03_Alarm_Status_EG led green
2015.04.14 21:16:46 3: Device wz_fenster added to ActionDetector with 028:00 time
2015.04.14 21:16:47 3: CUL_HM set LED16_13_Alarm_Wohnzimmer led green
2015.04.14 21:16:48 3: CUL_HM set LED16_04_Alarm_Status_ZG led green
2015.04.14 21:16:50 1: 192.168.150.11:1000 disconnected, waiting to reappear (HMLAN1)
2015.04.14 21:16:50 1: HMLAN_Parse: HMLAN1 new condition disconnected
2015.04.14 21:16:52 1: 192.168.150.11:1000 reappeared (HMLAN1)
2015.04.14 21:16:52 1: HMLAN_Parse: HMLAN1 new condition init
2015.04.14 21:16:53 1: Perfmon: possible freeze starting at 21:16:23, delay is 30.633
2015.04.14 21:16:54 3: CUL_HM set wz_licht statusRequest
2015.04.14 21:17:16 1: HMLAN_Parse: HMLAN1 new condition ok
2015.04.14 21:17:36 1: Perfmon: possible freeze starting at 21:16:54, delay is 42.669
2015.04.14 21:17:36 3: CUL_HM set HM_1A959E_Sw1_V_01 statusRequest
2015.04.14 21:17:40 1: Perfmon: possible freeze starting at 21:17:37, delay is 3.895
2015.04.14 21:17:40 3: CUL_HM set HM_1A959E_Sw1_V_02 statusRequest
2015.04.14 21:17:41 3: CUL_HM set fl_licht statusRequest
2015.04.14 21:17:43 1: Perfmon: possible freeze starting at 21:17:42, delay is 1.298
2015.04.14 21:17:43 3: CUL_HM set fl_rauchmelder statusRequest
2015.04.14 21:18:14 1: Perfmon: possible freeze starting at 21:17:45, delay is 29.139
2015.04.14 21:18:15 1: 192.168.150.11:1000 disconnected, waiting to reappear (HMLAN1)
2015.04.14 21:18:15 1: HMLAN_Parse: HMLAN1 new condition disconnected
2015.04.14 21:18:16 1: 192.168.150.11:1000 reappeared (HMLAN1)
2015.04.14 21:18:16 1: HMLAN_Parse: HMLAN1 new condition init
2015.04.14 21:18:17 1: Perfmon: possible freeze starting at 21:18:15, delay is 2.206
2015.04.14 21:18:23 1: HMLAN_Parse: HMLAN1 new condition ok
2015.04.14 21:18:24 1: Perfmon: possible freeze starting at 21:18:18, delay is 6.453
2015.04.14 21:18:25 3: CUL_HM set LED16_08_Licht_gesamt led off
2015.04.14 21:18:25 3: CUL_HM set LED16_08_Licht_gesamt led off
2015.04.14 21:18:26 3: CUL_HM set LED16_08_Licht_gesamt led off
2015.04.14 21:18:26 3: CUL_HM set LED16_08_Licht_gesamt led off
2015.04.14 21:18:26 3: CUL_HM set LED16_08_Licht_gesamt led off
2015.04.14 21:18:29 1: PERL WARNING: Subroutine HandleTimeout redefined at ./FHEM/98_apptime.pm line 24.
2015.04.14 21:18:29 1: PERL WARNING: Subroutine CallFn redefined at ./FHEM/98_apptime.pm line 58.
2015.04.14 21:18:29 1: Perfmon: possible freeze starting at 21:18:25, delay is 4.544
2015.04.14 21:18:31 3: CUL_HM set HM_1A959E getConfig
2015.04.14 21:18:33 1: Perfmon: possible freeze starting at 21:18:30, delay is 3.304
2015.04.14 21:18:38 1: Perfmon: possible freeze starting at 21:18:34, delay is 4.773
2015.04.14 21:19:22 1: Perfmon: possible freeze starting at 21:19:17, delay is 5.211
2015.04.14 21:19:34 1: Perfmon: possible freeze starting at 21:19:31, delay is 3.227
2015.04.14 21:19:47 1: Perfmon: possible freeze starting at 21:19:46, delay is 1.928
2015.04.14 21:20:07 1: Perfmon: possible freeze starting at 21:20:06, delay is 1.288
Apptime gibt mir im Moment folgendes aus:
name function max count total average maxDly
HMLAN1 HMLAN_Read 8547 29 49303 1700.10 0 HASH(HMLAN1)
logdb DbLog_Log 6636 54 52877 979.20 0 HASH(logdb); HASH(wz_heizung)
FHEMWEB:192.168.150.20:51032 FW_Read 5520 17 5652 332.47 0 HASH(FHEMWEB:192.168.150.20:51032)
tmr-CUL_HM_procQs CUL_HM_procQs 2058 1 2058 2058.00 1098 CUL_HM_procQs
tmr-ROOMMATE_DurationTimer HASH(0x2d08c28) 1074 1 1074 1074.00 6 HASH(rr_Josi_DurationTimer)
tmr-CUL_HM_respPendTout respPend:1A959E 889 4 903 225.75 1256 respPend:1A959E
tmr-ROOMMATE_DurationTimer HASH(0x17df160) 888 1 888 888.00 4 HASH(rr_Josi_DurationTimer)
FileLog_LED16 FileLog_Log 598 9 606 67.33 0 HASH(FileLog_LED16); HASH(LED16)
heizung_gesamt structure_Notify 576 54 2031 37.61 0 HASH(heizung_gesamt); HASH(az_heizung)
tmr-ROOMMATE_DurationTimer HASH(0x2fae4a0) 517 1 517 517.00 4 HASH(rr_Josi_DurationTimer)
tmr-ROOMMATE_DurationTimer HASH(0x17ca818) 513 1 513 513.00 3947 HASH(rr_Josi_DurationTimer)
FileLog_CUL_HM_HM_CC_RT_DN_31354 FileLog_Log 98 2 99 49.50 0 HASH(FileLog_CUL_HM_HM_CC_RT_DN_31354); HASH(CUL_HM_HM_CC_RT_DN_31354C)
tmr-PRESENCE_StartLocalScan HASH(0x26cd9d8) 72 7 290 41.43 3697 HASH(josi.handy)
tmr-PRESENCE_StartLocalScan HASH(0x26bb0f0) 71 7 326 46.57 3169 HASH(alex.handy)
tmr-PRESENCE_StartLocalScan HASH(0x28b25c8) 58 7 233 33.29 4012 HASH(alex.PC)
tmr-PRESENCE_StartLocalScan HASH(0x28b2088) 26 7 127 18.14 4085 HASH(josi.PC)
telnetForBlockingFn telnet_Read 17 31 124 4.00 0 HASH(telnetForBlockingFn)
battery_check notify_Exec 16 54 68 1.26 0 HASH(battery_check); HASH(fl_rauchmelder)
tmr-HMLAN_KeepAlive keepAlive:HMLAN1 16 10 44 4.40 2612 keepAlive:HMLAN1
wz_thermostat CUL_HM_Set 16 2 26 13.00 0 HASH(wz_thermostat); wz_thermostat; ?
tmr-FRITZBOX_Readout_Start FritzBox.Readout 15 1 15 15.00 5 FritzBox.Readout
Ok, jetzt habe ich ein anderes Problem. Ich habe etwas aufgeräumt, also meine alte Alarmanlagen-Schaltung rausgeschmissen und ein paar httpmods. Also alles übers Webinterface per delete ... .
Jetzt schmiert mir FHEM ab. Im Log finde ich:
2015.04.15 17:52:37 1: PERL ERROR: Can't locate Authen/SASL/XS.pm in @INC (@INC contains: ./FHEM/lib ./lib /etc/perl /usr/local/lib/perl/5.14.2 /usr/local/share/perl/5.14.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.14 /usr/share/perl/5.14 /usr/local/lib/site_perl . ./FHEM) at (eval 3415) line 2.
2015.04.15 17:52:37 3: stacktrace:
2015.04.15 17:52:37 3: main::__ANON__ called by (eval 3415) (2)
2015.04.15 17:52:37 3: (eval) called by /usr/share/perl5/Authen/SASL.pm (76)
2015.04.15 17:52:37 3: Authen::SASL::client_new called by /usr/share/perl5/XML/Stream.pm (2155)
2015.04.15 17:52:37 3: XML::Stream::SASLClient called by /usr/share/perl5/Net/XMPP/Protocol.pm (1958)
2015.04.15 17:52:37 3: Net::XMPP::Protocol::AuthSASL called by /usr/share/perl5/Net/XMPP/Protocol.pm (1807)
2015.04.15 17:52:37 3: Net::XMPP::Protocol::AuthSend called by ./FHEM/99_myUtils.pm (66)
2015.04.15 17:52:37 3: main::GoogleTalk called by (eval 3405) (1)
2015.04.15 17:52:37 3: (eval) called by fhem.pl (917)
2015.04.15 17:52:37 3: main::AnalyzePerlCommand called by fhem.pl (937)
2015.04.15 17:52:37 3: main::AnalyzeCommand called by fhem.pl (869)
2015.04.15 17:52:37 3: main::AnalyzeCommandChain called by ./FHEM/91_watchdog.pm (145)
2015.04.15 17:52:37 3: main::watchdog_Trigger called by fhem.pl (2574)
2015.04.15 17:52:37 3: main::HandleTimeout called by fhem.pl (540)
2015.04.15 17:52:40 1: CallBlockingFn: Can't connect to localhost:47533: IO::Socket::INET: connect: Verbindungsaufbau abgelehnt
2015.04.15 17:52:40 1: PERL ERROR: Can't use an undefined value as a symbol reference at FHEM/Blocking.pm line 125.
2015.04.15 17:52:40 3: stacktrace:
2015.04.15 17:52:40 3: main::__ANON__ called by FHEM/Blocking.pm (125)
2015.04.15 17:52:40 3: main::BlockingInformParent called by FHEM/Blocking.pm (94)
2015.04.15 17:52:40 3: main::BlockingCall called by ./FHEM/73_PRESENCE.pm (535)
2015.04.15 17:52:40 3: main::PRESENCE_StartLocalScan called by fhem.pl (2574)
2015.04.15 17:52:40 3: main::HandleTimeout called by fhem.pl (540)
das presence modul macht einen (wohl internen) aufruf einer Hintergrundaktion Blocking. Die geht schief, weil etwas fehlt.
Also Presence untersuchen - ggf alles davon rausschmeißen und probieren
Ok, danke. Das Presence-Problem hat sich jetzt wohl erledigt. Ich hatte Verbose Logging auf 4 gestellt und seitdem trat es nichtmehr auf. Ich bin mir unsicher, ob ich in dem Zuge auch den RPi neugestartet habe und es vielleicht damit zusammen hängt, das der sich irgendwie verschluckt hat.
Das Problem mit den HMLAN disconnects besteht aber leider weiterhin :/
Ich weiß nicht, ob es Sinn macht, den RPi platt zu machen und alles neu zu installieren :/
ZitatDas Problem mit den HMLAN disconnects besteht aber leider weiterhin :/
Ich weiß nicht, ob es Sinn macht, den RPi platt zu machen und alles neu zu installieren :/
eher nicht, würde ich behaupten.
logdb DbLog_Log 6636 54 52877 979.20 0 HASH(logdb); HASH(wz_heizung) überprüfe mal deine datenbank.
Vielleicht lag es daran. Ich habe den Sprung ins kalte und unangenehme Wasser gewagt und habe den RPi komplett platt gemacht, neu installiert und bis jetzt funktioniert alles recht gut. Habe ein paar Empfangsprobleme jetzt gehabt, aber die kriege ich dann wahrscheinlich in den Griff, wenn ich mit dem HMLAN weiter ins Zentrum des Hauses vorrücke. Zumindest bisher keine Disconnects von HMLAN.
Wie kann denn sowas sein? Habe heute meinen neuen hm-sec-sc2 ausgepackt, gepaired, getConfig, alles ok, dann mit meinem Heizungsthermostat gepeered (windowRec Channel) und das kam dabei raus:
Internals:
DEF 236BCB03
NAME HM_236BCB_WindowRec
NR 52
STATE last:og.sz.fenster :closed
TYPE CUL_HM
chanNo 03
device HM_236BCB
peerList og.sz.fenster,
Readings:
2015-04-24 22:50:48 R-og.sz.fenster_chn-01-shCtValLo 50
2015-04-24 22:50:48 R-og.sz.fenster_chn-01-winOpnTemp 12 C
2015-04-20 16:49:35 R-sign off
2015-04-24 22:50:47 RegL_01: 08:00 00:00
2015-04-24 22:50:48 RegL_03:og.sz.fenster_chn:01 04:32 00:00
2015-04-24 22:50:48 RegL_07:og.sz.fenster_chn:01 05:18 00:00
2015-04-24 22:50:47 peerList og.sz.fenster,
2015-04-23 15:01:39 state unpeered
2015-04-24 22:57:39 trigLast og.sz.fenster :closed
2015-04-24 22:57:39 trig_og.sz.fenster closed
Helper:
peerIDsRaw ,31BB9401,00000000
Role:
chn 1
Shadowreg:
Attributes:
model HM-CC-RT-DN
peerIDs 00000000,31BB9401,
stateFormat last:trigLast
Das state unpeered wundert mich...
Mich auch. Das Reading mit der Peerlist vom Sensor ist aber von 22:50, der state von 15:01, vielleicht also noch von vor dem Peeren. Seltsam.
Stimmt. Komisch ist, das ich den Sensor ja erst gestern ausgepackt habe, also er am 23. noch Batterielos in der Verpackung lag...
das ist so eine Sache....
der state des winrec könnte "unpeered" sein, wenn er nicht gepeert ist.
ist er gepeert wird bei WinRec NICHT peered geschrieben. Grund: ein gepeerter WinRec sollte als state open oder closed haben. das soll nicht überschrieben werden.
Es gibt also channels, die nur peered/unpeered haben und solche, die, wenn gepeert einen anderen State bereitstellen. Hier werden ich wohl besser "unknown" schreiben.
Zitat von: martinp876 am 25 April 2015, 11:37:16
Grund: ein gepeerter WinRec sollte als state open oder closed haben. das soll nicht überschrieben werden.
Nur für mich interessehalber, weil mich das sicher auch mal betrifft: das Reading
state = unpeered stammt also aus einer Zeit vor einem Peering. Da macht unknown als default natürlich mehr Sinn - ob gepeert ist oder nicht, ist ja in der peerList ohnehin ersichtlich.
Andererseits sollte
state also den Status des Fensterkontakts spiegeln - sprich: bei einer Zustandsänderung des Fenstersensors würde das aktualisiert - im Internal STATUS steht ja closed. Hat das der Thermostat geliefert oder hat das FHEM gelesen? Ist der Thermostat so modifiziert worden, dass er vom Fensterkontakt geweckt werden kann, weiß der Fensterkontakt, dass er den Thermostaten wecken muss? Da war doch irgendsowas ... http://www.fhemwiki.de/wiki/HM-CC-RT-DN_Funk-Heizk%C3%B6rperthermostat (http://www.fhemwiki.de/wiki/HM-CC-RT-DN_Funk-Heizk%C3%B6rperthermostat), Stichwort Burst ...
Möglich, dass etwas nicht funktioniert - dennoch ist das in diesem einfachen Fall gar nicht so einfach.
Grundsätzlich ist es ein Versuch immer etwas im Status stehen zu haben, auch bei Kanälen, die keinen operationalen Status liefern können.
Zum einen haben wir den SC und dann den WINREC. Die sind erst einmal unabhängig.
Mehr noch - der allgemeine Fall ist, dass es peerings mit Sensoren gibt, die keinen Status liefern (nicht beim Winrec, aber ClimaTeam z.B.). Da gibt es als Status nur peered/unpeered.
Zurück zum WinRec:
Wenn das Peering
eingetragen wird - in FHEM! - wird der Status geprüft. Das passiert auch bei neustarts, es passiert, wenn das Attribut in der peerlist gesetzt wird. Beim Neustart wird es dann durch das lesen der alten Readings wieder überschrieben - vom letzten (zeitpunkt etwas undefiniert..) bekannten Zustand. Das ist FHEM-Kernal.
Wenn ein WinRec nun nicht gepeert ist ist der Zustand unpeered - es gibt keinen SC.
Wenn gepeert ist ist der Zustand NICHT der des SC - sondern der des WINREC. Nur wenn ein trigger eines gepeerten SC an den Winrec gesehen wird ändert sich der Zustand des WinRec.
Das Kopieren des Zustands eines SC in den des WinRec ist sinnlos. Es könnte sei, dass - warum auch immer - kein trigger kommt (SC ist nicht gepeert, WinRec schon...). Ausserdem kann ein WinRec mit mehreren SC gepeert sein. Kopieren ist da sowieso kein Thema.
Es könnte also ein Thema sein, dass das handling mehrere SC an einem WinRec nicht korrekt dargestellt wird -kann ich noch einmal nachsehen.
Zitat
Ist der Thermostat so modifiziert worden, dass er vom Fensterkontakt geweckt werden kann
conditional Burst muss an sein. Sollte HMInfo prüfen - wenn nicht werden ich es nachtragen.
Zitatweiß der Fensterkontakt, dass er den Thermostaten wecken muss?
der muss gepeert sein - im peering (den Registern des SC für denWinRec) muss eingetragen sein, dass der winrec burst braucht.
Wird alles beim Peering autmatisch gesetzt. (peerChan)