raspberryMatic und Scripting

[hlwerschner]

Ich meine mich zu entsinnen, dass mit den ersten Diskussionen zu OCCU auch die Qualität (?) bzw Stabilität der Rega und auch der dort verankerten Script-Sprache (ich würde es ja nicht "Sprache" nennen) angesprochen wurde. Mit deer Softawre der CCU1/2 jetzt auf dem Raspberry sollte doch diese Diskussion, speziell ob man nicht eine brauchbare Scriptsprache nutzen sollte, aufgenommen werden.

Meine Vorstellungen wären:
1/ Eine moderne und einfach zu lernende Interpretersprache, die STABIL läuft und weder Auswirkungen auf die Lauffähigkeit des Kernels hat noch auf die Komponenten, die für Homematic Aktoren/Sensoren unabdingbar sind, hat. Also Kapselung und Fehler-Toleranz, als auch automatisches Recovery von Script-Fehler-Situationen. Ebenso gehört dazu eine saubere Verwaltung von Versionen/Änderungen (muss aber nicht gleich SVN sein).

2/ Scripte müssen syntaktisch prüfbar sein und zwar vollständig und nicht nach und nach durch schrittweises Vortasten, bevor man den ersten Run-Test macht. Ein guter Debugger mit den heute üblichen Funktionen (schrittweises oder Haltepunkte-getatktetes Testen, Watch auf Variablen-Werte-Änderungen und evtl Rücksetzen nach Korrekturen sind so einige triviale Forderungen).

3/ Die Limits, die nach und nach für die CCU-Scripte bekannt geworden sind ( max 200 SystemVariable, nicht zuviele Variablen in einem Script, merkwürdiges Verhalten bei Kommentaren , um nur ein paar Punkte zu nennen) müssen aufgehoben werden. Und natürlich muss die Doku konsistent mit der Sprache sein.

4/ Der Zugriff auf die Devices, Channels, Datenpunkte könnte meiner Meinung nach elementarer Bestandteil in Ausdrücken der Anweisungen sein und auch klarere Meldungen bei Zugriffsfehlern geben. Wenn z.B. ein Zugriff auf einen Datenpunkt ähnlich dem Referenzieren von properties in Javascript-Objekten erfolgen würde, könnte ich einfach schreiben:

mywert = Gaszaehler.METER;

um das zu tune, was ich jetzt mit

var obj = dom.GetObject("CUxD.CUX2500002:1.METER");
if (obj) {
real mywert = obj.Value();
}
kodieren muss, weil u.A. der Name "GasZaehler" sehr wohl in der Rega bekannt ist, aber ....

5/ Ganz wichtig, es muss lokale Unterprozeduren/Funktionen geben um modulare Scripte mit Code-Wiederverwendung zu haben. Ich hasse diese ewige Copy-Pasterei von einem Script in das nächste , objwohl fast alles gleich läuft (Fast!).

Oh, mir fällt noch viel mehr ein, aber als Start und um mal zu hören, ob ich der einzige bin, der so unzufrieden mit dieser "Programmier-Stümperei" ist, solls reichen.

Ich glaube, wir können heutzutage ziemlich gute und VIEL bessere Alternativen ausmachen und die würden auch auf dem raspberryMatic gut laufen. Ich habe oben schon mal Javascript erwähnt, das von seiner Syntax und Semantik nicht so schlecht ist - relativ zu den Anforderungen an eine einfache Scriptsprache - und sowohl weit verbreitet als auch sehr gut gepflegt ist. Ich glaube, bei node.js wurde z.B. die V8 engine erwähnt, mit der vielleicht auch nicht-HTML-embedded scripting (also stand-alone) gehen könnte.

Was meint ihr?

[paul53]

Ich glaube, wir können heutzutage ziemlich gute und VIEL bessere Alternativen ausmachen und die würden auch auf dem raspberryMatic gut laufen. Ich habe oben schon mal Javascript erwähnt, ...

Dann schau Dir mal ioBroker in Verbindung mit Hmcon an. Hmcon ist quasi raspberryMatic ohne ReGa und HM WebUI.

[hlwerschner]

ich kenne ioBroker. Habe eine Installation auf windows pc und testweise eine auf nem Raspberry 1 (ist ziemlich langsam, hat etwa 3 std gebraucht, um alle updates zu machen). Irgendwie hab ich auch keine Doku jenseits der Installation gefunden, alles auch sehr Linux lastig. Ich kann Linux, aber das ist nicht anwenderorientiert.

Meine Frage geht auch nicht dahin, mehrere Kisten zu haben, auf denen dann jeweils ein bisschen was von der Hausautomation läuft . RaspberryMatic is bestechend, weil es (a) eine direkte Migration ALLER Daten/Funktionen der CCU2 erlaubte und (b) viel schneller UND STABILER läuft - im Rahmen des Beta-status. Meine Intention ist, ein PRODUKT zu bekommen, auf der ich meine individuellen Einstellungen wie gehabt (CCU2-Scripting etc) machen kann und dann läuft es. Dass dabei Schwächen der Gesamtarchitektur angegangen werden müssen , ist mir und sicher vielen anderen klar. So eine Baustelle ist die Scripting-"Sprache", von ver ich eben glaube, dass man da etwas verbessern kann, ohne gleich alles wegzuschmeissen. ioBroker (und HMcon) haben einen anderen Ansatz und ursprünglich eine andere Plattform, darüberhinaus vermute ich nach Lesen aller Forumposts zu dem Thema, dass da noch sehr viel mehr "beta" ist. Aber wie ich sagte, ich will als Basis ein solides Homematic-Server Kistchen und sehe meine Bastelleidenschaft nicht im täglichen Linux-paket austauschen und testen sondern in der Erweiterung der "Hausautomation" selbst und evtl der Entwicklung von GUI-Frontends, die von Laien aufsetzbar sind (a la HTML5 Grafik).

Nach 45 Jahren EDV (Systemprog und Sw-Entwicklung/Beratung) bin ich nur noch Anwender mit einem kritischen Blick für Hw/sw-Qualität, aber bin auch bereit, mitzuarbeiten um etwas voranzubringen. Nur meine Tage für Löten und Assembler-Programmierung sind vorbei

Ich finde RaspberryMatic zur Zeit sehr gut und glaube, dass das Zukunft hat (als CCU3 sozusagen) wenn das Anwenderlevel erreicht wird und es besser/stabiler/schöner als CCU1, CCU2 ist. Da ist mein angesprochener Punkt "Script-Sprache" ein Topic, und die Intention meines Posts war, herauszubekommen, ob andere das auch so sehen.