KNX Controller (Android)

[avajon]

Die IP ist 192.168.132.40. Die IP des Android ist 192.168.132.100,


Verstehe die Frage nicht. Das Motorola XOOM ist ein Tablett-PC, ohne GMS, nur WIFI. Kann das das Problem sein ?

lg
Roland

stimmt, das hatte ich leider vergessen. Ich hab damit gemeint, ob es im selben Netz ist, aber das tut's ja. sehr komisch.

Heute bringe ich noch eine Version raus; aber bei der nächsten (kommt wahrscheinlich am wochenende) werde ich eine Art Testseite einbauen, auf der man seine Einstellungen verändern und testen kann. Vielleicht muss man da etwas ändern. Ich schau dass es so "flexibel" wie möglich wird.

Was ich dir noch anbieten kann, ist, dass ich versuche den Kontakt mit dem User, der den selben KNX/IP Router hat wie du, herzustellen. Also ich würde ihm deine Kontaktdaten geben und fragen ob er dir helfen kann/will. okay? vielleicht hilft das ja.

lg
markus

[Saturn61]

Wichtig, du musst nur die IP intern und Port intern angeben. Port ist normalerweise 3671. Wie sieht denn die IP aus?

Die IP ist 192.168.132.40. Die IP des Android ist 192.168.132.100,

Kommst du mit dem Telefon dort hin?

Verstehe die Frage nicht. Das Motorola XOOM ist ein Tablett-PC, ohne GMS, nur WIFI. Kann das das Problem sein ?

lg
Roland

[avajon]

Ja, das ist OK


Hier würde ich noch einen Parameter mit einfügen ob der Status beim Start gelesen werden soll, siehe Punkt 8.


Ja, ist OK


Ja, so gets.

Gruß
Roland

Solltest du vielleicht nochmal überdenken. Grundsätzlich ist es ja nicht falsch die Gruppenadressen beim Start zu lesen. Mann sollte nur die Problemfälle ausschließen können.

lg
Roland

stimmt... werde ich mir nochmal anschauen wo/wie ich es am Besten einbaue. Werde es mal in meiner Taskliste notieren. Danke für die Tipps!

lg
markus

[Saturn61]

Den Parameter kann ich noch hinzufügen - aber wenn dann würd ich das global machen, also pro Projekt und nicht auf Gruppenadressen-Ebene.

Solltest du vielleicht nochmal überdenken. Grundsätzlich ist es ja nicht falsch die Gruppenadressen beim Start zu lesen. Mann sollte nur die Problemfälle ausschließen können.

lg
Roland

[avajon]

Hier würde ich noch einen Parameter mit einfügen ob der Status beim Start gelesen werden soll, siehe Punkt 8.

Den Parameter kann ich noch hinzufügen - aber wenn dann würd ich das global machen, also pro Projekt und nicht auf Gruppenadressen-Ebene.

lg
markus

[Saturn61]

1.) Beim definieren einer Gruppenadresse (egal ob schalt oder dimmen) kann man zusätzlich noch eine Status-Gruppenaddresse definieren. Das ist aber optional.

Ja, das ist OK

2.) Beim starten der App schicke ich auf alle Status-Gruppenaddressen ein Read-Command.

Hier würde ich noch einen Parameter mit einfügen ob der Status beim Start gelesen werden soll, siehe Punkt 8.

2.1.) Wenn keine Status-Gruppenadresse eingetragen ist verwende ich für den Read Command die eigentliche Schalt-/Dimm Gruppenadresse.

Ja, ist OK

2.2.) (noch nicht implementiert) die App wird ja alle Telegramme mitbekommen und auf diejenigen "reagieren" die eben in der App definiert wurden. Meine "Wahrheit" über den Status wäre somit der letzte Wert der für eine Gruppenadresse gekommen ist - egal ob über die Schalt-Adresse oder Status-Adresse.

Da liegt es dann ja am Nutzer ob und wie er mit Rückmeldeobjekten arbeitet, oder? In meinem Fall hätt's ja vorher auch schon funktioniert, da es keine Rückmeldeobjekte gibt.

Ja, so gets.

Gruß
Roland

[avajon]

Nein bis jetzt nicht. Habe nochmal die IP/Port überprüft.
Habe beim Anlegen des Projektes die Fehlermeldung "Invalid Argument" erhalten. Direkt danach kam die Meldung "KNX Verbindung konnte nicht hergestellt werden". Beim Versuch einen Taster zu Schalten gab es wieder einen Absturz. Habe die Meldung gesendet, hoffe ich.

lg
Roland

Invalid Argument klingt irgendwie komisch, kann mich nicht erinnern diese Meldung eingebaut zu haben.
Wichtig, du musst nur die IP intern und Port intern angeben. Port ist normalerweise 3671. Wie sieht denn die IP aus? Kommst du mit dem Telefon dort hin?

Naja, wenn die App sich gar nicht zum Bus verbinden konnte, dann stürtzt sie gerne ab wenn man dann irgendwo auf einen Schalter/Dimmer klickt.

lg + viel Glück noch.
markus

[Saturn61]

Wie geht's eigentlich mit dem Router? Konntest die Verbindung schon herstellen?

Nein bis jetzt nicht. Habe nochmal die IP/Port überprüft.
Habe beim Anlegen des Projektes die Fehlermeldung "Invalid Argument" erhalten. Direkt danach kam die Meldung "KNX Verbindung konnte nicht hergestellt werden". Beim Versuch einen Taster zu Schalten gab es wieder einen Absturz. Habe die Meldung gesendet, hoffe ich.

lg
Roland

[avajon]

Habe gesehen das es hier wohl Unklarheiten gibt bezüglich Gruppenadressen und Statusobjekte.

1. Grundsätzlich muss man wissen das der KNX-Bus eine Multicast Adressierung verwendet und Event gesteuert ist, z.B. Taster sendet den Wert 1 an Schaltaktor für Licht ein. Der Schaltaktor kann dann zurücksenden eine 1 für Licht ist eingeschaltet. Diese Rückmeldung wird aktiv von der Schaltaktor-Applikation zurückgesendet. Hier legt der Ersteller der Applikation fest ob und wie eine Rückmeldung erfolgen kann.

2. Das Read auf eine Gruppenadresse hingegen wird vom jeweiligen KNX-Stack zurückgesendet. Die Implementierung ist für den Stack-Hersteller Pficht. Der Ersteller der Applikation kann über Flags ggf. nur festlegen ob ein Read auf ein Objekt erlaubt ist. In der Regel dann über die ETS aktivierbar.

3. Das Read-Telegramm wird von der Applikation nicht von einem Write-Telegramm unterschieden. Beide setzen in der Objektstruktur des KNX ein Update-Flag und schreiben den Wert in das Objekt. Dies ist wichtig zu wissen, das die Antwort auf ein Objekt-Read kaum von einem Objekt-Write zu unterscheiden ist.

4. Visualisierungen haben hier oft ein Problem da der Status permanent angezeigt werden soll. Hierzu sind die Schaltbefehle als auch die Rückmeldungen heranzuziehen. Die Frage ist hier, welche Wahrheit will man anzeigen. Es gibt eigentlich drei Zustände für eine Lampe, EIN, AUS und undefiniert. Beim Start einer Visualiserung ist der Zustand zunächst undefiniert. Erst mit dem ersten eintreffenden Schalttelegramm ist der Zustand definiert EIN oder AUS.

5. Status ist nicht Status. Normalerweise zeigt die Statusanzeige eines Tasters an ob die Lampe Ein- oder Ausgeschaltet ist. Dumm nur, das eine Lampe über mehrere Gruppenadressen geschaltet werden kann. Man spricht von überlappenden Schaltgruppen, z.B. zwei einzeln schaltbare Lampen und ein Zentral-EIN/AUS. Die Zentralschaltung erfolgt in der Regel über eine dritte Gruppenadresse. Wenn nun der Status der Lampen an jeweils einer der ersten Lampen hängt wirds kritisch. Eingeschaltet über jeweils die Einzelgruppenadresse zeigt der Status an den Tastern EIN, ausgeschaltet über Zentral, schon ist's passiert, die Taster zeigen Status EIN, obwohl die Lampen beide aus sind.

6. Aktive Rückmeldung über Rückmeldegruppenadresse heisst hier die Lösung. Die Applikation meldet aktiv den Schaltvorgang zurück. Es wird hierfür dann eine eigene Rückmeldegruppenadresse verwendet. Wird nun im obigen Beispiel eine 4. und 5. Gruppenadresse als Rückmeldung auf die Einzeltaster verwendet, so können die Taster jeweils den richtigen Zustand der Lampe wiedergeben auch wenn diese nicht von den Einzeltastern eingeschaltet wurden. Oft werden hier wegen der einfacheren Konfiguartion in der ETS separate Rückmeldeobjekte verwendet.

7. Problemfall Dimmaktoren. Die Dimmaktoren haben nach KNX-Spezifikation mindestens 3 Objekte, ein Schaltobjekt, ein Dimmobjekt und ein Werteobjekt. Das Schaltobjekt hat zwei Funktionen, EIN-Aus-schalten als auch den Schaltzustand senden. Der Schaltzustand wird auch gesendet, wenn der Dimmaktor aussgeschaltet war und über ein Dimm- oder Wertetelegramm eingeschaltet wurde. Habe ich jetzt mehr als einen Dimmaktor in der Gruppe und ich sende z.B. 50% auf das Werteobjekt, so schaltet der Dimmaktor ein und dimmt auf 50%. Das Einschalten wird jetzt über das Schaltobjekt auf alle Dimmaktoren in der Gruppe gesendet und alle schalten auf 100%. Da das Schalten nach KNX EIS2 Spezifikation auch Rückgemeldet werden muss kommt es zum Lawineneffekt. Daher haben heute fasst alle Dimmaktoren ein separates Rückmeldeobjekt.

8. Statuslesen bei Programmstart. Grundsätzlich haben alle Visualisierungen das Problem, das der Status mit dem Programmstart gelesen werden muss. Dies macht nicht immer Sinn und kann ggf. sogar eine Funktion auslösen, siehe Beispiel oben mit dem Dimmaktor. Bei Jalousieaktoren macht es z.B. keinen Sinn da der Status nur Auf oder Zu wiedergeben kann. Der Status einer Jalousie die nur halb gefahren ist kann nicht wiedergegeben werden (es sei denn der Jalousieaktor hat auch ein Werteobjekt). Das unbedarfte Lesen kann so auch eine Funktion auslösen. Der Jalousieaktor auf 50% könnte durch das Lesen des BEWEG-Objektes sogar seine Fahrt fortsetzen. Werden viele Gruppenadressen verwendet, so kann das Lesen aller gleichzeitig ebenfalls Probleme in den Gateways verursachen wenn alle Rückmeldungen auch gleichzeitig empfangen werden müssen.

9. Implementierungsvorschlag:
Die Rückmeldung sollte parametrierbar sein, z.B. Taster, Anzeige des Schaltbefehls, Anzeige eines Rückmeldeobjektes (separate Gruppenandresse), keine Statusanzeige solange kein gültiger Wert vorliegt.
Bei Initialisierung: die Rückmeldung lesen, auf erste Rückmeldung warten, Zeitverzögerung für Lesen Rückmeldung.
Beim Dimmem will man oft den Status einer Lampe auf einen Blick sehen. Da empfielt es sich eine Balken- oder Prozentanzeige anzuzeigen. Ggf. noch kombiniert mit einer Leuchte die heller und dunkler wird. Die Dimmanzeige sollte zwei Objekte haben, eine für den Helligkeitswert und eine für den Schaltwert. Grundsätzlich ist der Helligkeitswert in % zu übernehmen, Empfang auf dem Schaltobjekt setzt entsprechen 0% oder 100%.

10. Die optimale Implementierung für einen Dimmer hat 3 Elemente und 5 Objekte.
Elemente: 1. Taster Aus/AB, 2. Taster Ein/Auf, 3. Schieberegler 0-100%. Die Beiden Taster gehören zusammen und haben gemeinsam ein Schaltobjekt, ein Rückmeldeobjekt und ein Dimmobjekt. Analog zum Verhalten richtiger KNX-Taster kurze Betätigung sendet EIN bzw. AUS, lange Betätigung (und halten) größer 0,6 Sekunden sendet Dimm-Auf bzw. DIM-Ab, mit dem Loslassen wird Dimm-Stop gesendet.
Der Schieberegler sendet nach Verstellung und loslassen den entsprechenden Prozentwert. Die Elemente Taster und Schieberegler müssen nicht zwingend kombiniert werden. Vorrausgesetzt entsprechend verbundene Rückmeldeobjekte bei den Dimmaktoren sorgen dafür das der Status der Taster und des Schiebereglers entspreched aktualisiert werden.


