Funk-Heizungsregler-System MAX!

[Maurice M. (maurice2k)]

Hallo zusammen,

ich hatte mir zum Testen die sehr günstige Funk-Heizungsregler-System 
"MAX!" von ELV (gibt es auch in anderen Varianten vom selben Hersteller) 
zugelegt.

Das System besteht aus Funk-Heizkörperthermostaten, Wandthermostaten, 
Fensterkontakten und einer zentralen Steuereinheit, dem "Cube 
LAN-Gateway". Mittels letzterem lässt sich das System auch von außen 
steuern, d.h. es können Soll-Temperaturen für verschiedenen 
Zeitintervalle festgelegt werden.

Und hier sind wir auch an der Schwachstelle des Systems: Übertragen 
werden jeweils nur die Soll-Temperaturen und nicht die Ist-Temperaturen.
Da sowohl die Heizkörperthermostaten als auch die Wandthermostaten diese 
Messen können, müsste es doch möglich sein, diese auch zu übertragen...

Was bringt einem eine Soll-Temperatur wenn diese niemals erreicht wird 
-- Gründe hierfür gibt es genug. Heizung aus/defekt, Kesseltemperatur zu 
niedrig etc.

Hat jemand von euch dieses System und würde dieses gerne erweitern? Ich 
bin (noch) kein Mikrocontroller-Profi, aber wenn man es schafft die 
Software auszulesen...

Viele Grüße
Maurice.


[Keywords: Funk-Heizungssteuerung, Heizungssteuerung, MAX 
Heizungssteuerung, Funk-Heizkörperthermostat, Funk-Heizungsregler]

[Maurice M. (maurice2k)]

Hier das Innenleben des Cubes. Ist ein Atmel AT91SAM7X512 Prozessor 
drauf und man kann auf cube002.jpg links unten wohl das JTAG-Interface 
sehen ("ST3": 2x10 Pins ARM JTAG?).

Was könnte "ST1" und "ST2" sein?

[nokia001 (Gast)]

Hi,

das hast du vollkommen recht. Die Ist Temperatur sollte man schon 
angezeigt bekommen.
Hier gibt es schon mal einen Ansatz alle Daten aus CUBE zu bekommen 
(http://www.mega-nas.de/max/readerscript.php?host=&port=). Leider ohne 
IST-Temperatur.

Beitrag "CRC Berechnung für ETH comfort 200", dies könnte auch ein wenig 
weiter helfen.

Das beste wäre natürlich die Erweiterung des Cubs. Ich bin gerne bereit 
mit zu testen, falls jemand die Idee hier mit aufgreift.

Viele Grüße

[Klaus (Gast)]

Hi!

Ich hab mit vor ein paar Tagen auch das MAX System installiert. Und 
spiele seit dem mit dem Gedanken, ob man die Cube Firmware nicht 
irgendwie erweitern könnte. Ich wäre bei so einem Projekt also auch 
dabei!

[holger (Gast)]

>Ich bin (noch) kein Mikrocontroller-Profi, aber wenn man es schafft die
>Software auszulesen...

Das wird nicht gehen. Leseschutz. Und selbst wenn kommt da
nur Assemblercode bei raus den man kaum erweitern kann.
Also: Selber Firmware schreiben bzw. den Cube komplett
neu entwickeln.

[Stefan W. (wswbln)]

...mal 'ne Frage am Rande: War das ein Bausatz zum Selberlöten, oder 
kommt das so als Fertiggerät?

[Klaus (Gast)]

Stefan Wimmer schrieb:
> ...mal 'ne Frage am Rande: War das ein Bausatz zum Selberlöten, oder
> kommt das so als Fertiggerät?

Es gibt beides. Wobei ich vermute, dass bei dem Bausatz auch nur die 
Platine ins Gehäuse gesetzt werden muss. Ich glaube nicht, dass man bei 
ELV Bausätzen TQFP und andere SMD Bausätze löten muss.

[Klaus (Gast)]

Es gibt scheinbar schon ein paar Informationen zu dem System zu finden:

http://blog.hekkers.net/2011/08/29/unravelling-the-elv-max-heating-control-system-protocol/

[Maurice M. (maurice2k)]

@Stefan: Es war ein Fertigprodukt, aber an cube005.jpg sieht man klar, 
dass da noch Hand angelegt wurde -- was bei kleinen Fertigungsreihen 
wohl gängig ist, wenn ich da richtig informiert bin. Allerdings hat mich 
die Qualität der Ausführung "schmunzeln" lassen. Insgesamt ist die ganze 
Platine relativ verschmutzt (u.a. Flecken auf Prozessoren) und mit 
Fingerabdrücken übersät. Vllt. ein Bausatz, der zurückging g.

@Klaus: Danke für die Infos! Kannte ich noch nicht, obwohl ich gründlich 
gesucht habe -- wohl aber nur im deutschsprachigen Raum.
Was dort gemacht wird, habe ich auch bereits analysiert; es handelt sich 
dabei um das Protokoll der Java-Software auf dem Rechner mit dem Cube.
Der Cube hat maximal einen Pseudo-Webserver drauf und lauscht zwar auf 
Port 80, spricht aber kein echtes HTTP.
Darüber gibt es aber auch keine IST-Temperatur, soweit ich gesehen habe.

@holger: Ja, möglicherweise Leseschutz. Zumindest unterstützt der 
Prozessor das. Könnte das evtl. auch das Problem mit J-LINK erklären: 
Beitrag "J-Link und AT91SAM7X512" ?
Auf der anderen Seite gab es auch eine Firmware-Update-Möglichkeit über 
die Java-Software, ganz am Anfang.... Das wäre auch ein Angriffspunkt.


Und jetzt nochmal hallo an alle zusammen!

Es freut mich, dass der Thread hier etwas belebt wird und es mögliche 
Mitstreiter gibt :=)

Ich bin mir aber gar nicht sicher, ob eine Erweiterung des Cube das 
Richtige ist, da vermutlich (ich bin fast überzeugt) die IST-Temperatur 
gar nicht an den Cube geschickt wird, sondern im Thermostat am Regler 
(die dort nicht mal angezeigt wird) oder im Wandthermostat verbleibt.
Das Wandthermostat habe ich auch zerlegt, kann aber dank Epoxid 
Chip-On-Board ("schwarzer Klecks") nicht erkennen, um was es sich da 
handelt.

D.h. die Idee war erstmal die Software des Cubes zu disassemblieren und 
zu verstehen was für Daten dieser erhält. Vielleicht wäre es hier 
einfacher das Funkprotokoll mitzuschneiden; dazu fehlt mir bisher aber 
die Technik und die Erfahrung (sollte wohl mit einem einfachen RFM12 auf 
einem Eval-Board gehen?).

