WOLi2

[irgendwer]

Hallo,

ich bin neulich zufällig auf WOLi gestoßen und das ist genau das was ich suchte um das Displays meines Tablets im Flur über den PM zu schalten. Nun habe ich WOLi 0.35 auf einem Samsung Tablet installiert, KNX konfiguriert und das automatisch erkannte IP Interface (Weinzierl 730) ausgewählt sowie eine GA für WakeLock gesetzt. Leider reagiert der Button "Start Woli" nicht. Mit der "stable" versaion aus dem Play Store (ich meine .18?) war es genauso. Im Log sehe ich den folgenden Fehler:

15.01.2017 / 19:47:48 .666 > 0 <
WOLiActivity -- WoliState: OFF
15.01.2017 / 19:47:49 .879 > 0 <
setWoliState -- to: true
15.01.2017 / 19:47:49 .910 > 0 <
setWoliState -- using KNX
15.01.2017 / 19:47:49 .911 > 0 <
KNXProcessListener -- ...create ProcessListener
15.01.2017 / 19:47:49 .911 > 0 <
KNXWorker -- ...starting KNXWorker
15.01.2017 / 19:47:49 .912 > 0 <
KNXWorker -- use Gateway 00-24-6D-xx-xx-xx
15.01.2017 / 19:47:49 .912 > 0 <
KNXWorker -- Gateway DeviceInfo: device 1.0.240 "00-24-6D-xx-xx-xx", KNX medium TP1, installation 0 project 0 (project installation ID 0), routing multicast address /0.0.0.0, MAC address 00-24-6d-xx-xx-xx, S/N 0x00c501xxxxxx
15.01.2017 / 19:47:49 .913 > 0 <
KNXWorker -- trying TUNNEL-Connection
15.01.2017 / 19:47:49 .917 > 1 <
KNXWorker -- TUNNELING-Connection failed - KNXException
15.01.2017 / 19:47:49 .918 > 0 <
KNXWorker -- ... interrupted
15.01.2017 / 19:49:30 .405 > 0 <
WOLiActivity -- WoliState: OFF


Zusätzlich wird mir auf der Wiregate eibd angezeigt. Wenn ich den auswähle startet auch WOLi, jedoch wird auf die GA nicht adressiert.

Woran könnte das liegen?

Winterliche Grüße...

[trax]

kurzes Update:

V0.35 ist online ...

- Bugfixes
- set ScreenBrightness (0..255)
... Auto-Helligkeit muss deaktiviert sein
- Login heißt jetzt Heartbeat
(und muss gegebenenfalls neu angelegt werden)

[mars]

der "neue" Weg ist doch vom "alten" gar nicht so weit weg ....

... und die (einmalige) Umstellung ja auch kein Problem - auch Dank Deiner Unterstützung.
... und dass Du WOLi weiterentwickelst ist schon OK ;-)

[trax]

BorMa
der "neue" Weg ist doch vom "alten" gar nicht so weit weg ....
Und es erscheint mir immer noch die logischte Variante zu sein: 1 aktiviert etwas, 0 deaktiviert deaktiviert es wieder

ev. müsst ihr die UDP Befehle neu anlegen

Lösche in WOLi bei UDP Settings die WakeLock Zuordnung "DisplayON" und lege den WakeLock-Befehl mit "wake:" neu an, dann geht auch der von dir gesendete Befehl.
zum Deaktivieren nimmst du dann wake:0 - anstatt bisher (vrmtl.) DisplayOFF

Grundsätzlich bestreite ich jegliche Verständlichkeit von WOLi für Laien.
Es ist aber kein Hexenwerk und Programmierkenntnisse sind auch nicht von Nöten.


# "Never change a running system"
dann hätten wir noch immer WOLi V0.1 ...

[BorMa]

kaum schraubt man an einer kleinen Stelle ... schon brechen Häuser zusammen ....


http://woli.asp1.at/download/woli²-beta-v0-34/

in Version 0.34 müsste der Bug behoben sein.
UDP-WakeLock:1 = ON / 0 = OFF z.B. wolido:wake:1
- alles größer 0 (als Übergabe-Parameter) aktiviert den WakeLock
- 0 deaktiviert diesen

ev. müsst ihr die UDP Befehle neu anlegen

Vielleicht ist das doch zu unpraktisch ...
Bei den anderen Funktionen schien mir die Vereinfachung sinnvoll.

und das nach dem Dominoprinzip

Hallo,

bei mir ist es ebenso, wie mars beschrieben hat. UDP kommt an aber es passiert nicht.