Ich hoffe ich konnte mit diesem Beitrag etwas Licht in dieses schwierige Thema bringen.

lg
Roland

Hallo Roland,

vielen Dank für die ausführliche Beschreibung! Ich habe gestern bereits mit der Implementierung angefangen und werde heute vielleicht noch fertig. Meine Idee ist folgende:
1.) Beim definieren einer Gruppenadresse (egal ob schalt oder dimmen) kann man zusätzlich noch eine Status-Gruppenaddresse definieren. Das ist aber optional.
2.) Beim starten der App schicke ich auf alle Status-Gruppenaddressen ein Read-Command.
2.1.) Wenn keine Status-Gruppenadresse eingetragen ist verwende ich für den Read Command die eigentliche Schalt-/Dimm Gruppenadresse.
2.2.) (noch nicht implementiert) die App wird ja alle Telegramme mitbekommen und auf diejenigen "reagieren" die eben in der App definiert wurden. Meine "Wahrheit" über den Status wäre somit der letzte Wert der für eine Gruppenadresse gekommen ist - egal ob über die Schalt-Adresse oder Status-Adresse.

Da liegt es dann ja am Nutzer ob und wie er mit Rückmeldeobjekten arbeitet, oder? In meinem Fall hätt's ja vorher auch schon funktioniert, da es keine Rückmeldeobjekte gibt.

Wie geht's eigentlich mit dem Router? Konntest die Verbindung schon herstellen?
lg
markus

[avajon]

Na OK ... ich bin froh, dass ihr das macht und ich nicht Java auch noch lernen muss ;-)

Folgende Dinge wären für mich auch noch interessant:
- Verteilung auf mehrere Endgeräte, z.B. ich erstellt die Visu auf meinem Handy und meine Frau muss sich nur noch mit mir synchronisieren.
- Anwender Version, also ich kann die Handy Visu erstellen, meine Frau nur anwenden.

Ist was in die Richtung auch angedacht?

also zu 1) das geht bereits. zwar nicht so wie du es beschrieben hast, aber in der aktuellen Version kannst du ein Projekt mit irgendeinem beliebigen Texteditor bauen und dann auf den Android Geräten importieren.
ad 2) versteh ich nicht ganz. Sag deiner Frau (nachdem du ihr das Projekt importiert hast) sie braucht nur im ersten Tab ("Räume") die Lichter/Jalousien bedienen.... Hmm. oder ich hab die Frage nicht verstanden

lg
markus

[mclb]

Na OK ... ich bin froh, dass ihr das macht und ich nicht Java auch noch lernen muss ;-)

Folgende Dinge wären für mich auch noch interessant:
- Verteilung auf mehrere Endgeräte, z.B. ich erstellt die Visu auf meinem Handy und meine Frau muss sich nur noch mit mir synchronisieren.
- Anwender Version, also ich kann die Handy Visu erstellen, meine Frau nur anwenden.

Ist was in die Richtung auch angedacht?

[kobza]

Wieso baut ihr eigentlich jeder eure eigene App statt zu versuchen eine App so hinzukriegen, dass all damit glücklich sind?

Mein Wunsch wäre z.B. bestimmte Funktionen (z.B. aktueller Status des Hauses, Garage öffnen/schließen, usw.) als Widget definieren zu können. Ist sowas geplant?


Gesendet von meinem Galaxy Nexus mit Tapatalk

Ich baue meine eigene APP weil es mir Spaß macht zu programmieren :-)
Allerding wollte ich die App (vorerst) auf mein Haus/Projekt abstimmen.

Bisher (in den ersten 2 Tagen) habe ich den Buszugriff hingerkriegt, danke noch mal an Makrus, jetzt bin ich dabei eigene Buttons für Licht, Rollos usw. einzubauen,
und allgemeint das Design zu bestimmen.

Üner ein Widget für Status Objekte habe ich auch schon nachgedacht.

Gruß
Thomas

[Saturn61]

Exkurs Gruppenadressen / Statusobjekte

Habe gesehen das es hier wohl Unklarheiten gibt bezüglich Gruppenadressen und Statusobjekte.

1. Grundsätzlich muss man wissen das der KNX-Bus eine Multicast Adressierung verwendet und Event gesteuert ist, z.B. Taster sendet den Wert 1 an Schaltaktor für Licht ein. Der Schaltaktor kann dann zurücksenden eine 1 für Licht ist eingeschaltet. Diese Rückmeldung wird aktiv von der Schaltaktor-Applikation zurückgesendet. Hier legt der Ersteller der Applikation fest ob und wie eine Rückmeldung erfolgen kann.

