Scripting für Entwickler

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

Moderator: Co-Administratoren

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, 15:02

MichaelN hat geschrieben:
30.08.2020, 14:18
Wenn EQ3 ein Gerät mit Addon-Schnittstelle bietet, dann wird die Nutzung dieser ja wohl kaum eine unerlaubte Nutzung sein.
Das musst Du letztlich e-Q3 selber fragen was erlaubt ist und was nicht. Das Nutzten von Programmen bzw. der Schnittstelle wohl nicht in jedem Fall, das Verändern der Funkeigenschaften der CCU ganz sicher. Und wenn Du über Abschnitte der Gebrauchsanleitung darüber liest oder diese einfach ignorierst, ist das ja für Dich in Ordnung, dann musst Du Dich aber nicht beim Hersteller beschweren, dass das unerlaubt ist und dieser dann jeglichen Support bzw. Gewährleistung verwehrt. Es ist ja aber auch müßig darüber zu diskutieren, jeder der so was macht weis eigentlich auf was er sich da einlässt und muss dann eben für seine Entscheidung auch einstehen, bzw. man verzichtet halt bewust auf Gewährleistung und Support durch den Hersteller.

Der Hersteller hat absichtlich WLAN und Bluethooth per Firmware abgestellt um die EG Konformitätserklärung einzuhalten.
Wenn Du entweder Funk, der vom Hersteller absichtlich deaktiviert wurde, wieder aktivierst oder zusätzlichen Funk am Gerät ergänzt, entspricht das Gerät eben auch nicht mehr den Testkriterien, die der Hersteller geprüft hat und für die er verantwortlich ist und auch vor prüfenden Behörden gerade stehen muss.

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

Was redest du denn ständig von der Veränderung von Funk Eigenschaften? Darum geht es doch gar nicht.
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 » 30.08.2020, 15:17

MichaelN hat geschrieben:
30.08.2020, 15:08
Was redest du denn ständig von der Veränderung von Funk Eigenschaften? Darum geht es doch gar nicht.
Das war nicht ich, Matsch hat das Thema mit CUxD erneut aufgegriffen, auch wenn dazu eigentlich schon alles geschrieben worden ist.
Eigentlich ist die Frage bzw. dreht sich der Thread darum wo und wie man eine ideale Programmierumgebung als Softwareentwickler vorfindet.
Und das ist aus meiner persönlichen Sicht definitiv nicht die CCU selber, wenn um komplexen Code geht, den man strukturieren und wiederverwerten will, warum das aus meiner Sicht so ist habe ich aber ausführlich schon geschrieben.

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, 15:24

CUxD bedeutet doch nicht per se Veränderung an den Funkeigenschaften
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 » 30.08.2020, 17:18

MichaelN hat geschrieben:
30.08.2020, 15:24
CUxD bedeutet doch nicht per se Veränderung an den Funkeigenschaften
Irgendwie scheint Dich das Thema CuxD bzw. Gewährleistung ja zu beschäftigen, dem Threadowner ist das aber egal, der hat nämlich geschrieben das er einen Bausatz nutzt, und da das kein fertiges Gateway ist, gibt es da so oder so keine Gewährleistung durch den Hersteller.
Vielleicht wäre es daher besser wenn Du das Thema vertiefen willst, dafür einen seperaten Thread aufzumachen, sonst wird das irgendwie off topic, schließlich geht es im Kern dem Threadowner um eine Umgebung für Softwareentwicklung und nicht Gewährleistungsfragen des Herstellers.

Um auf Deine Feststellung einzugehen, was würdest Du denn für Schlussfolgerungen ziehen, wenn jemand CuXD installiert und sich auf den oft zitierten Artikel von ELV bezieht, wenn nicht um zusätzliche Funk USB Sticks anzusteuern? Es muss ja nicht per se der Veränderung der Funkeigenschaften dienen, aber wie soll denn ein Hersteller wie e-Q3 genau differenzieren, ob man die Software einfach so installiert hat und für andere Zwecke nutzten will oder ob das wirklich dazu dient zusätzliche Funk USB Sticks am Gateway zu betreiben, so wie das in dem Artikel auch dargestellt ist?

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 » 30.08.2020, 20:27

Hallo und danke nochmals für all die ausführlichen Kommentare zu diesem Thema.

Ich konnte einiges über den Aufbau der Homematic lernen und habe festgestellt, dass ein tieferes Verständnis der Laufzeit-Architektur bei mir noch fehlt aber notwendig ist um planvoller weiter machen zu können. Diese Lücke möchte ich in einem neuen Thread verkleinern.

Hier nehme ich mit: nutze mit beliebiger technologie die XML-RPC Schnittstelle, es lässt sich im Grunde alles machen.

Wenn ich XML-RPC nutze, implementiere ich zwangsweise einen Server der als eigene Anwendung auf der CCU/RaspberryPi oder irgendeiner anderen Hardware/VM laufen muss. Wenn ich keinen weiteren Daemon laufen lassen will, muss ich wohl die existierenden Mechanismen des ReGaHss Programms verwenden (dass diese nicht allen Ansprüchen genügen wurde bereits ausführlich erörtert, muss also nicht erneut betont werden).

Eine abschließende Frage hätte ich noch:

Wenn ich keine zusätzliche Applikation laufen lassen/nutzen möchte, kann ich nur HMScript und alles was mit system.Exec() machbar ist nutzen, oder? Und damit wären Möglichkeiten der Wiederverwendbarkeit, Implementierung von Funktionen etc. nicht mehr geben wenn ich das richtig verstehe.

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, 22:15

