Unabhängige WebUI entwicklen

[MaxDau]

Hallo

Wäre es nicht besser der Firmware eine ordentliche Schnittstelle zu verpassen und das Web von der Firmware zu trennen. Das würde nicht nur die Performance erhöhen sondern auch einen extrem großen und neuen Funktionsumfang ermöglichen.

Ich habe mir in den letzten Wochen viele Gedanken darüber gemacht und bin zu folgendem Ansatz gekommen.

Die Firmware wird von der normalen Webdarstellung befreit und erhält ein minimales Menü um Einstellungen zur Erreichbarkeit und Zugriff vorzunehmen.
(https://ccuip:port/admin)
Punkte wie
- Netzwerkeinstellungen
- Admin Passwort
- API Keys
- Modus (Zentrale / Gateway)

Ich würde als Schnittstelle eine Json API vorschlagen. Die ist leichter, schneller und einfach zu cachen bei geringem Speicherbedarf.

Danach wird eine Webapp erstellt, welche unabhängig vom Ort der Installation lediglich über die Schnittstelle der Firmware kommuniziert.

Mein persönlicher Ansatz wäre ein Webserver mit Php. Damit wäre es unabhängig vom Client / Endgerät möglich auch Events/Trigger zu abonnieren und diese zu verarbeiten und an die Clients (z.B. mit WebSocket) weiterzuleiten.
Der Vorteil durch die Trennung ist ganz offensichtlich, dass die Firmware nur noch genau das macht wozu sie da ist und keine Ressourcen für Addons, API (clients), Web oder Sonstigem verwenden muss.
Hingegen kann ich die Webapp beliebig skalieren und unabhängig von CCU auf einem Gerät meiner Wahl / VM betreiben.
Es wäre sogar problemlos möglich mehrere Instanzen des Webservers zu betreiben. Auch eine Verlagerung ins Internet (Webspace, Cloud, Server, VM) sind problemlos möglich, durch die Verwendung des API-Keys und ein paar wirklich einfachen Einstellungen für Access und Firewall. Damit ist es dann auch noch deutlich sicherer als die aktuellen Lösungen.

Im Zuge der Sanierung kann man dann gleich noch eine Brute Force erkennen integrieren.

Ein weiterer und sehr sehr wichtiger Aspekt sind die Addons. Viele Erweiterungen müssen nicht auf der Firmware laufen / installiert werden, weil sie eigentlich die Grundfunktionen der Firmware weder erweitern noch verändern. Wenn man diese Addons mittels php/html/JS umsetzt, wird nicht nur die Hardware der Firmware entlastet, sondern es bieten sich auch ganz neue Möglichkeiten.
Verschiebt man z.B. die Cache-Ebene auf den Webserver respektive auf Php, wird die Anzahl der API-Requests deutlich reduziert und die Geschwindigkeit aller Komponenten erheblich erhöht.
Zudem kann ich durch die Trennung von Web und Firmware, bei vielen Addons, Endgeräten, HM Geräten, etc, optimaler skalieren OHNE meine alten Geräte tauschen zu müssen.

Ich könnte jetzt noch unendlich weitere Vorteile wie getrennte Entwicklung, mehr Vielfalt und Addons, da Php weiter verbreitet ist, aufzeigen und sehe nur einen einzigen Nachteil, der aber eigentlich auch kein wirklicher Nachteil ist.

Aktuell hält man sich noch sehr nahe an der original Firmware auf. Das hat den Vorteil, dass bei einer neuen EQ3 Firmware Änderungen leichter übernommen werden können. In der Realität sieht es aber doch so aus, dass der Code / die Entwicklung in die andere Richtung fließt.
Daher empfinde ich es nicht als Nachteil sich weiter vom Original zu entfernen und einen Schritt aus der Bastler-Ecke raus zu gehen.
Dazu braucht es aber
- mehr Sicherheit (und echte Sicherheit)
- eine ordentliche API mit Dokumentation
- bessere und einfachere Skalierbarkeit

Freue mich auf eure Meinungen
MaxDau

[jmaus]

Wäre es nicht besser der Firmware eine ordentliche Schnittstelle zu verpassen und das Web von der Firmware zu trennen. Das würde nicht nur die Performance erhöhen sondern auch einen extrem großen und neuen Funktionsumfang ermöglichen.

Ich habe mir in den letzten Wochen viele Gedanken darüber gemacht und bin zu folgendem Ansatz gekommen.
[...]
Freue mich auf eure Meinungen

Da du hier "neu im Bunde bist" sage ich dazu meinen Standardsatz: Leg los und entwickle es und sende einen PR ein. Gedanken können sich viele machen (und haben das auch bereits mehrfach/vielfach gemacht) aber Zeit opfern wollen/können die wenigsten. Wenn du also KnowHow, technische Ressourcen und Motivation hast, leg los!

[MaxDau]

Etwas zu entwickeln ohne die Meinung der Community zu kennen oder überhaupt zu wissen ob die Richtung richtig ist, erachte ich nicht als sinnvoll. Habe dir dazu auch eine Nachricht geschrieben.

Ich habe genug Zeit und Erfahrung und bin bereit diese in RaspberryMatic zu investieren. Wie in meiner Nachricht geschrieben, sogar noch mehr als nur meine Zeit.
Gerne übernehme ich alles über der Firmware API. Gerne portiere ich auch vorhandene Addons wie Email, XML API o.Ä.
Aber einfach planlos loslegen... Da kann ich besseres mit meiner Zeit anfangen.

[jmaus]

Etwas zu entwickeln ohne die Meinung der Community zu kennen oder überhaupt zu wissen ob die Richtung richtig ist, erachte ich nicht als sinnvoll. Habe dir dazu auch eine Nachricht geschrieben.

Hast du? Hmm, ich bekomme leider so viele Anfragen das ich diese nicht immer entsprechend bearbeiten oder mit der notwendigen Tiefe auch wahrnehmen kann. Tschuldigung also schon einmal dafür. Auch gab es schon zich Leute die mir ihre guten Ratschläge bzw. Anfragen zur Weiterentwicklung dargelegt hatten, sogar bis hin zu großspurigen Unterstützungsbekundungen unter Zuhilfenahme irgendwelcher vermeintlicher "Mitarbeiter" von Web-Design Firmen, etc. Aber draus geworden ist nie was und es blieb immer bei diesen großspurigen Ankündigungen, vor allem als ich darum gebeten hatte sich doch erst einmal tiefgründiger mit der existierenden WebUI, den technischen Randbedingungen des Backend (tclsh, Linux, etc.) und der verschiedenen APIs (XMLRPC, etc.) zu beschäftigen. Dann ist der Kontakt immer irgendwann abgebrochen - vermeintlich weil es diesen Leuten dann doch vom Aufwand her zuviel wurde und man vllt. doch eher gedacht hatte es würde reichen nur den Anstoß zu geben und man darauf gehofft hatte, dass ich oder die Community das dann doch so umsetzen würde. Deshalb da auch meine anfängliche Skepsis - vor allem zu Personen die hier wie du frisch einfach so auftauchen, in der Community nicht bekannt sind und von denen ich auch auf GitHub noch nichts gelesen/wahrgenommen habe. Tschuldigung wenn das vllt. voreingenommen klingt, es dient aber momentan einfach dazu hier eine gewissen Filterung vorzunehmen. Und genau deshalb ja auch meine "Forderung", sich hier erst einmal zu beweisen bzw. "einen Namen" zu machen.

Ich habe genug Zeit und Erfahrung und bin bereit diese in RaspberryMatic zu investieren. Wie in meiner Nachricht geschrieben, sogar noch mehr als nur meine Zeit.
Gerne übernehme ich alles über der Firmware API. Gerne portiere ich auch vorhandene Addons wie Email, XML API o.Ä.
Aber einfach planlos loslegen... Da kann ich besseres mit meiner Zeit anfangen.

Willst du damit sagen wir gehen "planlos" vor? Nun, es gibt nunmal gewisse Abhängigkeiten (vor allem zu eQ3 und deren CCU Firmare) die man nicht einfach so aufbrechen kann oder mag. Wir sind und bleiben zum Teil davon abhängig was eQ3 selbst entwickelt/umsetzt in deren CCU3 firmware und auch wenn es dir nicht bewusst ist, aber große Teile der Firmware (vor allem die Schnittstellenprozesse zu Funk, Wired, HomeMaticIP, HomeMaticIP-Wired sind komplett closed source) inkl. der APIs. Insofern ist auch in diesem Bereich die Möglichkeit der Weiterentwicklung/Anpassung der APIs nur begrenzt möglich und man ist im Grunde darauf beschränkt welche Daten einem die existierenden APIs (XMLRPC, XML-API, JSON-RPC) zur Verfügung stellen. Aber du kannst dich gerne nochmal hinsetzen und deine Idee mal auf einem Blatt Papier genauer darlegen um so auch die Abhängigkeiten zu den existierenden Frameworks, Schnittstellen usw. aufzuzeigen und darauf basierend dann Verbesserungen/Umbauarbeiten vorschlagen. Denn wer mich näher kennt weiss, das ich im Grunde fast zu jeder Schandtat bereit bin - nur muss sie realisitisch und gut durchdacht sein und nicht vom Wohnzimmersessel aus als Geistesblitz kurz mal in ein Browserformular eines Online-Forums eingebongt worden sein.

[MaxDau]

Willst du damit sagen wir gehen "planlos" vor?

Mein Beitrag war eigentlich sehr deutlich und unmissverständlich formuliert.
Ich habe deutlich gesagt, dass RaspberryMatic ein gutes Projekt ist und ich mich deshalb beteiligen möchte. Jedoch nur nach Absprache mit der Community um meine Zeit nicht zu verschwenden.
Wie kommst nun darauf, dass eine Aussage zwischen Sätzen die mit Ich und Meine beginnen, auf einmal auf dich bezogen ist?
Ist das jetzt die neue Mode sinnlos irgendeinen Streit zu provozieren oder einfach nur eine Unart Aussagen aus den Kontext zu nehmen, negative zu deuten und auf sich / seine Arbeit zu beziehen.

Glaub mir, wenn ich Kritik los werden möchte, merkt man das (siehe dieser Beitrag).

Aber lassen wir das einfach gut sein.

Zum eigentlichen Thema:
Für mich ist eine wichtige Frage offen. Möchte man bei RaspberryMatic weiter jegliche Logik und Funktionen auf der CCU behalten oder wäre man grundsätzlich dazu bereit die CCU nur als Geräte-Zentrale zu verwenden und davon unabhängige Funktionen auf eine andere Ebene zu verlagern.

Ich habe aktuell zahlreiche Beispiele warum es aus meiner Sicht besser ist die Zentrale von zusätzlichen Funktionen zu trennen.

[jp112sdl]

Ich habe aktuell zahlreiche Beispiele warum es aus meiner Sicht besser ist die Zentrale von zusätzlichen Funktionen zu trennen.

Geht es bei der Trennung rein um eine Kapselung á la Docker - sprich: alles läuft weiter auf der selben Hardware, jedoch getrennt als Microservices?
Oder um eine komplett physische Trennung zwischen Gerät A, das die Schnittstellenprozesse bedient und Gerät B, das die Logik bereitstellt und über eine API mit A kommuniziert?

Aus meiner Sicht (ich zähle mich jetzt mal mit zur "Entwickler-Community") ist eine Hardware-Trennung ungünstig.
Mein persönlicher Anspruch (hier im Haus) ist es, dass die komplette Hausautomation weiterläuft, allein wenn nur der RaspberryPi in der Steckdose steckt.
Also ohne Abhängigkeit von LAN, WLAN, Switchen oder der Anbindung an Dritt-Prozesse (ioBroker, etc.pp.).

Das heißt, im Kern müssen schon Logik und Hardwareprozesse (zu Funk und Wired) zusammen arbeiten.
Dann liegt es auch nahe, eine Administrationsoberfläche darauf bereitzustellen.
Und dann sind wir eigentlich bei dem Stand "heute". Denn mehr als eine Admin-Oberfläche ist die WebUI nicht.

[jmaus]

Für mich ist eine wichtige Frage offen. Möchte man bei RaspberryMatic weiter jegliche Logik und Funktionen auf der CCU behalten oder wäre man grundsätzlich dazu bereit die CCU nur als Geräte-Zentrale zu verwenden und davon unabhängige Funktionen auf eine andere Ebene zu verlagern.

Das was du als Idee hier geäußert hast ist doch zumindest in teilen bereits jetzt möglich. Die APIs (XML-RPC, XML-API, ReGaSkripting und tclsh) sind ja reichlich bekannt. Und prinzipiell stimme ich dir ja zu das die CCU wie z.b. eine Pihilips Hue Bridge eine reine Gerätezentrale/Gateway sein sollte bzw dies im Grunde ja jetzt bereits ist.
Es ist jedoch auch so, das das was du hier vorschlägst bereits jetzt möglich ist. D.h. Du könntest eine WebApp oder sonstwas auf einem externen System entwickeln und diese über die bereits bekannten APIs auf die Geräte zugreifen lassen bis hin zum Anlernen neuer Geräte inkl Direktverknüpfungen. Nichts anderes machen Applikationen wie ioBroker, OpenHab oder gar das leider nicht mehr weiterentwickelte WebMatic Projekt. Der Ansatz bzw Idee die du da vorstellst ist also nicht gänzlich etwas neues.

Und ja, man könnte das natürlich weitertreiben, die WebUI gänzlich von der Zentrale entfernen und stattdessen das Hinzufügen/Konfigurieren von Geräten einer neuen Smartphone-App, einer WebApp oder ähnliches überlassen. Es spricht aber IMHO technisch/leistungsmäßig nichts dagegen eine solche Applikation auch gleich auf der CCU zu betreiben, wenn man es denn will. Nichts anderes macht die momentane WebUI ja, nur ist sie eben nicht so flexibel das man sie au CH auf einem anderen System betreiben kann. Aber im Prinzip ist das was die vorschwebt eben jetzt bereits möglich. Du könntest dich also jetzt bereits hinsetzen, solche eine flexible WebApp (mit welcher backend Technologie auch immer) implementieren anfangen und diese greift dann einfach über die bekannten APIs auf die Geräte, Einstellungen usw zu und kann diese auch manipulieren. Aber nochmal zur erinnerung: solche Ansätze gibt es z.b. mit ioBroker und anderen Applikationen ja bereits, nur wurden diese eben bisher nie soweit weiterentwickelt das die auch vollumfänglich die CCU inkl Geräteanlernen steuern können.

[MaxDau]

Geht es bei der Trennung rein um eine Kapselung á la Docker - sprich: alles läuft weiter auf der selben Hardware, jedoch getrennt als Microservices?
Oder um eine komplett physische Trennung zwischen Gerät A, das die Schnittstellenprozesse bedient und Gerät B, das die Logik bereitstellt und über eine API mit A kommuniziert?

Grundsätzlich soll alles auf einer Hardware betrieben werden können. So hätte ich mir auch die Auslieferung vorgestellt. Jedoch ist mein Gedanke Teile, die nicht zu den Grundfunktionen der CCU gehören (Historie, Email, WebUi und Addons ähnlicher Art auf die darüber liegende Schicht zu verlagern. Somit müssen die Addons auch nicht mehr mit der CCU selbst kommunizieren sondern erhalten Daten vom System darüber.

Ich habe hier zum Beispiel einen Anwendungsfall, der das sehr gut erklärt. 6 Wohn- und Büroeinheiten. Jede bekommt (alleine wegen räumlicher Trennung) eine CCU. Die Raumtemperatur wird basierend auf der Außentemperatur eingestellt.

In diesem Beispiel lasse ich die CCU einfach CCU sein, nehme die darüber liegende Komponente (Server, Web, oder wie auch immer bezeichnet) und packe sie auf nen Raspberry oder in eine VM. Über diese einzelnen Komponente kann ich jetzt alle CCUs steuern. Die Einrichtung bleibt mir zu 95% erspart, da die Addons nur auf der "Zwischenschicht" liegen und ich nicht jede CCU einzeln einrichten muss und jedes Addon 6 mal installieren und so weiter.
Zudem spare ich mir 5 Thermostate. In der Zwischenschicht kann ich mit der CCU A auf die Werte der CCU B zugreifen ohne diese beiden in irgendeiner Art und Weise miteinander zu verbinden.
Natürlich kann ich das auch ohne Zwischenschicht lösen. Dann bin ich aber wieder in der Bastelecke.

Es ist jetzt auch ziemlich egal wie die WebUi aussieht. Für den einfachen Anwender wird es auf dem Raspberry Pi 3 / CCU3 laufen mit Luft nach oben. Wenn ich aber viele HM Geräte im Einsatz habe und mir der RAM ausgeht oder ich andere Limitierungen umgehen möchte, kann ich einfach die Zwischenschicht "abnehmen" und auslagern. Die CCU läuft weiter als hätte sich nichts geändert. Nur eben mit mehr freien Ressourcen.
Zudem wäre das Vorgehen z.B. auch bei schwächere HW interessant.

CCU ist und bleibt CCU. Selbstständig und ohne Cloud(Zwang). Kein Internet, kein WLAN - CCU arbeitet weiter. Jedoch nur als das was die CCU eben sein soll - Gerätezentrale.

Ob und wie man das lösen möchte... Dafür gibt es viele Wege (wie z.B. Docker).

[Xel66]

Die Einrichtung bleibt mir zu 95% erspart, da die Addons nur auf der "Zwischenschicht" liegen und ich nicht jede CCU einzeln einrichten muss und jedes Addon 6 mal installieren und so weiter.
Zudem spare ich mir 5 Thermostate.

Du sparst Dir die einmalige One-Klick-Installation eines/mehrerer Addons, baust aber eine komplette eigenständige büroübergreifende Infrastruktur auf. Ich als Bürobetreiber einer Bürogemeinschaft oder Bewohner einer Wohneinheit fände es nicht sehr gut, wenn Nutzer aus einem anderen Büro/Firma oder mein Nachbar Zugriff auf mein Netzwerk haben. Zusätzlich musst Du die überlagerte Instanz administrieren und das zugrundeliegende Betriebssystem unterhalten und einen erhöhten Administrationsaufwand betreiben um eine überschaubare Anzahl von Außentemperatursensoren einzusparen. Zur Verteilung der Außentemperatur gäbe es auch andere Möglichkeiten.

Abgesehen davon ist das eine professionelle Anwendung, die man zwar durchaus mit Homematic realisieren kann, dessen Aufbau sich aber meilenweit von der eigentlichen Zielgruppe dieser Hausautomationslösung (Wohnung, EFH oder Mehrgenerationenhaus) entfernt. Als Benefit darf sich der Normalanwender dann mit derartigen komplexen Infrastrukturaufbauten rumschlagen, wenn das durch die "Weiterenticklung" zum Quasi-Standard wird.

[MaxDau]

Die Einrichtung bleibt mir zu 95% erspart, da die Addons nur auf der "Zwischenschicht" liegen und ich nicht jede CCU einzeln einrichten muss und jedes Addon 6 mal installieren und so weiter.
Zudem spare ich mir 5 Thermostate.

Du sparst Dir die einmalige One-Klick-Installation eines/mehrerer Addons, baust aber eine komplette eigenständige büroübergreifende Infrastruktur auf. Ich als Bürobetreiber einer Bürogemeinschaft oder Bewohner einer Wohneinheit fände es nicht sehr gut, wenn Nutzer aus einem anderen Büro/Firma oder mein Nachbar Zugriff auf mein Netzwerk haben.

Die Verwendung einer API und Zugriff auf ein Netzwerk kann man so eigentlich nicht gleich setzen. Es war auch nie die Rede davon, dass Dritte (unbefugte) Zugriff auf ein Netzwerk erhalten sollen.

Zusätzlich musst Du die überlagerte Instanz administrieren und das zugrundeliegende Betriebssystem unterhalten und einen erhöhten Administrationsaufwand betreiben um eine überschaubare Anzahl von Außentemperatursensoren einzusparen. Zur Verteilung der Außentemperatur gäbe es auch andere Möglichkeiten.

Das muss man eben nicht.
Ich spreche ja immer davon, dass man die Option schaffen kann. Das aktuelle Betriebssystem benötigt dafür nur das eine oder andere Paket. Eine Trennung in zwei Betriebssysteme auf einer HW ist nicht notwendig. ABER es besteht dann die Option eine Anwendung auf eine andere HW / Betriebssystem zu verlagern. Aktuell unmöglich.

Abgesehen davon ist das eine professionelle Anwendung, die man zwar durchaus mit Homematic realisieren kann, dessen Aufbau sich aber meilenweit von der eigentlichen Zielgruppe dieser Hausautomationslösung (Wohnung, EFH oder Mehrgenerationenhaus) entfernt. Als Benefit darf sich der Normalanwender dann mit derartigen komplexen Infrastrukturaufbauten rumschlagen, wenn das durch die "Weiterenticklung" zum Quasi-Standard wird.

Leider auch nicht richtig. Grundsätzlich muss sich der Normalanwender / die Zielgruppe mit dem Thema "unter der Haube" nicht im Geringsten beschäftigen. Es macht für den Nutzer aka Otto Normalverbraucher keinen Unterschied im Aufwand oder der Komplexität. Es ist eher das Gegenteil der Fall. Ich kann als Nutzer leichter etwas ändern, da ich mich nicht mehr in schlecht oder überhaupt nicht dokumentierte Themen einarbeiten muss. Weiter muss ich nicht mehrere Programmiersprachen und Syntaxen lernen / können um etwas ändern zu können. Zu einen der wohl grössten Vorteile zählt wohl auch, dass man sich in die unterschiedlichen APIs nicht mehr einarbeiten muss. Und dennoch bleiben alle anderen Möglichkeiten wie bisher weiter erhalten. Wer die XML-RPC verwenden will, kann das weiter machen. Und wer das XML-API Addon verwendet kann das auch weiter machen.


Die Bereitstellung einer Option bedeutet auch nicht, dass jeder diese verwenden muss. Die Zwischenschicht kann man im Homematic-Kreis mit der Firewall-Nutzung vergleichen. Nur weil ich Zugriffe zulassen kann bedeutet das doch nicht gleich, dass ich alle Ports öffnen muss.
Und nur weil man die Option schafft, Geräte CCU übergreifend zur Verfügung stellen zu können, bedeutet das nicht, dass mein Nachbar jetzt Zugriff auf meine Geräte oder mein Netzwerk hat. Das sind leider falsch Rückschlüsse. Du kannst dir das eher so vorstellen, dass in deiner CCU ein Gerät mehr verfügbar ist, das die Hausverwaltung mit dir geteilt hat. Was du damit machen darfst (nur Werte lesen, Einstellungen ändern, etc) ist dann eine Frage der Konfiguration. Also welche Rechte räumt dir die Hausverwaltung ein.
Wenn wir schon bei dem Thema sind:
Stell dir mal vor, dass die Oma von nebenan bei der Hausverwaltung anruft, weil ihre Heizung im Bad nicht geht. Dann besteht die Möglichkeit, dass die Hausverwaltung erst mal die Einstellungen der CCU prüft. Wenn man dann schon das Problem sieht, wie zum Beispiel Akku leer, keine Funkverbindung, Soll-Temp auf 15 Grad gestellt o.Ä., kann man darauf richtig reagieren ohne gleich den Sanitär schicken zu müssen. Natürlich kann man all das jetzt auch irgendwie regeln. Aber, und das ist der eigentliche Punkt, auf den ich mit dem Thema hinaus möchte; Als Hausverwaltung, Nutzer, Otto Normalverbraucher ist jede Arbeit die man macht immer nur für einen selber und muss von vielen Leuten immer wieder gemacht werden.
Gehen wir einfach mal davon aus, dass es die zusätzliche Schicht gibt. Und es gibt die Funktion oder ein AddOn ShareDevice. Nicht nur, dass die Programmierung einmal gemacht werden muss. Die Funktion ist zu 100% unabhängig von der CCU. Die Funktion muss nicht mit einem Patch in die EQ-3 Software eingebunden werden. Die Funktion muss bei der Entwicklung von RaspberryMatic (Hauptsystem) nicht berücksichtigt werden und hat auch keinerlei Auswirkungen auf das Hauptsystem.

@jmaus
Du hast absolut Recht. Habe mir da ein paar Gedanken dazu gemacht und werde das so angehen wie du das vorgeschlagen hast. Da ich einige Punkte für mich eh umsetzen möchte, ist es wohl der beste Weg auf dem aufzubauen was da ist.