2. Das Read auf eine Gruppenadresse hingegen wird vom jeweiligen KNX-Stack zurückgesendet. Die Implementierung ist für den Stack-Hersteller Pficht. Der Ersteller der Applikation kann über Flags ggf. nur festlegen ob ein Read auf ein Objekt erlaubt ist. In der Regel dann über die ETS aktivierbar.

3. Das Read-Telegramm wird von der Applikation nicht von einem Write-Telegramm unterschieden. Beide setzen in der Objektstruktur des KNX ein Update-Flag und schreiben den Wert in das Objekt. Dies ist wichtig zu wissen, das die Antwort auf ein Objekt-Read kaum von einem Objekt-Write zu unterscheiden ist.

4. Visualisierungen haben hier oft ein Problem da der Status permanent angezeigt werden soll. Hierzu sind die Schaltbefehle als auch die Rückmeldungen heranzuziehen. Die Frage ist hier, welche Wahrheit will man anzeigen. Es gibt eigentlich drei Zustände für eine Lampe, EIN, AUS und undefiniert. Beim Start einer Visualiserung ist der Zustand zunächst undefiniert. Erst mit dem ersten eintreffenden Schalttelegramm ist der Zustand definiert EIN oder AUS.

5. Status ist nicht Status. Normalerweise zeigt die Statusanzeige eines Tasters an ob die Lampe Ein- oder Ausgeschaltet ist. Dumm nur, das eine Lampe über mehrere Gruppenadressen geschaltet werden kann. Man spricht von überlappenden Schaltgruppen, z.B. zwei einzeln schaltbare Lampen und ein Zentral-EIN/AUS. Die Zentralschaltung erfolgt in der Regel über eine dritte Gruppenadresse. Wenn nun der Status der Lampen an jeweils einer der ersten Lampen hängt wirds kritisch. Eingeschaltet über jeweils die Einzelgruppenadresse zeigt der Status an den Tastern EIN, ausgeschaltet über Zentral, schon ist's passiert, die Taster zeigen Status EIN, obwohl die Lampen beide aus sind.

6. Aktive Rückmeldung über Rückmeldegruppenadresse heisst hier die Lösung. Die Applikation meldet aktiv den Schaltvorgang zurück. Es wird hierfür dann eine eigene Rückmeldegruppenadresse verwendet. Wird nun im obigen Beispiel eine 4. und 5. Gruppenadresse als Rückmeldung auf die Einzeltaster verwendet, so können die Taster jeweils den richtigen Zustand der Lampe wiedergeben auch wenn diese nicht von den Einzeltastern eingeschaltet wurden. Oft werden hier wegen der einfacheren Konfiguartion in der ETS separate Rückmeldeobjekte verwendet.

7. Problemfall Dimmaktoren. Die Dimmaktoren haben nach KNX-Spezifikation mindestens 3 Objekte, ein Schaltobjekt, ein Dimmobjekt und ein Werteobjekt. Das Schaltobjekt hat zwei Funktionen, EIN-Aus-schalten als auch den Schaltzustand senden. Der Schaltzustand wird auch gesendet, wenn der Dimmaktor aussgeschaltet war und über ein Dimm- oder Wertetelegramm eingeschaltet wurde. Habe ich jetzt mehr als einen Dimmaktor in der Gruppe und ich sende z.B. 50% auf das Werteobjekt, so schaltet der Dimmaktor ein und dimmt auf 50%. Das Einschalten wird jetzt über das Schaltobjekt auf alle Dimmaktoren in der Gruppe gesendet und alle schalten auf 100%. Da das Schalten nach KNX EIS2 Spezifikation auch Rückgemeldet werden muss kommt es zum Lawineneffekt. Daher haben heute fasst alle Dimmaktoren ein separates Rückmeldeobjekt.

