[Vorstellung] Xenia Steuereinheit

Auf Bitte aus dem Thread heraus wurde das Thema "Absicherung von Festwasseranschluss/Aquastop" in einen neuen Thread transferiert. Es geht hier weiter >Link<. Sollte die Absicherung nicht funktionieren, verweise ich auf den Frust-Thread.

 

Wenn ihr statt einfach eine Webseite zu implementieren einen Webservice bauen würdet, dann könnte darauf sowohl eine Webseite, als auch eine App, aber darüber hinaus auch noch ne ganze Menge mehr Zeugs aufsetzen. Bspw. ein Heimautomatisierungsserver. Damit würdet ihr eine noch größere Spielwiese ermöglichen, ohne, dass sich das gesamte Chaos in eurer Maschine abspielt. Der rechenintesive Teil einer modernen Webseite könnte sich dann bequem auf dem Rechner oder dem Handy des Benutzers austoben. Der Chip in der Maschine muss nur die Steuerdaten entgegennehmen (natürlich desinfizieren) und verarbeiten.

 

Bzgl. Smart Home: Hat schon jemand überlegt, ein REST API zu implementieren? Das würde einerseits externe Steuerbarkeit über gängige Smarthome Lösungen ermöglichen, wie auch später ohne weiteren Aufwand in der Firmware Projekte wie Smartphone Apps ermöglichen.

 

Sinnvoll ist es dann, wenn man Fremdlösungen ermöglichen will ohne später nochmal die eingene Firmware großartig anzupassen. Die Frage ist, was eine Smarthome Anbindung der Maschine bringt. Mir fällt da eigentlich nur präsenzgesteuerte Aktivierung (Ein/Vorheizen; Aus wenn alle das Haus verlassen haben) ein, vermutlich bin ich da aber zu fantasielos...

 

Vielleicht macht es Sinn, dass ihr zumindest eure Softwarearchitektur von Anfang so plant, dass so etwas möglich wäre.

 

Ich versuche mal anhand eines einfachen Beispiels den Unterschied zwischen serverseitigem und clientseitigem Code zu erklären. Nehmen wir an, ich sitze im Arbeitszimmer und möchte herausfinden, ob meine Maschine schon an ist und ob sie schon aufgeheizt ist. Dazu rufe ich die Statusseite auf: http://xenia/status. Jetzt rennt der Webserver los, liest alle nötigen Infos aus, klebt sie an den dafür vorgesehenen Stellen in das statische HTML, was er herumliegen hat und liefert die fertige Seite an den Benutzer aus. Das wäre serverseitig. Alternativ könnte der Webserver aber auch das statische HTML und eine Javascript Datei ausliefern. Das Javascript startet und ruft http://xenia/api/status auf. Jetzt rennt der Server los und holt alle nötigen Infos und liefert sie ohne HTML in einer ordentlichen Struktur (JSON bspw.) aus. Das Javascript nimmt die Daten und klebt sie in die Seite. Das wäre clientseitig. Bis hier stellt sich die Frage, warum man das für so etwas triviales so kompliziert machen sollte.
Eigentlich will man ja aber eine Statusseite haben, die sich aktualisiert. Sprich: Wenn meine Maschine noch nicht aufgeheizt ist wäre es doch toll, dass ich nicht alle 30 Sekunden die Seite neu laden muss, sondern automatisch die Anzeige aktualisiert wird. Und nun macht server- vs. clientseitig einen Unterschied. Bei serverseitiger Programmierung muss immer die ganze Seite neu geladen werden. Der Server klebt also neue Daten in die gleiche HTML Struktur und liefert sie wieder aus. Bei der clientseitiger Programmierung fragt das Javascript einfach nur nach neuen Daten und klebt sie wieder in das vorhandene HTML. Somit muss nicht die ganze Seite neu geladen werden. Das bedient sich angenehmer und bei komplexeren Dingen, macht das vielleicht auch weniger Rechenlast im Server. Beispielsweise, wenn man Verlaufsgrafiken erzeugen möchte. Dann kann der Browser einfach die Daten abrufen und rendert die Grafik selbst mit Hilfer von passenden Javascript Bibliotheken.
Ganz nebenbei macht man so auch für Apps den Weg frei, da die ja nicht HTML vom Server abrufen wollen, sondern nur Daten.
Fragt doch mal euren Programmierer, ob er das nicht sowieso so geplant hat.

 

