Bislang unterstützt das BlindControl Modul (Steuerung von Rollläden) noch nicht die neuen Darstellungen.
Hintergrund ist, dass das Modul zur korrekten Steuerung verschiedene Informationen braucht. Es wird
aus den Min und Max Werten des hinterlegten Variablenprofils der Regelbereich abgeleitet und
aus dem Profilzusatz „.reversed“ wird abgeleitet, ob die geöffnet Position beim Min oder beim Max Wert vorliegt
Ähnlich sieht es bei Kontakten aus. Auch hier wird bislang über Min und Max und „.reversed“ ein geöffneter Kontakt erkannt.
Nun zu meiner Frage.
Wie komme ich an die entsprechende Informationen bei den neuen Darstellungen? Irgendwie müsste es über IPS_GetVariable() und IPS_GetPresentationValue() gehen.
Hat da jemand einen Tipp für mich? In der Doku fehlt wohl noch die Beschreibung der entsprechenden Eigenschaften und Funktionen.
Die Situation ist ungleich schwieriger. Bislang musste musste bei der Variable nur prüfen, ob das Standardprofil „VariableProfile“ oder ein benutzerdefiniertes Profil „VariableCustomProfile“ zugeordnet war. Dann bekam man über IPS_GetVariableProfile() die Min/Max und Reversed Informationen.
Nun liegen die Informationen entweder in einer „VariablePresentation“
Zusätzlich besteht die Herausforderung, dass die Attribute zur Bestimmung von Min/Max und Reversed je nach Darstellung anders heißen können. Hier wären es „CLOSE_INSIDE_VALUE“ und „OPEN_OUTSIDE_VALUE“.
Also nicht wirklich trivial und für jede Darstellung (Legacy, Rollladen, Schieberegeler, Schalter etc.) individuell zu lösen und später zu erweitern.
Meinem ersten Eindruck nach fehlt da noch eine Unterstützung.
Du bekommst tatsächlich nur das, was in der Variable abgespeichert ist, die Logik des Zusammensetzens musst du aktuell noch selbst bauen. Ich kann mir aber sehr gut vorstellen, dass wir da nochmal eine Hilfsfunktion bauen, die die berechneten Endwerte ausgibt. Im Endeffekt ist die Logik hier Übersteuerter Wert > Template Wert > Standardwert (IPS_GetPresentation-> presentationParameters), das sollte also bis dahin gut selbst baubar sein.
Da dein BlindControl explizit Rollläden schaltet, müsste es ja eigentlich nur mit der Rollladen-Darstellung (und Legacy) arbeiten können, und die haben ja alle benötigten Parameter.
Bei manch anderen Darstellungen kannst du jetzt natürlich auch ein Minimum und Maximum ableiten, aber manche Darstellungen wie der Schalter haben das einfach gar nicht, du müsstest also für jede Darstellung individuell schauen, wie du diese händelst. Aber wie gesagt, das halte ich in deinem Fall für unproblematisch, da ja alles Rollläden sein sollten
Ja, das wäre gut. Braucht ihr es nicht auch selber für die Einbindungen der Sprachassistenten und auch für die Darstellung der adaptiven Icons? Und bitte auch an das Reversed denken.
Auch den Schieberegler möchte ich unterstützen und die Aufzählung (nutze ich selber). Hinzu kommen die Kontakte, bei denen ich erkennen muss, welche Stellung ‚offen‘ bedeutet Also Schalter sind auch zu unterstützen. Momentan habe ich den Eindruck, dass auch noch nicht alle der genannten Darstellungen eine reversed Darstellung unterstützen.
Momentan ist mir das noch etwas viel. Wann plant ihr, die Sprachassistenten und die adaptiven Icons für die neuen Darstellungen fit zu machen? Ich denke, da könnten wir vielleicht dann parallel eine Lösung finden.
Reversed haben wir nicht vergessen. Viel eher wollen wir in Anwendungsfällen, in denen Reversed Sinn ergibt spezialisierte Darstellungen anbieten anstatt diese in ein Standardformat zu zwingen, dass nicht unbedingt passt. Dafür sind Schieberegler und Rollläden ein schönes Beispiel. Bei Rollläden ist einfach nicht klar, wo auf und wo zu ist, das macht jeder Hersteller anders. Am Ende denkt man als Anwender ja aber auch nicht in „voll“ und „leer“, sondern in „offen“ und „zu“. Bei Lamellen wird es sogar nochmal komplizierter, da diese verschiedene Winkel nach links und rechts haben können.
Der Schieberegler im Gegensatz hat da kein entsprechendes Handling, dann hier gibt es einfach „voll“ und „leer“. Die Intensität einer Lampe braucht kein Reversed, niemand kommt auf die Idee eine Lampe bei 0% volle Helligkeit zu geben und bei 100% aus zu schalten. Wenn hier Anwendungsfälle auftauchen, dann würden wir daher eher schauen, dass wir weitere spezialisierte Darstellungen anbieten, die tatsächlich auch zum Anwendungsfall passen.
Der Schalter ist hier auch ein schönes Beispiel, wo wir noch Darstellungen offen haben. Denn An/Aus matcht sich meiner Meinung nach recht schlecht mit Offen/Zu. Da wollen wir noch eine Darstellung für Türen (Fenster, …) machen. Dort wäre dann natürlich auch wieder eine Auswahl, was nun offen und was geschlossen bedeutet.
Zugegebenerweise waren wir in unseren ganzen Modulen noch nicht dran, das wollen wir aber zur 8.1 natürlich nachholen. Und da würden wir sicherlich auch von so einer Funktion profitieren. Ich gehe aber ganz stark davon aus, dass Rollläden in den Assistenten die Rollladen-Darstellung verwenden müssen, etc.
Adaptive Icons kann sich nun jeder individuell konfigurieren, da es einfach viel mehr Icons und Möglichkeiten gibt. Die Aufgabe würde sich somit in die Konfiguration der Darstellung verlagern, da können jetzt ja auch per Intervall etc. punktuell nur die Icons überschrieben werden, sodass man sich da seine eigene Adaption bauen kann.
Also eine Ablösung für die "~*.Reversed Profile. Da gibt es ja gerade bei den Boolean eine ganze Reihe. Das ist gut.
Lass uns das dann gemeinsam anschauen. Auch Fensterantriebe werden üblicherweise über Rollladenaktoren angetrieben. Und auch in Alexa über „Rollladen“ angesprochen. Also „Alexa, öffne das Fenster Küche“ funktioniert, wenn es einen Rollladen „Fenster Küche“ gibt.
Aber eine Darstellung „Rollladen“ wäre an der Stelle unpassend. Momentan ist es bei uns ein eigenes Profil „Intensity.1.Reversed“.
Ich denke es sollte bei der Alexa Definition nicht zu viele Einschränkungen geben.
Ahh, ja dafür wären dann natürlich neue Darstellung relevant, die es noch nicht gibt. Ob die Sprachassistenten jetzt ein Misshandeln einer Variable für einen anderen Typ unterstützen möchten ist natürlich ein anderes Thema…
Ich sehe das Feature gerade mit einer Mischung aus Faszination, Begeisterung und Entsetzen.
Verstehe ich recht, dass das
sowieso nur in der Kachelvisu funktioniert?
als neue Eigenschaft von Variablen neben den Profilen eingeführt wurde, beides also parallel existiert und berücksichtigt werden muss bis die Profile irgendwann als deprecated raus gekickt werden?
Finde grundsätzlich total toll dass man mehr Optionen hat wie ein Slider aussehen soll, aber dieser Komplexitätszuwachs mit jedem Update + wie viel plötzlich als deprecated gilt, da schwirrt mir etwas der Kopf.
Das WebFront konvertiert Darstellungen auf Profil-Äquivalente um, damit nutzt es sozusagen auch die Darstellungen.
Für den Endnutzer ist mit den neuen Darstellungen meiner Meinung nach einfach alles einfacher und besser. Für Entwickler kann es aber komplizierter werden. Aber auch das nur unter bestimmten Bedingungen. Ein in sich abgeschlossenes Modul definiert einfach anstatt eines Profils eine Darstellung und ist damit fertig, wobei natürlich die Profile noch mittel- bis langfristig nutzbar sein werden. Komplizierter wird es nur, wenn eine Interaktion mit fremden Variablen erfolgen soll, insbesondere wenn man Variablen mit mehreren Darstellungen interagieren möchte. Das ist in @bumaas Beispiel jetzt der Fall. Das Modul soll für Schieberegler, Legacy, Rollladen jeweils den die Rollladen-Position anfahren, was für jede Darstellung halt irgendwie anders läuft. Ich glaube in den meisten Fällen wird es aber lediglich anders, nicht komplizierter.
Das erinnert mich an die Zeit, als ich Mobile Apps entwickeln musste. Wobei aber der frustrierendste Aspekt davon die vielen APIs waren, an denen man sich abarbeitet und die jeweils nach gefühlt 2 Jahren als deprecated erklärt werden und dann muss man alles neu machen.
Wenn das nicht die Richtung ist, in die es geht, sehr gut! Ich finde die neuen Features gut und freue mich, wie lebendig das Produkt IPS ist. Hoffe aber immer, dass die Entwicklung neuer Features nicht irgendwann uneinholbar auf und davon läuft, wenn man „nur“ eine große bestehende Installation pflegt und nicht immer jede Neuerung gleich übernehmen kann
Wenn die Maschine, die man programmiert, aus Stein ist, dann sind Abwärtskompatiblität und der Verzicht auf Breaking Changes ein hohes Gut.
Die Profile funktionieren ja weiterhin, somit ist Abwärtskompatibilität ja gegeben. Bevor wir die irgendwann ganz rausnehmen, werden wir bestimmt auch noch weitere einfache Funktionen zum Konvertieren auf Darstellungen einbauen, damit man im Standardfall auch weiterkommt ohne selbst Hand anzulegen.
Die Profile waren ansonsten seit der 2.0, also 2009, dabei, ich glaube also nicht, dass die Darstellung nur eine saisonale Erscheinung sind, sondern erst einmal bleiben
