Scripting für Entwickler

Homematic-, TCL- und Shell-Script, Toolchain, C, etc.

Moderator: Co-Administratoren

MichaelN
Beiträge: 9534
Registriert: 27.04.2020, 10:34
System: CCU
Hat sich bedankt: 692 Mal
Danksagung erhalten: 1604 Mal

Re: Scripting für Entwickler

Beitrag von MichaelN » 27.08.2020, 21:17

Vom Nutzen der nativen HM Skriptsprache auf eine Manipulation der Funk Eigenschaften zu kommen ist aber ein weiter Weg. Von letzterem war nämlich nie die Rede.
LG, Michael.

Wenn du eine App zur Bedienung brauchst, dann hast du kein Smarthome.

Wettervorhersage über AccuWeather oder OpenWeatherMap+++ Rollladensteuerung 2.0 +++ JSON-API-Ausgaben auswerten +++ undokumentierte Skript-Befehle und Debugging-Tipps +++

Fonzo
Beiträge: 6673
Registriert: 22.05.2012, 08:40
System: CCU
Hat sich bedankt: 25 Mal
Danksagung erhalten: 478 Mal

Re: Scripting für Entwickler

Beitrag von Fonzo » 27.08.2020, 21:47

MichaelN hat geschrieben:
27.08.2020, 21:17
Vom Nutzen der nativen HM Skriptsprache auf eine Manipulation der Funk Eigenschaften zu kommen ist aber ein weiter Weg.
Was in welcher Form von Hersteller beanstandet wird bzw. bei welchen Skripten es dann zu einem Gewährleistungsausschluss durch den Hersteller kommt kann ich persönlich nicht beurteilen, da ich selber keine Skripte auf der CCU3 nutzte und einen solchen Fall glücklicherweise auch noch nicht hatte. Da die Homematic Skript Sprache aber ihre Grenzen besitzt, von dem was man für Softwareentwicklung ohne Kompromisse einzugehen bräuchte, ist man ganz schnell in der Verlockung eben Dinge an der CCU zu modifizieren um diese Schwächen bzw. Grenzen der Homematic Skript Sprache zu umgehen bzw. aufzuheben. Spätestens dann wirst Du wieder Probleme bekommen mit der Gewährleistung durch den Hersteller, wenn man damit selber leben kann ist das ja aber ok. Ansonsten würde ich persönlich nach wie vor externe Systeme nutzten mit Sprachen, die für Softwareentwicklung ausgelegt sind und dann eben über definierte Schnittstellen des Herstellers auf die CCU zugreifen. Damit hat man zumindest beides eine professionelle IDE ohne Kompromisse mit dem notwendigen Funktionsumfang und auch eine funktionierende CCU ohne den Kompromiss die Gewährleistung zu verlieren.

MichaelN hat geschrieben:
27.08.2020, 21:17
Von letzterem war nämlich nie die Rede.
Da bezog ich mich auf die Aussage das mit der Installation von CUxD die Gewährleistung durch den Hersteller endet, und das kann ich persönlich zumindest aus Sicht des Herstellers nachvollziehen. Auch wenn es vielleicht für den einzelnen Nutzer einen Reiz hat statt einem zusätzlichen Funkgateway mit Konformitätserklärung einfach einen USB Stick an die CCU anzuschließen, hat der Hersteller da zumindest keinen direkten Einfluss mehr darauf, was die direkten Funkeigenschaften der CCU anbelangt.

micst
Beiträge: 16
Registriert: 09.08.2020, 13:14
System: Alternative CCU (auf Basis OCCU)
Hat sich bedankt: 5 Mal

Re: Scripting für Entwickler

Beitrag von micst » 28.08.2020, 23:54

Hallo und ersteinmal herzlichen Dank für die vielen ausführlichen Antworten! Ich denke ich sollte meine Vorstellungen etwas präzisieren um die Diskussion auf den Bereich zu fokussieren den ich für relevant halte. Tut mir leid wenn der Ursprungspost nicht genau genug formuliert war, ich werden Post entsprechend anpassen. Das Adjektiv kompromisslos war wohl etwas unbedacht gewählt, da jeder etwas Anderes dabei verstehen kann.

1) Gewährleistung des Herstellers und Modifikation des Funkmoduls

