Konzeptsuche: Netzwerkprotokoll für Kommunikation Android App <-> Heizungssteuerung

Für ein Standardinterface, das auch auf Android-Seite gut bedient werden 
kann, bietet sich HTTP(s) an - Webserver hast du ja schon. Dort sind 
Authentifizierung, Verschlüsselung usw. schon dabei, auch Android bringt 
die notwendigen Funktionen dafür schon mit. Die rudimentäre Funktion 
hast du auf beiden Seiten an einem Tag am Laufen.

Der Webserver muss auf das GET der App dann eben kein HTML 
zurückliefern, sondern meinetwegen JSON oder XML. Das lässt sich relativ 
schmerzfrei unter Android parsen, so dass du nur noch darstellen musst.

Wenn du richtiges Echtzeitverhalten haben willst (kein Polling), bist du 
mit Websockets besser bedient. Für Android gibt´s fertige Libraries 
(z.B. Autobahn), was dein Webserver so kann, weißt aber nur du.

Max

Ja, würde auch sagen, nimm einfach http.
Stichwort REST API.

Hallo und danke für die Hinweise!

Echtzeitverhalten brauche ich nicht. Pollen der Heizungssteuerung wird 
maximal mit 1x pro Minute erfolgen müssen.

Okay, es überrascht mich jetzt etwas, dass hier HTTP vorgeschlagen wird. 
Ich hatte erwartet, dass man mit einem eigenen Protokoll auf TCP-Basis 
hier schneller zum Ziel kommt. Andererseits ist die integrierte 
Authentifizierung bei HTTP natürlich ein gutes Argument.

Ich verwende übrigens den TCP/IP-Stack von Microchip. Der scheint recht 
mächtig zu sein, besonders einfach zu verstehen finde ich ihn allerdings 
nicht. Immerhin habe ich es geschafft, meine eigenen Webseiten dort zu 
integrieren. Der Stack bringt u.A. einen rudimentären Telnet-Server mit, 
wäre das auch eine Option?

Danke auch für das Stichwort REST api. Ich werde mich da mal belesen!

Aber noch mal zum Ablauf der Kommunikation mit HTTP:
Bedeutet das, ich würde von der App aus eine GET-Anfrage mit einem 
Phantasie-Dateinamen, also z.B:

GET /temperaturverlauf?roomID=1&range=1000

senden und im Webserver würde ich diesen GET-Befehl abfangen und 
entsprechend einen JSON-Datensatz für Raum 1 mit den letzten 1000 
Temperaturmessungen erstellen...?

Einen großen Datensatz an den Server übertragen ginge dann aber nur per 
POST, richtig?

Also ich denke, der Stack wird da die nötigen Einsprungpunkte bereits 
zur Verfügung stellen, dann läge es wohl nur an mir, ob ich den Code an 
den richtigen Stellen hereingefrickelt bekomme :-)

Ja, genau so geht das.
Die Daten auf GET können beliebig groß sein.
Lies am besten mal bzgl Rest API, dann wird das alles klarer, auch warum 
Http perfekt geeignet ist.
Du würdest nur eine "Kopie" von http entwerfen, das ist unnötig, das 
kann alles.
Und bzgl Einsprungpunkt: Du entwickelst eine ganz normale Web App., wenn 
auch eine ganz einfache - das sollte mit dem Microchip Stack problemlos 
gehen.
M.e. Ist es sogar der bessere Weg dort nur eine Api zu haben und ein UI 
woanders zu bedienen, denn ein uC hat nicht viel Resourcen um eine 
großartige UI zu bauen.

Okay, das klingt ja prima. Dann mache ich mich mal 'ran!
Die ersten Zeilen, die ich zu REST bereits gelesen habe, klingen 
vielversprechend!

Danke nochmals.

:-)
Gerne fragen, wenn Dir noch was unklar ist.

So, ich habe mal etwas in der REST-API und dem Microchip TCP/IP-Stack 
gestöbert und erste Erkenntnisse gewonnen:

