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]
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.
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.
@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.
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.
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
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
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.
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
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