Ich nutze eine RaspberryMatic die ich als Bausatz bei ELV direkt gekauft habe, von daher sollte das Thema Gewährleistung durch eQ3 keine Rolle spielen da es wahrscheinlich ohnehin keine gibt. Ich habe keinen Bedarf an irgendwelche Änderungen an Funkmodulen auszuführen und will (bis jetzt) auch keine weiteren Technologien über USB o.ä. integrieren. Zum Einsatz kommt schlicht der Bausatz mit SD-Karte und USB-Stick. Als System läuft der aktuelle RaspberryMatic release. Einzige Erweiterung die Installiert ist, ist CUxD. CUxD wir momentan (noch) nicht verwendet, ich sehe aber ein paar Anwendungsmöglichkeiten für mich.

An Hersteller-Firmen wie in diesem Fall eQ3 kann natürlich immer Kritik geübt werden und es gibt gewiss viele Dinge die verbessert werden könnten. Dennoch sehe ich in dem System eines der flexibelsten das im Detail angepasst werden und das ohne Cloud Zugriff betrieben werden kann. Mit der Möglichkeit Bausätze zu Beziehen bzw. mit Platinen ganz eigene Module zu entwerfen erreicht Homematic für mich eine Attraktivität die ich bis dato bei keinem anderen System sehen konnte. Alternative Heim-Automatisierungs-Systeme mit vergleichbarem Umfang könnten in einem alternativen Thread diskutiert werden. Es wäre frustrierend (aber gut!) zu wissen, wenn es bessere Alternativen zu einem vergleichbaren Preis gäbe.

2) Dritt-Systeme

In der Homematic-Community scheint es ein paar Dritt-Systeme zu geben die immer wieder verwendet werden: Mediola, IPSymcon und IOBroker sind die meist genannten. Wenn man unabhängig von Homematic nach Open Source Hausautomatisierungs-Projekten sucht die möglichst viele Technologien abdecken, findet man in erster Linie OpenHAB, IOBroker, FHEM und Home Assistant. Ohne einem solchen Technologie-Hub, egal ob open source oder kostenpflichtig, lassen sich schwer Geräte unterschiedlicher Hersteller zusammenbringen.

Aus diversen Gründen (die ggf. einem Pro/Con Thread zu Dritt-Systemen gesammelt werden könnten) habe ich mich als Frontend für Home Assistant entschieden und wurde davon nicht enttäuscht. Home Assistant ist bei mir aktuell gesetzt und wird auf Sicht nicht ausgetauscht werden.

3) Constraints/Vorbedingungen für meine "Setup-Suche"

Ich möchte mit den Automatisierungen die ausschließlich Homematic-Geräte betreffen nach Möglichkeit innerhalb der RaspberryMatic bleiben. Mit dieser Entscheidung breche ich wahrscheinlich für einige die Bedingung kompromisslos, aber das hat für mich mehrere Vorteile:
  • Wenn ein anderes System (Frontend, MQTT, ...) ausfällt funktioniert die Homematic Logik weiter
  • Ein Austausch des Frontends ist möglich ohne die Automatisierungen portieren zu müssen
  • wenn mir noch mehr einfällt (und ich dran denke) schreibe ich es hier rein
Ich bin primär nicht auf der Suche nach der komfortabelsten Entwicklungsumgebung (Debugger, Syntax highlighting, ...) sondern nach einer Laufzeit-Architektur, die mir erlaubt Code gut zu strukturieren und wieder zu verwenden. Die Optimierung des Entwicklungs-Setups erfolgt dann nachgelagert.

4) Findings bis jetzt

a) Script Sprachen:

TCL ist deprecated, Javascript scheint selbst von eQ3 bevorzugt zu werden (es gibt node auf der RaspberryMatic!). Ansonsten wird gerne PHP eingesetzt, das scheint auf der CCU/R-Matic aber nicht vorhanden zu sein.

b) Eingriffpunkt in das System

Das System, das ich gesucht habe scheint die Logik-Schicht zu sein die in einem Programm "ReGaHss" ausgeführt wird. Diese Logik-Schicht kann über eine XmlRpc Schnittstelle angesprochen werden. Es gibt bindings für alle möglichen Sprachen.

c) Programmatisches Anlegen/Verwalten von Programmen

Ist über XmlRpc Schnittstelle möglich, wie genau muss ich noch herausfinden. Das ist aber kein Thema das hier weiter verfolgt werden muss.

