EDOMI-Releases/Updates | Aktuell: Version 2.03

[gaert]

Das ist wohl wahr - daran habe ich nicht gedacht Es werden tatsächlich immer die Rohwerte angezeigt (hat Vor- und Nachteile).

Die Umsetzung ist allerdings nicht so trivial (ohne Extra-Feld für die Knopf-Formel): Es könnte ja auch z.B. "{#*5} ist mehr als {#}" in der Beschriftung stehen - welche "Formel" soll der Knopf jetzt anzeigen? Oder stumpf die ganze Beschriftung? (das wäre natürlich schön einfach)

Und eine Extra-Knopf-Formel finde ich irgendwie blöd, weil man dann noch mehr eingeben muss...

Außerdem: Was ist mit den dynamischen Designs? Dort könnte ja theoretisch eine andere Formel in der Beschriftung stehen.

[rdeckard]

Auch von mir ein Danke für die neue Version!

Beim Schieberegler habe ich einen kleinen Schönheitsfehler bemerkt. Die KO-Werte gehen ja beim Dimmen von 0-255. Menschen werden jedoch meist mit Prozentwerten steuern. Deshalb habe ich bei der Beschriftung auch die Formel {round(100/255*#)}% eingegeben. Dies funktioniert auch tadellos.
Problem ist nur, dass während der Schieberegler verschoben wird, Edomi den internen Wert anzeigt. Somit muss man sich da an die eigentlichen Prozentwerte annähern oder kennt es irgendwann mal auswendig (z.B. 26=10%). Denke nicht, dass dies so gewollt ist.
Kannst du bei Gelegenheit den Wert beim Verschieben mit der gleichen Formel, wie bei Beschriftung hinterlegt, ausgeben? (Oder ganz perfekt: ein 2. Feld für nur den Knopf-Wert. Da könnte man nur eine Zahl formatieren oder sogar ganz weglassen und die Beschriftung wäre dann getrennt davon und könnte z.B. umfassender formatiert sein.)

[SeatSLF]

Ich komme da auch nicht weiter. Mit Logik genau wie bei dir SeatSLF Ohne Logik und im Beschriftungsfeld {#/2.55} wird der richtige Wert 0-100 angezeigt aber für Auswahl, grün hinterlegt, dann wieder 0-255.

Is halt für die Optik und die Frauen

[ggt]

Ich komme da auch nicht weiter. Mit Logik genau wie bei dir SeatSLF
Ohne Logik und im Beschriftungsfeld {#/2.55} wird der richtige Wert 0-100 angezeigt aber für Auswahl, grün hinterlegt, dann wieder 0-255 wie im Beitrag #331

[SeatSLF]

Christian wie immer Top Arbeit, jetzt kommt leider ein kleines ABER:

Wenn ich bei den Schiebereglern einstelle, das diese auf den Status warten sollen.
Geht dieses wenn die Antwort vom Bus selber kommt,
ABER kommt die Antwort aus einem internen KO wird dieses nicht "angenommen"

Ich habe in den Logikfunktionen eine Umrechnung von 0-255 in 0-100%.
Die Logik funktioniert, das sehe ich anhand der Live Werte und das die Regler aktualisiert werden wenn ich
eine Leuchte durch einen KNX Taster dimme.

[gaert]

Version 1.18 ist verfügbar!

Wichtig:
Nach dem Update unbedingt das Browser-Fenster neu laden, da einige Javascript-Dateien aktualisiert werden.

ACHTUNG:
Nach dem Update muss das Projekt erneut aktiviert werden!

• bei jeden Start/Neustart werden alle Datenbanken überprüft und optimiert (aber nicht repariert)
  • ggf. werden im FehlerLog ein oder mehrere Einträge erfolgen
• Live-Monitor: das KO wird nun per Auswahldialog angegeben (hier kann ggf. nach einem KO gesucht werden)
• Visueditor:
  • bei einem Klick an eine freie Stelle auf der Arbeitsfläche werden alle Elemente deselektiert
  • wenn mehrere Elemente (oder Gruppen) bewegt werden, wird die Bewegung aller Elemente gemeinsam am Rand der Visuseite gestoppt
  • wenn mehrere Elemente (oder Gruppen) bewegt werden, wird das "Fadenkreuz" in der Größe der Selektion angezeigt
  • beim Bewegen per Tastatur wird auch ein Fadenkreuz angezeigt
  • Gruppen:
    • Gruppen werden jetzt durch einen Rahmen angezeigt
      • dieser Rahmen kann wie jedes andere Element verschoben und markiert werden
      • mit einem Rechtsklick können die Eigenschaften etc. aufgerufen werden
    • Gruppen können nun direkt bewegt werden, auch ohne vorheriges Markieren
    • beim Selektieren eines Elements einer Gruppe wird immer die ganze Gruppe selektiert
    • das Raster wird nun nicht mehr auf Elemente innerhalb einer Gruppe angewendet, wenn die ganze Gruppe bewegt wird
• Logikeditor:
  • bei einem Klick auf eine freie Stelle auf der Arbeitsfläche werden alle Elemente deselektiert
  • die Herstellung einer Verbindung (Ausgang -> Eingang) mit der Maus kann mit einem Links- oder Rechtsklick auf eine freie Stelle auf der Arbeitsfläche abgebrochen werden
• Dimmer, Drehregler, Schieberegler und Tastatureingabe:
  • Drehregler/Schieberegler/Tastatureingabe: Bei Bedarf kann nun ein Status-KO angegeben werden (beim Dimmer war dies bereits möglich)
  • wenn nur eines der beiden KOs angegeben wurde, wird das fehlende KO bei der Projektaktivierung ergänzt (d.h. beide KOs sind dann gleich)
    • soll z.B. nur ein Sollwert (ohne Status-KO) mit einem Schieberegler verändert werden, genügt es dieses KO anzugeben
  • Eigenschaft "Verhalten bei Werteingabe":
    • "KO immmer setzen, auf Status-KO warten":
      • Das KO wird immer gesetzt und anschließend wird auf das Eintreffen des Status-KOs gewartet (das Visuelement ist während dessen gesperrt).
      • Achtung: Unter Umständen sendet der Aktor keinen Status, wenn keine Status-Änderung(!) vorliegt - das Visuelement wartet dann endlos...
    • "KO nur bei Änderung setzen, auf Status-KO warten" (Defaulteinstellung):
      • Bei einer Änderung des KO-Werts wird das KO gesetzt und anschließend auf das Eintreffen des Status-KOs gewartet (das Visuelement ist während dessen gesperrt).
    • "KO immer setzen, nicht auf Status-KO warten"
      • Das KO wird immer gesetzt und das Visuelement kann sofort wieder benutzt werden.
    • "KO nur bei Änderung setzen, nicht auf Status-KO warten"
      • Bei einer Änderung des KO-Werts wird das KO gesetzt und das Visuelement kann sofort wieder benutzt werden.
• Diagramm:
  • Style: Transparenz in Opazität umbenannt (vorhandene Einstellungen bleiben erhalten)
  • die Anzeige der Y-Achse/Legende kann nun wie folgt beeinflusst werden:
    • Y-Achse komplett ausblenden
    • Beschriftung individuell festlegen (wie gehabt)
    • Beschriftung aus dem Daten-Archiv (Name) übernehmen
      

Viel Spaß! Und nicht vergessen: Browser refreshen und Projekt erneut aktivieren!

[saegefisch]

Danke!

[gaert]

Doch, ich habe gelesen (und verstanden)...

Im Prinzip ist Dein Wunsch schon längst implementiert: Designvorlagen. Nur mit gewissen Einschränken: z.B. Größe und Position. Hintergrund: ein "Design" soll unabhängig bleiben, d.h. man soll es z.B. in einem Button aber auch in einem Dimmer universell verwenden können. Übrigens war dies in 1.0 anders: Da habe ich tatsächlich mit "Element-Vorlagen" gespielt, also quasi exakt Deine Wünsche. Hat sich im Gesamtkontext aber als inkonsistent erwiesen, bzw. führte zu einem Mehraufwand, wenn man diese Option NICHT nutzen will.

Instanzierung (oder besser: Indizierung) kann durchaus praktisch sein - aber eben auch sehr unpraktisch. Das hat mich beim HS z.B. immer tierisch genervt, dass ich für jede Kleinigkeit erstmal ein neues "Objekt" definieren muss - einschließlich aussagekräftigen Namen etc.... Ist halt Geschmackssache - ich bevorzuge nunmal den direkten Weg, weil ich meine Visu nicht 10 mal pro Jahr grundlegend ändere, sondern höchstens hier und da etwas ergänze(!)

Alles gut - Du nervst mich nicht!

[saegefisch]

Verstehe ich nicht. Über jquery, frameworks, echte Objektorientierung und 1000 anderen Möglichkeiten, 99% overhead einzubauen habe ich ja gar nicht gesprochen. Natürlich ist alles nur SW und "wäre grundsätzlich kein Problem". Ich will das ja auch nicht! Ich schätze Dein Design! Ich liebe die Geschwindigkeit von edomi. Im Vergleich einer 1-Mutter-mit-x-Kinder-Gruppen-Lösung zu einer x-fach kopierten Gruppen-Lösung wäre die zum Ausführungszeitpunkt auch völlig identisch, da im Endeffekt gleich viele Objekte. Daher habe ich aber auch den Eindruck, Du hast nicht wirklich gelesen, was ich geschrieben habe. Aber egal, darum geht es hier nicht und sollten es vielleicht auch nicht weiter vertiefen, wenn Du es nicht magst. Ich habe eine Idee und habe den Eindruck, in _dieser_ Form wäre es konzeptionell durchaus _schlank_ und passend. Wenn dieser Samen nicht aufgeht, dann ist das auch gut. Es ist Dein Produkt. Und das ist gut so.

Zum Sinn: Ich bin mir recht sicher, dass die meisten Anwender das positiv empfinden würden, wenn man _einen_ Schalter aus x UniELementen designt und 50, 100, 300-fach (das ist bei mehreren Visus durchaus realistisch) einbauen kann. Und wenn der Chef im Haus sich was wünscht oder es sich im Nachhinein herausstellt, die Schalter sollten alle etwas breiter werden für zu dicke Finger auf dem Touch oder etwas anderes, dann kann man das durch eine Änderung an der Muttergruppe lösen. Charmant, wie ich finde. Bei einem Redesign oder Umbau für einen neuen Trend stimme ich Dir zu, aber oft sind es im Prozess einer über die Zeit reifenden Visu kleinere Dinge, aber mit großer Wirkung. Und da wäre das ein Segen - im Vergleich zu 50, 100, 300 manuellen Änderungen an den kopierten Gruppen. Oder einen API zur Massenpflege auf der DB.

Am Ende hilft mir aber eine klare Entscheidung, um mein weiteres Vorgehen bei der Visu-Erstellung zu entscheiden. Und die hast Du getroffen. Alles gut. Sorry, ich will Dir nicht auf den Nerv gehen. Aus dem Gaspacho wird's wohl nix. Ich mag Diskussion und auch mal kontrovers...<schäm>. Werde versuchen, das Thema nicht mehr anzufangen... und freue mich weiter über die wunderbaren Entwicklungen in 1.17ff...

[gaert]

Natürlich "geht" das - ist ja nur Software Aber dieser Gedanke entspricht nicht der Architektur von EDOMI - daher wäre eine Implementierung von Instanzen etc. mit einem kompletten Redesign verbunden. Du siehst ja z.B. bei "Farben" oder "Animationen", dass durchaus instanziert wird - nur sind u.a. die Visuelemente per design nicht mal eben instanzierbar. Dies hat v.a. Performance-Gründe im Gesamtkontext: Es wäre grundsätzlich kein Problem gewesen, EDOMI von Grund auf quasi Objektorientiert zu designen. Mit fetten "Frameworks" a la jQuery dann noch 99% Overhead einbauen und am Ende ruckelt die Visu geschmeidig vor sich hin

Abgesehen davon sehe ich auch wirklich keinen Sinn in diesem Ansatz. Klar, für manche Aufgabenstellungen macht's durchaus Sinn - aber wie oft ändert man das komplette Design seiner Visu wirklich? Oder anders formuliert: Wenn einem das Design der Visu so wichtig ist, dass man "mit der Mode" gehen will, dann dürfte es nicht schwerfallen manuell ein paar Tage lang die Elemente nach dem neuesten Trend anzupassen

[saegefisch]

Völlig andere Kontext: Architektur: viel. Datenmodellierung: intensiv. SW-Design+Realisierung: Viel (auch mal mit parametrisiert-selbstgenerierendem Code). DB: intensiv. Web: ja. WebApps: nein. PHP: nein. Und ja, ich habe mir Dein Coding noch nicht angeschaut, aber ich sehe das SW-Design, die Konzeption, die Chancen die daraus erwachsen. Sonst würde ich meine Zeit nicht mit edomi verbringen und mir mit V1.17 gerade 1 Woche Urlaub wünschen...

Daher bleibe ich bei meinem Gedanken: Am Ende alles eine Frage der DB dahinter, oder? Ob Webapp oder nicht, ist da doch völlig egal. Die API wäre aus meiner Sicht eine mögliche Lösung z.B. für Massenpflege von 200 kopierten Objekten, aber es bliebe nur eine Krücke im Gesamtkonzept.
Wenn aber ein UniElement ID4711 in Gruppe 123 aus seinem Datensatz weiß, dass fast alle seine Parameter nicht aus sich selbst kommen, sondern vom UniElement ID888 aus Gruppe 1 (als "Definitionsgruppe" markiert) und 200 weitere UniElemente das genauso wüsste, wie ID4711. Dann fühlt sich das wie Vererbung an, ist aber keine. Und nur Positionsattribute, Name und KO kämen aus der eigenen Gruppe 123. Fühlt sich an wie Redefinition, ist aber keine. Braucht auch gar keine rekursive Lösung, die eine Stufe wäre schon grandios. Und ist "nur" eine Frage der DB. Und dem VisuEditor, der Gruppen vom Typ "Definition" ermöglicht und Kopien davon, die eben genau diese Relation auf die Definitionsgruppe erzeugt bekommen und die wenigen Attribute aus der eigenen Gruppe dazu mappt.

Vielleicht visionär. Vielleicht liege ich auch völlig falsch. Ich mag ja nur einen Gedanken pflanzen... Ich hätt' ja schon Lust, mal auf ein frischen Gaspacho und ein Wasser vorbei zu kommen und das mit Papier und Bleistift auszudiskutieren...

Am Ende habe ich aber meine Antwort: Es lohnt aktuell noch(?<zwinker>) nicht, auf eine solche Logik zu warten.

[gaert]

Ich weiß durchaus was du meinst und wie das geht Aber daraus wird nix, denn EDOMI ist vollkommen anders strukturiert als du offenbar vermutest. Solche Features ließen sich eher in Form einer API realisieren - dann könnte man EDOMI quasi scripten ("ändere mal alle Farben auf Grün und setze das KO neu und und und"). Mit der Entwicklung von webapps scheinst du nicht besonders vertraut zu sein, oder?! Vergiss Dinge wie Vererbung usw. ganz schnell wieder

[saegefisch]

noch etwas vergessen: Bei den Attributen zur Instanziierung darf natürlich das 1 oder die 2 jeweils passenden KOs nicht fehlen...

<träum> Wenn man das Thema Objektorientierung ganz zu ende denkt, man also bei der Instanziierung alle Parameter veereben und nur gewünschte redefinieren könnte... das wär' aber sicher ein großer Umbau. Aber cool. Denn dann kann man die Visus mit wenig Aufwand im Layout sogar recht umfassend anpassen und hat doch alle Freiheiten im Detail. Aber schon das oben skizzierte ohne echte Objekte, sondern nur einer speziellen Gruppierungserweiterung wäre schon eine weiter große Hilfe - über die frisch geschenkte und wunderbare Gruppierungsfunktion hinaus.</träum>

[saegefisch]

"Exportieren" verstehe ich nicht ganz, was Du meinst.
Meine Frage zielt darauf: Eine Gruppe definiert z.B. eine optisch etwas aufwändigeren Schalter oder Slider aus 4-6 Universalelementen. Die Gruppe möchte ich als Objekt danach z.B. 49 mal verwenden. Die Instantiierung erfolgt durch einen Namen, die Position, Z-index, Skalierungsfaktor (gerne x und x stets gleich, also proportional). Wenn ich morgen das Design ändere möchte, ändere ich nur die eine objekt-definierende Gruppe, alle anderen 49 Verwendungen ändern sich automatisch mit, da sie nur Instanzen sind mit obigen Attribute sind, das Layout in Form aller anderen Paramter also vererbt wird.
Zu technischen Konzeption hatte ich in einem anderen Threat ja schon etwas geschrieben: Ich ahne, eine echte Objektorientierung ist schwierig, aber man könnte die Objekte ja im Backend ganz normal handhaben, nur im Visu-Editor maskiert und entsprechend automatisch adjustiert. Das wäre dann nur eine Frage der DB und des Editors, für alle anderen Komponenten des Backends würde sich nichts ändern

Da in einem Haus gerade für Schalter schnell mal 50 zusammen kommen, ist Gruppe kopieren schon eine andere Nummer. Wenn dann meine Frau fragt, ob ich da nicht mal was ändern mag, wären alle 50 Schalter in den Visus manuell anzupassen. Daher: Instanziierung wäre schon extrem geil... und da geht es mir um Deine Perspektive dazu: Planst Du derlei irgendwann? Oder ist das aus Deine Sicht abstrus oder nicht gewollt/geplant

[gaert]

Du kannst eine Gruppe erstellen, diese auch kopieren etc. (vielleicht irgendwann mal skalieren). Was ich nicht vorhabe ist das "Exportieren" etc. einer Gruppe. Du kannst (schon jetzt) natürlich auch Visu-übergreifend eine Gruppe kopieren! Es gibt nur keine Verwaltung von Gruppen, aber Du kannst Dir ja einfach eine (ungenutzte) Visuseite anlegen und dort die Gruppen "parken"