EDOMI - Fragen zur Visuseitenerstellung

[DirtyHarry]

Nein, gibt es nicht - aus gutem Grund: Das wäre quasi eine Totmannsteuerung, die aber nicht unter allen Umständen zuverlässig funktionieren würde (Visualarm, Bildschirmschoner, ggf. Browserabsturz...).

Nicht zuverlässig bedeutet? Es würde die Betätigung unterbrochen werden (Drücken=1, Absturz etc. fällt auf 0 zurück) oder es würde aus der Totmann eine dauerhafte Schaltung machen (Drücken=1, Absturz etc. bleibt auf 1)?

Erste Variante würde ich als hinnehmbar sehen, bei der zweiten Variante ist es natürlich sinnlos.

[gaert]

Die zweite Version würde dann "greifen" - daher: Zu unsicher. Wenn schon Totmann per KNX, dann per retriggern eines Timers (am besten im Aktor).

[Winni]

Animationen sind wie alle anderen dynamischen Designs immer vom KO abhängig. Das {#} kann nur in den hellgrünen Felden verwendet werden, also z.B. nicht(!) bei der Definition eine Animation - wohl aber bei deren Zuweisung (Dauer und Anzahl).

Auf andere interne/externe KOs {ID] oder {1/2/4} kann man aber nicht zugreifen? Wollte grad' einen Pfeil für Windrichtung/stärke basteln, entweder ich kann sich die Stärke auf die Größe auswirken, oder die Richtung auf die Rotation.
Beides krieg ich nur hin, wenn in ich einem LBS wieder was bastle und z.B. mit left() right() trenne. Will nur wissen, ob ich was falsch mache..

[gaert]

Diese Eigenschaften werden immer von 1 KO (das Status-KO des Visuelements) modifiziert. Mehrere KOs können nicht verwendet werden - mit Ausnahme diverser "Spezialitäten" (Diagramme, Webseiten, etc.). Im Normalfall geht {ID} also nicht, sondern "nur" {#}.

[gaert]

By the way: Im nächsten Update kommen diverse KO-Funktionen hinzu - unter anderem auch diese hier:

str_split(pos,separator)

Mit dieser Funktion kann ein KO-Wert in Form eines "Arrays" aufgedröselt werden, z.B. baut ein LBS ein KO "1|2|3" zusammen. str_split(1) würde dann "2" liefern (Index beginnt mit 0). Als Separator wird per Default "|" verwendet, oder es wird ein eigener Separator angegeben: str_split(1,"&")

Was bringt das? Nun, angenommen man möchte wie Winni verschiedene Eigenschaften (Windstärke und -Richtung) in einem(!) KO "transportieren" und dann damit ein Visuelement "füttern" (z.B. Windstärke soll die Größe beeinflussen, Windrichtung die Rotation). Dann baut man sich einen LBS (oder nutzt den vorhandenen LBS zum String-Verbinden) der ein KO z.B. mit "180|23" beschreibt. Im Visuelement gibt man dann bei Größe "{str_split(0)}" an und bei Rotation "{str_split(1)}". Das Ganze funktioniert natürlich auch mit weiteren Parametern, z.B. "1|2|3|...|999"

[Winni]

Super, dann warte ich mit dem Thema noch
Einziger Wermutstropfen: Macht nur bei Anzeigeelementen Sinn, Werte vernünftig setzen ist nicht

[gaert]

Werte vernünftig setzen ist nicht

Wie jetzt?! Dir stehen sämtliche Befehle mit unendlich vielen Möglichkeiten zu Verfügung...

[Winni]

Wie jetzt?! Dir stehen sämtliche Befehle mit unendlich vielen Möglichkeiten zu Verfügung...

Sorry gaert, da hab' ich jetzt etwas einfältig gedacht. Ich hatte nur das Universalelement vor Augen. Bei den anderen habe ich ja die Trennung KO / Status KO. Hab' einfach nicht überlegt. Wär mir sicher aufgefallen, hätte ich gewartet bis man es ausprobieren kann...
Sollte auch nicht unzufrieden rüberkommen, sondern nur ne Feststellung sein, war aber schlicht weg falsch!

[gaert]

Kein Problem

Der Grundgedanke von EDOMI ist maximale Flexibilität, d.h. vieles ist sicher nur über Umwege (aka umständlich) zu erreichen - aber gerade das macht m.E. den Charme aus (im Ergebnis). Flexibilität hat eben ihren Preis und der heißt in diesem Fall: Viel initiale Arbeit. Die Belohnung folgt jedoch auf dem Fuß: Jede Visu ist individuell und größtmöglich an die Bedürfnisse anpassbar. Ich mag eben keine Lösungen von der Stange

Und wenn's irgendwo nicht weitergeht kann man sich relativ einfach (im Vergleich z.b. zum HS) einen LBS basteln - dies ist ausdrücklich gewünscht und konzeptionell so vorgesehen (daher ist auch der LBS-Editor ab Werk dabei). Der größte Nachteil insgesamt ist sicherlich die dürftige Doku - aber ich arbeite heimlich daran

[Winni]

Jetzt muss ich doch nochmal nachhaken: Universalelement, welcher Wert wird für die dynamischen Designs verwendet, wenn ich z.B. unterschiedliche Icons verwenden will? Der erste im Array? Oder muss ich mehrere Universalelemente übereinanderlegen?
Noch eine Frage, die ich glaube schomal gelesen zu haben: Irgendwo kann man die Hintergrundfarbe der Eingabefelder verändern, ich glaube es war irgendwo hart im Code. Ich würde statt dem grün gerne was anderes benutzen...

[gaert]

Arrays gibt es nicht wirklich - es kann nur 1 Status-KO geben und dessen Wert wird für die Auswahl des dynamischen Designs verwendet. Falls du auf die neue Funktion split() anspielst: Dies ist eher für Spezialfälle gedacht, z.B. dein Beispiel mit Windstärke und -richtung. Ein zusätzliches dynamisches Design ist dann nicht mehr sinnvoll möglich, da das KO ja dann ein "Array" enthält...

Die Hintergrundfarbe in der GUI ist in irgendeiner CSS-Datei deklariert - muss ich selbst erstmal suchen

[Winni]

Falls du auf die neue Funktion split() anspielst:

Ja, darum ging's mir. Nur zum Verständnis was ich wieder abbilden möchte: über das Luftbild von meinem Haus möchte ich Windpfeil (Richtung und Größe variabel, Evtl. auch Opazität. Des weiteren wollte ich den Sonnenazimuth darstellen und je nach Elevation die Sonne färben. Transparent nach Untergang geht ja, aber rot einfärben bei < 5 Grad ist schwierig. Ich werd's mal it dem z-index versuchen.... Bin schon gespannt auf die nächsten Version

[gaert]

Du kannst natürlich auch ein paar Elemente überlagen und mit verschiedenen KOs "ansteuern" - muss ja nicht alles in 1 KO gequetscht werden

Ich habe bezüglich der Hintergrundfarbe der GUI-Inputs geguckt: Ist leider keine globale CSS-Deklaration sondern "hart" im Quelltext verankert. Grün bleibt also grün - oder Du änderst dies an allen Stellen im Quelltext manuell

[toggle]

Kann man edomi irgendwie die automatishe Bildschirm-Ausrichtung abgewöhnen? Denn edomi arbeitet mit statischen Designs und ab und zu kommt es vor, dass ein Smartphone/Tablet leicht zur Seite gekippt wird und der Bildschirm sich dreht. Dabei wird das Bild auf volle Breite skaliert und die unteren 3/4 verschwinden hinterm Bildrand.

Ich möchte die Drehung aber nicht grundsätzlich sperren, sondern pro Seite/Anwendung.

[DirtyHarry]

Da Edomi keine eigene App ist, sondern im Browser läuft, gehe ich davon aus, dass es nicht geht.

Es gibt aber eine andere Variante, die mit Sicherheit funktioniert. Ich habe das Drehen normalerweise gesperrt, bei der Anzeige von Bildern möchte ich es aber anhaben. Die App Llama (unter Android, wie es da bei IOs aussieht... Weitere Alternative: Tasker) überwacht nun die Galarie, ob sie läuft und im Vordergrund ist und schaltet währenddessen das Drehen an. Sobald die Galerie beendet wird (oder in den Hintergrund), wird das Drehen wieder ausgeschaltet. In deinem Fall wäre es halt die umgekehrte Variante, wurde aber eigentlich vorraussetzen, dass du den Browser nur für Edomi nutzt.