Neue Funktion zum generischen Schalten: RequestAction

Auf Grundlage von diesem Thema (IP-Symcon Community Forum) und dieser Ausführung (IP-Symcon Community Forum) möchten wir zu IP-Symcon 5.0 noch eine neue Funktion einführen die maßgeblich das Schreiben von Skripte beeinflussen wird.

Seit IP-Symcon 1.0 gibt es für jedes schaltbare Gerät eine oder mehrere Funktionen, die es erlauben einen Schaltbefehl (=Aktion) auszuführen. Dieser Befehl wurde dokumentiert und jeder Nutzer musste diesen nachschlagen/lernen. Mit Version 3.0 kam das WebFront. Dort war es möglich direkt an der Variable eine Aktion aufzurufen. Technisch ist dies möglich, da intern eine Zuordnung zwischen dem Ident der Variable und der Funktion zum Schaltbefehl besteht. Dies findet sich in den PHP Modulen auch unter der Modul-Funktion „RequestAction“ wieder. Für alle nativen Instanzen konnte dies lange über die undokumentierte und etwas komplexe Funktion IPS_RequestAction aufgerufen werden, welche mittlerweile viele PHP Module (z.B. Alexa, Assistant, HomeKit) verwenden.

Noch einmal einen Schritt zurück. In der Theorie haben wir in der Vergangenheit versucht immer Geräte (=Instanzen) als Ziel auszuwählen. Prominente Module waren dabei das (alte) Shutter Control / Heating Control. Mittlerweile geht der Trend dazu über die Ziel-Variable auszuwählen, da dadurch eine viel einfachere Verknüpfung erstellt werden kann. Bisher gab es jedoch keine Funktion die dies einfach für alle Anwender/Modul-Entwickler zur Verfügung gestellt hat.

Dies möchten wir mit der RequestAction Funktion ändern. Die Funktion erlaubt es die (Variablen-)Aktion auf einer beliebige Variable auszuführen. Sofern dort eine Aktion definiert ist, wird diese ausgeführt - unabhängig davon, welches echte physikalische Gerät dahinter versteckt ist.

Auf lange Sicht bedeutet dies, dass wir uns nach und nach von den hardwarespezifischen Funktionen (wie z.B. EIB_Switch) verabschieden können und fast immer die RequestAction Funktion nutzen können. Als Grundsatz würde dann gelten: Alles was du im WebFront schalten kannst, kannst du auch mit RequestAction schalten. Und man muss sich nur noch spezielle Funktionen merken, wenn man wirklich spezielle Dinge schalten möchte. (z.B. Dimmen mit benutzerdefinierter Rampe)

Man könnte sich nun die Frage stellen, warum wir nicht einfach SetValue dafür nehmen. Die Antwort ist einfach: SetValue setzt weiterhin den Wert einer Variable. Wir wollen jedoch das Gerät schalten, die dann wiederum (sofern erfolgreich) den Wert der Variable aktualisiert.

Ein paar offene Fragen zu der Funktion gibt es noch:

[ul]
[li]Sollte die Funktion intelligent das Prozent-Suffix auswerten, sodass dann 0-100% angegeben werden kann?[/li][li]Sollte die Funktion den eingegebenen Wert anhand vom Profil validieren? z.B. sollte bei Schrittweite 0,5 nur diese Schrittweite erlaubt werden?[/li][/ul]

Ich freue mich auf euer Feedback, zumal es für die nächsten Jahre einiges ändern/vereinfachen wird.

Beispiel zum Schalten von HomeMatic:


//Vorher
HM_WriteValueBoolean(12345, "STATE", true); //12345 ist die Instanz

//Jetzt
RequestAction(23456, true); //23456 ist die STATE Variable

paresy

PS: Für euch Entwickler gibt es auch noch RequestActionEx, welche den Sender in der Systemvariable beeinflussen kann.

Sollte die Funktion intelligent das Prozent-Suffix auswerten, sodass dann 0-100% angegeben werden kann?

Kannst du das noch mal kurz erläutern, da steh ich gerade aufm Schlauch…

Sollte die Funktion den eingegebenen Wert anhand vom Profil validieren? z.B. sollte bei Schrittweite 0,5 nur diese Schrittweite erlaubt werden?

Definitiv ja, vor allem auch Grenzwerte müssen überprüft werden

Und als insgesamt-Feedback: Sehr guter Schritt in die richtige Richtung für die Entwickler. Wenn wir jetzt die harte Verknüpfung von Object-ID und physischer Instanz weg bekommen würden, wäre mir auch an anderer Stelle geholfen.