d) Aufruf neue UI?

Das wäre natürlich der Jackpot! Ein Webfrontend das nach diesem Jahrhundert aussehen würde, wäre so ziemlich das Beste was dem System passieren könnte. Leider fehlt mir die notwendige Expertise als UX-Experte und auch FE-Entwicklung ist nicht meine Stärke. Wenn es aber Bestrebungen geben sollte, dem System ein neues node.js Frontend (oder welche Technologie auch immer) zu verpassen würde ich zumindest sofort mit testen.

Fonzo
Beiträge: 6673
Registriert: 22.05.2012, 08:40
System: CCU
Hat sich bedankt: 25 Mal
Danksagung erhalten: 478 Mal

Re: Scripting für Entwickler

Beitrag von Fonzo » 29.08.2020, 01:37

micst hat geschrieben:
28.08.2020, 23:54
Ich bin primär nicht auf der Suche nach der komfortabelsten Entwicklungsumgebung (Debugger, Syntax highlighting, ...) sondern nach einer Laufzeit-Architektur, die mir erlaubt Code gut zu strukturieren und wieder zu verwenden. Die Optimierung des Entwicklungs-Setups erfolgt dann nachgelagert.
Egal wie Du das jetzt formulierst ob bevorzugte Umgebung oder wie ursprünglich kompromisslos, würde ich Dir nach wie vor ans Herz legen eine objekt orientierte Sprache zu nutzen. Nur so wirst Du Deinem Ziel nachkommen den Code gut strukturieren zu können und vor allem durch Klassen und Methoden wiederverwertbar zu machen. Wenn Du Dich jetzt auf Python und Home Assistant festgelegt hast, dann würde ich das an Deiner Stelle dann eben auch nutzten für die Steuerung und Programmierung von Homematic und mir dazu dann noch eine passende IDE aussuchen.
Zu versuchen komplexe Programmierung auf die CCU zu verlegen bringt Dir aus meiner Sicht keinen Vorteil, sondern was die Strukturierung und Wiederverwendung des Codes anbelangt nur Nachteile. Was die Stabilität anbelangt ist dies das entscheidende bei einer Hausautomation.

Entweder Du vertraust also Deiner gesetzten Wahl in Python und Home Assistant auch im Hinblick auf die Stabilität, dann gibt es auch keinen Grund davon auszugehen, das dies instabiler wäre bzw. die CCU mit Code stabiler laufen sollte als wenn der gesamte Code in Python geschrieben wird und in Home Assistant läuft. Falls Du bezüglich der Stabilität von Home Assistant irgendwelche Zweifel haben solltest, weil es das auch noch nicht so lange gibt, wäre eventuell noch eine Alternative Systeme einzusetzen, die ihre Stabilität über die Jahre hinreichend unter Beweis gestellt haben. Das älteste erprobte Hausautomationsystem im deutschen Markt mit über 15 Jahren Erfahrung auch im gewerblichen Objekten ist IP–Symcon, ist aber im Gegensatz zu Home Assistant eben auch eine Firma und kostet daher auch Geld.
micst hat geschrieben:
28.08.2020, 23:54
[*]Ein Austausch des Frontends ist möglich ohne die Automatisierungen portieren zu müssen
Das Frontend kannst Du bei vielen Systemen einfach anpassen bzw. auch unterschiedliche Visualisierungstools nutzen, da Systeme, die für Automatisierung ausgelegt sind, ja Schnittstellen haben. Wenn es um sehr komplexe Automatisierung geht, ist hingegen die Sprache bzw. das System, in dem die Automatisierung programmiert wird, auf lange Sicht festgelegt, da Du Dir selten die Mühe machen wirst, das alles später in eine andere Sprache umzuschreiben. Daher solltest Du, wenn für Dich denn Python gesetzt ist, auch alles in Python schreiben und Dich nicht auf eine proprietäre Sprache auf der CCU beschränken, die Dir viel weniger Möglichkeiten bietet, als eine richtige höhere Programmiersprache wie Python.
micst hat geschrieben:
28.08.2020, 23:54
Ansonsten wird gerne PHP eingesetzt, das scheint auf der CCU/R-Matic aber nicht vorhanden zu sein.
Wenn Du damit sagen willst, das Du selber auch hinreichend Erfahrung hast in PHP, wäre IP–Symcon noch eine Alternative, das nutzt als Sprache selber PHP und ist auch gleichzeitig PHP Server.
micst hat geschrieben:
28.08.2020, 23:54
Diese Logik-Schicht kann über eine XmlRpc Schnittstelle angesprochen werden. Es gibt bindings für alle möglichen Sprachen.
Genau das wäre mein bevorzugter Ansatz. Nutze die definierten Schnittstellen, die der Hersteller zur Verfügung stellt. Das bedeutet dann aber eigentlich auch, das Du eben alles in der Sprache der Wahl, bei Dir wohl Python, programmieren solltest und die CCU nicht anderes ist als ein reiner Befehlsempfänger. Alle komplexen Prozesse werden dann eben in der Sprache ausgeführt, auf die Du Dich festgelegt hast und für die Du Deine IDE hast.

