Neue Fullscreen Browser APP für Android (WebViewControl)

[Martin Thomas Schrott]

Ja da hast du recht, viele reagieren vorsichtig bei zu vielen Genehmigungen.
Aber diese genialen Möglichkeiten können nicht deshalb unter den Tisch gefesselt werden ;-)

Im schlimmsten Fall eine App mit minimum und eine mit maximum Funktionalität, sollte nicht viel mehr Aufwand sein oder? ;-)
Und ich möche natürlich auch unbedingt GPS Koordinaten, das hab ich ja ganz vergessen, du hast recht.
Okay, dann bitte GPS, Anrufe, SMS in der nächsten Version *lac*
Ich teste umgehendst ...
Würde ja sogar helfen, aber von Android scripting leider noch keine Ahnung, ich bleib immer wieder bei perl hängen, weil dort so viel auf meiner internen Todo Liste steht. :-) Und nichts weitergeht, weil dann so Leute wie du so tolles Spielzeug bauen.
cheers
Martin

[Martin Thomas Schrott]

Hallo Dirk!



hab jetzt noch eine Weile getestet und muss sagen, dasss doch recht viele Befehle an das Android Gerät verloren gehen.
Das Gerät ist eigentlich ständig online nur eben im Standby Modus. Ev ist hier irgendetwas zu langsam um es aufzuwecken o.ä. Jedenfalls werden z.B. die gewünschten ttsSay oft nicht abgespielt, wenn das Handy schläft. Manchmal aber schon.


Hab mir deswegen Gedanken gemacht, wie man das ein wenig Zuverlässiger bekommen könnte. Hier ein Gedankenansatz, der dir ev. hilft oder gefällt, oder Ideen bei dir auslöst:



0. status von android ist alive


1. befehl geht von fhem an android raus mit einer einzigartigen jobid. Hier eine aufsteigende unique id vergeben. Der Befehl inkl. jobid bleibt in einer queue gespeichert.


2. Android empfängt und fragt bei fhem ab ob die jobid noch in der queue hängt.


3. android erhält von fhem Antwort ob die jobid in der queue hängt, wenn ja führt android die Aktion aus und fhem löscht die jobid.


4. wenn fhem keine Anfrage bezüglich eines jobs erhalten hat (nach xyz msec) wird der befehl mit gleicher jobid wiederholt an android gesendet.


5. fhem empfängt hoffentlich irgendwann das ack und löscht die jobid.
 Hier könnte man noch eine Warnung in Fhem ausgeben wenn nach xyz sec trotz android alive immer noch ein job in der queue hängt. Da könnte man dann mittels eines notify alternative benachrichtigungswege nutzen.

6. done.



Durch diese bidirektionale Abfrage sollte eigentlich keine message verloren gehen können und mittels warnung in fhem zumindest informiert werden, falls doch etwas schief läuft.
Einzig ein fehler android intern könnte hier noch das Ausführen verhindern, denn da werden wir wohl kein feedback bekommen, ob etwas getan wurde oder? :-)
Hoffe das lässt sich ohne all zu viel Aufwand so umsetzen, aber ich denke das wäre dann sogar für Sicherheitsrelevante Einsätze gut tauglich.

Liebe Grüße
Martin

[Dirk]

Das Gerät ist eigentlich ständig online nur eben im Standby Modus.

Der Standby-Mode stand bei der Entwicklung derzeit nicht im Vordergrund. Das wird mit der aktuell eingesetzten Technologie wohl auch nicht zuverlässig zu lösen sein. Dafür müsste der Webview, ständig im Hintergrund aktiv sein. Und das wird sich vermutlich extrem negativ auf die Akkulaufzeit auswirken. Muss man testen. Und mal sehen was sich in Zukunft daraus noch eintwickelt.

Gruß
Dirk

[Martin Thomas Schrott]

>Dafür müsste der Webview, ständig im Hintergrund aktiv sein.

hm... ist er denn das nicht, solange die app offen ist? Ich hätte gemeint das ist bei Android so, sonst würden ja nicht z.B. Youtube Videos weiterlaufen, wenn man den bildschirm sperrt?
bzw. vielleicht habe ich mich mit standby falsch ausgedrückt? Der Bildschirm wurde eben gesperrt, die app lief im Hintergrund.

n dieser Situation (ich hätte das eben standby genannt) geht es mal, mal nicht. Ich denke, mit der oben angegebenen bidirektionalen Rück-Kommunikation sollte das dann auch zuverlässig klappen, denn wenn das Gerät die erste Meldung durch aufwachen verpasst hätte, würde die zweite greifen.(so meine Theorie) ;-)

