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

[betateilchen]

Könnte man über einen (vermutlich neu zu schaffenden) Parameter/Attribut/was-auch-immer eine Möglichkeit schaffen, einfach eine Bestätigung an eine eingehende ID zurückzuschicken? Gerade bei Fernbedienungen ist es doch oft so, dass man einfach einen Button auf der Fernbedienung per notify auswerten möchte, um irgendwie zu reagieren.

Mir schwebt da gedanklich etwas in der Art vor:

Code Auswählen Erweitern


attr hmcfgusb forceAck 0x112233  <<< 112233 = HMID der Fernbedienung (oder des Channels, dann eben 8-stellig), immer wenn was von dieser ID kommt, einfach ein GRÜN schicken, damit der Empfang des Knopfdrucks bestätigt wird.


Ich weiß, es ist noch nicht Weihnachten, aber Wünsche darf man ja haben. Ich habe die Fernbedienung einzig und allein aus dem Grund angeschafft, eine zuverlässige optische Rückmeldung zu erhalten, wenn ich einen Knopf drücke, um zu wissen, dass das Kommando bei FHEM angekommen ist. Dann könnte ich mir auch das ganze Rumgeeiere mit virtuellem Aktor etc. sparen.

[mgernoth]

Hallo Betateilchen,

Aber die gepairte Fernbedienung schickt doch keine unadressierten Pakete. Die sind doch an den USB-Stick gerichtet.

Nein, die sind an den virtuellen Aktor gerichtet.

Und wenn es gar keinen virtuellen Aktor gibt?

Dann gehen sie an die Broadcast-Adresse und die Fernbedienung erwartet gar keine Rückmeldung.

Könnte man über einen (vermutlich neu zu schaffenden) Parameter/Attribut/was-auch-immer eine Möglichkeit schaffen, einfach eine Bestätigung an eine eingehende ID zurückzuschicken? Gerade bei Fernbedienungen ist es doch oft so, dass man einfach einen Button auf der Fernbedienung per notify auswerten möchte, um irgendwie zu reagieren.

Ja, Du hast soeben den virtuellen Aktor neu erfunden ;-)

Mir schwebt da gedanklich etwas in der Art vor:

attr hmcfgusb forceAck 0x112233  <<< 112233 = HMID der Fernbedienung (oder des Channels, dann eben 8-stellig), immer wenn was von dieser ID kommt, einfach ein GRÜN schicken, damit der Empfang des Knopfdrucks bestätigt wird.

Soweit bisher bekannt, kann man das der Firmware des Sticks/HMLAN nicht so beibringen. Die Antwortet _nur_ auf Pakete an die eigene Adresse, nicht auf alle Pakete einer bestimmten ID.

Btw: Der Kernel 3.3.8 bootet nicht mit meinem Raspbian, kann also leider nicht sagen, ob es damit besser waere...

Gruß
  Michael

[betateilchen]

Hallo Michael,

Hallo Betateilchen,

Aber die gepairte Fernbedienung schickt doch keine unadressierten Pakete. Die sind doch an den USB-Stick gerichtet.

Nein, die sind an den virtuellen Aktor gerichtet.

Und wenn es gar keinen virtuellen Aktor gibt?

Dann gehen sie an die Broadcast-Adresse und die Fernbedienung erwartet gar keine Rückmeldung.

Das ist aber komisch...

Code Auswählen Erweitern

2013-07-06 17:52:28 CUL_HM HMFB01_03 Short (to HMUSB)
2013-07-06 17:52:28 CUL_HM HMFB01_03 trigger: Short_10
2013-07-06 17:52:28 CUL_HM HMFB01 battery: ok
2013-07-06 17:52:28 CUL_HM HMFB01 HMFB01_03 Short (to HMUSB)

Da steht für mich doch eindeutig, dass Button 03 der Fernbedienung HMFB01 Short gedrückt wurde. Die Nachricht geht "to HMSUB" - das ist der USB-Stick, mit dem die Fernbedienung gepairt ist.
Wenn ich die Fernbedienungsbuttons mit einem virtuellen Aktor va peere, dann steht da in Klammer "to va"
Wenn ich die Fernbedienung mit gar nix verbinde (weder paire noch peere) geht die Meldung an "to broadcast"

Die Fernbedienung scheint also DOCH zu wissen, dass sie an den USB Stick adressieren muss - oder sie kennt zumindest drei verschiedene Adressierungsarten.