Benutzeravatar
Black
Beiträge: 5460
Registriert: 12.09.2015, 22:31
System: Alternative CCU (auf Basis OCCU)
Wohnort: Wegberg
Hat sich bedankt: 417 Mal
Danksagung erhalten: 1069 Mal
Kontaktdaten:

Re: Scripting für Entwickler

Beitrag von Black » 30.08.2020, 11:42

micst hat geschrieben:
28.08.2020, 23:54
Hallo und ersteinmal herzlichen Dank für die vielen ausführlichen Antworten! Ich denke ich sollte meine Vorstellungen etwas präzisieren um die Diskussion auf den Bereich zu fokussieren den ich für relevant halte. Tut mir leid wenn der Ursprungspost nicht genau genug formuliert war, ich werden Post entsprechend anpassen. Das Adjektiv kompromisslos war wohl etwas unbedacht gewählt, da jeder etwas Anderes dabei verstehen kann.

1) Gewährleistung des Herstellers und Modifikation des Funkmoduls

Ich nutze eine RaspberryMatic die ich als Bausatz bei ELV direkt gekauft habe, von daher sollte das Thema Gewährleistung durch eQ3 keine Rolle spielen da es wahrscheinlich ohnehin keine gibt. Ich habe keinen Bedarf an irgendwelche Änderungen an Funkmodulen auszuführen und will (bis jetzt) auch keine weiteren Technologien über USB o.ä. integrieren. Zum Einsatz kommt schlicht der Bausatz mit SD-Karte und USB-Stick. Als System läuft der aktuelle RaspberryMatic release. Einzige Erweiterung die Installiert ist, ist CUxD. CUxD wir momentan (noch) nicht verwendet, ich sehe aber ein paar Anwendungsmöglichkeiten für mich.
Support interessiert mich persönlich da eh nicht wirklich, um ein "supporttaugliches" System zu haben dürftes du alle Möglichkeiten, die das System bieten nicht nutzen. Von dahr, es wirft halt nur ein etwas schlechtes Licht auf EQ3, wenn von den Leuten, die wissen was sie sagen und es zeigen und nachweisen können, das allgemeingütog eine Motte an der und der Stelle sitzt, dann dort versucht wird mit Gags wie: die setzen Zusatzsoftwar eoder Scripte ein bzw: leider können wir ihr problem nicht nachstellen, installieren sie bitte den ganzen scheiss neu

An Hersteller-Firmen wie in diesem Fall eQ3 kann natürlich immer Kritik geübt werden und es gibt gewiss viele Dinge die verbessert werden könnten. Dennoch sehe ich in dem System eines der flexibelsten das im Detail angepasst werden und das ohne Cloud Zugriff betrieben werden kann. Mit der Möglichkeit Bausätze zu Beziehen bzw. mit Platinen ganz eigene Module zu entwerfen erreicht Homematic für mich eine Attraktivität die ich bis dato bei keinem anderen System sehen konnte. Alternative Heim-Automatisierungs-Systeme mit vergleichbarem Umfang könnten in einem alternativen Thread diskutiert werden. Es wäre frustrierend (aber gut!) zu wissen, wenn es bessere Alternativen zu einem vergleichbaren Preis gäbe.
cloud ist ein absolutes NOGO für mich, egal was irgendwelche marketing abeilungen erzahlen. Die Stäre des Systemes sind: die DV und die sehr weiten Möglichkeiten der programmierung (wenn man den support support sein lässt)

2) Dritt-Systeme

