mikrocontroller.net

Forum: Haus & Smart Home Alternative Firmware für Homematic Komponenten


Autor: Christian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Hat sich jemand mal das Innenleben von diversen Homematic Komponenten 
angesehen? Ist ein ISP bzw. JTAG Anschlus vorhanden?
Es soll ja angeblich auf einem CC1110 (von TI) und einer Atmel-MCU 
beruhen.

Mich interessiert dabei die Frage, ob man nicht "einfach" eine neue 
offene Firmware für die Dinger schreiben könnte, die auch in Bezug auf 
Sicherheit mehr zu bieten hat. Dieses BidCos-Protokoll soll ja eher 
Schrott sein.

Ja, ich weiß, dass Homematic völlig überteuert ist. Aber darum soll es 
hier jetzt nicht gehen. ;-)

Gruß
Christian

Autor: Christian (Gast)
Datum:

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

Autor: lrlr (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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...

Autor: Dirk Tostmann (tostmann)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi!

Gute Idee und auch machbar. In den Geräten steckt ein universeller 
CC1100-Transceiver und meist ein Atmel mit herausgeführter 6ISP 
Schnittstelle (6 Kontaktpunkte). Der (nicht eingesetzte) CC1110 (mit 
Controller) hätte bestimmt geholfen die Preise zu senken.

Ich würde aber ELV ungern in Ihrer "non-open-source" Strategie 
unterstützen wollen und diese überteuerten Geräte kaufen. Zumal es sich 
auch nicht durchzusetzen scheint.

Es dürfte billiger sein nützliche FS20 "auf-/umzurüsten", dazu 
entwickeln wir z.B. gerade einen Transceiver mit Controller: 
http://busware.de/tiki-index.php?page=CPM

Vielleicht sollte man direkt zu ZigBee wechseln?

Autor: Christian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Dirk Tostmann (tostmann)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich bin auch voll der Fan von Hardware die schon fertig ist.
(Das Problem beim CC ist zudem, dass der nur gut mit anderen CC's kann, 
wenn man die coolen Features der fast automatischen Datenübertragung 
nutzen will. Bei ZigBee regelt das der Standard)

Genau deshalb steckt auch in unserem CUL so ein CC. Der kann mit den 
HomaticDevices reden aber auch natives AM um die Vorgänger zu bedienen.

Heisst: an der Hardware soll es nun nicht scheitern.

Frage ist eher: Gibts ein offenes Protokoll, was man dann einfach 
implementiert?

Was ist mit: http://de.wikipedia.org/wiki/Z-Wave ?

Autor: Christian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Dirk Tostmann (tostmann)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ist die Frage eher: Welches Protokoll ist es wert implementiert zu 
werden. ;)

Es kann und sollte auch auf anderen Medien/Kabeln laufen.

Ich hatte immermal vor alles per Jabber und Messages zu machen, weil im 
Prinzip ja alles Events sind.
Kleine BOTs können dann die Steuerung, so nötig, übernehmen ... Per 
Publish&Subscribe können die sich die relevanten Events abonieren.

Wenn man sich darauf einläßt hat man schon ein Protokoll, muß es 
natürlich "binarisieren" ...

Schicke eine Nachricht per Jabberclient aus dem Büro an: 
Heizung@beiTOSTi.zuHause

T> wie geht?
H< alles ok, 18 Grad
T> Vorlauf: 28 Grad
H< Ok

auf dem Medium, Kabel oder Air natürlich etwas gepackter ...

Autor: Christian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Dirk Tostmann (tostmann)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, dann fangen wir unten an zu "stormen":

aus Beitrag "Funkübertragungen verschlüsseln" der Vorschlag:
http://de.wikipedia.org/wiki/CCMP

Wie man ggfs. Schlüssel tauscht (und wo speichert) muß man sehen ...

AES ist ohnehin cool, da von den neuen XMegas nativ unterstützt (falls 
man doch selbst löten will).

Autor: Christian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Dirk Tostmann (tostmann)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das dachte ich doch: alles schon erfunden! Fragt sich nur wieso sich ELV 
so immun verhält und auf XOR setzt? Auch egal, wollen wir ja gerade für 
die lösen :)

Also das ist Transport-Level ... Gibts echt nix fertiges für dden 
Payload?

Wie wärs mit einfachen C-"unions":

LEN,TYPE,DATA...

Autor: Christian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Für die Payload schlage ich grob sowas vor:
typedef struct
{
  unsigned int direction:1;
  unsigned int disableDefaultResponse:1;
  unsigned int reserved:6;
} payloadControl_t;

typedef struct {
   uint8 objectId;
   uint8 transActionSequencenum;
   uint8 commandId;
} payloadHeader_t;

/* ReadAttributeCommand: right after the payload header */
typedef struct
{
  uint16 attrID;            // attribute ID
  uint8  dataType;          // expected attribute data type
} ReadAttributeCommand_t;

/* WriteAttributeCommand: right after the payload header */
typedef struct
{
  uint16 attrID;            // attribute ID
  uint8  dataType;          // attribute data type of following data
  uint8  data[];            
} WriteAttributeCommand_t;

/* Response to command: right after the payload header */
typedef struct
{
  uint8 status;
} Response_t;

/* Payload directions (Requester->Responder, Responder->Requester)  */
#define DIR_REQ_RSP                           0x00
#define DIR_RSP_REQ                           0x01