Im Prinzip habe ich auf meiner CCU in der sh-Datei :
echo 'wolidoisplayON' | /usr/local/addons/socat UDP:192.168.178.31:6666,cr -
zu
echo 'wolido:wake:1' | /usr/local/addons/socat UDP:192.168.178.31:6666,cr -
Leider ohne Ergebnis.

Ich habe wenig Ahnung vom Programmieren, aber es lief ja gut, deswegen "Never change a running system". Der alte Weg machte es Laien auch einfacher zu verstehen, was wo eingetragen werden musste.

Ansonsten kann ich mich nur bedanken.

Beste Grüße

[zeitverschwendung]

Ich kann Dir bezüglich der 'sauberen' Methoden nur beipflichten; vor allem nachdem das PAD durch den 'Hack' zwar wesentlich länger reibungslos durchläuft, nach ein paar Tagen dann allerdings irgendetwas abzustürzen scheint was dann dazu führt dass alle Anwendungen geschlossen werden und auch WOLi regelmäßig wieder geschlossen wird. Nach einem Neustart läuft es dann wieder 3-5 Tage.

Dementsprechend sehe ich dem ordentlichen Re-Start erwartungsvoll entgegen. Bei mir schein es so zu sein, dass WOLi nach dem abgeschossen werden durch Android zwar laut Icon noch im Hintergrund läuft, die Log-Einträge aber erst wieder zu sehen sind nachdem man WOLi dann einmal geöffet hat, vor her scheint WOLi auch keine UDP-Telegramme entgegenzunehmen.
Ist für einem 'ordentlichen' Re-Start ist dann auch eine Remanenz geplant, um alle vorherigen Zustände wie z.B. Wake-Lock auch nach dem Restart wieder zu setzen?

[trax]

nun ... das mit local.prop ist nicht auf allen Geräten möglich (ausgenommen gerootet) und stellt grundsätzlich ein Sicherheitsrisiko dar.
ist ja wohl eher ein "Hack" als eine Lösung (nicht dass Hacks keine Lösung wären... aber trotzdem)
Ich würde gerne bei "sauberen" Methoden bleiben
Derzeitiges Ziel ist es den Re-Start ordentlich hinzubekommen,,,

[zeitverschwendung]

Das Problem dass WOLi durch Android nach einer Weile abgeschossen wird habe ich gelöst. Mit meinem Ansatz aus dem letzten Post war ich nicht zufrieden, deshalb habe ich weitergesucht und letztendlich folgenden Lösungsansatz verfolgt, der dafür sorgt, dass Android WOLi nicht mehr schließt:

1. Total Commander heruntergeladen und installiert (andere Dateimanager funktionieren sicherlich auch)
2. Ins /data-Verzeichnis navigiert und dort eine Datei namens local.prop angelegt, diese Konfigurationsdatei scheint additiv zur build.prop zu wirken.
3. Diese editiert und folgende Zeile eingefügt: sys.keep_app_1=at.asp1.woli. Laut den Infos die ich online gefunden habe soll man danach eine weitere Zeile einfügen da man sonst in einer Bootschleife landen könnte; hab's nicht ausprobiert aber die Zeile eingefügt ;-)

Nun läuft WOLi auch auf dem 4.4er Pad seit 2 Tagen reibungslos durch und auch der Log wächst und wird nicht nur für die letzte Minute angezeigt.
Vielleicht wäre es sinnvoll in WOLi eine Option hinzuzufügen diese Datei anlegen zu lassen falls sie noch nicht existiert und den entsprechenden Eintrag hinzufügen zu lassen (falls bereits keep_apps existieren sollte es mit keep_app_X+1 weitergehen).

Die WLAN Optimierung ist bei mir irrelevant da ich ausschließlich LAN verwende.

[trax]

schau doch mal unter "Einstellungen" - "WLAN" - "Erweitert" ob " WLAN Optimierung" aktiviert ist ... soweit ich weiß kam das min 4.4
... das optimiert aber nicht das WLAN sondern den Akkuverbrauch in dem es im Standby das WLAN auf Vermittlungsebene trennt ... das "mag" WOLi nicht

[zeitverschwendung]

