Hallo liebe Leute,
habe seit gestern mit anderem HM- Geraffel u.a. auch so eine Kombi erhalten.
Um gleich zur Sache zu kommen: Ich bekomme das Ding einfach nicht ordentlich gepairt >:( >:( >:(
Ungezählte Pearingversuche, mit und ohne Factory- Reset, mit und ohne Löschen des Codes in der CFG, mit direktem Pearing via HMid, ... Nichts hilft.
Das Höchste der Gefühle ist ein "R-pairCentral set_0xF10000". Darüber geht es nicht hinaus. Auch ein getConfig endet mit z.B. "protCmdPend 9 CMDs pending" und einem "state MISSING ACK". Auch das "in Ruhe lassen" über Nacht hat darin rein gar nichts geändert.
Mache ich da wieder mal was falsch? Kann ich mir nicht vorstellen; die anderen 5 HM- Geräte haben ja auch schmerzfrei funktioniert und Martin hat mich ja oft genug getriggert ;)
Könnte es sein, das dieses Teil ne Macke hat?
Hier mal der aktuelle List:
Internals:
CFGFN /opt/fhem/tastdimm.cfg
DEF 4A1975
IODev SCC2
LASTInputDev SCC2
MSGCNT 4
NAME HM4TB1
NR 198
SCC2_MSGCNT 4
SCC2_RAWMSG A1A0784004A1975F100001100DB4D45513138343936373981230000::-48:SCC2
SCC2_RSSI -48
SCC2_TIME 2016-06-04 14:20:24
STATE MISSING ACK
TYPE CUL_HM
channel_01 HM4TB1_1
channel_02 HM4TB1_2
channel_03 HM4TB1_3
lastMsg No:07 - t:00 s:4A1975 d:F10000 1100DB4D45513138343936373981230000
protCmdDel 10
protLastRcv 2016-06-04 14:20:24
protResnd 3 last_at:2016-06-04 14:19:28
protResndFail 1 last_at:2016-06-04 14:20:28
protSnd 6 last_at:2016-06-04 14:20:24
protState CMDs_done_Errors:1
rssi_at_SCC2 avg:-46.75 lst:-48 max:-45 min:-48 cnt:4
Readings:
2016-06-04 14:09:57 CommandAccepted yes
2016-06-04 14:20:24 D-firmware 1.1
2016-06-04 14:20:24 D-serialNr MEQ1849679
2016-06-04 14:09:56 R-pairCentral set_0xF10000
2016-06-04 14:20:28 state MISSING ACK
Helper:
HM_CMDNR 8
cSnd 01F100004A197500050000000000,01F100004A197500050000000000
mId 00DB
rxType 28
Expert:
def 1
det 0
raw 1
tpl 0
Io:
newChn +4A1975,00,00,00
nextSend 1465042824.90882
prefIO
rxt 2
vccu
p:
4A1975
00
00
00
Mrssi:
mNo 07
Io:
SCC2 -46
Prt:
bErr 0
mmcS 1
sProc 0
mmcA:
++A001F100004A197500050000000000
Q:
qReqConf
qReqStat
Role:
dev 1
Rssi:
At_scc2:
avg -46.75
cnt 4
lst -48
max -45
min -48
Shadowreg:
RegL_00. 02:01 0A:F1 0B:00 0C:00
Tmpl:
Attributes:
IODev SCC2
alias Taster / PIR
autoReadReg 4_reqStatus
expert 2_raw
firmware 1.1
group Sensoren
model HM-Sen-MDIR-WM55
msgRepeat 3
room EG.Schlafzimmer
serialNr MEQ1849679
sortby 30
subType motionAndBtn
webCmd getConfig:clear msgEvents
ZitatlastMsg No:07 - t:00 s:4A1975 d:F10000 1100DB4D45513138343936373981230000
von der last Msg, hat er das R-pairCentral set_0xF10000 angenommen,
hast du nicht bereits das hm-lan ufo daheim? den SCC2 hätte ich schon lange entsorgt,
Zitat von: fhem-hm-knecht am 04 Juni 2016, 14:43:33von der last Msg, hat er das R-pairCentral set_0xF10000 angenommen,
Jupp, aber weiter geht's halt ums verrecken nicht. Die anderen "Neugeräte" (3 x HM-LC-Dim1TPBU-FM, 2 x HM-PB-6-WM55, 3 x HM-PB-2-WM55) haben problemlos funktioniert, also sollte man meinen, das so'n schnödes Psselding auch tut ...
Zitat von: fhem-hm-knecht am 04 Juni 2016, 14:43:33hast du nicht bereits das hm-lan ufo daheim? den SCC2 hätte ich schon lange entsorgt,
Ja, aber durch die Masse der parallelen Baustellen hier bin ich noch nicht mit meinem PoE für das Ufo weiter gekommen ...
Das pairing ist nicht verifiziert. Also getconfig. Wenn es mit scc nicht funktioniert muss hmlan ran.
Hi,
hast Du mal den hinteren Knopf gedrückt?
Gruß,
Thorsten
@Thorsten: Na klar, bestimmt inzwischen gefühlte 1000 mal ...
@Martin: Tja, GetConfig läuft wie gesagt auf jede Menge "CMD's pending" und solche Sachen wir "MISSING ACK" oder "TimeOut reading Register" u.ä. ... Ich werde wohl das Projekt PoE für das UFO erstmal aufschieben und das Ding mal provisorisch in betrieb nehmen müssen. Mal sehen, ob es damit besser resp. überhaupt funktioniert...
... so ... Das UFO ist erstmal provisorisch in Betrieb gegangen. Hat aber anfänglich auch nicht wirklich funktioniert. Erst der 2. oder 3. Neustart des UFO brachte dann den gewünschten Erfolg, warum auch immer.
Allerdings weiß ich nun, wie schnell die 1% Grenze erreicht ist >:( Ein paar mal GetConfig und schon ist Schulz... Das Problem hatte ich mit dem SCC nie...
Ist zwar bestimmt schon 1000 mal gefragt worden, aber ich tue es zum 1001. mal: Kann man irgendwie per Hard- oder Software-Hack diese 1% Regel zumindest im UFO lahm legen? Das nervt ungemein, wenn man gerade ein Problemkind in Gang bringen will und das UFO mittendrin den Sendebetrieb einstellt ... Ich verstehe die BNA sowieso nicht; mit jedem anderen Proto kann ich senden bis die Nase glüht. Da jukt es niemanden, wenn ein z.B. IT-Sender 24/7 einen Träger setzt....
Dazu noch eine Frage: Könnte ich das UFO und den SCC parallel betreiben, so das der SCC den Sendebetrieb und das UFO den Empfangsbetrieb beim Testen übernimmt und im normalem Betrieb beide nach RSSI Prio senden?
Zitat von: M_I_B am 06 Juni 2016, 08:16:25
Ist zwar bestimmt schon 1000 mal gefragt worden, aber ich tue es zum 1001. mal: Kann man irgendwie per Hard- oder Software-Hack diese 1% Regel zumindest im UFO lahm legen?
Nein. Und das ist sehr gut so.
Zitat von: M_I_B am 06 Juni 2016, 08:16:25
Dazu noch eine Frage: Könnte ich das UFO und den SCC parallel betreiben, so das der SCC den Sendebetrieb und das UFO den Empfangsbetrieb beim Testen übernimmt und im normalem Betrieb beide nach RSSI Prio senden?
Schau dir VCCU an.
Zitat von: marvin78 am 06 Juni 2016, 08:20:10Nein. Und das ist sehr gut so.
"Nein" ist schon mal ne Antwort die ich ungern höre ::)
Aber mach mich mal schlau, warum das d.E. "gut so" ist? Ich sehe da nichts gutes dran... Im "Normalbetrieb" werden die 1% i.d.R. nicht erreicht, also spielt es da eh keine Rolle. Aber wenn z.B. kurz vor einem "Gefahrenfall" das Limit erreicht ist und im Gefahrenfall nicht mehr gesendet wird (Einbruch-, Feuer-, Gasalarm / Schließen von Feuertüren und Fenstern / Einschalten von Licht und Alarmgebern / ...), ist das eine ziemlich "unschöne" Situation.
Zitat von: marvin78 am 06 Juni 2016, 08:20:10Schau dir VCCU an.
Jo, danke. Mache ich
Zitat von: M_I_B am 06 Juni 2016, 08:29:35
"Nein" ist schon mal ne Antwort die ich ungern höre ::)
Aber mach mich mal schlau, warum das d.E. "gut so" ist?
Ganz einfach gesagt: Weil es vom Regulierer so vorgeschrieben ist. Etwas komplizierter ausgedrückt (und auch die Erklärung, warum ich es "gut so" finde): http://fhemwiki.de/wiki/1%25_Regel (http://fhemwiki.de/wiki/1%25_Regel) (es geht dabei um effektive Nutzung mehrerer Teilnehmer - gäbe es die Regel nicht, würde ggf. auf kurz oder lang in gewissen Haushalten nichts mehr funktionieren). Hättest du die Möglichkeit, die Regel auf zu heben (die du faktisch hast - mehr dazu findest du sicher hier im Forum - das Nein, war das offizielle Nein), wäre Chaos in gewissen Wohnbedingungen vorprogrammiert.
Zitat von: marvin78 am 06 Juni 2016, 09:28:05gäbe es die Regel nicht, würde ggf. auf kurz oder lang in gewissen Haushalten nichts mehr funktionieren
Naja... ich denke (und stütze mich da auf berufliche Erfahrungswerte), wenn die Regel eine "10% Regel" wäre, würde das immer noch auch bei großen Installationen problemlos funktionieren. ABer es ist müßig, sich darüber zu streiten, da die Regel nun mal existiert ...
Zitat von: marvin78 am 06 Juni 2016, 09:28:05... die Regel auf zu heben (die du faktisch hast - mehr dazu findest du sicher hier im Forum ...
Ja, Stecker ziehen... Das war das Einzige, was ich hier im Forum finden konnte. Bei einer fertigen Installation eher unpraktisch resp. nicht durchführbar, wenn niemand vor Ort ist. Oder habe ich falsch gesucht? Wenn ja, stoß mich doch bitte mal mit der Nase drauf... Denn wenn ich 3-4 mal ein Reload Config mache, ist schon Schicht im Schacht. Im Moment habe ich mir damit geholfen, das ich vor das Netzteil des UFO eine IT-Steckdose gesetzt habe; bei IT gibt es solch eine Regel zum Glück nicht ^^
Statt Stecker ziehen kannst Du den HMLAN auch booten (https://forum.fhem.de/index.php/topic,38708.0.html) ;)
Aber das 3-4x reload/restart einen Overload auslösen habe ich bei mir noch nicht festgestellt.
Zitat von: dev0 am 10 Juni 2016, 09:41:40Statt Stecker ziehen kannst Du den HMLAN auch booten (https://forum.fhem.de/index.php/topic,38708.0.html) ;)
Du hast Dir heute den Titel "Mein Held des Tages" verdient ;D ;D ;D Habe ich über die SuFu nicht finden können... Dann bau ich mal ne Automatik zusammen ;)
Zitat von: dev0 am 10 Juni 2016, 09:41:40Aber das 3-4x reload/restart einen Overload auslösen habe ich bei mir noch nicht festgestellt.
Naja, das war jetzt vielleicht etwas übertrieben und die Anzahl aus den Fingern gesogen, aber oft kann ich einen Reload nicht machen. Das ist mir die vergangenen Tage oft passiert; ich mach mal eine Strichliste ...
... noch mal zum Thema "Aber das 3-4x reload/restart einen Overload auslösen habe ich bei mir noch nicht festgestellt." ...
Das sieht dann z.B. so aus:
2016.06.12 23:09:25.568 1: HMLAN_Parse: UFO1 new condition ok
2016.06.12 23:09:36.529 1: HMLAN_Parse: UFO1 new condition Warning-HighLoad
2016.06.12 23:09:51.688 1: HMLAN_Parse: UFO1 new condition ERROR-Overload
2016.06.12 23:10:09.166 1: 192.168.1.198:1000 disconnected, waiting to reappear (UFO1) ### ab hier zieht die Reset-Automatik
2016.06.12 23:10:09.176 1: HMLAN_Parse: UFO1 new condition disconnected
2016.06.12 23:10:09.403 1: 192.168.1.198:1000 reappeared (UFO1)
2016.06.12 23:10:09.411 1: HMLAN_Parse: UFO1 new condition init
2016.06.12 23:10:09.658 1: HMLAN_Parse: UFO1 new condition ok