Alternative Firmware für Homematic Komponenten

Niemand da, der so eine Homematic-Komponente von Conrad oder ELV mal 
auseinander geschraubt hat? ;-)

>Ja, ich weiß, dass Homematic völlig überteuert ist.

hab mit jetzt nur kurz 3 sachen angescheut

zentrale 500€
i/o modul (wired) 12 ein 7 aus knapp über 100€
visualisierung (html) 200€
wetterstation 300€

also billiger gehts wohl nicht mehr...

Hallo Dirk,

ich habe mir heute mal drei Homematic-Module zum Aufmachen geholt:
1x Fenster-/Tür-Kontakt
1x Dimmaktor
1x 4fach UP-Sender

Von der Hardware sähe es in der Tat sehr gut machbar aus.
Ich habe bis jetzt einen ATmega32L im Dimmaktor gesichtet und einen 
ATmega168v im UP-Sender. Es scheint zwei unterschiedliche Bauformen von 
Funkmodulen zu geben. Haben aber alle die gleiche Anzahl Pins.
Ich gehe mal davon aus, dass überall ein CC1100-Transceiver drin steckt, 
oder?

Die "non-open-source" Strategie ist natürlich völlig daneben. Teuer 
finde ich persönlich relativ, wenn ich mir anschaue, was sowas von 
anderen Firmen kostet. Gut, dass ist dann zwar nicht proprietär (z.B. 
KNX-RF), aber teuer ist es auch.

Der Vorteil einer eigener Firmware wäre hier für mich, dass ich halt 
sofort alles an Hardware habe. Ich muss keine Platinen machen lassen, 
keine Bauteile bei Farnell oder anderen Distris besorgen, bei denen man 
als Otto-Normal-User nicht bestellen kann. Dann das Löten dieser kleinen 
Bauformen, etc.
Wenn ich da die Zeit und auch das Geld betrachte, komme ich vermutlich 
mit einer neuen Firmware schneller zum Ziel, da ich ja schon etwas zum 
Spielen habe.

Wenn ich auf dieser Hardware-Basis anfinge, wäre ja selbst bei einem 
späteren Schwenk zu einer "Open-Source-Hardware" nichts verloren. Vor 
allem, wenn der gleiche Transceiver zum Einsatz kommt.

Aber Eure Busware-Seiten kannte ich noch gar nicht. Sehr interessant!

Ich habe hier noch einen Energy-Sensor ES1 von Conrad rumfliegen. Der 
hat auch ein extra Platinchen mit Sende-Funkmodul. Das habe ich 
runtergelötet, weil ich auch überlegt hatte, dort "einfach" ein anderes 
Funkmodul dran zu hängen. Eine Firmware für den AVR habe ich auch schon 
zusammen geschustert, so dass ich die Leistungsaufnahme eines 
angeschlossenen Gerätes messen kann. Fehlt halt "nur" noch der Funk.

Ich habe hier noch div. Zigbee-Module (u.a. ZigBit) rumfliegen. Wenn ein 
802.15.4 Modul, dann nur noch mit 6LoWPAN (mittels Contiki).

Gruß
Christan

Z-Wave ist alles andere als offen! Ist faktisch so wie mit Homematic. Es 
kommt eigentlich alles nur von einem Chip-Hersteller. Im Internet findet 
man kaum technische Details darüber. Darauf würde ich auf keinen Fall 
setzen.

Es könnte ruhig etwas eigenes sein, da es ja Open-Source sein soll.
Hauptsache es bleibt schlicht und einfach. Ich fänd's halt cool, wenn 
die untere(n) Protokollschicht(en) möglichst unabhängig vom 
Sensor-/Aktortyp blieben. So könnte jeder dieses Protokoll benutzen. Ich 
finde es immer grausam zu sehen, dass applikationsspezifische Dinge in 
unteren Protokollschichten auftauchen.

Ideal wäre so etwas, wie es bei vielen Dingen schon gemacht wird: Es 
gibt Applikationsobjekte, deren Attribute man lesen und schreiben kann. 
Dazu definierte Datentypen (Uint8, Strings, Float, etc.) Mehr nicht. Es 
bleibt dann dem jeweiligen Entwickler überlassen, wie dieses Objekt 
aussieht und welche Attribute es bereit stellt. Evtl. könnte man noch 
sowas wie ein einfaches Profil definieren, das zwingend notwendige 
Objekte und deren Attribute vorschreibt. So läuft es bei Zigbee (Zigbee 
Cluster Library).