Nach der Neuinstallation auf beiden Pads gibt es keine komischen Effekte mehr auf dem 4.2er Pad.
Auf dem 4.4er Pad hingegen scheint es wirklich so zu sein dass WOLi regelmäßig abgeschossen wird, es kommen UDP-Telegramme nicht bzw. sind sie im Log nicht zu sehen und zeigen auch keine Wirkung.
Wenn ich die PictureFrame-App schließe und den Desktop anzeige, sehe ich zwar das Symbol von WOLi links oben und kann es auch direkt öffnen. Wenn ich dann allerdings das Log ansehe ist klar zu erkennen, dass die Software erst seit ein paar Sekunden läuft da die Log-Einträge erst in der aktuellen Minute beginnen (auf dem 4.2er Pad werden hingegen problemlos die letzten 500 Einträge angezeigt).
Auf beiden Pad's ist bis auf die Android-Version alles identisch.
Nun werde ich versuchen das System daran zu hindern, WOLi zu schließen... z.B. indem ich in WOLi für mehr Action sorge... das ist zwar nicht schön, aber vielleicht erstmal eine temporäre Lösung, und zwar würde ich einfach regelmäßig UDP-Datagramme an WOLi schicken und herausfinden, wie hoch die Frequenz sein muss damit WOLi nicht in gekillt wird.
Alternativ dazu könnte ich sicherlich auch Tasker installieren und WOLi intern regelmäßig ansprechen.
Komisch ist dass auch auf dem 4.4er Pad alles reibungslos funktioniert hat über 48h hinweg, erst heute Abend habe ich das Problem aufgrund fehlender Aktionen bemerkt, also frage ich mich nach welchem Schema Android Hintergrundprozesse abräumt... Zeit, Systemauslastung etc... ich hoffe bald mehr Details liefern zu können.

[trax]

..hier ein kurzes Feedback

ad 1) ... das sieht erst recht so aus als würde das System WOLis Service des Öfteren "wegräumen".
Solange das Service läuft (Symbol in der Statusleiste) wird auch aufgezeichnet. Ist das Log eher kurz wurde WOLi wohl erst vor Kurzem (neu)gestartet.
(Mit dem WakeLock-Problem...)

ad 6) ... für dich zwar kein Problem, aber trotzdem seltsam. Das sollte so nicht sein.
Wenn per Ethernet verbunden, dann wird dies automatisch als "Heimatnetzwerk" angesehen (= gelber Stern) und autostart kann ausgewählt werden (auch wenn es ohnehin nicht ratsam ist autostart zu deaktivieren...)

Das Hintergrundprozesslimit lass auf Std. - das ist jedenfalls mehr als 4 ...

[zeitverschwendung]

vielen Dank für die Info und Tipps, hier ein kurzes Feedback:

Die Geräte werden nie über den Power-Button an- oder ausgeschaltet.
Tasker nutze ich derzeit nicht, habe aber schon mit dem Gedanken gespielt, gäbe es für diesen Fall irgendetwas zu beachten?

zu 1)
bei mir sieht es derzeit so aus, als ob im Log nicht die letzten 500 Einträge, sondern maximal die Einträge seit App-(Re-)Start zu finden seien.

zu 5)
habe nun erstmal von Google TTS auf PICO TTS umgestellt, mal schaun ob sich was ändert

zu 6)
mit Ethernet ja, aber nicht per WLAN sondern per LAN, deshalb ist die SSID not available. Auf dem 4.2er Pad ist Autostart An und blau, auf dem 4.4er An und ausgegraut... kein Problem nur eine Differenz ;-)

Bezüglich des Killens der Apps durch Andorid habe ich folgendes gesehen:
In den Entwickleroptionen der Pads kann ich ein Hintergrundprozesslimit festlegen, ich kann bis zu 4 Hintergrundprozesse zulassen, derzeit steht es auf 'Standardlimit', ich habe aber keine Ahnung wie vielen Prozessen dies entspricht, weniger als 4, mehr als 4, dynamisch?
Außerdem bin ich nicht sicher ob alle Prozesse oder nur die vom User gestarteten Apps gemeint sind.

[trax]

eine Minute lang ein UDP-Wakeup-Paket pro Sekunde abzufeuern- nach 5-10 Sekunden geht das Display dann an

wieviele der gesendeten Pakete kommen denn an ? (siehe WOLi-Log)

UDP Pakete können schon mal nicht ankommen (also theoretisch) - sende doch mal nur 3 Pakete

wenn alle 60 ankommen bleibt die Meldung natürlich entsprechend lange (wird eben 60 mal angezeigt)
... nicht nur dass, sondern auch 60 mal ein WakeLock gelöscht und wieder gesetzt ...

weshalb feuerst du 1 Minute lang, wenn doch nach spätestens 10 Sekunden das Display an ist ?

Ich denke es handelt sich hier am ehesten um ein Netzwerk Problem


im Übrigen wird ScreenBrightness in V0.35 enthalten sein