Bei den Prozenten geht es darum, ob wir den echten Wert angeben oder eben einen Prozentwert, sofern das Profil es unterstützt. Ein Prozent als Suffix zeigt im WebFront immer einen Slider von 0-100% an. Somit könnte auch die RequestAction Funktion dies abbilden und somit die Nutzung vereinfachen.

Beispiel:


//RequestAction ohne Prozentfunktion. Profil = Intensity.255
RequestAction(12345, 255); //100%

//RequestAction mit Prozentfunktion. Profil = Intensity.255
RequestAction(12345, 100); //100%

paresy

Wie unterscheidest du dann ob er den echten Wert oder den Prozentwert angegeben hat? Ausschließlich den Prozentwert halte ich für nicht gut

Hallo paresy,

ah finde ich Klasse, als ich damals beim HomeBridge Modul gefragt habe, wie ich das realisieren kann, wurde mir die undokumentierte Funktion von euch erklärt, mit Hinweis darauf, dass diese jederzeit entfallen kann. Aber nun wird sie zum Standard, gefällt mir. :slight_smile:

Sollte die Funktion den eingegebenen Wert anhand vom Profil validieren? z.B. sollte bei Schrittweite 0,5 nur diese Schrittweite erlaubt werden?

Ich glaube, ich würde es so vorziehen.

Grüße,
Kai

Nur ganz kurz von unterwegs.
Bitte ohne Berücksichtigung der Profile!
Sobald ein User das Profil der Variable ändert, stimmten die Daten dann nicht mehr.
Grundsätzlich sehe ich jede weitere Konvertierung oder Prüfung der Daten als Aufgabe des Moduls. Die Funktion sollte also die angeforderten Rohdaten liefern.
Beispiel sind auch Variablen wo sich die Wertgrenzen dynamisch Bewegen können, also muß eine Prüfung so oder so im Modul stattfinden.

Zumal es ja ein breaking change wäre; bei IPS_RequestAction.
Dann müssen alle ab sofort, um bei Dimmern zu bleiben, immer mit 0-100 eingangsseitig arbeiten und ausgangsseitig passend skalieren.
Damit gibt es weitere Rundungsfehler und Unschärfe bei Werten.
Man könnte von 255 Stufen des Dimmers somit nur noch 100 ansprechen.
Michael

Super Vorschlag!

Bei den Fragen schließe ich mich den Antworten und Argumenten von Nall-Chan an:

  • keine Berücksichtigung der Profile

Gruß

Burkhard

  • keine Berücksichtigung der Profile

Hm, da muss ich noch drüber nachdenken.
Am Beispiel LCN haben alte Module 50 Dimmschritte, die auf 100% aufgelost sind, also immer 2% mehr oder weniger, bei neuen LCN Modulen sind es 200 Dimmschritte, bei 0-100% immer 0,5%.
Dann noch andere Module mit 0-255 Dimmschritten oder 0-100 Dimmschritten.
.
Wenn ich das im Profil abbilden kann, würde ich es so machen.(unsicher…):smiley:

Ohne Profil geht gar nicht finde ich. Die Aktion ist jetzt „Universal“, das ist super, aber mindestens für Grenzwertprüfungen etc. muss es eine „individuelle Instanz“ geben. Die Module hat man ja nicht „im Griff“ , ein ungültiger Wert kann ja auch mal ungewollt destruktive Folgen haben… irgendwie will ich das begrenzen können… alles andere wäre ein „wird ja schon klappen“…
An Profilen könnten man ja z.b. auch die gültigen Werte abfragen… wo soll ich sowas sonst machen?

Worauf bezieht sich deine Frage?
Auf die IPS Module oder die PHP-Module?
Wenn letzteres destruktive Folgen hat, oder keine Werteprüfung, hau es dem Autor um die Ohren.

Was ist mit den Usern, welche sich spezielle Assoziationen bauen um z.b. in einer Zeile Status, Aktion und Wert darzustellen? Das funktioniert dann auch nicht mehr.
Die Idee durch IPS eine Aktion auf die Variable zu triggern ist gut, aber der Nutzer muss dennoch wissen ob nun true Licht an oder false Licht an ist :wink:
Zusätzlich müssen dann auch die .Reversed Profile berücksichtigt werden.
Das wird dann chaotisch, wenn es sich um zwiespältig bool-Vars handelt. Wie ‚Alarm ausgeschaltet‘. Und was ist nun bei True? An oder aus?
Michael

