Neues Modul FULLY für Steuerung vom Fully Browser

[zap]

Ja, wenn das Fire aus geht, kommt beim Einschalten immer der Lockscreen. Das lässt sich auch nicht weg konfigurieren. Nur eben mit dem Workaround, dass das Tablet an bleibt und Fully lediglich die Helligkeit auf 0 setzt. Allerdings ist das kein richtiges Standby, d.h. der Stromverbrauch dürfte höher sein.

Ich hatte auch mal ein Fire Tablet und habe es wegen dieser Unzulänglichkeiten durch ein Galaxy Tab ersetzt.

[australien]

Danke für eure Infos. Dachte mir schon so etwas ähnliches.
Nur kann ich damit also die Motion Erkennung nicht verwenden, es wird ja nirgends ein Reading verändert.

[gloob]

Danke für eure Infos. Dachte mir schon so etwas ähnliches.
Nur kann ich damit also die Motion Erkennung nicht verwenden, es wird ja nirgends ein Reading verändert.

Motion funktioniert trotzdem. Hab es bei mir so am laufen auf eine Fire HD8.

[australien]

Das werde ich nächste Woche probieren!
Danke euch alle !

[zap]

Motion Detection frisst viel Energie. Das Tablet sollte in diesem Fall besser permanent am Strom hängen.

Die Readings werden zyklisch oder nach Ausführung eines Befehls aktualisiert. Fully bietet jedoch ein JavaScript API an. Damit könnte man z.B. beim Aufwachen des Tablets einen FHEM Befehl absetzen.

Der Aufruf erfolgt z.B. so

fully.bind('onMotion','todo();')

Todo wäre dann die Funktion, die den FHEM Befehl absetzt. Das Ganze ist auf der Fully Homepage recht gut dokumentiertt.

[australien]

Strom ist nicht das Problem, hängt sowieso permanent dran.

Das mit dem JavaScript hört sich gut an, leider hab ich da überhaupt keine Ahnung.

[DS_Starter]

Hallo zap,

ich betreibe zwei Wandtablets mit dem Fully-Browser und dem Fully-Modul zur Steuerung.
Bei einem dieser Tablets habe ich das Problem, dass ein "set .. restart" fast immer die Meldung generiert  "FULLY: Command failed" obwohl das Kommando selbst ausgeführt wird !
Bei anderen Kommandos kommt diese Meldung hingegen nicht.

Bug im Modul ?

Grüße,
Heiko

[zap]

Die Meldung tritt nur bei set restart auf, nicht bei anderen Befehlen?

[DS_Starter]

Morgen zap,

Die Meldung tritt nur bei set restart auf, nicht bei anderen Befehlen?

Ja, richtig. Bei anderen Befehlen habe ich es noch nicht festgestellt. Habe diese Meldung auch nur bei einem meiner Wandtablets (Google Nexus) festgestellt.
In allen Fällen wird der Befehl korrekt durchgeführt, trotz Meldung.
Irgendein Zeitproblem ?

[Phiolin]

Seit ein paar Tagen sehe ich regelmäßig diese Fehler im Log:
Stammt wohl von der Versionsnummer.

Code Auswählen Erweitern

2018.10.21 22:19:14 1: PERL WARNING: Argument "1.27.2" isn't numeric in numeric lt (<) at ./FHEM/89_FULLY.pm line 535.
2018.10.21 22:19:14 1: stacktrace:
2018.10.21 22:19:14 1:     main::__ANON__                      called by ./FHEM/89_FULLY.pm (522)
2018.10.21 22:19:14 1:     main::FULLY_ProcessDeviceInfo       called by ./FHEM/89_FULLY.pm (500)
2018.10.21 22:19:14 1:     main::FULLY_GetDeviceInfo           called by FHEM/Blocking.pm (194)
2018.10.21 22:19:14 1:     main::BlockingStart                 called by FHEM/Blocking.pm (107)
2018.10.21 22:19:14 1:     main::BlockingCall                  called by ./FHEM/89_FULLY.pm (484)
2018.10.21 22:19:14 1:     main::FULLY_UpdateDeviceInfo        called by /opt/fhem/fhem.pl (3142)
2018.10.21 22:19:14 1:     main::HandleTimeout                 called by /opt/fhem/fhem.pl (649)


Code Auswählen Erweitern