In der Homematic-Community scheint es ein paar Dritt-Systeme zu geben die immer wieder verwendet werden: Mediola, IPSymcon und IOBroker sind die meist genannten. Wenn man unabhängig von Homematic nach Open Source Hausautomatisierungs-Projekten sucht die möglichst viele Technologien abdecken, findet man in erster Linie OpenHAB, IOBroker, FHEM und Home Assistant. Ohne einem solchen Technologie-Hub, egal ob open source oder kostenpflichtig, lassen sich schwer Geräte unterschiedlicher Hersteller zusammenbringen.

stimmt. wobei die meisten dieser Middlewares auch noch Datenbankanbindungen, komplettes Backup management, IOT anbindung (webhooks bzw Alexa und co) und eine allgemine Hochsprache (bzw aktuelle Scriptsprache) mit bringen

Aus diversen Gründen (die ggf. einem Pro/Con Thread zu Dritt-Systemen gesammelt werden könnten) habe ich mich als Frontend für Home Assistant entschieden und wurde davon nicht enttäuscht. Home Assistant ist bei mir aktuell gesetzt und wird auf Sicht nicht ausgetauscht werden.
wennsbe dir läuft, alles perfekt


3) Constraints/Vorbedingungen für meine "Setup-Suche"

Ich möchte mit den Automatisierungen die ausschließlich Homematic-Geräte betreffen nach Möglichkeit innerhalb der RaspberryMatic bleiben. Mit dieser Entscheidung breche ich wahrscheinlich für einige die Bedingung kompromisslos, aber das hat für mich mehrere Vorteile:
  • Wenn ein anderes System (Frontend, MQTT, ...) ausfällt funktioniert die Homematic Logik weiter
  • Ein Austausch des Frontends ist möglich ohne die Automatisierungen portieren zu müssen
  • wenn mir noch mehr einfällt (und ich dran denke) schreibe ich es hier rein
passt, ich bin auch ein Freund von Rückfallebenen

Ich bin primär nicht auf der Suche nach der komfortabelsten Entwicklungsumgebung (Debugger, Syntax highlighting, ...) sondern nach einer Laufzeit-Architektur, die mir erlaubt Code gut zu strukturieren und wieder zu verwenden. Die Optimierung des Entwicklungs-Setups erfolgt dann nachgelagert.

4) Findings bis jetzt

a) Script Sprachen:

TCL ist deprecated, Javascript scheint selbst von eQ3 bevorzugt zu werden (es gibt node auf der RaspberryMatic!). Ansonsten wird gerne PHP eingesetzt, das scheint auf der CCU/R-Matic aber nicht vorhanden zu sein.

b) Eingriffpunkt in das System

Das System, das ich gesucht habe scheint die Logik-Schicht zu sein die in einem Programm "ReGaHss" ausgeführt wird. Diese Logik-Schicht kann über eine XmlRpc Schnittstelle angesprochen werden. Es gibt bindings für alle möglichen Sprachen.
Yup, diese Remote Api läuft mit der Scriptsprache der CCU. von daher ist es nicht schlecht, sich in die Objectstructur und den Befehlssatz von HMScript einzuarbeiten

c) Programmatisches Anlegen/Verwalten von Programmen

Ist über XmlRpc Schnittstelle möglich, wie genau muss ich noch herausfinden. Das ist aber kein Thema das hier weiter verfolgt werden muss.
die Remote-Api der Rega... machbar ist es, das Backup Restore des SDV benutzt auch diese Schnittstelle für diese Funktion

d) Aufruf neue UI?

Das wäre natürlich der Jackpot! Ein Webfrontend das nach diesem Jahrhundert aussehen würde, wäre so ziemlich das Beste was dem System passieren könnte. Leider fehlt mir die notwendige Expertise als UX-Experte und auch FE-Entwicklung ist nicht meine Stärke. Wenn es aber Bestrebungen geben sollte, dem System ein neues node.js Frontend (oder welche Technologie auch immer) zu verpassen würde ich zumindest sofort mit testen.
Wenn das Fernsehprogramm immer mehr durch nervende Werbung unterbrochen wird und der Radiomoderator nur noch Müll erzählt, ist es besser, die Zeit für sinnvolle Dinge zu nutzen -
mal aufs Klo zu gehen, ein Bier zu holen oder einfach mal den roten AUS-Knopf zu drücken. Klick - und weg

