Autor Thema: Problem: Fully verliert auf Wandtablet mit Tablet UI im Standby die Verbindung  (Gelesen 5825 mal)

Offline bruece-lee

  • Jr. Member
  • **
  • Beiträge: 88
Hallo,

ich habe seit einiger Zeit ein Wandtablet im Einsatz auf dem eine Übersichtsseite mit Tablet UI im "Fully Fullscreen Browser" dargestellt wird. Es handelt sich um ein Samsung Galaxy Tab A (2016) mit aktuellem Android 7.0. Zusätzlich installiert ist AMAD 4.0 mit der App Automagic, um mittels Homematic Bewegungsmelder bei erkannter Bewegung das Display einzuschalten, welches standardmäßig abgeschaltet ist. Der Lockscreen ist deaktiviert, es wird nur der Bildschirm abgeschaltet. Dies funktioniert wunderbar und 100% zuverlässig. Daraus schließe ich, dass die WLAN Verbindung zum Tablet auch im Standby zuverlässig aufrecht erhalten wird.

Was leider nicht funktioniert ist, dass Tablet UI die Verbindung zu FHEM aufrecht erhält und somit dauert es leider relativ lange, bis die Tablet UI Seite nach erneutem Einschalten des Bildschirms wieder aktuell ist. Bei Fully kann man in den Einstellungen die Funktion "Reload on Network reconnect" wählen, damit wird die Seite automatisch neu geladen, aber dies dauert leider relativ lange. Man bekommt auch eine Meldung, wenn die Netzwerkverbindung wiederhergestellt wurde, was eindeutig zeigt, dass Fully bei längerem Stndby die Verbindung zunächst verloren hat.

Hat jemand ähnliche Probleme? Kann dies vielleicht mit dem DozeMode von Android zusammenhängen, sodass Fully irgendwann schlafen gelegt wird? Ich habe schon alle Einstellungen unter Android durchprobiert, von denen ich mir Abhilfe versprochen habe. So habe ich sämtliche Stromsparfunktionen abgeschaltet und auch in Fully die Optionen angewählt, die dazu gedacht sind eine Verbindung aufrecht zu erhalten.

Hat jemand schon ähnliche Probleme gahbt und Lösungen dafür gefunden? Wie gesagt, das Problem besteht nur mit Fully, AMAD scheint die Verbindung zu halten. Es wäre ein riesiger Komfort-Gewinn, wenn sofort die aktuelle Tablet UI Seite angezeigt würde, wenn man vor das Tablet tritt und nicht erst mit 30-40 Sekunden Verzögerung.

Ich bin für jeden Tipp dankbar!

Viele Grüße,
Bruece-Lee

Offline aloz77

  • Full Member
  • ***
  • Beiträge: 495
Hallo, das WLAN-Verhalten im Standby ist bei Android eine große Magie. Und es wird mit jeder Android-Version etwas anders. Bei Android 6 und 7 ist es jedenfalls nicht so, dass die WLAN-Verbindung permanent aufrechterhalten wird. Du kannst z.B. ein Gerät im Standby nicht pingen. Aber irgendwie gelangen die Instant Messages trotzdem zeitnah zum Gerät, manchmal etwas verzögert. Das hat vermutlich mit Doze Mode und Mantainance Frames zu tun.

Fully Kiosk kann Standby verhindern (mit Optionen Keep Screen On oder Set CPU Wakelock). Wenn aber Standby nicht verhindert wird, nimmt Fully Kiosk m.W. keinen Einfluss darauf, was im Standby passiert. Wenn Fully anzeigt, dass die Netzwerk-Verbindung wiederhergestellt wurde, dann war sie m.E. systemweit weg. Wie stellst du fest, dass AMAD die Verbindung noch hält bzw. früher erlangt als Fully?

Offline dkreutz

  • Full Member
  • ***
  • Beiträge: 315
  • Home, Smart Home!
    • fhem-skill für Mycroft.ai
