Unabhängige WebUI entwicklen

Einrichtung, Nutzung und Hilfe zu RaspberryMatic (OCCU auf Raspberry Pi)

Moderatoren: jmaus, Co-Administratoren

Xel66
Beiträge: 10310
Registriert: 08.05.2013, 23:33
System: Alternative CCU (auf Basis OCCU)
Wohnort: Nordwürttemberg
Hat sich bedankt: 179 Mal
Danksagung erhalten: 757 Mal

Re: RaspberryMatic - Verbesserungsvorschläge/Wünsche

Beitrag von Xel66 » 21.11.2021, 22:45

MaxDau hat geschrieben:
21.11.2021, 20:56
Es war auch nie die Rede davon, dass Dritte (unbefugte) Zugriff auf ein Netzwerk erhalten sollen.
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.
MaxDau hat geschrieben:
21.11.2021, 20:56
Das muss man eben nicht.
Ich spreche ja immer davon, dass man die Option schaffen kann.
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.
MaxDau hat geschrieben:
21.11.2021, 20:56
Leider auch nicht richtig. Grundsätzlich muss sich der Normalanwender / die Zielgruppe mit dem Thema "unter der Haube" nicht im Geringsten beschäftigen.
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.
MaxDau hat geschrieben:
21.11.2021, 20:56
Ich kann als Nutzer leichter etwas ändern, da ich mich nicht mehr in schlecht oder überhaupt nicht dokumentierte Themen einarbeiten muss.
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.
MaxDau hat geschrieben:
21.11.2021, 20:56
Weiter muss ich nicht mehrere Programmiersprachen und Syntaxen lernen / können um etwas ändern zu können.
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.
MaxDau hat geschrieben:
21.11.2021, 20:56
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.
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.
MaxDau hat geschrieben:
21.11.2021, 20:56
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.
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.
MaxDau hat geschrieben:
21.11.2021, 20:56
Dann besteht die Möglichkeit, dass die Hausverwaltung erst mal die Einstellungen der CCU prüft.
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.
MaxDau hat geschrieben:
21.11.2021, 20:56
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.
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.
MaxDau hat geschrieben:
21.11.2021, 20:56
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.
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?

Gruß Xel66
-------------------------------------------------------------------------------------------
343 Kanäle in 118 Geräten und 264 CUxD-Kanäle in 33 CUxD-Geräten:
282 Programme, 246 Systemvariablen und 144 Direktverknüpfungen,
RaspberryMatic Version: 3.61.5.20211113 + Testsystem: CCU2 2.53.27
-------------------------------------------------------------------------------------------
Einsteigerthread, Programmlogik-Thread, WebUI-Handbuch

NickHM
Beiträge: 3108
Registriert: 23.09.2017, 12:04
Hat sich bedankt: 21 Mal
Danksagung erhalten: 41 Mal

Re: Unabhängige WebUI entwicklen

Beitrag von NickHM » 24.11.2021, 12:53

Hallo

was mir gleich bei ersten Beitrag aufgefallen ist und was in den vielen Zeilen danach auch schon angemerkt wurde ...
Wo ist der grundlegende Unterschied des Vorschlags zu schon bestehenden Lösungen.
Es gibt CCU User, die die WebUi nur zum Anlernen und einmaligen Konfigurieren der Geräte benutzen und das Teil sonst nur als Funk Gateway benutzen. Und es gibt diverse Abstufungen und Koexistenzen.
Schon seit der ersten CCU Generation nutze ich die Zusatzsoftware Homeputer Studio CL. Für alle Programmierungen, die Variablen benötigen, wo gerechnet werden muss, ein definierter Ablauf mit Schleifen, Verzweigungen und Wartezeiten notwendig ist. Ich hatte keine Motovation dafür extra die CCU Script Sprache zu lernen.
Inzwischen gibt es ioBroker wo diverse Adapter die Erstellung eigener Bedienoberflächen gestatten und komplexe Programme im Baukastenprinzip möglich sind.
Es gibt für MacOs und iOS die App Pocket Control, die ebenfalls eine WebUi auf der CCU fast überflüssig macht.
...

Warum nicht etwas bestehendes über Jahre kontinuierlich weiter entwickeltes verbessern, statt ein neues Produkt von Grund auf zu erfinden, dass die identischen Schnittstellen zur CCU nutzt(en muss) ??

TomMajor
Beiträge: 1614
Registriert: 30.08.2017, 23:25
Hat sich bedankt: 150 Mal
Danksagung erhalten: 327 Mal
Kontaktdaten:

Re: RaspberryMatic - Verbesserungsvorschläge/Wünsche

Beitrag von TomMajor » 24.11.2021, 14:29

Xel66 hat geschrieben:
21.11.2021, 22:45

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.
Sehr gut auf den Punkt gebracht und volle Zustimmung. :)
Viele Grüße,
Tom

ProfDrYoMan
Beiträge: 114
Registriert: 25.11.2018, 15:16
System: Alternative CCU (auf Basis OCCU)
Hat sich bedankt: 6 Mal
Danksagung erhalten: 4 Mal

Re: Unabhängige WebUI entwicklen

Beitrag von ProfDrYoMan » 24.11.2021, 17:51

Ich denke auch, vieles davon ist vergebene Liebesmüh.

Hier läuft ein RM ohne jedes Addon, ohne irgendein Programm. RM ist nur eine Hülle and die Sensoren/Aktoren.
Ich brauche die GUI zum anlernen und um ein paar Direktverknüpfungen zu setzen.
Da "ertrage" ich auch was aktuell da ist und freue mich daran, dass es einfach tut, auch wenn spröde aussehend.
Es ist einfach gut, so wie es ist. Danke Jens! (Vor allem das tailscale macht einem das Leben manchmal leichter.)

Oben drauf klebt in meinem Fall Home Assistant in einem Docker auf der gleichen Maschine, das gibt es aber auf im Bundle mit RM.
Da dran hängt dann auch noch Zigbee und Z-Wave und ESPhome.
Andere nutzen IoBroker mit ähnlichem hinten dran.

Jetzt mag jemand sagen, dass ist mehr Zeug was ausfallen kann, korrekt, aber es ist die selbe physikalische Kiste und es ist ruckzuck auf eine andere restored. Backup der Configs täglich. Die Installation ist in 1h gemacht. Egal wie man es nimmt, man braucht jemand der das kann. Komplett ohne Knowhow geht's nie.

Eine Sache die es meiner Ansicht nach Wert wäre:

Home Assistant und HomeMatic passen nicht so 100%. Die neuen Devicetypen von HmIP (z.B. das Scloss HMIP-DLD) werden von https://github.com/danielperna84/pyhomematic nicht sauber unterstützt. Der Maintainer hat da was Neues gestartet, aber aus Mangel an aktiven Mitstreitern steht das: https://github.com/danielperna84/hahomematic

Du würdest also mindestens 684 Leute die das laut https://analytics.home-assistant.io/#integrations HA mit HMIP und die Analytics Funktion an haben
erfreuen, wenn du deine Energie da reinsteckst. :)

Soweit ich weiß unterstützt IoBroker HMIP sauber/vollständig.

Hypnos
Beiträge: 437
Registriert: 06.01.2018, 12:48
System: Alternative CCU (auf Basis OCCU)
Hat sich bedankt: 51 Mal
Danksagung erhalten: 35 Mal

Re: Unabhängige WebUI entwicklen

Beitrag von Hypnos » 25.11.2021, 07:40

Hallo,
ProfDrYoMan hat geschrieben:
24.11.2021, 17:51
Home Assistant und HomeMatic passen nicht so 100%. Die neuen Devicetypen von HmIP (z.B. das Scloss HMIP-DLD) werden von https://github.com/danielperna84/pyhomematic nicht sauber unterstützt. Der Maintainer hat da was Neues gestartet, aber aus Mangel an aktiven Mitstreitern steht das: https://github.com/danielperna84/hahomematic
Wenn ich Home Assistant mit RaspberryMatic am Laufen habe, wozu wird dann noch pyhomematic/hahomematic benötigt?

Sind nicht alle Homematic Devices von RaspberryMatic dann über das RaspberryMatic AddOn in HomeAssistant verfügbar?

Ich frage weil ich gerade am Umstieg auf HomeAssistant bin und da nichts vermisse. Ein Grund könnte hier sein, dass ich in HomeAssistant als Logikschicht Node-Red einsetze und dort eine direkte Verbindung zur RaspberryMatic habe mit der ich bis hin zu rpc Befehlen Zugriff auf alle Attribute der Homematic Devices habe.