1.) Der Microchip-Stack unterstützt nur GET und POST und damit nicht das 
vollständige Vokabular um die Kommunikation entsprechend der REST-API 
korrekt umzusetzen.
Das restliche Vokabular (PUT, DELETE,...) in den Stack zu integrieren 
halte ich für Overkill, scheidet daher aus. Ergo wird es in meiner 
Anwendung zu einer Vergewaltigung der POST-Methode kommen müssen.
Grundsätzlich möchte ich vermeiden, im TCP/IP-Stack selber 
herumzupfuschen. Bei jedem Update des Stacks würde sich sonst aufs Neue 
ein Krampf ergeben...

2.) GET-Anfragen müssen sich in der aktuellen Implementierung des Stacks 
nach meinen Erkenntnissen immer auf eine konkrete Datei beziehen, die im 
Dateisystem auch vorhanden ist. Damit wird die XML-Generierung über 
"Phantasie-URIs" nicht einfach. Aber mit etwas Trickserei ist es 
sicherlich auch ohne Änderungen des Stacks möglich.
Kurz zur Funktion des HTTP-Servers momentan:
Dynamischer Kontent kann im Stack durch Platzhalter in der html-Datei 
eingebettet werden. Soll z.B. ein dynamischer Wert an einer Stelle der 
html-Datei auftauchen, wird dort ein Platzhalter eingesetzt: ~var_poti~
Wenn der Webserver-Code beim Senden der Webseite an den Browser über 
diesen Platzhalter "stolpert", wird eine dazugehörige Callback-Funktion 
aufgerufen, in der der User-Code die entsprechende Ausgabe für die 
Webseite dynamisch erzeugt.

Nun die Idee zur Umsetzung des dynamischen XMLs:
Ich erzeuge eine Webseite, z.B. "restapi.html". In dieser Datei findet 
sich nur ein Platzhalter: ~dynXML~

Der Aufruf vom Client erfolge nach diesem Schema:

1

GET /restapi.html?cmd=1&roomID=1&arg=10

Erreicht der Webserver-Code beim Bearbeiten der GET-Anfrage nun den 
Platzhalter ~dynXML~ wird auch dafür eine Callback-Funktion aufgerufen. 
In dieser Funktion werden die Argumente (cmd, roomID und arg) 
ausgewertet und entsprechend dieser die XML-Struktur dynamisch erzeugt 
und an den Client gesendet.
Könnte theoretisch funktionieren...

3.) Wie bekomme ich größere Datenmengen, z.B. eine längere XML-Struktur 
vom Client zum Webserver transportiert? GET ist bei dem TCP/IP-Stack auf 
100 Bytes beschränkt. Das reicht zwar für einfache Befehle, in der z.B. 
nur die Soll-Temperatur für einen Raum geändert werden soll, scheidet 
aber aus, wenn z.B. ein ganzer Zeitplan mit diversen Stellzeiten und 
-temperaturen gesendet werden muss.
Man müsste also die Daten per POST senden, auch wenn es dann nicht ganz 
REST-konform ist.
Ich würde also versuchen, vom Client aus eine Art Dateiupload zu 
initiieren und per POST eine XML-Struktur an den Server senden. Dort 
müsste ich versuchen, beim Abarbeiten der POST-Methode die eintrudelnden 
XML-Daten gleich on-the-fly aufzudröseln. Uff! Aber wahrscheinlich 
machbar...

Für Android wird man beim Stichwort "XML-Parser" ja schnell fündig 
(z.B.: 
http://developer.android.com/training/basics/network-ops/xml.html), auf 
dem PIC wird das allerdings schon etwas tricky. Da ist wohl eine flache 
XML-Hierarchie angesagt, um beim Parsen nicht den RAM zu sprengen.

Die Umsetzung auf Android-Seite scheint insgesamt wirklich recht 
schmerzfrei möglich zu sein. Die Klasse HttpURLConnection bietet ja 
eigentlich alles, was ich für den reinen Datentransfer benötige. Cool.

Bin natürlich weiterhin für jegliche Tips offen ;-)

