Hi, I have night mode set to turn on at a certain time, specifically 1am. On the odd occaision I am still up after this time, I created a mode called 'entertaining' and then set it in the Night Mode 'Select modes to ignore time changes' section as below:
This is what currently happens...
Night mode turns on (which then arms my house etc), and I then select 'Entertaining' mode thinking when in this mode it will not switch back to 'Night' - however, it keeps switching back to 'Night' mode and ignoring the fact that I set it to 'Entertaining' - does that make sense? What am I doing wrong here?
So are you saying (as an example):
- You are in (say) Day mode at 12:59am
- At 1am the hub moves to Night Mode due to the Mode Manager configuration
- At 1:01am you manually change to Entertaining Mode
- At 1:02am the HE hub switches back to Night mode
Granted, the automatic changes above would not take 1 minute to take effect.
1 Like
Sounds like a bug to me, at least in the way the setting is described in your screenshot.....
@bobbyD ? @bravenel ?
Sorry if I got the tagging wrong.... Looking at the documentation I'm not sure I can follow exactly what this option is intended to offer.... Any other insight you can offer?
@mabstrategy - might be worth providing a screenshot of the higher level setup in your Mode Manager App.
Many thanks. Do you mean these settings?
Yes... Looking at what you posted, there may be something in there for those that know more about how this app has been written to help you get to the bottom of what is happening, and some kind of solution.
1 Like
I also have this rule in WebCore to switch it back to Night at 3am, but I don't see how it could impact it? Seems simple enough?
Hmmm could it basically be doing both of those 'then' actions at the same time and not one after each other...
That's my first suspicion too, but I'm not a WebCore user so I'm not savvy enough to parse that syntax. But I'm pretty sure the issue is somewhere in there (WebCore setup) instead of your Mode Manager app setup.
Hopefully a fellow WebCore user will chime in here soon.
The question is does:
Or
Does Night Mode get set at 3am?
(I'm not a webcore afficionado)
An easy solution: pause, disable, or remove the piston and see if it stops. 
Or less impactfully for the automation, enable logging on the piston and see what they say. They'll tell you what's running when.
If you suspect it's Mode Manager Legacy, enabling logging in that app will tell you what it's doing when, too. Without either, it's a bit of a guessing game.
That being said, is there a reason that piston doesn't just check if the mode is Entertaining at 3 AM and then change it to Night if so? I'm not sure what the 1 AM check and then the wait is for unless you might change the mode in the meantime but still want this change to happen--but without a description of what you actually want to happen, maybe there is something that's not apparent. (This would also be easy to do with most rule-type apps on Hubitat too.)
1 Like
Ok, by means of an update, it was not the piston... 
It is now disbled, but the issue still happens, even in other modes. Whenever I turn on the custom mode 'Entertaining' it ultimately switches back to the relevant 'normal' mode according to the time of day (in my current case 'Day'), sometimes in 4mins, sometimes in 12mins, it's really strange... So I'm not sure where I go from here? Is this an app issue? Maybe migrating to the non-legacy mode manager would help?
The app logging is on, but when I click 'show app logs' it just shows the last scheduled change, i.e. in my case at the moment 06.00am changing to 'Day' from 'Night'
The app 'Events' just show the same, no notes of entertaining being turned on and day mode switching back, just the last scheduled change.
Live logs don't really help either, the below image shows other apps reacting to the changes and gives you an idea of the randomness of the timings when the mode switches back to 'Day', i.e. the apps react to the mode restriction when 'Entertaining' is turned on before then reacting again when 'Day' takes over.
It can't hurt; if you suspect Mode Manager as the problem, you're only likely to get help with "new" Mode Manager. (You should be able to "import" your Legacy settings into the new app, though check to make sure all looks good after.)
But with logging enabled, either Mode Manager app should tell you what it's doing when -- either app. I'm not sure what app is what in your logs, but if nothing from Mode Manager was in there, it's almost certainly something else. I'd look at what else you might have on your hub as well, including automations that might be doing this more sneakily (e.g., any mode "switches" exported to Alexa and Alexa Hunches is enabled?).
Thanks @bertabcd1234 So Mode Manager is leaving logs, but only at the scheduled time changes. Otherwise it is seemingly showing as nothing changing, which even if it was activated by something else, surely it should log the change of mode? So, it feels as though it is somehow just broken...
Re. Alexa, I'm in the UK so we do not have 'hunches' here for some reason (we also don't have the Alexa geo-fence ability you guys have either!) and I have nothing integrated into it that could do that (plus I've also checked my routine activity just in case). So yeah, guess I'll just migrate and see if that works. Fingers crossed...
Mode Manager won't log anything it doesn't actually do. As you know, it is just an app that can help automate changing your hub mode -- but there are a number of other ways this can be done, including manually from the Settings page, or using another app (including a rule, webCoRE piston, or third-party integration like HomeKit or Alexa/Google). Mode Manager doesn't have any knowledge about how these other changes might happen and does not log them (except, I think, for some "skip" cases where it needs to keep track of specific modes).
Thanks again, honestly this is so maddening, I've trawled through everything , and there's nothing as far as I can tell that makes this happen, plus it's seemingly so random!
EDIT!!!
So the last time stamp when this happened led me to explore a motion sensor that was seemingly triggering beforehand, which in turn led me to a linked WC piston that I initially thought (due to its title) couldn't have anything to do with it. However, upon inspection, it was a piston that did a whole lot more than the title suggested and I think I've found the culprit. Oh my word... 