micst hat geschrieben:
30.08.2020, 20:27
Hier nehme ich mit: nutze mit beliebiger technologie die XML-RPC Schnittstelle, es lässt sich im Grunde alles machen.
Richtig, dafür sind die Schnittstellen ja da, damit man darüber Homemtic steuern kann. Und im Grunde genommen must Du Dich auch weder im Detail mit Schnittstellen auseinandersetzten, als vielmehr mit der Technologie bzw. Sprache die nutzen willst, wenn Du also bei Home Assistant bleibst, dann eben Python und die Ansteuerung von Homematic aus Home Assistant. Für andere alternative Systeme gibt es eben auch jeweils eine Dokumentation wie man Homematic ansteuert.

micst hat geschrieben:
30.08.2020, 20:27
Wenn ich XML-RPC nutze, implementiere ich zwangsweise einen Server der als eigene Anwendung auf der CCU/RaspberryPi oder irgendeiner anderen Hardware/VM laufen muss.
Das ist letzlich Dir überlassen wenn Du so oder so einen Server laufen hast, kann da ja Home Assistant oder alternativ auch ein anderes System laufen.
Wenn Du unbedingt das Bedürfniss hast das auf die CCU zu quetschen, dann bist Du bei RaspberryMatic falsch, damit geht das nicht. Dann müsstest Du piVCCU nutzten.

micst hat geschrieben:
30.08.2020, 20:27
Wenn ich keine zusätzliche Applikation laufen lassen/nutzen möchte, kann ich nur HMScript und alles was mit system.Exec() machbar ist nutzen, oder? Und damit wären Möglichkeiten der Wiederverwendbarkeit, Implementierung von Funktionen etc. nicht mehr geben wenn ich das richtig verstehe.
Da musst Du Dich halt entscheiden ob Du jetzt so was wie Python bzw. Home Assistant oder alternativ irgendein anderes System, bei dem Du dann eine gängige IDE nutzt, dauerhaft nutzten willst oder eben nicht. Wenn ja, dann ist eine Sprache eines solchen Systems zumindest mächtiger als zu versuchen das auch nur ansatzweise mit HMScript zu lösen. Was Dir auf der CCU definitiv fehlt sind Vererbung wie man das in anderen Sprachen eben gewohnt ist und Expetion Handling wie bei anderen Sprachen gibt es auch nicht, daher ist alles was Du schreibst halt Fehler anfällig bzw. Du musst schon sehr genau verstanden haben was Du da tust um eben bei komplexen Code auch alles stabil laufen zu lassen.
Wenn Du wirklich eine IDE nutzten willst, solltest Du eben auch eine passende IDE und Sprache nutzten als Entwicklungsumgebung. Mit welchen Sprachen bist Du denn momentan vertraut bzw. welche IDE benutzt Du denn zur Zeit bevorzugt um etwas zu schreiben?
Zuletzt geändert von Fonzo am 30.08.2020, 22:21, insgesamt 1-mal geändert.

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, 22:21

Du wirfst da was durcheinander:

Auf der CCU gibt es mehrere XMLRPC Server, die so genannten Schnittstellenprozesse, die die Kommunikation z.b. mit

BidCosRF
HmIP
BidCos-Wired
CuXD
VirtualDevices

abwickeln.

Dein Client kann sich bei den Schnittstellenprozessen anmelden, und bekommt dann änderungen (z.b. ein aktor sendet was oder ähnliches) via push mitgeteilt (muss also nicht pollen). Bei Delphi / Freepascal ist die Indy Bibliothek gerne genommen, von Synapse/Ararat gibts auch eine Implementierung (erfordert aber noch einige Anpassungen). unter python müsste es xmlrpc.client sein. wenn du ds INIT sauber hinbekommen hast, sollten dir dann die Callbacks der prozesse reinlaufen

die Rega hat auch so einen prozess, da geht aber kein Push. Diese XMLRPC Doku findest du bei EQ3, mögliche Methoden kannst du selner am scnittstellenprozess abfragen

die RemoteApi ist quasi die Scriptengine nach aussen geführt (einfach gesagt). Wenn mans kann, kann man sich damit richtig austoben ^^. Ok, manche wissens nicht und verbreiten dann Falschinformationen über die Möglichkeiten. Also zumindest meine beiden Steuerungen laufen seit Jahren stabil: Trotz CuXdD, trotz Änderungen und Patches an der Firmware und trotz intensiven Nutzen von HMScript und Ausnutzen auch der ach so bösen undokumentierten Befehlen.

Black
Zuletzt geändert von Black am 30.08.2020, 22:28, insgesamt 1-mal geändert.
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

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 » 30.08.2020, 22:26

Black hat geschrieben:
30.08.2020, 22:21
Auf der CCU gibt es mehrere XMLRPC Server, die so genannten Schnittstellenprozesse, die die Kommunikation z.b. mit

BidCosRF
HmIP
BidCos-Wired
CuXD
VirtualDevices

abwickeln.

Dein Client kann sich bei den Schnittstellenprozessen anmelden, und bekommt dann änderungen (z.b. ein aktor sendet was oder ähnliches) via push mitgeteilt (muss also nicht pollen)

die Rega hat auch so einen prozess, da geht aber kein Push.
So arbeitet unter anderem ioBroker, der sich mit verschiedenen Instanzen von Adaptern an diese Prozesse anhängt.

Man könnte auch ioBroker als Middleware nutzen, hat dort schon mal alles gebündelt, und sich mit einer eigenen Anwendung an den socket.io Adapter hängen...

VG,
Jérôme ☕️

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

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 » 30.08.2020, 22:59

Fonzo hat geschrieben:
30.08.2020, 22:15
... Dann müsstest Du piVCCU nutzten.
Das klingt nach genau der Lösung die ich gesucht habe obwohl ich es nicht wusste.

Antworten

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