neue 4 Tasten Fernbedienung HM-RC-4-2, HM-RC-Key4-2, HM-RC-Sec4-2

betateilchen · 05 Juni 2013, 19:29:32

Es geschehen noch Zeichen und Wunder :) Endlich eine grüne Bestätigung beim Knopfdrücken!


2013-06-05 19:28:12 HMLAN HMLAN RCV L:0B N:04 F:A4 CMD:40 SRC:HMFB01 DST:va 0101 (REMOTE BUTTON:1 LONG:0 LOWBAT:0 COUNTER:0x01) (,CFG,BIDI,RPTEN)
2013-06-05 19:28:12 HMLAN HMLAN SND L:0D N:04 F:80 CMD:02 SRC:va DST:HMFB01 0101C800 (ACK_STATUS CHANNEL:0x01 STATUS:0xC8 UP:0 DOWN:0 LOWBAT:0) (,RPTEN)
2013-06-05 19:28:12 CUL_HM HMFB01_01 Short (to va)
2013-06-05 19:28:12 CUL_HM HMFB01_01 trigger: Short_1
2013-06-05 19:28:12 CUL_HM va_Btn1 ON
2013-06-05 19:28:12 CUL_HM va_Btn1 virtActState: ON
2013-06-05 19:28:12 CUL_HM va_Btn1 virtActTrigger: HMFB01_01
2013-06-05 19:28:12 CUL_HM va_Btn1 virtActTrigType: short_Release
2013-06-05 19:28:12 CUL_HM va_Btn1 virtActTrigRpt: 1
2013-06-05 19:28:12 CUL_HM va_Btn1 virtActTrigNo: 1
2013-06-05 19:28:12 CUL_HM HMFB01 battery: ok

Aber die Peer-ID taucht beim Button immer noch nicht auf: (ist mir aber jetzt fast egal...)

Code Auswählen


Internals:
   CFGFN      
   DEF        2123FC01
   NAME       HMFB01_01
   NR         338
   NTFY_TRIGGERTIME 2013-06-05 19:28:12
   STATE      Short (to va)
   TYPE       CUL_HM
   chanNo     01
   device     HMFB01
   Readings:
     2013-06-05 19:27:07   R-dblPress      0 s
     2013-06-05 19:27:07   R-longPress     0.4 s
     2013-06-05 19:27:07   R-sign          off 
     2013-06-05 19:26:38   R-va_Btn1-expectAES set_off 
     2013-06-05 19:26:38   R-va_Btn1-peerNeedsBurst set_off 
     2013-06-05 19:27:07   RegL_01:          04:10 08:00 09:00 00:00
     2013-06-05 19:28:12   state           Short (to va)
     2013-06-05 19:28:12   trigger         Short_1
   Helper:
     peerIDsRaw ,00000000
     Role:
       chn        1
     Shadowreg:
       RegL_04:va_Btn1  01:00
Attributes:
   model      HM-RC-4-2
   peerIDs    00000000,
   room       CUL_HM

betateilchen · 05 Juni 2013, 21:29:49

Die Rückmeldung ist sehr unzuverlässig. Oft meldet die Fernbedienung nach einem Tastendruck rot und erst nach dem dritten oder vierten Versuch kommt ein Grün. Das Schlimme daran ist, dass die gepeerte Aktion vom virtuellen Aktor aber trotzdem ausgeführt wird, auch wenn eine "rote" Rückmeldung kommt.

Für mich sieht das irgendwie nach Timing-Problemen aus.

martinp876 · 06 Juni 2013, 09:24:47

Hi,

Line 3821 ist bekannt, unkritisch (RSSI berechnung), wird behoben.

ZitatUnd ein anschließendes getConfig ergibt 9 CMDs pending:

ist auch ok. Die Kommandos werden ja erst in die Queue gesteckt und muessen dort auf Anlernen warten - bei einer Remote.
Du kannst in FHEM ueber event-on-change einstellen, ob diese Meldungen nur bei Statusaeunderung kommen sollen. Siehe auch event-on-update

ZitatEin anschließendes getConfig ergibt wieder 9 pending CMDs.

auch logisch - oder? Wird immer kommen, wenn du commandos an die remote richtest - also alle Devices, die eben nicht sofort bedient werden koennen.

ZitatEs geschehen noch Zeichen und Wunder :) Endlich eine grüne Bestätigung beim Knopfdrücken!

na das ist ja schon einmal gut.

ZitatDie Rückmeldung ist sehr unzuverlässig...
Für mich sieht das irgendwie nach Timing-Problemen aus.

moeglich (warscheinlich), oder der Empfangspegel.

Schaue dir doch einmal die RSSI werden an.
Und jetzt das timing, setze :

attr global mseclog 1
attr global verbose 1
attr HMLAN loglevel 1

dann zeichne einige der Aktionen auf und schreibe dazu, wann die LED rot oder gruen war.
Gruss Martin

betateilchen · 06 Juni 2013, 17:57:02

Zitat von: martinp876 schrieb am Do, 06 Juni 2013 09:24Line 3821 ist bekannt, unkritisch

hab ich nach einem Blick in den Sourcecode auch so interpretiert :)

Zitat von: martinp876 schrieb am Do, 06 Juni 2013 09:24ist auch ok.
[...]
auch logisch - oder?

ich sag mal so: Ja, es ist logisch, wenn man die Philosophie von HomeMatic so genau kennt und so tief drinsteckt wie Du.

Für mein Verständnis hat mir bis gestern folgende wichtige Information gefehlt, die Du dann hier - nach meiner grundlegenden Verständnisfrage - gegeben hast:

Zitatset HMFB01 getConfig
#=> Daten werden uebertragen, sobald du anlernen kurz drueckst

Mit der commandref habe ich immer wieder mal das Problem, dass diese wohl von Entwicklern erstellt ist, die bei den Beschreibungen immer von ihrem vollständigen eigenen Hintergrundwissen ausgehen. Das ist zwar sachlich dann alles richtig beschrieben, aber es bedeutet nicht automatisch, dass damit jeder Anwender zurechtkommt. Da ich selbst meine Brötchen als Softwareentwickler verdiene (wenn auch in einem völlig anderen Fachbereich) kenne ich dieses "Problem" nur zu gut. Deshalb schreibe ich für von mir erstellte Programme schon seit ca. 10 Jahren keinerlei Anwenderdokumentationen mehr selbst, sondern überlasse das den technischen Redakteuren bei uns in der Firma, die den ganzen Tag nix anderes machen :)

Zitat von: martinp876 schrieb am Do, 06 Juni 2013 09:24moeglich (warscheinlich), oder der Empfangspegel.
Schaue dir doch einmal die RSSI werden an.

Empfangspegel schließe ich erstmal aus. Drei Meter Entfernung und freie Sicht zwischen HMLAN und Fernbedienung sollten keine Probleme machen.

Zitat von: martinp876 schrieb am Do, 06 Juni 2013 09:24Und jetzt das timing, setze :

attr global mseclog 1
attr global verbose 1
attr HMLAN loglevel 1

dann zeichne einige der Aktionen auf und schreibe dazu, wann die LED rot oder gruen war.

Werde ich heute abend machen und die Ergebnisse mitteilen.

Danke & Gruß
Udo

betateilchen · 06 Juni 2013, 18:12:51

Code Auswählen


grün:

2013-06-06 18:05:21.525 CUL_HM HMFB01_02 Short (to va)
2013-06-06 18:05:21.525 CUL_HM HMFB01_02 trigger: Short_16
2013-06-06 18:05:21.623 dummy wz_FHT_Soll 16
2013-06-06 18:05:21.672 dummy wz_FHT_Soll 16
2013-06-06 18:05:21.720 dummy wz_FHT_Soll 16
2013-06-06 18:05:21.768 dummy wz_FHT_Soll 16
2013-06-06 18:05:21.816 dummy wz_FHT_Soll 16
2013-06-06 18:05:21.864 dummy wz_FHT_Soll 16
2013-06-06 18:05:21.866 CUL_HM va_Btn2 ON
2013-06-06 18:05:21.866 CUL_HM va_Btn2 virtActState: ON
2013-06-06 18:05:21.866 CUL_HM va_Btn2 virtActTrigger: HMFB01_02
2013-06-06 18:05:21.866 CUL_HM va_Btn2 virtActTrigType: short_Release
2013-06-06 18:05:21.866 CUL_HM va_Btn2 virtActTrigRpt: 1
2013-06-06 18:05:21.866 CUL_HM va_Btn2 virtActTrigNo: 16
2013-06-06 18:05:21.912 CUL_HM HMFB01 battery: ok
2013-06-06 18:05:21.912 CUL_HM HMFB01 HMFB01_02 Short (to va)