Ja, Du hast soeben den virtuellen Aktor neu erfunden ;-)

Nein, meine Gedanken gingen in eine andere Richtung.

Btw: Der Kernel 3.3.8 bootet nicht mit meinem Raspbian, kann also leider nicht sagen, ob es damit besser waere...

nicht sehr verwunderlich.

Viele Grüße
Udo

[mgernoth]

Hallo Udo,

Und wenn es gar keinen virtuellen Aktor gibt?

Dann gehen sie an die Broadcast-Adresse und die Fernbedienung erwartet gar keine Rückmeldung.

Das ist aber komisch...

Code Auswählen Erweitern

2013-07-06 17:52:28 CUL_HM HMFB01_03 Short (to HMUSB)
2013-07-06 17:52:28 CUL_HM HMFB01_03 trigger: Short_10
2013-07-06 17:52:28 CUL_HM HMFB01 battery: ok
2013-07-06 17:52:28 CUL_HM HMFB01 HMFB01_03 Short (to HMUSB)

Ok, das ist interessant.
Bei meiner RC-19 (gepairt, aber diese Taste nicht gepeert) sieht das so aus:

Code Auswählen Erweitern


2013-07-06 23:30:02 CUL HM_CUL RCV L:0B N:3E F:84 CMD:40 SRC:RC_19_B DST:broadcast 0E01 (REMOTE BUTTON:14 LONG:0 LOWBAT:0 COUNTER:0x01) (,CFG,RPTEN)
2013-07-06 23:30:02 CUL_HM RC_19_B_Btn_14 Short (to broadcast)
2013-07-06 23:30:02 CUL_HM RC_19_B_Btn_14 trigger: Short_1
2013-07-06 23:30:02 CUL_HM RC_19_B battery: ok
2013-07-06 23:30:02 CUL_HM RC_19_B RC_19_B_Btn_14 Short (to broadcast)


Da steht für mich doch eindeutig, dass Button 03 der Fernbedienung HMFB01 Short gedrückt wurde. Die Nachricht geht "to HMSUB" - das ist der USB-Stick, mit dem die Fernbedienung gepairt ist.

Ja, in Deinem Fall geht das tatsächlich an den Stick.

Kannst Du mal dem Stick das Attribut hmProtocolEvents mit Wert >= 3 verpassen?
Dann siehst Du auch die Messageflags im Log (wie bei mir oben).

Falls da am Ende in der Klammer nicht nur CFG und RPTEN auftaucht, sondern zusätzlich noch BIDI, dann besteht die Chance der Fernbedienung den Tastendruck tatsächlich zu bestätigen. BIDI gibt an, dass der Sender hier ein ACK vom Empfänger haben will. Und wenn dieses Flag gesetzt ist und das Ziel die hmId des Sticks ist, dann sollte die Firmware das ACK generieren können.

Nein, meine Gedanken gingen in eine andere Richtung.

Ja, mit dem Verhalten dieser Fernbedienung kann ich das nachvollziehen.

Btw: Der Kernel 3.3.8 bootet nicht mit meinem Raspbian, kann also leider nicht sagen, ob es damit besser waere...

nicht sehr verwunderlich.

Eigentlich schon, da die Kernelconfig (die ich vorher durchgeschaut habe) kompatibel sein sollte (Ext4 und USB ist drin). Habe aber übersehen, dass dieser Kernel einen anderen Init-Pfad eingebaut hat. Jetzt hat er gebootet, die Latenz eines USB-Interrupttransfers bewegt sich aber immernoch im Bereich zwischen einer ms und einer Sekunde. Ist also auch unbrauchbar :-(

Gruß
  Michael

[betateilchen]

Endlich versteht mich mal jemand... *g* Nur wegen eines anderen Gehäuses wird man diese neue Fernbedienung ja nicht entwickelt und auf den Markt gebracht haben.

Kannst Du mal dem Stick das Attribut hmProtocolEvents mit Wert >= 3 verpassen?
Dann siehst Du auch die Messageflags im Log (wie bei mir oben).

nichts leichter als das...

Code Auswählen Erweitern


2013-07-07 12:22:54 HMLAN HMUSB RCV L:0B N:1D F:A2 CMD:40 SRC:HMFB01 DST:AABBCC 0308 (REMOTE BUTTON:3 LONG:0 LOWBAT:0 COUNTER:0x08) (,WAKEMEUP,BIDI,RPTEN)
2013-07-07 12:22:54 CUL_HM HMFB01 CMDs_done_events:3
2013-07-07 12:22:54 HMLAN HMUSB SND L:0D N:1D F:80 CMD:02 SRC:AABBCC DST:HMFB01 0101C800 (ACK_STATUS CHANNEL:0x01 STATUS:0xC8 UP:0 DOWN:0 LOWBAT:0) (,RPTEN)
2013-07-07 12:22:54 CUL_HM HMFB01_03 Short (to HMUSB)
2013-07-07 12:22:54 CUL_HM HMFB01_03 trigger: Short_8
2013-07-07 12:22:54 CUL_HM HMFB01 battery: ok
2013-07-07 12:22:54 CUL_HM HMFB01 HMFB01_03 Short (to HMUSB)


Falls da am Ende in der Klammer nicht nur CFG und RPTEN auftaucht, sondern zusätzlich noch BIDI,

tja, wenn ich das richtig sehe, steht da unter anderem auch BIDI :)

