It flashes up over the screen of tablet (continuously). I had to go to work but I’ll try later and let you know.
Don’t have MQTT installed yet - just the basics plus zwave so far - I’ll have to leave that until next weekend probably.
EDIT: Yeah, rebranding is on the way 
Not that. I don’t think it is either Homedash ™ or the docker image as it happens on both pc browsers and the tablets and also when I go back to normal undockered appdaemon. I did a fresh os install on a tablet and tried again just to be sure but no dice. I’ve plugged in an older (working) raspberry pi backup build for now as I have guests so any further tests will have to wait. In any case I suspect it’s to do with my install of debian.
Here’s the error anyway.
If ask in the beta thread. Strange that it would happen with the Docker too, since the point of that is consistency of the app code in a known to work state. Something environmental. That must be an error thrown by appdaemon code though since it’s JavaScript, not Java
Thanks for this great app. Testing it out on an old Samsung S4 (4.4) right now and it works really well. One thing though that’s kind of a dealbreaker with my current setup: I have the IP Webcam app running on the tablets mounted around my house, which get recorded by the ZoneMinder server. Because of that I can obviously not use the wake-screen feature because the camera is already blocked.
So as a feature request for the future: expose the camera-stream that’s being used for motion detection as mjpeg or similar. Then I could leave out the IP Webcam app. 
1 Like
Haha I had a deep down feeling it would come to that eventually :). Will take some rethinking of things but certainly something for the roadmap. Noted up top.
EDIT: What do you basically need, mjpeg on a URL, just the same as the HASS component would use? Any parameters/settings beyond that?
2 Likes
Yes, the mjpeg component is pretty much simliar to what I can configure with ZoneMinder. What might make sense would be the possibility to request the stream at a specific resolution, bit depth and fps (ZM does that on the server side). I don’t know how much processing can be left to the tablet. But since those probably are 99,9% wifi, limiting a hi-res camera to 640x480x8bpp, before sending out the packets, would take some load off the network, allowing more 4k for other clients in the network.
Edit:
I’ve put some more thought into my feature request, which results in extending my previous idea the following way:
- mjpeg stream accessible by something like: http://blabla:8888/mjpeg?width=640&height=480&bpp=8&fps=15&rotation=90&ar=1
where therotationenables embedding the stream without having to deal with the orientation client-side, andarwould be a boolean which preserves the aspect ratio if the requested resolution doesn’t match the actual stream-dimensions. Maybe an additionalbwparameter could be used to force a greyscale stream if desired. But that’s less important I guess. - The MQTT API could be extended to be accessible via REST as well. Even though HASS is good at talking MQTT, someone might see a benefit in controlling the app through simple HTTP requests. At the very least it would make this more versatile, like having Tasker take control without the need for the MQTT plugin.
- Not directly related to the stuff above: a simple auto-reload at a configurable interval. Right now I can remotely trigger a reload. Having the app doing it itself would get rid of another automation in HASS. To max out the fancyness, the interval could be reset when motion is detected, since with motion there’s probably someone around who wants to interact with the tablet. Reloading while pressing a button on the dashboard wouldn’t be too nice.
1 Like
Some more ideas:
- Allow starting Android-activities from within the webview or by MQTT (or HTTP, if that’s going to be implemented). For the webview this is what I’ve found: Stackoverflow
The main thought here would be, that there are doorbells available that come with an app for “intercom”-like functionality. So if HASS detects that the doorbell has been rung, it could switch to the corresponding app to let people see who’s outside, and switch back to the regular dashboard after time X or whatever. - Bluetooth scanning for presence detection. The list of devices could be published via MQTT, along with the signal level. That way if there are multiple Bluetooth-enabled tablets, HASS could use the signals to calculate some basic indoor-position. With this it could be possible to have multiple (user-specific) dashboards, which could be loaded as soon as a BT-device gets near a specific tablet.
1 Like
What is the minimum Android version needed to run this?
Whew. Just a few ideas
All seems likely stuff in the long run. Right now I’m concerned with a stable API that is matched in the iOS version that’s coming. I figured REST would be part of that and the HASS support would probably be REST. But the Android flavor will likely pick up a lot of that stuff, or the means to accomplish those things!
1 Like
API19, 4.4 currently. I think API16 might be possible to roll back to but hasn’t been tried. Not sure which Android that is off the top of my head either. :).
1 Like
I’m in the process of setting up HADashboard and in the meantime I tried to test this with the normal Home Assistant front-end. After the HA login I get a blank white screen. I don’t see anything in logcat that would point to an error and trying other websites seems to work. Is this a known issue with HA? Not really critical since I’m planning on using HADashboard anyway, just curious. Thanks.
Not sure. Which Android version is it and which device? The Android world seems full of ‘ifs’ and ‘excepts’
If anyone’s curious… WallPanel-API README.md on GitHub
WallPanel for Android 0.5 will be conforming to this document (which means REST is targeted for both Android and iOS currently). Which is mooooooooooostly where the Android one is at now but it may break a few MQTT configs (I’ll update the Home Assistant YAML examples for it!)
2 Likes
It’s a Kindle Fire 7 rooted and running a rom based on stock 5.1.1 (Fire Nexus). I’m sure flashing a rom just added a bunch of additional ‘ifs’ and ‘excepts’ as well . I won’t worry about it. Once I get HADashboard up and running i’ll start worrying if I have issues then!
Interesting I have a Fire HD6 tablet, is the the same line? It’s running CyanogenMod, I didnt know anyone had anything based on 5.x available but the 4.4 ran really well on it so, s’all good.
Just worried on if there’s fire behind that smoke you see. Could be a weird quirk. Since you’re on 5.x, it should be defaulting to using the OS’ WebView. There’s a setting in there where you can force it to use CrossWalk which is the default on 4.x devices that have a really old WebView that /totally/ does not work with HASS. Maybe give that toggle a try? It would at least say its a WebView specific bug on that OS.
I’m not sure how different the hardware is but it looks like the rom is only available for the Fire 7. I almost went with CyanogenMod but since the project is all but dead I kept looking. Ended up going with this rom since the developer seems committed (at least for now) to updating it each time there’s an Android security patch.
I’ll try that toggle tonight and also reinstall WebView and see if that does the trick. Thanks for your help!!
1 Like
WallPanel it is then!
With some guidance in the appdaemon thread I figured out the problem - on the off chance anyone comes back here looking for it. It was my appdaemon docker config / local DNS. The line…
-e DASH_URL="http://$HOSTNAME:5050" \
converted all the widget links to the netbios name of the PC which wasn’t resolving to an IP on the tablets. New router coming should fix this and a few other issues. Using the IP address gets around it for now.
` -e DASH_URL="http://192.168.1.7:5050" \`
1 Like
Glad you figured that one out. I keep bugging him about removing these hard coded things would make life easier even without Docker
I have the REST API support in there, and the framework of supporting the full ‘Common’ Wallpanel API. Just need to clean all of that up. After that’s all done it’s full on just worrying about features. Silly foundation work
Hopefully should be seeing 0.5 by/during this weekend. Want to slip in the zoom parameter still…
Thinking webcam will be a target for 0.6
1 Like