Zum eigentlichen Thema, sehe ich es wie meine Vorredner. Die WebUI ist eine reine Administrations-Oberfläche, welche auch direkt auf dem System laufen sollte und mit diesem direkt verbunden sein kann. Für alles andere, nutze ich dann eben ein anderes System (HomeAssistant/IOBroker/OpenHAB/...), welche entkoppelt laufen. In gewissen Bereichen kann ich von diesen anderen Systemen auch administrative Aufgaben durchführen (wie Heizungsprofile ändern, etc...). Anstelle die WebGUI zu einem FrontEnd umzubauen sollte man vielleicht überlegen in wieweit man weitere (teilweise administrative) Funktionen "von außen" einfacher (REST-Schnitstelle/...) zugänglich macht.

Beipiele:
  • Warum sollte es nicht möglich sein den 60 Sekunden Anlern-Vorgang nicht auch von außen über einen Befehl starten zu können? Damit derjenige, welcher das benötigt sich in seiner Oberfläche (HomeAssistant/IOBroker/OpenHAB/...) einen Button dafür hinlegen kann. (Ich denke hier an sowas wie bei Zigbee2MQTT.)
  • Für die RPC Befehle kann man sich auf die Events subscriben. Etwas ähnliches fehlt bei der REGA (z.B. Systemvariablen). Aktuell muss man diese in einem Intervall abfragen.
Gruß
Zuletzt geändert von Hypnos am 25.11.2021, 07:53, insgesamt 1-mal geändert.

Benutzeravatar
jmaus
Beiträge: 7874
Registriert: 17.02.2015, 14:45
System: Alternative CCU (auf Basis OCCU)
Wohnort: Dresden
Hat sich bedankt: 268 Mal
Danksagung erhalten: 972 Mal
Kontaktdaten:

Re: Unabhängige WebUI entwicklen

Beitrag von jmaus » 25.11.2021, 07:50

Hypnos hat geschrieben:
25.11.2021, 07:40
ProfDrYoMan hat geschrieben:
24.11.2021, 17:51
Home Assistant und HomeMatic passen nicht so 100%. Die neuen Devicetypen von HmIP (z.B. das Scloss HMIP-DLD) werden von https://github.com/danielperna84/pyhomematic nicht sauber unterstützt. Der Maintainer hat da was Neues gestartet, aber aus Mangel an aktiven Mitstreitern steht das: https://github.com/danielperna84/hahomematic
Wenn ich Home Assistant mit RaspberryMatic am Laufen habe, wozu wird dann noch pyhomematic/hahomematic benötigt?
pyhomematic/hahomematic wird intern von HomeAssistant als Ebene zwischen der CCU und HomeAssistant verwendet.
RaspberryMatic 3.61.5.20211113 @ ESXi – ~195 Hm-RF/HmIP-RF/HmIPW Geräte + ioBroker – GitHub / Twitter / Facebook / Sponsors

deimos
Beiträge: 4620
Registriert: 20.06.2017, 10:38
Wohnort: Leimersheim
Hat sich bedankt: 89 Mal
Danksagung erhalten: 612 Mal
Kontaktdaten:

Re: Unabhängige WebUI entwicklen

Beitrag von deimos » 25.11.2021, 08:27

Hi,
Hypnos hat geschrieben:
25.11.2021, 07:40
Beipiele:
  • Warum sollte es nicht möglich sein den 60 Sekunden Anlern-Vorgang nicht auch von außen über einen Befehl starten zu können? Damit derjenige, welcher das benötigt sich in seiner Oberfläche (HomeAssistant/IOBroker/OpenHAB/...) einen Button dafür hinlegen kann. (Ich denke hier an sowas wie bei Zigbee2MQTT.)
Das geht laut Doku der RPC Schnittstellen bereits jetzt.

Viele Grüße
Alex

ProfDrYoMan
Beiträge: 114
Registriert: 25.11.2018, 15:16
System: Alternative CCU (auf Basis OCCU)
Hat sich bedankt: 6 Mal
Danksagung erhalten: 4 Mal

Re: Unabhängige WebUI entwicklen

Beitrag von ProfDrYoMan » 25.11.2021, 09:51