Sowohl als auch, hier sollte keine Unterscheidung getroffen werden für eine allgemeine Funktion

:confused: Gerade da macht es doch Sinn, wenn sich ein User ein explizites Profil baut, sollte es doch auch nur in diesen Grenzen verwendet werden. Der Ansatz ist doch das gleiche zu tun wie das Webfront und da kannst du auch keine Werte außerhalb des Profils eingeben. Und die .Reversed-Profile sind doch genau das selbe, wenn true = AUS und false=AN bedeutet, dann doch auch für die neue Funktion. Ich will ja nicht wissen (müssen) das es bei diesem Modul anders ist, ich will „AN“ übergeben können und dann funktioniert es… alles andere führt die Funktion ad-absurdum

Kann man nicht auch einfach nur die Funktion prüfen lassen, ob der richtige Wert übergeben wurde ob bool, integer oder string? Und sollte ein Wert übergeben werden, der nicht zulässig ist muss das Modul eine Meldung ausgeben.

An die Möglichkeit, dass ein Entwickler das Profil ändert hab ich gar nicht gedacht.

Grüße,
Kai

Gesendet von iPhone mit Tapatalk

Und das ist der Unsinn. Weil wir ja nicht vom WebFront reden, sondern wenn ein User ein Script oder Ereignis mit IPS_RequestAction nutzt.
Kann doch Absicht sein, dass das Profil nur z.b. Assoziationen 1,2 und 5 im WebFront darstellt, aber er per Script auch 3 und 4 setzen will.

Das Profil ist zur Visualisierung!
Beispiel RGB. Ich gebe fünf Werte für das WebFront per Profil vor; möchte aber niemals die Möglichkeit verlieren es per Script auch anderen Werten zu übergeben.
Das Profil hier mit einzubeziehen macht es für die Nutzer nur noch komplizierter was es eigentlich vereinfachen soll.

@KaiS
Datentypen brauchst du bei IPS 5 nicht prüfen, da wirft PHP dann schon vorher einen Fehler in der __generated (PHP7). Das war nötig bis IPS 4.4
Michael

mmh, ich glaube da ist etwas noch nicht ganz durchdacht… einerseits soll es die Befehle verallgemeinern, andererseits sind die Parameter dann ggf. doch wieder so unterschiedlich das ich doch wieder genau wissen muss was es für ein Modul/Instanz ist… :banghead: das würde es nicht leichter machen… ja, nur ein Profil für Anzeige und Grenzwerte zu haben wäre blöd, aber ganz ohne fehlt mir die „Konvertierung“ die die Funktion wirklich allgemeingültig macht… dann kann ich mir auch die Methoden raussuchen, wenn ich es für die Werte eh muss…

Eine systeminterne Normierung der Werte auf Prozent oder Ähnliches wäre zwar nicht schlecht, jedoch ist die Hardware in der Praxis zu verschieden. Die Folge davon sind dann Rundungsfehler, die zu sehr ärgerlichen Systemverhalten führen können. Daher bin ich auch der Meinung, dass IPS hier nix skalieren sollte. Die Werte sollen „unverfälscht“ an die Hardware übergeben werden. Skalierung und Grenzwertüberwachung gehört ins Script oder in das Zielsystem.

Gruß
Dieter

Ich habe mir für einen vergleicbaren Usecase generische Device-Module für Switch/Dimm-Funktionen sowie Energy- und Wetterdaten gebaut, bei denen das verbundene spezifische Splittermodul die korrekte Umsetzung der Action sorgen muss. Das heist, ich kann immer mit den gleichen Befehlen Schalten und muss mich nicht um die dahinter liegende Umsetzung kümmern.

Es ist aber dann schon so, das man sich auf einen gemeinsamen Nenner der Funktionalität einigen muss und Sonderfeatures damit nicht mehr unterstützt werden können, weil es sonst zu unübersichtlich wird.

Tommi

Als SPS-Programmierer habe ich zur Zeit unheimlich viel mit der Kopplung zu I4.0- bzw. IoT-Systemen zu tun.
Wahnsinn, was das Thema Typen Zeit kostet.
90% der Programmierer sollte man mal wieder vor einen C-Compiler setzen.
Ich bekomme mittlerweile einen Hass auf typlose Sprachen :banghead:

Warum nicht 2 Befehle?
Eines mit und eines ohne Berücksichtung der Profile:

Mit: RequestAction
Ohne: RequestActionRaw

Wie ist denn das nun umgesetzt worden?

RequestAction ohne Berücksichtigung der Profile.