Gruß
Daniel

Danke, Andreas, das sind hervorragende Hinweise.
Ich hatte mich bereits mit Stift und Papier hingesetzt und die 
anfallenden Daten- und Befehlspakete aufgedröselt. Dabei kam mir auch 
der Gedanke, das XML-Parsen auf dem PIC möglichst zu vermeiden und auf 
ein einfacheres Protokoll beim Client->Server Transfer zurückzugreifen. 
Dein Vorschlag gefällt mir sehr gut!

Hi Daniel,

wenn ich die Limitationen des TCP/IP Stacks so lese, dann ist er nicht 
ansatzweise mit dem eines PC vergleichbar und das wirft für mich die 
Frage auf, was man dann damit lösen sollte und was nicht.
Hatte ja früher schon geschrieben, dass ich nichts davon halte ein UI 
auf einem uC abzubilden, wahrscheinlich geht es auch an oder über die 
Grenzen größere Datenmengen per HTTP zu verarbeiten.
Denke eine Serie von Settings lassen sich noch hinbekommen, aber mehr 
übersteigt die Zielsetzungen für die der TCP/IP Stack gemacht wurde.

Ich weiss jetzt nicht genau, was Du damit vorhast, evtl. lässt sich Dein 
Beispiel von weiter oben umsetzen (1000 Temperaturwerte als JSON oder 
CSV abfragen), aber sehr viel Daten per GET/POST an den uC zu senden 
scheint mir schon gegen die Architektur zu gehen.
Und richtig, XML oder JSON zu parsen ist eigentlich nichts für einen uC, 
das sind für einen uC enorm aufwändige Stringoperationen, die man am 
liebsten auch in einer höheren Programmiersprache macht, der die 
Resourcen (Speicher, CPU) eher egal sind.
JSON, XML sind für maximale Flexiblität gemacht, aber keinesfalls um 
sparsam mit Resourcen zu arbeiten.
Ich habe für mich die Erfahrung gemacht, dass ein String-basiertes 
Protokoll überhaupt für einen uC eine "teure" Sache ist - ich brauche 
bei meinen AVR-Schaltungen wohl ein Drittel des Flash nur für 
Stringverarbeitung, das ist eigentlich die ultimative Verschwendung.

Also dürfte das Protokoll "an REST angelehnt" eher die richtige 
Herangehensweise sein und ansonsten genau infrage stellen, was der uC 
übernehmen sollte und wo lieber eine Embedded-Hardware-Linux-Gurke à la 
Rasperry Pi oder BeagleBoard Black ran sollte - da arbeitet man schon in 
ganz anderem Umfeld, u.a. mit einem vollständigen TCP/IP Stack mit allem 
drum und dran. Und hat alle Parser/Serializer zur Verfügung (JSON, XML), 
die man so braucht.

Ich habe bei mir eine AVR Schaltung als Kommunikationsschnittstelle nach 
Funk an einem Raspberry Pi auf dem dann UI (Web-Interface, Siri), 
Business Logik (Events, Trigger, etc.) und Datensammlung laufen / laufen 
werden.

Viele Grüße,
Conny

Hallo Conny,

sicherlich, der Stack hat seine Limitationen. Dies wird bestimmt auch 
darin begründet liegen, dass der Stack auf den PIC32, den PIC24 (16-Bit) 
und sogar diversen 8-Bit-PICs läuft. Ich bin mit dem, was Microchip 
einem kostenlos zur Verfügung stellt aber völlig zufrieden. Mein Ziel, 
ein einfaches Webinterface zu erstellen, mit dem ich die Heizung steuern 
kann, habe ich schnell erreicht. Die Schaltung mit dem PIC32 ist gerade 
mal so groß wie eine EC-Karte, ist sparsam und läuft absolut 
zuverlässig.
Als ich ca. 2010 mit dem Projekt startete (das Projekt gerät in den 
warmen Monaten immer in Vergessenheit...), war der RasPI noch nicht in 
Sicht und die PIC32-Basis damit sicherlich eine gute Entscheidung. Heute 
würde ich vermutlich auch eher einen RasPI einsetzen.

