Homematic Wired - Homebrew Devices

Begonnen von Thorsten Pferdekaemper, 27 April 2014, 00:13:17

Vorheriges Thema - Nächstes Thema

Thorsten Pferdekaemper

Hi Dirk,
ok, mit den XMLs ist's ein bisschen klarer. Ich werde aber erstmal ein paar andere Sachen verbessern und dem Teil ein par richtige Ein- und Ausgänge geben. Zwei Taster und ein paar LEDs habe ich noch...
Wenn Du Skypen willst: Man findet mich mit meinem Realname und da müsste ich auch eindeutig sein. ...was man von Deinem Namen nicht behaupten kann.
Gruß,
    Thorsten
FUIP

Dirk

Zitat von: Thorsten Pferdekaemper am 14 Mai 2014, 21:24:32
...was man von Deinem Namen nicht behaupten kann.
Auch mit meinem vollen Namen wird das nicht eindeutig :)

Thorsten Pferdekaemper

#32
@Dirk: Das habe ich mir schon gedacht, aber Du hast mich ja gefunden.

Ich wollte eigentlich heute nicht, aber es hat doch in den Fingern gejuckt. Man kann jetzt von FHEM aus Ausgänge schalten. Sozusagen als Beweis habe ich mal einen Screenshot angehängt. Der HMW_LC_Sw2_DR_KEQ1056682 ist einer von HomeMatic, der HMW_LC_Sw2_DR_HHB2703111 ist der selbst gebastelte.

Das Teil sendet jetzt nur noch die Tastendrücke alle 20 Sekunden. Die Ausgänge sind jetzt echt (im Sketch Pin 7 und 8) und können per FHEM geschaltet werden.
Sonstige Änderungen:
- Es gibt jetzt eine Klasse HMWDeviceBase. Die enthält die Definitionen für Callbacks vom Protokoll zur Hardware. Momentan ist das setLevel und getLevel zum Setzen und Lesen eines Zustands. HMWModule ruft die Methoden momentan dann auf, wenn von der Zentrale (oder auch von sonstwo) eine "x" oder "s" Nachricht kommt.
- Das Teil hat versucht, Nachrichten ohne Inhalt (also frameLength 0) zu verarbeiten. Das gab merkwürdige Effekte. (ACKs verarbeite ich momentan noch gar nicht, es werden auch noch keine reinen ACKs gesendet.)

Besonders @Dirk: A propos leere Nachrichten: FHEM sendet des Öfteren so etwas:
   FD-42-38-01-23-1C-00-00-00-01-02-A6-DC
Das kommt z.B. dann, wenn ich einen Ausgang schalten will. Ich mache also ein "set ... on" auf den Kanal und dann kommt erstmal so eine Nachricht. Offenbar ist es eine leere I-Nachricht. Ist das so gedacht? Wenn ja, wie muss ich darauf reagieren?

...und wenn wir gerade bei Problemchen sind: Am Anfang (also wenn ich meinen Testaufbau hochfahre) brauche ich immer einmal shutdown restart, muss ggf. den rs485-Dämon neu starten und muss einmal (oder so) "get info" aufs Gerät machen. Woran kann das liegen?

Gruß,
    Thorsten
FUIP

Dirk

Du bist schnell :)
Ich kann leider erst am Wochenende mitmachen.

Gruß
Dirk

MarkusO

Hallo,
ich habe mir den Discovery-Mode jetzt mal etwas näher angesehen und eine erste Version hochgeladen. Prinzipiell scheint der Mode zu funktionieren:
2014.05.15 22:30:25 3: HM485_LAN: Discovery - found device: 42380123
Allerdings frage ich mich jetzt, wofür der Discovery-Mode eigentlich gut ist? Ursprünglich bin ich davon ausgegangen, dass der Mode benötigt wird, um neue Devices zu finden. Die Devices werden scheinbar aber auch erkannt, wenn z.B. einfach eine Taste gedrückt wird und Botschaften von dem Gerät verschickt werden.
Wie sieht das bei Devices aus, die keine Eingänge haben? Werden hier zyklisch Acknolege-Botschaften verschickt und diese Devices damit auch automatisch erkannt, oder benötigen solche Geräte evtl. den Discory-Mode?