[mgernoth]

Hallo Udo,

Code Auswählen Erweitern


2013-07-07 12:22:54 HMLAN HMUSB RCV L:0B N:1D F:A2 CMD:40 SRC:HMFB01 DST:AABBCC 0308 (REMOTE BUTTON:3 LONG:0 LOWBAT:0 COUNTER:0x08) (,WAKEMEUP,BIDI,RPTEN)


Ok, hier wird das ACK angefordert.

Code Auswählen Erweitern


2013-07-07 12:22:54 HMLAN HMUSB SND L:0D N:1D F:80 CMD:02 SRC:AABBCC DST:HMFB01 0101C800 (ACK_STATUS CHANNEL:0x01 STATUS:0xC8 UP:0 DOWN:0 LOWBAT:0) (,RPTEN)


Und hier ist das gesendete ACK. Ich nehme mal an, dass die LED gelb blieb? Dann wertet die Fernbedienung in diesem Zustand das ACK nicht als Bestätigung für den Tastendruck :-(

Man könnte (ganz grauenhaft) probieren, die Fernbedienung mit einem virtuellen Aktor zu paaren, der die gleiche ID hat wie der Stick. Evtl. funktioniert das und die Fernbedienung wertet das dann auch korrekt aus. Ich weiss aber nicht, ob das "High-Level" geht oder ob man sich die Sendesequenz selbst zusammenbauen muss.

Wenn es High-Level nicht geht, kann wahrscheinlich nur Martin helfen, da ich von dem Funkprotokoll selber relativ wenig Ahnung habe...

Gruß
  Michael

[betateilchen]

Man könnte (ganz grauenhaft) probieren, die Fernbedienung mit einem virtuellen Aktor zu paaren, der die gleiche ID hat wie der Stick

Diese Idee hatte ich gestern auch schon, aber irgendwie bin damit auch nicht weitergekommen.
Wie Du richtig vermutet hast, reagiert die Fernbedienung nicht weiter auf das ACK. Es kommt weder rot noch grün.

Aber vielleicht hat ja wirklich Martin noch eine Idee, er hat ja auch eine dieser neuen Fernbedienungen. Es wäre schon toll, wenn man die Anzeige einer Bestätigung ohne den unzuverlässigen Umweg über einen virtuellen Aktor lösen könnte.

[betateilchen]

ich habe jetzt einfach mal folgendes mit einem ansonsten nicht gepeerten Fernbedienungsbutton versucht:

Code Auswählen Erweitern

set HMFB01_01 peerChan 0 HMUSB single set

Das wurde widerspruchslos ausgeführt und als peerId steht da nun 12700000

Code Auswählen Erweitern


Internals:
   DEF        2123FC01
   NAME       HMFB01_01
   NR         340
   NTFY_TRIGGERTIME 2013-07-08 01:41:21
   STATE      Short (to 127000)
   TYPE       CUL_HM
   chanNo     01
   device     HMFB01
   Readings:
     2013-07-08 01:40:35   R-12700000-expectAES off
     2013-07-08 01:40:35   R-12700000-peerNeedsBurst off
     2013-07-08 01:40:34   R-dblPress      0 s
     2013-07-08 01:40:34   R-longPress     0.4 s
     2013-07-08 01:40:34   R-sign          off
     2013-07-08 01:40:34   RegL_01:          04:10 08:00 09:00 00:00
     2013-07-08 01:40:35   RegL_04:12700000   01:00 00:00
     2013-07-08 01:40:35   peerList        12700000,
     2013-07-08 01:41:21   state           Short (to 127000)
     2013-07-08 01:41:21   trigger         Short_15
   Helper:
     peerIDsRaw ,12700000,00000000
     Role:
       chn        1
     Shadowreg:
       RegL_04:127.0.00  01:00
Attributes:
   group      HM-RC-4-2
   model      HM-RC-4-2
   peerIDs    00000000,12700000,
   room       60_Fernbedienung


Wenn ich jetzt den Button 01 drücke, bekomme ich zumindest schonmal eine rote Rückmeldung, was wohl bedeutet, dass die Fernbedienung auf eine Quittung wartet.

Code Auswählen Erweitern


2013-07-08 01:47:17 HMLAN HMUSB RCV L:0B N:86 F:A4 CMD:40 SRC:HMFB01 DST:127000 0110 (REMOTE BUTTON:1 LONG:0 LOWBAT:0 COUNTER:0x10) (,CFG,BIDI,RPTEN)
2013-07-08 01:47:17 CUL_HM HMFB01_01 Short (to 127000)
2013-07-08 01:47:17 CUL_HM HMFB01_01 trigger: Short_16
2013-07-08 01:47:17 CUL_HM HMFB01 battery: ok
2013-07-08 01:47:17 CUL_HM HMFB01 HMFB01_01 Short (to 127000)


Also war mein nächster Gedanke, dem HM-CFG-USB einfach mal die HM-Id 127000 zu verpassen.

Und nun rate mal, was passiert?

Code Auswählen Erweitern


2013-07-08 01:52:51 HMLAN HMUSB RCV L:0B N:8A F:A4 CMD:40 SRC:HMFB01 DST:127000 0114 (REMOTE BUTTON:1 LONG:0 LOWBAT:0 COUNTER:0x14) (,CFG,BIDI,RPTEN)
2013-07-08 01:52:51 CUL_HM HMFB01 CMDs_done
2013-07-08 01:52:51 HMLAN HMUSB SND L:0D N:8A F:80 CMD:02 SRC:127000 DST:HMFB01 0101C800 (ACK_STATUS CHANNEL:0x01 STATUS:0xC8 UP:0 DOWN:0 LOWBAT:0) (,RPTEN)
2013-07-08 01:52:51 HMLAN HMUSB SND L:0E N:1A F:A0 CMD:11 SRC:127000 DST:wz_Ventilator 0201C80000 (SET CHANNEL:0x01 VALUE:0xC8 RAMPTIME:2) (,BIDI,RPTEN)
2013-07-08 01:52:51 CUL_HM HMFB01_01 Short (to HMUSB)
2013-07-08 01:52:51 CUL_HM HMFB01_01 trigger: Short_20
2013-07-08 01:52:51 CUL_HM HMFB01 battery: ok


Und der Fernbedienungsbutton leuchtet fröhlich grün auf!

Ok, der Ventilator läßt sich nun nicht mehr einschalten. Aber das dürfte einfach daran liegen, dass der Unterputz-Aktor nun mit der neuen ID des HMUSB noch nix anfangen kann. Das bedeutet, ich werde jetzt alle meine Geräte noch einmal neu pairen müssen, damit sie die neue ID 127000 akzeptieren.

Nun bleibt natürlich die Frage, ob der USB Stick immer diese ID haben muss, oder ob sich das von Installation zu Installtation ändert?

[betateilchen]

Weitere Erfolgsmeldung!

Inzwischen habe ich alle 4 Buttons der Fernbedienung wie oben beschrieben mit HMUSB gepeert, den virtuellen Aktor wieder komplett gelöscht und den Schaltaktor für den Ventilator auf die neue Id gepaired. Nun macht die Fernbedienung endlich das, was ich seit Wochen möchte: sie leuchtet grün auf, wenn der Tastendruck von FHEM (genauer: dem Stick) empfangen wurde. Und auch der Ventilator läuft wieder munter los.

Jetzt steht mir nur noch die Fleißarbeit bevor, alle HM-Devices hier noch einmal neu zu pairen. Gibt es dafür nicht irgendeine "einfachere" Lösung, als alle erst mit unpair bzw. einem kompletten Reset umzufrickeln?

Vielleicht kann nochmal jemand testen, ob der HM-CFG-USB auch bei ihm die ID 127000 meldet, wenn man ein peerChan darauf absetzt. Dann könnte man irgendwo einen Hinweis in der Doku unterbringen, dass es Sinn machen kann, diese ID beim Einrichten des Sticks zu verwenden. Analog könnte man den Test auch mal bei einem LAN-Konfigurationsadapter machen (vielleicht mach ich das mal die Tage)

Gute Nacht!

[mgernoth]

Hallo Udo,

Weitere Erfolgsmeldung!

Glückwunsch! :-)