Andernfalls - wenn dem nicht so ist, wäre es doch sehr praktisch diesen Tiefenschlaf, der die Verbindung kappt, verhindern zu können, vgl. dem was du schon hast, aber auch bei Batteriebetrieb!

Wie auch immer, so eine Rückfrage-Queue würde ich jedenfalls einbauen, Bestätigungen können nie schaden und der Aufwand sollte sich in Grenzen halten, ebenso wie die Latenz dadurch.
bye
Martin

[Martin Thomas Schrott]

Morgen Dirk,

mir ist noch etwas eingefallen, kann es sein, dass durch einen neuen powerLevel im Gerät die app den standby aufhebt, eine Nachricht an FHEM sendet und dadurch trotz vermeindlichem STandby auf einmal wieder Befehle an das Gerät durchgehen?
Das würde erklären, warum ich mal senden konnte und mal nicht, obwohl das Gerät geschlafen hat.

Wenn das so ist, könntest du ein keepAlive in der App einbauen?
keepAlive = 0 no messages sent.
keepAlive = 1...n every n seconds a message with alive is send to fhem.

Das müsste ein flexibles wach halten und status anzeigen ermöglichen. Wenn du das auf default = 0 setzt merkt auch niemand einen Unterschied.
Ich denke so machen das andere clients z.B. sip clients auch, denn dort bleibt das Gerät ja auch erreichbar, obwohl der Bildschirm gesperrt ist?!

lG
Martin

[Dirk]

hm... ist er denn das nicht, solange die app offen ist?

Grundsätzlich schon. Aber Android hat die Angewohnheit Hintergrund-APPs zu beenden wenn es meint dass sie nicht mehr "gebraucht" werden. Es sei denn man unternimmt entsprechende Schritte daß das Funktioniert.

vielleicht habe ich mich mit standby falsch ausgedrückt?

Unter Standby hatte ich verstanden Bildschirm aus, Gerät verbraucht am wenigsten Energie, und im besten Fall weckt die APP das Gerät dann auf um eine Benachrichtigung zu empfangen. Und dafür währ die aktuell eingesetzte Technologie wohl unpassend.

Ich denke, mit der oben angegebenen bidirektionalen Rück-Kommunikation sollte das dann auch zuverlässig klappen

Wenn du nur das brauchst, dann kann man das sicher so machen. Also: Wenn Gerät wieder an -> alle "pending Commands" kommen an? Da muss man nicht mal was an der APP selber machen. Entsprechende Änderungen im Perl-Modul und am Javascript sollten da ausreichen. Wenn du mich hier unterstützen möchtest, gerne.

Andernfall ... wäre es doch sehr praktisch diesen Tiefenschlaf, der die Verbindung kappt, verhindern zu können, vgl. dem was du schon hast, aber auch bei Batteriebetrieb!

Das geht grundsätzlich auch, die Akkulaufzeit würde sich dann aber rapide verschlechtern, daher wird das keine Option sein denke ich.

kann es sein, dass durch einen neuen powerLevel im Gerät die app den standby aufhebt, eine Nachricht an FHEM sendet und dadurch trotz vermeindlichem STandby auf einmal wieder Befehle an das Gerät durchgehen?

Müsste ich mal untersuchen ob der Broadcast Receiver die Nachrichten auch im Standby verarbeitet.

Wenn das so ist, könntest du ein keepAlive in der App einbauen?
keepAlive = 0 no messages sent.
keepAlive = 1...n every n seconds a message with alive is send to fhem.

Ich werde die Wachbleiben / Standby -Sachen auf alle Fälle im Auge behalten. Neben den ganzen anderen Ideen die mir so im Kopf rumschwirren. Meine letzten Experimente waren neben TTS die Sprachsteuerung. Ala: "Licht Wohnzimmer aus".

Gruß
Dirk

[Martin Thomas Schrott]

Hi Dirk,

bin momentan leider ziemlich ausgelastet aber zumindest beim Testen versuch ich zu helfen :-)

Muss nochmal wegen dem keep alive nerven:
Könntest du trotzdem dieses setting einbauen? Einfach nur Einstellmöglichkeit für sendkeepalivesec und wenn der default von 0 auf irgendwas geändert wird, eben alle n Sekunden ein schlichtes keepalive oder nur alive zu fhem senden.
Ich weiß die Batterie und so, aber die notify Möglichkeiten sind irgendwie das beste an dieser App und ohne keepalive funktionieren sie leider nicht, oder nur am Stromnetz.:-)
Sprachsteuerung klingt auch super, funktioniert meiner Meinung nach bei Android schon wirklich gut. Hast du da was implimentiert oder nutzt du einfach das, was Android schon mit sich bringt und fragst nur den Text der Übersetzt wird ab? ... kannst du da (ich weiß der Akku ;-) ) ein ständiges Lauschen aktiv halten?