Falls der Mode tatsächlich benötigt wird: hat jemand Informationen zum Timing? Also wie lang die Pause zwischen Empfang der Botschaft und dem Versenden der Bestätigung sein muss? Ich könnte mir vorstellen, dass alle Geräte exakt die gleiche Wartezeit haben und gleichzeitig Antworten. Dadurch, dass keine unterschiedlichen Adressen geschickt werden, sondern von allen die gleiche Botschaft "0xF8" kommt es zu keinen Kollisionen (wie die Arbitrierung beim CAN-Bus). Ist aber nur eine Vermutung. Hat schon mal jemand beobachtet, ob verschiedene Geräte unterschiedliche "Wartezeiten" haben?

Viele Grüße
Markus

Dirk

Zitat von: MarkusO am 15 Mai 2014, 23:11:42
Allerdings frage ich mich jetzt, wofür der Discovery-Mode eigentlich gut ist? Ursprünglich bin ich davon ausgegangen, dass der Mode benötigt wird, um neue Devices zu finden. Die Devices werden scheinbar aber auch erkannt, wenn z.B. einfach eine Taste gedrückt wird und Botschaften von dem Gerät verschickt werden.
Hm-Wired-Geräte werden automatisch erkannt und gepaired, sofern die Zentrale diese noch nicht kennt.
Zumindest mach das die CCU so. Daher habe ich das im FHEM-Modul genau so gemacht.
Bei einem Wired-Bus kann man eigentlich davon ausgehen, dass es hier keine fremden Geräte gibt.

Der Discovery-Mode dient lediglich dazu, das Anlernen einfacher zu gestalten. Auch wenn man an einem IO-Modul mal noch keine Taster angeschlossen hat, oder wenn man alle Module mal neu anlernen möchte, dafür aber nicht durch das Ganze Haus rennen zu müssen.

ZitatWie sieht das bei Devices aus, die keine Eingänge haben? Werden hier zyklisch Acknolege-Botschaften verschickt und diese Devices damit auch automatisch erkannt, oder benötigen solche Geräte evtl. den Discory-Mode?
Aktuell fällt mir zwar kein fertig-Modul ein, was keine Eingänge. Aber ja, dafür währ der dann erforderlich.

ZitatFalls der Mode tatsächlich benötigt wird: hat jemand Informationen zum Timing? Also wie lang die Pause zwischen Empfang der Botschaft und dem Versenden der Bestätigung sein muss?
Die CCU schickt Discovery-Messages, das Device muss innerhalb von 7ms. Antworten.
Ich überarbeite grade die Protokoll Dokumentation da hab ich noch ein paar neue Infos drinn.

ZitatDadurch, dass keine unterschiedlichen Adressen geschickt werden, sondern von allen die gleiche Botschaft "0xF8" kommt es zu keinen Kollisionen (wie die Arbitrierung beim CAN-Bus).
Hier bin ich mir noch nicht ganz sicher. Wenn die Devices das F8 nämlich nicht exact gleichzeitig verschicken, könnte es trotzdem Kollisionen geben. Das wollte ich hier aber noch mal testen.

Gruß
Dirk

MarkusO

ZitatWenn die Devices das F8 nämlich nicht exact gleichzeitig verschicken, könnte es trotzdem Kollisionen geben.
Ja, das könnte eine Herausforderung werden. Allein das Verschicken von ein paar Debug-Nachrichten hat bei mir soviel Zeit in Anspruch genommen, dass die Antwort nicht mehr innerhalb der 7ms gekommen ist und der Discovery-Mode nicht mehr lief. Das ganze so zu timen, dass alle Devices so zeitgleich senden und es zu keinen Kollisionen kommt, klingt fast unmöglich...
Ich werd einfach mal die neue Doku abwarten.

