Wertebereich von Variablen beschränken / Sprung im Wertebereich von Profilen

IP-Symcon
1

Hallo zusammen,

da ich gerade mal wieder eine Anpassung meiner Anlage vornehme, stolpere ich mal wieder über eine Frage, die ich eigentlich schon habe, seit ich IPS nutze:

Gibt es eine Möglichkeit, den von IPS akzeptierten Wertebereich für Variablen zu beschränken bzw. Sprünge im Wertebereich von Variablenprofilen zu realisieren?

Um es etwas verständlicher zu machen, folgender Anwendungsfall:
Ich verwende diverse Dimmer, deren Dimmbereich je nach verwendetem Leuchtmittel unterschiedlich beschränkt ist. Der Einfachheit halber nehmen wir mal an, dass der Dimmer nur den Dimmbereich von 50-100 % Helligkeit akzeptieren soll und natürlich die Zustände ‚Ein‘ und ‚Aus‘, welche 100 % und 0 % entsprechen.
Normalerweise haben die Dimm-Variablen bei mir das Integer-Profil ~Intensity.100. Damit kann ich dann jeden beliebigen Dimmwert einstellen, allerdings inkl. des unzulässigen Bereichs von 1-49 %. Mit 0 % kann ich den Dimmer so jedoch wie gewünscht abschalten.
Wenn ich das Profil nun modifiziere und als Minimalwert 50 zulasse, so kann ich zwar den Dimmbereich auf den gewünschten Bereich beschränken, kann den Dimmer jedoch nicht mehr mit 0 % ausschalten, da 0 % dann 50 % entspricht.

Kann ich es irgendwie erreichen, dass 0 % als 0 % interpretiert wird und der restliche Bereich (1-100 %) als 50-100 % intepretiert wird? Oder kann ich es irgendwie erreichen, dass der Bereich zwar wie bei ~Intensity.100 von 0-100 % geht, Werte im Bereich 1-49 % aber von IPS abgelehnt und nicht an die zugehörige Dimmer-Instanz weitergeleitet werden?

Ich habe mich früher damit beholfen, eine weitere Variable für das Webfront zu erstellen, deren eingestellter Wert zunächst mittels Ereignis/Skript auf Gültigkeit geprüft und ggf. korrigiert wird und dann nur die korrekten Werte an die eigentliche Variable / Instanz weitergereicht werden. Das ist aber irgendwie doppelt gemoppelt und nicht wirklich schön.

Also bin ich auf der Suche nache einer Möglichkeit, entweder Profile mit Sprüngen im Wertebereich zu erstellen, die trotzdem ein nahtloses Auswählen (Slider) ermöglichen oder aber bzw. zusätzlich den zulässigen Wertebereich von Variablen zu beschränken, sodass diese grundsätzlich keine anderen Werte als die gewünschten akzeptieren. Für letzteres hätte ich noch eine Reihe weiterer Anwendungsmöglichkeiten.

Mit den mir aktuell bekannten Möglichkeiten in IPS ist es zur Zeit so, dass ich den Wertebereich - sofern möglich - direkt am Dimmer beschränke. Dann korrigiert im besten Fall der Dimmer den gesendeten Wert und meldet den korrigierten zurück. In machen Fällen geht dies jedoch nicht und der Dimmer korrigiert den Wert entweder und sendet die Korrektur aber nicht zurück an IPS oder der Dimmer lässt explizit das Überschreiben mit ungültigen Werten zu. Dann ist beispielsweise der Wertebereich am physischen Taster wie gewünscht beschränkt, in IPS jedoch nicht.

Ich hoffe ihr könnt mir folgen worum es mir geht und habt vielleicht eine einfache und praktikable Lösung für mich. :smiley:

Gruß
Slummi

2

Mir würde als Lösung hier ein eigenes Aktionsskript einfallen. Damit könntest du dann den Wert überprüfen und ggfs. an die Instanz weitergeben. Je nachdem wie du den „blockierten“ Bereich umsetzen möchtest, kannst du ihn entweder in den passenden Bereich korrigieren oder eine Fehlermeldung ausgeben.

3