Die Übertragung des Datensatzes mit 1000 Werten ist eher eine Spielerei. 
Meine Schaltung loggt die diversen Raumtemperaturen (Soll/Ist), 
Ventilstellungen usw. alle 5 Minuten und legt sie im LogView-Format auf 
einer SD-Karte ab. Bisher habe ich die SD-Karte dann immer am PC 
ausgelesen und die Verläufe dort dargestellt. "Schön" wäre es halt, wenn 
man diese Temperaturverläufe (bzw. einen Ausschnitt) direkt in der 
Android-App graphisch darstellen könnte. Dazu müsste allerdings dieser 
Datensatz mittels TCP/IP-Stack übertragen werden. Aber wie gesagt, das 
ist nur ein nice-to-have-Feature.

Diese String-Operationen bereiten mir auch leichte Sorgen, daher mein 
initialer Ansatz, das ganze auf einem eigenen, lediglich TCP-basierten 
Protokoll umzusetzen. Aber die bereits integrierte HTTP-Implementierung 
im Stack bietet mit den integrierten Features (Authentifizierung,...) 
doch so viele Vorteile, dass es zielführender ist sich mit den Strings 
herumzuschlagen. Und ein wenig Platz für Code ist noch im Flash...

Große Datenmengen zu transportieren geht prinzipiell schon. Beim Stack 
ist z.B. ein Beispiel dabei, wo eine Datei beliebiger Größe hochgeladen 
werden kann und der Server bildet nebenbei die MD5. Habe das getestet 
und es dauert bei Dateien > 5 MB zwar etwas, funktioniert aber tadellos 
;-) Der Transport in Richtung Client ist ja an sich nur ein Download. 
Auch das wird schon klappen.

Ich werde jetzt erst einmal die nötigsten Befehle / Transfers mit einem 
"Hybridprotokoll mit REST-Anleihen" abbilden, so wie Du und Andreas es 
vorschlagen. Wahrscheinlich wird mich das schon die ganze aktuelle 
Heizperiode aufhalten, denn nebenbei muss ich mich auch noch in Android 
einarbeiten. Eine schöne Beschäftigung für die kalte Jahreszeit :-)

Gruß
Daniel

Hallo!

Nur noch ein kleiner Tipp: wenn Du einen Protokollparser z.B. für JSON 
aber auch für ein simples Protokoll für einen Mikrocontroller baust, 
musst Du etwas anders herangehen als auf einem "richtigen" Rechner:

1. Vergiss alle Stringbefehle (extrem wichtig!)
2. Versuche nie die ganze Nachricht in einen Puffer zu bekommen
3. Betrachte die Eingangsdaten als Stream, versuche nur immer ein 
Zeichen zu verarbeiten. Komme nie in eine Situation, wo Du voraus oder 
zurück schauen musst. (Auch z.B. Zahlen lassen sich Ziffernweise 
einlesen.)
4. Definiere zuerst eine "State Machine" für das Protokoll incl. 
Fehlerhandling
5. Parse nur das, was Dir eine Information (Statuswechsel oder Daten) 
bringt, überspringe den Rest (Beispiel: um Zwischen GET und POST zu 
unterscheiden ist nur der erste Buchstabe wichtig, igoriere den Rest bis 
zum Leerzeichen)
6. Der Parser muss das Protokoll nicht validieren, sondern nur verstehen
7. Mache das Protokoll einfach - JSON geht schon ;)

Damit hab ich einen Web-Server (TCP/IP+HTTP+JSON) in einen PIC18F4550 
bekommen (32K ROM/2K RAM). Ein PIC32 ist da schon richtig Luxus ;)

PS: Mit dem uIP TCP-Stack. Der MicroChip Stack passt da gar nicht rein.