Grüße,
Markus

Thorsten Pferdekaemper

Zitat von: MarkusO am 15 Mai 2014, 23:11:42Falls der Mode tatsächlich benötigt wird: hat jemand Informationen zum Timing?
Die ganzen Timing-Geschichten und Kollisionsvermeidung sind sowieso noch nicht implementiert. Vielleicht ergibt sich das später fast von selbst.

ZitatIch könnte mir vorstellen, dass alle Geräte exakt die gleiche Wartezeit haben und gleichzeitig Antworten. Dadurch, dass keine unterschiedlichen Adressen geschickt werden, sondern von allen die gleiche Botschaft "0xF8" kommt es zu keinen Kollisionen
Das kann ich mir irgendwie nicht wirklich vorstellen. Wenn ich mir das Coding vom SoftSerial anschaue, dann ist das ganze so schon recht zeitkritisch. Ich gehe mal nicht davon aus, dass die Geräte so genau zur gleichen Zeit senden können.

ZitatIst aber nur eine Vermutung. Hat schon mal jemand beobachtet, ob verschiedene Geräte unterschiedliche "Wartezeiten" haben?
Ich hab leider nur ein "echtes".

FUIP

Dirk

Zitat von: Thorsten Pferdekaemper am 16 Mai 2014, 09:59:36
Das kann ich mir irgendwie nicht wirklich vorstellen.
Ich auch nicht so ganz. Obwohl das möglich sein sollte. Daher liegt der Punkt noch etwas im Dunkeln.
Ich werde mir das mal auf meinem Bus ansehen.
Ggf. mal mit dem Logicanalyzer.

ZitatWenn ich mir das Coding vom SoftSerial anschaue, dann ist das ganze so schon recht zeitkritisch. Ich gehe mal nicht davon aus, dass die Geräte so genau zur gleichen Zeit senden können.
Ich nehme an das man SoftSerial hier nicht als Referenz heranziehen kann.
Ansonsten sollte es schon möglich sein beim Eintreffen von Discovery Paketen einen ziemlich gleichzeitigen Interrupt in den Devices auszulösen.
Die HMW-Geräte haben auch alle einen Quarz. Somit ist das Timing hier genauer als ohne.

Thorsten Pferdekaemper

#39
Hi,
ich habe mal wieder ein bisschen weitergebastelt und an meinen Arduino zwei LEDs und zwei Taster angeschlossen (siehe Bild). Ich weiß jetzt, dass das Teil tatsächlich seine Ausgänge schaltet, wenn auch etwas langsam (siehe unten).
Außerdem habe ich im Coding die Taster-Eingänge dazugebaut. (Eingecheckt in meinem Branch.) D.h. das Teil sendet jetzt nicht mehr alle 20 Sekunden einen Key-Event, sondern wenn man die Tasten drückt. Im Einzelnen...

  • Die Tasten sind entprellt. Eine Taste muss mindestens 50ms gedrückt sein, damit überhaupt was passiert.
  • Beim Loslassen einer Taste wird ein KEY_EVENT_SHORT geschickt, außer die Taste wurde länger als 300ms gedrückt.
  • Bei einem Tastendruck von mindestens 300ms wird alle 300ms ein KEY_EVENT_SHORT geschickt.
  • Wenn man eine Taste 2 Sekunden lang drückt, wird ein KEY_EVENT_LONG ausgelöst. Es gibt immer nur ein KEY_EVENT_LONG, egal wie lange man eine Taste drückt.
  • Alles wird an die Broadcast-Adresse geschickt

Ein paar Sachen fehlen da natürlich noch, z.B. müssen die 2 Sekunden einstellbar werden und ich glaube auch die "Repeat"-Funktion alle 300ms. Außerdem denke ich, dass Broadcast nicht ganz das Richtige ist. (Oder?)
Das Coding gefällt mir auch noch nicht wirklich. Vielleicht sollte man dem Teil eine eigene Klasse spendieren, vielleicht sogar eine eigene Mini-Lib.

