God I hope Homedash doesn’t have the ads. If someone slipped something in there it will be terminated with extreme prejudice. 
The only apps I installed myself are Homedash, Chrome, Speedtest and the IP app required for the android component (https://play.google.com/store/apps/details?id=com.pas.webcam). That last one does state it includes ads. I uninstalled all of those except Homedash and Chome. Rulling out Chrome the ads must therefore originate from Homedash or the OS. Not sure how likely the OS is the culprit? I have this tablet https://www.amazon.co.uk/Fusion5-Quad-core-Android-Tablet-Bluetooth/dp/B06WRR6HXN/ref=sr_1_12?ie=UTF8&qid=1490872192&sr=8-12&keywords=fusion5
I’d blame the tablet OS. If the OS doesn’t come from a trusted entity you have no idea what you’re getting. Re flash that sucker
Also the reviews on the tablet indicate ads. People seem to be accepting of it though??
Oh yeah, mine is #1 on that list…
Perhaps they really love Candy Crush ads… 
1 Like
It should, but I’ve not tried it personally. It’s going to be hit with every single DNS request your network makes so I think it would be worth monitoring for a couple of days and seeing how it goes. You might need to alter the default port if you are using emulated hue or something that uses port 80 already. I had no idea there was a hass component!
Oh! Perhaps I have misunderstood how it works. I don’t even have MQTT enabled at the moment so perhaps I should do that before I wipe. I was just expecting the screen to wake up when it detects movement which is what my existing setup does. I’ll try this on another tablet with android 5 or above first and report back.
1 Like
Oh. It SHOULD wake. But. What i was getting at is if it’s doing anything at all. It will trigger MQTT messages awake or asleep so. Curious about that.
It’s possible the issue is waking, not the camera turning on. There’s all sorts of lock modes and flags you can play with. It might be another one of those different on different androids thing.
Or it could just be the camera code
Probably should put a tester in the app.
So two thoughts reviewing the code
<!-- motion detection -->
<uses-feature android:name="android.hardware.camera" />
<uses-feature
android:name="android.hardware.camera.front"
android:required="false" />
It doesn’t seem to require that the front camera permission is set, so I’d double check that on the device
Secondly, the library that was included says “There must be a surfaceview” but it’s being used from a service that doesn’t have a surfaceview… and it works fine for some folks, but I wonder if that’s related to the issue. It also suggests that surfaceview could show what the camera sees so… I’ll think about something different here, hopefully in a few days, I’m thinking we need a “test” screen to play around with the lighting parameters and get some feedback.
EDIT: I have some other thoughts, I’m going to start refactoring some stuff in the 0.4-dev branch. It might be more ideal to handle the PowerManager stuff in a different place. I’m starting to think that yah, the issue you guys are having may not be the camera as much as things aren’t in the right state to ‘listen’ to the motion detector’s events… at least I hope so, since the motion detection is someone else’s library 
In my case the tablet only has a front camera, there is no rear.
From the other app there is this note on the website.
When activating the Screen Off Timer, Webseite integration, Remote Admin or Scheduled sleep time Administration rights are requested so Fully may automatically turn the screen off. The administration rights must be withdrawn before the app can be uninstalled.
And this is the list of permissions.
INTERNET – Internet connection RECEIVE_BOOT_COMPLETED – start at boot DISABLE_KEYGUARD – unlock screen INSTALL_SHORTCUT – add links to the home screen SYSTEM_ALERT_WINDOW – required for kiosk mode REORDER_TASKS – required for kiosk mode WAKE_LOCK – required for kiosk mode READ_EXTERNAL_STORAGE – show local files with file: // and import settings WRITE_EXTERNAL_STORAGE – export settings to file ACCESS_NETWORK_STATE – check network state ACCESS_WIFI_STATE – check WiFi connection CAMERA – required for motion detection SET_ALARM – required for scheduled sleep and wakeup ACCESS_COARSE_LOCATION – required for HTML geolocation access ACCESS_FINE_LOCATION – required for HTML geolocation access RECORD_AUDIO – required for HTML microphone access MODIFY_AUDIO_SETTINGS – required for HTML microphone access CHANGE_WIFI_STATE – required for Wifi pre-config GET_TASKS and PACKAGE_USAGE_STATS – required for app management in Kiosk mode WRITE_SETTINGS – required for setting screen brightness (ver. 1.14+) NFC – read URLs from NFC tags (ver. 1.16+) READ_PHONE_STATE – access IMEI and SIM Serial (ver. 1.16+)
I changed the motion detector library to work on a textureview which is never displayed. So that shouldn’t be the cause.
Plan for “when I find some time” is to add a preview to the settings dialog. So people can verify its the right camera and triggers.
1 Like
Ah gotcha, you changed that behavior. Cool
Yeah just need to add some more visibility at this point to understand whats going on.
Ooooh look at that, they’re reading NFC tags! I’ve been playing with those for a completely different project. I don’t think my tablet has the hardware though. Oh well something long term maybe, we have fundamentals to get through here
Yeah I’m assuming the perms list must be right, I’m just not sure if the required=false means that perhaps it’s not asking/they’re not getting set on SOME platforms. It’s all new to me…
As per the other convos, I think we just need to add more visibility/diagnostics, to be sure if it’s the camera or not the camera, but I’m making some changes too assuming the camera is fine, to do the way the sleep/wake is handled a little differently.
“required” defines if the app runs at all without that feature. In case of camera required=true the playstore would mark the app as incompatible. With the local install it shouldn’t matter.
Got ya, makes sense then the way it is. Not the issue. Also realized when taking a step back, it’s not the permission anyhow! Thanks
Talking about fancy features REORDER_TASKS permission and FLAG_SHOW_WHEN_LOCKED could allow us to keep homeDash on top of the keyguard (android lockscreen). Means we would have some basic security. Maybe not every guest should have direct access to my internal wifi or the tablet config.
@quadportnick do you keep somewhere the long list for ideas?
I have a build with a little hack of a placement of status. If the camera detection component raises motion or too dark, it will display it on the sensors pref pane at the bottom. Wont be the permanent strategy. I’ve also been moving a lot of stuff around so, maybe its worth re-testing if it will wake, but first see if the camera detection actually puts a ‘motion detected!’ on that page, because that’s the first hurdle
PM me and I’ll drop you a dropbox link. I dont want to make it a release. @BarryHampants @robmarkcole
I was thinking they should go in as Github issues at this point, or use a Wiki page? I didn’t start anything officially yet though.
Thanks - I’ve spent the last day trying to get mqtt working just to see what the sensors are reporting, no luck so far.
Nothing showing as detected so far.
I’m switching to cloudmqtt to try and test rather than sort out my pi’s mosquitto install or get embedded running - any idea what the server address should be?
tcp://m10.cloudmqtt.com:16522 doesn’t seem to work, nor does http:// or mqtt://
If you’re on the settings screen, and the sensor is on, and nothing is appearing, I’d say the camera code is not working so… one certain test is to put your finger right up on the lens, in my case it says TOO DARK almost immediately… but yeah it sounds like its not sampling the camera on your OS slash Hardware. so at least we know what we’re looking at now.
The URL format should be tcp://host:port , and I’d presume it doesnt do SSL right now (so I’d use a burner account for the time being as the logon)… sanity check that you can connect with the same parameters in another mqtt client. (what gets me on CloudMQTT a lot is when adding a user, you HAVE to give them a permission first or they cant connect)
Edit: At this point, I’d say, it may make the most sense for you to USB to a computer and run the android debug tools and watch the debug/infos that are coming out of the device?
I did try fingering the camera, leaving it to time out and so on.
Also - probably irrelevant but I notice in your screenshot the ON switches for everything are blue in the on position, mine stay grey.
As far as I can tell mqtt is all configured correctly I had it set up with presence detection for a while but just for a test I’ve installed on an android 6 device I have, motion detection works but mqtt is not reporting so I suspect the problem is me! Common enough and usually because I’ve missed something obvious.
ADB debug might be beyond me, I have it all connected etc but only getting errors reading logs.