vg

Jürgen

Daniel P. schrieb:
> ein einfaches Webinterface zu erstellen, mit dem ich die Heizung steuern
> kann, habe ich schnell erreicht. Die Schaltung mit dem PIC32 ist gerade
> mal so groß wie eine EC-Karte, ist sparsam und läuft absolut
> zuverlässig.

Erzähl mehr über Deine Lösung, welche Komponenten der Heizung steuerst 
Du und mit was, wo/wie misst Du die Temperaturen?
Ich frage, weil ich mich gerade auch beginne mich mit Heizungssteuerung 
zu beschäftigen, habe mir gerade 2 Sparmatic Comet zum experimentieren 
gekauft:
Beitrag "Entwicklungen und Forschung um den Sparmatic Comet / Zero v2 Heizungsthermostat"
http://www.mikrocontroller.net/articles/Sparmatic_Heizungsthermostate

Habe eine Home Automation-Lösung zusammengebaut mit RPi als Zentrale, 
eine uC-Schaltung dran, die das 868 Mhz RFM12-Funknetzwerk bedient, 
Funksteckdosen steuert und mit Funksatelliten kommuniziert, die 
verschiedene Tätigkeiten verrichten (IR-Sender, Geräteschalter, 
Ventilschalter = Gartenbewässerungsanlage, bald auch Steuerung der 
Türsprech/-öffnungsanlage) und später auch Sensoren einliest (alte 477 
Mhz ELV und neue noch selbst zu bauende).
Gerade dabei die Kommunikation mit der uC-Schaltung auf eine REST-API zu 
abstrahieren und ein Webinterface auf dem Rpi darüber zu legen, läuft 
bisher nur mit Siri / Siriproxy.
Und da würde ich gerne auch die Heizung mit einbinden und die Ventile 
steuern, entweder direkt oder indem ich die Pläne/Vorgaben an die 
Sparmatic Cometen übertrage, d.h. ich müsste auch mit den Comet per Funk 
sprechen.

Ansonsten: ich denke so wie Du es beschreibst dürfte sich eine API 
hinbekommen lassen!
Bin gespannt auf das Ergebnis / die Erkenntnisse, lass wissen wie es 
läuft!

Danke Jürgen, das sind gute Tips! Allerdings werde ich zunächst 
versuchen, das Parsen der Standardformate (XML, JSON) auf dem PIC ganz 
zu vermeiden. Diese Formate bringen mir aus der aktuellen Sicht keine 
wirklichen Vorteile, da hat Conny schon Recht.
Respekt, dass Du diese Funktionalität in einem 18F4550 untergebracht 
hast! Ich hatte anfangs einen Webserver mit einem PIC24 aufgebaut und 
selbst da wurde es bereits eng :-)

@Conny:
Ich hatte anfangs auch den Anspruch, möglichst viel selber zu machen. 
Also eigene Funk-Temperatursensoren (und andere "Satelliten", wie Du so 
schön sagst) zu entwickeln. Hatte mich damals stark für ZigBits 
interessiert und auch mehrere Zigbit-Temperatursensoren aufgebaut (mit 
SHT15). War eine nette Spielerei aber leider nicht ganz praxistauglich. 
Dann habe ich festgestellt, dass es fertige, spottbillige 
Funk-Temperatursensoren bei ELV gibt (inzwischen gibt es leider nur noch 
den etwas teureren Außensensor ASH 2200). Dazu einen fertigen Empfänger 
(USB-WDE1), der sich problemlos an die serielle Schnittstelle hängen 
lässt.

