Homematic Wired - Homebrew Devices

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

Vorheriges Thema - Nächstes Thema

T.ihmann

Ja ich hätte Interesse an dem Arduino Code. Sollten wir evtl. die Aktivitäten zusammenfassen und den Arduino Code auch ins Github einpflegen?

reneFHEM

ZitatSozusagen ein HMW-IO-8-FM
Das und das HMW-LC-SW2-DR sind die beiden die ich aktuell benötigen würde. Die Möglichkeit das Modul ohne FHEM zu betreiben ist für mich wichtig. Deshalb auch das HMW-LC-SW2-DR. FHEM soll nur die "Komfortsteuerungen" zur Verfügung stellen.

ZitatDas ganze sollte auch einen eigenen Bootloader bekommen.
Diese Frage habe ich mir auch schon gestellt. Insbesondere kann der Bootloader wahrscheinlich nur auf der realen HW entwickelt/getestet werden, da Arduino IMHO einen speziellen Bootloader verwendet. 

ZitatInsbesondere ist mir nicht klar, woher FHEM später wissen soll, wo im EEPROM welche Konfig-Option liegt.
Muss FHEM das wissen oder nur die Firmware auf dem Modul ?

ZitatSollten wir evtl. die Aktivitäten zusammenfassen und den Arduino Code auch ins Github einpflegen?
Das sollten wir auf jeden Fall :-). Dirk wollte sich um ein Repository kümmern.

Gruß Rene

MarkusO

Hallo,
für alle die es interessiert hänge ich mal meinen Arduino-Code an (Projekt + Library). Vielleicht kann ja jemand was davon gebrauchen. Die Frage nach einer aktuellen Protokoll-Doku hat sich durch den Link im ersten Post auch erledigt. Hatte ich vorher noch nicht gesehen...
Mit dieser für mich neuen Doku werde ich mal versuchen, den Discovery-Mode zu implementieren. Vielleicht werden damit auch die Tastendrücke richtig gemeldet?
ZitatSollten wir evtl. die Aktivitäten zusammenfassen und den Arduino Code auch ins Github einpflegen?
Wär großartig! Ich hab auf jeden Fall Interesse, dass Ganze weiter zu entwickeln.

Beste Grüße
Markus

Thorsten Pferdekaemper

Zitat von: reneFHEM am 11 Mai 2014, 21:32:16Die Möglichkeit das Modul ohne FHEM zu betreiben ist für mich wichtig. Deshalb auch das HMW-LC-SW2-DR. FHEM soll nur die "Komfortsteuerungen" zur Verfügung stellen.
Klar, sonst bräuchte man ja nicht sowas wie das Homematic-Protokoll. Ich meinte damit nur, dass man das Programmieren (z.B. was ist Ein- oder Ausgang, irgendwelche Schaltzeiten, Peering) der Module über eine Zentrale (wie FHEM) vornehmen kann. Danach können dann die Module alleine arbeiten, auch wenn FHEM oder was auch immer die Zentrale ist mal ausfällt.
ZitatDiese Frage habe ich mir auch schon gestellt. Insbesondere kann der Bootloader wahrscheinlich nur auf der realen HW entwickelt/getestet werden, da Arduino IMHO einen speziellen Bootloader verwendet.
Ein Arduino kommt mit einem vorgefertigten Bootloader, aber soweit ich weiß kann man den mit einem Programmer auch umschießen.
ZitatMuss FHEM das wissen oder nur die Firmware auf dem Modul ?
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.

FUIP

Thorsten Pferdekaemper

Zitat von: MarkusO am 11 Mai 2014, 22:22:16für alle die es interessiert hänge ich mal meinen Arduino-Code an (Projekt + Library).
Ich bin auch gerade dabei, etwas ähnliches zu bauen. Wenn ich was Lauffähiges habe, dann stelle ich's auch hier rein. Mal sehen, wie man das dann verheiraten kann. 
ZitatMit dieser für mich neuen Doku werde ich mal versuchen, den Discovery-Mode zu implementieren.
Das trifft sich gut, davon wollte ich nämlich erstmal die Finger lassen. 
FUIP

Dirk

