Hallo zusammen, ich bin hier auf der Suche nach ein paar Denkanstößen. Zunächst kurz ein paar Hintergrundinfos zum Projekt: Ich habe auf Basis eines PIC32 einen Webserver aufgebaut, der über ein Funkinterface kommerzielle Temperaturfühler abfragt und Heizkörper-Stellantriebe nach einem vorgegebenen Zeitplan regelt. Die Konfiguration des Zeitplans, Anzeige der Ist- und Solltemperaturen usw. erfolgt über eine vom µC dynamisch erzeugte Webseite. Das System funktioniert an sich eigentlich schon ganz prima, die Konfiguration über die Webseite ist allerdings doch teilweise etwas fummelig. Da Tablets auf Android-Basis inzwischen für einen Spottpreis zu haben sind, soll nun zukünftig eines dieser Tablets als ein etwas geschmeidigeres Interface zur Heizungssteuerung fungieren. Nun zur eigentlichen Frage: Wie baut man so ein Kommunikationsprotokoll zwischen der Android App und dem PIC32 sinnvoll auf? Gut, TCP als Transportlayer ist klar, aber welches Protokoll setze ich "darauf"? Es müssen einfache Befehle übertragen werden können, aber auch größere Datenmengen (z.B. Temperaturverlauf der letzten 24h, alle 15 Minuten) Das Projekt ist ausschließlich für den Privatbereich, es muss also nicht "overengineered" werden. Allerdings sollten schon ein paar Sicherheitsfeatures möglich sein. Also eine Authentifizierung des Clients (dem Android Tablet) per Login/Passwort, eventuell vielleicht sogar eine verschlüsselte Übertragung (SSH)? Ich glaube, die Fragestellung an sich ist nicht sonderlich schwierig, mir fehlt nur einfach ein "Startpunkt". Gibt es vergleichbare Projekte / Beispiele, wo man sich die (Protokoll-)Umsetzung an-/abschauen könnte? Kann mir jemand Literatur für das Selbststudium empfehlen? Danke Euch! Gruß Daniel
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
:
Bearbeitet durch User
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
Auf der PIC Seite brauchst Du keine XML Verarbeitung, mache es ganz einfach - schicke per POST einen einfachen String:
1 | ZIMMER=1,20;ZIMMER=2,24;ZEITPLAN=3,18:30,22,20:30,18... |
- Zimmer 1 20° - Zimmer 2 24° - Zimmer 3 ab 18_30 22°, ab 20:30 18°... Daten vor dem Senden vorbereiten, am besten gleich im Format, welches vom PIC verwendet wird, z.B. die Urzeit als "18:30", "1830" oder in Minuten "1110". Als Parameternamen kurze Strings wählen: ZM=ZIMMER, ZT=Zeitplan usw, ist die Anzahl Zimmer fest, so kann man gleich ZM1=20 benutzen. Eine solche Liste ist einfacher zu verarbeiten als XML - keine Verschachtelung, keine schließende Tags. In die andere Richtung kann durchaus XML gesendet werden, da XML-String zu erstellen viel einfacher ist als parsen. Und als Tipp: Protokoll Entwickeln, Aufschreiben, Ausdrucken und Abheften - später eine unverzichtbare Hilfe für Fehlerbehebung und Weiterentwicklung ;-)
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
Angehängte Dateien:
-
fiddler2_ausgabe.jpg
160 KB -
AndroidApp.jpg
340 KB
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.