EDOMI - Fragen zur Visuseitenerstellung

[gaert]

heckmannju
Sorry - Du hast recht. In der Doku steht ja noch so gut wie nichts zur Visu... Habe ich verwechselt mit der alten .txt-"Doku" für die VMs.

[gaert]

Echt? Das wäre ja schick. Dachte nicht, dass da Blockelemente gesondert behandelt werden.

Jepp EDOMI habe ich tatsächlich nicht mal eben so zusammengewurschtelt, sondern quasi jede Zeile gut durchdacht. Alles Überflüssige musste raus etc., damit die Performance so optimal wie möglich ist. Dies jetzt alles zu erklären ginge wohl zu weit - aber man erkennt dies ganz gut im Quelltext: Keine Klassen etc., weil alles Overhead. Das spielt bei einigen Objekten natürlich keine Rolle - aber bei hunderten auf einem iPad 2 durchaus

[Schromie]

heckmannju

Vieles steht in dem Thread Grundlegendes zu Edomi. Hier sind auch die Videos verlinkt, bei denen auch schon so einiges erklärt wird.

Viele Grüße
Sebastian

[DerSeppel]

Jepp EDOMI habe ich tatsächlich nicht mal eben so zusammengewurschtelt, sondern quasi jede Zeile gut durchdacht. Alles Überflüssige musste raus etc., damit die Performance so optimal wie möglich ist. Dies jetzt alles zu erklären ginge wohl zu weit - aber man erkennt dies ganz gut im Quelltext: Keine Klassen etc., weil alles Overhead. Das spielt bei einigen Objekten natürlich keine Rolle - aber bei hunderten auf einem iPad 2 durchaus

Dass das nicht mal eben hin gewurschtelt ist sieht man. Den Eindruck hat auch keiner hier denke ich.
Ich bin eher in der Embedded-Ecke unterwegs, daher bin ich was Web-Technologien an geht nicht immer 100% auf Stand.
Mir fehlt die Erfahrung mit größeren PHP Projekten, aber ist OO wirklich soo unperformant in PHP? Das macht doch sicher nicht mehr als 10% aus, oder?
Ansonsten gerne wieder zurück zum Thema.

[gaert]

Nein, OO ist nicht wirklich unperformant in PHP - aber in der Kombination mit JS etc. durchaus! Klar könnte man tolle Klassen und Objekte bauen in PHP - aber was nützt es, wenn das alles am Ende in JS/HTML/CSS "konvertiert" werden muss. EDOMI besteht im Wesentlichen aus 3 Teilen:

• das reine PHP-Backend: Hauptprozess, KNX-Stack, Logikengine, etc. (läuft wie ein normales C++ Programm ganz stur auf dem Server vor sich hin)
• Apache-PHP-Prozesse: Wie bei jeder dynamischen Website werden diese PHP-Scripte beim Abruf durch den Browser ausgeführt und füttern hauptsächlich via "Ajax" die JS-Scripte im Browser
• JavaScript/HTML: Die Client-Scripte im Browser (also die GUI, Visualisierung, etc.)

Um diese 3 Welten zu verbinden bedarf es einiger Tricks - es sind ja 2-3 verschiedene Sprachen mit unterschiedlichen Möglichkeiten. Allein schon die "Kommunikation" zwischen diesen 3 Welten ist alles andere als trivial: Entweder über Datenbanken oder über Shared-Memory (EDOMI nutzt beides). PHP-Prozesse laufen immer isoliert, d.h. es gibt (bis auf s.o.) keinerlei "Schnittstellen". Man kann also nicht mal eben eine Variable von Script 1 in Script 2 nutzen - oder gar Client-Variablen auf dem Server nutzen... Bei normalen Webapplikationen wird der Datenaustausch i.d.R. per Ajax oder GET-Parametern realisiert, bei EDOMI ist das aber nur die halbe Miete, da die Hauptprozesse mit der Webapplikation nichts am Hut haben...

Du siehst also: Alles nicht so einfach Daher kommt man mit der üblichen "Denke" nicht weit, so von wegen: Ich hab' ne Klasse, instanziere die mal eben und fertig ist Natürlich gibt es ne Menge Frameworks, die etwas in dieser Art nachbilden. Nur leidet die Performance ungemein, da unendlich viel Overhead für alle möglichen Szenarien vorgehalten werden. Und das wollen wir ja nicht - wir wollen ein EDOMI, dass sich 100%tig auf seine Aufgabe konzentriert...

