Is this the perfect standalone tablet for HA?

No, doesn’t work.

But I got a little further. Sending the wake command over mqtt (Wallpanel app) does turn on the screen immediately.
it works as indicated in the WallPanel documentation:

json payloads sent to the mqtt topic: wallpanel/mywallpanel/command

  • wake: {"wake": true}
    it also seems to “reset” the issue with the screen not timing out, since the screen goes back to sleep after the timeout when sending that command.
This returned the following logs in logcat:
01-21 10:10:36.142  1206 13999 D AppOps  : noteOperation: allowing code 23 uid 10069 package
01-21 10:10:36.146  1206 13999 D AppOps  : noteOperation: allowing code 23 uid 10069 package
01-21 10:10:36.312   672   705 E libnav  : CablComputeBacklightLevel(): UpdateType = DifferentSceneUpdate
01-21 10:10:36.328   672   705 E libnav  : CablComputeBacklightLevel(): UpdateType = DifferentSceneUpdate
  • screen off: {"wake": false}
    doesn not work and does not produce any log entries in logcat either.
    however, the adb shell input keyevent 26 still works to turn off the screen, even when it’s stuck on

I tried testing a few other mqtt commands, but they did have no effect (again: not even logcat entries).
the {"settings": true} command does work, and open the WallPanel settings, however, if the screen times out / or was already timed out before, apparently it blocks further mqtt commands from being executed.
From that state (being in the settings menu) I tried to go back to the Home Assistant dashboard using the {"url":<http://....>} command, but that one didn’t work either. So best to avoid opening the settings over mqtt.

The {"url":<http://....>} does work (when not being stuck in the settings), so it can be used to load a specific dashboard - even if that takes 2-3 seconds to complete.

Sadly, the screenOn Parameter in the wallpanel/mywallpanel/state topic doesn’t work, and does not correctly report the screen state (neither does the brightness level).
So at the moment, we can’t get the current screen state without actually polling them using adb commands.

However, it seems, we can at least turn on the screen in Home Assistant using the mqtt command, and turn if off again using an adb command (there is an ADB integration, I’m going to test that next)

1 Like

The ADB integration in Home Assistant seems to work fine for turning off the screen, not so much for turning it off though - but at the moment I feel like this is the more important issue anyway.

When using the WallPanel app, you can actually even use the media player entity, to turn off the screen. Example action:

service: media_player.turn_off
metadata: {}
data: {}
  device_id: <home_assistant_id_for_thinksmart_view>

If not, an ADB action works perfectly fine too:

service: androidtv.adb_command
metadata: {}
  command: input keyevent 26
  device_id: <home_assistant_id_for_thinksmart_view>

The media_player.turn_on action doesn’t work to turn on the screen - as expected

In order to wake up the device, the following action can be used (using the MQTT integration and WallPanel’s mqtt capabilities:

service: mqtt.publish
metadata: {}
  qos: "1"
  payload: "{\"wake\": true}"
  topic: wallpanel/mywallpanel/command

So with these actions, we can at least automate turning on and off the tablet, depending on some Home Assistant triggers (e.g. entering/leaving the area, detected movement, lights turning on/off, etc…)

For the ADB command to work, ADB debugging over network/tcp needs to be enabled. In order to do that, you need to connect to the device using ADB over USB port once and enable ADB over network as indicated above:

The only issue is, that after a reboot of the device, ADB is not acessible over network any more. However, luckily there’s a work-around for that as well, though it involves actually interacting with the tablet:

Maybe there is a way to actually properly persist the ADB over network setting?

1 Like

Getting this error even though i replaced the libsub drive as suggested. Did you see this/know a fix?

 ...Traceback (most recent call last):
  File "C:\Users\scott\edl\edl", line 386, in <module>
  File "C:\Users\scott\edl\edl", line 289, in run
    conninfo = self.doconnect(loop)
  File "C:\Users\scott\edl\edl", line 199, in doconnect
    self.cdc.connected = self.cdc.connect(portname=self.portname)
  File "C:\Users\scott\edl\edlclient\Library\Connection\", line 240, in connect
    self.configuration = self.device.get_active_configuration()
  File "C:\Users\scott\AppData\Local\Programs\Python\Python39\lib\site-packages\usb\", line 921, in get_active_configuration
    return self._ctx.get_active_configuration(self)
  File "C:\Users\scott\AppData\Local\Programs\Python\Python39\lib\site-packages\usb\", line 113, in wrapper
    return f(self, *args, **kwargs)
  File "C:\Users\scott\AppData\Local\Programs\Python\Python39\lib\site-packages\usb\", line 249, in get_active_configuration
  File "C:\Users\scott\AppData\Local\Programs\Python\Python39\lib\site-packages\usb\", line 113, in wrapper
    return f(self, *args, **kwargs)
  File "C:\Users\scott\AppData\Local\Programs\Python\Python39\lib\site-packages\usb\", line 131, in managed_open
    self.handle = self.backend.open_device(
  File "C:\Users\scott\AppData\Local\Programs\Python\Python39\lib\site-packages\usb\backend\", line 804, in open_device
    return _DeviceHandle(dev)
  File "C:\Users\scott\AppData\Local\Programs\Python\Python39\lib\site-packages\usb\backend\", line 652, in __init__
    _check(_lib.libusb_open(self.devid, byref(self.handle)))
  File "C:\Users\scott\AppData\Local\Programs\Python\Python39\lib\site-packages\usb\backend\", line 600, in _check
    raise NotImplementedError(_strerror(ret))
NotImplementedError: Operation not supported or unimplemented on this platform

Could this be related?

UPDATE: I was able to find a PC that would run the live Linux usb suggested on the EDL git. That worked!

Yes, you must a modify default.prop inside the partition image(s).

“Image(s)” because default and vendor.prop are a hierarchy of files scattered throughout the file system.

Are you using Wallpanel? I believe it has a setting in there to keep the screen awake. By default, the HA companion app will not keep the display on.

This post by the HA Android dev suggests that its not possible to turn the screen off.

Well, tell that to my app. If Home Assistant is open on my ThinkSmart, WallPanel timeout does not ever blank the screen. I have to exit the Home Assistant app, then five minutes later the screen goes dark.

I think you/and the dev are right, that’s why I mentioned above, that the screen turns off after some timeout.
However: at least with those actions, we can trigger the screen to go dark after the timeout. At least my device was frequently stuck with the screen on, even with a timeout setting of just 1m. Sometimes it worked to click around a little, open another app, etc… With the ADB command sent through HA, I can at least make sure, the screen goes dark when leaving the apartment, or going to sleep.

Try just leaving it on the settings screen, or something else. Maybe its an incorrect wallpanel setting?

What are you reading into what I am saying? Timeout works. No matter what app is running, or none, the screen times out. EXCEPT Home Assistant. If the Home Assistant app is running then the screen won’t time out.

I’m having the same screen timeout issue. I set timeout to 15 secs to test some scenarios. I notice that

  • if I toggle the camera cover switch (covered then uncovered again), sleep timeout works again (once).
  • at the android home screen, sleep timeout works once
  • inside the settings app, sleep timeout works once
  • I can get sleep to work again by using an app which closes itself. Eg press a button on the navigation bar (even pressing home from the home screen, which does nothing!) and let it auto hide, and sleep will work. Toggle the camera switch back and forth without touching the screen, and sleep will work. Audio switch doesn’t do this, though)

My impression is that by after first sleep/wake, focusing any app by interacting with it makes it a sleep blocker. This includes HA, system settings, and android home screen. But use something self-terminating, like the self hiding notification bar, or the invisible “camera disconnected” notification, and since the sleep blocker self terminated it no longer blocks sleep. The one exception seems to be the volume slider notification. Press a volume button and it shows you the volume change. That volume notification seems to release the sleep blocker without hiding itself.

So the easy workaround to sleep the screen is to hit a volume button, or toggle the camera.

I’m trying to use the android HA app sensors to track when the app thinks it’s active for more info, but this could be a dead end.

1 Like

I see something similar, the ‘sleep once’ situation is also valid for the Wallpanel app.

AFAIK, there is nothing in the HA app that keeps the screen awake, so you’ve done something to make that happen. Maybe a Wallpanel misconfiguration?

edit: After reading the other posts, I see this is possibly a device issue. :wink:

1 Like

Just a thought regarding screen sleeping/not sleeping:

Could it be dashboards that include camera streams?

Probably correct.

The original software was heavily dependent on a single app that launched at startup. So most ‘housekeeping” tasks were probably handled there, so as to best integrate with the user experience.

You might be on to something here. Maybe can set package manifest permissions to stop certain app(s) from preventing screen turn off.

For those using WallPanel, any luck with the face detection? I can get motion, but face detection doesn’t work (WallPanel says the libs aren’t present, so I’m guessing they don’t exist in Android 8.0). I expect it just won’t work, but curious is anyone has it populating in HA via the MQTT sensors.

For my part, i have no camera or audio in my dashboards, so that is not blocking sleep. Plus, sleep is blocked in home screen and settings apps, too.

It really seems like a device issue, but I have a hard time imagining what! Tap works fine, and first sleep is ok. There are no phantom taps or any other symptoms of bad touchscreen detection.

Anyway the most likely solution is going to be a workaround. Can we remotely trigger eg show a notification and then immediately hide it?

I received my device a few days ago and finally had time to flash it yesterday. Although I read a lot in this thread, I managed to get the paths wrong twice…

I ran into the same screen off problems as discussed with the Wallpanel App and switched to Fully Kiosk Browser.
For now I have a working setup with

motion detection by camera to brighten the screen
timeout to start screensaver with brightness = 0

I had issues with screen off/wake there, too. Also I noticed the media_player entity got no working volume control. Whatever the settings its always super loud…

1 Like

Whatever the settings its always super loud…

I got blasted with audio volume as well. Media player entity in HA is in an ‘unknown’ state and volume buttons on device don’t change it.

However, I found that if I make a service call from HA to set the volume like any other media player it worked the same. Haven’t tested if it ever changes on its own, but likely needed anytime it restarts.

Hi everyone !

I’m in Europe and Finally just received my unit. I must admit, as others have pointed out, that instructions are not perfectly clear.

Do we agree that the only thing to dowload is kingston-ha-rom.7z off Google Drive ?

EDL is installed on computer by command line through bkerler’s edl . Ok.

What about those ADB tools / Android SDK tools ? Is there something to DL ?

As I understand, the only thing to do on computer would then to install EDL, download kingston-ha-rom, extract it, point terminal to the extracted folder, then type the edl command.

After that, just plug the device, boot it in EDL mode, and continue on tablet. Right ?

How to know the edl command had been succesfull and it’s then listening for the tablet to connect with it ? Is everything processed from the tablet after I typed the command ?

Finally, is there a risk of bricking the device during the process ? I must admit I’m pretty used to flashing devices as i’ve been doing this from time to time since many years now but this one is way less detailled than what i’m used to and i’ve got absolutely no idea what’s going on by reading the tutorial (sorry for being honest) and i’m a bit afraid of f*ing up. So i would like to know if there are steps that would require special care or extra attention.

Still, thank you very much to OP and everyone contributing here, it’s just that some people may need more details about what’s happening during the process and what to expect when actions are executed.