Wenn dies dein erster Besuch hier ist, lies bitte zuerst die Hilfe - Häufig gestellte Fragen durch. Du musst dich vermutlich registrieren, bevor du Beiträge verfassen kannst. Klicke oben auf 'Registrieren', um den Registrierungsprozess zu starten. Du kannst auch jetzt schon Beiträge lesen. Suche dir einfach das Forum aus, das dich am meisten interessiert.
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
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.
@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.
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.
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
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"
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...
@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.
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...
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!
Beispiel:
Das iPad an der Wand hat bei mir eine andere Bedeutung/Funktion, als das iPhone in der Tasche. Das fest installierte iPad visualisiert so ziemlich alles - während ich mit dem iPhone nur eine sehr abgespeckte Visu nutze. Ganz einfach weil das Display so klein ist... Da machen Grundrisse etc. wenig Sinn - mit dem iPhone möchte ich mit ein paar Buttons einige Lampen schalten, aber nicht in die Analyse des Stromverbrauchs o.d.G. abtauchen.
Soweit ich die Spec verstehe, ist die PA nicht frei wählbar (wie ich ursprünglich dachte) - vielmehr muss dies die PA des Router sein. EDOMI selbst hat ja in diesem Sinne keine PA - EDOMI kommuniziert ja nur per UDP mit dem Router (also auf Network-Ebene).
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?!
Bei mir meldet sich EDOMI in der ETS mit 1.1.201 obwohl in der edomi.ini die 1.0.2 eingetragen ist ...
Sooooo, wenn ich in der edomi.ini anstatt der EDOMI-HOST-PA 1.0.2 die in der ETS5 sichtbare TUNNEL-PA 1.1.201 einstelle, dann funktioniert es.
Mit 1 wird ein-, mit 0 ausgeschaltet …
Kein ERROR LOG mehr ...
Da ist die Frage offen, ist die edomi.ini PA eine HOST- oder TUNNEL-PA (Edomi tunnelt ja die Verbindung zum KNXnet/IP-Router …)
Nochmal: Die Visu muss man sich ABSOLUT STATISCH vorstellen bezüglich der Dimensionen. Festgenagelt eben...
Hintergrund ist, dass ich eine "app-artige" Oberfläche erschaffen wollte: Die Visu soll "an der Wand hängen" oder auf dem Smartphone wie eine Fernbedienung laufen - aber eben OHNE den ganzen Scroll/Zoom/usw.-Kram.
Wenn Bedarf besteht, kann ich dies auch gerne optional implementieren, so dass sich die Visu wie eine normale Website verhält. Mein Anspruch war allerdings, dass ich eine absolut fixe Visu-GUI haben wollte...
Ich habe noch kein Gefühl dafür, wie schnell es mit EDOMI gelingt, eine Visu zu erstellen, aber ich würde mich davor scheuen, zwei Visus (eine für Handys, eine für PC/Tablet zu erstellen. Dabei geht es nicht nur um die damit verbundene Arbeit/Zeit, sondern auch um die Konsistenz. Schnell vergisst man, eine Änderung auch für die jeweils andere Visu einzupflegen und dann leidet die Nutzbarkeit, weil man sich nicht mehr zurechtfindet.
Auch wenn Handys mittlerweile auch 1080p darstellen können... Die Finger skalieren nicht, daher wäre das nötig (oder wie machst du das?)
Ich denke, Gira hat das mit den Quadranten gut gelöst.
Wenn man die Visu in Quadranten aufteilt, die dann auf dem Mobilgerät untereinander dargestellt werden, während sie auf dem PC neben/untereinander dargestellt werden, wäre das doch ein sehr guter Kompromiss.
Wir verarbeiten personenbezogene Daten über die Nutzer unserer Website mithilfe von Cookies und anderen Technologien, um unsere Dienste bereitzustellen. Weitere Informationen findest Du in unserer Datenschutzerklärung.
Indem Du unten auf "ICH stimme zu" klickst, stimmst Du unserer Datenschutzerklärung und unseren persönlichen Datenverarbeitungs- und Cookie-Praktiken zu, wie darin beschrieben. Du erkennst außerdem an, dass dieses Forum möglicherweise außerhalb Deines Landes gehostet wird und bist damit einverstanden, dass Deine Daten in dem Land, in dem dieses Forum gehostet wird, gesammelt, gespeichert und verarbeitet werden.
Einen Kommentar schreiben: