Scripting für Entwickler

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

Moderator: Co-Administratoren

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

Scripting für Entwickler

Beitrag von micst » 26.08.2020, 23:48

Hallo liebe Homematic-Experten,

ich bin auf der Suche nach dem kompromisslos besten Weg (für Softwareentwickler) meine Homematic zu Programmieren einem Weg meine Automatisierungen innerhalb der RaspberryMatic so zu implementieren, dass es sich für einen Softwareentwickler besser anfühlt. Die WebUI ist hervorragend geeignet für Einsteiger und Leute die in der Softwareentwicklung, der Konsole und Linux nicht zuhause sind. Für alle anderen ist sie suboptimal.

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
Was sich bei mir bis jetzt heraus destiliert hat:
  • Programme immer als Skript schreiben, ist am flexibelsten
    • am besten direkt TCL Skripte entwickeln, bieten beste Flexibilität ohne Funktionsverlust ggü. in UI geschriebenen Skripten
    • Skripte in /usr/local/ ablegen, das wird im Backup mit gespeichert
    • Skripte in separatem git repository versionieren (kann auch leicht mit community geteilt werden)
    • Synchronisierung zwischen Entwickler-Maschine und RaspberryMatic einrichten (i.e. komfortabel auf Laptop entwickeln, automatisch auf Zielsystem kopieren zum testen)
  • mit WinSCP/Putty direkt auf dem Gerät arbeiten
    • candy: in /etc/ssh/sshd_config pubkey authentication aktivieren, macht mehr Spaß beim Arbeiten
  • TCL lernen
  • RaspberryMatic selber bauen
  • SDV Editor von Black nutzen! Das Ding sieht aus wie ein Röntgengerät für Homematic: man sieht alles was da drinnen steckt und kommt an alle IDs und was man sich so wünschen kann ran.
Constraints/Vorbedingungen für meine "Setup-Suche":

Ich möchte ausschließlich auf der RaspberryMatic bleiben und keine weiteren Dritt-Systeme dafür integrieren. Gewährleistungen seitens des Herstellers können vernachlässigt werden, da ohnehin ein Bausatz verwendet wird.

Meine aktuellen Fragen:
  • Habe ich bei TCL tatsächlich den vollen Funktionsumfang den Homematic Script mir bietet? Ich vermute es, konnte es aber noch nicht feststellen.
  • 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.
  • Kann man direkt im System neue Programme anlegen ohne über die UI gehen zu müssen? Insbesondere das gescriptete anlegen der WENN/Trigger Abschnitte wäre Gold wert.
Gibt es hier noch weitere Homematic Anwender die mit ähnlichen Vorstellungen an ihre Automatisierung heran gehen und etwas über ihr Development Environment erzählen können/wollen (z.B. Editor/IDE/Versionierung/Debugging/...)? Ich wäre sehr gespannt zu hören wie sich erfahrenere Benutzer das Leben möglichst leicht machen.

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.
Zuletzt geändert von micst am 29.08.2020, 00:13, insgesamt 1-mal geändert.

jp112sdl
Beiträge: 12072
Registriert: 20.11.2016, 20:01
Hat sich bedankt: 846 Mal
Danksagung erhalten: 2138 Mal
Kontaktdaten:

Re: Scripting für Entwickler

Beitrag von jp112sdl » 27.08.2020, 07:03

micst hat geschrieben:
26.08.2020, 23:48
Ich wäre sehr gespannt zu hören wie sich erfahrenere Benutzer das Leben möglichst leicht machen.
Bei mir gibt es da nur eine Strategie: Nicht alles muss bis ins letzte Detail durch-automatisiert sein. Es darf auch Szenarien geben, wo man tatsächlich händisch einen Taster bedienen muss.

Programme sind klein und übersichtlich gehalten, so dass auf den ersten Blick erkenntlich ist, was da passiert.

Ansonsten passiert nicht viel... Ich hab damals alles eingerichtet und bis auf ein bisschen Feintuning hat sich an der gesamten Programmierung über die Jahre nichts verändert.

Wenn ich deinen Beitrag so lese, hört es sich für mich so an, als hättest du "Großes" mit Homematic vor...
Hoffentlich werden deine Erwartungen auch erfüllt.

Das letzte Firmware-Update 3.53.26 war ja wieder mal ein Griff ins Klo.
Getestet wird bei eQ-3 scheinbar nix, nicht mal die Stellen, an denen sie was geändert haben.
Und so erlebt man bei jedem Release neue Überraschungen ^^

VG,
Jérôme ☕️

---
Support for my Homebrew-Devices: Download JP-HB-Devices Addon

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, 08:51

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.
Zuletzt geändert von Fonzo am 27.08.2020, 10:55, insgesamt 1-mal geändert.