ABER: Alles viel viel abgespeckter!

Hallo Dirk,

klaro. Es sollte auf allen Medien laufen.
Das was Du mit Jabber beschreibst, ist für mich aber schon wieder eine 
der oberen Protokollschichten, bzw. die Oberste.

Dieses könnte man ja ohne Probleme mit dem objektorientierten Ansatz 
lösen. Es gäbe dann halt ein Reporting-Objekt, dass Deine Jabber-Dinge 
sprechen könnte und das auch Publish&Subscribe unterstützt. Bei Zigbee 
läuft es ähnlich. Zusätzlich zu ReadAttribute und WriteAttribute gibt es 
dort noch so etwas wie SetReportingAttribute. Damit kann ein Attribut 
eines Objekts automatisch Sendungen vornehmen. Aber gut....

Mir geht es erstmal darum, wie baut man die unterste Schicht am besten 
auf?
Addressierung? Message-Counter? Verschlüsselung mit Hinblick auf 
Replay-Sicherheit? Wie bekommt man das unter einen Hut mit 
Broadcast-Messages, etc.

Über die Payload, die dann übertragen werden soll, kann man sich immer 
noch unterhalten.

Hintergrund dabei ist: wenn die neue "Open-Source-Firmware" z.B. die 
Verschlüsselung nicht besser macht hinsichtlich Replay-Manko, dann kann 
ich auch bei der Homematic-Firmware bleiben und deren System benutzen 
(mal unabhängig von ideologischen und finanziellen Überlegungen).

Gruß
Christian

Okay.

Gerade gefunden:
http://www.atmel.com/dyn/resources/prod_documents/doc2600.pdf

Für die Payload schlage ich grob sowas vor:

1

typedef struct

2

{

3

  unsigned int direction:1;

4

  unsigned int disableDefaultResponse:1;

5

  unsigned int reserved:6;

6

} payloadControl_t;

7

8

typedef struct {

9

   uint8 objectId;

10

   uint8 transActionSequencenum;

11

   uint8 commandId;

12

} payloadHeader_t;

13

14

/* ReadAttributeCommand: right after the payload header */

15

typedef struct

16

{

17

  uint16 attrID;            // attribute ID

18

  uint8  dataType;          // expected attribute data type

19

} ReadAttributeCommand_t;

20

21

/* WriteAttributeCommand: right after the payload header */

22

typedef struct

23

{

24

  uint16 attrID;            // attribute ID

25

  uint8  dataType;          // attribute data type of following data

26

  uint8  data[];            

27

} WriteAttributeCommand_t;

28

29

/* Response to command: right after the payload header */

30

typedef struct

31

{

32

  uint8 status;

33

} Response_t;

34

35

/* Payload directions (Requester->Responder, Responder->Requester)  */

36

#define DIR_REQ_RSP                           0x00

37

#define DIR_RSP_REQ                           0x01

38

39

/* Data Types (from ZCL) */

40

#define DATATYPE_NO_DATA                            0x00

41

#define DATATYPE_DATA8                              0x08

42

#define DATATYPE_DATA16                             0x09

43

#define DATATYPE_DATA24                             0x0a

44

#define DATATYPE_DATA32                             0x0b

45

#define DATATYPE_BOOLEAN                            0x10

46

#define DATATYPE_BITMAP8                            0x18

47

#define DATATYPE_BITMAP16                           0x19

48

#define DATATYPE_BITMAP24                           0x1a

49

#define DATATYPE_BITMAP32                           0x1b

50

#define DATATYPE_UINT8                              0x20

51

#define DATATYPE_UINT16                             0x21

52

#define DATATYPE_UINT24                             0x22

53

#define DATATYPE_UINT32                             0x23

54

#define DATATYPE_INT8                               0x28

55

#define DATATYPE_INT16                              0x29

56

#define DATATYPE_INT24                              0x2a

57

#define DATATYPE_INT32                              0x2b

58

