Es gibt immer noch kein git-Repository. (@Dirk: ?)
Ich denke das ich das heute schaffen werde.
Das ganze sollte auch einen eigenen Bootloader bekommen. Es gibt dazu auch schon (Bascom)-Sourcen, aber mir ist noch nicht klar, wie ich das tatsächlich auf "Arduinisch" bekomme.
Für den Arduino-Bootloader gibt es auch Beispielcode. Den könnte man erweitern. Der Bascom-Bootloader kann übrigens auch noch keine Kommunikation über den Bus.
Ich habe etwas den Überblick verloren, wie weit die Anbindung von Homematic Wired an FHEM gediehen ist.
Da habe ich die letzte Zeit leider nicht viel geschaft.
Aber, ich war am Samstag auf dem Homematic-Userteffen. Da wurden einige interessante Dinge vorgestellt. Unter anderem auch die mögliche Freigabe des hs485d und des rfd von der CCU. Das betrifft die Nutzung der Binärfiles auf externer Hardware wie dem Raspberry Pi usw. Im Gespräch waren ARM und x86 Plattformen. Ich vermute aber das die Fritzbox und MacOS hier außen vorleiben würden. Daher bin ich grade am überlegen ob und wie ich das ganze weiterentwickle.
Insbesondere ist mir nicht klar, woher FHEM später wissen soll, wo im EEPROM welche Konfig-Option liegt.
In den Device-Files ist die Adresszuordnung abgelegt. FHEM weis also welche EEprom-Adresse mit welchem Wert beschriebe werden muss. Im Prinzip das Gleiche wie das Registerhandling bei HM-Funk (BidCos).
Schalten der Ausgänge:
Beim Schalten der Ausgänge (z.B. client_14 auf ON) schickt FHEM zunächst 3x eine Botschaft raus, deren Bedeutung mir nicht ganz klar ist.
Das sieht für mich auch etwas merkwürdig aus.
Kannst du mal den Abschnitt posten der während des Anlernen und bei get info ober den Bus gehen?
Bei der anschließenden Botschaft wird der Befehl "x" verwendet, laut Protokoll-Doku hätte ich hier "s" erwartet. Ist das eine "normale" Kommunikation oder läuft hier irgend etwas schief, weil der Client noch nicht vollständig gepairt ist?
"x" sollt in diesem Fall korrekt sein. "s" sendet die Zentrale soweit ich es noch in Erinnerung habe nur an einen gepeerten aktor.
Wird am Arduino eine angeschlossene Taste gedrückt, verschickt der Client die folgende Botschaft:
2014.05.11 13:16:34-681 3: HM485d: Rx: I[2](0,Y,F,B)(9C) 000000AB -> FFFFFFFF [6] 4B(K) 01000A {8DFA}
In der FHEM-Zentrale passiert allerdings nichts (die Zeile steht auch nicht im allgemeinen Logfile, sondern nur in dem Logfile für das HM485-Gateway).
Dein Device hat 000000AB als Adresse? So wie ich das herausgefunden habe ist der Adressraum 00000001 - 000000FF für das Interface der Zenralen vorgesehen. Auch wenn aktuell vor allem an der CCU1/2 nur eine Wired-Interface unterstützt werden.
Und ich meine dass Messages von anderen Zentralen ignoriert werden.
1. Hat jemand Interesse an dem Arduino-Code? Dann würde ich das ganze nochmal etwas aufräumen, den Code mehr kommentieren und posten. Ist allerdings nichts was wirklich ausgereift ist, sondern nur schnell zusammen geschrieben, um die Kommunikation testen zu können.
Ich guck mir das auf alle Fälle auch mal an.
3. Sind die Quellen für das HMW-Gateway, die im Wiki angegeben sind (https://github.com/kc-GitHub/FHEM-HM485), noch aktuell, oder gibt es mittlerweile irgendwo Arbeitsstände mit weiteren Funktionen?
Soweit ja. Es gibt dort noch eine DEV-Branch die ein kleines Stück weiter ist. Aber auch noch Bugs enthält.
4. Irgendwo im Netz habe ich die Protokolldoku von Dirk gefunden. Besten Dank dafür - großartige Hilfe! Ist die Version 14 vom 04.04.2012 die aktuellste die es gibt? Besonders interessieren mich etwas mehr Details zum Discovery-Mode, aber dazu stelle ich später vielleicht noch ein paar Fragen.
Das ist nicht mehr die neuste. Die letzte die ich veröffentlicht hatte ist hier:
http://forum.fhem.de/index.php/topic,10027.msg56562.html#msg56562Da sollten auch deine Fragen zum Discovery-Mode beantwortet werden.
Aus Informationen vom Samstag kommen hier noch ein paar Ergänzungen rein.
Insbesondere kann der Bootloader wahrscheinlich nur auf der realen HW entwickelt/getestet werden, da Arduino IMHO einen speziellen Bootloader verwendet.
Auch der Bootloader den Arduino verwendet ist nix besonderes. Es müssen halt die vorher spezifizierten Übergangsparameter eingehalten werden.
Ein Arduino kommt mit einem vorgefertigten Bootloader, aber soweit ich weiß kann man den mit einem Programmer auch umschießen.
Das ist korrekt. Und wenn die Module dann auch über den Bus updatebar sein sollen, muss man in den Arduino dann einen eigenen Bootloader "brennen". Man das dann übrigens auch mit einem zweiten Arduino welcher dann den Job des ISP-Programmers übernimmt, erledigen. Daher sollte das dann kein großes Problem werden.
Soweit ich verstanden habe, verwendet Homematic kaum Funktionen im Protokoll, die das EEPROM indirekt verändern. Statt dessen wird das EEPROM über spezielle Kommandos ausgelesen, in der Zentrale geändert und dann über RS485 wieder geschrieben. D.h. die Zentrale muss ziemlich genau wissen, wo was im EEPROM liegt, es hat aber den Vorteil, dass man sich einiges an Programmzeilen im Modul selbst spart.
Das Protokoll kennt Befehle für das Lesen (R) und schreiben (W) des EEprom. Daher hat man von der Zentrale (FHEM) aus den kompletten EEprom unter Kontrolle.
In der Gerätedefinition ist beschrieben an welche Speicheradresse welche Informationen stehen müssen.
Gruß
Dirk