Falls doch herauskommt, dass die Thermostate die IST-Temperatur 
mitsenden, kann man entweder den Cube "pimpen" oder eine eigene 
Steuerzentrale basteln.

Ich werde nachher mal Bilder vom Wandthermostat online stellen. 
Vielleicht kann jemand etwas damit anfangen. Auch hier gibts einige 
offensichtliche Schnittstellen zur Außenwelt.

Viele Grüße
Maurice.

[Maurice M. (maurice2k)]

Anbei ein paar Bilder des Wandthermostats.

Aufgebaut aus zwei Platinen, die mittels 2x6-Pin Steckleiste verbunden 
werden (Stecker auf wandthermostat001.jpg; Buchse auf 
wandthermostat005.jpg).

wandthermostat001.jpg zeigt die Frontplatine von hinten;
wandthermostat004.jpg zeigt die Frontplatine von vorne.


Irgendwelche Theorien?

[holger (Gast)]

>@holger: Ja, möglicherweise Leseschutz. Zumindest unterstützt der
>Prozessor das. Könnte das evtl. auch das Problem mit J-LINK erklären:
>Beitrag "J-Link und AT91SAM7X512" ?
>Auf der anderen Seite gab es auch eine Firmware-Update-Möglichkeit über
>die Java-Software, ganz am Anfang.... Das wäre auch ein Angriffspunkt.

Was für ein Angriff? Bootloader vermutlich. Auslesen geht auch nicht
denke ich mal.

>D.h. die Idee war erstmal die Software des Cubes zu disassemblieren und
>zu verstehen was für Daten dieser erhält.

Einen ARM disassemblieren. Na viel Spass damit. Du scheinst eine
Menge Zeit zu haben.

[Maurice M. (maurice2k)]

holger schrieb:
>>@holger: Ja, möglicherweise Leseschutz. Zumindest unterstützt der
>>Prozessor das. Könnte das evtl. auch das Problem mit J-LINK erklären:
>>Beitrag "J-Link und AT91SAM7X512" ?
>>Auf der anderen Seite gab es auch eine Firmware-Update-Möglichkeit über
>>die Java-Software, ganz am Anfang.... Das wäre auch ein Angriffspunkt.
>
> Was für ein Angriff? Bootloader vermutlich. Auslesen geht auch nicht
> denke ich mal.

Angriffspunkt die Software zu modifizieren. Keine Ahnung wo er das 
Update hingeladen hat.


>>D.h. die Idee war erstmal die Software des Cubes zu disassemblieren und
>>zu verstehen was für Daten dieser erhält.
>
> Einen ARM disassemblieren. Na viel Spass damit. Du scheinst eine
> Menge Zeit zu haben.

Nein, leider eher das Gegenteil. Habe aber lange genug x86er ASM 
programmiert; ARM hat natürlich einen etwas anderen Befehlssatz, aber 
die wesentlichen Punkte wird man schnell herausfinden können.

Hast Du eine bessere Idee?

[Klaus (Gast)]

Maurice Maurice schrieb:
> Auf der anderen Seite gab es auch eine Firmware-Update-Möglichkeit über
> die Java-Software, ganz am Anfang.... Das wäre auch ein Angriffspunkt.

Ja, man müsste mal mit WireShark mitschneiden, was bei einem 
Firmwareupdate passiert. Leider bin ich da noch nicht auf die Idee 
gekommen. Und nun hat mein Cube schon die aktuellste Firmware.

Falls jemand nen neuen Cube hat und beim ersten verbinden nen Wireshark 
nen anderen Netzwerksniffer mitlaufen lassen könnte, wäre das super!

[Klaus (Gast)]

Maurice Maurice schrieb:
> D.h. die Idee war erstmal die Software des Cubes zu disassemblieren und
> zu verstehen was für Daten dieser erhält. Vielleicht wäre es hier
> einfacher das Funkprotokoll mitzuschneiden; dazu fehlt mir bisher aber
> die Technik und die Erfahrung (sollte wohl mit einem einfachen RFM12 auf
> einem Eval-Board gehen?).

Die ETH 200 Serie ist ja recht ähnlich. Die lassen wich per RFM12 
auslesen, bzw. lässt sich der Verkehr mitschneiden. Vielleicht haben wir 
Glück, und die MAX! Thermostate benutzten das gleiche Protokoll.

[Klaus (Gast)]

Auch ein interessanter Link:

http://blog.hekkers.net/tag/elv-max/

[A. S. (telekatz)]

Maurice Maurice schrieb:
> Hier das Innenleben des Cubes. Ist ein Atmel AT91SAM7X512 Prozessor
> drauf und man kann auf cube002.jpg links unten wohl das JTAG-Interface
> sehen ("ST3": 2x10 Pins ARM JTAG?).
>
> Was könnte "ST1" und "ST2" sein?

Im aktuellen ELVjournal 1/2012 ist der Schaltplan des MAX! Cube 
abgedruckt. ST3 ist das JTAG interface.

ST1 ist mit UART0 belegt, ST2 mit dem Debug Port.
Pinbelegung ist:
1 +3,3V
2 TXD
3 RXD
4 GND

[Maurice M. (maurice2k)]

Habe der Java-Anwendung mal etwas "auf die Finger geschaut". Firmware 
liegt dort in verschlüsseltem Zustand bei und wird mittels UDP-Paketen 
auf den Cube übertragen. Dazu wird erst mittels UDP der Bootloader 
aktiviert und rebootet.

Es muss also so sein, dass der Bootloader die Firmware decrypted und 
flashed.
Dabei scheint es sich um eine "ernsthafte" Verschlüsselung zu handeln; 
nicht nur XOR o.ä., da die Byteverteilung relativ gut ist (~3% 
Schwankungsbreite bezogen auf Standardabweichung). Theoretisch lässt 
sich das auch mit XOR erreichen, dann bräuchte man aber hinreichend 
große Schlüssel, was in diesem Fall unpraktisch wäre. Tippe auf AES oder 
XTEA. Mist ;)


@telekatz: Danke für den Hinweis, habe das Magazin mittlerweile gekauft 
und mir den Schaltplan angesehen. Versuche mit ST1 (UART0) sind leider 
fehlgeschlagen, allerdings war es gestern auch schon spät und ich 
fürchte ich habe ein serielles Null-Modem-Kabel erwischt (und nicht 
vorher durchgemessen ;), bei dem TxD und RxD vertauscht sind und ich 
dann letztenendes doch TxD vom Rechner auf TxD des Cubes geschaltet habe 
(analog mit RxD)...

[Ferdinand M. (fermoll)]