#define DATATYPE_ENUM8                              0x30

59

#define DATATYPE_ENUM16                             0x31

60

#define DATATYPE_SEMI_PRECISION                     0x38

61

#define DATATYPE_SINGLE_PRECISION                   0x39

62

#define DATATYPE_DOUBLE_PRECISION                   0x3a

63

#define DATATYPE_OCTET_STRING                       0x41

64

#define DATATYPE_CHAR_STRING                        0x42

65

#define DATATYPE_TIME                               0xe0

66

#define DATATYPE_DATE                               0xe1

67

68

/* Command ID */

69

#define COMMAND_READ_ATTRIBUTE                      0x01

70

#define COMMAND_WRITE_ATTRIBUTE                     0x02

71

72

/* ------------------------------------------------------*/

73

/* internal object representation */

74

/* ------------------------------------------------------*/

75

76

/* Access Control Bitmask */

77

#define ACCESS_CONTROL_READ                         0x01

78

#define ACCESS_CONTROL_WRITE                        0x02

79

80

typedef struct {

81

   uint16  attributeId;         

82

   uint8   dataType;       

83

   uint8   accessControl;  

84

   void    *dataPtr;      /* Pointer to "normal" program variable */

85

} attributeRecord_t;

86

87

typedef struct {

88

   uint8               objectId;

89

   uint16              numAttrbutes;

90

   attributeRecord_t   attribute[];

91

} objectRecord_t;

92

93

#define OBJECT_ID_SYSTEM                            0x01

94

#define OBJECT_ID_LIGHTCONTROL                      0x02

95

#define OBJECT_ID_HEATING                           0x03

96

97

/* OBJECT_ID_SYSTEM attributes */

98

#define OBJ_SYSTEM_ATTR_NAME                        0x0001

99

100

/* OBJECT_ID_LIGHTING attributes */

101

102

/* OBJECT_ID_HEATING attributes */

Oh, payloadHeader_t müsste so aussehen:

1

typedef struct {

2

   payloadControl_t pC;  

3

   uint8            objectId;

4

   uint8            transActionSequencenum;

5

   uint8            commandId;

6

} payloadHeader_t;

Alles basierend auf Zigbee-Prinzipien. Aber stark ausgedünnt.

:-)

Ich würde prinzipiell erst noch etwas mehr dokumentieren bzw. 
konzeptionieren. Ein Wiki wäre dafür am besten.

Sourceforge, BerliOS?

Die oberen Schichten sind für mich inzwischen recht klar vor Augen.
Ich persönlich lege bei den unteren Schichten den Fokus auf Funk.

Zum Testen der oberen Schicht würde die Entwicklung auch auf einem PC 
reichen. Man könnte es ja in UDP-Pakete packen und einen UDP-Treiber 
vorsehen, der über Sockets läuft.

Ich mache mir momentan noch eher Gedanken, wie ich das vernünftig mit 
dem Funk und seinen Widrigkeiten hinbekomme. Vor allem mit der 
Verschlüsselung. Passt das überhaupt in die kleinen Controller alles 
rein?

Öhm. Was ist Dir jetzt lieber? Code bei Google oder bei Berlios, weil 
Berlios CVS bietet?

Würde SVN bevorzugen. :-)

Google Code sieht doch ganz gut aus. Schön schlicht mit SVN und Wiki. 
Reicht doch.

Lieber Dirk,
willst du nicht erst einmal 1 Projekt richtig fertig machen?
Ich meine, nicht nur Layout, sodass es auch "benutzbar" ist.
DMX, FS20, EIB, Freebus, Freebus über USB ....
Jetzt CC....
Ich zweifel ein wenig, oder schreibe, dass ich mich irre.

ja, KNX-RF ist komplett unverschlüsselt.

Was haltet ihr vom one-net protokoll ?
Ist verschlüsselt open-source und unterstützt verschiedene Funkchips.

www.one-net.info
www.one-net.info/spec

Harald

Klaus M. schrieb:
> Wurde dieses Projekt eigentlich weitergeführt, oder ist es wie viele
> Andere auch im Sande verlaufen ???

Also ich habe nach der Ideenphase nicht mehr weitergemacht. Es war 
einfach in absehbarer Zeit nicht vernünftig machbar.

