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

[betateilchen]

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

ich hab das loglevel-Attribut im HMLAN gelöscht - scheint zu wirken :)

[martinp876]

Hi,

die HMID 000000 wird ist ein Dummy. Sie wird als Zieladresse genutzt, wenn es ein Broadcast ist - also eben keine Adresse.
Ausserdem taucht sie auf um das ende einer Peerlist zu signalisieren - bei der Abfrage der peers eines Channels.

Und letztlich wird sich noch als adresse des action-detectors genutzt. Ist nur ein Notbehelf, da der ActiondDetector eine HM-instanz, um steuerbar sein zu koennen. Dass ich hier die '000000' verwendet habe ist Zufall (und aergert mich immer noch...)

Freut mich, wenn die Doku ein wenig weiterhilft. Es geht fuer einige relativ tief in die Steuerung hinein - daher ist es nur ein Versuch und eine Hilfestellung.

Einen Zusammenhang zwischen rote LED und länger nicht genutzt kann ich nicht herstellen. Kann es sein, dass dein FHEM controller in eine Art sleepmode fällt?

Gruss Martin

[betateilchen]

Hallo Martin,

der Raspberry auf dem (nur) FHEM läuft, ist dabei derartig aktiv, dass er zum Schlafen kaum kommt *g* Das Problem mit der roten Rückmeldung tritt definitiv nur bei der Fernbedienung auf. Alle anderen hier eingesetzten HM-Komponenten haben dieses Verhalten noch nicht gezeigt. Türöffner melden sofort grün - und die sind viel länger ungenutzt als die Fernbedienung. Ich tippe gefühlsmäßig eher auf einen Schlaf-Modus in der Fernbedienung selbst. Die läuft ja nur mit einer 1,5V Batterie, da dürfte Energiesparen oberstes Gebot sein.

Viele Grüße
Udo

[martinp876]

Hallo Udo,

schlafen der FB kann ich mir schlecht vorstellen. Schliesslich wacht die FB auf und sendet den trigger. Sie sollte also hellwach sein, wenn die Antwort kommt.
Ansonsten waere es ein FW bug - Zeitstempel nicht korrekt in der Aufwach-Sequenz
Kannst du logs aufzeichnen?
Gruss Martin

[betateilchen]

Hallo Martin,

das ist ein Mitschnitt nach längerer Nichtnutzung der Fernbedienung.
Der erste Knopfdruck ergab eine rote Rückmeldung, der direkt darauf nochmal gedrückte gleiche Knopf erhielt eine grüne Rückmeldung.

Falls Du was anderes brauchst, sag mir bitte was und ich wie ich loggen soll.

Code Auswählen Erweitern