Ich habe auch lange mit Verbindungsabbrüchen gekämpft. Geholfen hat es letztendlich dem Android-Tablet eine feste IP zu geben (in der WLAN-Konfiguration eintragen). Seit dem habe ich keine Verbindungsabbrüche mehr, auch beim aufwachen aus dem Standby. Die feste IP sollte außerhalb der DHCP IP-Range (im Internetrouter konfiguriert) liegen.
Raspberry Pi3B+ (Stretch) / JeeLink868v3c (LaCrosse), nanoCUL433 (a-culfw V1.24.02), HM-MOD-UART (1.4.1), TEK603, MapleCUL / diverse Sensoren/Sender/Aktoren von Technoline, Intertechno, Shelly, Homematic und MAX!, Froggit Wetterstation, Luftdaten.info / Autor des fhem-skill für Mycroft.ai

Offline motopi

  • New Member
  • *
  • Beiträge: 32
Hallo,

ich habe auch ein Tablet(Fire 7 + root, ohne Amazon) mit dem gleichen, ungewünschten Verhalten. Habe Fully so eingestellt, dass er bei jedem Reconnect die Seite neu lädt.

Ich versuche es die Tage mal mit einer festen IP, wundert mich dass das so gehen soll...

Gruß

Offline bruece-lee

  • Jr. Member
  • **
  • Beiträge: 88
@aloz77: Ich habe in meinem Fully die beiden Optionen "Set CPU Wakelock" und "Set Wifi Wakelock" aktiviert, aber leider ohne Erfolg. Ich kann feststellen, dass AMAD die Verbindung immer hält, da über AMAD und einen Homematic Bewegungsmelder der Bildschirm des Tablets bei Bewegung eingeschaltet wird. Das funktioniert ohne Verzögerung und sehr zuverlässig.

@dkreutz: Ich habe mal getestet dem Tablet eine feste IP zu geben. Bislang habe die IP, die ursprünglich per DHCP vergeben wurde als feste IP vergeben, um in AMAD und Co. nichts ändern zu müssen. Geholfen hat es leider nicht. Warum sollte die fest vergebene IP außerhalb der DHCP-IP-Range liegen? Gibt es dafür eine Erklärung? Ich nutze eine Fritzbox und wüßte nicht, dass ich eine per DHCP vergebene IP nicht auch als feste setzen kann. Ich hatte in der Fritzbox bereits zuvor eingestellt, dass das Tablet immer die gleiche IP bekommen soll und habe es lediglich jetzt nochmal unter Android eingestellt. Aber wie gesagt löst das leider das Problem noch nicht.

Es gab jetzt jüngst nochmal ein Android Update für das Galaxy Tab A, aber am Verhalten hat dieses nichts geändert. Es ist auch immernoch Android 7.0.


Offline dkreutz

  • Full Member
  • ***
  • Beiträge: 315
  • Home, Smart Home!
    • fhem-skill für Mycroft.ai
Warum sollte die fest vergebene IP außerhalb der DHCP-IP-Range liegen? Gibt es dafür eine Erklärung? Ich nutze eine Fritzbox und wüßte nicht, dass ich eine per DHCP vergebene IP nicht auch als feste setzen kann. Ich hatte in der Fritzbox bereits zuvor eingestellt, dass das Tablet immer die gleiche IP bekommen soll und habe es lediglich jetzt nochmal unter Android eingestellt. Aber wie gesagt löst das leider das Problem noch nicht.
Für mich ist das einfach "best practice". Konfiguriere ich einem Gerät eine feste IP, so nehme ich dafür immer eine außerhalb der DHCP-Range. So kann ich immer identifizieren "woher" die IP kommt.
Vielleicht gibt es dafür auch noch eine technische Begründung irgendwo aus den Untiefen des DHCP-Protokolls und/oder OSI-Layer, die ein Netzwerktechniker erklären kann (ich habe mich während meines Informatik-Studium früh in Richtung Softwareentwicklung orientiert, weshalb ich die Netzwerktechnik-Vorlesung geschwänzt habe...)
Raspberry Pi3B+ (Stretch) / JeeLink868v3c (LaCrosse), nanoCUL433 (a-culfw V1.24.02), HM-MOD-UART (1.4.1), TEK603, MapleCUL / diverse Sensoren/Sender/Aktoren von Technoline, Intertechno, Shelly, Homematic und MAX!, Froggit Wetterstation, Luftdaten.info / Autor des fhem-skill für Mycroft.ai