Script Time Scheduler V1.3
AstroSteuerung über Zeitmodul flexibel mit Offset / spätestens, frühestens
SDV 5.03.01 Das umfassende Entwicklungs und Diagnosetool für Homematik
Selektive Backups - Nützliche Dinge, die die WebUI nicht kann

Intel NUC6 Celeron 16GB mit 512GB SSD unter Proxxmox mit insgesamt 5 VM: 2 x bloatwarebefreiter Raspberrymatik, 2 x IOBroker als Middleware und einer MariaDB zur Archivierung. Verbrauch: 6W

technical contribution against annoying advertising

Fonzo
Beiträge: 6673
Registriert: 22.05.2012, 08:40
System: CCU
Hat sich bedankt: 25 Mal
Danksagung erhalten: 478 Mal

Re: Scripting für Entwickler

Beitrag von Fonzo » 30.08.2020, 13:38

Black hat geschrieben:
30.08.2020, 11:42
micst hat geschrieben:
28.08.2020, 23:54
3) Constraints/Vorbedingungen für meine "Setup-Suche"

Ich möchte mit den Automatisierungen die ausschließlich Homematic-Geräte betreffen nach Möglichkeit innerhalb der RaspberryMatic bleiben. Mit dieser Entscheidung breche ich wahrscheinlich für einige die Bedingung kompromisslos, aber das hat für mich mehrere Vorteile:
  • Wenn ein anderes System (Frontend, MQTT, ...) ausfällt funktioniert die Homematic Logik weiter
    [...]
passt, ich bin auch ein Freund von Rückfallebenen
Das ist aus meiner persönlichen Sicht keinesfalls eine Rückfallebene, sondern höchstens eine Risikoebene. Die beste Rückfallebene einer CCU sind die Direktverknüpfungen, die funktionieren immer, auch wenn die CCU mal aussteigt. Ein Kette ist nur so stabil wie ihr schwächstes Glied.
Die CCU mit dem was Homematic Skript für komplexe Programmierung zur Verfügung stellt, ist definitiv das schwächste Glied, wen man so oder so höhere Programmiersprachen nutzt. Sowohl in der von ihm bevorzugten Sprache Python hat er richtigtes Exception Handling und ich selber habe bei mir mit der genutzten Sprache PHP auch Ausnahmebehandlung zur Verfügung. Nur so und mit der Möglichkeit in der IDE komplexen Code auch zu debuggen bzw. klar zu strukturieren und wiederzuverwerten, bekommt man am Schluss auch komplexen Code der stabil läuft.
Bei einem Vergleich von Sprachen wie Python, PHP usw. mit dem was auf der CCU mit der proprietären Sprache des Herstellers e-Q3 möglich ist, muss ich persönlich zumindest nicht lange überlegen, mit welcher Sprache es möglich ist bei komplexen Dingen sauber strukturieren Code zu erzeugen, der wiederverwertbar ist, Fehler sauber abfängt, und zuverlässig stabil läuft. Zu einer stabilen Umgebung bzw. komplexen Abläufen gehört auch die lückenlose und saubere Dokumentation der Möglichkeiten und Funktionen der Sprache, die man bei der Programmierung nutzten kann. Hier ist ein riesiger Unterschied zwischen der Programmierung in Python, PHP usw. bei der ich auf umfangfreiche Dokumentation zurückgreifen kann und zahlreiche Beispiele und Quellen für die Sprache und Lösung von Problemen finden werde. Bei der proprietären Sprache des Herstellers e-Q3 kannst Du eine ausführliche öffentlich einsehbare Dokumentation, die in allen Einzelheiten alle Möglichenkeiten beschreibt suchen, das ist weitestgehend eine Blackbox.
Zu guter letzt wird es auch schwierig ein ordentliche IDE zu finden, während man für Sprachen wie Python, PHP usw. ja so IDEs nutzten kann wie von Microsoft Visual Studio Code oder im Fall von PHP z.B. PHPStorm usw. wirst Du keinem großen Hersteller bzw. weit verbreiteten IDEs eine richtige Möglichkeit finden mit Homematic Skript zu arbeiten. Mit einer richtigen umfangreichen IDE sind aber auch seine selber aufgestelleten Kriterien
micst hat geschrieben:
28.08.2020, 23:54
die mir erlaubt Code gut zu strukturieren und wieder zu verwenden.
abdeckt, wie vollständige Git Integration oder Auto Deployment, die automatische Lokalisierung von Duplikaten, das reformartieren und Rearrangments des Codes durch die IDE bzw. das Verwalten der Version Control in der IDE.
micst hat geschrieben:
26.08.2020, 23:48
Meine Hauptschmerzen sind:
  • Zuviel klicken bei der Programmierung (insbesondere wenn viele Einträge in Bedingungen notwendig sind)
  • Keine Versionierungsmöglichkeit (nogo, ich will ein git repo für meine Logik-Implementierung!)
  • Keine bzw. schlechte Wiederverwendbarkeit von Skripten/Programmen in anderen Skripten/Programmen
  • Keine Funktionen mit Parametern/Rückgabewerten
  • die beiden letzten Punkte bedeuten: viel Code Duplizierung, dadurch schlechte Wartbarkeit