rot:
2013-06-06 18:06:16.797 CUL_HM HMFB01_01 Short (to va)
2013-06-06 18:06:16.797 CUL_HM HMFB01_01 trigger: Short_18
2013-06-06 18:06:16.892 dummy wz_FHT_Soll 18
2013-06-06 18:06:16.941 dummy wz_FHT_Soll 18
2013-06-06 18:06:16.990 dummy wz_FHT_Soll 18
2013-06-06 18:06:17.038 dummy wz_FHT_Soll 18
2013-06-06 18:06:17.086 dummy wz_FHT_Soll 18
2013-06-06 18:06:17.134 dummy wz_FHT_Soll 18
2013-06-06 18:06:17.137 CUL_HM va_Btn1 OFF
2013-06-06 18:06:17.137 CUL_HM va_Btn1 virtActState: OFF
2013-06-06 18:06:17.137 CUL_HM va_Btn1 virtActTrigger: HMFB01_01
2013-06-06 18:06:17.137 CUL_HM va_Btn1 virtActTrigType: short_Release
2013-06-06 18:06:17.137 CUL_HM va_Btn1 virtActTrigRpt: 1
2013-06-06 18:06:17.137 CUL_HM va_Btn1 virtActTrigNo: 18
2013-06-06 18:06:17.183 CUL_HM HMFB01 battery: ok
2013-06-06 18:06:17.183 CUL_HM HMFB01 HMFB01_01 Short (to va)

rot:
2013-06-06 18:07:46.814 CUL_HM HMFB01_01 Short (to va)
2013-06-06 18:07:46.814 CUL_HM HMFB01_01 trigger: Short_20
2013-06-06 18:07:46.909 dummy wz_FHT_Soll 19
2013-06-06 18:07:46.958 dummy wz_FHT_Soll 19
2013-06-06 18:07:47.007 dummy wz_FHT_Soll 19
2013-06-06 18:07:47.054 dummy wz_FHT_Soll 19
2013-06-06 18:07:47.102 dummy wz_FHT_Soll 19
2013-06-06 18:07:47.150 dummy wz_FHT_Soll 19
2013-06-06 18:07:47.153 CUL_HM va_Btn1 OFF
2013-06-06 18:07:47.153 CUL_HM va_Btn1 virtActState: OFF
2013-06-06 18:07:47.153 CUL_HM va_Btn1 virtActTrigger: HMFB01_01
2013-06-06 18:07:47.153 CUL_HM va_Btn1 virtActTrigType: short_Release
2013-06-06 18:07:47.153 CUL_HM va_Btn1 virtActTrigRpt: 1
2013-06-06 18:07:47.153 CUL_HM va_Btn1 virtActTrigNo: 20
2013-06-06 18:07:47.199 CUL_HM HMFB01 battery: ok
2013-06-06 18:07:47.199 CUL_HM HMFB01 HMFB01_01 Short (to va)

rot:
2013-06-06 18:08:18.147 CUL_HM HMFB01_01 Short (to va)
2013-06-06 18:08:18.147 CUL_HM HMFB01_01 trigger: Short_21
2013-06-06 18:08:18.245 dummy wz_FHT_Soll 19
2013-06-06 18:08:18.294 dummy wz_FHT_Soll 19
2013-06-06 18:08:18.343 dummy wz_FHT_Soll 19
2013-06-06 18:08:18.391 dummy wz_FHT_Soll 19
2013-06-06 18:08:18.440 dummy wz_FHT_Soll 19
2013-06-06 18:08:18.489 dummy wz_FHT_Soll 19
2013-06-06 18:08:18.492 CUL_HM va_Btn1 ON
2013-06-06 18:08:18.492 CUL_HM va_Btn1 virtActState: ON
2013-06-06 18:08:18.492 CUL_HM va_Btn1 virtActTrigger: HMFB01_01
2013-06-06 18:08:18.492 CUL_HM va_Btn1 virtActTrigType: short_Release
2013-06-06 18:08:18.492 CUL_HM va_Btn1 virtActTrigRpt: 1
2013-06-06 18:08:18.492 CUL_HM va_Btn1 virtActTrigNo: 21
2013-06-06 18:08:18.538 CUL_HM HMFB01 battery: ok
2013-06-06 18:08:18.538 CUL_HM HMFB01 HMFB01_01 Short (to va)