Jetzt nochmal zum langsamen Schalten der Ausgänge: Das ganze liegt (denke ich) daran, dass die Zentrale (FHEM) vor dem eigentlichen Schalt-Befehl (sowas wie
     FD-42-38-01-23-1E-00-00-00-01-05-78-02-C8-AC-3A
) erst einmal drei leere Nachrichten schickt, also sowas wie
FD-42-38-01-23-18-00-00-00-01-02-DC-44.
Da ich noch keine ACKs sende, macht die Zentrale das dann jeweils dreimal. D.h. es werden 9 Nachrichten versendet, bevor der eigentliche Befehl kommt. Natürlich liegt das Hauptproblem bei mir (fehlende ACKs), aber müssen die leeren Nachrichten sein? Wofür sind die gut?

Gruß,
    Thorsten
FUIP

Mr. P

Zitat von: Thorsten Pferdekaemper am 17 Mai 2014, 23:47:49

  • Die Tasten sind entprellt. Eine Taste muss mindestens 50ms gedrückt sein, damit überhaupt was passiert.
  • Beim Loslassen einer Taste wird ein KEY_EVENT_SHORT geschickt, außer die Taste wurde länger als 300ms gedrückt.
  • Bei einem Tastendruck von mindestens 300ms wird alle 300ms ein KEY_EVENT_SHORT geschickt.
  • Wenn man eine Taste 2 Sekunden lang drückt, wird ein KEY_EVENT_LONG ausgelöst. Es gibt immer nur ein KEY_EVENT_LONG, egal wie lange man eine Taste drückt.
Hej Thorsten,

nachdem mich das Projekt auch interessiert, versuche ich hier im Thread regelmäßig zu informieren und die Fortschritte gefallen mir. :-)
Aber für ein SHORT würde ich nicht min. 50ms veranschlagen, damit was passiert. Ich würde eher bei einem Tastendruck von unter 300ms  min. 50 oder 100ms warten, bis ich den nächsten akzeptiere und das ganze damit entprellen.
Und wie muss man das mit den 300ms verstehen? Entweder, dass wenn ich die Taste zwischen 300ms und 2Sek. loslasse ein kontinuierliches SHORT geschickt wird (bis die Taste vermutlich nochmal gedrückt wird) oder aber, dass ab 300ms solange ein SHORT geschickt wird, bis du bei 2 Sekunden angelangt bist (also bei 300ms, 600ms, 900ms, 1200ms, 1500ms & 1800ms) und dann folgt ein LONG.

Wär' super, wenn du das ein wenig näher erläutern könntest. :-)
Greetz,
   Mr. P

Thorsten Pferdekaemper

Zitat von: Mr. P am 18 Mai 2014, 00:20:31nachdem mich das Projekt auch interessiert, versuche ich hier im Thread regelmäßig zu informieren und die Fortschritte gefallen mir. :-)
Danke!
ZitatAber für ein SHORT würde ich nicht min. 50ms veranschlagen, damit was passiert. Ich würde eher bei einem Tastendruck von unter 300ms  min. 50 oder 100ms warten, bis ich den nächsten akzeptiere und das ganze damit entprellen.
Es gibt ein paar Gründe, warum ich es so gemacht habe:

  • Das scheint zum Entprellen die gängige Praxis zu sein.
  • Die Nachricht soll immer beim Loslassen gesendet werden (laut Dirks Doku). Wenn ich jetzt schon den ersten Wackler als Loslassen interpretiere, dann sendet das Ding schon beim Draufdrücken.
  • Bei einem Tastendruck von über 300ms würde ich (beim ersten Wackler) nicht erst bei 300ms etwas senden, sondern schon ganz am Anfang. Das wollte ich auch vermeiden.