Zitat von: Thorsten Pferdekaemper am 11 Mai 2014, 12:57:32
Es gibt immer noch kein git-Repository. (@Dirk: ?)
Ich denke das ich das heute schaffen werde.

ZitatDas 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.

ZitatIch 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.

ZitatInsbesondere 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).

Zitat von: MarkusO am 11 Mai 2014, 13:55:29
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?

ZitatBei 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.

ZitatWird 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.

Zitat1. 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.

Zitat3. 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.

Zitat4. 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#msg56562

Da sollten auch deine Fragen zum Discovery-Mode beantwortet werden.
Aus Informationen vom Samstag kommen hier noch ein paar Ergänzungen rein.

Zitat von: reneFHEM am 11 Mai 2014, 21:32:16
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.

Zitat von: Thorsten Pferdekaemper am 12 Mai 2014, 08:03:07
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.

ZitatSoweit 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

Thorsten Pferdekaemper

#21
Hi,

so, jetzt habe ich auch die erste einigermaßen lauffähige Version von "meiner" Lösung. (Genau genommen ist ein großer Teil davon Dirks Lösung.) Die Sourcen hängen hier als .zip mit dran. Ich habe das mit Eclipse gemacht, aber es müsste auch in der Arduino-IDE gehen, wenn man HMWHomebrew.cpp nach .ino umbenennt.

Ich benutze für RS485 die SoftwareSerial Lib. Dummerweise kann die keine Parity, also musste ich da auch rumbasteln. Mit der SoftwareSerial.cpp hier im Anhang sollte es gehen.
Das Gerät sondert über die normale serielle Schnittstelle (Pin 0/1 bzw. USB) Debug-Ausgaben mit 57600 ab. RS485 geht über Pins 2 (RXD), 3 (TXD) und 4 (TX-Enable). Siehe auch den Anfang von HMWHomebrew.cpp.

Das Teil wird von FHEM (mit Dirks HM485-Erweiterungen) als HMW-IO-12-FM erkannt. Das funktioniert dadurch, dass es alle 20 Sekunden eine "A"-Nachricht sendet. (Also besser nicht in Eure Produktiv-Umgebung reinhängen.)
Die I/O-Ports funktionieren allerdings noch nicht...

Gruß,
    Thorsten
FUIP

MarkusO

Hallo,
erstmal vielen Dank für die vielen Infos und besonders für diesen Tipp:
ZitatDein 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.
Mit einer Adresse, die nicht zwischen 0x00 und 0xFF liegt, werden die Tastendrücke auf einmal erkannt. Viel mehr habe ich heute leider nicht geschafft. Falls ich morgen Zeit finde, schaue ich mir mal Thorstens Code an.
@Thorsten: Auf den ersten Blick sieht dein Arduino-Projekt deutlich strukturierter aus als meins. Ich werd mal versuchen, auf Basis von Deinem Code den Discovery-Mode zu implementieren.

Viele Grüße
Markus

Dirk

Hallo,

Ich habe hier schon mal ein Repo erstellt welches aber noch leer ist:
https://github.com/kc-GitHub/HM485-Lib

Ich wollte eigentlich schon mal ein Gerüst einbauen.
Das habe ich heute aber nicht mehr.

Ihr könnt mir ja schon mal eure Github Accouns schicken.
Dann kann ich euch mit einrichten.

@Thorsten,
Ich schaue mir morgen mal deinen aktuellen Code an.
Allerdings würde ich den Hartdware-UART und den Soft-UART tauschen.
Soft-UART als Debug-Ausgang.
Ich habe im Platinenlayout für die RS485-Version des Wettersensors übrigens PD2 als TX-Enable "verkabelt".
Die Platinen sollten hoffentlich Ende der Woche bzw. Anfang nächster Woche bei mir ankommen.

Gruß
Dirk

Thorsten Pferdekaemper

Zitat von: MarkusO am 12 Mai 2014, 23:11:28@Thorsten: Auf den ersten Blick sieht dein Arduino-Projekt deutlich strukturierter aus als meins. Ich werd mal versuchen, auf Basis von Deinem Code den Discovery-Mode zu implementieren.
Danke für die Blumen. Allerdings konnte ich noch nicht so richtig Tastendrücke etc. verschicken. Da scheinst Du weiter zu sein. Vielleicht liegt's aber auch daran, dass der HMW-IO-12-FM irgendwie anders reagiert.
Hat jemand einen echten HMW-IO-12-FM, so dass man das mal ausprobieren kann?

