Homematic Wired - Homebrew Devices

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

Vorheriges Thema - Nächstes Thema

MarkusO

ZitatDie Adresse, die Seriennummer und ggf. sogar den Devicetype würde ich hier gerne im Hexfile des Bootloaders an definierten Adressen mit unterbringen.
Wie wär's die Seriennummer im Hexfile der Applikation unterzubringen, z.B. an der letzten Adresse bevor der Bootloader beginnt? Das hätte den Vorteil, das die Seriennummer vom Bootloader selbst geändert werden könnte. Dann hätte man alle Optionen offen und könnte die Nummer direkt beim Flashen reinschreiben oder aber eine Nummer durch Tastendruck o.ä. selbst generieren.

ZitatIm Endeffekt hat die Firmware des Geräts die Kontrolle darüber. Ich könnte relativ einfach die paar Bytes irgendwo reservieren und in der Firmware verhindern, dass sie überschrieben werden. (Auch beim "Factory-Reset.) Für eine CCU würde dieser Bereich dann immer als "leer" (0xFF) erscheinen.
Seriennummer im EEPROM fänd ich auch ok. Allerdings besteht dann immer die Gefahr, dass eine unreife Firmware "mal eben zum testen" geflasht wird, die das EEPROM löschen könnte.

ZitatDas ist mir noch nicht klar wie das mit deinem Konzept funktioniert.
Die Idee hinter dem Bootloader ist folgende: Wenn die fertigen Geräte irgendwann mal verbaut sind, kann man sich in der Regel nicht mehr über einen Programmieradapter oder RS232 verbinden, sondern nur noch über den HM485-Bus. Das Konzept sieht so aus, dass das Programmiergerät (ein normaler Arduino mit RS485-Interface) sich so verhält, wie ein normaler Arduino-Bootloader, die Daten allerdings nicht selbst verarbeitet, sondern in das HM485-Protokoll verpackt und auf den Bus legt. Der Bootloader im HM485-Device packt die Nutzdaten aus und verhält sich dann wieder wie ein "normaler" Arduino-Bootloader.
Damit kann man ein HM485-Device so flashen, als wäre es direkt über USB (bzw. RS232) an den Rechner angeschlossen. Das Ganze fand ich ganz attraktiv, weil ja das ganze Projekt auf Arduino-Basis läuft. Und weil ich aus der Arduino-IDE heraus keine Möglichkeit kenne, beim Flashen eine individuelle Seriennummer zu generieren und ins Hex zu schreiben, müsste dieser Bootloader sich die ID selbst generieren.

Viele Grüße
Markus

Thorsten Pferdekaemper

Zitat von: ph1959de am 21 Juli 2014, 07:52:57ich hätte als Bezeichnung HB-1W-TMP10 erwartet ...
Hi,
das Ding ist jetzt umbenannt und nennt sich HBW-1W-T10 (auch im Wiki). Ich glaube, dass das mit dem Namensschema konform ist. Damit das auch richtig in der CCU dargestellt wird, muss man das alte XML "hwb_1wire_tmp10.xml" durch das neue "hbw_1w_t10.xml" ersetzen (im Verzeichnis /firmware/hs485types). Danach die CCU durchstarten, das Gerät löschen und neu anlernen.

Ich habe jetzt auch das .hex-File mit ins Git gehängt. (https://github.com/kc-GitHub/HM485-Lib/tree/thorsten/HBW-1W-T10) Damit braucht man eigentlich nur noch das XML und das HEX File.

Ach ja: Die Adresse ist jetzt 0x42FFFFFF und die ID ist HBW4073471. Das war zur Vorbereitung für eine flexiblere Vergabe der Adresse und ID.

Gruß,
   Thorsten
FUIP

Thorsten Pferdekaemper

Hi,
mit der aktuellen Version im Git ist jetzt die Adresse und die Seriennummer einstellbar. Es funktioniert folgendermaßen:
Die Adresse steht in den obersten vier Byte des EEPROM, high Byte first. Was auch immer dort beim Reset (oder Einschalten) steht wird als Adresse benutzt. Eine Ausnahme ist 0xFFFFFFFF. Falls das in den obersten vier Byte steht, dann wird die Adresse 0x42FFFFFF benutzt. Das bedeutet, dass 0x42FFFFFF sozusagen die Default-Adresse ist.
Zum Ändern der Adresse gibt es den "@a"-Befehl (0x4061). Das "@" benutzt die CCU hoffentlich nie. D.h. das steht für "HomeBrew"... Danach das "a" steht für "adresse". Danach folgt die neue Adresse des Geräts. (Mit dem "W"-Befehl geht es nicht, die Geräte-Adresse ist vor normalen Befehlen geschützt.)
So etwas kann man natürlich nicht mit der CCU machen (soweit ich weiß), aber mit einem FHEM-RAW Befehl geht das:
set hm485 RAW 42FFFFFF 1C 00000001 406142000013 
Dieser Befehl würde die Geräte-Adresse auf 0x42000013 setzen. Danach muss man natürlich das "alte" Gerät löschen und das "neue" anlernen.

Die Seriennummer wird dann aus der Adresse ermittelt. Sie beginnt immer mit "HBW", danach kommen die letzten sieben Ziffern der Dezimaldarstellung der Adresse. Für 0x42000013 ergibt sich damit HBW7296275.

Gruß,
   Thorsten
FUIP

reneFHEM

Hallo zusammen,

mein neues Device spricht erfolgreich mit FHEM und gibt sich als HMW_LC_Sw2_DR aus. Bei jedem Sensorerignis wird ein press_short erzeugt. Nun wäre es sinnvoll eine "richtiges Device" für FHEM anzulegen. Dazu muss ich in lib/HM485/Devices ein neues Device anlegen. Gibt es eine Beschreibung über die einzelnen Attribute ?

Gruß Rene


Dirk

Hallo Thorsten,

Zitat von: Thorsten Pferdekaemper am 29 Juli 2014, 00:04:58
mit der aktuellen Version im Git ist jetzt die Adresse und die Seriennummer einstellbar.
Ich bin mir imme noch nicht Sicher, warum man die Adresse und / oder die Seriennummer vom Device nachträglich ändern muss.
Aber mal sehen, vielleicht findet sich ja noch eine Anwendung.

ZitatDie Adresse steht in den obersten vier Byte des EEPROM, high Byte first.
Passt du das dann auch im XML-File an? Oder werden die ersten 4 Bytes vor der Zentrale versteckt? In der Regel stehen an Bytes 01 LOGGING_TIME und 02-05 CENTRAL_ADDRESS.
Wie erfolgt dann die Adressierung der anderen Register?

ZitatZum Ändern der Adresse gibt es den "@a"-Befehl (0x4061).
Warum nicht normal mit "W"? Wenn man die Adresse ohnehin mit Deinem Spezialbefehl ändern kann.
Warum aber 2 Bytes für den Befehl? Das würde dann nicht mehr so dem Protokoll entsprechen.

Ich würde diese Art der Seriennummernverwaltung ggf. per Compilerdirective schaltar machen. Dann kann man sich den Code für das Parsen von "@a" im AVR sparen wenn man z.B. die Seriennummer aus dem Bootloaderbereich lesen möchte.




Hallo Rene,

Zitat von: reneFHEM am 31 Juli 2014, 22:19:43
Nun wäre es sinnvoll eine "richtiges Device" für FHEM anzulegen. Dazu muss ich in lib/HM485/Devices ein neues Device anlegen. Gibt es eine Beschreibung über die einzelnen Attribute ?
Nein, Soweit bin ich mit den Modulen noch nicht.
Es wird aber daraus hinaus laufen, dass man eine XML-Datei ähnlich denen der CCU erstellt. Damit funktioniert dein Device dann auch gleich dort.
Mit einem kleinen Perl-Script wird dieses dann in ein entsprechendes Device-File für FHEM transformiert.
Ich habe die FHEM-Module dahin gehend schon umgestellt, dass das funktioniert. Das Script gibt es hier auch schon. Allerdings bin ich noch nicht ganz fertig.

Gruß
Dirk

Thorsten Pferdekaemper

Zitat von: Dirk am 01 August 2014, 01:01:32Ich bin mir imme noch nicht Sicher, warum man die Adresse und / oder die Seriennummer vom Device nachträglich ändern muss.
Aber mal sehen, vielleicht findet sich ja noch eine Anwendung.
Normalerweise muss man das nachträglich nicht ändern, aber was garantiert uns, dass es nicht ein anderes Device (z.B. eins von eq3 selbst) gibt, welches nicht dieselbe Adresse hat? Das kann sogar nachträglich passieren, wenn man seine Installation um ein (eq3-)Device erweitert. Dann wäre es schon blöd, wenn man das Ding ausbauen muss zum Flashen.

ZitatPasst du das dann auch im XML-File an? Oder werden die ersten 4 Bytes vor der Zentrale versteckt? In der Regel stehen an Bytes 01 LOGGING_TIME und 02-05 CENTRAL_ADDRESS.
Da gibt es nichts anzupassen (bisher). Ich verwende die letzten vier Byte, nicht die ersten. Das wird nur problematisch, wenn wir wirklich das ganze EEPROM brauchen.

ZitatWie erfolgt dann die Adressierung der anderen Register?
Ganz normal. Warum sollte sich da was ändern?

ZitatWarum nicht normal mit "W"? Wenn man die Adresse ohnehin mit Deinem Spezialbefehl ändern kann.
Warum aber 2 Bytes für den Befehl? Das würde dann nicht mehr so dem Protokoll entsprechen.
Die CCU verwendet den "W"-Befehl. Wenn ein "W"-Befehl versucht, die letzten 4 Bytes zu schreiben, dann ignoriert der Sketch das. D.h. die letzten 4 Byte können mit dem "W"-Befehl nicht geschrieben werden. Das garantiert, dass die Zentrale nicht "versehentlich" die Adresse ändern kann.
Jetzt habe ich aber einen Mechanismus gebraucht, der mit dem bisherigen Protokoll kompatibel ist und mit Sicherheit nicht von der CCU (auch in Zukunft) verwendet wird. Deshalb der @-Befehl. Nach dem @ haben wir dann die Freiheit, zu tun was wir wollen. Die CCU schickt so etwas nicht. Der Ausbruch aus dem Protokoll war also Absicht.

ZitatIch würde diese Art der Seriennummernverwaltung ggf. per Compilerdirective schaltar machen. Dann kann man sich den Code für das Parsen von "@a" im AVR sparen wenn man z.B. die Seriennummer aus dem Bootloaderbereich lesen möchte.
Das kann ich gerne einbauen, sobald wir einen Bootloader haben, der eine Adresse/Seriennummer enthält. Momentan haben wir das aber nicht.

ZitatEs wird aber daraus hinaus laufen, dass man eine XML-Datei ähnlich denen der CCU erstellt. Damit funktioniert dein Device dann auch gleich dort.
Mit einem kleinen Perl-Script wird dieses dann in ein entsprechendes Device-File für FHEM transformiert.
Könnte man das automatisieren? Es wäre gut, wenn man das XML einfach in ein bestimmtes Verzeichnis kopieren könnte und der Rest von alleine passiert.

ZitatIch habe die FHEM-Module dahin gehend schon umgestellt, dass das funktioniert. Das Script gibt es hier auch schon. Allerdings bin ich noch nicht ganz fertig.
Hast Du die Beiträge hier gesehen? http://forum.fhem.de/index.php/topic,10607.255.html
Mir scheint, dass gevoo auch an den FHEM-Modulen arbeitet. Wisst Ihr voneinander?

Gruß,
   Thorsten
FUIP

Dirk

Zitat von: Thorsten Pferdekaemper am 01 August 2014, 09:19:12
Normalerweise muss man das nachträglich nicht ändern, aber was garantiert uns, dass es nicht ein anderes Device (z.B. eins von eq3 selbst) gibt, welches nicht dieselbe Adresse hat?
Ja, ich weiß. Das habe ich im Universalsensor-Tread auch schon mal als Begründung angeführt warum es keine gute Idee ist die Seriennummer eines 1-Wire-MAC-IC als Adresse/Seriennummer zu benutzen.
Aber, vor allem bei Wired ist die Warscheinlichkeit sehr gering ein fertiges Device mit der selben Adresse/Seriennummer zu bekommen. Und dann kann man das entweder durch Flashen eines neuen Bootloaders fixen, oder wenn man das Gerät nicht ausbauen will, definiert man eine andere Adresse/Seriennummer in der Firmware und Flasht diese über den Bus (wenn das dann geht). Daher würde ich die Adresse/Seriennummer aus dem Bootloader auch nur als default benutzen und in der Lib die Möglichkeit lassen diese bei Bedarf zu überschreiben.

Noch eine andere Idee:
Man nimmt die Adresse/Seriennummer aus dem Bootloader und "schaltet" mit einem einfachen Befehl nur die letzte Stelle "weiter". Dann hätte man bis zu 255 unterschiedliche Nummern und braucht nur 1 Byte im EEprom dafür.

ZitatDas garantiert, dass die Zentrale nicht "versehentlich" die Adresse ändern kann.
Wenn laut XML-File die reservierten Bytes nicht benutzt werden sollte die Zentrale diese Adressen gar interessieren.

ZitatDie CCU schickt so etwas nicht. Der Ausbruch aus dem Protokoll war also Absicht.
Die CCU interessiert uns hier zwar nicht, dennoch würde ich gerne eine Lösung finden welche auch dort funktioniert. Daher könnte man das oben genannte "rotieren" der Adresse/Seriennummer z.B. auch beim Einschalten bei gedrückter Config-Taste auslösen.

ZitatDas kann ich gerne einbauen, sobald wir einen Bootloader haben, der eine Adresse/Seriennummer enthält. Momentan haben wir das aber nicht.
Ich bau dir einen. Ich denke dafür werde ich dan auch wieder ein Flash-Tool bauen, mit dem man Adresse und Seriennummer selber festlegen kann.

ZitatKönnte man das automatisieren?
Ja, kann man. Das Script verarbeitet auf Wunsch alle XML-Dateien im Verzeichniss. Das sollte man dann auch aus FHEM aus ausrufen können.

ZitatHast Du die Beiträge hier gesehen? http://forum.fhem.de/index.php/topic,10607.255.html
Mir scheint, dass gevoo auch an den FHEM-Modulen arbeitet. Wisst Ihr voneinander?
Ja, allerdings wegen fehlender Hardware hier :) hab ich mich da noch nicht eingemischt.
Auch das werde ich die nächsten Tage nachholen.

Gruß
Dirk

MarkusO

Hallo Thorsten,
in letzter Zeit hast Du ja einige neue Funktionen implementiert. Deshalb habe ich mir nochmal die neusten Files geholt und würde gerne darauf basierend weitere Module basteln (z.B. HMW-LC-Bl1).
Ich habe allerdings schon Probleme die Dateien aus dem Github zu kompilieren. Einige Fehlermeldungen konnte ich schon beseitigen, aber jetzt komme ich einfach nicht weiter. Bevor ich jetzt noch ewig weiter suche, wär meine Frage, welche IDE Du verwendest und ob Du evlt. deine Projektdatei zur Verfügung stellen könntest? Als IDE nutze ich bisher das Atmel Studio 6.2. Mit der Arduino-IDE ließ sich das Projekt auch nicht kompilieren (auch nicht nach Anpassen von Dateiname und -endung / alle *.cpp und *.h files im Sketch-Ordner, ...).

Viele Grüße
Markus

Thorsten Pferdekaemper

Hallo Markus,

als IDE verwende ich Eclipse Juno mit dem "Arduino eclipse plugin" von Jan Baeyens.
Mit der Arduino-IDE könnte es tatsächlich etwas schwierig werden, da die keine Libraries kann, die wiederum selbst Libraries einbinden. Über das Atmel Studio kann ich nichts sagen. Ich kann mir aber vorstellen, dass das ein paar Arduino-spezifische Sachen nicht hat.
Das Projekt-File und die Verzeichnisstruktur, wie sie zurzeit bei mir aussieht, findest Du im angehängten Zip-File. Es enthält zwei Verzeichnisse (HBW-1W-T10 und HMW), die direkt ins eclipse-workspace Verzeichnis gehören.

Das Projekt hat dann den Namen des Geräts (HBW-1W-T10) und verweist auf das Library-Verzeichnis (HMW).
Das Hauptprogramm (der Sketch) ist sozusagen HBW-1W-T10.cpp.

Falls das dann immer noch nicht klappt, dann stell' mal die Fehlermeldungen hier rein. Das Projekt ist ja nicht wirklich komplex, das müsste hinzubekommen sein.

Noch ein Hinweis für Deine Entwicklungen: Die Struktur der HMW-Lib ist noch nicht stabil. Außerdem fehlt noch ein ganz großer Teil. Das Protokoll interessiert sich momentan noch nicht für andere Geräte auf dem Bus und sendet einfach drauflos. Es gibt noch keine Kollisionserkennung, keine Retries etc. Es wird also sicherlich passieren, dass sich das ganze noch ändert und die Änderungen nicht abwärtskompatibel sind. Ich werde das aber immer hier im Forum veröffentlichen.

Gruß,
   Thorsten
FUIP

Dirk

Hi Thorsten,

anbei der Bootloader mit Adress-Data-Bereich. Der Quellcode ist auch mit dabei. die addressData Section ist am ende vom C-File und auch am Ende des Bootloader bereiches im Hexfile. Dort kannst du die Daten auch ändern bis ich dafür das Flashtool angepasst habe.
Der Bootloader lässt sich im Eclipse kompilieren.

Die Firmware die über diesen Bootloader in den AVR kommt muss aber noch wie bisher seriell geflasht werden. Also nicht über den Bus.

an Adresse 0x7FF1 steht der Devicetype (wenn man den benutzen möchte)
an Adresse 0x7FF2 stehen die 10 Bytes der Seriennummer
an Adresse 0x7FFC stehen dann doe 4 Bytes der Serriennummer.

Im Kompilierten Hex-File stehen aktuell folgende Daten:
Device-Type: 0x81 (129)
Seriennummer: HBW0000001
Seriennummer: 0x42 0x43 0x44 0x45

Viele Grüße
Dirk

Thorsten Pferdekaemper

Hi Dirk,

ich weiß noch nicht so genau, wie ich den Bootloader brennen kann.
Ich denke mal, ich nehme einen Uno und verdrahte das sinngemäß so:
http://arduino.cc/en/Tutorial/ArduinoISP
Brauche ich tatsächlich den 10uF Kondensator?

...und dann sowas wie das hier:
avrdude -c arduino -p atmega328 -P COMPORT -b 19200 -U flash:w:filetoburn.hex

Würde das gehen?

Gruß,
   Thorsten
FUIP

Dirk

Zitat von: Thorsten Pferdekaemper am 03 August 2014, 12:29:50
ich weiß noch nicht so genau, wie ich den Bootloader brennen kann.
Ah, ok. da werde ich mal noch einen Beitrag im Wiki dazu schreiben müssen.
Wenn man keinen weiteren Arduino hat, würde das auch mit dem Raspberry Pi gehen.

ZitatBrauche ich tatsächlich den 10uF Kondensator?
Nö. Eigentlich nicht.

Zitat...und dann sowas wie das hier:
Ja. Würde ich mal so sagen.

kannst noch -vvv anhängen. Dann gibt es beim Brennen auch Infos.

Anschließend solltest du die Lockbits wieder setzen:


avrdude -c arduino -p atmega328 -P COMPORT  -U lock:w:0x0F:m

Ohne neu gesetztes Lockbit kann es passieren dass sich der Bootloader beim Flashen einer Firmwaredatei die zu groß ist zerschießt.


Gruß
Dirk

Thorsten Pferdekaemper

Hi Dirk,
ich habe das jetzt mal mit einem Arduino Uno probiert. Erstmal den Programmer hochgeladen, wie hier beschrieben:
http://arduino.cc/en/Tutorial/ArduinoISP
Dann Pins 11,12,13 und GND verbunden. Außerdem Pin 10 vom Arduino auf Reset vom Device.
...dann

C:\Users\...\bin>avrdude -c arduino -p atmega328p -P COM15 -b 19200 -U flash:w:ATmegaBOOT_168_atmega328_pro_8MHz.hex

avrdude: stk500_program_enable(): protocol error, expect=0x14, resp=0x50
avrdude: initialization failed, rc=-1
         Double check connections and try again, or use -F to override
         this check.

avrdude: stk500_disable(): protocol error, expect=0x14, resp=0x51

avrdude done.  Thank you.

oder auch diese Version:

C:\Users\...\bin>avrdude -c arduino -p atmega328p -P COM15 -b 19200 -U flash:w:ATmegaBOOT_168_atmega328_pro_8MHz.hex

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.03s

avrdude: Device signature = 0x000000
avrdude: Yikes!  Invalid device signature.
         Double check connections and try again, or use -F to override
         this check.

avrdude done.  Thank you.


Was kann da schief gelaufen sein?
Ich höre jetzt mal auf, damit zu experimentieren, da der Uno 5V Levels hat und die Platine nur 3,3V. ...das hatte ich vergessen und ich will eigentlich nichts kaputt machen.

Gruß,
   Thorsten
FUIP

MarkusO

Hi Thorsten,
vielen Dank für Deine Hilfe! Mit der Eclipse IDE und dem Arduino Plugin läufts jetzt. Komischerweise habe ich mit Deinen importierten Einstellungen weiterhin Fehler beim Build-Prozess gehabt (trotz angepassten Verzeichnissen). Irgend ein Make-File wurde nicht gefunden... Wie auch immer, wenn ich die einzelnen Dateien in ein neues Projekt übernehme, dann funktioniert alles. Also, besten Dank nochmal.

Ach ja, nochwas:
ZitatBrauche ich tatsächlich den 10uF Kondensator?
Ich würde das mal mit dem Kondensator probieren. Beim Flashvorgang aus der Arduino-IDE (und vermutlich auch über das Eclipse-Plugin) wird ein Reset auf den Arduino ausgelöst, um ihn in den Bootloader zu schicken. Das läuft darüber, dass die DTR-Leitung der seriellen Schnittstelle mit dem Hardware-Reset des Atmegas verbunden ist. Wenn du jetzt aber einen Arduino als Programmiergerät verwendest, musst Du verhindern, dass dieser Arduino den Reset ausführt, sonst landet das Programmiergerät im Bootloader. Mit dem Kondensator verhinderst Du, dass die Spannung während des Reset-Puls einbricht und der Arduino (das Programmiergerät) nicht in den Bootloader wechselt. Falls Du keinen 10µF zu Hand hast, sollten auch höhere Werte funktionieren.
siehe auch hier: http://playground.arduino.cc/Main/DisablingAutoResetOnSerialConnection

Viele Grüße
Markus

Dirk

Zitat von: Thorsten Pferdekaemper am 03 August 2014, 17:30:27
ich habe das jetzt mal mit einem Arduino Uno probiert.
Ok, dein Hinweis mit dem Uno hatte ich vorhin überlesen. Da braucht es den Kondensator sonst reseted der 2. AVR. Ich hatte irgendwie noch in Erinnerung dass du noch einen Pro Micro hast.

Falls du einen Raspberry Pi "rumliegen" hast, den kannst du auch als ISP-Programmer benutzen:
http://www.forum-raspberrypi.de/Thread-tutorial-raspberry-als-programmiergeraet-fuer-atmel-%C2%B5controller

Dort hast du auch gleich 3,3V an den GPIO's

Gruß
Dirk