Klaus schrieb:
> Maurice Maurice schrieb:
>> Auf der anderen Seite gab es auch eine Firmware-Update-Möglichkeit über
>> die Java-Software, ganz am Anfang.... Das wäre auch ein Angriffspunkt.
>
> Ja, man müsste mal mit WireShark mitschneiden, was bei einem
> Firmwareupdate passiert. Leider bin ich da noch nicht auf die Idee
> gekommen. Und nun hat mein Cube schon die aktuellste Firmware.
>
> Falls jemand nen neuen Cube hat und beim ersten verbinden nen Wireshark
> nen anderen Netzwerksniffer mitlaufen lassen könnte, wäre das super!

Hallo
Ich habe die Anmeldung des Cube und das Herunterladen des Updates mit 
WireShark mitgeschnitten, bin jedoch mit de Programm nicht vertraut und 
kann deshalb die Daten ( 6MB) nicht zurecht schneiden. Wenn Interesse 
besteht, stelle ich die gerne zur Verfügung.

[Micha K. (klemic)]

Eine (selbstgeschriebene) Firmware ließe sich ja mittels SAM-BA (nachdem 
man den Chip mit Hilfe des Erase Pins, Pin 92, auf dem MAX Board müsste 
sich ein Jumper J1 für diesen Zweck befinden, gelöscht hat) per USB ganz 
einfach einspielen... Mein erster Blick sagt mir, dass alles dazu auf 
der Platine richtig bestückt sein sollte...

Mein Gedanke dabei ist das ganze Teil platt zu machen und eine eigene 
Firmware zu schreiben...

[Micha K. (klemic)]

Achja, als Ausgangsbasis kann man ja das Demo des "uIP Embedded Web 
Server Demo using the FreeRTOS SAM7X ARM port" verwenden, das für das 
AT91SAM7X-EK Evaluation Board geschrieben ist und dessen Schaltplan, 
zumindest im Ethernet Teil (PHY ist identisch), nur marginal vom 
MAX-cube abweicht...

Den Rest, die LEDs, Tasten, das Tranceiver Modul und den Flash Speicher, 
kriegt man ja dann auch locker angepasst bzw. angesprochen...

[Maurice M. (maurice2k)]

@Micha:

Danke für die Infos. J1 gibt es, aber Jumper als solcher nicht 
vorhanden. Kann man aber natürlich leicht überbrücken.

Die Frage ist, ob einen das so richtig weiterbringt. Zumindest mir geht 
es erstmal darum, herauszufinden, ob der Cube die IST-Temperatur 
bekommt.
Wenn nein, dann muss ohnehin das (Wand-)Thermostat als auch der Cube 
angepasst werden -- oder man steuert das dann ganz ohne Cube.

Einmal überschrieben ist der Cube erstmal "kaputt"; eine neue 
ELV/eQ3-Firmware wird man dann mangels Bootloader auch nicht aufspielen 
können. Die Firmware, die der Java-Software beiliegt scheint zumindest 
verschlüsselt zu sein, die Übertragung an den Cube wird wohl auch 
verschlüsselt erfolgen, der Schlüssel ist im Bootloader.

Sprich: Bevor man sich die Mühe macht den Cube neu zu erfinden, 
vielleicht lieber erstmal den Funkverkehr mitschneiden... Oder?

[Micha K. (klemic)]

Hallo Maurice,
klar, wenn man den J1 beim Einschalten brückt, ist alles im AT91SAM7 
weg... Auch der ELV Bootloader. Der Cube ist dann erst mal 
unbrauchbar...

Wenn man das System wieder so zum Laufen bringen möchte, wie es vorher 
war (plus eigene Erweiterungen) muss man natürlich erst mal den 
Funkverkehr entschlüsseln... Allerdings scheint es da schon was im Netz 
zu geben... Habe ich aber noch nicht geprüft...

Ich habe bei mir zu Hause mit den ELV Ventilen FHT8V angefangen und 
wollte den Cube dann nur als mein proprietäres Interface zum Web 
verwenden, der kann dann noch andere Aufgaben mit übernehmen, Wake On 
Lan für den PC usw...

Immerhin liegen 40€ für den Bausatz vom Cube im Bereich eines Eval 
Boards und man hat gleich ein Gehäuse drumherum (ich warte aber mal 
noch, bis es wieder mal einen 5€ Gutschein von ELV gibt)

[A. S. (telekatz)]

Micha Kleiber schrieb:
> Immerhin liegen 40€ für den Bausatz vom Cube im Bereich eines Eval
> Boards und man hat gleich ein Gehäuse drumherum (ich warte aber mal
> noch, bis es wieder mal einen 5€ Gutschein von ELV gibt)

Bis zum 26.02. läuft noch eine Gutscheinaktion bei ELV mit 5€ Gutschein 
ab 25€ Wahrenwert. Zusätzlich noch Versandkostenfrei ab 50€ Wahrenwert.
Gutscheincode: XKT001

Auf meinenm Cube habe ich mittlerweile NUT/OS installiert. Habe vor, in 
den Cube noch eine RS232 Schnittstelle und einen SD Slot einzubauen und 
ihn als Datenlogger für meinen Heizkessel zu verwenden. Eventuell auch 
noch zum loggen von FS20/FHT/Wettersensoren.

[Micha K. (klemic)]

Hi A.S.,
danke für den Hinweis, hab' mir gleich 'nen Würfel bestellt.

Ich werfe dann auch mal einen Blick auf das Nut/OS, oder kannst du Deine 
Sourcen posten?

[Maurice M. (maurice2k)]

Ich wollte meinen Cube noch nicht killen... ;-)

Müsste man in SAM-BA eigentlich Daten sehen? Also Memory usw.? Bei mir 
sind alle Werte immer 0x8?

Nutze einen USB/TTL Converter mit CP2102 Chip und habe alternativ auch 
mal den Pollin RS232-TTL-Wandler (5V) mit Widerstand angeschlossen...

Sollte man auf der Console etwas sehen bei Connect mit 115200 baud und 
8N1?

[Micha K. (klemic)]

Hi Maurice,

nee, auslesen is nich... Das ist Atmels Methode den Code eines 
Geräteherstellers gegen Kopieren zu schützen...

Erst nachdem man den Chip mit dem Erase Jumper gelöscht hat, ist der USB 
Port für SAM-BA aktiv und Du kannst direkt mittels USB Kabel und SAM-BA 
flashen (Der Treiber wird (wenn ich mich richtig erinnere) automatisch 
installiert, wenn man den gelöschten AT91SAM7 per USB anstöpselt)... 
Wenn der Chip nicht gelöscht ist, sind die Ports für USB und RS232 in 
der Hand des Codes von ELV und SAM-BA kann damit nichts anfangen 
(offenbar hat ELV ja auch keinen Code für USB im Chip, sonst würde 
Windows ja ein USB Gerät melden)...