Genau so ist das dersmie!
Und wenn dann später mal html5 oder java xx veraltet sind (wir hatten da gerade ein ähnliches Problem an meinem Arbeitsplatz mit einer 6 Jahre alten Browserlösung), dann muss man nicht die Platine updaten oder gar austauschen. Es reicht dann, die Benutzeroberfläche des Clients zu erneuern. Das läßt sich sehr viel einfacher realisieren.
Soll die Xenia sich ins Netze einbuchen (d.h. sich mit Deinem Router verbinden) oder ein eigener Access-Poin mit DHCP sein?

 

Beides sinnvollerweise, sonst wird die Erstkonfiguration schwierig...

 

Vielleicht ist ja nur an ein ad hoc Netz gedacht?

 

Dann würde sich eine Integration in eine Smart Home Lösung allerdings erübrigen. Macht auch aus Nutzersicht keinen Sinn, wer wollte schon ständig Wlan wechseln nur um die Xenia zu bedienen.

 

Es wird zunächst wenn kein WiFi hinterlegt ist, ein Accesspoint aufgemacht, der sich nach einer gewissen Zeit wieder ausschaltet. Über diesen accesspoint wird dann konfiguriert ob mit einem WLAN verbunden wird oder der accesspoint dauerhaft benutzt wird (Gartenlaube ohne WLAN) oder gar nichts, dann kommt weiter der AP nach dem einschalten des Netzschalters.

 

Thema Smart Home: hier gibt es so viele verschiedene Protokolle, und am Ende geht es nur ums Ein- oder Ausschalten. Angedacht ist ein interner Kalender und vllt. eine Anbindung an einen Google cal wie das die Fritz Steckdosen können. Zusätzlich kann man ja immernoch eine spezielle Steckdose dazwischenhängen. Das ist wahrscheinlich jeweils einfacher und günstiger als eine ganze Armada an Chips zu verbauen und zu pflegen für alle eventuell 2 oder 3 mal genutzten Smart Home Protokolle. Am Ende geht es um eine Kaffeemaschine und nicht um lasergesteuerte Überwachungstechnik.

 

@Phillip Hommel:Man braucht keine X Chips verbauen um verschiedene Protokolle zu implementieren, die verbreitetsten Smart Home Lösungen unterstützen HTTP/REST API.

@Iskanda: Ein denkbarer Mehrwert wäre die externe Timerprogrammierung über die verwendete Smarthome Lösung.
Klar kann man den Timer an der Xenia separat einstellen und das ist gut so. Für die Smarthome Fetischisten wäre aber siche die Möglichkeit den Timer extern über die Smarthome Zentrale zu setzen komfortabel.
z.B. Könnte die Smarthome Lösung abhängig von der Weckzeit des Nutzers den Timer anpassen.
Braucht man das unbedingt? Nein. Ist es ein Verkaufsargument? Vielleicht für einige Wenige, man unterschätzt wie oft Kaufentscheidungen auf Basis von Features beeinflusst werden, die man dann garnicht verwendet.

Man darf bei der ganzen Smarthome Überlegung nicht ausser acht lassen, dass hier zur Zeit noch haupsächlich eine technikaffine bastelfreudige Klientel am Werkeln ist. Die zur Zeit am Markt verfügbaren Lösungen sind entweder sehr teuer, sehr abgeschottet oder nicht endusertauglich. Ich selbst habe mit OpenHAB und FHEM herumexperimentiert und auch ein paar Sachen damit realisiert, würde meine Lösung aber nicht als Smart-Home bezeichnen (ich hab aber auch nicht neu gebaut und eine Umrüstung der gesamten Haustechnik ist finanziell nicht sinnvoll).



Gesendet von iPad mit Tapatalk

 

Ich find ne "Kaffeemaschine" hat im Smarthome nix zu suchen, oder steuert ihr auch eure Waschmaschine, Wäschetrockner, Kühlschränke usw.?
Wenn ich die um 6 Mo - Fr anhaben möchte und Sa + So um 8 dann gibt's dafür schon Lösungen. Uns selbst das Einschalten vom Büro aus, damit dat Dingen warm ist wenn man zu Hause ist lässt sich auch realisieren.

 

Waschmaschine und Wäschetrockner werden in Smarthomes durchaus gesteuert - da macht das auch Sinn.
Gerade Trockner kann man dann starten, wenn der Stromtarif günstiger ist oder die Photovoltaikanlage überschuss liefert. Energiemanagement ist eines der zentralen Themen bei Smarthome Lösungen und das wird in Zukunft eher noch mehr in den Vordergrund treten, wenn die Energieversorger Tageszeitabhängige Tarife focieren. Sind erstmal alle mit Smartmetern "zwangsbeglückt" wird diese Methode auf den Verbraucher Druck auszuüben zur "richtigen" Zeit seine Großverbraucher anzuwerfen gängige Praxis.


Gesendet von iPad mit Tapatalk