grün:
2013-06-06 18:08:21.527 CUL_HM HMFB01_01 Short (to va)
2013-06-06 18:08:21.527 CUL_HM HMFB01_01 trigger: Short_22
2013-06-06 18:08:21.622 dummy wz_FHT_Soll 19
2013-06-06 18:08:21.670 dummy wz_FHT_Soll 19
2013-06-06 18:08:21.718 dummy wz_FHT_Soll 19
2013-06-06 18:08:21.766 dummy wz_FHT_Soll 19
2013-06-06 18:08:21.814 dummy wz_FHT_Soll 19
2013-06-06 18:08:21.862 dummy wz_FHT_Soll 19
2013-06-06 18:08:21.865 CUL_HM va_Btn1 OFF
2013-06-06 18:08:21.865 CUL_HM va_Btn1 virtActState: OFF
2013-06-06 18:08:21.865 CUL_HM va_Btn1 virtActTrigger: HMFB01_01
2013-06-06 18:08:21.865 CUL_HM va_Btn1 virtActTrigType: short_Release
2013-06-06 18:08:21.865 CUL_HM va_Btn1 virtActTrigRpt: 1
2013-06-06 18:08:21.865 CUL_HM va_Btn1 virtActTrigNo: 22
2013-06-06 18:08:21.912 CUL_HM HMFB01 battery: ok
2013-06-06 18:08:21.912 CUL_HM HMFB01 HMFB01_01 Short (to va)

grün:
2013-06-06 18:09:40.581 CUL_HM HMFB01_01 Short (to va)
2013-06-06 18:09:40.581 CUL_HM HMFB01_01 trigger: Short_23
2013-06-06 18:09:40.676 dummy wz_FHT_Soll 20
2013-06-06 18:09:40.724 dummy wz_FHT_Soll 20
2013-06-06 18:09:40.772 dummy wz_FHT_Soll 20
2013-06-06 18:09:40.820 dummy wz_FHT_Soll 20
2013-06-06 18:09:40.868 dummy wz_FHT_Soll 20
2013-06-06 18:09:40.916 dummy wz_FHT_Soll 20
2013-06-06 18:09:40.919 CUL_HM va_Btn1 ON
2013-06-06 18:09:40.919 CUL_HM va_Btn1 virtActState: ON
2013-06-06 18:09:40.919 CUL_HM va_Btn1 virtActTrigger: HMFB01_01
2013-06-06 18:09:40.919 CUL_HM va_Btn1 virtActTrigType: short_Release
2013-06-06 18:09:40.919 CUL_HM va_Btn1 virtActTrigRpt: 1
2013-06-06 18:09:40.919 CUL_HM va_Btn1 virtActTrigNo: 23
2013-06-06 18:09:40.964 CUL_HM HMFB01 battery: ok
2013-06-06 18:09:40.964 CUL_HM HMFB01 HMFB01_01 Short (to va)

Protokolldatei im Anhang.

martinp876 · 07 Juni 2013, 09:34:34

Hallo Udo,

Die Doku kann man sicher verbessern. Das Commandref sehe ich aber dennoch nicht als Referenz, nicht als Dokumentation im Sinne von Einfuehrung, Grundlagen Philosophie oder Archektur, weder FHEM noch HM. Daher habe ich anfaenglich den Anhang zum Einsteigerdoc fuer HM geschrieben - der sollte den HM Aspekt aus FHEM sicht darstellen. Ich empfehle jedem, es einmal zu ueberfliegen, zumindest wenn er etwas mehr machen will.
Verbessern kann man das sicher noch, einen technischen Redakteur habe ich leider nicht.
Wiki ist ein 2. Ansatz, beinhaltet aber mehr praktische Details und beantwortet m.E. keine Fragen zur Architektur. Hier habe ich die Hoffnung, dass die User genau aus ihrer Sicht beschreiben, quasi als technische Redakteure.

