WOLi2

[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.

[trax]

erstmal danke für die ausführliche Info.

Das hilft zwar nicht, aber... mit den Xoro MegaPads gabs von Anfang an Probleme mit WOLi

Wird das Gerät auch über den Power-Button an und aus gestellt ?

muss nichts zu bedeuten haben, aber hast du Tasker installiert ?

ad 1) Ein Update von 0.33 und 0.34 kann hier eigentlich nicht schuld sein, da bzgl. den WakeLocks nichts verändert wurde.
Ich empfehle hier ganz klar alle WOLi-App Daten dezidiert zu löschen und WOLi zu deinstallieren (über App.Einstellungen) und eine Neu-Installation vorzunehmen.
btw: Das WOLi Log ist recht primitiv, und startet mit dem Hintergrund-Dienst. Nach 500 Einträgen beginnt die Aufzeichnung von neuem (nicht nach 1000 ...)

ad 3) einfach nur seltsam ...

ad 4) ... die Funktion die das Hinzufügen,Löschen und Editieren ermöglicht ist bei allen Einstellungen identisch, Es könnte durchaus sein, dass durch die Updates irgendwie ein Fehler in der Datenbank entstanden ist.

ad 5) könnte auch an WOLi liegen ... oder an 1000 anderen Sachen ...
Nach Tagen oder Wochen ist es nahezu unmöglich zu bestimmen was genau da dann schief gelaufen ist

ad 6) ich nehme mal an, dass beide Xoros per Ethernet verbunden sind. Somit müsste auch der SSID Stern gelb/aktiv sein (als Heimatnetzwerk erkannt) Dann sollte Autostart auch zur Verfügung stehen

[zeitverschwendung]

Bin gerade nicht zuhause, deshalb fasse erstmal alles relativ grob zusammen:

0) Umgebung:
Zwei Xoro Megapads 21", ein altes mit Android 4.2, ein neueres mit Android 4.4
Beide so eingestellt das der Bildschirm nach 30 Sekunden Inaktivität abschaltet.
Morgens schalte ich über UDP das WakeLock an und starte die Anwendung 'Cloud PhotoFrame EX.Net', die meines Wissens nach selbst auch das Schlafen verhindert wenn sie im Vordergrund ist.
Abends Schalte ich per UDP auf die Android-Uhr um damit die PhotoFrame-Anwendung nicht mehr im Vordergrund ist und das Schlafen verhindert, und schalte dann das WakeLock wieder aus, 30 Sekunden später geht der Bildschirm dann aus.
Das WakeLock nutze ich unter anderem auch deswegen, da die Pads tagsüber teilweise auch für andere Zwecke (Heimautomatisierungssteuerung, DLNA-Renderer etc.) genutzt werden und dann auch nicht einschlafen sollen.

zu 1)
Leider reicht mein WOLi-Log nicht so weit zurück, sondern scheinbar nur bis zum nächsten Neustart von WOLi (oder gibt es noch ein anderes als das auf welches ich aus der Oberfläche zugreifen kann?). Die Hardware an sich wird eigentlich nie neu gestartet, aber v0.34 von WOLi scheint irgendwie Probleme zu bereiten auf den Pads... ich hatte sogar schon die Situation dass WOLi plötzlich nicht mehr lief... weiß aber nicht ob es abgestürzt war oder was passiert war... hab ich alles erst seit dem neuesten Update auf dem 4.2er Pad, sonst nichts geändert oder geupdated, Android lässt sich auf dem Megapad wohl leider nicht nachträglich auf die neueste Version hochziehen, zumindest nicht sicher.
@All: falls jemand gegenteilige Erfahrungen bezüglich eines Updates vom Xoro Megapad 2151 von Android 4.2 auf 4.4 gemacht haben sollte wäre ich für einen entsprechenden Erfahrungsbericht sehr dankbar.
Wenn ich ins Log geschaut habe schien es mir manchmal so als ob es gerade erst in dem Augenblick angefangen hätte zu schreiben als ich die Anwendung aus dem Hintergrund geöffnet habe. Ich weiß... 'manchmal'... werde das genauer beobachten und dann genaueres Feedback liefern ;-)

zu 3)
Derzeit nur 'Cloud PhotoFrame EX.Net', die ist allerdings auch meistens im Vordergrund. Manchmal ist sie in den Hintergrund gewandert, was dann dazu zu führen scheint dass nach kurzer Zeit auch der Bildschirm abschaltet, was auch auf ein Problem mit dem WakeLock hinzuweisen scheint. Manchmal bin ich auch auf einmal in den Einstellungen der App, wohin man normalerweise durch Drücken auf den 'Zurück' Knopf gelangt.