Welcher dieser einzelnen "Hauptschmerzen" wird denn dadurch gelöst, dass man sich irgendwie auf das schreiben von komplexen Abläufen auf die CCU einschränkt bzw. fokussiert? Aus meiner Sicht keine einziges Kriterium. Man hat weder Klassen noch Vererbung zur Verfügung, vollständige Git Implemtieruung ist ein Fremdwort, die Wartbarkeit wegen fehlenden Traits oder Klassen nicht gegeben. Parameter und Rückgabe Werte bestimme ich durch eigene Klassen und Methoden, die es ja auf der CCU selber nicht gibt. Und Wiederverwertbarkeit ist wegen fehlenden Klassen und Vererbung auch keine gegeben.

Sobald man jedoch eine höhere Sprache benutzt, wie jetzt in seinem favorisierten Fall Python, oder bei mir PHP kann man alle "Hauptschmerzen" ersatzlos streichen, diese sind dann nämlich mit Nutzung einer höheren Sprache mit einem Schlag alle gelöst.
Daher ist doch die Frage, was ist denn jetzt eigentlich der Fokus von dem Post, die Sorgen die man offensichtlich hat zu lösen, dann sollte man auch eine höhere Sprache nutzten und nicht auf der CCU selber rumarbeiten, dann sind nämlich alle "Probleme" bzw. "Hauptschmerzen" augenblicklich gelöst.

Matsch
Beiträge: 5345
Registriert: 30.05.2019, 11:37
System: Alternative CCU (auf Basis OCCU)
Wohnort: Chemnitz
Hat sich bedankt: 113 Mal
Danksagung erhalten: 722 Mal

Re: Scripting für Entwickler

Beitrag von Matsch » 30.08.2020, 14:00

Fonzo hat geschrieben:
27.08.2020, 19:09
ELV bewirbt auch kein CUxD, wenn ELV etwas mit der CCU3 bewirbt, dann ist das der NEO Server bzw. NEO Automation Manager mit der CCU3...
Ich glaube, das kann man so nicht stehen lassen. ELV hat in seinem Magazin von 2014 - 2017 mehrere Beiträge veröffentlicht zur Nutzung von CUxD ("CUxD – das Leatherman für die Homematic®-CCU"), die auch heute noch downloadbar sind. Da wurde kein Wort darüber verloren, dass das zu Gewährleistungsproblemen der von ELV selbst vertriebenen Geräte führt. Umso verwunderlicher, zumal ELV und eQ-3 ja historisch betrachtet mal einunddiesselbe Firma waren - 2007 ausgegründet und noch immer Schwesterunternehmen.
Die eine will's loswerden, die andere nicht dafür grade stehen.

https://de.elv.com/cuxd-das-leatherman- ... 9492&c=989
https://de.elv.com/cuxd-das-leatherman- ... 9492&c=989
https://de.elv.com/cuxd-das-leatherman- ... 9492&c=989
https://de.elv.com/cuxd-das-leatherman- ... 9492&c=989
https://de.elv.com/homematic-scriptprog ... 9492&c=989

Fonzo
Beiträge: 6673
Registriert: 22.05.2012, 08:40
System: CCU
Hat sich bedankt: 25 Mal
Danksagung erhalten: 478 Mal

Re: Scripting für Entwickler

Beitrag von Fonzo » 30.08.2020, 14:16