Zitat von: Dirk am 13 Mai 2014, 00:17:16Allerdings würde ich den Hartdware-UART und den Soft-UART tauschen.
Soft-UART als Debug-Ausgang.
Ich habe das absichtlich so gemacht, damit ich den Arduino Uno so wie er ist benutzen kann. Der USB-Stecker ist nun mal der Hardware-UART.
Man kann das aber im Hauptprogramm ganz einfach umstellen. Die HMWRS485-Klasse nimmt im Konstruktor jeweils einen Stream für den rs485 und für den Debug-Ausgang. Das kann man einfach umdrehen, wenn die Hardware etwas anders aussieht.

Gruß,
     Thorsten
FUIP

Thorsten Pferdekaemper

Zitat von: Dirk am 13 Mai 2014, 00:17:16Ihr könnt mir ja schon mal eure Github Accouns schicken.
Dann kann ich euch mit einrichten.
Du hast eine PM.

Ansonsten habe ich gestern (oder eher heute morgen) doch noch geschafft, etwas "sinnvolles" von meinem Prototypen zu FHEM zu senden. 4B-Nachrichten bekommt FHEM mit, aber 69-Nachrichten scheinen ignoriert zu werden. Ich habe es daher mal kurz mit der Emulation eines HMW-LC-SW2-DR probiert, da funktionieren (auch?) 69-Nachrichten für die Schaltausgänge.
Ich werde daher wahrscheinlich erst einmal mit einem HMW-LC-SW2-DR weitermachen, da ich da wenigstens was sehen kann. Ich habe auch vor, das Coding noch etwas zu vereinfachen (z.B. brauchen wir wohl keine zwei Klassen für das Protokoll und die generische Modulfunktionalität). Außerdem ist noch nicht wirklich sauber getrennt, was "Library" ist und was modulspezifisch. Das will ich aber noch machen.

Wo ich nicht so recht durchblicke ist die Konfiguration übers EEPROM. Das Layout des EEPROM-Speichers geht irgendwie aus dem Modul-Dateien (mit JSON-Beschreibungen oder so) hervor. Ich kapiere aber nicht, wie das genau zu verstehen ist. Gibt's dazu eine Doku?
Vielleicht kann sich jemand anders dieses Teils annehmen.

Außerdem wäre es gut, wenn jemand, der wirklich einen HMW-IO-12-FM hat, das ganze mal ausprobiert. Vor Allem wäre interessant, welche Messages das Teil bei einem Tastendruck schickt bzw. wenn ein Ausgang geschaltet wird.

...aber jetzt muss ich erstmal Geld verdienen

Gruss,
    Thorsten
FUIP

Thorsten Pferdekaemper

Hi,

ich habe das jetzt umgebaut, so dass es in FHEM aussieht wie ein HMW-LC-Sw2-DR.
Die Sourcen liegen in https://github.com/kc-GitHub/HM485-Lib/tree/thorsten.
(Das "alte" Hauptprogramm habe ich nach HMW-IO-12-FM.cpp bzw. .h kopiert.)

Es sendet jetzt alle 20 Sekunden jeweils eine 4B-Nachricht (Key Event) für die ersten beiden Channels und je eine 69-Nachricht (Information) für die Channels 3 und 4. Das ist in etwa so, wie mein echter HMW-LC-Sw2-DR es auch macht.
Die Nachrichten kommen in FHEM als Events an und werden auch in den Readings der Channels angezeigt.

Device-Type, Seriennummer und Adresse werden jetzt im Konstruktor von HMWModule mitgegeben. Außerdem gibt es die Methoden broadcastKeyEvent und broadcastInfoMessage, mit denen man relativ einfach was vom Modul an die Zentrale (FHEM) schicken kann.

Die Konfiguration funktioniert noch nicht, da ich wie schon gesagt das Speicherlayout im EEPROM nicht kapiere. Falls sich da jemand verweilen will...
(...das ist aber nicht alles, was noch fehlt.)