Online CoolTux

  • Developer
  • Hero Member
  • ****
  • Beiträge: 20718
Natürlich gibt es eine tech. Begründung. Der DHCP Server kann nicht wissen das Du die IP welche in der Rangeliegt fest vergeben hast und vergibt sie an ein anderes Gerät welches eine Anfrage stellt.

Davon mal ab kann man aber einer MAC Adresse eine dauerhafte DHCP IP zuweisen. Dann gibt der DHCP Server dieser MAC immer die selbe IP
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.me/MOldenburg
FHEM GitHub: https://github.com/fhem/
kein Support für cfg Editierer

Offline Mave

  • Sr. Member
  • ****
  • Beiträge: 630
Der Router/DHCP Server vergibt aus der IP-Range dynamische IP-Adressen an anfragende Geräte, die auf DHCP eingestellt sind und keine feste IP-Adresse haben.

Ist ein Gerät auf DHCP eingestellt und fragt bei einem Router/DHCP Server nach einer dynamischen IP-Adresse an, bekommt es eine freie IP-Adresse zugeteilt. Diese kann bei jeder Anfrage anders sein.
Möchte man dem Gerät immer dieselbe IP-Adresse zuweisen lassen, kann man im Router/DHCP Server bei diesem Gerät ein Häkchen setzen. Somit bekommt dieses Gerät quasi eine "statische" IP-Adresse.
Der Router/DHCP Server vergibt diese IP-Adresse immer nur an dieses eine Gerät und an kein anderes. Das wird über die eineindeutige MAC-Adresse des Gerätes geregelt.

Von einer statischen IP-Adresse spricht man, wenn ein Gerät nicht über DHCP eine IP-Adresse anfordert, sondern eine eigene IP-Adresse fest eingestellt hat.

Was ich im Moment wirklich nicht weiß, ob ein Router/DHCP Server eine IP-Adresse aus der IP-Range vergibt, wenn es bereits ein Gerät im Netzwerk gibt, das eine statische IP-Adresse verwendet, die innerhalb der IP-Range liegt und diese IP-Adresse vom Router/DHCP Server noch nicht dynamisch vergeben wurde.
Der Router/DHCP Server kennt ja die statische IP-Adresse des Gerätes in "seinem" Netzwerk und sollte schlau genug sein, diese nicht erneut dynamisch zu vergeben. Aber ob er tatsächlich so schlau ist, kann ich nicht beurteilen.

Wo es definitiv knallt, ist, wenn eine IP-Adresse zuerst vom Router/DHCP Server dynamisch vergeben wurde und dann ein Gerät mit der exakt selben statischen IP-Adresse im Netzwerk auftaucht.

Deshalb tut man sehr gut daran, statische IP-Adressen ausserhalb der IP-Range zu verwenden.

Offline aloz77

  • Full Member
  • ***
  • Beiträge: 495
Zum ursprünglichen Problem: Reproduzieren kann ich das nicht. Beim Samsung-Gerät mit Android 7.0 gibt's zwei System-Einstellungen, die relevant sein könnten:

1. Verbindungen -> WLAN -> Erweitert -> WLAN im Standbymodus eingeschaltet lassen -> Immer

2. Gerätewartung -> Akku -> Nicht überwachte Apps -> Hier Fully Kiosk hinzufügen

Beides könnte auf den Akku-Verbrauch schlagen, aber hier hängt das Gerät eh am Strom, oder?

Zu FireOS kann ich nichts sagen. Es ist m.W. auf Android 5.0 basiert und die Problematik dort ist sicherlich eine ganz andere.

Offline cotecmania

  • Sr. Member
  • ****
  • Beiträge: 513
Hallo,

