Ich bin es jetzt wirklich leid und werde mich mal dransetzen. Alle möglichen Systeme (CAN, 4-20mA Analog, S0, UART 20mA, Einzelkontakte, Pumpen Rolläden usw), Wildwuchs eben, wie er so im Lauf der Zeit entsteht :-) Ein bisschen mit dem Banana Pi gespielt, das Teil ist einfach genial, damit werde ich alles zentral sammeln. Anzeige/Bedienung sollen 1 oder 2 kleine tablets sein (trekstor surftab). Jetzt stellt sich eine grundlegende Frage - was ist sinnvoller: 1. auf dem Banana Pi eine website zur Verfügung zu stellen und die tablets zeigen diese mit einem x-beliebigen browser an oder 2. sich eine app zu schreiben und den Pi nur als nackte Datenschleuder zu betreiben Ich denke, Variante 1 wird wesentlich schneller zu realisieren sein (zumindest für mich, mit Android habe ich noch nie was gemacht) Was denkt ihr was sinnvoller ist?
H.Joachim Seifert schrieb: > was ist sinnvoller Wenn viele Daten übermittelt und client-individuell behandelt werden würden, könnte man diskutieren. Aber hier ist der Fall klar: 1.
Ja, ich denke auch. Noch dazu könnte man das ganze auch nach aussen exportieren, wenn man denn wollte (ist im Moment nicht geplant, aber kann schon Sinn machen, von unterwegs die Heizung wieder hochfahren). Was mir an der app-Lösung gefallen würde: im Bad z.B. (da kommt auf jeden Fall ein Display hin) sind Warmwassertemperatur/evtl. Brennernachforderung/Zustand Zirkulation wichtig, aber ganz bestimmt nicht aktueller Stromzählerstand/Rolläden/Zustand Wechselrichter etc.
H.Joachim Seifert schrieb: > Was mir an der app-Lösung gefallen würde Das geht aber auch mit HTML und einem Browser nicht komplizierter.
Ich würde auch 1.) nehmen hab ich auch so gemacht wen du hinterher noch Langeweile hast machst du eine Mobile Seite draus, der Vorteiel ist das es Systemunabhängig ist und auch auf dem PC ... Funktioniert
Mach eine HTTP API für alle Geräte, dann kannst Du sie auf verschiedenste Weisen bedienen: - eine Webseite, die setzt dann die HTTP Calls auf die API ab - eine App wie diese, die HTTP kann: https://itunes.apple.com/de/app/homeremote/id806202366?mt=8 - Shell Scripts via crontab etc - Siri via Homekit zB über HAP-NodeJS (für Android gibts bestimmt auch was) - uvm. Ich habe auf einem Raspberry Pi einen Mini Webserver auf Basis BottlePy laufen (python), der bietet die API an. Dieser API Server weiß wie man mit den Geräten spricht (zB über serielle Schnittstelle mit einer Schaltung die 868 MHz Schaltungen anfunkt, die dann zB IR Codes senden). Die API sieht derzeit so aus: - http://<Host>/kueche/espresso/<on|off> - /wohnzimmer/licht/<on|off> - /pp/2850/FFFFF0FFFFF0 (Funksteckdose schalten) - /irsend/6:2:23:1 (IRMP/IRSND) - /garten/sprinkler/valve:2:1:1800:1 (Ventil 2 einschalten für 1800s, aber warten, bis Ventil 1 fertig ist) Gleichzeitig empfängt der BottlePy Server noch über seriell Daten von alten alten 433 MHz Funksensoren, die von einer Schaltung empfangen werden und per UART an den Raspberry Pi geschickt werden. Auf einem Apache läuft wiederum ein Set .psp Seiten, die mit JQuery Mobile ein ganz einfaches Interface per Web bereitstellen, Screenshots anbei. Und es läuft seit neuestem noch o.g. Siri HomeKit server, der iOS eine HomeKit Accessories vorspielt.
Ich würde auch zur Web-Anwendung tendieren und dann ein Tablett mit Browser an die Wand hängen. Die kann man dann auch von woanders aus aufrufen, z.B. vom Handy aus oder PC oder gar vom Arbeitsplatz aus, wenn man keine Angst vor der Anbindung ans öffentliche Internet hat. Klar kann man auch eine App entwickeln, was auch nicht sehr schwer ist. Aber dann hängs Du am Betriebsystem. Wenn das Tablet in 10 Jahren kaputt geht und Android bis dahin nicht mehr in Mode ist, bis Du am Arsch.
Hallo, ich kann dir FHEM emfehlen, open source Hausautomation mit einer guten Community die eine eierlegende Wollmilchsau entwickelt mit Modulen für fast alle Dinge die im Haus zu steuern sind. Mit Webinterface - flexible div. Android und IOS Apps. Ich kann nur sagen das macht süchtig und Spass weil es funktioniert. Gruß Stefan
Stefan Sorge schrieb: > Hallo, > > ich kann dir FHEM emfehlen, open source Hausautomation mit einer guten > Community die eine eierlegende Wollmilchsau entwickelt mit Modulen für > fast alle Dinge die im Haus zu steuern sind. Mit Webinterface - flexible > div. Android und IOS Apps. > Ich kann nur sagen das macht süchtig und Spass weil es funktioniert. > > Gruß > Stefan Das habe ich mir auch überlegt, aber ich wollte für den Anfang nichts komplexes als Unterbau haben und auf existierende Frontends angewiesen sein. Dondern erstmal selber reinschnüffeln, wie ich das zusammenbaue. Unter der Voraussetzung, dass ich in wenigen Stunden was zusammenfriemeln kann und das hat geklappt. Die Entscheidung steht noch aus irgendwann auf ein Framework wie FHEM zu gehen, da gibt's ja mehrere davon, auch z.B. OpenHAB. Habe ich mir alle noch nicht genauer angesehen. Das mit dem Mini-Webserver, der eine API anbietet ist echt supersimpel, das dauerte nur 3-4h für die erste Version, seitdem nochmal ein paar Stunden (< 10h) investiert es noch zu erweitern und verbessern. Die JQuery Mobile Und es ist cool, was sich daraus alles an Möglichkeiten ergeben hat - ich bin jetzt völlig frei welchen "Client" ich dafür nehme, jede Software, jedes Script kann per API einfach drauf. Einen HTTP-Call kann man fast immer bewerkstelligen. Und sogar Scripten mit Shellscripts ist einfach möglich. Oder Cronjobs, die was machen. Z.B. habe ich im Schlafzimmer einen Luftbefeuchter, der nicht nach Feuchtigkeit stoppt, sondern befeuchtet, bis er leer ist. Da habe ich ein Python-Script gemacht, das wird via Crontab (Linux-Basics) jede Minute aufgerufen, holt sich die Daten, die von den Funksensoren eingesammelt werden, schaut sich die Feuchtigkeit an und wenn sie <40% ist, wird per Funksteckdose der Luftbefeuchter eingeschaltet, sonst aus. Klappt prima :-)
Stefan us schrieb: > Ich würde auch zur Web-Anwendung tendieren und dann ein Tablett mit > Browser an die Wand hängen. Die kann man dann auch von woanders aus > aufrufen, z.B. vom Handy aus oder PC oder gar vom Arbeitsplatz aus, wenn > man keine Angst vor der Anbindung ans öffentliche Internet hat. > > Klar kann man auch eine App entwickeln, was auch nicht sehr schwer ist. > Aber dann hängs Du am Betriebsystem. Wenn das Tablet in 10 Jahren kaputt > geht und Android bis dahin nicht mehr in Mode ist, bis Du am Arsch. Web-App ist gut, aber nicht die Steuerungen in die Web-Anwendung einbauen, das ist zu unflexibel. Trenne es in eine HTTP-API und einen Web-App-Client.
Ich hänge das BottlePy Script einfach mal an, hab noch schnell ein paar Kommentare reingemacht zum besseren Verständnis. BottlePy: http://bottlepy.org/docs/dev/index.html Schritte um es zum Laufen zu bringen: Raspberry Pi lauffähig. Python und Zubehör installieren: sudo apt-get install python-setuptools sudo easy_install -U pyserial sudo easy_install jsonpickle sudo easy_install bottle Das Script in ~/ha_api/ werfen Dort "python ha_api.py" starten. Fertig, Du hast eine HTTP-API für Home Automation! Es reagiert jetzt auf HTTP-Kommandos wie /kueche/espresso/on und versucht einer Schaltung am seriellen Port des Raspberry Pi (/dev/ttyAMA0) mitzuteilen, dass es ein Funkkommando an die Schaltung absetzen soll, die die Espressomaschine schaltet. An dieser Stelle kann man natürlich tun was man braucht. Für Start bei RPi Systemstart noch hinzufügen in /etc/rc.local: (evtl. muss noch "screen" installiert werden) # Start API server echo "Starting API server" cd /home/pi/ha_api screen -d -m -S apiServer su - pi -l -c "/usr/bin/python /home/pi/ha_api/ha_api.py" & Viel Spass, Conny P.S. Habe gerade gesehen, ich habe den API Key von ThingSpeak dringelassen. No worries, ich habe meine Keys jetzt geändert.
:
Bearbeitet durch User
Noch nicht viel, bin noch am Daten einsammeln und Aktoren steuern. Ich kämpfe noch mit den ESP8266-Modulen :-) Wird aber ne website werden.
@Conny: Habe auch schonmal ein wenig rumprobiert mit jQuery. Bevorzuge es auch gegenüber einer App. Vorallem sieht es auch aus optisch wie eine App, wenn man es als Vollbild hat. Ich hatte die HTML-Seiten auf der SPS. Das war manchmal ein wenig blöd wenn mehrere drauf zugreifen parallel. Ich werd es auch mal mit dem Raspi versuchen. Hab ich richtig verstanden das die HTTP API der Server ist und die Calls entgegennimmt und dementsprechend an die geräte weiterschickt? Und die jQuery Website liegt auch auf dem Raspi?
:
Bearbeitet durch User
Mathias O. schrieb: > @Conny: > Habe auch schonmal ein wenig rumprobiert mit jQuery. Bevorzuge es auch > gegenüber einer App. Vorallem sieht es auch aus optisch wie eine App, > wenn man es als Vollbild hat. Ich hatte die HTML-Seiten auf der SPS. Das > war manchmal ein wenig blöd wenn mehrere drauf zugreifen parallel. Ich > werd es auch mal mit dem Raspi versuchen. Hab ich richtig verstanden das > die HTTP API der Server ist und die Calls entgegennimmt und > dementsprechend an die geräte weiterschickt? Und die jQuery Website > liegt auch auf dem Raspi? Der Vorteil von JQuery Mobile ist, dass es einigermassen "Responsive" ist und bringt schon ein Style-Famework mit, d.h. es sieht auf Smartphone, Tablet und Desktop sehr ok aus und mein HTML/CSS-Code beschränkt sich auf die reine Funktionalität. Also minimaler Aufwand für ein ansehnliches Ergebnis. Ja, ich hab auf dem Raspberry Pi die HTTP API laufen, die ist nur Umsetzer von HTTP Call auf Gerätesteuerung. Und separat dazu läuft die JQuery Mobile Site, auch auf dem Raspi, die nur UI ist und HTTP API Calls absetzt. Sind auch zwei verschiedenen Frameworks, HTTP API als BottlyPy und die JQuery Mobile Site als Apache/PSP (Python Server Pages). Für beides kann man nehmen, was einem beliebt, aber die Trennung finde ich sehr vorteilhaft. Also einen schöner Layer-Aufbau: - Elektronik und Ansteuerung (z.B. Elektronik > 868Mhz Funk) - HTTP-Api-Server - Bedienung (z.B. JQuery Mobile Site > Browser oder iOS App) Und dabei ist die HTTP-API die zentrale Komponente, was unter der API passiert hat niemanden zu interessieren, da kann man alles drunter verstecken - sei es 868 Mhz RFMxx oder direkte Ansteuerung von Funksteckdosen oder direkte Bus-Verbindung oder nochmal HTTP-Call an andere Geräte, die das können ... was auch immer. Und drüber kann man auch machen was man möchte, jeder "Client" willkommen. Denn wenn man dann noch andere Wege hat, wie man schalten will, ist es supereinfach, wenn man einfach per HTTP-Call ran kann. Z.B. hab ich letztens mit iBeacon und iOS App experimentiert und lasse mein iPhone automatisch das Licht im Büro einschalten, wenn ich mich nähere bzw. ausschalten, wenn ich mich entferne: - iBeacon funkt die Broadcasts im Bereich von ca. 5 Metern (inhouse) - iPhone empfängt das und teilt das meiner App mit - die App reagiert auf "entered region" bzw. "exited region" und setzt dann HTTP-Calls auf die API ab das Licht auszuschalten Und genau da sieht man schon den Vorteil: ich hab Zugriff auf das Licht von Crontab-Scripts, von JQuery Mobile, von der iBeacon iOS App, von der HomeRemote App etc. Alles derselbe Senf auf dieser Ebene, die drunterliegende Hardware ist mir da wurst.
Bitte 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.