WOLi2

[trax]

... Moment - langsam
Die Frage war:

2) Gibt es eine Möglichkeit einen Shortcut vom Homescreen/Desktop zu starten, ohne zusätzliche Apps wie Tasker installieren zu müssen?

... hat ja nix mit Webapp(s) zu tun - was auch immer damit gemeint ist

Um im Std. Webbrowser eine URL zu öffnen hat WOLi die doch BrowseTo-Funktion (URLs)


... btw: Google liefert zwar Antworten - aber nicht immer auf deine Frage !

[toggle]

Inwiefern funktioniert SendIntent anders als erwartet - was hast du denn erwartet ?

[Edit] ... ich denke ich weiß was du meinst: - einen "allgemeinen" Intent-(BroadCast)-Sender (wie. z.B. in Tasker) - nun ... das würde zwar gehen -- aber keine Lösung für dein Problem darstellen... Der "HomeScreen" ist eine App (Activity) die, um in den Vordergrund zu kommen, gestartet werden muss - es existiert also nichts was auf einen Broadcast reagieren würde ...

Ich dachte da an so etwas wie (gegoogelt):

 
 #Intent;action=com.google.android.apps.chrome.webapps.WebappManager.ACTION_START_WEBAPP;package=com.android.chrome;S.org.chromium.chrome.browser.webapp_id=xyxyxyx-yxyxxyx-xxyxx-xyyy-yxxxxyxyxx;S.org.chromium.chrome.browser.webapp_url=http%3A%2F%2F192.168.177.100%2Fvisu;end

Möglicherweise habe ich zu viel in die Deutung dieser Zeile interpretiert...

[toggle]

Launcher (Apps) gibt es viele - standardmäßig am Galaxy Tab S (glaub auf allen Samsung Geräten) TouchWiz (com.sec.android.app.launcher)

Mir ist nur nicht klar, wie ich dem Launcher beibringen kann, dass er meine Webapp startet, bzw. wie ich das in WOLi umsetze.

[trax]

Launcher (Apps) gibt es viele - standardmäßig am Galaxy Tab S (glaub auf allen Samsung Geräten) TouchWiz (com.sec.android.app.launcher)
An der Stelle sei mal NOVA empfohlen ...

Inwiefern funktioniert SendIntent anders als erwartet - was hast du denn erwartet ?

[Edit] ... ich denke ich weiß was du meinst: - einen "allgemeinen" Intent-(BroadCast)-Sender (wie. z.B. in Tasker) - nun ... das würde zwar gehen -- aber keine Lösung für dein Problem darstellen... Der "HomeScreen" ist eine App (Activity) die, um in den Vordergrund zu kommen, gestartet werden muss - es existiert also nichts was auf einen Broadcast reagieren würde ...

[toggle]

[Edit]... in der kommenden Version brauchst du den WakeLock auch nicht mehr zurücksetzten - einfach ein Timeout eingeben.

Das klingt sehr praktisch!

ad 2) theoretisch könntest du WOLi's APP-Launcher nutzen und die Launcher-App des Systems starten
da ich die Funktion für brauchbar halte, wird die kommende Version jedenfalls eine Möglichkeit bieten.

Welche Launcher-App meinst du? Ich hoffte, dass man etwas mit Intent (z.B. an WebView) machen könnte, aber SendIntent scheint anders zu funktionieren, als ich erwartet hatte.

[trax]

ad 1) hier gibt es leider nichts was du tun könntest.
aber die Limitierung betrifft nur den WakeLock (hat techn, Gründe und könnte vrmtl. noch optimiert werden)
- sende also diesen zuletzt, dann kannst du davor kürzere Intervalle verwenden (getestet 0.1 Sekunden - für noch kürzer habe ich kein zuverlässiges TestTool)
[Edit]... in der kommenden Version brauchst du den WakeLock auch nicht mehr zurücksetzten - einfach ein Timeout eingeben.

ad 2) theoretisch könntest du WOLi's APP-Launcher nutzen und die Launcher-App des Systems starten
da ich die Funktion für brauchbar halte, wird die kommende Version jedenfalls eine Möglichkeit bieten.

[toggle]

