WOLi2

[tuxedo]

Aktuelle Version installiert (per PC/Browser die Fern-Installation eingeleitet...).

Hintergrund des Updates: Das Display wacht KNX gesteuert nicht mehr auf.

Hab jetzt parallel dazu mal das aufwecken per IP/UDP+TCP eingerichtet:

Trying 192.168.200.74...
Connected to 192.168.200.74.
Escape character is '^]'.
wolido:wake
WOLi: Command received by : /192.168.200.52:50988
WOLi: valid command: wake
WOLi: found Parameter: 
WOLi: done

Aber aufwachen tut das Display nicht.

Ich hab noch das Elcom Videofon installiert. Wenn jemand anruft/klingelt, dann wacht das Display auf.... Nur KNX und Netzwerk via Woli will nicht :-(

Kommen sich da mehrere Wakelocks in die Quere?

[trax]

1. ich hab keine Ahnung warum dein Xoro Megapad im Playstore kein Update findet (aktuell ist 0.37)
das sollte gar nicht möglich sein. die einzig derzeit veröffentlichte APK ist die Version 0.37f(inal).
die Anforderungen sind seit V0.18 unverändert, lt. developer console werden auch gleich viele Geräte unterstützt.

- wenn du die app aus dem store installierst - welche version wird im "about" dialog angezeigt ?

2. downloaden kannst du WOLi jederzeit von: http://woli.asp1.at/download/

3. der Wake TCP/UDP Befehl erwartet einen Parameter 1 (=ein) oder 0 (=aus) (also wolido:wake1)
zugegeben ... die TCP-Rückmeldungen sind eher spärlich aber das WebInterface ist in Entwicklung.
WOLi: done bedeutet in dem Zusammenhang nur dass es keinen Fehler bei der Übermittlung gab - passiert ist in deinem Fall aber nichts (fehlender Parameter)
Die derzeitige TCP Kommunikation verhilft einem hauptsächlich dazu, festzustellen ob das Gerät auch "verbindungswillig" ist - im Gegensatz zu UDP


Leider dürfte es Probleme mit diesen Geräten in Verbindung mit WOLi geben - ich besitze selbst keines und kann nur vermuten, dass es Hardware bedingt sein könnte.
Diese Geräte (XORO) sind auch der google developer console unbekannt - weshalb ich auch dort keine Information dazu erhalte ob diese kompatibel wären.

[tuxedo]

Zu 1:
Das sollte kein Vorwurf sein. Das war nur ein Feedback. Im About-Dialog müsste 0.26 gestanden haben. Installiert hab ich die neuere Version nicht über die PlayStore APP am Gerät selbst, sondern über den PC über die Playstore-Webseite. Da kann man auch "installieren" anklicken und dann sagen auf welchem seiner Geräte man installieren möchte. Das Gerät führt dann die Installation entsprechend nach kurzer Zeit selbst durch. Jetzt ist 0.37 drauf.

Zu 2: Hab ich mal gebookmarked...Danke.

Zu 3:
Ah, ok, das erklärt einiges. Habe es aber heute morgen vor dem Frühstück schnell ausprobiert: Der Parameter (wahlweise 1 oder 0) wird erkannt, aber das Display will nicht aufwachen :-(

Bis vor kurzem hat Woli auch bestens funktioniert. Meine anfänglichen und zwischenzeitlichen Probleme lagen am Switch (der war auf Energiesparen getrimmt und hat diverse Spar-Modis am Port eingeschaltet, womit das Xoro Megapad nicht klar gekommen ist). Das Problem hatte ich aber behoben.

Aktuell geht's wieder nicht. Wieso weiß ich noch nicht. Interessant ist aber:

Ich habe für meine SIP Türsprechanlage das "ELCOM Videofon" (https://play.google.com/store/apps/d...on.android.app) installiert. Die APP wacht auch im Hintergrund auf ein klingeln an der Tür. Wenn das Display gerade inaktiv ist und jemand an der Haustüre klingelt, dann klingelt's in der APP und das Display wacht auf.
DAS funktioniert nach wie vor. Aber WOLI, was zum aufwachen tendenziell den gleichen Mechanismus benutzt, funktioniert nicht?!
Ein Hardwareproblem schließe ich deshalb mal aus.

Die Xoro Megapad Gerät sind von ihrer Machart her prädestiniert für so Dinge wie eine Visu an der Wand.
Wenn du Interesse hast, können wir gern mal schauen wie man das ganze remote-debugged (ADB müsste das glaub ich können). Dann kann ich dir den Zugang zu meinem Gerät entsprechend tunneln.

Xoro baut die Geräte übrigens nicht selbst. Das ist ein China-Import der entsprechend umgelabeled ist. Gibt noch andere Firmen die das selbe Gerät unter anderem Namen vertreiben.

[trax]

Bis vor kurzem hat Woli auch bestens funktioniert.

... wie darf ich das verstehen - soll dass heißen dass WOLi einfach aufgehört hat zu funktionieren ? (also nicht nach Update oder anderen Software-Veränderungen)
Die WakeUp-Funktion selbst ist seit Generationen unverändert.
Was noch zu versuchen wäre ist: den FallBack-Timer zu aktivieren.
Außerdem wäre auch interessant, ob das Gerät aufwacht wenn du einen Alert in WOLi definierst und diesen auslöst.

Meines Wissens nach gibt es eine einzige Methode um ein Gerät "aufzuwecken" - und das ist ein FULL_WAKE_LOCK mit ACQUIRE_CAUSES_WAKEUP.
WOLi macht genau das. Der WakeLock ist nicht indexiert (ReferenceCounted) und wird auch, sofern ev. noch von WOLi gehalten, zuerst deaktiviert bevor dieser erneut "erworben (acquire) wird.
Ich begreife nicht weshalb das nicht auf allen Geräten funktioniert - bzw. eigentlich noch tragischer - warum es nicht funktioniert wenn WOLi das macht
Wenn man dass hier so liest würde man ja vermuten dass das überhaupt nicht funktioniert - Tatsache ist aber dass ich das weder auf meinen Geräten noch in irgendeiner VM nachbilden kann.

Was mir jedenfalls noch fehlt ( - obwohl ich's schon vermute ) ist die Information ob wakeup lt. WOLi-Log durchgeführt wird oder nicht (ActionPerformer wakeup: ), sprich ob WOLi zu dem Zeitpunkt den Befehl auch erhält, "versteht" und ausführt.


Nur zur Sicherheit:
Ich nehme an, dass du versucht hast WOLi vollständig zu re-installieren.
... und außerdem, dass der Schalter "WakeLock" in der APP auf ON steht...

bzgl. Remote-Debuging: sehr gerne - wenn wir das hinbekommen...

[tuxedo]

... wie darf ich das verstehen - soll dass heißen dass WOLi einfach aufgehört hat zu funktionieren ? (also nicht nach Update oder anderen Software-Veränderungen)

Mehr oder weniger, ja.

Mein Display hängt an einem Netgear Smart Switch. Ich hatte hier vor kurzem ein Firmware-Update eingespielt. Dadurch war das Display für einige Minuten nicht mit dem Netzwerk verbunden, womit Woli keine KNX Verbindung mehr hatte und das Display dann folglich nach Zeit X abgeschaltet wurde.
Nach dem Firmwareupdate hat Woli und/oder die KNX Verbindung nicht wieder nahtlos funktioniert (auf das Display bezogen, andere KNX-over-IP Lösungen liefen wieder).
Also Display vom Strom getrennt und neu gestartet. Danach direkt in Woli nach dem Problem geschaut. Oben rechts findet man normalerweise "Start WOli" oder "Stop WOli". Es war jedoch nichts dergleichen zu finden. Nach langem hin und her probieren, stellte ich fest, dass der Button noch da war, die Beschriftung aber gefehlt hat. Er war somit "nicht sichtbar". MIt viel probieren hat man es dann ab und an geschafft den Button anzutippen, was jedoch darin endete, dass Woli abgestürzt ist.
Ich hab dann probiert für die Woli APP den Cache zu löschen und auch die gesamten Anwendunfsdaten zu löschen (was ja quasi einer neu-installation gleicht). Aber nichts: Der Button war nach wie vor unsichtbar und führte zum Absturz.

Ich sehe leider keinen direkten Zusammenhang zwischen dem Switch-Firmwareupdate und dem fehlenden Button/Crash von Woli... Nur eben fass das eine nach dem anderen aufgetreten ist.

Deshalb der Upgrade auf 0.37 (wurde auch mal Zeit).

Um Probleme mit dem Switch auszuschließen, habe ich das Display nun schon mit WLAN (Fritzbox) statt LAN getestet. Aber auch das scheint nicht zu helfen. Das Display wacht nicht auf (hat aber früher schonh mit WLAN und dieser Fritzbox funktioniert).
Dass das Aufweck-Signal in WOLI aber ankommt, zeigt das Log:

15.03.2017 / 06:33:05.123 >0<
ActionPerformer -- wakeup: 1

In den Einstellungen hab ich

* bei der Netzwerkverbindung den gelben Stern markiert (sowohl für WLAN auch auch für LAN getestet)
* Die IP Verbindung für TCP/UDP auf Port 6666 konfiguriert
* Die KNX Verbindung (MDT IP Router) mit Routing und GA 5/0/5 eingerichtet
* WakeLock ebenfalls eingerichtet mit Fallbacktime "1"

Da die Videofon-APP (deren Wakelock funktioniert noch) für die Haustürklingel vor dem Firmware-Update auch schon installiert war und WOLI nicht negativ beeinflusst hat, schließe ich die Videofon-APP mal aus.

Was ich noch probieren kann ist nicht nur Cache- und Appdaten löschen, sondern die tatsächliche komplette re-installation. Dann gehen mir aber die Ideen aus.

Bzgl. Remote-Debugging: Da muss ich mich erst mal schlau machen. Oder hast du da schon einen Ansatz wie das im Detail funktioniert?

[update]
http://stackoverflow.com/questions/2...h-adb-over-tcp

From a computer, if you have USB access already (no root required)

It is even easier to switch to using Wi-Fi, if you already have USB. From a command line on the computer that has the device connected via USB, issue the commands
adb tcpip 5555 adb connect 192.168.0.101:5555
Be sure to replace 192.168.0.101 with the IP address that is actually assigned to your device.

Könnte dir den Port 5555 entsprechend durchtunneln/freigeben. Brauchen wir sonst noch was?

[trax]

... WOLI mal komplett runter und neu drauf / schaden wird's nicht / zumindest in der Theorie aber auch nichts nützen
(ev. mal die aus dem play store versuchen)

bzgl. Start/Stop WOLi button:
bei Verwendung von KNX ist Start nur verfügbar wenn auch ein KNX Gateway gefunden wurde
Stop ist natürlich nur sichtbar wann WOLi auch gestartet ist.
Um manuell eine Suche nach einem KNX/IP Gateway auszulösen, einfach useKNX de- und re-aktivieren.

Ein Netzwerk-Ausfall (oder irgendeine Veränderung des Netzwerks) sollte vom System an WOLi signalisiert werden. Sofern eine Netzwerkverbindung in ein lokales Netzwerk daraufhin erkannt wird, wird - wenn KNX aktiviert - nach KNX/IP Gateways gesucht (TimeOut hierzu kann in Sekunden gesetzt werden - obwohl meist 1 meist schon reicht). Sofern das ausgewählte Gateway erreichbar ist wird - sofern autostart aktiv - WOLi gestartet.
Dies wird im WOLi-Log protokolliert und müsste auch nachvollziehbar sein.

Lt. dem Log Eintrag wird die wakeup-Routine ausgeführt - und müsste das Gerät eigentlich wie bereits beschrieben aufwecken ...
also bis hierhin soweit OK (Netzwerk und KNX Verbindung steht, Kommando wird empfangen und ausgeführt) <Ironie> - is' doch alles bestens </Ironie> **heftiger Kraftausdruck**

Wird eigentlich irgendein anderes Kommando richtig ausgeführt ? - oder ist Wake die einzige - zugegebenermaßen die wichtigste - Funktion die nicht wie erwartet funktioniert ?

Wenn du die Toast messages für den WakeLock aktivierst (- am besten gleich mit # ) und du den Wake Befehl sendest während das Geräte an / wach ist - werden diese angezeigt ?

[ChristianHS]

Moin,

Woli und MegPad funktionieren hier bei mir einwandfrei. Das wird wohl eher mit dem Update deines Switches zusammenhängen. Ggf. mal den Switch und das MegaPad neu starten.

Grüße,

Krischan

[trax]

[tuxedo]

ChristianHS
Switch neu starten bringt nichts wenn's auch über die WLAN Verbindung nicht geht (die ja gar nicht an diesem Switch hängt).

in der Theorie aber auch nichts nützen

Hat auch nix genützt, wie erwartet.

is' doch alles bestens </Ironie> **heftiger Kraftausdruck**

Willkommen in meiner Xoro Megapad Welt :-)



Seit gestern Abend scheint es nun zu laufen. So 100%ig weiß ich nicht woran es lag, aber ich hab da eine Vermutung:

Warum Version 0.26 komplett ausgestiegen ist, sogar gecrashed ist und der "start Woli" button (trotz gefundenem MDT Router) nicht zu sehen war: Absolut kein kein Plan. Kann ich mir keinen Reim drauf machen.

Warum 0.37 auch so gezickt hat könnte an folgendem liegen

* Ich könnte schwören, dass es in v0.26 ausgereicht hat in der KNX Einstellung die GA + den Wakelock anzugeben. In 0.37 muss man jetzt auf der Hauptseite wakelock explizit einschalten? Könnte mich da aber auch kollosal irren.
* Auch scheint man - da bin ich mir aber nicht 100% sicher - den "Stern" neben dem WLAN/LAN auf der Hauptseite oben links "aktivieren" zu müssen, so dass dieser gelb wird. Hab das auch recht spät gesehen/entdeckt und entsprechend eingeschaltet/aktiviert
* In meiner Verzweiflung hatte ich wohl den Wakelock Fallback mit 1min eingerichtet. Das hat unter'm Strich irgendwie gar nicht funktioniert. Seit ich das gestern wieder auf 0 zurückgestellt habe läuft's nun. SOwohl über LAN als auch über WLAN

Abgesehen von den v0.26 Problemem die "spontan aufgetreten sind" und die ich im Leben nicht direkt auf das Firmwareupdate im Switch zurückführen kann, würde ich sagen mit 0.37 lag es einfach am Layer8... Hab den Workflow von Woli wohl erst so langsam angefangen zu verinnerlichen. Aus Usability-Sicht ist da sicherlich noch "room for improvement".

Aber sonst: Top App, Top Service.
Mein letzter Fallback wäre jetzt noch gewesen auf eine HW Lösung mit KONNEKTING zurück zu greifen (simulierte Maus- und/oder Keyboardtaste zum aufwecken). Aber die SW läuft ja wieder ...

[trax]

* Ich könnte schwören, dass es in v0.26 ausgereicht hat in der KNX Einstellung die GA + den Wakelock anzugeben.

Nö - das war von Anfang an so
Hab' auch nochmal gecheckt (GIT sei Dank)

* Auch scheint man - da bin ich mir aber nicht 100% sicher - den "Stern" neben dem WLAN/LAN auf der Hauptseite oben links "aktivieren" zu müssen,

... also müssen muss man nicht aber man sollte - da WOLi dann weiß dass dieses Netzwerk "zuhause" ist
Autostart funktioniert selbstverständlich ausschließlich in diesem Netz.

Aus Usability-Sicht ist da sicherlich noch "room for improvement".

Keine Frage, aber es ist (alles) dokumentiert und beschrieben: woli.asp1.at
Sehr gerne nehme ich Vorschläge entgegen.

läuft ja wieder ...

bestens !

[tuxedo]

Nö - das war von Anfang an so

..also müssen muss man nicht aber man sollte

Naja, hab ich mich wohl kollosal getäuscht. Was aber zumindest bei mir Fakt war: 0.26 hat sich komisch verhalten und ist gecrashed. Reset der App nicht gebracht. Nach dem Upgrade hat er wohl nur ein Teil der Einstellung (eigentlich nur die GA für den Wakelock) übernommen. Das hat wohl - was auch immer da die Ursache war - zur weiteren Verwirrung geführt.

Die Doku-Seite kenn ich. Da sind die einzelnen Funktionen beschrieben. Für den "Kenner" ist das ein leichtes. Für den Neueinsteiger nicht unbedingt.
Optimal wäre es, wenn die Anwendung das angeben der GA und die Verbindung zur Funktion "Wakelock" nicht zulässt wenn Wakelock gar nicht eingeschaltet ist. Optional könnte das hinzufügen einer GA mit einer Funktion die aktuell noch ausgeschaltet ist, diese Funktion dann implizit einschalten. Das würde Fehlkonfigurationen weiter unterbinden. Ist vom Prinzip her unintuitiv dass man den Zugang (KNX) konfigurieren kann und dort gleich Adressen angeben muss, die man mit Funktionen verbindet, die man an anderer Stelle erst noch einschalten/konfigurieren muss.

ODER man entfernt die Möglichkeit die GA in der KNX Einstellung hinzuzufügen und setzt das stattdessen in die Wakelock-Funktion rein. Das wäre wohl die sicherste Variante Workflow wäre dann:

* KNX einschalten und konfigurieren (nur den Zugang... mehr nicht).
* Dann die Funktion "Wakelock" (könnte man noch in "Displaysteuerung" umbenennen, dann können Anfänger auch was damit anfangen ohne das Handbuch zu lesen) einschalten
* und in deren Konfiguration angeben, dass GA x/y/z diese Funktion steuert.

Wäre sicher kein kleiner Umbau wie ich vermute, aber du wolltest ja Vorschläge ;-)

[jonofe]

tuxedo Läuft bei dir eigentlich Wakelock stabil über KNX? Bei mir reagiert es nach einer bestimmten Zeit nicht mehr. Ich verwende auch ein XORO Tablet (27"). UDP läuft dagegen stabil über Wochen hinweg.

[tuxedo]

Bis dato lief es stabil. Außer es gab so einen Moment wo gar nix mehr geht und ich hier im Thread auftauche ;-)

Habs mit einem MDT IP Router am laufen. "Könnte" mir vorstellen dass es im Tunneling Modus je nach Netzwerk (LAN, WLAN?) due sibscriptions an der KNX Schnittstelle "zumüllt"?

Wie hast du's denn eingestellt? Welche KNX Schnittstelle verwendest du mit welchem Setup in WOLI?

[jonofe]

Verwende es mit einer eibmarkt IP Schnittstelle oder eibd beide Interfaces im Tunneling Mode. Ggf. gibt es noch ein Problem dadurch, dass es zwei Interfaces sind.
Und dann natürlich ein GA dem WakeLock zugeordnet. Wenn es nicht mehr auf KNX reagiert, dann muss ich nur WOLi aufrufen, kurz Stop und wieder Start drücken, dann gehts wieder.

[trax]

Ggf. gibt es noch ein Problem dadurch, dass es zwei Interfaces sind.

mehrere KNX/IP Schnittstellen sollte seit V0.37 kein Problem mehr sein
- bitte unbedingt beobachten und rückmelden !

Ich habe mittlerweile eine Siemens N148/22 parallel zum eibd auf wirgate im Netz und keine Probleme mehr feststellen können.
Es gibt aber (theoretisch) ein Szenario das zu einem "Fehler führt:
- die Netzwerkverbindung ändert sich (warum auch immer)
- besteht eine Verbindung in ein lokales Netzwerk sucht WOLi die KNX/IP Gateways
- wird das zuvor ausgewählte Gateway nun NICHT gefunden, die/das Weitere(n) aber schon, wird versucht mit dieser eine Verbindung herzustellen.
- öffnet man nun in der WOLi App die KNX-Settings wird (sinniger Weise) nun dieses Gateway als ausgewählt betrachtet und gespeichert !
- beim nächsten Start (z.B. erneut durch eine Veränderung des Netzwerkstatus) würde nun aber das "falsche" Gateway benutzt auch wenn das ursprünglich wieder erreichbar wäre !

Der KNX-Watchdog müsste/sollte eigentlich einen Verbindungsabbruch abfangen - sprich erneut nach Gateways suchen und bei Erfolg verbinden.

Für WOLi ist - sofern möglich - routing zu bevorzugen (ich kann das leider nicht erklären, aber es läuft stabiler)

dann muss ich nur WOLi aufrufen, kurz Stop und wieder Start drücken, dann gehts wieder.

Wie immer ist von Interesse, was VOR dem Restart im Log zu finden ist ...
( ... nicht gut ist wenn da Link OK steht ...)

_{Randnotitz für die, die das noch nicht entdeckt haben:
Das WOLi-Log hat eine (zugegeben spärliche) Filter-Funktion - aber man kann damit die Log-Einträge auf "beliebigen Text" eingrenzen - z.B. "Action" liefert nur noch Einträge des ActionPerformers, oder "dog" liefert Einträges des KNX-Watchdogs}