zu 4)
War mir nur bei den UDP-Settings aufgefallen... kann aber vielleicht auch etwas damit zu tun haben dass diese bei mir bereits seit einigen Versionen geupdated wurden (ich glaube ich habe seit v0.28 am Betatestprogramm teilgenommen). KNX wollte ich ursprünglich nutzen, lief aber bei mir damals nicht zuverlässig, auch nicht wenn ich mich auf Tunneling festgelegt hatte, deshalb nutze ich derzeit nur UDP. Werde mal versuchen es zu reproduzieren.

5)
Ein Problem ist hatte ich noch nicht erwähnt, allerdings glaube ich dass es eher bei Google liegt als bei WOLi.
Und zwar gebe ich wichtige Meldungen per TTS aus. Das funktioniert auch eine ganze Weile (Tage bis Wochen) gut, dann irgendwann nicht mehr... Befehlt kommt an, scheint reibungslos verarbeitet zu werden, aber keine Ausgabe. Nach einem Neustart der Hardware geht es dann wieder.

6)
Außerdem ist mir aufgefallen, dass ich bei Android 4.2 in den WOLi-Einstellungen den Autostart aktivieren und deaktivieren kann, bei Android 4.4 ist der Autostart aktiv, aber ausgegraut.

[trax]

1) ... und zwar scheint das WakeLock nicht immer zu funktionieren.
2) ... eine Maximalzeit mit integriert?
3) ... Außerdem wandert die App im Vordergrund von Zeit zu Zeit in den Hintergrund ...

4) ...UDP-Action... korrekt angezeigt, aber wenn man auf Editieren klickt sieht man dass die falsche Aktion hinterlegt ist

ad 1) "nicht immer", "ab und zu", etc. ist immer ungemütlich - lässt sich nur schwer sagen was da los ist
das WOLi-LOG enthält die letzten 1000 Aktionen ... wird der WakeLock gar nicht empfangen, oder nicht ausgeführt ?
Ein Nicht-Zurücksetzten des Wakelocks kann mitunter zu ungewollten Verhalten führen.


ad 2) derzeit nein.

ad 3) welche App, (oder alle ?)

ad 4) das ist in der Tat seltsam - hast du das Verhalten nur bei UDP-Settings ? kannst du das reproduzieren ? (... ich nämlich nicht)

Grundsätzlich ist immer interessant welche Hardware und Android Version im Einsatz ist - vor Allem beim Betriebssystem gibt es
erhebliche Unterschiede im Energie-Management (Standby etc). (z.B. Android 6.0 Marshmallow und „Doze“)

[trax]

woli.asp1.at/en/download/woli²-beta-v0-33/
zum Rest melde ich mich später ...

[zeitverschwendung]

Könnte ich bitte einen Download-Link für die Version 0.33 bekommen, die alten Links sind leider nicht mehr verfügbar.

Der Grund ist folgender:
Die letzten Versionen von WOLi liefen auf meinem Android-Pad für meine Zwecke hervorragend, zuletzt lief Version 0.33. Dann habe ich mir ein zweites Pad zugelegt, dort wurde dann die aktuelle Version 0.34 von WOLi installiert, wobei direkt die Unterschiede bezüglich WakeLock aufgefallen sind. Nachdem das Problem behoben war habe ich auf dem alten Pad auch auf Version 0.34 geupdated.

Nun habe ich auf beiden Pads ein komisches Verhalten; und zwar scheint das WakeLock nicht immer zu funktionieren. Ich bin mir bezüglich des Schemas noch nicht im Klaren, ist da jetzt vielleicht eine Maximalzeit mit integriert?
Außerdem wandert die App im Vordergrund von Zeit zu Zeit in den Hintergrund und nur noch der Desktop ist zu sehen.
Ich gehe davon aus dass diese Effekte auf die neue Version von WOLi zurückzuführen sind, kann dies aber nur mit Sicherheit sagen indem ich auf v0.33 zurückspringe und somit die Unterschiede offensichtlich werden.

