First of all, I know a lot of people have been using the Fully Kiosk Browser on Android for displaying HA, or Floorplan, which works great (I use it myself). But I haven’t come across a write up describing what else you can do with Fully, so I thought I’d share that here.
So, besides installing Fully on an Android device, setting the start URL to your HA URL, and putting it in kiosk mode, it also has a plethora of sensors, and even switches you can control from HA.
The Fully browser is also capable of reporting motion via the camera, or gyroscope. I experimented with this a bit, but had some erratic behavior. Your mileage may vary.
note, in order for the below to work, you’ll need a (Plus) license for Fully, which is a few bux at the time of this writing. You’ll also need to enable the “Remote Admin” in settings, which enables the device info, screen-switch (below), and REST interface.
For instance, here’s a list of some of the sensors that I monitor, and pull into HA:
batterylevel, kioskmode, screenbrightness, motiondetectorstate, maintenancemode, appfreememory, appusedmemory, totalfreememory, totalusedmemory, hostname4, ip4, mac, locationlatitude, locationlongitude, locationaltitude, starturl, currentpage.
I’ve also setup the ability to turn the screen on/off from HA. Which works great for not-home, or asleep automations.
The sensors are polled into HA via the REST API (documented on the website). What I’ve done is, create a single rest sensor, with the name of the device, and the value of “isScreenOn”. Then using the json_attributes list I’ve pulled in the rest of the values, and stored them as attributes to the original sensor. So at the end of the day, you’ve got a sensor named, ‘foo’ with a value of ‘on’ (or off depending on screen state), but this sensor has a large list of attributes, that you can use elsewhere. I’ll go more into this later.
Here’s what the REST sensor looks like (sensors.yaml):
- platform: rest name: foo json_attributes: - batteryLevel - kioskMode - screenBrightness - motionDetectorState - maintenanceMode - appFreeMemory - appUsedMemory - totalFreeMemory - totalUsedMemory - hostname4 - ip4 - mac - locationLatitude - locationLongitude - locationAltitude - startUrl - currentPage resource: !secret foo_rest value_template: '{{ value_json.isScreenOn }}'
The foo_rest is set to the following, in my secrets file:
http://[device-IP]:2323/?cmd=deviceInfo&type=json&password=[Fully Password]
Then I decided to break out the “Battery Level” from the sensor.foo attribute, which looks like this:
- platform: template sensors: foo_battery_level: friendly_name: "foo_battery_level" unit_of_measurement: '%' value_template: "{{ states.sensor.foo.attributes.batteryLevel }}"
You could do this for any of the sensor values listed above, which could give each attribute it’s own sensor. Seems a little bloated if you ask me, but it’s possible!
So now I have 2 sensors in HA, one for the state of the screen, and another for the battery level. Which was great to detecting if the battery was getting low, or to verify if the screen was actually on (or not).
But I really wanted to be able to turn the screen on or off, from HA, and more importantly, from automations!
So I wasn’t able to find a way to cleanly do this through the REST API, though I haven’t dug too far into it either. What I did find, is the ability to send a specific HTTP POST/GET command, and control the screen state that way. In practice, it actually works great, every time! It’s a little “hacky”, but it works.
switches.yaml:
- platform: command_line switches: foo_screen: command_on: !secret foo_screen_on command_off: !secret foo_screen_off command_state: !secret foo_screen_state value_template: '{{ value == "on" }}' friendly_name: Foo Screen
Secrets.yaml:
foo_screen_on: "/usr/bin/curl -X POST 'http://[device-IP]:2323/?cmd=screenOn&type=json&password=[Fully Password]'" foo_screen_off: "/usr/bin/curl -X POST 'http://[device-IP]:2323/?cmd=screenOff&type=json&password=[Fully Password]'" foo_screen_state: '/usr/bin/curl --silent -X GET "http://[device-IP]:2323/?password=[Fully Password]" |grep "Screen status" |grep "on\|off" |sed "s/<[^>]*>//g" |sed "s/Screen status//g" |sed "s/Turn on//g" |sed "s/Turn off//g"'
When that’s in place, you’ll have a switch called switch.foo_screen which will allow you to control the state of the screen, through the UI, or automations!
Now, whenever you leave the house, you can turn the tablet screen off, as well as all your lights. I’ve been using this for a few months, and it works great!
Anyways, I’m sure there’s better ways of doing some of this, but the above works great for me! If you try to get it setup, and run into issues, let me know, I’ll do my best to answer them.
Todo: Swap out the “foo_screen_state” curl command for the REST attribute from above. Less-Hacky == Better.
EDIT: As illistrated below by @Hefford27 here’s an example of how to send TTS messages to Fully:
- platform: command_line switches: dashdiningdisarmnotify: command_on: /usr/bin/curl -k "http://TabletIP:2323/?cmd=textToSpeech&text=The+House+Alarm+Has+Been+Disarmed&password=FullyOpenKisokPassword" friendly_name: Dining Room Dashboard Nofify Alarm Disarmed Open
Happy Automating!