RS232 geht wohl auch, aber ich  bin mir nicht sicher ob mit allen 
AT91SAM Derivaten und welcher Port verwendet wird, das müsste man in den 
Infos von Atmel erst nachlesen. Auf jeden Fall wird das SAM-BA Protokoll 
erst aktiv, wenn der Chip gelöscht ist, dann springt der AT91SAM bei 
Reset in einen fest einprogrammierten Bootloader der den Code für das 
Ansprechen des USB Ports enthält (nicht löschbar)...

Ich habe mal mit einem AT91SAM7 (ICSWIFT) Board gespielt und nur den USB 
Port verwendet. Das funzt einfach und zuverlässig. Ich werde meinen 
selbst geschriebenen Code auch erst auf dem ICSWIFT laufen lassen, bevor 
ich den Cube plätte, das wird also noch dauern...

[Maurice M. (maurice2k)]

Hi Micha,

vielen Dank für die Erklärungen!

Ich hatte gehofft, nachdem ELV den UART rausführt, dass es dort auch 
irgendwas an Debug output ausgegeben wird, ähnlich wie man das von 
diversen Routern kennt. Andere Baudraten etc. könnte man natürlich noch 
durchtesten.

Ich versuche mal den Funkverkehr aufzuzeichnen, sofern ich das 
hinbekomme.

Grüße
Maurice.

[Micha K. (klemic)]

Hat jemand weitere Infos oder ein Datenblatt zu dem Funkmodul?

[A. S. (telekatz)]

Im Funkmodul steckt ein CC1100 drinn.
http://www.ti.com/product/cc1100

[Micha K. (klemic)]

Ah, danke für die Info. Cool, dann müsste der ja mit dem TI 
EZ430-Chronos-868 Kit kommunizieren können.

[Micha K. (klemic)]

Hi,

so, jetzt habe ich angefangen mal mit FreeRTOS zu spielen...
Ich war vor Ewigkeiten erfolgreich mit der Anleitung, die zum FreeRTOS 
Demo verfügbar war, aber die ist wegen neuerer Versionen nicht mehr 
sonderlich hilfreich...

Ich versuche daher momentan erfolglos Eclipse Indigo und den 
CodeSourcery Lite Compiler dazu zu bringen das FreeRTOS Demo zu 
kompilieren. In Eclipse habe ich das CDT Plugin von 
http://gnuarmeclipse.sourceforge.net/updates installiert und damit wird 
die Codesourcery Toolchain auch in Eclipse zur Auswahl angeboten...
Aber beim Versuch zu kompilieren bekomme ich die Meldung:
"cs-make: *** No rule to make target `RTOSDemo', needed by `all'. 
Stop."

Hat jemand mit diesen Tools Erfahrung und ist bereit diese zu teilen?

Viele Grüße,
Micha

[Kingsammy (Gast)]

Hallo an alle hier im Forum,

für Interessierte gibt es hier Bilder vom Innenleben des 
MAX!Thermostats/-stellers:

http://max.kopsan.de/heizkorperthermostat-nackt/

Vielleicht kann damit jemand etwas anfangen...

Grüße

Kingsammy

[Micha K. (klemic)]

Hallo,

wenn man jetzt wüsste welcher Prozessor unter dem Lacktropfen im 
Thermostat steckt...

Ich bin gerade eher geneigt den Transceiver von der Cube Leiterplatte 
auszulöten und durch einen RFM12 zu ersetzen um dann die Eurotronic 
Sparmatic Thermostate zu verwenden (da ist ein Atmel Mega169 drin, ein 
RFM12 lässt sich nachrüsten, siehe 
http://www.mikrocontroller.net/articles/Sparmatic_Heizungsthermostate). 
Das ganze kriegt dann eine eigene Firmware...

Bezüglich Programmierung Cube bin ich nun soweit auf Eclipse zu 
verzichten und ganz einfach per Kommandozeile zu kompilieren. Das klappt 
soweit...
Mit Eclipse kriege ich das leider einfach nicht hin...

[kawa0815 (Gast)]

Micha Kleiber schrieb:
> wenn man jetzt wüsste welcher Prozessor unter dem Lacktropfen im
> Thermostat steckt...

Nun, im ELVjornal 2/2012 war der Schaltplan des Thermostaten zu finden.
ELV bietet ja auch den Thermostaten als AAR- Bausatz an.
Allerdings ist IC2 nicht bezeichnet. IC2 ist natürlich der der 
Mikrocontroller.

Mal ein paar Daten.

Gehäuse eventuell ein LQFP64

VDD 2,3 V an PIN 9
GND an PIN 10
2 Quarze 1x 4,19 MHz an XIN (PIN 12) und XOUT (PIN 11)
         1x 32,768 KHz an XTIN (PIN 14) und XTOUT ((PIN 15)

Das LCD hängt direkt am Mikrocontroller
COM0 PIN2
COM1 PIN3
COM2 PIN4
COM3 PIN5

SEG 0-9 an PIN5-14)


Kawa

[kawa0815 (Gast)]

kawa0815 schrieb:
> Allerdings ist IC2 nicht bezeichnet. IC2 ist natürlich der der
> Mikrocontroller.

So, ich hab mal gesucht und bin fündig geworden.

Der im Schaltplan nicht bezeichnete IC2 ist ein zum SAMSUNG 
S3F8275/278/274
pinkompatibler Microprozessor (PIC).

Ich gehe mal davon aus, dass er auch funktionskompatible ist.

Auslesen und programmieren sollte sich der MC über den PRG-Port lassen.


kawa

[mxii (Gast)]

interessant wäre ob diese misteriösen trx868 module von elv
(wo man nirgens informationen zu findet?!)
mit dem rfm12 kommunizieren können ..

das wäre super .. dann könnte man den cube komplett ersetzen,
bzw nur die SW .. je nach aufwand und lust auch die HW ..

gibt es schon mehr infos?

noch jmd dran?

[mxii (Gast)]

ach und hat jmd die schaltpläne und könnte sie einscannen?
das wäre perfekt..
.. bin auch sehr interessiert das ganze system noch etwas zu customizen 
:)

[Micha K. (klemic)]

Wie oben im Thread schon erwähnt sind in den Transceiver Modulen von ELV 
die Texas Instruments CC1100 Chips enthalten, die Beschaltung ist 
praktisch fest vorgegeben, und ist im TI Datenblatt dokumentiert. Bei 
Ebay gibt's Module mit dem CC1101 Nachfolgechip, die müssten mit dem ELV 
Modul kommunizieren können.
Der RFM12 kann das ziemlich sicher nicht.

