Mode Manager - Dual Mode

📢 Feedback Feature Requests
41

Yes, yes it would!

42

Interesting thread. I as about to start a new one that would have run this same course.

I was going to ask for a separate global setting akin to Mode called Mood. The Moods could be used to determine things like Party (self explanatory), Friendly (Guests present), Empty (Away), Quiet (mute).

As I use Mode to delineate Morning, Day, Evening, and Night I'd like another global setting for behavioral based rules.

I look forward to this future global variable you speak of.

1 Like
43

While not as elegant as an additional global variable, you could use a Virtual Dimmer as a way of doing this. You would need to keep a lookup table handy to know that a Dim Level of 1 = Party, 2=Friendly, 3=Empty, and 4=Mute. And, you would still have another 96 values available! :wink: Logic based on Dim Levels is already available, so you could implement this today if you wanted to.

44

That is clever, but would be a pain to implement widely. I don't want to have to look up each mood number when making a rule or adding a feature.

I'll stick with the hodge-podge of duplicate rules based on virtual switches until the global variable update. At least with the virtual switches they have friendly names. But I like your line of thinking.

45

Hmm, so my outdoor lights won't go on in the evening if we are away? I guess I'm just now realizing this. In my scenario thats obviously what is wanted/intended. I'm using Simple Lighting and have it turn on the outside lights when mode changes to evening and off when it changes back. I looked at using time to turn them on instead, but then they cant be turned off with the mode change to night. So now I have two SL rules one to turn them on and one off avoiding the Away mode all together.

46

Hi There! Dunno if this is the right thread for this question but I'm new to Hubitat and I'm trying to migrate most of my smartapps from ST. I've been facing several incompatibilities with what appeared to be bat habits in my coding and hubitat environment, so far. But now, I'm perplex since it appears a simple request into a list of modes doesn't seem to work:
I have this:

def currMode = location.currentMode 
    boolean inRegularModes = currMode in modes

While current mode is "Day" and "modes" returns " [Day, Evening, Night]", the test "inRegularModes" returns false... I'm sure this is another obvious thing I'm not seeing and maybe I should think of getting some sleep... Let me know if you see what's going on here because It's one of those times when you spend hours on things that always end up being a type somewhere...
Thanks in advance.

47

This always gets confusing. Put in log.debug to show location.mode, location.modes, location.currentModes, and modes.

48

Thank you for your answer. For some reason it seems to be working now... dunno what I did. It was due to something in my code because I noticed it worked in any other app code... But I don't remember doing anything beside changing all "in" by .find{it == currMode} then went back to "in" (after I saw from a test in a different app that it had to work) and now it works... Mystery.

50

It does it again now:

def currMode = location.currentMode
    boolean inRegularModes = currMode in inRegularModes //modes.find{it == "$currMode"}
    boolean Active = motionTest() || !bedSensorIsOpen()
    //boolean inSavingModes = !bedSensorClosed && currMode in savingModes || (inRegularModes && !Active)
    boolean inSavingModes = currMode in savingModes 
    // if there's been no activity around motion sensors (and no bedsensor pressed), then run in power saving mode
    boolean inMotionMode = currMode in motionModes 
    
    def dumbtestList = ["a","b","c"]
    def currDumbMode = "a"
    boolean inCurrDumbMode = currDumbMode in dumbtestList
    log.info """
location.mode = $location.mode
location.modes = $location.modes
location.currentMode = $location.currentMode
currMode = $currMode
savingModes :: $savingModes
motionModes :: $motionModes 
location.mode in savingModes = ${location.mode in savingModes}
inSavingModes = $inSavingModes
inMotionMode = $inMotionMode
--------------------------------inRegularModes = $inRegularModes

Dumb test: 
dumbtestList = $dumbtestList
currDumbMode = $currDumbMode
inCurrDumbMode = $inCurrDumbMode


"""

OUTPUT:

location.mode = Night
location.modes = [Day, Evening, Night, Away]
location.currentMode = Night
currMode = Night
savingModes :: [Away, Night]
motionModes :: [Away, Day, Evening, Night] 
location.mode in savingModes = true
inSavingModes = false
inMotionMode = false
--------------------------------inRegularModes = false

Dumb test: 
dumbtestList = [a, b, c]
currDumbMode = a
inCurrDumbMode = true

I FOUND THE CAUSE:

def currMode = location.currentMode        //doesn't work
def currMode = location.mode                     //works
51

Hi All,

I wonder if there is any update on implementation of a more flexible "mode" system, potentially with additional global variables?

I'll add my vote to this being a very useful feature that would simplify my automations by avoiding hodge podge work-arounds.

Cheers.

52

I'm also interested in if there were any updates to this (maybe that weren't captured in this thread?) I would imagine the option to add global variables could be handy for those who choose to add them.

Edit 2: found this

53

I think it's only natural for folks to want dual or multiple concurrent modes. The fact that you can add multiple custom modes, combined with the fact that you can set these modes based on different kinds of triggers, e.g. time of day, presence, etc. makes for a natural logical leap that you should be able to have a state that is in multiple concurrent modes.

I don't see why this is problematic programmatically. A simple object called "current modes" can serve as a container where modes can be added such as in a list object. Later the contents of said list object can be used in comparisons (e.g. if modes.away in "current modes" then etc. etc. etc.)

I would like to add my vote for this Feature Request.

54

I was looking for the same thing but, a global variable was all I really needed. I use the Simple State Machine app to manage what actions to take when multiple modes I in effect.

I use the built in modes for time of day and a global for each room to track the mood of that room, normal, movie, party, and cleaning. I've never implemented the 'Away' mode, this is working pretty well for me.

2 Likes
55

brilliant, a state machine implementation for Hubitat. This would indeed work, kudos for making me aware of it's existence.
kind regards