trax
Ich hätte zwei Fragen:
1) WOLi kann auf meinem Tab S UDP-Pakete scheinbar nur alle 0.5 Sekunden empfangen. Sende ich schneller, gehen sie verloren. Es geht mir nicht um eine "Dauerlast", sondern um drei aufeinander folgende Aktionen: Aufwecken, Edomi anzeigen und Display-Lock zurücksetzen. Mir ist aufgefallen, dass im Log die "Pausen" etwas großzügig ausfallen:

25.01.2017 / 18:08:27 .955 > 0 <
UDPWorker -- UDP-Packet received: wolido:display1
25.01.2017 / 18:08:[B][COLOR=#FF0000]27 .959[/COLOR][/B] > 0 <
ActionPerformer -- wakeup: 1
25.01.2017 / 18:08:[COLOR=#FF0000][B]28 .466[/B][/COLOR] > 0 <
UDPWorker -- UDPReceiverStatus: true

Diese Pause ist völlig unabhängig davon, ob das Gerät im Standby war oder aktiv. Ist es eine Besonderheit von Tab S (6.0.1) oder gibt es irgendwas, was ich tunen kann?
2) Gibt es eine Möglichkeit einen Shortcut vom Homescreen/Desktop zu starten, ohne zusätzliche Apps wie Tasker installieren zu müssen?

Gruß
toggle

[trax]

Allerdings nach einiger scheint die KNX Verbindung dann verloren zu gehen

das Phänomen dass die Tunneling-Verbindung irgendwann weg ist habe ich auch ... allerdings konnte ich noch keine exakte Zeit ausmachen.
Im virtuellen Gerät passiert das nicht .. weshalb das Debuging schwierig ist
Übrigens gehts auch mit auch HearBeat nicht...
Die Lösung die für V0.36 geplant ist, sieht einen Timer vor der regelmäßig die KNX Verbindung prüft.

Diese drei Meldungen innerhalb von 8 Tausendstel Sekunden

Die drei Meldungen finden nahezu zeitgleich statt ... und verdeutlichen, dass die Activity (APP) sich erfolgreich mit dem Hintergrundservice verbunden und den Status abgefragt hat. (Der Zeitversatz kommt hauptsächlich beim Eintragen ins Log zustande...)

WakeUp... kurze PopUp Nachricht

Für 0.36 ist geplant dem WakeLock zusätzliche Einstellungen zu verpassen. Jedefalls autom. Fallback und die Toast (PopUp) Nachricht

[jonofe]

Bei mir lässt es sich nun mit KNX Tunneling wie bereits erwähnt starten und läuft dann auch. Allerdings nach einiger scheint die KNX Verbindung dann verloren zu gehen, ohne das WOLI es bemerkt. Sende ich dann nach z.B. 3h wieder mal die KNX GA zum Wakeup, dann erscheint im Log nur noch:

WOLIActivity - WolisService Connected
WOLIActivity - WolisState ON
WOLIActivity - WolisState ON

Diese drei Meldungen innerhalb von 8 Tausendstel Sekunden.

Erst wenn ich dann wieder STOP WOLI und START WOLI klicke, dann gehts wieder und ich sehe im Log eine erfolgreiche Tunneling Verbindung, die mit dem Logeinttrag KNXWorker--... started endet. Danach funktioniert es dann erstmal wieder.

EDIT: Noch eine Frage: Beim UDP WakeUp wird beim Ein- und Ausschalten ja jeweils eine kurze PopUp Nachricht angezeigt. Kann man das bei KNX auch machen? Und es ggf. für beide Varianten (UDP und KNX) auch abschaltbar machen.

EDIT2: Kann es sein, dass die Tunnelingverbindung ggf. ein Keepalive braucht, damit sie nicht disconnected?
Habe jetzt mal Heartbeat aktiviert. Mal sehn, ob dann die Verbindung erhalten bleibt.

[trax]

Interessanterweise liefert sie keine Multicast Adresse, sondern nur 0.0.0.0. Aber Woli akzeptiert das, zumindest im Log und gibt eine Erfolgsmeldung.

Das lässt sich abfangen, da Multicast-Adressen ab 224.0.0.0 beginnen ...
Weshalb der NetworkLink bzw. die KNX Verbindung trotzdem als gültig erkannt wird, bleibt ein Rätsel ...

Jetzt funktioniert es genau so wie es soll! SUPER!

[trax]

Das Wiregate nutzt selbst auch das IP Interface (welches 5 Tunnelverbindungen kann).

Ich bin mir beim Weinzierl 730 nicht sicher ob es mehrere Clients kann ... so wie ich das verstanden habe dient diese Schnittstelle zur "Verbindung eines Clients (PC) mit einer Buslinie." ( siehe http://www.weinzierl.de/images/downl...over_IP_DE.pdf )

Hast du mit V035.2 noch immer die Verbindungsprobleme ?

[jonofe]

ich denke es liegt / lag an WOLi
... ich kann derzeit leider nicht testen ob es ein Problem mit mehren Schnittstellen geben könnte,
aber beim Versuch eine Tunneling-Verbindung aufzubauen kann(konnte) vorab was schief gehen,
weshalb dann scheinbar meist der Tunnel nicht klappt ...
In V035.2 ist das mal "verändert" - ich hoffe behoben

Meiner Meinung nach ist routing (sofern vorhanden) jedenfalls zu bevorzugen.
bzw. tunneling irgendwie nicht stabil zu sein scheint und WOLi derzeit nicht immer mitbekommt,
dass die Verbindung beendet ist... (da bin ich auch grad dran)

Jetzt funktioniert es genau so wie es soll! SUPER!
Verbindung wird erfolgreich aufgebaut und auch die GA korrekt erkannt.
Werde jetzt mal beobachten, ob es weiterhin stabil läuft.
Vielen Dank für dieses tolle Tool!

[irgendwer]

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.

Genauso ist es bei mir mit dem eibd am Wiregate auch. Das Wiregate nutzt selbst auch das IP Interface (welches 5 Tunnelverbindungen kann). Habe leider keines übrig, sonst würde ich es als Leihe zur Verfügung stellen.

[jonofe]

ich denke es liegt / lag an WOLi
... ich kann derzeit leider nicht testen ob es ein Problem mit mehren Schnittstellen geben könnte,
aber beim Versuch eine Tunneling-Verbindung aufzubauen kann(konnte) vorab was schief gehen,
weshalb dann scheinbar meist der Tunnel nicht klappt ...
In V035.2 ist das mal "verändert" - ich hoffe behoben

Meiner Meinung nach ist routing (sofern vorhanden) jedenfalls zu bevorzugen.
bzw. tunneling irgendwie nicht stabil zu sein scheint und WOLi derzeit nicht immer mitbekommt,
dass die Verbindung beendet ist... (da bin ich auch grad dran)

Wirklich Interessant ist dass die eibmarkt-Schnittstelle scheinbar eine Multicast-Adresse auf Anfrage liefert
eigentlich müsst der Verbindungsversuch fehlschlagen...
... ist vielleicht auch der Grund weshalb der eibd nicht funktioniert (muss der einzige router im Netz(segment) sein !)

Interessanterweise liefert sie keine Multicast Adresse, sondern nur 0.0.0.0. Aber Woli akzeptiert das, zumindest im Log und gibt eine Erfolgsmeldung.

[trax]

ich denke es liegt / lag an WOLi
... ich kann derzeit leider nicht testen ob es ein Problem mit mehren Schnittstellen geben könnte,
aber beim Versuch eine Tunneling-Verbindung aufzubauen kann(konnte) vorab was schief gehen,
weshalb dann scheinbar meist der Tunnel nicht klappt ...
In V035.2 ist das mal "verändert" - ich hoffe behoben

Meiner Meinung nach ist routing (sofern vorhanden) jedenfalls zu bevorzugen.
bzw. tunneling irgendwie nicht stabil zu sein scheint und WOLi derzeit nicht immer mitbekommt,
dass die Verbindung beendet ist... (da bin ich auch grad dran)

Wirklich Interessant ist dass die eibmarkt-Schnittstelle scheinbar eine Multicast-Adresse auf Anfrage liefert
eigentlich müsst der Verbindungsversuch fehlschlagen...
... ist vielleicht auch der Grund weshalb der eibd nicht funktioniert (muss der einzige router im Netz(segment) sein !)