WOLi2

[trax]

omg ... jetzt dämmert's - ich hab das ja völlig falsch interpretiert ... (sorry) - -
du willst nicht den HomeScreen anzeigen - sondern "etwas" das dort abgelegt ist öffnen...

- sofern es sich um Apps oder Webseiten (Lesezeichen) handelt, bietet WOLi Möglichkeiten, aber ...

wenn ich das (nun) richtig verstehe möchtest du den Chrome "Desktop Shortcut" öffnen - also Chrome im "WebApp"-Modus öffnen ...
Ich hab zwar den von dir "ergoogelten" StackOverflow Post gefunden - aber das ist keine Lösung für WOLi

In der kommenden Version funktioniert der interne (WOLi)-Browser deutlich besser (z.B. auch mit EDOMI) (sofern man Android >= KitKat (4.4) hat)

[toggle]

Ich habe versucht mit "am start -a ..." aus der Shell ACTION_START_WEBAPP in verschiedenen Kombinationen auszuführen, konnte aber keinen Intent erzeugen, der ausführbar wäre. VIEW war dagegen ziemlich "kooperativ".

Letztendlich ist es egal, wie die Funktion heißt (Webapp, Shortcut, Kioskmode, immersive Mode, Fullscreen, etc.). Mir geht es darum, dass Edomi fullscreen, ohne Tabs und andere Leisten angezeigt wird.

Wäre es denkbar, eine Makrofunktion einzubauen, so dass man nicht mehrere Trigger in bestimmten Abständen hintereinander schicken muss? Wenn Android schlummert, ist die Verarbeitung verzögert. D.h. auch ohne Wake an erster Stelle werden hin und wieder UDP-Pakete verschluckt, weil der UDP-Receiver (laut Log) erst nach 100-300ms wieder aktiv wird.

[trax]

von Natur aus hat UDP das Problem ein verbindungsloses Protokoll zu sein - die Datenübertragung ist daher ungesichert. Es darf also vorkommen, dass Pakete nicht ankommen...

Da es bei UDP immer wieder Probleme mit <CR><LF> am Ende gab - wird das in der kommenden Version nicht nur abgefangen, sondern genutzt um UDP-Kommandos zu trennen -
sprich: per UDP ist es dann möglich mehrerer WOLi Befehle auf einmal zu übermitteln.

[trax]

ich möchte euch die V0.36 nicht länger vorenthalten:
"unter der Haube" hat sich einiges getan ... ich hoffe ich habe genug getestet
jedenfalls wird Android 6 besser unterstützt


Update ... Version 0.36
Änderungen / Changelog (kurz zusammengefasst)

• jede Menge Buxfixes
• KNX-Watchdog überwacht minütlich die KNX-Verbindung
• WakeLock - Settings
  - die Toast-Nachrichten können individuell eingestellt werden
  - FallBackTimer ... nach der Zeit in Minuten wird der WakeLock deaktiviert.
• mehrere UDP Befehle übertragen
  - mehrere Befehlen können mit <cr>lf> getrennt übertragen werden
  Woli arbeitet diese der Reihe nach ab
• fake HOME-App
  - im App Launcher findet sich als erstes eine "App" die zum HomeScreen führt
• einstellbarer Notification Sound
  - die angelegten Sounds können nun auch für die Notifications genutzt werden
• Sonstiges
  - zusätzliche Icons
  - einstellbare Zeit für Gateway-Suche
  - WOLiLog-Filter
  - der WOLi-Browser funktioniert nun deutlich besser (... ist jedenfalls einen Test wert)

[jonofe]

Vielen Dank, super Arbeit! Für mich ist die v0.36 ein Meilenstein, denn jetzt scheint die KNX Verbindung wirklich stabil zu funktionieren!

[trax]

jetzt scheint die KNX Verbindung wirklich stabil zu funktionieren!

das war schließlich das Ziel
... aber warten wir mal das Langzeitverhalten ab - sieht aber bisher ganz gut aus

[trax]

[gelöscht]

[jonofe]

das war schließlich das Ziel
... aber warten wir mal das Langzeitverhalten ab - sieht aber bisher ganz gut aus

Ich hatte nun nach ca. 24h Laufzeit einen Aussetzer. Per KNX ging nix mehr. Heartbeat lief noch und auch die minütliche Meldung, dass die KNX Verbindung okay ist. Aber WakeUp hat nicht mehr funktioniert. Einmal auf "Stop" und wieder auf "Start" geklickt und es lief wieder. Werde es weiter beobachten...

[trax]

Per KNX ging nix mehr. Heartbeat lief noch ...

spannend ...
bzw. wurde auf den Bus auch was ausgegeben ? - oder war da nur die Meldung dass der Heartbeat ausgelöst hat ? - diese Meldung zeigt nur an, dass der Timer abgelaufen ist - und nicht ob die Funktion auch ausgeführt wurde. Also auf Heartbeat - write to KNX ... folgt ActionPerformer writeKNX:...
-Konklusion: wenn schreiben möglich dann auch lesen ... entweder die Verbindung steht (LinkOK) oder eben nicht
Bzw. würde das in letzter Konsequenz bedeuten, dass der Watchdog nicht (richtig) funktioniert ...

Hinweis: wenn im Log der ActionPerformer auf die Anforderung des HeartBeat-Timers nicht reagiert ist vermutlich keine GA für diese Funktion angelegt !

[jonofe]

Es kamen immer drei Meldungen:

1. KNX-Watchdog -- ...Link OK
2. HeartBeat-Timer -- write to KNX ...
3. ActionPerformer -- writeKNX:x/y/z - XXXXXXXXXXXX - 16.001