habe ein ähnliches Problem mit einem Acer Iconia 10" Tablet.
Wenn ich den Bildschirm anlasse, dann bleiben die Inhalte aktualisiert.
Sobald der Bildschirm ausgeht ist nach ein paar Minuten die Verbindung weg.
Hab auch schon alles an Einstellungen getestet aber es hat alles nichts gebracht.
So ist das als Wand-Tablet echt unbrauchbar und ich überlege schon, mir ein anderes zuzulegen.

Hat aber vor langer Zeit mal funktioniert ...
FHEM auf RaspberryPI B (jessie)
2xCUL868 für MAX/Slow_RF, HM-LAN, JeeLink
MAX!/HM-Thermostate, FS20/HM-Rolladenschalter, FS20-EM, LevelJet-Ölstandsmessung, PCA301, IT, KM271, IPCAM, ACER Iconia One mit AMAD/FTUI

Offline TheAbalone

  • New Member
  • *
  • Beiträge: 18
Mir ist das Problem auch vor ein paar Tagen aufgefallen. Davor hatte ich das nicht.

Liegt es vielleicht an einem Fullykioskbrowser Update?

Lg Berni

Update: Ich habe eine mögliche Fehlerquelle gefunden. Außerdem habe ich die Remote Möglichkeiten von Fully entdeckt. Hammer!
« Letzte Änderung: 26 Dezember 2018, 11:06:52 von TheAbalone »

Offline cotecmania

  • Sr. Member
  • ****
  • Beiträge: 513
Update: Ich habe eine mögliche Fehlerquelle gefunden. Außerdem habe ich die Remote Möglichkeiten von Fully entdeckt. Hammer!

Klasse. Wäre toll wenn Du uns an deine Erkenntnissen und Fehlerquellen auch teilhaben lässt.
So haben wir nix davon ...
FHEM auf RaspberryPI B (jessie)
2xCUL868 für MAX/Slow_RF, HM-LAN, JeeLink
MAX!/HM-Thermostate, FS20/HM-Rolladenschalter, FS20-EM, LevelJet-Ölstandsmessung, PCA301, IT, KM271, IPCAM, ACER Iconia One mit AMAD/FTUI

Offline TheAbalone

  • New Member
  • *
  • Beiträge: 18
Ich hatte gedacht, dass es daran liegt, dass ich meinen FHEM Server in der Nacht abschalte und dadurch ie Websocket Verbindung flöten geht. Aber heute hatte ich das Problem untertags.
Also wieder von Vorne...

Update: Ich habe jetzt die Webview Updates deinstalliert (zurückgefallen von v73 auf v49). Schaut bis jetzt richtig gut aus. Die Daten sind sogar schon aktuell, wenn das Display angeht.

Update2: Läuft immer noch, ohne einen einzigen Aussetzer.
« Letzte Änderung: 02 Januar 2019, 07:37:29 von TheAbalone »

Offline xl:bk

  • New Member
  • *
  • Beiträge: 24
Hallo zusammen,

ich hatte auf meinem Samsung Tab4 an der Wand ähnliche Probleme.
Danke für den Tipp mit dem WebView von Android. Nachdem ich hier die Updates wieder runter geschmissen habe, läuft alles problemlos. Auch bei mir sind die Daten aktuell, wenn das Display angeht.
FHEM auf Raspberry PI 3+, Stribel Eltron THZ 403sol Wärmepumpe

Offline sinus61

  • Full Member
  • ***
  • Beiträge: 490
Ich habe  gerade beiu meinem neuem Tab mit Android 8 auch das Problem. Da gibt es ja die Webview Komponente so als Extra nicht mehr, sondern es wird direkt die aus Chrome genutzt. Nach Ausschalten des Bildschirms ging beim Einschalten in FTUI erstmal nichts mehr. In Fully hab ich alles probiert, auch unter Android die WLAN und Akku Einstellung angepasst. Die Netzverbindung ist aber anscheinend auch immer da, per AMAD kann ich auf das Tablet zugreifen und auch den Screen einschalten. Eigentlich hilft für FTUI nur der Reload bei Screen On in Fully (ist aber optisch nicht so schön).

Zum Testen hab ich mal das in meine FTUI Seite eingebaut:

<div><div class="inline">Version: </div> <div data-bind="ftui.version" class="inline"></div></div>
<div><div class="inline">SP lastTimestamp: </div> <div data-bind="parseISOLocal(ftui.poll.short.lastTimestamp);" class="inline"></div></div>
<div><div class="inline">SP StatusText: </div> <div data-bind="ftui.poll.short.request.statusText" class="inline"></div></div>
<div><div class="inline">SP Duration: </div> <div data-bind="ftui.poll.short.duration" class="inline"></div></div>

<div><div class="inline">LP lastEventTimestamp: </div> <div data-bind="parseISOLocal(ftui.poll.long.lastEventTimestamp);" class="inline"></div></div>
<div><div class="inline">LP lastUpdateTimestamp: </div> <div data-bind="parseISOLocal(ftui.poll.long.lastUpdateTimestamp);" class="inline"></div></div>
<div><div class="inline">LP longPollType: </div> <div data-bind="ftui.config.longPollType" class="inline"></div></div>
<div><div class="inline">LP lastReading: </div> <div data-bind="ftui.poll.long.lastReading" class="inline"></div></div>

An den Timestamps sieht man schön, dass die FTUI Seite kurz nach Screen Off Shortpoll (also der default 15minütige Refresh aller Readings) und Longpoll (das sofortige aktualisieren der Readings) einstellt.

Also hab ich mal
<meta name="longpoll_type" content="websocket">auf
<meta name="longpoll_type" content="1">geändert.

Damit wechselt die Aktualisierung von Websocket auf Ajax. Jetzt funktioniert der longpoll wieder sofort bei Screen On, also ab dem Zeitpunkt kommen wieder Readings rein. Allerdings  sind die Readings die sich in der Screen Off Zeit geändert haben weiterhin nicht aktuell, der Shortpoll startet nicht von selbst wieder.

Zum Testen hab ich mal einen Button eingebaut:

<div data-type="symbol" data-icon="fa-refresh" data-background-icon="fa-circle" data-off-color="#2A2A2A" class="" onclick="ftui.states.lastShortpoll = 0;ftui.shortPoll();ftui.startShortPollInterval();"></div>

Das löst sofort einen Shortpoll aus und startet den Intervall wieder. Nach 2-3 Sekunden sind alle Readings da. Eigentlich müsste ich jetzt nur das Drücken des Buttons automatisieren, dann würde wieder alles gehen.

Offline sinus61

  • Full Member
  • ***
  • Beiträge: 490
Hab jetzt mal für mein Problem einen Workaround gebaut. Das angehängte Widget löst einen Shortpoll aus wenn sich im Amad-Device des Tablets das Reading screen auf "on unlocked" ändert, also der Bildschirm angeht. Dann werden sofort alle Readings erneuert.

Wenn also jemand FTUI und Amad nutzt und auch so ein Problem hat hilft das vielleicht.

In der FTUI Seite muß ganz oben hinter <body> das hier eingefügt werden:
<div data-type="shortpoll" data-device="wz_tablet" data-get="screen"></div>
und natürlich das Widgets in das Verzeichnis der FTUI Widgets gepackt werden.
Hilfreich Hilfreich x 1 Liste anzeigen

Offline torte

  • Developer
  • Full Member
  • ****
  • Beiträge: 457
Moin,

bei mir gibt es ähnliche Probleme. Sobald ich im Fully RemoteAdmin ausschalte läuft alles. Alle updates der Devices kommen dann sofort und das dann
tagelang in der FTUI an. Sobald ich aber RemotAdmin einschalte geht es ne Stunde manchmal auch nur 10 Minuten, erst wenn man dann die FTUI Seite aktualisiert
sind die Devices wieder UpToDate.
Bin auch ziemlich ratlos ob es am Tablet liegt oder was anderes ist, ist ein iWork 10 mit Android 5.1

Grüße
Torte


Offline cotecmania

  • Sr. Member
  • ****
  • Beiträge: 513