Die Schaltpläne gibt's bei ELV in den zugehörigen Journalartikeln als 
PDF (kostenplichtiger Download), bzw. liegen den Bausätzen in gedruckter 
Form bei. Die sind natürlich urheberrechtlich geschützt, können hier 
also nicht gepostet werden...

Grüße, Micha

[Sascha E. (mxii)]

oh ja, sorry..
den kleinen Post hab ich überlesen..
Wenn es der CC1100 ist, kann der RFM12 damit kommunizieren ..
Gibt ein Projekt wo die Betty (Fernbedienung mit CC1100 auf 433 Mhz) mit 
einem RFM12 spricht..

Super ! :)
Habe ein RFM12 mit 868 Mhz hier .. werde mal versuchen da etwas mit zu 
schneiden .. ;)

Danke für die Infos..
.. falls es was neues gibt, melde ich mich ..

[Schurli (Gast)]

Servus,

ich hätte auch noch eine kleine Frage. Hoffe das der thread noch 
halbwegs aktiv ist.^^
Das auf der Platine des MAX! Cube als transceiver ein CC1100 Funkchip 
von TI zum Einsatz kommt hab ich bereits rausfinden (rauslesen im Forum) 
können.
Mich würde nun stark interessieren welche Modulation des Signals zum 
Einsatz kommt.
Hat irgendjemand hier dafür schon Messungen durchgeführt?
Ich würde ja selber im HF-Labor der Hochschule messen, aber ich habe 
keinen Cube^^
Ich vermute ja das wie bei HomeMatic eine FSK mit 20 khz Datenrate zum 
Einsatz kommt, aber 100% sicher bin ich mir da nicht.
Da  laut eQ-3 ein Wandthermostat maximal 8 Heizkörperthermostate 
unterstützt.
Geht man davon aus das dies die maximale Anzahl von Geräten ist bei der 
eine problemlose Kommunikation stattfinden kann und theoretisch noch 
einige mehr möglich wären. Sind 8 geräte nicht wirklich viele.
Bezieht man sich dabei auf die maximale relative Frequenzbelegungsdauer 
von <=1% pro Stunde, sendet das System entweder mit einer sehr geringen 
Baud-rate (ca. 1000Baud) oder die einzelnen Telegramme sind einfach 
rießig. :D

Ich will mich erst mal über die verschiedenen eQ-3 Systeme genaustens 
informieren ;)

Über eine Antwort würde ich mich freuen.
Grüße Georg

[A. S. (telekatz)]

Schurli schrieb:
> Da  laut eQ-3 ein Wandthermostat maximal 8 Heizkörperthermostate
> unterstützt.
> Geht man davon aus das dies die maximale Anzahl von Geräten ist bei der
> eine problemlose Kommunikation stattfinden kann und theoretisch noch
> einige mehr möglich wären. Sind 8 geräte nicht wirklich viele.

Nein, man geht hier davon aus, das in einem normalen Raum nie mehr als 8 
Heizkörper sind, die der Wandthermostat Regeln muss. Denn der 
Wandthermostat ist ja nur für die Regelung in einem Raum zuständig. 
Deshalb sind 8 Geräte mehr als ausreichend.
Möglich wären weit mehr, aber praxisfern für die Auslegung des MAX! 
Systems.

[Schurli (Gast)]

A. S. schrieb:
> Nein, man geht hier davon aus, das in einem normalen Raum nie mehr als 8
> Heizkörper sind, die der Wandthermostat Regeln muss. Denn der
> Wandthermostat ist ja nur für die Regelung in einem Raum zuständig.
> Deshalb sind 8 Geräte mehr als ausreichend.
> Möglich wären weit mehr, aber praxisfern für die Auslegung des MAX!
> Systems.

Das macht natürlich auch Sinn :D
So weit hab ich mir garkeine Gedanken gemacht über die Praktische 
Anwendung.
Danke für den kleinen Schubser ;)

Aber über die Modulation weißt du auch nichts genaueres?

[Micha K. (klemic)]

Hallo Schurli,

in meinen Augen macht es keinen Sinn über Details der HF Seite des 
CC1100  auch nur den kleinsten Gedanken zu verschwenden, das macht der 
CC1100 (und Nachfolger, denn der CC1100 ist abgekündigt) doch alles ganz 
alleine ohne dass man sich als Anwender darum kümmern müsste...

Aber wenn man tiefer einsteigen möchte, könnte man einen Blick ins 
Datenblatt werfen, Kapitel 16 hat die Überschrift "Modulation 
Formats"...

Grüße,
Micha

[Schurli (Gast)]

Hallo Micha,

das Datasheet des CC1101 und CC1100 kenn ich zu genüge^^
Auch welche Modulationsarten die Chips unterstützen bei welcher 
Baudrate.
Hätte mich einfach nur mal interessiert welche Modulation eben beim 
Funk-Heizungsregler-System MAX! zum Einsatz kommt.

Natürlich ist mir klar das ich mit dieser Information nicht viel 
Anfangen kann. Bin eben einfach neugierig, da man natürlich über die 
Modulation auch eine Ausage über der die Funkverbindung zwischen den 
Geräten machen kann.

[avrfreak (Gast)]

Hier die CC1101 Init Sequenz für MAX! Erster Wert Register, zweiter der 
Inhalt (nach Reset mit Defaults):

     0x00, 0x08,
     0x02, 0x46,
     0x04, 0xC6,
     0x05, 0x26,
     0x0B, 0x06,
     0x10, 0xC8,
     0x11, 0x93,
     0x12, 0x03,
     0x15, 0x34,
     0x17, 0x00,
     0x18, 0x18,
     0x19, 0x16,
     0x1B, 0x43,
     0x21, 0x56,
     0x25, 0x00,
     0x26, 0x11,
     0x0D, 0x21,
     0x0E, 0x65,
     0x0F, 0x6A,
     0x07, 0x0C,
     0x16, 0x07,
     0x20, 0xF8,
     0x1E, 0x87,
     0x1F, 0x6B,
     0x29, 0x59,
     0x2C, 0x81,
     0x2D, 0x35,
     0x3E, 0xC3,

Danach kann man die Nachrichten ganz normal aus der FIFO des CC1101 
lesen. Diese entsprechen dem Homematic-Frame-Format und sind 
unverschlüsselt, siehe: http://culfw.de/commandref.html#cmd_A

[Dirk T. (tostmann)]

MAX! kann nun auch von einem CUL mit culfw (aus SVN HEAD) 
empfangen/gesendet werden:

Empfang einschalten:

Zr

was senden, z.B. den Nachbarn erfrieren lassen (Thermostat absenken auf 
5C):

Zs0B120440034EA002A5F0000A

Sicherheit gibts keine!