2013.06.09 18:02:19 1: HMLAN_Parse: HMLAN V:03C1 sNo:JEQ0706699 d:1EA0BD O:9601BD t:19032D10 IDcnt:0000
2013.06.09 18:02:44 1: HMLAN_Send:  HMLAN I:K
2013.06.09 18:02:44 1: HMLAN_Parse: HMLAN V:03C1 sNo:JEQ0706699 d:1EA0BD O:9601BD t:19038EC1 IDcnt:0000
2013.06.09 18:02:56 1: HMLAN_Parse: HMLAN R:E2123FC   stat:0000 t:1903BB82 d:FF r:FFB8     m:40 A440 2123FC 112233 0108
2013.06.09 18:02:56 1: HMLAN_Send:  HMLAN I:+2123FC,00,00,
2013.06.09 18:02:56 1: HMLAN_Send:  HMLAN S:S29AD16AC stat:  00 t:00000000 d:01 r:29AD16AC m:40 8002 112233 2123FC 01010000
2013.06.09 18:02:56 1: HMLAN_Parse: HMLAN R:E2123FC   stat:0000 t:1903BC7C d:FF r:FFB8     m:40 A040 2123FC 112233 0108
2013.06.09 18:02:56 1: HMLAN_Parse: HMLAN R:R29AD16AC stat:0002 t:00000000 d:FF r:7FFF     m:40 8002 112233 2123FC 01010000
2013.06.09 18:02:56 1: HMLAN_Parse: HMLAN discard
2013.06.09 18:02:56 1: HMLAN_Parse: HMLAN R:E2123FC   stat:0000 t:1903BD77 d:FF r:FFB8     m:40 A040 2123FC 112233 0108
2013.06.09 18:02:59 1: HMLAN_Parse: HMLAN R:E2123FC   stat:0000 t:1903C955 d:FF r:FFB8     m:41 A440 2123FC 112233 0109
2013.06.09 18:02:59 1: HMLAN_Send:  HMLAN S:S29AD2331 stat:  00 t:00000000 d:01 r:29AD2331 m:41 8002 112233 2123FC 0101C800
2013.06.09 18:02:59 1: HMLAN_Parse: HMLAN R:R29AD2331 stat:0002 t:00000000 d:FF r:7FFF     m:41 8002 112233 2123FC 0101C800
2013.06.09 18:02:59 1: HMLAN_Parse: HMLAN discard
2013.06.09 18:03:09 1: HMLAN_Send:  HMLAN I:K
2013.06.09 18:03:09 1: HMLAN_Parse: HMLAN V:03C1 sNo:JEQ0706699 d:1EA0BD O:9601BD t:1903F075 IDcnt:0001


[martinp876]

Hi,

hm... die Antwort von FHEM ist korrekt. Koennte zu spät sein, aber leider war kein mseclog an.

Aber bei der Gelegenheit habe ich versucht, auf die beiden Wiederholungen zu reagieren. Die SW von gerade (3268) sollte das unterstützen.

Gruss Martin

[Kunibert]

Hallo Martin,

ich war einige Tage unterwegs, habe mich erst heute wieder mit dem Thema beschäftigen können, nochmals alles neu eingegeben und dann an mein Garagentor angeschlossen.
Bis auf das Problem des manchmal fehlenden oder nicht erkannten ACK und der roten LED funktioniert es nun.

Dein HM-RC-4-2 ist wohl auf AES eingestellt.

Kann ich nicht mit Gewissheit bestätigen.

In dem Ausschnitt, den du gepostet hast scheint das pairing funktioniert zu haben. FHEM hat alles einmal wiederholen muessen, kann aber an der Verzoegerung durch AES gelegen haben. Hier sollte aber kein timeout aufgetreten sein.

Ja, das pairing hatte funktioniert. Ein Timeout ist mir jetzt nicht mehr aufgefallen.

Hast du AES selbst gesetzt?

Wurde von mir, zumindest nicht wissentlich eingestellt. Vorsichtshalber habe ich es jetzt definitiv abgeschaltet.

Es ist doch der RC4 und nicht einer seiner Key oder Sec varianten?

Ich habe eindeutig den HM-RC-4-2. Ursprünglich dachte ich, dass die FB für die anderen Funktionen konfigurierbar ist, da ja auch die Bedienungsanleitung für alle 3 FBs ist.

Nochmals vielen Dank für Deine Hilfe. Ich werde das Thema selbstverständlich weiterverfolgen. Vielleicht findet ja noch jemand heraus, wo das Problem liegt. Mir ist aufgefallen, dass es bei den Device-Attributen eine Angabe der Firmware gibt. Gibt es vom Hersteller bei Problemen auch Updates für Devices und wenn ja, wie kann man sie einspielen?

Gruß,
Dietmar

[martinp876]

Hallo Dietmar,

keine Ahnung, wie der FW update funktioniert. Offensichtlich kann man es den Haendler gegen Gebuehr machen lassen. Ob es das Funkinterface auch hergeben wuerde ist nicht klar...
Gruss
Martin

[betateilchen]

die Antwort von FHEM ist korrekt. Koennte zu spät sein, aber leider war kein mseclog an.

Das mit den Millisekunden kann ich gerne nachholen, ich weiß ja, wie ich das Verhalten reproduzieren kann :)

