I am using DayDream on my device as a screensaver and HomeHabit is permanently running as homescreen. A few months ago this was working fine, however now I can see that when I exit DayDream the data is old and it takes a few seconds until it is refreshed again. Also when I want to switch a light, the first time I try it it gets stuck in “Turning on” state (even though the light is being switched on), when I tap on it again it goes to “Off” (light is also being turned off) and tapping on it again it switches to “On” (and light goes on). My device is keeping wifi connectivity alive all the time, so this shouldn’t be any issue. Maybe there should be an option to keep HomeHabit alive either all the time, just when charging or never/just when in foreground.
@Flole This behavior is expected since Android runs Daydream as a separate application, so this is no different from you switching to another app. HomeHabit does not keep connection while in background since there is usually no reason to do that for a dashboard app.
Adding optional connection in background is possible, but is easy to drain resources, so it is a delicate feature. Let me see what can be done.
The best idea would probably be to have an option to select when HomeHabit should keep the connection alive in background: Always, Just when running on external Power, Never,
Also you could check if daydream is currently running and if it is, don’t drop the connection. Plenty of options available, this is very irritating as the first button press always gets stuck in “Turning on…” or “Turning off…”.
That is definitely considered since there are other cases when having persistent connection is preferable.
Checking for current foreground app requires extra permissions, which is less than ideal and I’m trying to avoid that. It makes more sense when running HomeHabit as home app of course. So yeah, something to think about as well.
Hi @igor,
is there anything new to this? I haven’t found an Option to do this yet and want to make sure this issue is not forgotten.
@Flole nothing new yet. Persistent connection in background when charging is planned as an option, but it is not in development yet.
Unfortunately when recovering from Daydream HomeHabit is still in some very weird state, the controls aren’t working when used the first time and I need to press them again (turning on a light the first time doesn’t work even though HomeHabit shows it as on, I need to turn it off and back on, then it actually goes on). Would be great if we could at least get that solved.
Bumping this one again: Recently it got a lot worse. Now there is a 10 second delay where it’s unable to switch anything. Pressing the buttons doesn’t help and the commands are processed after some time then. This is really annoying, please at least provide a fix for that if it’s too complicated to keep the connection alive during daydream.
@Flole I want to separate the app state from OH state here, to understand what you see better. Commands to OH should be send immediately even if server is not connected yet. Can you confirm that in OH logs there is no command received? Regardless of what is shown in HomeHabit UI.
There is a delay between my button press and the actual light turning on, so I am pretty sure that OpenHAB get’s it delayed aswell and isn’t the cause of the delay here. While waiting it stays at “turning on”, then the actual light turns on after around 10 seconds, then it goes off in HomeHabit and a few seconds later when the connection is re-established it goes on in HomeHabit again…
There might be also delay because wifi is disconnected. Can you check if delay to send command OH still present if you just turn screen off and on again on device (for short period of time), and try an action right after screen is on?
In my testing, commands are send immediately to OH regardless of how the app was opened, so there shouldn’t be an inherent delay.
I am sure that WiFi is connected as I have a remote control of the device that works over Wifi. I can turn on and off the screen for example and that kind of stuff. That works perfectly fine in daydream. When I turn off and on the screen the button presses work instantly, that is even the case when I am in daydream, turn the screen off and back on and then press a button. However, whenever I exit directly from Daydream into HomeHabit there is that 10 second delay, sometimes it doesn’t work at all.
I just checked the logs of HomeHabit and the connection seems to only take 13ms so that should be alright. Also could you please change the hour format to 24 hours? I was a little confused when I looked at it as I thought it was from this morning but it wasn’t.
What is the Android version?
Android 6.0.1
Can’t reproduce this behavior yet.
This is still an issue by the way. I was hoping that there would finally be an option to have the clock of the screensaver fade out and in at a different location so I can get rid of daydream and hopefully solve the issue this way, but seems like that isn’t going to happen soon.
How can I find the root cause of this issue and finally solve it?
@Flole Still wasn’t able to reproduce this behavior after an extensive testing, so not sure what’s going on there yet.
However, in the one after next release, screensaver will have a random clock position option that I hope would allow you to replace the daydream.
Unfortunately that did not really help. I disabled Daydream and now I am using the screensaver in HomeHabit. The only thing that’s different now is that after a few days the entire device locks up completely… The root cause for that is probably not in HomeHabit but that (and the fact that it doesn’t really help either) made me go back to Daydream for now.
Also the Logs of Homegear are full of Database Unique constraint errors, HomeHabit seems to constantly try to insert something that’s already there…
I see. Something else must be going on then, because screensaver is just rendered on top of dashboard and the app is fully active during that time. Does delay happens any time HomeHabit screensaver was active, even for few seconds, or only after screensaver was on for longer time?
Also, can you share those logs errors that you see?