Datenframing: wie bei/siehe Homematic.
Payload: tbd

[Ronny H. (rhb)]

Hallo Dirk,

hat Du nähere Infos über die Payload? Ich habe mal einen "Bus Pirate" an 
den SPI eines Heizungsregler gehängt. Sowohl bei angelerntem 
Wandthermostat als auch ohne direkt an den Cube.

Interessant ist, dass
a) wenn an Wandthermostat angelernt, der Wandthermostat immer im 2 min 
Abstand die IST-Temperatur sendet
b) wenn nur an Cube angelernt unter bestimmten (welche?) Umständen der 
Heizungsregler die IST-Temperatur sendet:
Wenn das 4. Byte eine 0x04 ist, dann ist im 17.Byte die Temperatur: Bsp: 
0xDF=223-> 22.3°C, aber 0x20: dann addiere 0x100->0x120=288=28.8°C
Leider ist das 4. Byte fast immer nur eine 0x02, und dann sendet der 
Thermostat nur seine Ventilstellung im 15.Byte

Diese Pakete vom Regler an den Cube folgen auch nicht komplett der 
Homematic-Spezifikation: das 3. Byte zählt nicht noch, ist also kein 
Sequenz/Paketzähler. Wenn der Regler an den Wandthermostat angelernt 
ist, dann jedoch schon...

Meine Zählweise ist immer inklusive des Kommandos an den CC110x: das 
heißt, Byte 1 ist immer 0x7F (Burst send) oder 0xFF (Burst read).

Hat jemand noch weitere Infos?

PS: die Adressen der einzelnen Geräte sind als QR-Code auf die 
Leiterplatten aufgedruckt, also aufschrauben und Handy zücken ...

Gruß
Ronny

[Matze (Gast)]

Ich weiß nicht ob es jemanden hilft, aber in diesem Forum gibt es auch 
noch Informationen die helfen könnten:

http://www.domoticaforum.eu/viewtopic.php?f=66&t=7015

[Dennis H. (somebuddy)]

Guten Tag,

Was ist denn nun "mittlerweile" mit dem MAX! System in Verbindung mit 
einem CUL und fhem möglich ?
Konnte darüber nichts wirklich etwas finden ?

Kommuniziert fhem nur mit den Wandthermostaten ?
Wird die aktuelle Ventilsteuerung übertragen ? ( Wäre sehr hilfreich für 
meine geplante Vaillant / Wärmebedarfsschaltung )

MAX! und FS20 Komponente lassen sich nicht gleichzeitig verwenden. Somit 
wäre wohl ein zweiter CUL notwendig.

Es steht für mich nun die Entscheidung für ein System ins "Haus".
Das MAX! System gefällt mir dabei am besten.

Die Alternative wäre eben alles auf FHT basierend zu lösen. Das müsste 
ich ,falls eine fhem regelung der max! komponente aus welchen Gründen 
auch immer ausgeschlossen ist.

Vielen Dank
Grüße
Dennis

[thoweiss (Gast)]

Wie jetzt?

Der Thermostat sendet seine Ist-Temperatur?

Aber der Cube gibt die Daten nicht über die LAN-Schnittstelle weiter?



Ronny H. schrieb:
> Interessant ist, dass
> a) wenn an Wandthermostat angelernt, der Wandthermostat immer im 2 min
> Abstand die IST-Temperatur sendet
> b) wenn nur an Cube angelernt unter bestimmten (welche?) Umständen der
> Heizungsregler die IST-Temperatur sendet:
> Wenn das 4. Byte eine 0x04 ist, dann ist im 17.Byte die Temperatur: Bsp:
> 0xDF=223-> 22.3°C, aber 0x20: dann addiere 0x100->0x120=288=28.8°C
> Leider ist das 4. Byte fast immer nur eine 0x02, und dann sendet der
> Thermostat nur seine Ventilstellung im 15.Byte

[Matze (Gast)]

Wenn man der Google-Group "FHEM users" glauben schenkt und den Thread 
"CUL-rfmode MAX" ließt, dann scheint das der Fall zu sein.
Hier der Link zum Thread: 
https://groups.google.com/forum/?fromgroups=#!topic/fhem-users/p06mttMFAs8

Leider habe ich keinen CUL, sonst würde ich gerne dort mitwirken.

[Matze (Gast)]

Maurice Maurice schrieb:
> Habe der Java-Anwendung mal etwas "auf die Finger geschaut". Firmware
> liegt dort in verschlüsseltem Zustand bei und wird mittels UDP-Paketen
> auf den Cube übertragen.

Dir Firmware liegt wirklich der originalen Java-Anwendung bei. Auch wohl 
die Kodierung wie die Datei verschlüsselt ist. Wer damit was anfangen 
kann, bitteschön.

package de.eq3.max.al.local.update;

import 
de.eq3.max.al.local.update.exceptions.InvalidFirmwareFileUpdateException 
;
import java.io.ByteArrayOutputStream;
import java.io.IOException;
import java.io.InputStream;
import java.util.LinkedList;
import java.util.List;

public class FirmwareFile
{
  private final List<byte[]> frames;

  public FirmwareFile(InputStream stream)
    throws InvalidFirmwareFileUpdateException
  {
    this.frames = new LinkedList();
    parse(stream);
  }

  public List<byte[]> getFrames()
  {
    return this.frames;
  }

  private void parse(InputStream stream) throws 
InvalidFirmwareFileUpdateException
  {
    try
    {
      readFrames(stream);
    }
    catch (IOException ex)
    {
      throw new InvalidFirmwareFileUpdateException(ex);
    }
  }

  private void readFrames(InputStream stream) throws IOException
  {
    this.frames.clear();

    byte[] frame = readFrame(stream);
    while (frame != null)
    {
      this.frames.add(frame);
      frame = readFrame(stream);
    }
  }

  private byte[] readFrame(InputStream stream) throws IOException
  {
    int length = readLength(stream);
    if (length > 0)
    {
      return readFrameData(stream, length);
    }

    return null;
  }

  private int readLength(InputStream stream)
    throws IOException
  {
    int high = readByte(stream);
    int low = readByte(stream);

    return high << 8 | low;
  }

  private byte[] readFrameData(InputStream stream, int length) throws 
IOException
  {
    ByteArrayOutputStream outStream = new ByteArrayOutputStream();

    for (int i = 0; i < length; i++)
    {
      int value = readByte(stream);
      outStream.write(value);
    }

    byte[] result = outStream.toByteArray();
    outStream.close();
    return result;
  }

  private int readByte(InputStream stream) throws IOException
  {
    int high = stream.read();
    int low = stream.read();

    return createByte(high, low);
  }

  private int createByte(int high, int low)
  {
    return fromHex(high) << 4 | fromHex(low);
  }