8. Statuslesen bei Programmstart. Grundsätzlich haben alle Visualisierungen das Problem, das der Status mit dem Programmstart gelesen werden muss. Dies macht nicht immer Sinn und kann ggf. sogar eine Funktion auslösen, siehe Beispiel oben mit dem Dimmaktor. Bei Jalousieaktoren macht es z.B. keinen Sinn da der Status nur Auf oder Zu wiedergeben kann. Der Status einer Jalousie die nur halb gefahren ist kann nicht wiedergegeben werden (es sei denn der Jalousieaktor hat auch ein Werteobjekt). Das unbedarfte Lesen kann so auch eine Funktion auslösen. Der Jalousieaktor auf 50% könnte durch das Lesen des BEWEG-Objektes sogar seine Fahrt fortsetzen. Werden viele Gruppenadressen verwendet, so kann das Lesen aller gleichzeitig ebenfalls Probleme in den Gateways verursachen wenn alle Rückmeldungen auch gleichzeitig empfangen werden müssen.

9. Implementierungsvorschlag:
Die Rückmeldung sollte parametrierbar sein, z.B. Taster, Anzeige des Schaltbefehls, Anzeige eines Rückmeldeobjektes (separate Gruppenandresse), keine Statusanzeige solange kein gültiger Wert vorliegt.
Bei Initialisierung: die Rückmeldung lesen, auf erste Rückmeldung warten, Zeitverzögerung für Lesen Rückmeldung.
Beim Dimmem will man oft den Status einer Lampe auf einen Blick sehen. Da empfielt es sich eine Balken- oder Prozentanzeige anzuzeigen. Ggf. noch kombiniert mit einer Leuchte die heller und dunkler wird. Die Dimmanzeige sollte zwei Objekte haben, eine für den Helligkeitswert und eine für den Schaltwert. Grundsätzlich ist der Helligkeitswert in % zu übernehmen, Empfang auf dem Schaltobjekt setzt entsprechen 0% oder 100%.

10. Die optimale Implementierung für einen Dimmer hat 3 Elemente und 5 Objekte.
Elemente: 1. Taster Aus/AB, 2. Taster Ein/Auf, 3. Schieberegler 0-100%. Die Beiden Taster gehören zusammen und haben gemeinsam ein Schaltobjekt, ein Rückmeldeobjekt und ein Dimmobjekt. Analog zum Verhalten richtiger KNX-Taster kurze Betätigung sendet EIN bzw. AUS, lange Betätigung (und halten) größer 0,6 Sekunden sendet Dimm-Auf bzw. DIM-Ab, mit dem Loslassen wird Dimm-Stop gesendet.
Der Schieberegler sendet nach Verstellung und loslassen den entsprechenden Prozentwert. Die Elemente Taster und Schieberegler müssen nicht zwingend kombiniert werden. Vorrausgesetzt entsprechend verbundene Rückmeldeobjekte bei den Dimmaktoren sorgen dafür das der Status der Taster und des Schiebereglers entspreched aktualisiert werden.


Ich hoffe ich konnte mit diesem Beitrag etwas Licht in dieses schwierige Thema bringen.

lg
Roland

[avajon]

Wieso baut ihr eigentlich jeder eure eigene App statt zu versuchen eine App so hinzukriegen, dass all damit glücklich sind?

Mein Wunsch wäre z.B. bestimmte Funktionen (z.B. aktueller Status des Hauses, Garage öffnen/schließen, usw.) als Widget definieren zu können. Ist sowas geplant?


Gesendet von meinem Galaxy Nexus mit Tapatalk

Hi,

ich bau die App weil ich mir Android beibringen wollte - und mit den Hello World Beispielen war ich schnell durch... Ich denke viele haben eine ähnliche Motivation.
Außerdem wollte ich eine App bauen die so ist wie ICH es mir vorstelle (die Grafik stell ich mir nicht so vor, aber das ist jetzt auch nicht prioritär).
Widget hab ich geplant und auch schon angefangen (ist leider etwas tricky), mein Ziel ist es, nicht nur den Status anzuzeigen sondern auch Schalter/Szenarien drauf zu geben... Aber wie gesagt, das wird noch einige Zeit dauern. Ist ja auch nur ein Hobbyprojekt von mir.

lg
markus

[mclb]

Wieso baut ihr eigentlich jeder eure eigene App statt zu versuchen eine App so hinzukriegen, dass all damit glücklich sind?

Mein Wunsch wäre z.B. bestimmte Funktionen (z.B. aktueller Status des Hauses, Garage öffnen/schließen, usw.) als Widget definieren zu können. Ist sowas geplant?


Gesendet von meinem Galaxy Nexus mit Tapatalk