Deine Logs
Zum einen sind mehr Aktionen im Log als du auf gefuehrt hast, ist ok.

Timing: ist aus FHEM sicht ok und Praezise, leider nicht echtzeitfaehig.
Die Details (falls du etwas an der Tiefen interresse hast):
FHEM antwortet nach 100ms - ist beabsichtigt, man darf nicht zu schnell sein...
Wenn ich jetzt die von HMLAN gelieferten Zeitstempel umrechne ist zu sehen, dass FHEM einen mit einer Varianz von bis zu 75ms addiert. In diene Logs kann man sehr schoen sehen, dass delays bis 29ms erfolgreich beantwortet wurden. Der Delay mit 39 ms und hoeher ging schief.
Nachdenklich stimmt mich noch mehr, dass die Wiederhohlung der remote (praezise nach 250ms gesendet) mit ~350ms Verspaetung eintrifft. Deren Beantwortung ist demnach sinnlos, den zu diesen Zeitpunkt hat deine remote schon die 2. Wiederholung ins Feld geschickt.
Die 2. Wiederholung kommt dann mit nur noch ~80ms delay daher.

Das ganze ist zu erklaeren, da FHEM die erste Meldung komplett parsed und eine Antwort schickt. Das Parsen und die Anzahl der Notifes (auch fileLogs) sind verantwortlich fuer den Delay. Da die 2. Message nicht mehr geparst wird und somit auch keine Notifies abgeprueft werden geht alles viel schneller, wir holen wieder auf.

So, viel Hintergrund.
Du kannst einmal die wartezeit von 100ms reduzieren
00_HMLAN.pm zeile 330:

Code Auswählen

$hash->{helper}{nextSend}{$src} = gettimeofday() + 0.100;
auf

Code Auswählen

$hash->{helper}{nextSend}{$src} = gettimeofday() + 0.070;
Generell hatte ich mit kuerzeren Zeiten Probleme, es ist also keine generelle Loesung. Ich muss also versuchen, den Zeitstempel des HMLAN zu nutzen, um den ethernet/IO-delay zu eliminieren. Das kostet aber etwas Aufwand, dauert also.

Gruss
Martin

betateilchen · 07 Juni 2013, 11:15:50

Hallo Martin,

bitte nicht falsch verstehen: Meine Aussage zu commandref etc war keine Kritik an irgendjemandem persönlich, der sich die Mühe macht und die Zeit investiert, das überhaupt zu pflegen. Ganz im Gegenteil.
Und Deinen HomeMatic-Anhang werde ich mir in einer ruhigen Stunde noch einmal zu Gemüte führen. Irgendwie hatte ich den Einsteigerleitfaden mehr oder weniger bisher nur überflogen.

Ich habe jetzt testweise die von Dir vorgeschlagene Änderung im Timing eingebaut und bisher hatte ich keine rote Rückmeldung an der Fernbedienung mehr. Danke für diesen Vorschlag!
Ob es dadurch jetzt irgendwelche Auffälligkeiten an anderen hier eingesetzen HM-Komponenten gibt, werde ich beobachten.

Für mich funktioniert die neue Fernbedienung jedenfalls jetzt so wie ihr Einsatz auch geplant war und ich habe dabei viel gelernt.
Dann kann ich mich also in Kürze der nächsten HM-Baustelle (Rauchmelder) widmen.

martinp876 · 07 Juni 2013, 12:33:44

Hallo Udo,

konstruktive Kritik ist nie schlecht, ich denke ich habe es schon richtig verstanden. Ich wollte auch nur den Anspruch der Dokumentation klarlegen, jedenfalls meine Sicht der Level.

Das veraenderte Timing (reduzieren der 100ms) hat mir schon Probleme bereitet, werde ich also nicht generell einbauen. Das Timing aus dem HMLAN zu nehmen waere besser, aber leider ist ist es nicht ganz einfach eine Korrelation zum FHEMclock (sysTime) herzustellen. Ausserdem laufen die Uhren auseinander, wie ich in alten Logs gesehen habe. Wird eine Bastelei...

Gruss Martin

betateilchen · 07 Juni 2013, 16:08:46