Hypnos hat geschrieben:
25.11.2021, 07:40
Ich frage weil ich gerade am Umstieg auf HomeAssistant bin und da nichts vermisse. Ein Grund könnte hier sein, dass ich in HomeAssistant als Logikschicht Node-Red einsetze und dort eine direkte Verbindung zur RaspberryMatic habe mit der ich bis hin zu rpc Befehlen Zugriff auf alle Attribute der Homematic Devices habe.
Warum hast du HomeAssistant am laufen, wenn als Programlogic dann NodeRed unter Umgehung von HomeAssistant nutzt?
Ergibt wenig Sinn aus meiner Sicht. Da kannst du dann auch gleich NodeRed als AddOn im RM laufen lassen.

HomeAssistant, bzw. pyhomematic was aktuell die Schnittstelle ist, hat keine saubere vollständige Unterstützung für alle Attribute der HMIP devices (geht aber man muss überall selber Sensoren definieren) und kann mit neuern Geräten (HMIP-DLD z.b.) nicht sauber umgehen, da es nicht dafür ausgelegt ist, dass SollZustand und IstZustand in unterschiedlichen Entities vorliegt. hahomematic soll das lösen. Lies einfach mal die Texte in dem Github repository.
IoBroker ist da vollständig, aber für mich ist das so eine "Frickelsoftware" die mag ich nicht einsetzen. MEINE Meinung.
Zuletzt geändert von ProfDrYoMan am 26.11.2021, 13:24, insgesamt 1-mal geändert.

Roland816
Beiträge: 38
Registriert: 26.01.2019, 14:29
Wohnort: Friedrichshafen
Hat sich bedankt: 11 Mal
Danksagung erhalten: 2 Mal

Re: Unabhängige WebUI entwicklen

Beitrag von Roland816 » 25.11.2021, 10:21

NickHM hat geschrieben:
24.11.2021, 12:53
Warum nicht etwas bestehendes über Jahre kontinuierlich weiter entwickeltes verbessern, statt ein neues Produkt von Grund auf zu erfinden, dass die identischen Schnittstellen zur CCU nutzt(en muss) ??
Dem kann ich nur beistimmen.
Nutze die WEBUI für alles. Sicher ist sie nicht das eleganteste, jedoch damit habe ich am wenigsten Aufwand.
Wenn ich dann noch etwas darüber installieren muss, muss ich es auch verwalten. Also einarbeiten und laufend auf dem aktuellen Stand halten. Alles Aufwand der bei einem sonst stabilen System unnötig ist.
Habe auch einige kleine Skripte gemacht die Lücken ausfüllen. Hier wäre mir mehr Zugriff auf die Komponenten und Dokumentation für Nichtprogrammierer recht.
Aus meiner Programmiererfahrung erfuhr, ich dass durch die Dokumentation sehr viele Fehler gefunden werden. Der Aufwand lohnt sich.
CCU3, RaspberryMatic, Controme. Zur Heizungssteuerung und Haussicherheit.

ProfDrYoMan
Beiträge: 114
Registriert: 25.11.2018, 15:16
System: Alternative CCU (auf Basis OCCU)
Hat sich bedankt: 6 Mal
Danksagung erhalten: 4 Mal

Re: Unabhängige WebUI entwicklen

Beitrag von ProfDrYoMan » 25.11.2021, 13:28

Sobald du mehr als nur HMIP oder Homematic nutzen willst brauchst du eh was oben drüber. Und das wird bei vielen der Fall sein, weil es einfach nicht alles von EQ3 gibt oder preislich anderes auch sehr interessant ist.

Also frage ich anders herum. Wieso brauche ich soviel auf HMIP/Homematic Seite, wenn ich doch eigentlich nur ein gateway haben möchte wie z.B. für Zigbee und Z-Wave und ...?

Dann kann man sowas Potentes wie Home Assistant oder IOBroker nutzen und gut. Wie gesagt, wenn man eh andere Sachen als HMIP oder Homematic haben will kommt man eh nicht aussen rum.

Und genau das bietet RM. Superstabil. Nötige GUI sinnvoll implementiert. Saubere Backups/Config-saves. Läuft in VM auf fast jeder Hardware. Was will man da mehr?

Ja ich weiß, jeder hat andere Ansprüche und Jens kann ganz sicher nicht alles erfüllen. Ich finds klasse, das er RM stabil und in kleinen Schritten am leben hält.

Antworten

Zurück zu „RaspberryMatic“