Also in folgendem Modus läuft mein Tablet nun wieder zuverlässig. Lediglich der Stromverbrauch steigt.
Es lädt ca. 2 mal pro Tag. Seither alle 2 Tage einmal.

Ein Touch auf den Bildschirm und alle Werte sind sofort da UND aktuell !!!

Das habe ich gemacht :
- Fully (PRO) gekauft
- Screen always on
- Screensaver aktiviert (60s, schwarzer Bildschirm 0x000000)

Gruss
Joe
FHEM auf RaspberryPI B (jessie)
2xCUL868 für MAX/Slow_RF, HM-LAN, JeeLink
MAX!/HM-Thermostate, FS20/HM-Rolladenschalter, FS20-EM, LevelJet-Ölstandsmessung, PCA301, IT, KM271, IPCAM, ACER Iconia One mit AMAD/FTUI

Offline Helmi55

  • Hero Member
  • *****
  • Beiträge: 1011
    • Helmi's Fotoseite
Servus
Funktioniert. Danke. Aber ganz schwarz ist der Screen nicht?
Oder ich mach was falsch.
Die Batterie steuere ich jetzt über AMAD und HM Steckdose.
Unter 25 % an, über 80 aus
Gruß Helmut
System1 fhem 5.9 auf RPi 3B, HMUSBConfig, DS9490R-1Wire, Busware USB 868, Pool-Solarsteuerung mit FHEM. System2 fhem 5.9 auf RPi 3B mit Busware USB 868 und 433 und HMUARTLGW für Haussteuerung

https://www.flickr.com/photos/canonhelmi/album

Offline cotecmania

  • Sr. Member
  • ****
  • Beiträge: 513
Japp, ganz dunkel ist er nicht, deshalb auch der erhöhte Energieverbrauch.
Fully bietet auch den Battery Level. Brauche somit AMAD nicht mehr.
FHEM auf RaspberryPI B (jessie)
2xCUL868 für MAX/Slow_RF, HM-LAN, JeeLink
MAX!/HM-Thermostate, FS20/HM-Rolladenschalter, FS20-EM, LevelJet-Ölstandsmessung, PCA301, IT, KM271, IPCAM, ACER Iconia One mit AMAD/FTUI

Offline Helmi55

  • Hero Member
  • *****
  • Beiträge: 1011
    • Helmi's Fotoseite
Servus
Frage wie hast du das ohne AMAD mit dem autom. Laden des Tablets gelöst?

Gruß
Helmut
System1 fhem 5.9 auf RPi 3B, HMUSBConfig, DS9490R-1Wire, Busware USB 868, Pool-Solarsteuerung mit FHEM. System2 fhem 5.9 auf RPi 3B mit Busware USB 868 und 433 und HMUARTLGW für Haussteuerung

https://www.flickr.com/photos/canonhelmi/album

Offline cotecmania

  • Sr. Member
  • ****
  • Beiträge: 513
Servus
Frage wie hast du das ohne AMAD mit dem autom. Laden des Tablets gelöst?

Gruß
Helmut

Mit einem DOIF
([FULLY_Iconia1:battery_level] > 95) (set PCA301_067DE4 off,{Log 3, "Tablet Iconia laden aus"}) DOELSEIF ([FULLY_Iconia1:battery_level] < 20) (set PCA301_067DE4 on,{Log 3, "Tablet Iconia Laden ein"})
FHEM auf RaspberryPI B (jessie)
2xCUL868 für MAX/Slow_RF, HM-LAN, JeeLink
MAX!/HM-Thermostate, FS20/HM-Rolladenschalter, FS20-EM, LevelJet-Ölstandsmessung, PCA301, IT, KM271, IPCAM, ACER Iconia One mit AMAD/FTUI

Offline Helmi55

  • Hero Member
  • *****
  • Beiträge: 1011
    • Helmi's Fotoseite
Ok danke. Dazu muss aber auch im Fully das "Show Battery Warning in den power Settings aktiviert werden oder ?
und jetzt noch eine blöde Frage - Fully_Iconia1 wie bekommst du den Namen ins FHEM damit es DOIF erkennt?

