micst hat geschrieben: ↑26.08.2020, 23:48
ich bin auf der Suche nach dem kompromisslos besten Weg (für Softwareentwickler) meine Homematic zu Programmieren.
Da setzt Du Dir ja selber hohe Maßstäbe wenn das
kompromisslos sein soll. Wenn Du keine Kompromisse eingehen willst, bist Du mit der proprietären Skriptsprache von Homematic aus meiner Sicht schon mal auf dem flaschen Weg. Es gibt keine vollständige öffentliche Dokumentation zu einer API und die proprietären Skriptsprache wird auch nicht vom Hersteller selber weiterentwickelt. Wenn macht es also Sinn sich an offizielle Quellen vom Hersteller auszurichten und das ist die
Technische Dokumentation, da sind alle Daten zu den Geräten aufgeführt. Als Sprache bleibt bei Deinen Ansprüchen eigentlich nur ein objektorientierte Sprache der Wahl, mit der Du halt arbeiten willst.
micst hat geschrieben: ↑26.08.2020, 23:48
[*]Zuviel klicken bei der Programmierung (insbesondere wenn viele Einträge in Bedingungen notwendig sind)
Ich weis ja nicht was Du im Detail vorhast, aber wenn es wirklich komplex werden sollte, dann solltest Du eine objektorientierte Sprache nutzten und Dir eine Klasse schreiben und entsprechende Dinge vererben. Das brauchst Du auch nichts doppelt wenn Du das erst mal erzeugt hast.
micst hat geschrieben: ↑26.08.2020, 23:48
[*]Keine Versionierungsmöglichkeit (nogo, ich will ein git repo für meine Logik-Implementierung!)
Hier gilt das gleiche wie oben, in einer objektorientierte Sprache eine Klasse schreiben, die Klasse kannst Du dann auch versionieren. Wenn Du alle komplexeren Spripte versionieren willst, nutzte ich selber dazu IP-Symcon und
IPSymconConfigVC, damit wird alles auf Git versioniert.
micst hat geschrieben: ↑26.08.2020, 23:48
[*]Keine bzw. schlechte Wiederverwendbarkeit von Skripten/Programmen in anderen Skripten/Programmen
Zu Wiederverwertbarkeit nutzt man Klassen bzw. Traits. Ich nutzte dafür
PHP mit Klassen und Objekten und
Traits. Wenn ich einzelne Skripte erneut ansprechen will nutzte ich selber dazu
IPS_RunScriptEx und übergebe die entsprechenden Parameter an das zu verarbeitende PHP Skript.
micst hat geschrieben: ↑26.08.2020, 23:48
[*]Keine Funktionen mit Parametern/Rückgabewerten
Wenn Du Dir die Klasse selber schreibst, bestimmst Du die zu übergebenden Parameter und Rückgabewerte der Methode ja selber.
micst hat geschrieben: ↑26.08.2020, 23:48
[*]die beiden letzten Punkte bedeuten: viel Code Duplizierung, dadurch schlechte Wartbarkeit
s.o. Methoden nutzten und Traits dann kannst Du das auch besser warten und hast keine doppelten Codezeilen. Wenn Du mit einer passenden Entwicklungsumgebung Deiner Wahl arbeitest, wird Dir diese auch doppelten Code hervorheben.
micst hat geschrieben: ↑26.08.2020, 23:48
[*]Programme immer als Skript schreiben, ist am flexibelsten
Das wäre die erste Stufe, um das auch dauerhaft verwerten und versionieren zu können solltest Du Dir eine eigene Methode in einer objektorientierten Sprache der Wahl erstellen.
micst hat geschrieben: ↑26.08.2020, 23:48
[*]am besten direkt TCL Skripte entwickeln, bieten beste Flexibilität ohne Funktionsverlust ggü. in UI geschriebenen Skripten
Da bist Du aus meiner persönlichen Sicht auf dem Holzweg und das deckt sich nicht mit Deinem Anspruch einer kompromisslosen Umsetzung.
Nutze eine objektorientierte Sprache mit der Du auch Klassen erstellen kannst und vererben und suche Dir eine Sprache aus die auch weltweit benutzt wird und mit allen Funktionen dokumentiert ist. Und vor allem eine Sprache die auch weiter entwickelt wird, das ist bei der proprietären Skriptsprache von Homematic durch den Hersteller nicht der Fall. Der Hersteller setzt selber inzwischen auf Javascript, das im NEO Server, der auf der CCU3 vorinstalliert ist, benutzt wird. Auch NodeRed, das man optional nachinstallieren kann, setzt als Skriptsprache Javascript ein.
Als weltweit meist genutzte serverseitige Programmiersprache nutzte ich selber PHP um Skripte zu schreiben bzw. eigene Klassen und Methoden nutzten zu können.
micst hat geschrieben: ↑26.08.2020, 23:48
[*]
Habe ich bei TCL tatsächlich den vollen Funktionsumfang den Homematic Script mir bietet? Ich vermute es, konnte es aber noch nicht feststellen.
Meine persönliche Meinung zu Homematic Skript habe ich geschrieben, Du setzt damit auf ein Auslaufmodell, das so auch vom Hersteller weder in vollem Umfang mit API öffentlich dokumentiert ist, noch vom Hersteller weiterentwickelt wird. Ich würde Dir wenn Du wirklich eine kompromisslose Umsetzung suchst, wirklich eine objektorientierte Sprache Deiner Wahl an Herz legen und mit der dokumentieren Datenpunkten der
Technischen Dokumentation arbeiten.
micst hat geschrieben: ↑26.08.2020, 23:48
[*]mit WinSCP/Putty direkt auf dem Gerät arbeiten
Aus meiner persönlichen Sicht ebenfalls nicht die bevorzugte Methode einer kompromisslosen Umsetzung. Wenn lasse die CCU einfach das machen was Sie soll, nämlich als zertifiziertes Funkgateway arbeiten. Wenn es wirklich so komplex werden sollte das Du dafür eigene Klassen und Programme erwickeln willst, dann mach das auf einem externen System in einer Sprache der Wahl und greife dann von extern auch auf die Datenpunkte der CCU zu.
micst hat geschrieben: ↑26.08.2020, 23:48
[*]TCL lernen
[*]RaspberryMatic selber bauen
Auch mit RaspberryMatic gehst Du von vornherein einen Kompromiss ein. Du möchtest Funktionen ergänzen, die der Hersteller EQ3 absichtlich wegen
Funkanlagenrichtlinie und Konformität deaktiviert hat wie z.B. Bluetooth und WLAN? Wenn Du erweitere Funktionen brauchst und diese ohne Kompromiss nutzten willst, solltest Du externe Gateways ergänzen, die ebenfalls die Funkanlagenrichtlinie erfüllen und für die eine Konformitätserklärung vorliegt. Jeder der dann so was nutzten will, wenn Du so was zur Verfügung stellen willst, nutzt dann immer noch den Auslieferungszustand der CCU und verliert damit auch nicht den Support durch den Hersteller. Wenn Du so was wie RaspberryMatic nutzt hast Du zwar erweiterte Funktionen verlierst aber die Gewährleistung durch den Hersteller wie es auch im Handbuch steht.
eQ3 hat geschrieben:
Jeder andere Einsatz, als der in dieser Bedienungsanleitung beschriebene, ist nicht bestimmungsgemäß und führt zu Gewährleistungs- und Haftungsausschluss.
Wenn Du also was selber baust ist das auch ein Kompromiss zwischen den Funktionen, die Du selber ergänzen willst und damit aber auch die Gewährleistung durch den Hersteller verlierst und dem was der Hersteller Dir selber zur Verfügung stellt.
Sinnvoller wenn Du denn die Gewährleistung erhalten willst ist es komplexe Programme oder auch Ergänzungen der CCU mit weiteren zertifizierten Gateways oder externen Systemen zu ergänzen. Diese haben ebenfalls für sich wiederum eine Konformitätserklärung der Herstellers und damit bleibt sowohl auf der CCU selber als auch auf externen Systemen die Gewährleistung und der Support durch den Hersteller selber erhalten.
Insofern stellt das auch immer ein persönlicher Kompromiss dar und ist nicht unbedingt das was Du als
kompromisslos besten Weg bezeichnen würdest.
micst hat geschrieben: ↑26.08.2020, 23:48
[*]
Gibt es neben TCL noch tiefere und bessere Zugriffspunkte in das System? Ich will meine Logik nicht in C/C++ gießen, aber wenn es weitere Möglichkeiten gibt wäre das interessant.
Ich nutzte als Kommunikationsebene zu Homematic / Homematic IP bzw. zur CCU
BidCos über IP-Symcon und spreche damit alle in der
Technische Dokumentation des Herstellers dokumentierten Datenpunkte an.