[EPIX]

RGB: Ja, meine DALI-Dimmer brauchen alle einzeln R/G/B. Da ich die im ganzen Haus habe, war ich irgendwie der Annahme erlegen, dass das wohl bei jedem so ist. Bei Dir war's vermutlich genau anders herum. Naja, bei mir auf jeden Fall und so braucht es für die ganzen RGBs doch einige Logik. Vermutlich haben das auch andere Nutzer.
-> Vielleicht könnten man dem VisuElement auch beide Optionen geben, also mit 2 RGB-GA oder auch 6 R/G/B-GA zu sprechen. Das wäre eine große Erleichterung.
-> Und tatsächlich nutze ich recht viel RGBW, also einen 4. Warmweißen-Kanal, da Weiß von RGB wirklich nicht schön ist. Wenn es also auch einen RGBW-Dimmer gäbe, ahne ich, dass auch andere dies gut brauchen können.

Hast du da schon eine funktionierende Lösung?

[Robby]

....bin ich noch Karnevalsgeschädigt oder haben wir wirklich keinen Slider als Dimmer? Ausgabe eines KO´s durch verschieben geht ja aber der umgekehrte Weg??

[gaert]

Slider gibt es nicht - "nur" Drehräder. Slider haben nämlich das Problem, dass diese nicht "endlos" sind, sondern immer einen "Anschlag" haben. Das ist GUI-technisch unpraktisch, da unflexibel! Beispiel: Das Drehrad kannst Du 10x10 Pixel klein machen und es funktioniert noch immer wunderbar. So ein Mini-Slider würde auf dem iPad/etc. nichts taugen.

Auch hier gilt also: Frisches Denken ist gefragt Ich sehe keinerlei Vorteile in Slidern...

[basaltnischl]

Ich finde Slider in manchen Situationen auch besser. Für mich klar ein Vorteil das sie einen Anschlag haben. Läßt sich in evtl. sogar schneller bedienen.
Wer seine Visu so gestaltet (10x10) das er sie nicht mehr bedienen kann, ist doch selber schuld ... oder?

[gaert]

10x10 war natürlich untertrieben, aber 100x50 wäre z.b. recht gängig. Wo ist der Vorteil eines Anschlags?! So ein drehrad unterlege ich immer mit einem Element, dass den Wert grafisch darstellt, z.b. Hintergrundfarbe "Bargraf".

[mwKNX]

Ich finde Slider in manchen Situationen auch besser. Für mich klar ein Vorteil das sie einen Anschlag haben. Läßt sich in evtl. sogar schneller bedienen.
Wer seine Visu so gestaltet (10x10) das er sie nicht mehr bedienen kann, ist doch selber schuld ... oder?

Sehe ich auch so! Aber vielleicht soltle man alte Zöpfe ruhig mal abschneiden

[baumhaus123]

Um ganz ehrlich zu sein würde ich mich auch über einen Slider freuen. Der Dreher ist zwar ein frisches Konzept, aber so richtig konnte ich mich damit noch nicht anfreunden. Mit einem zusätzlichen Slider könnte dann ja jeder verwenden, was ihm gefällt.

[ggt]

In deinem Video Diagramme gibt es für die Aktualisierung die Auswahl „bei Telegramm an KO“. Aktuell ist der nicht (mehr) vorhanden?

edomi Diag Aktualisierung Video.JPG edomi Diag Aktualisierung.JPG

[Robby]

Visu9.png

gaert

Beim HSV Dimmer für meine LED Stripes gebe ich Dir recht das es nichts besseres gibt

Wenn ich jetzt wie auf dem oberen Bild mit einem "Balken" (so nenne ich das mal) den Wert durch schieben verändern könnte fände ich klasse. Ich würde auf einer Seite auf meinem Handy bestimmt 10 Slider drauf bekommen in einer sehr guten Bedienbarkeit. Anders sähe das bei Drehdimmern aus.
Gib dir doch mal nen Ruck...

[2Fast4You78]

Ich brauche keinen Slider... ich wäre schon froh wenn der RGB-Dimmer geht.
Was mache ich denn falsch ?
RGB1.JPG
RGB2.JPG


RGB3.JPG

1/1/50 ist Rückmeldung Helligkeitswert Rot als DPT5
Darunter dann umgekehrt das Setzen der Werte