Herzlichen Dank
Helmut
« Letzte Änderung: 05 Februar 2019, 16:45:24 von Helmi55 »
System1 fhem 5.9 auf RPi 3B, HMUSBConfig, DS9490R-1Wire, Busware USB 868, Pool-Solarsteuerung mit FHEM. System2 fhem 5.9 auf RPi 3B mit Busware USB 868 und 433 und HMUARTLGW für Haussteuerung

https://www.flickr.com/photos/canonhelmi/album

Offline cotecmania

  • Sr. Member
  • ****
  • Beiträge: 513
Hallo Helmut

Du musst zuvor natürlich ein Device vom Typ FULLY anlegen, dann hast Du dort automatisch die Readings ...

Internals:
   DEF        192.168.1.69 passwort 60
   FUUID      5c4a1591-f33f-623c-5ba6-89a8945f8639e34f
   NAME       FULLY_Iconia1
   NR         987
   STATE      on
   TYPE       FULLY
   host       192.168.1.69
   nextUpdate 07.02.2019 20:18:44
   onForTimer off
   port       2323
   prot       http
   version    1.1
   READINGS:
     2019-02-07 20:16:47   acoustic_detection off
     2019-02-07 20:16:47   active_fragment screensaver
     2019-02-07 20:16:47   android_id      807772637d77d58c
     2019-02-07 20:16:47   android_version 5.1 (SDK 22)
     2019-02-07 20:16:47   app_code_data_cache ?/?/? KB
     2019-02-07 20:16:47   app_ram_used_free 13603/117468 KB
     2019-02-07 20:16:47   battery_level   58
     2019-02-07 20:16:47   brightness      1
     2019-02-07 20:16:47   current_page    http://192.168.1.150:8099/fhem/ftui/
     2019-02-07 20:16:47   device_admin    on
     2019-02-07 20:16:47   device_name     B3-A20
     2019-02-07 20:16:47   device_type     B3-A20 (Acer)
     2019-02-07 20:16:47   foreground_app 
     2019-02-07 20:16:47   fully_device_id 95197b05-28d825e6
     2019-02-07 20:16:47   fully_version   1.28.1
     2019-02-07 20:16:47   hostname        192.168.1.69
     2019-02-07 20:16:47   ip4_address     192.168.1.69
     2019-02-07 20:16:47   ip6_address     2A00:79C0:602:FE00:A23E:6BFF:FEAB:8B41
     2019-02-07 20:16:47   keyguard_locked off
     2019-02-07 20:16:47   kiosk_mode      off
     2019-02-07 20:16:47   last_app_start  05.02.2019 1:25:20 nachm.
     2019-02-07 20:16:47   mac_address     a0:3e:6b:ab:8b:41
...
...


also

define FULLY_Iconia1 FULLY 192.168.1.xxx passwort 60
Gruss
Joe
« Letzte Änderung: 07 Februar 2019, 20:35:20 von cotecmania »
FHEM auf RaspberryPI B (jessie)
2xCUL868 für MAX/Slow_RF, HM-LAN, JeeLink
MAX!/HM-Thermostate, FS20/HM-Rolladenschalter, FS20-EM, LevelJet-Ölstandsmessung, PCA301, IT, KM271, IPCAM, ACER Iconia One mit AMAD/FTUI

Offline Helmi55

  • Hero Member
  • *****
  • Beiträge: 1011
    • Helmi's Fotoseite
Ups -sorry das hatte ich übersehen das es für Fully auch schon ein Modul gibt.
Damit ist jetzt alles klar. Danke und das mit der Batterie funktioniert super.
Mal sehen ob die Abstürze und Hänger am Lenovo nun vorbei sind. ich hoffe es

Danke
Gruß
Helmut
System1 fhem 5.9 auf RPi 3B, HMUSBConfig, DS9490R-1Wire, Busware USB 868, Pool-Solarsteuerung mit FHEM. System2 fhem 5.9 auf RPi 3B mit Busware USB 868 und 433 und HMUARTLGW für Haussteuerung

https://www.flickr.com/photos/canonhelmi/album

 

decade-submarginal