Die SW von gerade (3268) sollte das unterstützen.

Die krieg ich einfach mit einem update?

[martinp876]

ja, ab heute sollte es per Update klappen

[betateilchen]

Hier nochmal der gleiche Vorgang mit Millisekunden (ich habe noch kein Softwareupdate gestartet)

Erster Tastendruck ergibt rot, zweiter Tastendruck danach ergibt grün.

Code Auswählen Erweitern


2013.06.10 18:52:49.543 1: HMLAN_Parse: HMLAN R:E2123FC   stat:0000 t:1E57F6C0 d:FF r:FFB9     m:54 A440 2123FC 112233 0110
2013.06.10 18:52:49.614 1: HMLAN_Send:  HMLAN S:S2F011E52 stat:  00 t:00000000 d:01 r:2F011E52 m:54 8002 112233 2123FC 01010000
2013.06.10 18:52:49.986 1: HMLAN_Parse: HMLAN R:R2F011E52 stat:0002 t:00000000 d:FF r:7FFF     m:54 8002 112233 2123FC 01010000
2013.06.10 18:52:49.987 1: HMLAN_Parse: HMLAN discard
2013.06.10 18:52:49.988 1: HMLAN_Parse: HMLAN R:E2123FC   stat:0000 t:1E57F7BA d:FF r:FFBD     m:54 A040 2123FC 112233 0110
2013.06.10 18:52:49.993 1: HMLAN_Parse: HMLAN R:E2123FC   stat:0000 t:1E57F8B5 d:FF r:FFC0     m:54 A040 2123FC 112233 0110
2013.06.10 18:52:52.770 1: HMLAN_Parse: HMLAN R:E2123FC   stat:0000 t:1E5803C2 d:FF r:FFBB     m:55 A440 2123FC 112233 0111
2013.06.10 18:52:52.841 1: HMLAN_Send:  HMLAN S:S2F012AEC stat:  00 t:00000000 d:01 r:2F012AEC m:55 8002 112233 2123FC 0101C800
2013.06.10 18:52:52.996 1: HMLAN_Parse: HMLAN R:R2F012AEC stat:0002 t:00000000 d:FF r:7FFF     m:55 8002 112233 2123FC 0101C800
2013.06.10 18:52:52.996 1: HMLAN_Parse: HMLAN discard



----

Nachtrag: Wenn ich ein "update check" mache, wird mir nichts von HM-irgendwas angezeigt:

List of new / modified files since last update:
UPD FHEM/00_FBAHA.pm
UPD FHEM/01_FHEMWEB.pm
UPD FHEM/DevIo.pm

[marc2]

Hallo Martin,

das FHEM interne update hängt ja immer etwas hinterher. Im SVN Log  
sieht man die Updates ja aber eigentlich sofort. Aber auch dort ist nichts zu sehen.

Gruß, Marc

[martinp876]

Marc, Udo,

ich habe die Version 3262 und 3268 am Sonntag eingebracht und 3272 gestern.
Nach Rudi werden die Files immer am Morgen des naechsten Tages in den Update eingebaut, macht ein batch-job von Rudi...
Lasst mich wissen, wenn es wieder nicht da ist.

Zu den Zeitstempeln: Sehr knapp "Ausgeschnitten", da habe ich kaum Zeit-referenzen. (ich weiss, ich bin mit nichts zufrieden).
HMLAN setzt eine Zeitmarke vond er ich annehme, dass es die korrekte Sendezeit ist, also die Zeitmarke, zu der die Nachricht an den HMLAN-IP-stack uebergeben wird. In FHEM kommt alles recht spaet an - falls es jemanden interessiert, hier die Details:

 Trigger 1 gesendet T=0, geparsed T= 100ms => 100ms delay
 repeat 1 gesendet T=250, geparsed T= 540ms => 290ms delay
 repeat 2 gesendet T=500, geparsed T= 550ms => 50ms delay

 Trigger 2 0ms delay