Hallo Dr. Niels,

das mit dem Aktionsskript ist eine wirklich gute Idee! Selbst - oder besser - gerade weil man IPS schon so lange nutzt, ist man manchmal echt betriebsblind. Das Aktionsskript ist mir gar nicht in den Sinn gekommen und funktioniert wunderbar - mit einer kleinen Einschränkung.

Statusvariablen sind ja schreibgeschützt. Das heißt ich kann ihnen kein Aktionsskript zuweisen, bei denen ich den Wert am Ende mit SetValue() setze. Stattdessen muss ich direkt über die entsprechenden Befehle der Instanz gehen.

Hier ist nun aber das Problem, den passenden Befehl rauszukriegen. RequestAction() hilft mir ja in dem Fall nicht weiter, weil ich dann wieder auf meinem eigenen Aktionsskript landen würde. Gibt es da eine elegante Lösung, wie ich der Statusvariablen zwar ein eigenes Aktionsskript zuweise, im Skript selbst aber den ursprünglichen Befehl der Standardaktion rauskriege?

Aktuell habe ich mir für die betroffenen Variablen ein Aktionsskript entsprechend zum jeweiligen Instanztyp erstellt. Cooler wäre aber, wenn ich ein generisches Skript erstellen könnte, was für jeden Instanztyp funktioniert. Eine weitere Variable, die nicht schreibgeschützt ist, würde ich nach Möglichkeit umgehen wollen.

Hat dazu noch jemand Ideen / Tipps?

Gruß
Slummi

4

Ich habe noch mal ein wenig rum gespielt und überlegt, wie ich das lösen kann.
Aber mir fällt nicht wirklich was ein.

Daher mal folgende allgemeine Frage:
Wäre es nicht hilfreich, wenn man eine Funktion analog zu RequestAction() hätte, mit der man immer die ursprüngliche Standardaktion der Variablen bekommt, selbst wenn diese durch ein eigenes Aktionsskript überschrieben wurde?

Dann könnte man wunderbar in seinem eigenen Aktionsskript beliebige Spielereien mit dem Wert machen, bevor er dann an die Standardaktion weitergereicht wird. Das geht jetzt natürlich auch schon, aber dann muss ich das Aktionsskript jedes Mal explizit auf die Ziel-Instanz zurechtschneiden.

Und noch eine Frage an die (Modul-)Entwickler. Beim Nachlesen der Dokumentationen zu RequestAction() bin ich darüber gestolpert, dass die Methode innerhalb der Module den Ident der Statusvariablen und den Zielwert der Variablen als Parameter erwartet. Wenn ich die Funktion aber für den Variablenzugriff aufrufe, erwartet Sie statt des Idents die Variablen-ID und den Zielwert.

Gibt es innerhalb der Klasse IPSModule eine weitere Methode RequestAction(), die eine andere Signatur hat und die dann die RequestAction() der Unterklasse mit Ident aufruft oder wie hängt das zusammen?

Gruß
Slummi

5

Die haben nicht direkt etwas miteinander zu tun. Das RequestAction an Symcon nimmt die ID und startet die Aktion.
Wenn es eine Instanz-Aktion ist führt Symcon die phpmodule:: RequestAction aus.
Eine direkte Verbindung gibt es nicht.
Michael

6

Ok, dann ist es ja qausi so wie ich dachte. Also wenn die Variable eine Standardaktion hat, ermittelt IPS einfach den Ident und ruft damit dann die Modul-Funktion auf.

Vielleicht gibt es doch schon das, was ich eigentlich suche. Ich habe gerade mal mit der undokumentierten Funktion IPS_RequestAction() rum gespielt. Da ich ja die Statusvariable habe und sowohl deren Ident als auch deren Instanz ermitteln kann, kann mir die Funktion doch auch die ursprüngliche Standardaktion liefern. In einem ersten Test klappt das jedenfalls trotz eigenem Aktionsskript.

Oder gibt es bei der Funktion irgendwelche Fallstricke? Es liegt ja in der Natur der Sache, dass man bei undokumentieren Funktionen nicht viel nachlesen kann. :wink:

Gruß
Slummi