Hallo zusammen,
ich habe ein Problem mit dem HM-Mod-Re-8 Device.
Ich habe das Device an FHEM angelernt (über CUL), es wird erkannt und ein manuelles Setzen/Rücksetzen der einzelnen Ausgänge funktioniert und wird in der Weboberfläche auch entsprechend angezeigt. Die Kommunikation zwischen dem Device und FHEM scheint also grundsätzlich zu funktionieren.
Wenn ich allerdings versuche die Ausgänge über FHEM zu schalten, scheinen die Befehle nicht anzukommen. Es passiert erst mal nichts und ich bekomme MISSING ACK als Status angezeigt.
Auch das Setzen oder Auslesen der Register klappt nicht richtig. Wenn ich ein set regSet ... oder ein getConfig absetze bekomme ich eine Timeout Meldung als Status.
Was eigenartig ist, ist dass dann, wenn ich den Status manuelle aus und einschalte, und danach ein set on oder set off absetzte es einmal funktioniert.
Irgendeine Idee was das sein könnte, für mich sieht es so aus, als ob das Aufwecken per Burst irgendwie nicht funktioniert, also entweder kein Burst gesendet wird, oder das Device nicht richtig darauf reagiert.
Hallo,
habe das Modul am Laufen und hatte gestern (nach 2 Monatigem erfolgreichem Betrieb) ein ähnliches Phänomen. Ursache war eine schwache Batterie. Nach Austausch der Batterie war wieder alles gut.
Gruß Udo
Danke für den Hinweis, aber so einfach ist es bei mir leider nicht. Ich betreibe das Teil an einem Netzteil.
Zitat von: eki am 16 Juni 2015, 12:50:52
Danke für den Hinweis, aber so einfach ist es bei mir leider nicht. Ich betreibe das Teil an einem Netzteil.
und kommt auch genug Spannung an?
Antenne gut abgeschirmt?
Wie eingangs bereits gesagt, die Kommunikation mit dem CUL scheint ja prinzipiell zu funktionieren, wenn ich manuell schalte, bekommt das FHEM mit und ändert den Status. Werden denn die Bursts anders gesendet als normale Nachrichten (weniger Leistung oder so was)?
bei mir war es so (... die schlechte Batterie ...), dass ich über meine gepeerte Fernbedienung einen Befehlt abgesetzt hatte. Dieser Befehl wurd von Fhem erkannt (event sichtbar). Aber geschaltet hat es nicht. Desweiteren konnte ich ein set <HM-Mod-Re-8_channel1> on absetzen. diesen Befehl habe ich im WEBUI gesehen. Aber nichts passiert.
Desweiteren konnte ich erfolgreich ein getConfig auf dem HM-Mod-Re-8 machen. Der Befehl wurde im WEBUI im HM-Mod-Re-8 abgearbeitet .... bis die Queue leer war. ABER: Trotzdem hat das Ding nicht mehr geschaltet, weil die Batterie leer war.
Muss natürlich nicht bei dir auch so sein, aber könnte
Hier noch ein Log mit verbose 5:
2015.06.16 20:21:30 5: CUL_HM HM_353DBF protEvent:CMDs_done
2015.06.16 20:21:36 5: CUL_HM HM_353DBF protEvent:CMDs_pending pending:1
2015.06.16 20:21:36 3: CUL_HM set HM_353DBF_Sw_01 on
2015.06.16 20:21:36 5: CUL_HM HM_353DBF protEvent:CMDs_processing... pending:0
2015.06.16 20:21:39 4: CUL_HM_Resend: HM_353DBF nr 2
2015.06.16 20:21:44 5: CUL_HM HM_353DBF protEvent:CMDs_done_Errors:1
2015.06.16 20:21:47 3: CUL_HM HM_353DBF_Sw_01 repeat, level 00 instead of C8
2015.06.16 20:21:47 5: CUL_HM HM_353DBF protEvent:CMDs_pending pending:1
2015.06.16 20:21:47 5: CUL_HM HM_353DBF protEvent:CMDs_processing... pending:0
2015.06.16 20:21:51 4: CUL_HM_Resend: HM_353DBF nr 2
2015.06.16 20:21:53 3: CUL_HM HM_353DBF_Sw_01 repeat, level 00 instead of C8
2015.06.16 20:21:56 5: CUL_HM HM_353DBF protEvent:CMDs_done_Errors:1
2015.06.16 20:24:42 5: CUL_HM HM_353DBF protEvent:CMDs_done
2015.06.16 20:25:09 5: CUL_HM HM_353DBF protEvent:CMDs_done
2015.06.16 20:26:04 5: CUL_HM HM_353DBF protEvent:CMDs_pending pending:1
2015.06.16 20:26:04 3: CUL_HM set HM_353DBF_Sw_01 on
2015.06.16 20:26:04 5: CUL_HM HM_353DBF protEvent:CMDs_processing... pending:0
2015.06.16 20:26:07 4: CUL_HM_Resend: HM_353DBF nr 2
2015.06.16 20:26:07 3: CUL_HM set HM_353DBF_Sw_01 on
2015.06.16 20:26:12 3: CUL_HM set HM_353DBF_Sw_02 on
2015.06.16 20:26:12 5: CUL_HM HM_353DBF protEvent:CMDs_done_Errors:1
2015.06.16 20:26:34 3: CUL_HM HM_353DBF_Sw_01 repeat, level 00 instead of C8
2015.06.16 20:26:34 5: CUL_HM HM_353DBF protEvent:CMDs_pending pending:1
2015.06.16 20:26:34 5: CUL_HM HM_353DBF protEvent:CMDs_processing... pending:0
2015.06.16 20:26:37 3: CUL_HM HM_353DBF_Sw_01 repeat, level 00 instead of C8
2015.06.16 20:26:37 4: CUL_HM_Resend: HM_353DBF nr 2
2015.06.16 20:26:37 4: CUL_HM HM_353DBF dupe: repeat 2 ack, dont process
2015.06.16 20:26:40 3: CUL_HM HM_353DBF_Sw_02 repeat, level 00 instead of C8
2015.06.16 20:26:40 5: CUL_HM HM_353DBF protEvent:CMDs_processing... pending:1
2015.06.16 20:26:42 5: CUL_HM HM_353DBF protEvent:CMDs_processing... pending:1
2015.06.16 20:26:42 5: CUL_HM HM_353DBF protEvent:CMDs_done_Errors:1
2015.06.16 20:28:14 5: CUL_HM HM_353DBF protEvent:CMDs_done
Cool waere rohmessages zu sniffen, siehe wiki.
Waere nicht ueberrascht, wenn das device eine message trotz falscher source verarbeitet, danach aber nicht mehr. Ist korrekt gepairt ? Immer die erste Frage.
OK, Rohmessages kann ich machen. Worauf muss ich denn schauen um zu erkennen, ob "richtig gepairt" ist.
Ich verstehe das so, dass FHEM den Status des Moduls immer mitbekommt (beim Schalten am Modul direkt), aber selbst nicht steuern kann...
Ist der Re8 wirklich sauber gepairt? Das Device kann nämlich per Autocreate oder manuell angelegt sein und liest alle gemeldeten Stati des Moduls mit, ohne dass ein Pairing erfolgreich gewesen sein muss. Das Reading pairCentral (o.ä., habs nicht im Kopf) muss die ID des CUL tragen und darf auch nicht mit set_ anfangen. ..
Sonst Pairing einfach wiederholen.
geht nich Gips nich ...
Danke für den Hinweis. Ich habe autocreate verwendet, allerdings steht das Reading R-pairCentral auf set_... . Ich werde nochmal versuchen zu pairen (habe ich aber schon einige Male gemacht.
Dann ist das die Ursache. Das Modul zum Pairen zu überreden ist etwas tricky. Versuche es mit der Taste des Kanals 1 (>4 Sekunden lang drücken) NACHDEM Du den Pairmodus am CUL aktiviert hast. Das Pairen mit Seriennummer ist hier nicht so zuverlässig, komisch. Erfolgreiches Pairen müsste das Modul durch ein schnelleres Blinken anzeigen (bin nicht ganz sicher).
Es kann sein, dass die Register erst nach einem neuen getConfig vollständig gelesen wurden, inkl. pairCentral. Mache das also vorsichtig und wechselseitig - und beachte, dass das Re-8 ein Burstgerät ist und den CUL schnell ans Sendelimit bringt, was eine weitere Fehlerquelle für ein missglücktes Pairen sein kann...
Zitatden CUL schnell ans Sendelimit bringt
glaube ich nicht. ;)
Zitat von: frank am 18 Juni 2015, 13:30:25
glaube ich nicht. ;)
Muss auch nicht. Aber mit einem getConfig auf das Device kriege ich mit dem Schwestermodul EM-8 (Sender) mit all seinen Einstellungsmöglichkeiten spätestens beim zweiten Versuch den HMLAN zuverlässig ins Sendelimit. Habs deswegen auch ins Wiki geschrieben.
Zitatden HMLAN zuverlässig ins Sendelimit
das glaube ich schon.
ein cul hat eben auch vorteile. ;)
So, hier sind jetzt die rawmessages. Ich habe die entsprechenden settings in global und CUL gemacht und dann ein Anlernen mit anschließendem getConfig und set on set off gemacht und danach manuell ein und ausgeschaltet (alles mit Kanal 01).
2015.06.18 21:04:01.299 4: CUL_Parse: CUL1 A 0F DD 8610 22374F 000000 0AA8F10C001F0B -68.5
2015.06.18 21:04:12.797 4: CUL_Parse: CUL1 A 0F 80 8610 33B15E 000000 0A98F90F00000F -66.5
2015.06.18 21:04:20.992 4: CUL_Parse: CUL1 A 1A 0F 8400 353DBF 000000 1000BE4C455131353231373537104801000B -68.5
2015.06.18 21:04:21.095 4: CUL_send: CUL1As 10 10 A001 F11234 353DBF 00050000000000
2015.06.18 21:04:21.248 4: CUL_Parse: CUL1 A 0A 10 8002 353DBF F11234 000C -68
2015.06.18 21:04:21.350 4: CUL_send: CUL1As 13 11 A001 F11234 353DBF 000802010AF10B120C34
2015.06.18 21:04:21.505 4: CUL_Parse: CUL1 A 0A 11 8002 353DBF F11234 000F -66.5
2015.06.18 21:04:21.607 4: CUL_send: CUL1As 0B 12 A001 F11234 353DBF 0006
2015.06.18 21:04:21.755 4: CUL_Parse: CUL1 A 0A 12 8002 353DBF F11234 000A -69
2015.06.18 21:04:23.930 4: CUL_Parse: CUL1 A 14 9C 845E 314945 000000 87E12200017F00210931FAF7 -78.5
2015.06.18 21:04:52.534 4: CUL_send: CUL1As 10 13 B001 F11234 353DBF 00040000000000
2015.06.18 21:04:57.772 4: CUL_send: CUL1As 10 13 B001 F11234 353DBF 00040000000000
2015.06.18 21:05:14.680 4: CUL_send: CUL1As 0E 14 B011 F11234 353DBF 0201C80000
2015.06.18 21:05:19.062 4: CUL_send: CUL1As 0E 14 B011 F11234 353DBF 0201C80000
2015.06.18 21:06:27.930 4: CUL_Parse: CUL1 A 14 9D 845E 314945 000000 87E12300018000210932FAF3 -80.5
2015.06.18 21:06:32.798 4: CUL_Parse: CUL1 A 0F 81 8610 33B15E 000000 0A98F90F00000F -66.5
2015.06.18 21:06:53.299 4: CUL_Parse: CUL1 A 0F DE 8610 22374F 000000 0AA8F10C001F0C -68
2015.06.18 21:08:38.300 4: CUL_Parse: CUL1 A 0F 82 8610 33B15E 000000 0A98F90F00000F -66.5
2015.06.18 21:09:21.431 4: CUL_Parse: CUL1 A 14 9E 845E 314945 000000 87E12500017F00210932FAF5 -79.5
2015.06.18 21:09:30.800 4: CUL_Parse: CUL1 A 0F DF 8610 22374F 000000 0AA8F10C001F0D -67.5
2015.06.18 21:10:59.358 4: CUL_Parse: CUL1 A 0D 14 A410 353DBF F11234 0601C80011 -65.5
2015.06.18 21:10:59.461 4: CUL_send: CUL1As 0E 15 A011 F11234 353DBF 0201000000
2015.06.18 21:10:59.483 4: CUL_send: CUL1As 0A 14 8002 F11234 353DBF 00
2015.06.18 21:11:02.166 4: CUL_send: CUL1As 0E 15 B011 F11234 353DBF 0201000000
2015.06.18 21:11:05.651 4: CUL_Parse: CUL1 A 0D 16 A410 353DBF F11234 0601C8000F -66.5
2015.06.18 21:11:05.754 4: CUL_send: CUL1As 0A 16 8002 F11234 353DBF 00
2015.06.18 21:11:33.550 4: CUL_Parse: CUL1 A 0F 83 8610 33B15E 000000 0A98F90F00000F -66.5
2015.06.18 21:11:34.758 4: CUL_Parse: CUL1 A 0D 18 A410 353DBF F11234 0601000010 -66
2015.06.18 21:11:34.860 4: CUL_send: CUL1As 0A 18 8002 F11234 353DBF 00
Dad peeren hat funktioniert. Der burst funktioniert nicht. Ist die cul dazu in der lage ?
Ist die fw aktuell ?
Das war der entscheidende Hinweis. Ich habe die Neueste CUL FW installiert und jetzt laeuft alles wie es soll. Vielen Dank :).