  private int fromHex(int value)
  {
    if ((48 <= value) && (value <= 57))
    {
      return value - 48;
    }
    if ((97 <= value) && (value <= 102))
    {
      return value - 97 + 10;
    }
    if ((65 <= value) && (value <= 70))
    {
      return value - 65 + 10;
    }

    return 0;
  }
}

[retired TL (Gast)]

Ja,

wenn an den Cube angelernt, dann sendet der Heizungsregler bei einer 
Änderung der Ventilstellung die Ist-Temperatur.

Wenn der Heizungsregler an den Wandthermostat angelernt ist, so 
übernimmt der Wandthermostat die Temperaturmessung und sendet die 
Ist-Temperatur alle 2min an den Regler - es wird sozusagen der 
Temperaturfühler ersetzt.



thoweiss schrieb:
> Wie jetzt?
>
> Der Thermostat sendet seine Ist-Temperatur?
>
> Aber der Cube gibt die Daten nicht über die LAN-Schnittstelle weiter?

[thoweiss (Gast)]

Meine Frage wäre jetzt:

Bekommt man aus dem Cube über die LAN-Schnittstelle die Isttemperatur?

Also nicht mit CUL...


Warum sollte der Thermostatantrieb die Isttemp an den Cube senden wenn 
man diese nicht irgendwie auswerten kann?

[rhb (Gast)]

thoweiss schrieb:
> Bekommt man aus dem Cube über die LAN-Schnittstelle die Isttemperatur?
>

Definitiv nicht!

>
>
> Warum sollte der Thermostatantrieb die Isttemp an den Cube senden wenn
> man diese nicht irgendwie auswerten kann?

Das wäre eine Frage an ELV... Die ist-Temp wird nur sehr selten an den 
Cube gesendet - eigentlich nur, wenn sich die Ventilstellung ändert oder 
Einstellungen geändert werden.

[thoweiss (Gast)]

alles klar, danke...

Dann gibt es doch Homematic auf das bitgeschubse hab ich keine lust:-)

[Tzanimir Tzankov (Gast)]

Hallo Micha

hast du geschaft eine funktionierende Firmware fuer dem MAX!Cube zu 
kompilieren?

Tzanimir

[Rudi R. (rudiratlos)]

Hi,
habe mit Hilfe dieses Forums es bewerkstelligt, dass ich das MAX! Cube 
protokoll mittels eines RFM22B Funkmoduls auf meinem RaspberyPI 
empfangen kann. Allerdings werde ich aus den folgenden Rohdaten (nach 
Manchester Dekodierung) nicht schlau:

2912A0051221006028033320019001A004058000010000A0864008403011224036005252 
204024030080

Ich habe gelesen, dass die FHT und Homematic mit einem BidCos 
Algorithmus verschluessselt (bzw. XORed) sind. Gilt dies auch für diese 
Daten? Habe den Decrypt Algorithmus probiert, bekomme allerdings auch 
keine sinnvollen Daten.

Wo komme ich hier weiter.

Von dem CUL Stick werden die MAX! Rohdaten offenbar nocht irgendwie 
aufbereitet, aber wie?

[rhb (Gast)]

Diese Daten sehen überhaupt nicht nach MAX!-Daten aus...
CUL macht nichts anderes, als die ankommenden Daten in einen Hex-String 
zu wandeln, wenn also 0x30 ankommt, "wandelt" CUL zu einem String "30".

Ich denke eher, dass dort Datenmüll zu sehen ist. Ich habe ein 
CC1100-Modul aus ebay (~9Euro) recht einfach mit einem Arduino zum 
laufen bekommen. Mit RFM12 hatte ich immer schlechte Erfahrungen - liegt 
aber vielleicht auch an mir.

[garfield (Gast)]

Hallo Leute

Das Ding hat von der Konzeption her für Einfamilienhausbesitzer einen 
(sehr) großen Haken!
Man kann zwar die Heizkörper damit in allen möglichen Nuancen regeln, 
aber was ist mit der Heizung zb. einer Gastherme selber?

Meine Gastherme könnte man zwar mit einem ganz normalen Schaltkontakt 
steuern/regeln aber genau hier versagt dieses Ding.


Was nützt es einem zb. wenn man mit dem Ecotaster Absenktemperatur 
einstellt weil man das Haus verlässt oder per I-Net Heiztemperatur weil 
man früher heimkommt, die Therme aber immer noch das tun will was ihr 
eigener Thermostat ihr vorschreibt weil man auf diesen keinen Zugriff 
hat?

Also wenn ich nicht gerade einem ausgesprochenen Denkfehler unterliege 
ist dieses Ding aus meiner Sicht ein leider leider wertloses UNDING.

[Micha K. (klemic)]

Hallo garfield,

nun rate doch mal, warum sich die Leute hier bei www.mikrocontroller.net 
mit Selbstbauprojekten und z.B. mit der Modifikation des MAX Systems 
beschäftigen...

Gruß,
Micha

[GOst4711 (Gast)]

hi,

ich habe hier sehr gespannt den Thread gelesen und muß sagen Hut ab was 
Ihr so drauf habt.
Zum Temeratur auslesen beim MAX! habe ich jetzt folgendes gefunden. Bin 
aber noch nicht dazu gekommen das zu testen.

http://www.maxbuddy.de/

Also sollten ja die Geräte wirklich unter bestimmten Umständen die 
Temperatur senden.

GOst4711

[Wolfgang S. (ws1293)]

Hallo

Ich habe auch das Max System installiert
Funktioniert sehr gut , auch mit Max !Buddy
Ich möchte gerne bei meinem Ofen (Buderus Regelsystem 3000) die 
Tag-Nachtumschaltung mit dem Max System schalten.
Also die Zeitschaltuhr überbrücken.
Kann man dazu vielleicht einen Heizungsregler umbauen?

Wolfgang

[Pink S. (pinkshell)]

garfield schrieb:
> die Therme aber immer noch das tun will was ihr
> eigener Thermostat ihr vorschreibt

Ja, aber wenn die Ventile an den Heizkörpern dichtmachen, dann kommt das 
Wasser wärmer zurück und braucht von der Therme nicht so stark 
nachgeheizt werden -> Energieeinsparung.

Aber noch besser wäre es, wenn auch die Therme vom Max! beeinflusst 
würde. Dann würde das Wasser weniger heiß durchs Haus fließen. Bei der 
Vielfalt an Thermen stelle ich mir das aber schwierig vor.

[Wolfgang S. (ws1293)]

Hallo
Ich möchte die Elektronik eines Heizkörperregler
missbrauchen und ein Relais mit Wechsler ansteuern,
um ein Buderussteuergrät anzusteuern.
Gruß,
Wolfgang