Und wenn wir schon bei Steuern sind, könnte man auch Gesten per Videokamera einfangen? Also nicht Display Gesten sondern in der Luft?
lG
Martin

[Dirk]

Hi Martin,

bin momentan leider ziemlich ausgelastet

Das geht mir derzeit ähnlich. Und darum baue ich derzeit tauch meist erstmal an Funkionen die ich interessant finde. Siehe Sprachsteuerung/Erkennung. Mal sehen ob ich da vielleicht am WE schon mal was zu Präsentieren habe.

Die Ganze Keepalife / Standby-Sache schau ich mir auch noch an.

Für die Spracherkennung benutze ich die Android API. Daher wird es dafür auch zwingend eine Onlineverbindung benötigt. Google werted die Spracheingabe in der Cloud aus und liefert dann entsprechende Ergebnisse. Ständiges "Lauschen" sollte auch gehen. Man sollte dann aber eine "Schlüsselwort" haben, damit nicht ungewollt Befehle abgesetzt werden.

Tja, Gesten. Sowas geht sicher auch. Derzeit nutze ich für die Userinteraktion auschliesslich die Android API. Alles weitere wird dann wohl etwas aufwendiger, vor allem auch die Bildverarbeitung. Und die verbaute Kamera wird da auch eine entscheidende Rolle spielen. Ich denke aber eher, dass das eine Feature ist was weiter hinten auf der Liste steht. In der Zwischenzeit kann das dann Android vielleicht von sich aus, dann kann das direkt per API angesprochen werden :)

Gruß
Dirk

[Markus]

Ich steuere fhem über diese app Funktioniert super horcht auch immer mit wenn man möchte aber halt leider der Akku..
steuert fhem ganz einfach über http links und kann sich auch sonst ziemlich gut mit dir unterhalten. Ist eigentlich gratis aber wenn man mehr steuern möchte mus man die Vollversion kaufen, aber unter drei Euro ist nicht so schlimm. vielleicht kannst du das ja in deine app einbauen?

Gruß Markus

[Martin Thomas Schrott]

Hi Markus,

hm, ich hab die Vollversion seit Monaten, wie hast du rausgefunden, dass dieses Tool FHEM steuern kann? Ich hab das nicht bemerkt, wo geht das?

Und was meinst du sollte Dirk in seine App einbauen? Die ganze App?*verwirrt bin* Oder meinst du die Sprachsteuerung? da ist er ja dran!

lG
Martin

[Dirk]

Hi,

@Martin,
Man kann mit AVIC per Sprachbefehl eine beliebige URLs aufrufen. Damit natürlich auch z.B.

Code: [Auswählen]

http://<host>:8083/fhem?cmd.=set%20wzLicht1%20on

@Markus
An einem Spracheingabeinterface für die App experimentiere ich gerade.
Ein kontinuierliches Zuhören könnte man auch einbauen. Auf eine Verbesserung bezüglich des Energieverbrauches mach ich aber keine großen Hoffnungen, weil die App dann die ganze Zeit aktiv sein und "zuhören" muss. Entsprechend viele Ressourcen müssen dann also aktiv sein. Zusätzlich ist dann auch eine Internetverbindung dauernd erforderlich, weil die Sprachauswertung in der "Cloud" stattfindet.

Gruß
Dirk

[Markus]

Stromverbrauch ist mir eigentlich egal ich hab das tablat an die Wand geschraubt und fix angeschlossen :-)

@ Martin

Manager
Befehle verwalten
bei Aktion must du "HTTP ausführen" wählen

Gruß Markus

[Dirk]

Ja, für die Wandtablets ist die Funktion interessant, und erstmal auch geplant. Für Marcus wird es aber sicher nicht stromsparender als AVIC. Daher wird das kontinuierliche erkennen für Handys wohl nicht so interessant werden. Mal sehen. Erste Tests sind übrigens noch nicht sooo berauschend. Denn mit abnehmender Entfernung zum Mikrophon sinkt die Erkennungsgenauigkeit erheblich. Daher ist die Frage ob es da dann zufriedenstellende Ergebnisse geben wird. Ggf. wird es dann erforderlich mikrophontechnisch noch was zu machen. Mal sehen.

Gruß
Dirk

[Markus]

Ich bin auch schon am überlegen mehrere Mikrofone im Raum zu verteilen und über eine art Verstärker am Tablet anzuschließen aber ich weiß noch nicht genau welche Hardware am besten geeignet ist :-)

[Guido]

Hallo,

Wie siehts denn mit so was wie  Kinect aus gibts so was auch für Android ?