Vielleicht kann nochmal jemand testen, ob der HM-CFG-USB auch bei ihm die ID 127000 meldet, wenn man ein peerChan darauf absetzt. Dann könnte man irgendwo einen Hinweis in der Doku unterbringen, dass es Sinn machen kann, diese ID beim Einrichten des Sticks zu verwenden. Analog könnte man den Test auch mal bei einem LAN-Konfigurationsadapter machen (vielleicht mach ich das mal die Tage)

Die hmId ist einfach zu erklären. Das ist das erste Byte der IP-Adresse (127.0.0.1) und dann mit Nullen aufgefüllt. Kommt aus der Definition des Sticks.

Evtl. kann man beim peeren auch direkt eine hmId statt eines Namens angeben oder mit

Code Auswählen Erweitern


define stick-va CUL_HM hmId

sich ein Gerät mit der gleichen ID wie das Attribut hmId am Stick basteln.

Gruß
  Michael

[betateilchen]

Evtl. kann man beim peeren auch direkt eine hmId statt eines Namens angeben

Na ob der Stick nun die Id 127000 hat oder (wie ursprünglich) AABBCC "heißt" ist mir eigentlich ziemlich egal, Hauptsache es funktioniert *g* Bei Gelegenheit kann ich ja mal testen, ob ich im peerChan auch hätte AABBCC angeben können.