[Marek N. (Gast)]

Moin,

weiß jemand, ob das MAX!-System abwärtskompatibel ist zu den bisherigen 
ETH-comfort-Thermostaten von ELV?
Ich habe nämlich bereits einige von diesen und würde sie gerne 
vernetzen, bzw. per SMS steuerbar machen, wenn ich z.B. später heim 
komme.
Neue Hardware möchte ich aber nicht anschaffen.

Beste Grüße, Marek

[Micha K. (klemic)]

Hi Marek,

nein, sie sind nicht kompatibel. Die MAX Thermostate habe eine 
bidirektionale Funkverbindung, die ETH Thermostate haben nur einen 
Empfänger...

Gruß,
Micha

[Marek N. (Gast)]

Ah OK, dann werde ich wohl doch was eigenes mit RFM und AVR-Net I/O 
basteln müssen.
Vielen Dank!

[Matthijs Kooijman (Gast)]

Forgive me writing in English, but I suspect your English is better than 
my German :-)

Recently, I've been investigating the hardware and firmware of the Cube, 
in the hopes of analyzing and possibly modifying the Cube's firmware. 
The end result is that I didn't get this far: The firmware image sent to 
the cube is (probably) encrypted, there is no terminal on the serial 
console (there is some interesting output, though) and JTAG seems to be 
disabled. I did learn some interesting things about the hardware itself 
and documented most of the firwmare update UDP protocol. See this thread 
for the detailed findings: 
http://www.domoticaforum.eu/viewtopic.php?f=66&t=6992

Next challenge for me: See if I can get my RFM22 module to talk with the 
Cube (and if that doesn't work, I'll just order a CUL :-p)

[Micha K. (klemic)]

Hi,

this forum is a German forum, so the language should be German... You 
can use google for translation, so please continue in German...

However, one exception:
This microcontroller can be erased by pulling the ERASE pin high when 
powering up. Afterwards a permanently stored bootloader is active which 
can be used via the UART or the USB client interface. Atmel provides the 
free software SAM-BA including USB drivers for programming the SAM7X 
controllers. The PCB of the MAX cube has the pins for the ERASE pin 
wired to a jumper... If you plug the Jumper and power up the cube, you 
are on your own writing your own firmware... Then you can of course 
connect what you want, but you're not able to use the ELV firmware any 
more...

In Deutsch: Der Microcontroller hat einen ERASE Pin, der bewirkt, dass 
das interne Flash gelöscht wird, wenn man den Pin beim Einschalten nach 
High zieht. Der Jumper dafür ist auf der Platine vorhanden (nur nicht 
bestückt).
Nach dem Löschvorgang ist ein Bootloader aktiv und man kann mittels der 
kostenlosen Software SAM-BA von Atmel diesen Controller über das USB 
Interface oder den UART programmieren. Logischerweise ist man nach dem 
Löschen auf sich gestellt, eine Firmware von ELV ist dann nicht mehr 
einspielbar...

[Matthijs Kooijman (Gast)]

Dank fur deine Antwort. Ich versuche in Deutsch zu schreiffen, ich hoffe 
das Sie mich verstehen könnte :-)

Ich habe über das ERASE Pin gelesen, und vielleicht werde ich das nog 
nutzen später. Aber, ich hatte gehofft die Firmware von ELV lesen zu 
können, anstatt ein von Grund auf neu zu schreiben. Leider, sieht es so 
aus ELV hat die Firmware gut geschützt...

In der Zwischenzeit habe ich auch mehr gelernd über die Hardware der 
Heizkörperthermostate. Ich habe festgestellt das der Microcontroller 
eine Samsung (S3F8275X/F8278X/F8274X) ist und das die Flash vielleicht 
gelesen werden konnte (aber es gibt einen read protection möglichkeit, 
welche wahrscheinlich aktiviert wurden). Aber, das Datasheet gibt keine 
Details über das Programmierprotocol. Hatte jemand auf dieses forum 
enige Erfahrung mit das programmieren von Samsung OTP, MTP oder MCU 
Flash Chips (es sieht aus das alle eine gleiche Protocol nutzen). Siehe 
auch 
http://www.domoticaforum.eu/viewtopic.php?f=66&t=6992&start=15#p61559

Außerdem hatte ich auch probiert uhm eine RF22B Transceiver die 
Funkpaketen von der Max! System zu empfangen. Ich hatte der richtige 
Einstellungen gefunden, aber es sieht aus das der RF22B ein anderes Data 
Whitening Methode Nutzed (obwhol der RF22 Datasheet sagt das es gleich 
sollte sein). Siehe auch 
http://www.domoticaforum.eu/viewtopic.php?f=66&t=7015&p=61629#p61629

[Micha K. (klemic)]

Hallo,

es macht gar keinen Sinn das MAX System zu verwenden, wenn man es 
modifizieren möchte. Da gibt es einfachere Möglichkeiten. Der Samsung 
Prozessor ist sicherlich ein OTP Typ, was bedeutet, dass er sich nur 
einmal programmieren lässt (One Time Programmable). Es gibt Thermostate 
(mit USB Buchse zum programmieren, allerdings ist das kein USB sondern 
das SPI, waren gerade wieder bei Aldi Süd im Angebot) die einen AVR 
Controller verwenden und hier gibt es ein Forum in dem eine alternative 
Firmware gepostet wurde. Bei diesen Thermostaten kann man auch einfach 
ein RFM12 oder sonstiges Funkmodul einbauen. Eine Zentrale lässt sich 
dann ja auch einfach mit dem Pollin Ethernet Board oder einem Arduino 
aufbauen, es muss ja kein ARM sein, ein ATMEGA reicht auch...
Oder man nimmt die FHT Thermostate, da ist das Protokoll praktisch offen 
gelegt...

[Martin (Gast)]

Mittlerweile gibt es eine sehr schöne Zweitverwendung für den Max!Cube. 
Im FHEM-Forum hat sich ein User die Arbeit gemacht, die Firmware des 
CULs auf den Cube zu portieren, incl. Netzwerkschnittstelle! :-)

http://forum.fhem.de/index.php?topic=38404.0

Viele Grüße,
Martin

[Michael (Gast)]

Hallo,

hat jemand Infos über das Funkprotokoll vom eq Max (oder Homeatic)? Mir 
geht es nicht um den Paketinhalt sondern wann wird was gesendet 
(zeitlicher Verlauf).

Pakete von den Thermostaten werden bestätigt vom Cube, das ist was ich 
weiß. Aber schickt der Cube auch proaktiv an die Thermostate auch wenn 
keine Änderungen vorliegen? Und wie oft schicken die Thermostate 
eigentlich was an den Cube?

Viele Grüße
Michael