Edomi

[gaert]

gaert
Hallo Christian, wenn du in der ETS schaust, welche PA siehst du im Monitor wenn du ein Befehl via EDOMI absetzt ?
DANKE.

0.0.1 (so wie in der edomi.ini konfiguriert)

Ich schätze mal, dass mein Router irgendwann auf die 0.0.1 konfiguriert wurde - ist schon lange her...

[MatthiasS]

Das Ergebnis ist eine sehr restriktive Visu ("Mädchen-Visu") - jede Visu sieht quasi gleich aus. Geschmackssache...

Aber wie gesagt: Dies sind alles Ideen, die in Zukunft durchaus implementiert werden könnten - ist nur eine Frage des Fleisses. Ich sehe für mich persönlich jedoch keinen Bedarf...

Auch meine meinung.

[gaert]

Ich liebe auch die Funktionalität, dass nach einer bestimmten Zeit wieder zum Start gesprungen wird, damit ist für jeden Bediener der Startpunkt erstmal sauber definiert, geht sowas in EDOMI auch?

Klar - genau diese Funktionalität bietet ja der "Bildschirmschoner":
Der Name ist vielleicht etwas verwirrend... Das Prinzip ist ganz einfach: Nach einer einstellbaren Zeit der Inaktivität (sprich: keine Klicks) wird die Bildschirmschoner-Seite angezeigt. Diese kann ein Popup sein (damit dieses Popup z.B. beim Anklicken wieder verschwindet und alles beim alten ist), oder auch eine normale Visuseite. Diese normale Visuseite kann z.B. auch die Startseite sein - oder eine Seite mit Codeschloss, oder was auch immer.

Diese Funktion müsste also eigentlich so heißen: "Visuseite (bzw. Popup), die nach einer Zeit X ohne Nutzerinteraktion aufgerufen wird"

Vielleicht noch erwähnenswert in diesem Zusammenhang:
Wenn die Bildschirmschoner-Seite aufgerufen wurde, kann optional eine andere Refreshrate für die Visu angegeben werden. Diese Refreshrate wird dann solange angewendet, bis wieder eine Nutzerinteraktion stattfindet.

Beispiel:
Die Visu aktualisiert sich jede Sekunde. Wird der "Bildschirmschoner" aktiv, wird die Visu nur noch z.B. alle 10 Sekunden aktualisiert (weil ja offenbar eh niemand hinguckt). Dies kann u.U. nützlich sein, um Ressourcen zu sparen (Akku, Netzwerklast, etc.).

Außerdem werden Kamerabilder und Diagramme nicht mehr aktualisiert. Auch dies spart ggf. eine Menge Ressourcen (sowohl auf dem Client, als auch bezüglich der Kamera selbst).

In diesem Zusammenhang vielleicht noch gut zu wissen:
EDOMI lagert nach Möglichkeit alle Berechnungen etc. auf die Visu-Clients aus. Diagramme werden beispielsweise vom Client generiert - der Server liefert nur die Daten. Würde man die Diagramme (z.B. als Bild) auf dem Server generieren, so würde dessen Ressourcenverbrauch mit zunehmender Clientzahl entsprechend wachsen. Daher nutzt EDOMI nach Möglichkeit die Clients für derartige Aufgaben - also quasi ein "verteiltes Rechnen"

[coliflower]

In der Test-Visu ist die Auflösung 768x1004 anstatt 1024 … Ist der Grund die obere iPad Leiste ?

[gaert]

Richtig. Die Statusleiste beansprucht 20 Pixel für sich... Seit iOS 8 (oder 7?) lässt sich diese in einer Webapp nicht mehr komplett ausblenden - leider. Andererseits schadet's ja auch nicht

[henfri]

Hallo Christian,

@henfri:
Ich denke, dass beide Konzepte jeweils Vor- und Nachteile haben. Wie ich schon schrieb, wäre eine "dynamische Visu" (QC-ähnlich) durchaus denkbar - dann müsste prinzipbedingt das Layout aber flexibel bleiben, sprich: Der Client ordnet je nach Bildschirmgröße/Auflösung/Ausrichtung/etc. die Visuelemente passend an.

Jain.
Was ich meine habe ich mal im Anhang dargestellt.

PC:
PC.png
Mobil dann so:
Mobile.png

Natürlich hätte dies den Vorteil, dass man quasi nur eine einzige Visu erstellen muss - den Rest erledigen dann die Clients schon irgendwie. Ich empfinde dies aber als unschön, denn dies wäre mehr oder weniger eine unstrukturierte (bzw. in engen Grenzen vorgegebene) Anordnung. Das Ergebnis kann man im QC schön beobachten: Das Ergebnis ist eine sehr restriktive Visu ("Mädchen-Visu") - jede Visu sieht quasi gleich aus. Geschmackssache...

Ich denke, beide Varianten haben ihre Berechtigung. (Gira wohl auch ;-) Ich würde vermuten, dass die Quad-Client Visu die verbreitetste ist.

Aber wie gesagt: Dies sind alles Ideen, die in Zukunft durchaus implementiert werden könnten - ist nur eine Frage des Fleisses. Ich sehe für mich persönlich jedoch keinen Bedarf... Klar, das Erstellen von 2-3 Visus für PC/iPad/iPhone ist mit viel Arbeit verbunden. Jedoch ist mein Konzept etwas anders: Ich möchte NICHT auf jedem Endgerät ALLE Optionen visualisieren!

