WebUI/ReGaHss Beta für CCU2 & RaspberryMatic (2.29.x)

[deimos]

Vielleicht gibt es ja einen Fall wo der User froh ist wenn er es am Anfang des Scriptes auf 10 setzt und am Ende wieder hoch.

Genau das sollte ein Nutzer aber definitiv nicht machen und dafür gibt es auch keinen Grund.

Dann verstehe ich grade nicht, wofür es die Funktion überhaupt gibt, wenn diese nicht genutzt werden soll. Dann braucht man doch eigentlich nur streiten, was der Default-Wert sein soll und wenn das anders sein soll, ließt man es aus einer Config Datei. In eine API Funktionen aufzunehmen, bei denen der Entwickler selbst von vorne herein sagt, man soll sie nicht nutzen, sind imho einfach nur schlechtes Design.

Viele Grüße
Alex

[jmaus]

In eine API Funktionen aufzunehmen, bei denen der Entwickler selbst von vorne herein sagt, man soll sie nicht nutzen, sind imho einfach nur schlechtes Design.

Bitte mal einen Gang runterschalten und mir hier nicht schlechtes Design vorwerfen. Es gibt sehr wohl einen Grund dafür das diese Funktion da ist und das muss sich der Allgemeinheit eben auch nicht sofort und unmittelbar erschliessen. Jedoch beantworte ich das natürlich gerne wenn mir nicht schon wieder Inkompetenz vorgeworfen wird.

Auch hatte ich nicht gesagt das man die nicht generell nutzen sollte, sondern eben nicht in dem Kontext das man vor einer while() das MaxIterations() auf den wert setzt die eine schleife maximal durchlaufen soll. Sie ist eben da wie jede andere system.XXX() Funktion, nämlich um globale Dinge einzustellen/auszulesen. Und bitte auch nicht vergessen das man die Methode auch ohne Parameter aufrufen kann um eben nun herauszubekommen was die maximale Anzahl von Iterationen ist.

[deimos]

Hi,

ich werfe dir ganz bestimmt keine Inkompetenz vor. Aber ich stehe zu der Aussage, dass eine API Funktion, die man nicht nutzen soll, kein gutes, sondern ein schlechtes Design sind. Und das die Rega nicht grade ein Paradebeispiel für gutes API Design ist, kann man (ganz emotionslos) auch nicht verneinen und da verstehe ich durchaus, dass manchmal Dinge in ähnlicher Weise übernommen werden müssen, damit man da keinen kompletten Bruch drin hat.

Das Problem ist, du schreibst recht allgemein gehalten, man soll es nicht benutzen, und jetzt nebulös, dass es doch einen Grund gibt. Da frage ich mich, welcher das sein soll. Hier aus dem Thread konnte ich es nicht erkennen, aber vielleicht habe ich es auch einfach übersehen.

Viele Grüße
Alex

[jp112sdl]

ich halte nichts von Bevormundung der Nutzer wenn ein User dort eine 1 einträgt ist das doch seine ccu. Jeder kann zu Hause mit seiner CCU machen was er will...
OB sinnvoll oder nicht kann ich nur für meine ccu beurteilen. Vielleicht gibt es ja einen Fall wo der User froh ist wenn er es am Anfang des Scriptes auf 10 setzt und am Ende wieder hoch.

Ein Flüchtigkeitsfehler im Skript und nicht nur das Skript, sondern die ganze CCU ist global betroffen?
Vielleicht nur bis zum Reboot, wo dann aber u.U. das fehlerhafte Skript erneut ausgeführt wird?
Gefährlich auch für Skript-Anfänger, die sich per Copy und Paste irgendwo was unwissend zusammenkopieren.
Klar, wer format c: eingibt, muss sich nicht wundern, dass seine Festplatte auf einmal leer ist - jeder muss oder sollte selbst wissen, was er macht.

Ich sehe es wie alchy. - Wer ist denn bisher darüber gestolpert, dass er (s)ein Skript nicht nutzen konnte, weil diese Funktion fehlte?

[Familienvater]

Hi,

soweit ich das Problem verstanden habe, hat es mit der größerwerdenden Anzahl an möglichen Plattformen zu tun.

