Wenn Du die CCUs nicht gemeinsam in einem separaten "Automations"-Netz betreiben willst, sondern jede in ihrem eigenen der Wohnung oder Büro vorhandenen Netzwerk, damit die jeweiligen Anwender auch administrativen und steuernden Zugriff darauf haben, wie willst Du die Netzwerke dann wirksam voneinander trennen? Für den gegenseitigen Zugriff der CCUs auf eine Zentralinstanz bzw. andersherum oder gemeinsamer Nutzung einzelner Geräte benötigst Du zwangsweise ein gemeinsames Netzwerk. Und CCUs lassen sich relativ problemlos zusätzlich als Proxy konfigurieren, womit ein Zugriff auf die jeweiligen lokalen Ressourcen möglich ist. Würde ich weder als Bürobetreiber noch als Bewohner wollen. Du kannst Dich nicht waschen, ohne Dich nass zu machen. Sprich: Du kannst die Netze dann nicht sicher trennen.
Was ist dann gegenüber den jetzigen bestehenden Möglichkeiten (z.B. iobroker & Co) gewonnen? Solche Systeme können wenigstens gegenüber Deiner vorgeschlagenen Lösung noch mit anderen Automatisierungssystemen und Geräten aller möglichen Hersteller umgehen.
Mich interessiert im Status Quo auch nicht, wie die ReGa im einzelnen arbeitet. Ich habe derzeit eine WebUI, in der ich Geräte anlernen und administrieren sowie die automatischen Abläufe programmieren kann. Dieses Webinterface kommt auf der gleichen Hardware daher wie die unterlagerte Automatisierung nebst embedded OS. Ich sehe einfach keinen Sinn darin, diese funktionelle Einheit auf einer Hardware auseinanderzureißen oder zusätzliche Schichten einzuziehen, weil der der Vorteil eines solchen Ansatzes irgendwie nicht einleuchten will. Würde ich sowas wollen, könnte ich mich schon jetzt aus einem bunten Potpourrie bedienen. Ginge es um die Erweiterung der Interoperatibilität mit anderen Systemen, könnte ich dem noch was abgewinnen. Aber das scheint ja nicht das wirkliche Ziel zu sein.
Ich finde das WebUI auch nicht gerade ansprechend, aber wenn ich nichts zu administrieren habe, dann sehe ich nichts davon. Ist wie beim TV. Ich muss äußerst selten mal neue Sender suchen und muss dafür tiefer in die Oberfläche eintauchen. Im normalen TV-Betrieb brauche ich aber von der Administratonsoberfläche nichts, sondern bediene den Fernseher mit der Fernbedienung. Bei meiner Hausautomation will nicht nicht mal was bedienen, denn es soll automatisch funktionieren. Meines Erachtens werden bei einer Neuentwicklung der Oberfläche und Beibehaltung des Unterbaus nur unnötig Entwicklungsressourcen ohne wirklichen Funktionsgewinn gegenüber dem bestehenden System gebunden, die besser in der wirklichen Weiterentwicklung oder Interoperatibilität mit anderen Systemen und vor allem Fehlerbeseitigung des bestehenden Systems investiert würden. Nebenbei kann man sich ja etwas um die Optik kümmern und das ein oder andere nützliche Feature hinzufügen. Bisher hat sich ja auch schon einiges getan. Dass die vorhandene WebUI ein ziemlicher programmiertechnischer Verhau ist, habe ich durchaus wahrgenommen.
Meine Skepsis nährt sich aus den vielen Projekten rund um Homematic, die als one men show mit großen Versprechungen begonnen haben und dann später nicht mehr gewartet und an neue Versionen angepasst werden, weil sich der Maintainer zurückgezogen und auf ein anderes Pferd gesetzt hat. Da zieh' ich perönlich den Hut vor jmaus für sein Engagement rund um Raspberrymatic, dass er immer noch nicht die Lust verloren hat.
Nun ja, auch ein neu entwickeltes System benötigt eine Einarbeitung und Dokumentation. Und die vorhandenen Funktionalitäten müssen auch in einer veränderten Oberfläche nutz- und administrierbar sein. Für mich ist nicht einsichtig, dass das dann einfacher gehen sollte, nur weil es ggf. etwas anders aussieht, unter der Oberfläche etwas anders arbeitet, aber trotzdem die vorhandenen Hardwareschnittstellen (Datenpunkte) ansprechen muss und somit an deren Möglichkeiten gebunden ist.
Den Großteil meiner Automationen konnte ich ganz ohne Programmiersprachen einfach durch Auswahl der Möglichkeiten an Geräten, Verknüpfungen und Ereignissen im WebUI anlegen und ändern. Dass ReGa-Script als Erweiterung der innewohnenden Möglichkeiten der WebUI nicht der Weisheit letzter Schluss ist, habe ich durchaus zur Kenntnis genommen. Aber nur weil am Ende eine andere Programmiersprache benutzt würde, ist es noch lange nicht besser und geht auch nicht dem Einsteiger ohne Einarbeitung von der Hand. Und wer jetzt z.B. unbedingt in NodeRed programmieren will, kann das jetzt auch schon tun. Es gibt die notwendigen Addons und Middlewarelösungen doch schon.
Du vergisst, dass dann - um bei Deinem Beispiel zu bleiben - in diesem Konstrukt der Außentemperatursensor mit mehreren CCUs sprechen müsste. Dazu müsstest Du aber auch die Firmware des Sensors umprogrammieren, damit dieser das kann. Willst Du dagegen die Weiterleitung der Sensordaten von einer CCU zur anderen aber über ein LAN realisieren, brauchen die CCUs wieder ein gemeinsames Netz. Womit wir wieder beim eingangs skizzierten Szenario wären.
Wenn Du das nicht über ein gemeinsames LAN machen willst/kannst, dann müssen z.B. die CCU über z.B. die Funkschnittstelle miteinander kommunizieren. Dazu muss aber eine gegenseitige Erreichbarkeit realisiert werden. Auch wieder schwierig.
Ich würde als Administrator des Systems meiner Wohnung aber nicht, dass da irgendwer Fremdes draufschaut. Womit wir wieder im Bereich "professioneller Einsatz" wären. Dein beschriebenes Szenario wäre nämlich nur in Umgebungen interessant, wenn dem Bewohner/Büronutzer ein solches System vorinstalliert hingesetzt wird und er sich nicht um die Administration kümmern will (oder darf). Allerdings dürfte solch eine Installation die Integration eigener Hardware und Programmierung eigener Automationen schon wieder ausschließen (Stichwort: Gewährleistung und Wartung durch den Installateur). Ein Deinem Beispielumfeld wäre m.E. vielleicht die Cloudlösung mit mehren Accesspoints der bessere Lösungsansatz. Es ist eben nicht der normale Anwendungsfall für den typischen Homematic-Anwender (wenn es den denn gibt) mit CCU, denn das System ist eben für den Home-Bereich (Wohnung, Einfamilien- oder Mehrgenerationenhaus) konzipiert. Für Dein beschriebenes Konstrukt gibt es professionelle Systeme.
Jedes System muss für sich sowieso programmiert und die verbaute Hardware angemeldet und eingerichtet werden, da sich die Nutzungsgewohnheiten in Deinem Konstrukt Büro/Wohnungen schon stark unterscheiden. Man gewinnt auch durch eine zusätzliche Schicht oder einzelne shared devices nicht wirklich was.
Also sowas, was in der ein oder anderen Ausprägung mit iobroker, HomeAssistant, NodeRed, HPCL, Mediola Automation Manager, openHAB, FHEM, IP-Symcon bereits vorhanden ist?MaxDau hat geschrieben: ↑21.11.2021, 20:56Die 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.
Gruß Xel66