jp112sdl
Beiträge: 12072
Registriert: 20.11.2016, 20:01
Hat sich bedankt: 846 Mal
Danksagung erhalten: 2138 Mal
Kontaktdaten:

Re: Scripting für Entwickler

Beitrag von jp112sdl » 27.08.2020, 09:11

Fonzo hat geschrieben:
27.08.2020, 08:51
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.
Um den Anspruch auf Support zu verwirken, reicht es, auf der originalen Firmware
- das von ELV selbst beworbene CUxD Addon zu installieren
- Skripte in Programmen zu verwenden
- Expertenparameter in DV zu nutzen

VG,
Jérôme ☕️

---
Support for my Homebrew-Devices: Download JP-HB-Devices Addon

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, 11:20

micst hat geschrieben:
26.08.2020, 23:48
und etwas über ihr Development Environment erzählen können/wollen (z.B. Editor/IDE/Versionierung/Debugging/...)?
Also ich nutzte als IDE PHPStrom mit IP-Symcon Plugin für PHP Strom, Versionierung erfolgt auf Gitlab, bzw. Github. Automatisches Testen von Klassen durch Github und SymconStubs. Style Check durch Github bzw. StyleCI. Gibt aber auch eine Extension für Visual Studio Code für IP-Symcon.

Wenn ich Homematic erweitert auf einer CCU ansprechen will, nutzte ich IP-Symcon und Homematic Extended. An Skripten läuft bei mir kein einziges Skript auf der CCU selber, das sind alles Dinge, die in PHPStorm geschrieben werden, benutzte Sprache ist zur Zeit PHP 7.3.x (x64 Thread Safe). Zum Ansprechen des NEO Servers auf der CCU3 nutzte ich Mediola Gateway Services.

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, 11:33

jp112sdl hat geschrieben:
27.08.2020, 09:11
Um den Anspruch auf Support zu verwirken, reicht es, ...
...ein System zu betreiben, das nicht 100% dem Testsystem von EQ3 entspricht :twisted:

Ich war anfangs auch entsetzt wie 80er die CCU ist. Aber man gewöhnt sich dran. Kommen Erinnerungen an den C64 auf...
Es gibt ja einen Aufruf von Jens eine neue WebUI für die RM zu programmieren - vielleicht wäre das etwas, wo Du Dich dran austoben möchtest?
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 » 27.08.2020, 12:33

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.
    Es ist nicht schlecht, TCL zu können, viel internes auf der CCU ist in TCL geschrieben. Aber komplette logiken in TCL... kann man machen, muss man nicht. Ich halte da nix von
  • 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.
    Du kannst dich direkt an den schnittstellenprozessen der verschiedenen Interfaces einhängen, wenn du so tief runterwillst. Die meisten Hochsprachen wie C oder Delphi/Pascal haben componenbibliotheken für einen XMLPRC client. Damit kannst du dann komplett von einer Hochsprache direkt dien geräte steuern ohne Umwege über die Logikschicht
  • Kann man direkt im System neue Programme anlegen ohne über die UI gehen zu müssen? Insbesondere das gescriptete anlegen der WENN/Trigger Abschnitte wäre Gold wert.
    ja, kann man. Man kann mit der remote API so ziemlich alles zaubern, alles was der SDV macht macht der auch über die Remote-API der rega (von ein paar Ausnahmen abgesehen). ebenso kannst du natürlich auch über regascript selber auch webui programme anlegen.
Gibt es hier noch weitere Homematic Anwender die mit ähnlichen Vorstellungen an ihre Automatisierung heran gehen und etwas über ihr Development Environment erzählen können/wollen (z.B. Editor/IDE/Versionierung/Debugging/...)? Ich wäre sehr gespannt zu hören wie sich erfahrenere Benutzer das Leben möglichst leicht machen.
ist bei mir aufgeteilt.. alles was mit Homematik geräten alleine arbeitet ist auch auf der CCU programmiert. Script export und ablage gehen mit dem SDV, ebenso das getrennte Sichern von Programmen bzw auch kompletten Geräten mit ihren Einstellungen. Debugging geht auch, man kann auch Geräten zum testen Werte aufzingen, auf die dann die rega reagiert. Logiken, die die HM Welt verlassen bzw übergreifend sind, laufen bei mir auf IOBroker, der virtualisiert bei mir auf einem kleinen NUC läuft. Ich benutze da nativ Javascript, wenns richtig hart wird geht da auch debugging mit Webstorm. als Alternativ allerdings auch Programmierung mit grafischen Blöcken via Blockly. Iobroker hat den grossen Vorteil, als openSource Projekt kostenlos zu sein, die meisten Fremdgewerke unter einer grossen Haube vereinen zu können, eine Datenbank anbindung mitzubringen sowie als Nebeneffekt auch noch eine Grosse (Vis) und mindestens noch eine kleinere (IQControl) Visualisierungen mitzubringen
Black
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 » 27.08.2020, 19:09