Aktuell gibt es ja CUL und FHEM. Für viele Dinge reicht das erstmal.
Eine eigene Firmware schien also nicht nötig zu sein.

Allerdings
1) finde ich die Idee natürlich immer noch recht interessant.
2) hat das AES-Signing in manchen HM-Komponenten wohl einen Bug, so dass 
sich Schaltzustände ändern lassen, obwohl Authentizität nicht 
gewährleistet ist

Mit dem CUL von Dirk wäre ja jetzt immerhin eine vernünftige 
Schnittstelle zum PC/Embedded System per USB vorhanden, so dass man die 
Zentrale nicht mehr bräuchte.

Vielleicht sollte man wirklich nochmal anfangen, eine alternative offene 
Firmware für HM-Komponenten zu entwickeln. Für mich wäre die Sicherheit 
auf jeden Fall sehr wichtig. Es muss von Anfang an sichergestellt sein, 
dass nur berechtigte Geräte Aktionen ausführen können. Von daher ist es 
schon löblich, dass EQ3 hier sowas bedacht hat (AES Signing).
Außerdem finde ich es sehr gut, dass Sensoren und Aktoren direkt 
miteinander kommunizieren (können). Beim Ausfall der Zentrale 
funktioniert der Lichtschalter dann nämlich immer noch (im Gegensatz zu 
vielen anderen Systemen).

Meines Erachtens wurde die Sicherheit bei vielen heutigen Funk-Systemen 
völlig vernachlässigt! Das Disaster wird dann irgendwann mal in der 
Zukunft folgen, wenn die ersten FS20, KNX-RF-Hacker durch die Gegend 
fahren und Unfug treiben. ;-)

Wenn ihr wirklich was offenes flexibles und professionelles sucht,
dann schaut euch mal die embedded pcs und das busklemmensystem von 
beckhoff an.

http://www.beckhoff.de/german/embedded_pc/cx5010_cx5020.htm
http://www.beckhoff.de/german/bus_terminal/digout.htm