Internals:
   DEF        1.2.3.4 passwort 20
   NAME       mein.name
   NR         377
   STATE      on
   TYPE       FULLY
   host       10.0.0.62
   nextUpdate 27.10.2018 09:22:59
   onForTimer off
   version    0.9
   READINGS:
     2018-10-27 09:22:39   acoustic_detection off
     2018-10-27 09:22:39   active_fragment main
     2018-10-27 09:22:39   android_id      4713439d4a714fcf
     2018-10-27 09:22:39   android_version 7.0 (SDK 24)
     2018-10-27 09:22:39   app_code_data_cache ?/?/? KB
     2018-10-27 09:22:39   app_ram_used_free 7774/188833 KB
     2018-10-27 09:22:39   battery_level   100
     2018-10-27 09:22:39   brightness      255
     2018-10-27 09:22:39   current_page    http://1.2.3.4/
     2018-10-27 09:22:39   device_admin    on
     2018-10-27 09:22:39   device_type     SM-T580 (samsung)
     2018-10-27 09:22:39   foreground_app  de.ozerov.fully
     2018-10-27 09:22:39   fully_device_id 6ce1cbbc-d6d840b8
     2018-10-27 09:22:39   fully_version   1.27.2
     2018-10-27 09:22:39   hostname        my.host.name
     2018-10-27 09:22:39   ip4_address     1.2.3.4
     2018-10-27 09:22:39   ip6_address     
     2018-10-27 09:22:39   keyguard_locked on
     2018-10-27 09:22:39   kiosk_mode      on
     2018-10-27 09:22:39   last_app_start  19.10.18 10:48:19
     2018-10-27 09:22:39   location        ...
     2018-10-27 09:22:39   mac_address     20:8E:E0:5A:0D:48
     2018-10-27 09:22:39   maintenance_mode off
     2018-10-27 09:22:39   motion_detection off
     2018-10-27 09:22:39   movement_detection off
     2018-10-27 09:22:39   power           plugged
     2018-10-27 09:22:39   screen          1920x1200 px
     2018-10-27 09:22:39   screen_status   on
     2018-10-27 09:22:39   serial          33002a1826626547
     2018-10-27 09:22:39   start_url       http://x.y.z/
     2018-10-27 09:22:39   state           on
     2018-10-27 09:22:39   total_ram_used_free 1136352/856532 KB
     2018-10-27 09:22:39   webview_version 70.0.3538.64
     2018-10-27 09:22:39   wifi_ssid       "xyz"
   fully:
     password   fltabletwo67
     schedule   0
Attributes:
   event-on-change-reading .*
   pollInterval 20
   room       Flur

[tomcat.x]

@ Phiolin: Ist das (1.27.2) eine Beta-Version von Fully? Aktuelle Version ist "1.28" und das ist dann wieder numerisch. Wenn Du ein Fully Update auf 1.28 machst, dürfte das auf jeden Fall Dein aktuelles Problem lösen.

[zap]

Ich habe gerade ein Update eingecheckt. Damit sollten die Logmeldungen bei der Versionsprüfung verschwinden und auch Versionen wie z.B. 1.28-fire korrekt erkannt werden. Da ich keine solche Version im Einsatz habe, Bitte an die Betroffenen, das zu testen.

Morgen per FHEM update, heute direkt aus dem SVN.

[zap]

Morgen zap,
Ja, richtig. Bei anderen Befehlen habe ich es noch nicht festgestellt. Habe diese Meldung auch nur bei einem meiner Wandtablets (Google Nexus) festgestellt.
In allen Fällen wird der Befehl korrekt durchgeführt, trotz Meldung.
Irgendein Zeitproblem ?

Ja, möglich. Ich kann das bei mir nicht nachvollziehen. Ich habe folgende Attribute gesetzt:

pingBeforeCmd = 1
requestTimeout = 8

Der Neustart der App klappt ohne Fehlermeldung.

[DS_Starter]

Attribut "requestTimeout " hat's gebracht. Ich musste es bis auf 14 Sekunden setzen.
Komischerweise wird der Befehl zügig umgesetzt (ich habe davor gestanden)... aber gut.
Danke, damit kann ich gut leben 

Grüße
Heiko

[zap]

Jedes Tablet braucht unterschiedlich lang, um aus dem Standby aufzuwachen. pingbeforecmd kann das etwas abmildern, jedoch reagiert nicht jedes Tablet auf einen Ping mit Aufwachen.

Die nächste Version vom Modul kann wahlweise Befehle per BlockingCall ausführen, sodass FHEM bei langem Timeout nicht mehr blockiert.