Ich habe jetzt das Eiscafe-Wetter genutzt und mir bei einem leckeren Nussbecher Deine Homematic-Beschreibung nochmal zu Gemüte geführt. In der Kombination aus den Erfahrungen bei der FB-Inbetriebnahme und dieser Doku wurden mir dann doch noch einige Zusammenhänge klarer.

Eine Frage hab ich aber im Moment doch noch: Was verbirgt sich hinter der peerID 000000, die mir in den Attributen jedes Fernbedienungs-Channels zusätzlich zur peerID des va_Channels angezeigt wird?

Inzwischen hatte ich schon wieder ein paar rote Rückmeldungen, meistens dann, wenn die Fernbedienung länger nicht benutzt wurde und dann wieder einer der Buttons gedrückt wurde.

marc2 · 08 Juni 2013, 00:15:57

Moin !

Ich kann das Problem mit dem nicht/schlecht verarbeiteten ACK bei dieser Verbedienung
auch mit einem CUL und einem CUNO nachvollziehen. Der ACK wird nur innerhalb eines
ganz engen Radius von der FB erkannt/verarbeitet, wobei es beim CUL besser klappt als
beim CUNO.

Code Auswählen

2013.06.08 00:09:30.329 1: CUNO1: A0D8A800211223321237F01010000 -67.5
2013.06.08 00:09:30.341 1: CUNO1: A0B8AA04021237F1122330167 -59.5
2013.06.08 00:09:30.349 1: CUNO1: A0B8AA04021237F1122330167 -59.5
2013.06.08 00:09:33.709 1: CUNO1: A0B8BA44021237F1122330168 -54
2013.06.08 00:09:33.717 1: CUNO1: A0D8B800211223321237F0101C800 -67.5
2013.06.08 00:09:33.725 1: CUNO1: A0B8BA04021237F1122330168 -54
2013.06.08 00:09:33.745 1: CUNO1: A0B8BA04021237F1122330168 -54
2013.06.08 00:09:37.225 1: CUNO1: A0B8CA44021237F1122330169 -52
2013.06.08 00:09:37.233 1: CUNO1: A0D8C800211223321237F01010000 -64
2013.06.08 00:09:37.241 1: CUNO1: A0B8CA04021237F1122330169 -52
2013.06.08 00:09:37.249 1: CUNO1: A0CAE86701CCD3D00000000BC3C -41.5
2013.06.08 00:09:37.909 1: CUNO1: A0B8CA04021237F1122330169 -51.5
2013.06.08 00:09:40.885 1: CUNO1: A0B8DA44021237F112233016A -53.5
2013.06.08 00:09:40.893 1: CUNO1: A0D8D800211223321237F0101C800 -64
2013.06.08 00:09:40.901 1: CUNO1: A0B8DA04021237F112233016A -53.5
2013.06.08 00:09:40.985 1: CUNO1: A0B8DA04021237F112233016A -54
2013.06.08 00:09:44.785 1: CUNO1: A0B8EA44021237F112233016B -53.5
2013.06.08 00:09:44.793 1: CUNO1: A0D8E800211223321237F01010000 -64.5
2013.06.08 00:09:44.805 1: CUNO1: A0B8EA04021237F112233016B -52.5
2013.06.08 00:09:44.809 1: CUNO1: A0B8EA04021237F112233016B -50
2013.06.08 00:09:48.465 1: CUNO1: A0B8FA44021237F112233016C -58
2013.06.08 00:09:48.469 1: CUNO1: A0D8F800211223321237F0101C800 -65
2013.06.08 00:09:48.481 1: CUNO1: A0B8FA04021237F112233016C -59
2013.06.08 00:09:48.501 1: CUNO1: A0B8FA04021237F112233016C -59
2013.06.08 00:09:52.209 1: CUNO1: A0B90A44021237F112233016D -63.5
2013.06.08 00:09:52.217 1: CUNO1: A0D90800211223321237F01010000 -63.5
2013.06.08 00:09:52.229 1: CUNO1: A0B90A04021237F112233016D -63.5
2013.06.08 00:09:52.249 1: CUNO1: A0B90A04021237F112233016D -63.5
2013.06.08 00:09:55.801 1: CUNO1: A0B91A44021237F112233016E -65
2013.06.08 00:09:55.809 1: CUNO1: A0D91800211223321237F0101C800 -63.5
2013.06.08 00:09:55.817 1: CUNO1: A0B91A04021237F112233016E -65
2013.06.08 00:09:55.825 1: CUNO1: A0B91A04021237F112233016E -65
2013.06.08 00:09:59.433 1: CUNO1: A0B92A44021237F112233016F -63.5
2013.06.08 00:09:59.441 1: CUNO1: A0D92800211223321237F01010000 -66
2013.06.08 00:09:59.449 1: CUNO1: A0B92A04021237F112233016F -61.5
2013.06.08 00:09:59.469 1: CUNO1: A0B92A04021237F112233016F -61.5
2013.06.08 00:10:03.017 1: CUNO1: A0B93A44021237F1122330170 -51.5
2013.06.08 00:10:03.025 1: CUNO1: A0D93800211223321237F0101C800 -66
2013.06.08 00:10:03.033 1: CUNO1: A0B93A04021237F1122330170 -48
2013.06.08 00:10:03.041 1: CUNO1: A0B93A04021237F1122330170 -45.5
2013.06.08 00:10:47.153 1: CUNO1: A0C2F86701AC26A00000000CA3E -59.5