Ich habe keinen Zugriff auf die Therme / Zentralheizung, also verwende 
ich nur Heizkörper-Stellantriebe. Die Teile von REV bzw. ELV names 
FHT-8V werden dazu über ein Funkinterface (FHT-8i, leider inzwischen 
auch aus dem Programm) angesteuert. D.h. ich habe jetzt pro Raum einen 
dieser Funksensoren und an jedem Heizkörper einen Funk-Stellantrieb.
Der PIC braucht sich nicht groß um Funkprotokolle kümmern, geht nur 
regelmäßig den Zeitplan mit den Temperaturen durch, macht die 
Temperaturregelung (einfacher P-Regler reicht da aus...) und loggt ein 
bißchen mit.
Der Nachteil an meinem System ist momentan halt nur noch, dass es keine 
weiteren Möglichkeiten zur Raumtemperaturbeeinflussung gibt, als über 
das Webinterface. Für mich okay, aber Gästen ist es nicht unbedingt 
zuzumuten, sich erst einmal mit Passwort auf einer Webseite einzuloggen, 
nur um die Heizung mal ein wenig aufzudrehen :-D

Dein Projekt klingt ziemlich cool! Da scheinst Du ja bereits ein 
ziemlich fortgeschrittenes Stadium erreicht zu haben. Die Idee mit Siri 
ist natürlich auch fein. Denke es ist nur logisch, wenn Du nun versuchst 
die Temperaturregelung bei Dir zu integrieren. Ich habe mich länger 
nicht mehr um Alternativen gekümmert, aber gibt es inzwischen 
Funk-Stellantriebe/Thermostate mit offenem Protokoll? Bei den 
FHT-8-Dingern sieht es scheinbar noch schlecht aus... Oder ist die 
Nachrüstung der Comet mit RFM12 möglich?

Viele Grüße
daniel

Guten Morgen zusammen,

ich möchte mal ein kurzes Update liefern:
Die XML-Generierung habe ich inzwischen erfolgreich in meinem 
PIC32-Webserver integriert. Einzige Schwierigkeit: die Generierung muss 
häppchenweise erfolgen, da man immer nur eine begrenzte Anzahl Bytes in 
den TCP-Buffer schreiben kann. Die XML-Erzeugung muss daher in einer 
Statemachine erfolgen, was natürlich zu etwas komplexerem Code führt.

Beim Debugging hat sich das kleine Programm "Fiddler" 
(http://fiddler2.com/) als sehr nützlich erwiesen. Wie man auch im 
beigefügten Screenshot sehen kann, dröselt das Programm die 
HTTP-Transfers auf und stellt sogar XML-Inhalte sinnvoll dar. Wie 
gesagt, sehr hilfreich und empfehlenswert.

Die zweite Baustelle, die Android-APP, hat inzwischen ebenfalls einen 
guten Stand erreicht (siehe Screenshot). Das Darstellen der Ist- und 
Sollwerte funktioniert, die Kommunikation mit dem Server erfolgt 
ebenfalls völlig problemlos. Ich hatte noch keinerlei Erfahrung mit 
Java- oder Android-Programmierung, dafür war der Zeitinvest zur 
Erstellung der App bislang recht gering.

Jetzt fehlt noch der Part mit der Datenübertragung von der App zum 
Webserver um z.B. den Heizzeitplan anzupassen. Das wird ein stückchen 
aufwändiger, aber die Heizperiode hat ja auch noch ein paar Tage ;-)

Schöne Grüße
Daniel

Hi Daniel,

super, sieht sehr gut aus, hast Talent! :-)

TCP-Buffer: ja, macht Sinn, dass man da nicht viel Buffer hat.

Fiddler kenne ich, habe ich für Testing / Debugging von REST APIs im 
Einsatz.

Heizplan anpassen: da ist aber eher die Benutzeroberfläche in der App 
der Aufwand, oder?

Daniel P. schrieb:
> @Conny:
> Ich hatte anfangs auch den Anspruch, möglichst viel selber zu machen.
> Also eigene Funk-Temperatursensoren (und andere "Satelliten", wie Du so
> schön sagst) zu entwickeln. Hatte mich damals stark für ZigBits
> interessiert und auch mehrere Zigbit-Temperatursensoren aufgebaut (mit
> SHT15). War eine nette Spielerei aber leider nicht ganz praxistauglich.
> Dann habe ich festgestellt, dass es fertige, spottbillige
> Funk-Temperatursensoren bei ELV gibt (inzwischen gibt es leider nur noch
> den etwas teureren Außensensor ASH 2200). Dazu einen fertigen Empfänger
> (USB-WDE1), der sich problemlos an die serielle Schnittstelle hängen
> lässt.

