WebUI oder Skriptfunktionen besser bzgl. Systemauslastung/Stabilität?

[Norfolk]

Hallo,

gibt es eine Daumenregel, ob man einfachere Sachen wie z.B. das Setzen von Soll-Temperaturen für 20 Raumthermostate bevorzugt direkt im WebUI-Programm oder eher in einem dort aufgerufenen Skript setzen sollte - oder ist das "Jacke wie Hose"?

Ich denke da primär an die Systemauslastung oder Stabilität.

Hintergrund der Frage ist in meinem Fall, daß ich vor einigen Jahren bevorzugt in Skripten gearbeitet habe und ich frage mich jetzt im Zuge von Überarbeitungen, ob nicht der andere Weg besser wäre. Betrifft eine CCU3 bzw. hier eigentlich eine Raspberrymatic auf Charly.

Danke,
Norfolk

[Xel66]

Daumenregel ist da nicht. Das ist eher individuell. Ich bin eher der Fraktion "Scripte nur dort, wo es zwingend notwendig ist, weil die Programmierumgebung die gewünschte Funktion in Programmen nicht zur Verfügung stellt" zugehörig. Der Hintergrund ist ganz einfach. Die Firmware besitzt nur eine einzige Scriptengine. Läuft ein Script, kann kein anderes (und auch manche Programmfunktiononen) gleichzeitig ausgeführt werden. Hängt ein Script (vorzugsweise welche, die extern kommunizieren), kann dieses zur Verzögerungen im Minutenbereich bis zur Blockierung der CCU führen. Ich sehe keine Notwendigkeit, Funktionalitäten der WebUI in Scripten nachzubilden. Das System ist vom Hersteller ereignisgetriggert ausgelegt. Auch wenn die Programmlogik manchmal sehr gewöhnungsbedürftig ist und von anderen Systemen und Erfahrungen abweicht, ist sie doch strikt logisch (in ihrer eigenen Art). Hat man das mal gefressen, sind auch umfangreichere Steuerungen kein Problem.

Verzögerungen kann man ja seit einiger Zeit auch in Scripten benutzen. Zur Entzerrung der Funkkommunikation (Stichwort: Bestätigungen können Befehler bei zu schneller Reihenfolge überlagern) ist es manchmal notwendig, Aktoren mit Zeitversatz anzusprechen. Ohne diese Verzögerungen schickt die CCU per Script gesetzte Befehle in kurzer Zeit hinereinander raus (im Takt des Scriptlaufes). Das kann zu Kommunikationsstörungen führen. Gerade bei Rollladenaktoren, die etwas geschwätziger sind, kann das pronlematisch sein. Im Normalfall kann das System das handhaben (durch Mehrfachaussendungen), was aber zulasten des Duty Cycle geht. Das Leben ist nicht schwarz/weiß. Es gibt eben auch Anwender, die fühlen sich in einer Scriptsprache wohler, wohl auch, weil sie sich mit den Eigenheiten des Systems nicht auseinandersetzen wollen. Aber nicht umsonst lehnt der Hersteller den Support des Scriptings (und aus vielerlei anderen Gründen) ab. Man kann aber davon ausgehen, dass die den Ausführungen von Programmen zugrundeliegenden Firmwareroutinen ausgiebig getestet sind, so dass sich daraus eher wenig Stabilitätsprobleme ergeben. Tippfehler können da schon größerer Auswirkungen haben und häufiger vorkommen.

Ich betreibe umfangreiche Heizungs-, Licht- und Rollladensteuerungen fast ausschließlich ohne Scripte und fahre recht gut damit. Nur wenn was berechnet wird oder ich Meldungen generiere und Strings handle, greife ich auf Scripte zurück.

Gruß Xel66

[frd030]

Daumenregel ist da nicht. Das ist eher individuell. Ich bin eher der Fraktion "Scripte nur dort, wo es zwingend notwendig ist, weil die Programmierumgebung die gewünschte Funktion in Programmen nicht zur Verfügung stellt" zugehörig. Der Hintergrund ist ganz einfach. Die Firmware besitzt nur eine einzige Scriptengine. Läuft ein Script, kann kein anderes (und auch manche Programmfunktiononen) gleichzeitig ausgeführt werden. Hängt ein Script (vorzugsweise welche, die extern kommunizieren), kann dieses zur Verzögerungen im Minutenbereich bis zur Blockierung der CCU führen.

Ich kann dem nur zustimmen.
Das hängt mit dem obigen Umstand zusammen, aber auch damit, dass man Skripte nur sehr eingeschränkt testen und debuggen kann, zumindest mit Bordmitteln. Zudem habe ich den Eindruck, dass die Skriptengine beim Hersteller nicht die größte Priorität bei der SW-Pflege geniesst (letztlich lehnt der sogar den Support ab, wenn Skripte vorhanden sind, bei RM vielleicht nicht so tragisch). Da es auch keine bordeigene übergreifende Möglichkeit gibt, Skripte im Zusammenhang zu sehen, verliert man auch sehr schnell den Überblick, es sei denn man nutzt Fremdtools wie SDV. Es gibt kein lokales Variablenkonzept, was Seiteneffekte wahrscheinlicher macht. Fehler führen häufig auch nicht gleich zum Absturz, aber zu "unterhaltsamen" Fehlfunktionen der ganzen CCU, die nicht immer gleich mit einem Skript in Zusammenhang zu bringen sind. Das Forum ist voll von sowas.

Auch ich nutze Skripte nur, wenn es nicht anders geht. Meist für die Steuerung "fremder" Gerätschaften, dann muss man allerdings höllisch aufpassen, dass die CCU nicht blockiert. Ich hatte auch schon diverse "Nebeneffekte" durch Skripte, die extrem schwer zu finden und fixen waren.

Management Summary:
Mit der WebUI lässt sich eigentlich fast alles machen, nicht schön, aber funktional.
Skripte machen den Betrieb der CCU in der Regel nicht stabiler.
Skirpte nutzt man, wenn es nicht anders geht und dann muss man wissen, was man tut!

[Norfolk]

Danke euch beiden für die umfangreichen Antworten!

[Norfolk]

Zur "externen Kommunikation" kurz nachgefragt:

Ich verwende für externe Befehle wie SSH oder CURL den CUxD, siehe unten. Bremst das ebenfalls die Script-Engine, d.h. wartet die CCU bis der Befehl erledigt ist - oder wird lediglich resourcenschonend der State gesetzt und das Script kann weiterlaufen, während der Befehl parallel vom CUxD erledigt wird?

Code: Alles auswählen

dom.GetObject("CUxD.CUX2801001:3.CMD_EXEC").State("gewünschtes shell-command");

[Black]

wenns es ein Aufruf ist, von dem kein Rückgabewert erwartet wird, ist das so schon korrekt, oder ein system.exec mit dem & am Ende.

wenn man ein Ergebnis erwartet und dieser Rüclgabewert beispielsweise noch von einer externen Seite kommt, benutze ich von CUXD die Callback funktionalität. dies splittet sich dann in 2 programme.

programm 1 staret die Abfrage an die Seite, und gibt danach auch sofort wieder die Rega frei, andere Programme und ereignisse können weiterhin bearbeitet werden, es findet kein blockieren der Rega statt.

trifft das Ergebnis ein (CallBack) , dann wird mit diesem Ereignis Programm 2 getriggert und die Bearbeitung des Ereignisses kann durchgeführt werden.

Praktisches Beispuel gibt es, wenn mann hier meinen Beitrag zum Auslesen einer SUSV sucht, dies arbeitet genauso

Black