WOLi2

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

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

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]

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]

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]

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]

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?

[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

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

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

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)

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

Es möge mir wer eine IP-Schnittstelle schenken ... oder leihen ...

Also im Ernst ... ich hab keine Ahnung. Ich selbst nutze (mangels Alternativen^^) nur den eibd am wiregate.
Ev. eine Netzwerk-Geschichte, Router, Firewall etc. Tunneling nutzt UDP
Nutzt sonst noch etwas zeitgleich die Schnittstelle ? ... die Weinzierl 730 kann nur 1 Client
was spricht dagegen den eibd am wiregate zu nutzen ? oder hängt das nicht am Bus ...

[jonofe]

Ich erhalte auch immer den Fehler

TUNNELING-Connection failed - KNXException

Sowohl bei der Verwendung der eibmarkt IP-Schnittstelle (5 Tunnel) als auch bei Nutzung von eibd.
Die Fehler treten auf, sobald ich auch "START WOLI" klicke.
UDP funktioniert problemlos.

[jonofe]

Interessanterweise startet die Routing Verbindung über eibd ohne Fehler, aber es passiert danach nichts, d.h. wenn ich die GA sende, dann kommt gar nichts im Log an. Und was dann seltsam ist, wenn ich das eibmarkt Interface auswähle und Routing auswähle, dann erscheint auch eine Erfolgsmeldung im Log, obwohl das Interface nur Tunneling kann.

Wie genau muss der eibd konfiguriert werden, damit es funktioniert?

Ist es ein Problem, wenn WOLI mehr als ein KNX Interface findet?
Kann es noch am WLAN liegen?