/* Data Types (from ZCL) */
#define DATATYPE_NO_DATA                            0x00
#define DATATYPE_DATA8                              0x08
#define DATATYPE_DATA16                             0x09
#define DATATYPE_DATA24                             0x0a
#define DATATYPE_DATA32                             0x0b
#define DATATYPE_BOOLEAN                            0x10
#define DATATYPE_BITMAP8                            0x18
#define DATATYPE_BITMAP16                           0x19
#define DATATYPE_BITMAP24                           0x1a
#define DATATYPE_BITMAP32                           0x1b
#define DATATYPE_UINT8                              0x20
#define DATATYPE_UINT16                             0x21
#define DATATYPE_UINT24                             0x22
#define DATATYPE_UINT32                             0x23
#define DATATYPE_INT8                               0x28
#define DATATYPE_INT16                              0x29
#define DATATYPE_INT24                              0x2a
#define DATATYPE_INT32                              0x2b
#define DATATYPE_ENUM8                              0x30
#define DATATYPE_ENUM16                             0x31
#define DATATYPE_SEMI_PRECISION                     0x38
#define DATATYPE_SINGLE_PRECISION                   0x39
#define DATATYPE_DOUBLE_PRECISION                   0x3a
#define DATATYPE_OCTET_STRING                       0x41
#define DATATYPE_CHAR_STRING                        0x42
#define DATATYPE_TIME                               0xe0
#define DATATYPE_DATE                               0xe1

/* Command ID */
#define COMMAND_READ_ATTRIBUTE                      0x01
#define COMMAND_WRITE_ATTRIBUTE                     0x02

/* ------------------------------------------------------*/
/* internal object representation */
/* ------------------------------------------------------*/

/* Access Control Bitmask */
#define ACCESS_CONTROL_READ                         0x01
#define ACCESS_CONTROL_WRITE                        0x02

typedef struct {
   uint16  attributeId;         
   uint8   dataType;       
   uint8   accessControl;  
   void    *dataPtr;      /* Pointer to "normal" program variable */
} attributeRecord_t;

typedef struct {
   uint8               objectId;
   uint16              numAttrbutes;
   attributeRecord_t   attribute[];
} objectRecord_t;

#define OBJECT_ID_SYSTEM                            0x01
#define OBJECT_ID_LIGHTCONTROL                      0x02
#define OBJECT_ID_HEATING                           0x03

/* OBJECT_ID_SYSTEM attributes */
#define OBJ_SYSTEM_ATTR_NAME                        0x0001

/* OBJECT_ID_LIGHTING attributes */

/* OBJECT_ID_HEATING attributes */


Autor: Christian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oh, payloadHeader_t müsste so aussehen:
typedef struct {
   payloadControl_t pC;  
   uint8            objectId;
   uint8            transActionSequencenum;
   uint8            commandId;
} payloadHeader_t;

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

Autor: Dirk Tostmann (tostmann)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Na los ... ich bin dabei.

Was brauchen wir an Hardware? Ich denk' UARTs tun es für einen Anfang. 
Geht ja vorerst ums Protokoll ...

Wo hosten wir das?

Ganz wichtig: Hast' schon einen Namen dafür ;)

Autor: Christian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
:-)

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?

Autor: Dirk Tostmann (tostmann)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also den CC1101 kannst Du als Socket oder serielles Interface 
idealisieren (Paket basiert). Praktisch wird in eine FIFO geschrieben, 
LEN, DATA ... dann TX-Strobe ... und die andere Seite(n) melden sich mit 
INT bei empfangenen Daten und CRC ok (macht er selbst).

UDP-Broadcasts treffen es am ehesten.

Wiki kann ich bei busware.de bieten ... Code bei Google? BerliOS macht 
cvs, das ist mir lieber!

Autor: Christian (Gast)
Datum:

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

Würde SVN bevorzugen. :-)

Autor: Christian (Gast)
Datum:

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

Autor: Dirk Tostmann (tostmann)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, dann ziehen wir zu Google ... Name?

Autor: ein (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dirk Tostmann (tostmann)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich dachte gerade darüber nach als einfachen Test mal KNX-RF 
draufzuspielen, die HW sollte das locker können.

Jedoch: Kann es sein, daß KNX-RF komplett unverschlüsselt ist?

Autor: auch ein (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ja, KNX-RF ist komplett unverschlüsselt.

Autor: Harald (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Klaus M. (muek)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wurde dieses Projekt eigentlich weitergeführt, oder ist es wie viele 
Andere auch im Sande verlaufen ???

Autor: Jörg S. (joerg-s)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian schrieb:
> Ich muss keine Platinen machen lassen,
> keine Bauteile bei Farnell oder anderen Distris besorgen, bei denen man
> als Otto-Normal-User nicht bestellen kann.
Nur so nebenbei, bei Farnell kannst du als Privatperson über den 
hbe-Shop bestellen.

Autor: Christian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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. ;-)

Autor: Guru (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Udo Bösau (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schade, wohl wieder einmal etwas im Sande verlaufen :-(

Autor: Christian (Gast)
Datum:

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

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.

Autor: Moritz (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Christian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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&ri...

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

Autor: Noberto (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Roger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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 ?

Autor: Matthias M. (matthias_m69)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Roger: ich glaube kaum, dass Du irgendeine Firmware auslesen kannst. 
Die werden alle kopiergeschützt sein. Da müsstest Du schon selbst eine 
schreiben.

Autor: trilu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: jabdoa (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.