Maybe I missed it in searching, but I just switched to the integrated mode manager which is great with triggers and such. I was trying to see how it’s working since the switch but I can’t see it as a selection yo filter for in the logs. Any guidance?
I also don't see it in the drop down for apps/device as I thought I would. It only sees one of the many modes for me. But I could drill down with a little work.
First, I used the search option in the logs -
Then I drilled down by selecting the related app number on the left.
In my case it's 'app: 8':
Appreciate the feedback. Yes, searching for mode does yield some results, but I do not see anywhere when mode is changed and what triggered it. I only see apps that affected by a mode change. In your logs, what is app:8? I have nothing in my logs similar. Mine are all just the apps that are triggered.
As I understand it, when an app is enabled or added to your HE environment it is assigned an ID number. Like for devices, this is a foundational component. Names and labels (for devices) associate with this.
You can see the app ID in the url (Note the .../configure/8...) here:
Unlike devices, there isn't a lot of optional logging options : just this at the bottom of the app page:
Mode changes in my environment are visible if I've set OTHER apps to trap the logging. Heres a result from this morning showing apps doing their business - 5 lines from the bottom you can see the Time 10PM triggered as well as a few other events throughout the night into early morning :
Are you using the integrated mode manager....
I was using the normal mode manager app and switched to the integrated mode manager which disabled the mode manager app...
So there doesn't appear to be an associated app with the integrated mode manager to access the logging you reference.
I want to add some thoughts that could be discussion points.
First, Full disclosure - I originally found Mode Manager lacking a few years ago, so I wrote my own. I had proposed a hopeful feature to 'trigger' mode manager to run but it never made it into HE. My thought process at that time (and I'm just doing this from memory) was that there are 'periodic' modes, and 'state' modes.
Times of day are periodic, while 'home/away' and 'awake/sleeping' are states. Mode manager doesn't really cover this for me.
I think that in the definition of Modes (which is still hidden in the Settings kind of legacy like) one shouldn't have 'state' modes. However, in my case I still have them but don't use them:
Also note that in the mode definitions on Modes (see above bottom of screencap) there is a 'select Mode Manager' and a 'NEW - Integrated Mode Manager' option exists. I have never tried it so I can't say if that may be helpful to you or not. YMMV.
I use IMM too and haven't ever seen any logs related to it. But we just use basic Home and Away, so our mode-mgmt needs are very simple.
I have 2 rules related to Home and Away stuff to do, so I just added a line in each of those to log "Mode is now Home (or Away)"
I totally agree with your states of modes argument. There are different states of, for instance, night. I may want lights to behave differently at night depending on if I am home or not. I use all of my motion sensors to control a virtual whole-house motion detector. This modifies how things operate. It would be nice if my modes could have states like Night.MotionDetected vs Night.NoMotion. I actually use my whole-house motion to automatically arm my alarm but unfortunately I’ve got dogs that sleep a lot. I’m sure if someone was prying open a door the dogs would move before they opened a door and disarm the alarm but then they gotta deal with the dogs 
1 Like
Mode changes are logged under location events. At least mine are. I use IMM. For my use cases it works as well or better than the Mode Manager app.
On the state vs periodic thoughts... I use IMM for both. My modes are Home, Away, Asleep, and Evening. I have RM rules that manage what the house does given what the mode is. Evening is the only mode that's based on time (sunset). The others are all triggered by something else happening no matter what time it is.
1 Like
That’s great to know. I still cannot see what triggered the change there. I’ve determined that my one trigger for day mode that is based on illuminance of two outdoor sensors (front and back of house) were fighting each other based on this oscillation between day and night as the sun rose. The triggers are OR’d and there is no option to AND them. I now only rely on one and added report logging in my mode change app. More standard logging should be available from the integrated mode manager.
Modes are very simplistic. At least there could be Away plus regular daily modes. For instance, if I’m away at night, my lights should shut off at random late times, but during the change from day to night they should turn on regularly. Yes. It’s possible to code that but arduous logic like it’s day or night and away or not. States of modes could reduce the actions logic I think. Probably a lot of things can be solved with virtual switches or variables I assume.
The more I think about it, I’m not sure the value that mode manager adds other than keeping us from creating our own app to manage a variable. Possibly is rule or rule sets execution could be tied to different modes? Maybe only execute this rule during these modes but we already have ways to do that with required expressions. It could possibly be used as a UI thing but I’m beginning to see it’s really not that valuable.
Triggers are always OR'd because any one will trigger the actions.
If you want to combine lux from multiple sensors, there's an app available in HPM called Sensor Groups+ [Resurrected] that will do this for you. It creates a child device that you can use as your trigger.
1 Like
I use variables to trigger mode changes. And I use mode changes to trigger rules. And I also have modes in required expressions. Yes, I could handle all of that without modes. But modes, for me at least, make a handy short-cut. I was using modes before there were required expressions, and I didn't see any reason to change that.
One thing I love about Hubitat is its flexibility. If you think up a use case, chances are there are multiple ways to accomplish it. And if whatever you are doing with it stops working for you, there are plenty of other methods to try.
2 Likes
I totally agree with that. From my old days of using other platforms through the years, Hubitat is by far the most flexible and also most fun to tinker with,
1 Like
I switched back to the mode app. No logging and unpredictable behavior is too much.