Außerdem ist mir noch ein Bug in v0.34 aufgefallen. Wenn ich eine UDP-Action ganz oben lösche (ich hatte noch WakeLockON und WakeLockOFF, und dann anstelle dieser eine neue anlege, scheinen die dahinter durcheinander zukommen. Zwar werden sie korrekt angezeigt, aber wenn man auf Editieren klickt sieht man dass die falsche Aktion hinterlegt ist, so dass dann die alten Befehle jeweils um 1 verschobene Befehle auslösen würden.

Vielen Dank im Voraus und frohe Feiertage!

[trax]

... außerdem gibts hier einen BUG:
die Übermittlung von ID's an Speak funktioniert aktuell nicht !
bzw. noch viel schlimmer - es wird die Notification ausgelöst

[trax]

mars ... du kannst weiterhin einen beliebigen Text senden, außer NUR 0...254, weil dass würde WOLi als ID ansehen.

Edit:
... mit UDP geht das, aber KNX erwartet eine ID

Die erwarteten UDP Daten (Parameter) je Funktion sind hier dokumentiert [http://woli.asp1.at/udp-settings/]

Edit2:
... steht auch nirgends: aktuell werden max 512 Zeichen verarbeitet
- dass sollte doch reichen ?

[mars]

Danke Dir trax,
... wenn der Befehl angelegt ist, klappt es auch mit dem wake (ist also auch noch was für die Hilfe ;-)
... und da es keine vordefinierten Kommandos gibt, müssen alle Aktionen per ID angelegt werden - richtig?
Dann habe ich aber ein "Problem": bisher (mit v0.18) lasse ich mir beim Verlassen des Hauses ansagen, wenn Fenster geöffnet sind. Dazu wird im Homeserver ein iKO mit dem Text zusammengesetzt (je nachdem wo Fenster offen sind). Also z.B. "Fenster offen im Badezimmer" oder "Fenster offen in Wohnzimmer und im Kinderzimmer". Diesen Text sende ich per wolido:speak:<Inhalt des Text-iKO> und die Visu sagt was los ist - coole Sache mit hohen WAF. Gibt es für diese Anwendung in v0.34 eine Lösung?

und danke auch für den Tipp zum Akkustand mit Tasker - werde ich testen.

Gruß Marco

[homesman]

Ich kann schon mal positives berichten, dass nun wakelock mit der V0.34 wieder funktioniert.

Sounds, Notifications, App Launcher, Speak gehen auch.


Getestet auf Samsung Tab 7.7 mit Android 4.1.2

[trax]

Um die Daten des Intent-Receivers per UDP auszugeben sind die zu übermittelnden Extras:
Data: (String)[Daten oder Variable]
Adress: (String)[IP-Adresse des Empfängers]

Es gibt noch das zusätzliche Extra Port - das aktuell aber ignoriert wird. und anstatt dessen der unter UDP-Settings Eingestellte zum Versenden verwendet wird.
Mit V0.35 kann der Port dann über das Intent gesteuert werden

[trax]

Mit Tasker und WOLi Akkustand auslesen:

[ in WOLi]
 - aktiviere Intent Receiver
 - hinzufügen von KNX o. UDP Befehl SendIntent

[in Tasker]
- neuen Task anlegen  z.B. SendeAkkuStand
  - Aktion hinzufügen // System // Sende Intent
[I]Aktion [/I]= at.asp1.woli.RECEIVER
[I]Extra [/I]= Data:(String)%BATT
[I]Extra [/I]= GA:(String)6/6/6
[I]Extra [/I]= DPT:(String)5.001
[I]Ziel [/I]= Broadcast Receiver

 - neues Profil // Ereignis // System // Intent Empfangen
[I]Aktion [/I]= at.asp1.woli.SENDER
[I]Typ [/I]= Default
     Task >> SendeAkkuStand

-- wird der Befehl SendIntent ausgelöst (per UDP oder KNX) sendet WOLi ein Intent an Tasker. Tasker löst beim Empfangen den Task SendeAkkuStand aus, der wiederum den Akkustand per Intent an WOLi sendet. WOLi sendet die empfangenen Daten (Akkustand) dann auf die angegeben Stelle. z.B. KNX GA
Der Einfachheit halber reagiert Tasker im obigen Beispiel auf alle von WOLi gesendeten Intents - das kann mit einer IF Anweisung mit $woli_value aber leicht gelöst werden.
Natürlich könnte der Task SendeAkkuStand auch per Zeit oder per Akkustand ! ausgelöst werden.

Mit obigen Beispiel lassen sich auch alle anderen von Tasker bereitgestellten System-Variablen abfragen

[trax]

mars
Danke für das Feedback.
Bzgl. WakeLock - ich gehe mal davon aus, dass du den UDP-Befehl ohne : (Doppelpunkt) angelegt hast - dann wäre das nämlich: wolido:wake1
Bzw. wenn du von V0.18 kommst: du must die UDP Befehle in den UDP-Settings anlegen - es gibt keine vor-definierten Kommandos.