Gruß, Marc

marc2 · 08 Juni 2013, 00:25:10

Hi !

Ich habe den zweiten Button der FB eben noch einmal mit einem realen Schalter gepeert (
HM-LC-Sw1PBU-FM). Hier klappt es wunderbar. Scheint also wirklich ein Timingproblem
mit FHEM zu sein. Da ich Devices aber eh direkt schalten will und FHEM an dieser
Stelle nur nutze, um das Peering zu definieren, bin ich glücklich :-)

Gruß, Marc

Dextha · 08 Juni 2013, 09:15:11

Hallo,

ich hab mir auch einen HM-RC-4-2 besorgt und diesen mit auto-create in FHEM eingebunden:

Code Auswählen


define CUL_HM_ID_00A0_212322 CUL_HM 212322
attr CUL_HM_ID_00A0_212322 .devInfo 040000
attr CUL_HM_ID_00A0_212322 .stc 40
attr CUL_HM_ID_00A0_212322 firmware 1.0
attr CUL_HM_ID_00A0_212322 model unknown
attr CUL_HM_ID_00A0_212322 room CUL_HM
attr CUL_HM_ID_00A0_212322 serialNr KEQ0111704
attr CUL_HM_ID_00A0_212322 subType 
define FileLog_CUL_HM_ID_00A0_212322 FileLog ./log/CUL_HM_ID_00A0_212322-%Y.log CUL_HM_ID_00A0_212322
attr FileLog_CUL_HM_ID_00A0_212322 logtype text
attr FileLog_CUL_HM_ID_00A0_212322 room CUL_HM

Jedoch funktioniert der Handsender in FHEM dann nicht :-(
Wie hast du den Handsender in FHEM angelegt?

LG. Dextha

marc2 · 08 Juni 2013, 12:17:09

Hallo Dextha !

Hast Du den Rest des Threads gelesen ? Offensichtlich hast Du die Erweiterung in der HMConfig.pm
nicht vorgenommen und deswegen kann FHEM mit der FB nichts anfangen:

Code Auswählen

attr CUL_HM_ID_00A0_212322 model unknown

Der HM-RC-4-2 ist recht neu, Martin hat die Änderung nocht nicht im SVN eigecheckt. Wird er sicher
bald tun. Bis dahin musst Du die eine Zeile von Hand in die HCMConfig.pm eintragen, FHEM neu starten
und die FB neu mit FHEM pairen.

Gruß, Mar

betateilchen · 08 Juni 2013, 20:27:19

Wie werde ich denn nach den vielen Experimenten hier im Thread diese vielen Logeinträge wieder los:

Code Auswählen


2013.06.08 20:23:31 1: HMLAN_Send: ...
2013.06.08 20:23:31 1: HMLAN_Parse: ...

Welchen loglevel oder welchen verbose muss ich da anpacken?

Dextha · 08 Juni 2013, 20:28:43

Jetzt gings.... hatte die Zeile scheinbar an der falschen Stelle oder falsch drin....

Danke!