EDOMI - Fragen zur Visuseitenerstellung

[SeatSLF]

3tes Feld ist doch Müll, wenn man es 1-2 mal gemacht hat funzt es

[gaert]

Wenigstens einer mit Sinn für Ästhetik

[SeatSLF]

Wenn man manches erstmal verstanden hat, hat edomi enorme Vorteile gegenüber den bisherigen Server/Visu

[gaert]

Ich versuche halt hier und da alte Zöpfe abzuschneiden (Apple-geprägt). Einiges erschließt sich daher nicht auf den ersten Blick, aber insgesamt denke ich, dass ein frisches Denken/Design durchaus vorteilhaft sein kann. Oder will jemand wirklich Dialoge wie: Abbrechen, übernehmen, Ok

[SeatSLF]

Man kann auf Apple schimpfen wie man will, aber das UI ist das beste.

[rdeckard]

Generische Popups

Ich komme jetzt auch auf das hier beschriebene Bedürfnis zurück:
https://knx-user-forum.de/forum/proje...757#post905757

Ich möchte nun die Einzelsteuerung meiner 15 Jalousien in Angriff nehmen. Mit Fahren/Schrittweise und evtl. Statusanzeige braucht das jeweils viel Platz (vorallem auf einem Handy). Deshalb möchte ich dies immer über ein Popup lösen. Klar, ich könnte jetzt ein Popup definieren und dann 14x kopieren und dann die Elemente/KO's anpassen.
Aber irgendwie finde ich das (als Informatiker) ineffizient. In der Zeit von objektorientierter Programmierung wäre es bei gleichbleibenden Elementen eigentlich immer sinnvoller, wenn man nur die sich ändernden Werte (Variablen) übergeben könnte.
Problem ist vermutlich, dass in einem Popup natürlich x verschiedene Visu-Elemente mit unterschiedlichen KO's existieren können. Wie will man diese allle mit Variablen füttern? In meinem Beispiel hätte ich ja sicher schon 4+ GA's (Jalousie fahren, Schrittweise/Stop, Status Lamellen, Status Höhe etc.) pro Popup. Ist also glaub nicht ganz so trivial.
Da ich aber auch bei der Lichtsteuerung (Dimmer auf Popup) auf das gleiche "Problem" stosse und dort wesentlich mehr Leuchten zu steuern sind, wäre es sicher zu diskutieren, was man hier machen könnte.

Wie gesagt, x gleiche Popups mehrfach zu erstellen ist zwar etwas unschön, aber wäre jetzt nicht das Hauptproblem. Die anschliessende Klickorgie mit dem Anpassen aber schon.

Zudem ein weiterer gravierender Nachteil: Möchte man später mal die Popups ändern, so muss man dies in ALLEN Popups manuell nachführen. (Etwas ähnliches wie die schon sehr praktischen Designvorlagen wäre optimal.)

[SeatSLF]

Kannst du nicht einiges davon mit Szenen ersetzen?

So das du nur noch eine "Hauptsteuer" Seite hättest in der du einstellst und speicherst und dann auf den eigentlichen Seiten
nur noch die Szenen abrufst?

[gaert]

So ist das Grundkonzept der Visu nunmal - dies ist der Preis der Freiheit Wie will man das auch anderes lösen?! Du möchtest "Objektorientierte Popups", ein anderer will "Quadranten", der nächste "Objektorientierte Quadranten", und wieder jemand will das alles gar nicht... Es ist ganz einfach nicht lösbar mit vertretbaren Aufwand. Aber: EDOMI ist hinsichtlich der GUI bereits quelloffen, natürlich fehlt noch eine Doku/API. Es spricht aber (in Zukunft) nichts dagegen, z.B. eine Art "Makro-Schnittstelle" zu erschaffen. Ähnlich wie in Photoshop, Blender oder Word könnte man quasi Scripte basteln und "teilen", die bestimmte Aufgaben erledigen - z.B. 20 Popups generieren, die entsprechend konfigurierte Elemente enthalten usw.

[rdeckard]

So eine "Makro-Schnittstelle" in der Zukunft wäre sicher nicht das Dümmste. Denn du wirst nie alle Bedürfnisse abdecken können.

Zudem muss ich ehrlicherweise auch zugeben, dass wenn man mal die Visu erstellt hat, dann ändert man wohl nicht mehr an allem rum ("Oh, jetzt ist die Flat Design Welle wieder vorbei und Skeuomorphismus ist cool."). Vielleicht ergänzt man neue Funktionen oder lässt etwas weg.
Somit ist dieser ganze Aufwand eher eine einmalige Geschichte. Und auch wenn natürlich jeder mehr Komfort bevorzugt und nicht gerne unnötig Freizeit für manuelles, repetives Rumgeklicke opfern möchte, so ist dieser einmalige Aufwand glaub zu verschmerzen. (Was natürlich nicht heisst, dass ein Entwickler nicht auch nach Lösungen suchen darf, die die Arbeit mit seinem Programm vereinfacht.)