Trigger 2 kann ich also ohne Probleme bestaetigen. Bei Trigger 1 kommen jetzt mehrere Probleme zum Tragen:
- repeat1 und 2 werden nicht beantwortet. Das sollte ab Version 3268 behoben sein.
- Repeat1 kommt so spaet dass er garnicht zeitgerecht beantwortet werden kann, da ist sogar schon der 2. Repeat draussen. Grund ist, dass Trigger1 "komplett" in CUL_HM geparst wird. Das verarbeiten aller Notifies und Prozeduren kostet offensichtlich so viel Zeit.
- Repeat2 kommt dann wieder schneller. Grund ist, dass CUL_HM die doppelte Nachricht erkennt und ein erneutes Parsen verhindert.
=> FHEM "Nachbearbeitung" nach CUL_HM dauert etwa 200ms!

Ab Version 3268 sollte CUL_HM/HMLAN also in der Lagen sein den 2. repeat zu beantworten (den Ersten auch, aber leider zu spaet)

Wenn HMLAN nicht gewartet haette (70ms), haette es der erste Trigger noch schaffen koennen. Aber ein Ack sollte min 100ms nach dem Kommando kommen.... dan haette ggf. der 2. Trigger ein Problem....

Ich versuche, die Wartezeit dynamisch zu errechnen.... ist nicht ganz einfach da sich staendig alles verschiebt. Mein HMLAN arbeitet mit einer Genauigkeit von 100ppm - nicht sehr viel.

Wen die Details nicht interessieren: mit Version 3268 sollte es weitgehend funktionieren. Eine weitere Verbesserung dauert noch ein Bisschen


Gruss
Martin

[betateilchen]

Zu den Updates: Heute morgen gab es immer noch keine Updates, die HM betreffen.

Zu den Zeitstempeln: Sehr knapp "Ausgeschnitten", da habe ich kaum Zeit-referenzen. (ich weiss, ich bin mit nichts zufrieden).

Ich bin davon ausgegangen, dass Du nur den Teil mit den beiden Tastendrücken brauchst, und da gab es nicht mehr Inhalt im Log.

falls es jemanden interessiert, hier die Details:

Ja, interessiert mich schon, und ich hab das auch soweit verstanden. Für mich bleibt aber die Frage, warum das NUR bei der Fernbedienung auftritt und z.B. bei den Tür-/Fensterkontakten nicht. Dort habe ich noch nie eine rote Rückmeldung erhalten.

[martinp876]

Ich nehme an, dass die Tuer und Fensterkontakte auch mit FHEM gepeert sind (virtueller Aktor). Ansonsten ist der Vergleich nicht fair ;-)

Das gesamte TimingBild habe ich nicht, auch nicht, wer welche Verzoegerung macht.

FB->HMLAN->FHEM
oder SW (grob)
FB->HMLAN-RF->HMLANprocessing->HMLANStacketh->Zentrale ETH/IPstack->FHEM-IO->FHEM-HMLAN

Die FB ist sauer, wenn ihre Timingvorgaben uebergangen werden. Diese sind: Antwort 100ms nach dem Senden(empirisch ermittelt...) aber nicht spaeter als 250ms danach (kann man daran festmachen, dass dann ein repeat kommt).

Da ich nicht messen kann (ok, wireshark schon...) habe ich nur Stempel von HMLANpocessing (beginn oder Ende) und FHEM-HMLAN.

Bei HMLAN bin ich guter Dinge, es ist nicht viel los, da kann so eine kleine CPU sehr einfach sehr genau arbeiten - auch sehr schnell (ist sicher kein Perl :-) )

Ein Linux Rechner (Fritzbox,...) ist da schon ein komplexeres Gebilde. Aber die Verarbeitung von FB und Fensterkontakt sollte identische Wege gehen. Ob ein Fensterkontakt ein laxeres Timing hat kann ich nicht Sagen.
Wenn du mir ein vergleichbares log schickst kann ich einmal reinsehen. Mit ein paar Zeitstempeln drumrum, da mit ich mir ein TimingBild bauen kann

Gruss Martin