Matsch hat geschrieben:
30.08.2020, 14:00
Da wurde kein Wort darüber verloren, dass das zu Gewährleistungsproblemen der von ELV selbst vertriebenen Geräte führt.
Das ist wohl ein Problem das es zwei Unternehmen sind. Aber ELV zieht sich bei den veröffentlichten Artikeln ja gleich raus und schiebt jegliche Verantwortung dann gleich wieder zurück und schreibt das diese kein Support leisten
ELV hat geschrieben: .. der Komplexität kann ELV zu dieser Zusatzsoftware leider keinerlei Support übernehmen. Bei allen Fragen zu CUxD steht Ihnen allerdings das HomeMatic-Forum [3] zur Verfügung, welches durch viele erfahrene User und auch den Entwickler selbst betreut wird und somit als Support-Plattform dient.
Und eQ-3 ist wie gesagt ein anderes Unternehmen und die können gar nicht anders als die Gewährleistung zu verweigern in dem Moment in dem man selbstständig die Funkeigenschaften des Gateways verändert bzw. die Konformitätserklärung des Geräts aushebelt, das schreibt wiederum der Hersteller aber auch ganz dick in die Anleitung, das kann man schlecht überlesen.
eQ-3 hat geschrieben: Aus Sicherheits- und Zulassungsgründen (CE) ist das eigenmächtige Umbauen und/oder Verändern des Geräts nicht gestattet.

MichaelN
Beiträge: 9534
Registriert: 27.04.2020, 10:34
System: CCU
Hat sich bedankt: 692 Mal
Danksagung erhalten: 1604 Mal

Re: Scripting für Entwickler

Beitrag von MichaelN » 30.08.2020, 14:18

Du kannst das noch so oft wiederholen, aber
eQ-3 hat geschrieben: Aus Sicherheits- und Zulassungsgründen (CE) ist das eigenmächtige Umbauen und/oder Verändern des Geräts nicht gestattet.
Wenn EQ3 ein Gerät mit Addon-Schnittstelle bietet, dann wird die Nutzung dieser ja wohl kaum eine unerlaubte Nutzung sein.
LG, Michael.

Wenn du eine App zur Bedienung brauchst, dann hast du kein Smarthome.

Wettervorhersage über AccuWeather oder OpenWeatherMap+++ Rollladensteuerung 2.0 +++ JSON-API-Ausgaben auswerten +++ undokumentierte Skript-Befehle und Debugging-Tipps +++

Benutzeravatar
Black
Beiträge: 5460
Registriert: 12.09.2015, 22:31
System: Alternative CCU (auf Basis OCCU)
Wohnort: Wegberg
Hat sich bedankt: 417 Mal
Danksagung erhalten: 1069 Mal
Kontaktdaten:

Re: Scripting für Entwickler

Beitrag von Black » 30.08.2020, 14:24

@Match
Support von EQ3 kannst du er vergessen... Du hast eine höhere chance, das system stabil am laufen zu halten, wenn du auch die Tiefen des Systemes kennst, als wenn man sich auf den Support verlässt.
Also von daher ist alles andere: Marketinggeschwätz

wie gut das von EQ3 offiziell "empfholene" oder besser gesagt zwangsweise untergeschobene System ist, zeigt, das es "DeBloater" braucht, um das Zeug wieder loszuwerden, damit es einem die Backups nicht unnötig zumüllt.

Black

der im übrigen mit der objektorienten Scriptsprache der CCU doch recht gut umgehen kann ^^
Wenn das Fernsehprogramm immer mehr durch nervende Werbung unterbrochen wird und der Radiomoderator nur noch Müll erzählt, ist es besser, die Zeit für sinnvolle Dinge zu nutzen -
mal aufs Klo zu gehen, ein Bier zu holen oder einfach mal den roten AUS-Knopf zu drücken. Klick - und weg

Script Time Scheduler V1.3
AstroSteuerung über Zeitmodul flexibel mit Offset / spätestens, frühestens
SDV 5.03.01 Das umfassende Entwicklungs und Diagnosetool für Homematik
Selektive Backups - Nützliche Dinge, die die WebUI nicht kann

Intel NUC6 Celeron 16GB mit 512GB SSD unter Proxxmox mit insgesamt 5 VM: 2 x bloatwarebefreiter Raspberrymatik, 2 x IOBroker als Middleware und einer MariaDB zur Archivierung. Verbrauch: 6W

technical contribution against annoying advertising

Antworten

Zurück zu „Softwareentwicklung für die HomeMatic CCU“