[junibart]

Hallo Christian,

auch von mir ein kurzes Feedback zu den neuesten Beta-Versionen:

WOLi2 läuft bei mir seit ca. einem Jahr auf einem Medion 10433-Tablet (Android, 10"). Das ist im Eingangsbereich positioniert und soll mir beim Verlassen und Betreten der Wohnung einige Status-Infos geben. Als Trigger für das Ein- und Ausschalten des Displays dient ein Präsenzmelder im Eingangsbereich mit einer Nachlaufzeit von 15 Minuten. Die Visualisierung wird von EDOMI bereitgestellt.

Ich hatte in der Vergangenheit mal Schwierigkeiten mit dem Aufwecken über KNX-Pakete und nutze daher die UDP-Variante.

Auch mit der neuesten Version gelang es nicht, das Tablet zuverlässig mit dem ersten Paket zu wecken. Alle Versuche, an den Einstellungen für den Energiesparmodus etc. zu drehen, funktionierten nicht. Erfolg hatte ich letztendlich damit, mit einem Telegrammgenerator eine Minute lang ein UDP-Wakeup-Paket pro Sekunde abzufeuern- nach 5-10 Sekunden geht das Display dann an- und das zuverlässig. Problem gelöst... mit dem Schönheitsfehler, dass sehr lange die Message "Display On by WOLi" auf dem Display steht.
Lässt sich die Nachricht abschaltbar machen bzw. nur einmal anzeigen, wenn wirklich das Display eingeschaltet wird? Derzeit kommt die Meldung auch, wenn das Display an ist und ich ein WakeupPaket schicke.

Ich wäre auch dafür, den Wakelock auf eine bestimmte Zeit zu begrenzen und über regelmäßige Wakeup-Pakete zu verlängern, wie es hier schon angesprochen wurde.
Das würde auch die von Dir angesprochenen Probleme lösen:

- Android versucht möglichst Resourcen schonend zu sein und "beseitigt" alles was gerade nicht benötigt wird. Da WOLi nicht gerade viel tut wird die App schon mal vom System gekillt. WOLi startet zwar sofort neu, jedoch sind zuvor gesetzte WakeLocks verloren
- Außerdem werden je nach Implementierung (im herstellerspezifischen ROM) unterschiedliche Energiespar-Methoden genutzt die meist nur teilweise konfigurierbar sind, aber letztlich große Auswirkungen auf Apps haben die ständig im Hintergrund laufen aber eigentlich nicht viel tun.

Zum Schluss noch einen Feature-Wunsch: Lässt sich ein Befehl zur Steuerung der Display-Helligkeit einrichten? Ich würde das Display nachts herunterdimmen wollen, wenn es eingeschaltet wird.

Ansonsten vielen Dank für die Programmierung von WOLi und die inzwischen auch sehr gute Dokumentation!

Beste Grüße,
Gunnar

[trax]

Vielleicht noch zum besseren Verständnis:

Wozu überhaupt WakeLocks ?
- ist leider die einzig mir bekannte Art und Weise das Display eines Android Gerätes per Software zu aktivieren und aktiv zu halten !

Was bewirkt ein WakeLock ?
- fordert eine App einen WakeLock an, teilt das dem System mit, dass die App aktiv bleiben möchte.
um das Gerät aber auch aufzuwecken greife ich aus kompatibilitäts-Gründen auf Methoden zu, die seit API Level 17 als veraltet gekennzeichnet sind

Warum ist ein WakeLock unerwünscht ?
- weil Android für mobile Geräte entwickelt wurde und Energie sparen große Priorität hat. Da das Display schließlich der größte "Energiefresser" ist soll es somit so kurz als möglich genutzt werden (aus Sicht des Systems). Ein kompletter WakeLock (also das absichtliche Wachhalten des gesamten System) ist nicht wirklich energiesparend. Etliche Powermanager-Apps setzen auch hier an.

Wo is jetzt das Problem ?
- Android versucht möglichst Resourcen schonend zu sein und "beseitigt" alles was gerade nicht benötigt wird. Da WOLi nicht gerade viel tut wird die App schon mal vom System gekillt. WOLi startet zwar sofort neu, jedoch sind zuvor gesetzte WakeLocks verloren
- Außerdem werden je nach Implementierung (im herstellerspezifischen ROM) unterschiedliche Energiespar-Methoden genutzt die meist nur teilweise konfigurierbar sind, aber letztlich große Auswirkungen auf Apps haben die ständig im Hintergrund laufen aber eigentlich nicht viel tun.