Ja, da hast du vollkommen Recht.
Ich denke, ein "Hybrid" zwischen einer dynamischen/adaptiven und einer pixelgenauen Darstellung gut wäre ein guter Kompromiss (wie von mir oben skizziert). So könnte man ohne große Einschränkungen ein Design erstellen, welches auf beider Art Endgeräte nutzbar ist, auch wenn es vielleicht ideal nur auf dem Tablet aussieht.
Zusätzlich kann man ja dezidierte Seiten für das Handy erzeugen.

Ich denke aber, jetzt gibt es erst einmal andere Prioritäten.

Gruß,
Hendrik

[henfri]

O.k. werd ich akzeptieren müssen, aber für mich persönlich ist es unabdingbar, dass man schnell auf z.B. Google-Kalender, Fernsehprogramm oder Dreambox-Timer zugreifen kann. Klar, bei mobilen Devices startet ich ne zweite App und schalte hin und her, bei einem fest verbauten Panel ist das nicht so angenehm.
Mit "Klicki-Bunti" hat das in meinen Augen wenig zu tun, ich denke mein Visu ist da weit weg davon.

Da möchte ich Winni zustimmen.
Es ginge mir hier nicht darum, das Wetter abzufragen, sondern z.B. die Web-Oberfläche von der Musik-Anlage (ob nun Squeezebox, Sonos oder sonstwas) oder das Media-Center einzubinden.

Oben gibt es den Knöppe um z.B. die Szene Musik auszuwählen und unten kann man dann im Web-interface des Zuspielers auswählen, was man hören möchte.

Gruß,
Hendrik

[gaert]

Oben gibt es den Knöppe um z.B. die Szene Musik auszuwählen und unten kann man dann im Web-interface des Zuspielers auswählen, was man hören möchte.

Dies ist dann aber irgendwie "unsauber" - also nicht zu Ende gedacht. Entweder binde ich die Weboberfläche des Gerätes ein - oder ich triggere mit entsprechenden Funktionen per KO diverse Geräteoptionen, bzw. lasse mir per WasAuchImmer-Request die Daten des Geräts anzeigen.

Aber jeder nach seinem Geschmack - keine Frage! Momentan gibt es allerdings wichtigeres (für mich), als derartige Optionen. Denn dies eilt ja nicht, würde ich sagen - die Zukunft kommt ja noch

[gaert]

Zum Thema Visu: Klar, der QC wird sicher gerade bei Anfängern beliebt sein. EDOMI ist "by design" allerdings nichts für Anfänger, bzw. Klick-und-fertig-Visu-Anhänger Aber das kann alles noch kommen - hängt von meiner Zeit und der Nachfrage ab...

By the way: Schön finde ich Deine Beispiele nicht gerade - oder sagen wir mal: Diese versprühen den Charme einer Excel-Tabelle...

[AScherff]

Aehmm...

Ich weiss nicht, ob es bemerkt wurde, aber wir haben edomi ein eigenes Forum "spendiert"....

Ihr könnt natürlich weiter alles um edomi in diesen "all in one"-Fred packen. Dann sind die 1000 Posts ja nicht mehr fern. Oder die Gelegenheit nutzen und weitere Threads auf machen um das thematisch zu teilen...

Viel Spass! ... und Erfolg..

[coliflower]

Yes :-)

[SeatSLF]

Hallo Christian,


Jain.
Was ich meine habe ich mal im Anhang dargestellt.

Das tippst du noch auf einem Handy?

Da mach ich mir lieber auf Handy passende Visu, da muss ich keine Statistiken oder so sehen.
Da gibt es Hauptmenü mit Zimmern und evenutell Meldungsarchive mit gut findbaren Tasten.

Ganz im ernst wie oft ändert sich die Belegung deiner Aktoren oder Dimmer?

[SeatSLF]

Die PA scheint essentiell zu sein - ich habe gerade mal spaßeshalber die 0.0.0 angegeben und erhalte nun genau die erwähnten Fehlermeldungen (3 Versuche, dann Abbruch). Mit der PA 0.0.1 funktioniert es ohne Probleme bei mir.

Die aktuelle KNX-Spec enthält für mich keine neuen Informationen - der Verbindungsaufbau (CONNECTION_REQUEST) und das Tunneling (TUNNEL_REQUEST) ist korrekt implementiert - es funktioniert ja auch mit meinem Router... Vielleicht ist tatsächlich "nur" die PA das Problem?!

Das Hauptproblem bei einer Tunnelverbindung wird immer der Router sein, weil er die Tunnel frei vergibt.
Ist Tunnel 1 besetzt, macht er den zweiten auf usw.
Man müsste nun aufpassen das EDOMI immer den selben Tunnel bekommt,
da sonst wieder die Probleme anfangen.

Es sei den man könnte dem Router eine Art IP Binding beibringen, sodass nur EDOMI mit seiner IP
den Tunnel mit der passenden PA bekommt.

Christian du könntest spaßenshalber mal versuchen EDOMI auszuschalten, warten bis der Tunnel von deinem Router
geschlossen wurde. Dann verbindest du dich mit der ETS auf diesen Tunnel und startest dann EDOMI.
Sodass EDOMI bei dir mal auf einen anderen Tunnel "gezwungen" wird.

[gaert]

Würde ich gerne versuchen - nur leider habe ich es noch nie geschafft mehr als eine Tunnelverbindung gleichzeitig zu etablieren. Auch lange vor EDOMI, mit der ETS, eibd, etc...

Wie gesagt: Meinem Verständnis nach hat man ohnehin keine Tunnelwahl, zumindest gibt die Spec nichts dergleichen her.

[basaltnischl]

Mit der iOS App "T-n-l Web Visu" läßt sich EDOMI auch im Vollbild darstellen.
Das gute an der App man kann nur eine URL angeben.

Wie bekomme ich den gestreiften Hintergrund der Visu Loginseite auch in den normalen Hintergrund?