jp112sdl hat geschrieben:
27.08.2020, 09:11
Um den Anspruch auf Support zu verwirken, reicht es, auf der originalen Firmware
- das von ELV selbst beworbene CUxD Addon zu installieren
Die Diskussion um ELV und eQ3 gab es doch schon mal an anderer Stelle im Forum. eQ3 ist der Hersteller und ELV ist ein Verlagshaus und Elektronikversandhaus. 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, durch diesen wird die CCU selber aber auch nicht in ihrer Funktion als Funkgateway bzw. die Funkeigenschaften verändert bzw. das Einhalten der Funkrichtline bzw. Konformitätserklärung der CCU3 beeinflusst. CuxD ist aber vom Kern ausdrücklich ein Lösung um die CCU so zu modifizieren, damit weitere Funkkomponten genutzt werden können, damit kann der Hersteller eQ3 aber auch gar keine Freigabe erteilen bzw. Herstellergewährleistung leisten, weil eben die Funkeigenschaften des Gateways durch Modifikation abweichen und damit auch die Konformitätserklärung der CCU3 keine Gültigkeit mehr besitzt.
Und ELV als Verlagshaus kann ja schreiben was es will, damit diese halt Auflage haben und irgendwas veröffentlichen können, ELV windet sich ja aber selber in dem Artikel zu CuxD fein raus, indem diese selber schreiben
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.
Da schiebt ELV dann also die Verantwortung bzw. den Support dann auch gleich wieder zurück zu dem Homematic Forum bzw. dem Entwickler. Und für eQ-3 eine Konformitätserklärung abgeben, kann ELV erst recht nicht, eQ-3 als Hersteller der CCU3 ist schließlich eine andere Firma.
jp112sdl hat geschrieben:
27.08.2020, 09:11
Um den Anspruch auf Support zu verwirken, reicht es, auf der originalen Firmware
[...]
- Skripte in Programmen zu verwenden
Und genau deshalb ist es aus meiner persönlichen Sicht fragwürdig darüber nachzudenken auf der CCU selber komplexe Skripte abarbeiten zu wollen, zumindest wenn man die Hersteller Gewährleistung behalten will. Da der Hersteller mit Homematic Skript aber so oder so keine richtige Sprache mit Vererbung und Klassen zur Verfügung stellt, ist eine CCU alleine für einen Softwareentwickler nach der Suche der kompromisslosen IDE meiner persönlichen Meinung nach auch die falsche Plattform. Von einer richtigen IDE erwartet man ja auch so was wie Debugging, optimale Codevervollständigung, Refaktorierungen, Fehlerbehebung im Code mit Code Inspektion und vollständige Unterstützung für Github, dazu wird man aber immer eine externe IDE nutzten müssen, die eben auf so was auch ausgelegt ist.

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, 19:53

Fonzo hat geschrieben:
27.08.2020, 19:09

Und genau deshalb ist es aus meiner persönlichen Sicht fragwürdig darüber nachzudenken auf der CCU selber komplexe Skripte abarbeiten zu wollen, zumindest wenn man die Hersteller Gewährleistung behalten will.
Der Hersteller lehnt ja auch die Gewährleistung ab, wenn Du mit Drittsystemen auf die CCU zugreifst. Am besten lässt man sie originalverpackt im Regal stehen und nutzt sie gar nicht. Das ist wahrscheinlich gewährleistungskompatibel.

EQ3 verschenkt unglaubliches Potential. Ein Smarthome-System lebt ja gerade von Interaktion, Flexibilität, Programmierbarkeit, Austauschbarkeit, eine rege Community. Das alles wird von EQ3 abgelehnt. Daher kann man engagierten Entwicklern eigentlich nur von HM abraten. Wenn das System nicht trotz - und nicht wegen - dem Herstellersupport Interaktion, Flexibilität, Programmierbarkeit, Austauschbarkeit, eine rege Community bieten würde.
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, 20:55