...um die 50ms kann man natürlich streiten. Für die trainierte Gamer-Hand wären vielleicht 25ms besser, für zaghafte oder betagte Benutzer vielleicht 100ms.
ZitatUnd wie muss man das mit den 300ms verstehen? Entweder, dass wenn ich die Taste zwischen 300ms und 2Sek. loslasse...
Also hier mal ein paar Beispiele für Tastendrücke verschiedener Länge:

  • 42ms: Es passiert gar nichts.
  • 142ms: Beim Loslassen wird ein SHORT gesendet.
  • 342ms: Bei 300ms wird ein SHORT gesendet. (Beim Loslassen wird nichts mehr gesendet.)
  • 2542ms: Bei 300, 600, 900, 1200, 1500, 1800, 2100, 2400ms wird je ein SHORT gesendet. Bei 2000ms wird ein LONG gesendet.
  • 4242ms: Bei 300, 600, ..., 3900, 4200ms wird je ein SHORT gesendet. Bei 2000ms wird ein LONG gesendet. (Es kommt kein weiteres LONG mehr bei 4000ms.
Durch meine Implementierung können die Zeiten ein bisschen abweichen. Das dürften nie mehr als ein paar Millisekunden sein, aber eine genaue Uhr kann man damit nicht bauen.
Ich habe oben den momentanen Stand beschrieben. Das muss nicht so bleiben, speziell müssen ein paar Sachen konfigurierbar werden.
Gruß,
    Thorsten
FUIP

Dirk

Zitat von: MarkusO am 16 Mai 2014, 00:06:31
Ja, das könnte eine Herausforderung werden. Allein das Verschicken von ein paar Debug-Nachrichten hat bei mir soviel Zeit in Anspruch genommen, dass die Antwort nicht mehr innerhalb der 7ms gekommen ist und der Discovery-Mode nicht mehr lief. Das ganze so zu timen, dass alle Devices so zeitgleich senden und es zu keinen Kollisionen kommt, klingt fast unmöglich...
Nicht unbedingt. Ich habe mir das nochmal überlegt. Das Timing der AVR's haben wir komplett in der Hand. ggf. muss man auf Arduino-Libs hier verzichten aber das sollte gehen. Allerdings nicht mit SoftSerial.
Die ARV's brauchen für Wired sowieso einen Quarz. D.H. Wenn der AVR ein Discovery-Frame für seine Seriennummer empfängt, muss dieser "nur" ein Byte senden. Und das sollte mit einem vorhersagbarem Timing möglich sein. ggf. müssen während des Discovery nicht benötigte Interrupts abgeschaltet werden. Debugmessages während dessen sind da natürlich nicht drinn.

Ich werde aber mal fertige Module belauschen wie die sich hier verhalten. Mal sehen ob die tatsächlich gleichzeitig F8 senden. Da bin ich nämlich noch nicht so sicher.



Zitat von: Thorsten Pferdekaemper am 17 Mai 2014, 23:47:49
  • Bei einem Tastendruck von mindestens 300ms wird alle 300ms ein KEY_EVENT_SHORT geschickt.
Hier sollte alle 300ms KEY_EVENT_LONG gesendet werden.

ZitatAußerdem denke ich, dass Broadcast nicht ganz das Richtige ist. (Oder?)
Wenn das Device noch nicht gepeert ist, nur dann werden events an die Broadcastadresse gesendet. Ansonsten nur an das gepeerte Device.

ZitatDas Coding gefällt mir auch noch nicht wirklich. Vielleicht sollte man dem Teil eine eigene Klasse spendieren, vielleicht sogar eine eigene Mini-Lib.
Ich hätte das Ganze evtl. sogar so ähnlich aufgebaut wie Trillus AskSin-Lib?

ZitatDa ich noch keine ACKs sende, macht die Zentrale das dann jeweils dreimal. D.h. es werden 9 Nachrichten versendet, bevor der eigentliche Befehl kommt. Natürlich liegt das Hauptproblem bei mir (fehlende ACKs), aber müssen die leeren Nachrichten sein? Wofür sind die gut?
Ich vermute das ist ein Bug. Pasiert das auch, wenn du RAW-Messages schickst?



Zitat von: Thorsten Pferdekaemper am 18 Mai 2014, 08:52:37
  • Das scheint zum Entprellen die gängige Praxis zu sein.
Ja, so mache ich das auch immer.

Zitatfür zaghafte oder betagte Benutzer vielleicht 100ms. Also hier mal ein paar Beispiele für Tastendrücke verschiedener Länge:
Auch hier reichen 50ms. Für die "Betagten" wird nur die Einstellung für die Erkennung des langen Tastendrucks interessant.

Sofern braucht es auch keine weitere Prüfung

  • 0-49 ms: nix passiert
  • 50-longPressSchwelle: nach Loslassen -> kurzer Tastendruck
  • > longPressSchwelle: alle 300ms keyEventLong, Wiederholungen müssen mit selben keyEventCounter gesendet werden. Sonst gibt es probleme beim Dimmen

Gruß
Dirk

Mr. P

Zitat von: Dirk am 18 Mai 2014, 11:33:05

  • 0-49 ms: nix passiert
  • 50-longPressSchwelle: nach Loslassen -> kurzer Tastendruck
  • > longPressSchwelle: alle 300ms keyEventLong, Wiederholungen müssen mit selben keyEventCounter gesendet werden. Sonst gibt es probleme beim Dimmen
Ok, wenn die zeitliche Untergrenze für ein SHORT so die übliche Vorgehensweise ist, werd' ich mir das gerne einmal ansehen. :-)
Und wenn dann ab 300ms ein LONG geschickt wird, wäre das auch die Art, wie ich es bereits von anderen HM-Schaltern kenne.

Danke für die Infos!
Greetz,
   Mr. P

Thorsten Pferdekaemper

Zitat von: Dirk am 18 Mai 2014, 11:33:05Nicht unbedingt. Ich habe mir das nochmal überlegt. Das Timing der AVR's haben wir komplett in der Hand. ggf. muss man auf Arduino-Libs hier verzichten aber das sollte gehen.
Wir haben die Zeit in der Hand, die vom Eintreffen der Discovery-Message bis zum Raussenden des F8 vergeht. Was ist aber mit der Zeit, bis die Discovery-Message wirklich beim jeweiligen Device ankommt?
ZitatIch hätte das Ganze evtl. sogar so ähnlich aufgebaut wie Trillus AskSin-Lib?
Muss ich mir mal anschauen...
ZitatIch vermute das ist ein Bug. Pasiert das auch, wenn du RAW-Messages schickst?
Muss ich mal ausprobieren...

Zitat

  • 0-49 ms: nix passiert
  • 50-longPressSchwelle: nach Loslassen -> kurzer Tastendruck
  • > longPressSchwelle: alle 300ms keyEventLong, Wiederholungen müssen mit selben keyEventCounter gesendet werden. Sonst gibt es probleme beim Dimmen
Der Default-Wert für "Long press" liegt bei 2 Sekunden. Wie kann ich nach 2 Sekunden nachträglich alle 300ms ein Event schicken???
Oder ist es so gemeint:

  • 342ms:: Ein SHORT beim Loslassen.
  • 2642ms:: Jeweils ein LONG beim 2000, 2300, 2600ms. (Alle mit demselben Counter.) Keine Nachricht beim Loslassen.
...und die 2000ms werden noch einstellbar.

Zitat von: Mr. P am 18 Mai 2014, 11:49:29Und wenn dann ab 300ms ein LONG geschickt wird, wäre das auch die Art, wie ich es bereits von anderen HM-Schaltern kenne.
Ich habe das noch nicht ausprobiert, aber ich glaube, dass die Untergrenze für LONG 400ms ist.
FUIP