Jetzt bleibt nur noch das ungelöste Problem mit dem nicht aktualisierten WindoRec beim HM-TC-CC, aber das ist eine völlig andere Baustelle.

Danke für Deine Unterstützung.

[betateilchen]

Martin,

was hast Du getan? Mit der 10_CUL_HM 3422 bekomme ich keine Rückmeldung mehr an die Fernbedienung, mit der 3378 funktioniert alles.



edit: jetzt funktioniert es auch mit der alten Version nicht mehr. Es ist zum Verzweifeln.

[marc2]

Hi !

Diese FB ist halt einfach schlicht schrott. Bei mir ist sie direkt mit den Aktoren gepairt.
Da aber offensichtlich die Empfangseigenschaften doch eher recht limitiert erscheinen,
darf ich mich nicht zu weit von Aktoren entfernen, wenn ich das ACK des Aktors noch als
grünes Licht auf der FB sehen möchte. Round about 10m im Gebäude mit maximal einer
Aussenwand und 30-40 im Freien (der Aktor befindet sich im Gartenhaus). Zum Vergleich,
mein CUNO hat hier immerhin einen RSSI Wert -60 (bei ebenfalls rund 10m und einer
Aussenwand). Man wird sich also an das organe Lämpchen gwöhnen müssen, wenn man diese
FB benutzt ...

Gruß, Marc

[martinp876]

hm - schade.

Sicher hast du schon an einen repeater gedacht.

[betateilchen]

Das mit der geringen Reichweite kann ich nicht wirklich nachvollziehen. Ich wohne im zweiten Obergeschoß eines 80-er-Jahre Hauses mit viel Beton. Wenn ich zur Haustür reinkomme und die ersten 3 Stufen der Treppe hochgegangen bin, bekomme ich eine grüne Rückmeldung, wenn ich einen Knopf drücke. Die Fernbedienung ist übrigens direkt dem HM-CFG-USB2 gepeert.

Nachdem ich gestern abend noch ein paar ganz andere Homematic-Eigenarten feststellen mußte, habe ich noch folgende Schritte unternommen:

1. shutdown restart -> keine Abhilfe
2. den Raspberry neu gebootet -> keine Abhilfe
3. den Raspberry und den externen USB-Hub stromlos gemacht, gewartet, wieder angesteckt -> Erfolg!

Ich habe fast den HM-CFG-USB2 in Verdacht, dass der irgendwann "überläuft" und anfängt rumzuspinnen. Oder es ist eben doch der USB Bus des Raspberry eine Ursache. Ich werde die Sache mal weiter beobachten.