MichaelN hat geschrieben:
27.08.2020, 19:53
Der Hersteller lehnt ja auch die Gewährleistung ab, wenn Du mit Drittsystemen auf die CCU zugreifst.
Keine Ahnung ob das zutrifft, im Fall das man die CCU selber einschicken soll oder ein Backup der CCU, kann der Hersteller zumindest gar nicht nachvollziehen ob man externen Systemen auf die CCU zugreift oder nicht, so lange an der CCU selber keine Modifikationen vorgenommen worden sind.
MichaelN hat geschrieben:
27.08.2020, 19:53
Am besten lässt man sie originalverpackt im Regal stehen und nutzt sie gar nicht. Das ist wahrscheinlich gewährleistungskompatibel.
Du sollst die nicht im Regal stehen lassen, sondern eben so wie in der Gebrachsanweisung beschrieben einsetzten als Funkgateway für Homematic / Homematic IP und Verbindung zu Homeatic IP Wired.
eQ-3 hat geschrieben: Jeder andere Einsatz, als der in dieser Bedienungsanleitung beschriebene, ist nicht bestimmungsgemäß und führt zu Gewährleistungs- und Haftungsausschluss.
Irgendwelche zusätzlichen Funk USB Sticks an der CCU anzubringen und zu nutzten, steht definitiv nicht in der Gebrauchsanleitung der CCU3.

MichaelN hat geschrieben:
27.08.2020, 19:53
EQ3 verschenkt unglaubliches Potential.
Mag ja sein, aber dennoch ist eQ-3 ja an sich erfolgreich mit dem System, und es wird auch von anderen SmartHome Anbietern als Funksystem genutzt.
MichaelN hat geschrieben:
27.08.2020, 19:53
Ein Smarthome-System lebt ja gerade von Interaktion, Flexibilität, Programmierbarkeit, Austauschbarkeit, eine rege Community.
Dem stimme ich ja zu, die Flexibilität endet halt meist da beim Hersteller wenn man Dinge am Gerät modizifiert, die so nicht vom Hersteller vorgesehen sind und dann auch keinen Richtlinen, die der Hersteller einhalten muss, berücksichtigt werden.

Du kannst ja auch an Deinem Auto oder Motorrad Dinge austauschen und verbessern. Der Hersteller übernimmt da auch keine Gewährleistung. Nachdem Du was modifiziert hast, must Du bevor Du mit dem Fahrzeug in den Straßenverkehr darft, auch erst die Änderungen beim TÜV abnehmen lassen und in den Fahrzeugschein eintragen lassen. Du kannst Du auch nicht machen, aber dann hast Du defintiv und spätestens dann ein Problem, wenn Dich die Polizei mit solch einem modifizierten Fahrzeug anhält und Du keine Eintragung im Fahrzeuugschein hast.

Und wenn Du bei einem Funkgateway rumbastelst was den Funk betrifft ist das eben auch eine Modifikation, bei der man Funkrichtlinien zu beachten hat. Der Hersteller muss dafür zumindest gerade stehen wenn er so ein Gerät in den Handel bringt und nachweisen das es geltenden Vorgaben entspricht.
MichaelN hat geschrieben:
27.08.2020, 19:53
Das alles wird von EQ3 abgelehnt.
Alles ist vielleicht etwas sehr pauschal, aber definitiv alles was mit einer Modifikation der Firmware oder der Funkeigenschaften der CCU3 einhergeht.
MichaelN hat geschrieben:
27.08.2020, 19:53
Daher kann man engagierten Entwicklern eigentlich nur von HM abraten.
Ich seher da eigentlich kein Problem darin, es gibt unzählige Apps oder auch kommerzielle Systeme, die über definierte Schnittstellen auf die CCU zugreifen ohne das Du damit ein Problem mit der CCU3 selber oder dem Support durch den Hersteller bekommst. Um über die vorhandenen Schnittstellen lässt sich an sich viel nutzten, mehr als bei manch anderem System was eher geschlossen ist. Nur auf der CCU selber hast Du Grenzen was Du dort ändert kannst oder im Sinne des Herstellers ändern solltest wenn Du denn die Gewährleistung erhalten willst.
MichaelN hat geschrieben:
27.08.2020, 19:53
Wenn das System nicht trotz - und nicht wegen - dem Herstellersupport Interaktion, Flexibilität, Programmierbarkeit, Austauschbarkeit, eine rege Community bieten würde.
Ich denke da überschätzt Du die Masse der Leute die wirklich solche Dinge modifizieren. Die Mehrheit der Kunden kauft das System wie beworben und setzt das auch so ein. Es ist ja schön wenn man Dinge modifizieren kann, dann must Du dafür als Kunde aber auch gerade stehen.

Und so User wie hier der Threadowner, die den Anspruch haben sehr komplexe Sachen zu programmieren und für Softwareentwickler eine passende Umgebung zu finden, bilden unter den gesamten Nutzern auch eher die absolte Minderheit bzw. Ausnahme. Möglich ist es aber und da sind einem im Rahmen dessen was die Datenpunkte der Geräte vorgeben auch wenig Grenzen gesetzt.

Antworten

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