Mode changes not being published to Node-RED

[richard1]

I recently updated to 2.2.2.126 on my Australian-spec C4 hub and since then, it appears that mode change events are just not being pushed to Node-RED (running nicely on my local Windows 2016 server). This of course breaks my mode-dependent lighting automation.

Has anyone else experienced this? This worked a couple of days ago! I have tried reinstalling the Mode Manager app, and I have an event listener directly coupled to a debug node in my flow in Node-RED. I have buttons linked on a WallMote (for testing) and I can see the button press events, and in the hub itself I can see that the mode has changed, but I can't see the mode change event come through, and the annotation on the mode nodes reads "Night" all the time.

[mike]

It's working for me on an Aussie C-5. In fact, the mode change originated from Node-Red into Hubitat, which was then sent back, and changed a global in Node Red.

[erktrek]

I stopped using mode manager and am using a combo of global var and MQTT (for change triggering or you can use Link nodes) - and that allows me to make "mode" into an object instead of a simple string.. something like this:

{
    away: true,
    guests: false,
    timePeriod: "morning",
    status: "away",
    alerts: {}
}

[richard1]

I gave up on using the mode manager and now use triggered flows in Node-Red for modes as well. Since I was not using modes anywhere else, it was a better solution.

[erktrek]

I did this as well - allowed me to manage "mode" as a json object instead of a string - then I could do things like separate a guests flag, away/home, and time periods (morning/afternoon/evening) etc... very handy for my use-case.

Something like this:

mode = {
    "away": false,
    "guests": true,
    "timePeriod": "morning",
    "armed": false
...
...
}

"timePeriod" bit of the mode when it changes gets sent to the HE hubs as the "mode".

You get the idea...

[Keo]

Which node are you using to create the json object?

Would you be willing to share you flow?

[erktrek]

Happy to! There are a couple of steps and its a little complicated but you can probably simplify. Will PM you the details if you want but essentially I use NR to set the mode for each hub (I have 2 right now with a 3rd coming online soon) and also store the result in a global variable + mqtt (running the Aedes MQTT node for local stuff). The act of storing in MQTT allows me to treat it as an event which I can then use other sequences if I want. You could also do this with a Link nodes as well. The global variable I'm calling "Mode" uses file storage in case of reboots etc.

First thing I do is set the mode for my 2 hubs via Node-RED using the Big Timer node.. I have a subflow that gets a list of nodes and compares it with the mode name change I want. Note: The "no-op" node does nothing just helps prettify things. Also note that all hubs have to have the same Mode names in order for this to work properly.

Side Note: I am probably going to change the Mode ID lookup subflow to happen during initialization and store the modes + id's in a global var since Modes aren't likely to change all that often. It doesn't really matter though not a huge drain on resources.

The "MQTT/Global Object Set" subflow stores the values I want in the appropriate Global Variable (and MQTT). Here are the properties I am using for setting the Mode name from Big Timer into the global variable "Mode" which contains the property "timePeriod":

"Mode" is the global variable name / MQTT Parent Topic
"Topic" is the subtopic and property of global variable i.e. "Mode.timePeriod"
"INPUT" is data I want to store.
"INIT" is an environmental variable I set in the "settings.js" file that allows me to initialize the Global Variable if none exists. It looks like this:

// Declare custom "static" variables for use within Node-RED. Great for initialization routines etc.
process.env.ADSV_MODE_INIT = JSON.stringify({"away":false,"guests":false,"alert":false,"timePeriod":"initial","alertMsgs":[]});

"SEND_ALL_TO" just fills in the blanks if any properties are missing from Mode. Normally not needed.

You can use the "MQTT/Global Object Set" to populate any of the declared properties of the Mode object this way - like toggling away / home etc.