Gruß,
    Thorsten


FUIP

Dirk

Zitat von: Thorsten Pferdekaemper am 14 Mai 2014, 00:01:39
Die Konfiguration funktioniert noch nicht, da ich wie schon gesagt das Speicherlayout im EEPROM nicht kapiere. Falls sich da jemand verweilen will...
Das kann ich  mit machen bzw. kann ich dich hier einweisen. Das ich nicht so schwehr.
Ich würde das gerne so ähnlich machen wie in der AskSin-Lib, wo man die Register aus der Device-Config generieren lassen kann.
Allerdings würde ich hier auf die XML-Dateien zurück greifen.

Zum Thema Device-Type, Seriennummer und Adresse, würde ich das ganze auch so machen wie ich es bei Wettersensor gemacht habe.
Dann könnte man diese Daten während des Flashens vergeben.
Alternativ, so wie es auch bei den kommerziellen Geräten gemacht wird, könnte man diese Daten in den Bootloader packen. Den muss man sowieso selber flashen, wenn man Updates über den Bus fahren möchte.

Man kann den Raspery Pi übrigens auch als ISP-Programmer "misbrauchen". Das ganze passiert dann über 4 GPIO-Pins + GND.
Alternativ kann man einen Ardiuno mit einem passenden Sketch versorgen und diesen als ISP benutzen.

Die neuen Platinen vom Wettersensor sind ürbigens auf dem Weg zu mir.
Da diese auch für eine Bestückung mit RS485 Tranceiver und Spannungsversorgung vorgesehen sind, kann man diese auch gut zum experimentieren benutzen.

Gruß
Dirk

Thorsten Pferdekaemper

Zitat von: Dirk am 14 Mai 2014, 16:22:34
Das kann ich  mit machen bzw. kann ich dich hier einweisen. Das ich nicht so schwehr.
Ok, dann erklär mir das mal, am besten Anhand des HMW-LC-Sw2-DR.
ZitatIch würde das gerne so ähnlich machen wie in der AskSin-Lib, wo man die Register aus der Device-Config generieren lassen kann.
Allerdings würde ich hier auf die XML-Dateien zurück greifen.
Das können wir gerne so machen. Wo ist das Coding und woher bekomme ich die XML-Dateien?

ZitatZum Thema Device-Type, Seriennummer und Adresse,
[...]
diese Daten in den Bootloader packen.
Das sind für mich alles Themen, die ich momentan noch nicht angehen will. Zuerst sollte das Gerät mit richtig funktionieren, danach können wir es für die Massentauglichkeit fit machen.

ZitatDie neuen Platinen vom Wettersensor sind ürbigens auf dem Weg zu mir.
Da diese auch für eine Bestückung mit RS485 Tranceiver und Spannungsversorgung vorgesehen sind, kann man diese auch gut zum experimentieren benutzen.
Ok, aber dafür braucht man dann definitiv einen eigenen Bootloader oder muss per Programmer flashen, denke ich. (...aber den habe ich ja.)

Gruss,
    Thorsten
FUIP

Dirk

Zitat von: Thorsten Pferdekaemper am 14 Mai 2014, 17:21:06
woher bekomme ich die XML-Dateien?
Lade dir mal von der eq-3 Website das aktuellste firmwareupdate von der CCU1
Das Img benennst du um in tar.gz und packst das aus. Das innere Archiv auch noch mal
Die XML-Dateien liegen dann unter /firmware/hs485types
Hier kann man auch gut die Adressen der Register im EEprom rauslesen.

Es gibt da aber noch ein paar Kleinigkeiten zu beachten.
Das jetzt hier komplett zu erklären währ aber ziemlich umfangreich. Ggf. können wir dazu ja mal Skypen oder so.
Ggf. könnte man das in die Protokoll-Doku mit aufnehmen.
Die Doku habe ich übrigens noch etwas erweitert. Werde die die Tage mal noch hochladen.

ZitatOk, aber dafür braucht man dann definitiv einen eigenen Bootloader oder muss per Programmer flashen, denke ich.
Den brauchen wir in jedem Fall, wenn man über den Bus updaten können soll.

Gruß
Dirk