Und diese jede Minute.

Eigentlich sollte ja dann beim Senden der WakeUp GA noch die Meldung

• ActionPerformer -- wakeup: 1

erscheinen. Dies war aber nicht mehr der Fall. Die GA ist definiert, denn nach STOP WOLI und START WOLI funktioniert auch sofort wieder alles.
Auf dem KNX habe ich parallel nicht geprüft, ob etwas ankommt.

Was mir allerdings aufgefalllen ist: Ich habe eine eibmarkt IP Schnittstelle und einen eibd.
Ursprünglich war die eibmarkt IP Schnittstelle ausgewählt. Wenn ich jetzt aber die KNX Einstellungen aufrufe, dann steht bei use Gateway. eibd.

Wäre gut, wenn das Interface, welches man manuell ausgewählt hat auch als Einstallung erhalten bleibt. Wie erfolgt die Auswahl des Interfaces, wenn man WOLI einfach nur startet ohne erneut ein Gateway auszuwählen?

[trax]

OK ... jetzt ist (vermutlich) klar was da passiert - wohl nach Restart das falsche Interface gewählt...
Restart ev. auf Grund des DHCP leases (24h / 1440M) - für WOLi stellt das eine Änderung des Netzwerkes dar, weshalb sicherheitshalber die Verbindung neu aufgebaut wird. (Ist natürlich fragwürdig ob das tatsächlich notwendig ist)

... das muss jedenfalls "repariert" werden

[Borgal]

Hey Trax,

ich hab mich heute mal wieder mit dem Thema "Tablet an die Wand" beschäftigt und dabei natürlich Woli² eingesetzt. Ich habe mir die 0.36 Version installiert und versucht per KNX mit dem Wakeup zu starten.
Leider gab es keine Reaktion auf das Signal der GA.
Habe dann zusätzlich UDP aktiviert und siehe da das Display wacht auf. Kann ich eigentlich mit leben, aber verstehen tue ich es irgendwie nicht.
Vielleicht hast du ja einen Denkanstoß für mich.

Des Weiteren habe ich den Woli Browser eingesetzt, da dieser wunderbar im Vollbild läuft.
Wenn ich allerdings die xxAPI2 im Browser laufen habe und das Display geht aus und wache das Tablet per GA wieder auf, dann wird die xxAPI2 kurz angezeigt und dann läd er die Seite komplett neu.
Das geht beim Tab3 leider nicht so schnell das man es nicht mitbekommen würde. Ist das normal?

Ich könnte auch damit leben, aber vielleicht kann man da noch etwas optimieren.

Danke schon einmal und Gruß
Borgal

[toggle]

trax Danke fürs Update!

Ich habe ähnliches Verhalten wie Borgal. Der WOLi-Browser lädt die Seite alle 60 Sekunden neu. Laut Log wird alle 60 Sekunden ein UDP-Trigger empfangen. Nur es hat niemand was gesendet (bis auf das erste Mal).

Dazwischen flackert die Seite in unregelmäßigen Abständen. Man sieht, dass etwas im oberen Bildschirmdrittel überlagert wird und sofort wieder verschwindet.

Während ich die App testete, haben sich verschiedene Einstellungen selbständig deaktiviert - mal war es UDP, mal WOLi-Service, mal WOLi-Browser.

Wie verwendet man die WakeLock-Einträge ON und OFF? Die Aktion wird doch bereits durch das Triggerwort in UDP spezifiziert. Und die angehängte 1 oder 0 lösen ON bzw. OFF aus.

Fallback-Timer konnte ich nicht testen, weil WOLi glaubt, jede Minute einen Trigger zu empfangen, und deswegen nicht zur Ruhe kommt.

Mehrere Befehle in einem UDP-Paket zu übertragen funktioniert gut.

Der WOLi-Browser ist wirklich Fullscreen - die obere Leiste (Uhrzeit, Akku, etc.) ist auch verschwunden. Dumm nur, dass ich die Visu bereits darauf ausgelegt habe, dass sie da ist...

[toggle]

Der zyklische Trigger ist nach einem TabS-Reboot verschwunden. Der Fallback-Timer funktioniert jetzt auch. Allerdings ist das unregelmäßige Flackern im oberen Drittel immer noch da.

Die Funktion mit mehrere Befehlen in einem UDP-Paket ist doch etwas eigenwillig:
Es wird immer <CR><LF> erwartet. Wenn nur <LF> kommt, dann wird nicht richtig segmentiert. Ich würde <CR> wegfiltern und nur <LF> interpretieren.
Mit Edomi ist diese "Makro"-Methode leider nicht direkt kompatibel. Edomi behandelt Zeilenumbrüche als Trennzeichen für UDP-Pakete - jede Zeile wird in einem separaten Paket geschickt, was zu Paketverlusten führt, weil der WOLi-Receiver noch beschäftigt war. Ich habe stattdessen ein Edomi-Shell-Befehl verwendet.

Noch eine Beobachtung:
Wenn WOLi aktiv ist und ich versuche die WOLi-Startseite aufzurufen (über die Statuszeile oder über App-Icon), dann sehe ich kurz die WOLi-Startseite, die sofort von der Standardseite "Anwendungen" der TabS-Einstellungen überdeckt wird. Wenn ich nun die Taste "Zurück" drücke, komme ich zur WOLi-Startseite.

[trax]

... bin beruflich zur Zeit im Ausland ... ich kümmer mich nach Rückkehr umgehend um eure Anliegen
zwischenzeitlich jedenfalls vielen Dank für die ausführlichen Rückmeldungen