Announcement: there is an English version of this forum on 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]
Angehängte Dateien:
-
cube001.jpg
64 KB -
cube002.jpg
78 KB -
cube003.jpg
83 KB -
cube005.jpg
83 KB -
cube006.jpg
150 KB -
cube007.jpg
120 KB
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?
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
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!
>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.
...mal 'ne Frage am Rande: War das ein Bausatz zum Selberlöten, oder kommt das so als Fertiggerät?
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.
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/
@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.
Angehängte Dateien:
-
wandthermostat001.jpg
77 KB -
wandthermostat002.jpg
80 KB -
wandthermostat003.jpg
38 KB -
wandthermostat004.jpg
59 KB -
wandthermostat005.jpg
49 KB -
wandthermostat007.jpg
56 KB
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: 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.
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?
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!
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.
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
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)...
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.
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...
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...
@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?
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)
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.
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?
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?
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...
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.
Ah, danke für die Info. Cool, dann müsste der ja mit dem TI EZ430-Chronos-868 Kit kommunizieren können.
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
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
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...
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 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
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?
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 :)
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
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 ..
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
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.
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?
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
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.
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
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
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
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
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
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
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.
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; } }
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?
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?
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.
alles klar, danke... Dann gibt es doch Homematic auf das bitgeschubse hab ich keine lust:-)
Hallo Micha hast du geschaft eine funktionierende Firmware fuer dem MAX!Cube zu kompilieren? Tzanimir
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?
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.
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.
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
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
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
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.
Hallo Ich möchte die Elektronik eines Heizkörperregler missbrauchen und ein Relais mit Wechsler ansteuern, um ein Buderussteuergrät anzusteuern. Gruß, Wolfgang
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
Hi Marek, nein, sie sind nicht kompatibel. Die MAX Thermostate habe eine bidirektionale Funkverbindung, die ETH Thermostate haben nur einen Empfänger... Gruß, Micha
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)
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...
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
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...
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
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
Thread beobachten
Seitenaufteilung abschalten