Problem ist halt in der Anfangsphase auch, dass man da noch sehr viel am Rumprobieren bezüglich Design und Funktionalität ist. Es ist wohl ein Unterschied, ob ein Edomi-Anfänger 15 Popups für seine Jalousien-Steuerung erstellt, oder einer, der schon viele Stunden mit Edomi verbracht hat. Deshalb sollte man am Anfang lieber nur mit einzelnen Funktionen (1-2 Fenster etc.) spielen, bis es einem wirklich gefällt. Und dann kann man es duplizieren (und nie mehr antasten...hehe).
Leider ist man gerade am Anfang so begeistert, dass man beim Testen natürlich immer mehr bedienen möchte und nicht nur 1-2 Lichter/Rolladen etc.
Also mir ergeht es zurzeit so. Ich kann schon alle Leuchten steuern (ohne Dimmen) und es ist somit auch für meine Frau voll produktiv einsetzbar (ihr gefällts schon jetzt sehr!). Aber das ganze Design werde ich noch ändern und vorallem dann für meine beiden Wand-iPads umstellen.

Egal..die meisten müssen da wohl durch

Wenn ich bedenke, dass Edomi eigentlich ein Freizeit-Projekt ist, so bin ich einfach begeistert über die Möglichkeiten. Ich kann zurzeit (fast) alles machen, was ich mir vorgestellt habe. Natürlich habe ich weitere Wünsche und die Bedienung ist nicht immer effizient. Aber ich fordere nichts, denn ich weiss, dass alles viel Arbeit für Christian ist. Ich freue mich einfach über neue Funktionen und lass mich überraschen.

Und nie vergessen...Edomi ist kostenlos und erst seit ein paar Wochen öffentlich erhältlich! (Und es ist eine Web App, was technisch etwas limitierend sein kann.)

[rdeckard]

Kannst du nicht einiges davon mit Szenen ersetzen?

Ich werde später sicher vieles über Szenen regeln (Lichter) und die Jalousien mehrheitlich über die Wetterstation steuern. Ist ja auch der Sinn eines Smart Home.

Aber da ich bei den physischen Taster bewusst nur wenige verbaut habe, kann ich zurzeit (ohne) Visu) nicht alle Jalousien/Leuchten steuern. (Also abgsehen vom Knopf drücken am Aktor im Keller, was aber beim Testen sehr mühsam ist.)

Deshalb war die Visu für mich mal sehr wichtig, dass ich ALLES im Haus einzeln über das Handy steuern kann. Halt wie ein übergrosser Taster.
Ich muss z.B. noch die Laufzeiten meiner Jalousien eingeben und da ist es sehr praktisch, wenn ich einfach mit der Visu die einzelnen Fenster steuern kann.
Dass das später eher selten vorkommen wir, ist mir schon klar. Aber ich muss es trotzdem in der Visu drin haben. Das ist wie eine Advanced View.
Für die späteren, normalen täglichen Steuerungen wird es wohl über Szenen gehen.

Wenn jemand im Haus schon sehr viele Taster verbaut hat, wo er vieles einzeln steuern kann, der wird wohl in der Visu nicht nochmals alles abbilden wollen. Ist halt immer eine individuelle Angelegenheit.

[Robby]

Verstehe ich nicht? Die Dimmer "sprechen" direkt mit den entsprechenden GAs - da braucht's keine Logik.

Hier siehst Du ein Beispiel (HSV):
Die 0/1/60 ist die Status-GA meines HSV-Aktors (MDT) - DPT232.
Die 0/0/60 ist die GA zum Setzen eines HSV-Wertes - auch DPT232.
Eine Logik ist nicht erforderlich!

[ATTACH=CONFIG]n907477[/ATTACH]

Habe auch einen RGBW Dimmer von MDT....für das eingebaute Relais bräuchste ich ja auch noch eine Gruppenadresse in deinem Dimmer Plugin...wie hast Du das denn bei Dir gelöst oder schaltest du das Relais nicht aus?

Der Android-Browser (Chrome?!) hat ein Problem mit dem onTouchMove-Event in Javascript (https://code.google.com/p/android/issues/detail?id=5491).

Es gibt Workarounds dafür - ich habe aber kein Android-Device zum Testen... Der Browser hält sich ganz einfach nicht an die Webkit-Norm in der Android-Version - auf dem Desktop-Chrome klappt's hingegen (zumindest per Maus).

Leider weiß ich nicht so recht wie ich vorgehen muss um meinem Android Browser klar zu machen das er den Zeiger beim Dimmer Plugin bewegen kann.
Vielleicht weiß ja jemand Rat und kann es mir erklären. Denke doch mal das ich nicht der Einzige mit Android bin der auch gerne Dimmen möchte.

[toggle]

Ich bekomme ein paar Details in den Diagrammen irgendwie nicht in den Griff.

1. Der standardmäßig eingestellte Wertebereich ist für meinen Geschmack zu groß - bei der Zimmertemperatur wird der Bereich 0-30 (°C) angezeigt, obwohl sich die Werte um die 21°C bewegen. Eingabe von Min-/Max-Werten in der Konfiguration ("Diagrammdatenquelle") scheint keine Wirkung zu haben (v1.15). Muss das noch irgendwo freigegeben werden?
2. In einem Diagramm wird das Symbol Ø dauerhaft am rechten Ende der Temperaturkurve angezeigt. Was bedeutet es? Ein anderes, scheinbar identisch konfiguriertes Diagramm hat kein solches Symbol.

[vento66]

Was das bedeutet? Du bist zu faul zum suchen!

[toggle]

Wenn man Durchschnitt falsch schreibt, dann findet man auch nix.

[gaert]

@robby
das Relais beim MDT schaltet automatisch aus, sobald ein HSV-Wert xxxx00 am Aktor ankommt. Und automatisch ein, wenn der V-Wert > 0 ist. Für andere Aktoren oder was auch immer hilft eine Logik