Kenne das System von ELV auch. Ich habe immer keinen Spass an fertigen 
Modulen, finde es immer spannend sowas selber zusammen zu zimmern. Auch 
wenn es enorm viel aufwändiger ist, aber eben das selbst Herausfinden 
ist für mich die Challenge dabei.

> Dein Projekt klingt ziemlich cool! Da scheinst Du ja bereits ein
> ziemlich fortgeschrittenes Stadium erreicht zu haben.

Fortgeschritten... mmmh... unter den Blinden ist der Einäugige der 
König?

> Die Idee mit Siri
> ist natürlich auch fein. Denke es ist nur logisch, wenn Du nun versuchst
> die Temperaturregelung bei Dir zu integrieren. Ich habe mich länger
> nicht mehr um Alternativen gekümmert, aber gibt es inzwischen
> Funk-Stellantriebe/Thermostate mit offenem Protokoll? Bei den
> FHT-8-Dingern sieht es scheinbar noch schlecht aus... Oder ist die
> Nachrüstung der Comet mit RFM12 möglich?

Dafür gab's bis vor kurzem bei mir nur Siri und kein Webinterface, das 
habe ich jetzt gerade erst nachgerüstet.
Und zwar habe ich eine zusätzliche "Schicht" REST API eingeführt, die 
nun von Web UI und Siri genutzt werden kann.
Und mit der Rest Api kann man jetzt auf dem Raspi auch prima scripten, 
so wird die Espressomaschine jetzt zu bestimmten Zeiten automatisch 
ein-/ausgeschaltet.
Das mit Siri ist supercool, aber leider nicht vollständig 
kontrollierbar, weil es halt ein Community Hack ist. Z.B. funktioniert 
das Siriproxy jetzt mit iOS 7 nicht mehr und hindert mich an einem 
Upgrade der Geräte bzw. sollte ich mir jetzt ein neues iPhone zulegen 
wollen, ginge das erstmal nicht mehr damit.
Heisst also, an Siri hat man nur solange Spass solange Apple es 
toleriert und nicht das Protokoll ändert.

Stellantriebe: ich habe beim Recherchieren keine offenen gefunden, aber 
es gibt einige, die von der Community gehackt werden, die Sparmatic und 
die Honeywell z.B.
Ich habe beim mir gerade in einem Raum 2 Stück Sparmatic im Einsatz, 
funktionieren super. Da bin ich mir gerade noch nicht sicher, ob ich die 
so dringend in die H.A. integrieren muss, denn so viele verschiedenen 
Heizzeiten brauche ich nicht und die Regelung, die sie so bereits machen 
ist perfekt.
Comet mit RFM12, da gibt's wohl noch keine fertige Lösung. Für den Zero 
hat mal jemand einen Entwurf für ein RFM12-Huckepack-Modul entworfen, 
für den Comet habe ich das noch nicht gesehen.
Wenn, dann wäre es genau das, was ich bei den Cometen aufrüsten würde: 
dass ich das Heizprogramm per Funk übermitteln kann.
Ich habe momentan noch kein Problem damit festgestellt, dass der 
Temperatursensor gleich am Heizkörper sitzt. Deshalb würde ich nicht die 
Ventilregelung per Funk machen wollen (dann wäre die Frequenz recht busy 
nur mit Ventilkommandos, das gefällt mir nicht), nur die Vorgabe per 
Funk übermitteln.
Kommt halt dann automatisch mit komplett eigener Steuerungsfirmware, mit 
der man sich beschäftigen muss - da habe ich gerade noch 2-3 andere 
Projekte auf der Liste, die ich vorher abschliessen wollen würde.