Schade, wohl wieder einmal etwas im Sande verlaufen :-(

Offenbar ist wirklich etwas in Arbeit:
http://forum.fhem.de/index.php?t=msg&goto=56768&rid=0

Dort wird ein Funk-Bootloader für den Zwischenstecker-Schaltaktor 
beschrieben.

Bin ja mal gespannt, was da noch so kommt....

Achja, zur Kommunikation benötigt man dann wohl ein CUL-Modul.

Moin,

ich hab da heute mal ein bisschen rumgefummelt, wie ich löten hasse...

Basis ist ein Unterputz-Schaltaktor (den ich gerne als Sender für eine 
Hue Lampe nutzen möchte, was mit der Standard-Firmware nicht geht...)

Verbunden via BusPirate auf die SPI Ports (die 6 Lötkontakte).

Funktioniert soweit, allerdings noch ziemlich Beta. Spricht kein BidCos, 
sondern ein einfaches eigenes Protokoll (CA FE 01 SEQ[0..7] SEQ[8..15] 
CMD A B C), CMD z.b. F0 für button, dann A=button, B=state, C=toggle 
counter.

Die Kommandos können mit CUL, HM-LAN-CFG etc. empfangen/gesendet werden.

Kompilieren/Flashen mit:
avr-gcc -mmcu=atmega644 -Os -funsigned-char -funsigned-bitfields 
-fpack-struct -fshort-enums -fdata-sections -ffunction-sections \
    -Wall -Wstrict-prototypes -Wundef -std=gnu99 -Wl,--gc-sections 
test.c -o test.elf && \
avr-objcopy -O ihex test.elf test.hex && \
avrdude -P /dev/tty.usbserial-AD01W21E -c buspirate -p m644 -U 
flash:w:test.hex:i

Hallo Moritz,

ich habe Deinen Beitrag leider gerade erst gesehen.

Ich habe mich diesem Thema (Alt. FW) auch wieder angenommen.
Aktuell betreibe ich hauptsächlich Dokumentation von vorhandener 
Hardware:
https://github.com/ccier/openhm/wiki
Das Wiki sollte für jeden editierbar sein.

Den Anfang macht bei mir der Schaltaktor PSS von RWE:
https://github.com/ccier/openhm/wiki/PSS

Als Firmware benutze ich diese hier:
http://code.google.com/p/panstamp/

Eine Unterstützung von panStamp wird auch gerade bei FHEM eingebaut:
http://forum.fhem.de/index.php?t=msg&goto=76489&rid=0

Die FW für die AVRs habe ich als Atmel Studio 6 Solution/Projekte 
erstellt und verwende dabei auch die Arduino CoreLib (libcore.a), die 
ich mit der Atmel AVR Toolchain kompiliert habe. Der SWAP-Stack von 
panStamp baut auf dem Arduino Core auf.

Gruß
Christian

Hallo Christian.

   Ich wollte ein TRX868 Modul mit Arduino UNO verbinden und dann die 
SWAP SW von PanStamp darauf flashen. Müßte doch gehen...

   Als Gegenstation habe ich eine Fritzbox 7390 mit FHEM und HMlan 
adapter.

  Frage: geht der HMlan adapter für SWAP oder muss ich einen CUL adapter 
haben?

  ...kämpfe aber gerade noch heftig mit Atmel Studio6. Die libcore.a 
habe ich jetzt.

Ein TRX868 mit Arduino geht natürlich. Ich habe hier einen 3.3V-Wattuino 
+TRX868 und betreibe beides mit SWAP.

Einen HMLAN-Adapter kannst Du nicht benutzen.
CUL wird erst gehen, wenn Du die SWAP-Unterstützung einbaust.

Nimm doch lieber einen zweiten Arduino mit noch einem TRX868.
Oder den panStick. Das ist dann Dein Gateway (wie bei HMLAN oder CUL).
Du müsstest dann nur die panStamp-Modem-Firmware nehmen.

> Moin,
>
> ich hab da heute mal ein bisschen rumgefummelt, wie ich löten hasse...
>
> Basis ist ein Unterputz-Schaltaktor (den ich gerne als Sender für eine
> Hue Lampe nutzen möchte, was mit der Standard-Firmware nicht geht...)
>
> Verbunden via BusPirate auf die SPI Ports (die 6 Lötkontakte).
>
> Funktioniert soweit, allerdings noch ziemlich Beta. Spricht kein BidCos,
> sondern ein einfaches eigenes Protokoll (CA FE 01 SEQ[0..7] SEQ[8..15]
> CMD A B C), CMD z.b. F0 für button, dann A=button, B=state, C=toggle
> counter.
>
> Die Kommandos können mit CUL, HM-LAN-CFG etc. empfangen/gesendet werden.
>
> Kompilieren/Flashen mit:
> avr-gcc -mmcu=atmega644 -Os -funsigned-char -funsigned-bitfields
> -fpack-struct -fshort-enums -fdata-sections -ffunction-sections \
>     -Wall -Wstrict-prototypes -Wundef -std=gnu99 -Wl,--gc-sections
> test.c -o test.elf && \
> avr-objcopy -O ihex test.elf test.hex && \
> avrdude -P /dev/tty.usbserial-AD01W21E -c buspirate -p m644 -U
> flash:w:test.hex:i



Hallo zusammen,
ich stehe vor dem Problem, dass meine Dimmaktoren eine alte Firmware 
installiert haben. Nun würde ich gerne die Firmware von einem neueren 
Aktor einspielen, ohne das alle zu EQ3 eingesendet werden müssen.
Wenn ich das richtig verstanden habe müsste ich mit dem BusPirate die 
bestehende auslesen und dann mit der angepassten Seriennummer auf den 
"alten" Dimmer wieder flashen können.

Richtig oder Falsch ?

Hallo Zusammen,

ich habe mal angefangen das HM Protokoll für Arduino's verfügbar zu 
machen. Falls jemand interessiert ist, findet ihr hier den Entwicklungs 
Thread.

http://forum.fhem.de/index.php/topic,14140.0.html

Viele Grüße
trilu

Hi,

ich habe die Library von trilu auf den oben genannten Aktor portiert. 
Wer Interesse hat kann das ganze gerne ausprobieren und mitwirken: 
https://github.com/jabdoa2/Asksin_HM_LC_Sw1PBU_FM


Gruß,
Jab