Früher war ein konstanter Wert reinkompiliert, der sich irgendwie an der Hardwareleistung der CCU2 orientiert hat, und für das harte beenden einer möglichen Endlosschleife nach ich sage mal 15 Sekunden geführt hat. Dann kam Raspberrymatic, und auf einmal wäre eine potentielle Endlosschleife schon nach 5 Sekunden abgebrochen worden (weil der Raspi schneller die Durchläufe schafft), deswegen wurde angedacht, den Wert global für alle Plattformen wieder so zu erhöhen, das auch ein Raspi sich z.b. 15 Sekunden beschäftigen würde, bis es hart abgebrochen wird, das hat zu einem Aufschrei der CCU-User geführt, weil die jetzt 45 Sekunden warten müssten, bis eine potentielle Endlosschleife abgebrochen werden würde, währenddessen aber z.B. der Event-Ringpuffer mit 500 Events volllaufen könnte, also wurde es konfigurierbar gemacht, das passt jetzt auch wieder einigen nicht.

Mir fällt persönlich kein Grund ein, warum ein Raspi/Tinker/Sonstwie-Board mehr Iterationen machen können sollte, als eine CCU, und egal ob der Wert vorher auf max 5.000, 50.000 oder 500.000 Iterationen Stand, mir fällt auch nicht ein, warum ein sinnvolles Script mehr als 50.000 Iterationen machen können sollen müsste, selbst wenn man irgendwie über alle Datenpunkte iterieren wollte, laut EQ3 sind ja eher nur 32.000 möglich als 64.000, logisch wäre für mich wenn überhaupt, das der Wert nicht kleiner gestellt werden kann, als er ursprünglich hart reinkompiliert war, wer dann (warum auch immer) mehr braucht, der kann von mir aus das Limit hochsetzen.

Der Familienvater

[Cash]

Ok aus der sicht: Nicht niedriger als es vorher fest verdrahdet war ist evtl wirklich nicht der schlechteste Ansatz...

[jmaus]

Schon erledigt

[robsdobs]

Ich denke auch, der Wert sollte sich nicht niedriger stellen lassen als für eine originale CCU2 sinnvoll ist.

Vom Smartphone gesendet.

[Cash]

Hallo Jens,

Du bist aber schnell heute. Für welche Lösung hast Du Dich entschieden? Für die Idee vom Familienvater?

[jmaus]

Hallo Zusammen,

für die interessierten ReGaHss Tester ist heute eine neue ReGaHss beta (beta27) im OCCU Repository erschienen:

Verfügbar wie immer im OCCU Repository. Die darin von mir vorgenommenen Änderungen können aus dem ChangeLog (siehe hier) herausgelesen werden.

Die Anpassungen die gegenüber der letzten hier benannten Version (beta25) vorgenommen habe lassen sich wie folgt zusammenfassen:

• Feature: ReGa – "incorrect use" Warnungen für die Verwendung von Device() auf DP Objekte und LastTimestamp() und LastTimestampSeconds() auf Kanal-Objekte hinzugefügt um bei der Skriptentwicklung ähnlich wie bei einer inkorrekten Verwendung von AlDestMap() benachrichtigt zu werden.
• Bugfix: ReGa – Automatische Erweiterung des Variablenstacks umgesetzt um bei einer Abarbeitung von vielen genutzten Variablen nicht zu einem stack overflow zu kommen.
• Bugfix: ReGa – Angabe des Charset Encoding (ISO-8859-1) zu allen xmlrpc Antworten hinzufügt um Clients die Möglichkeit zu geben eine bessere Zeichenkonvertierung vorzunehmen.
• Feature: ReGa – Minimum von 5000 für das setzen eines Iterations limits hinzugefügt.

Bei dieser Version würde ich darum bitten, detaillierte Tests durchzuführen und mir Fehler/Hinweise/FeatureRequests zeitnah zukommen zu lassen. Dies soll helfen etwaige weitere Fehler aufzudecken und bis zur letztendlichen Integration in die nächste RaspberryMatic oder CCU2 Firmware diese noch ggf. zu beseitigen. Gerade für den kommenden RaspberryMatic Release soll damit geklärt werden ob mit dieser Version gravierende Fehler zu erwarten sind.

Wie auch die vorherige Version wurde diese Version mit dem von hobbyquaker entwickeltem Testframework getestet (siehe https://github.com/hobbyquaker/occu-test). Wenn hier jemand freie Ressourcen hat mögliche Testcases (auch ReGa-Skriptests sind möglich) mit zu entwickeln die wir da mit aufnehmen können (lediglich Javascript-KnowHow notwendig), dann bitte melden oder aber auch einfach hier mal ein paar ReGa-Skripte einstellen die als mögliche Testcases genutzt werden können um Funktionalität auf ihre Konsistenz hin zu überprüfen.

Um die neue Betaversion zu installieren / testen bitte einfach wie im ersten Beitrag in diesem Thread vorgehen und die Version über die existierende /bin/ReGaHss bzw. /bin/ReGaHss.community drüberinstallieren. Die Anleitung sollte hierbei auch bei der aktuellen 2.31.x problemlos umgesetzt werden können.