Context Data vs. Virtual Devices

So I am beginning to transition more of my Hubitat rules into NR and in the process I am starting to realize that context data in NR and virtual devices in HE, or really any platform, serve very similar purposes, and I imagine in the backend are virtually the same. But I was wondering, how do you guys use these two features? Do you prefer one over the other or are they unique enough to have their own use cases?

Virtual devices seem to be a no-brainer when trying to interface with a smart assistant for example, but for holding special-mode data or overrides or scenes or anything like that, they seem to be interchangeable. I air on the side of using virtual devices as I know how they work and am comfortable with their reliability and stability, but I have messed around with context data in multiple scopes with both volatile and non-volatile storage, but to me it just seems to be more to go wrong and more to initialize and just more of a headache overall compared to virtual devices.

The specific case that brought this thought up was with the addition of contact sensors for the bedroom doors. I am trying to make it so that when the door is closed and the room is occupied, then the motion control is off and manual only mode is activated, conversely, if the door is closed and the room is unoccupied or if the door is open, the motion is enabled, priming the room for the next entrance and turning the lights off as normal by motion. And that is working, but it got me thinking, what happens if someone takes a nap by closing the door and turning the lights off manually and then someone comes into the room. By my logic the lights would come on since the door was opened and the motion was triggered, but imo they should not. So I wanted to implement a Do Not Disturb override, activated by Alexa for now, for this specific case, enter the context variable or virtual device.

What is everyone’s thoughts about context data/variables and how they related to virtual devices? I am very curious to hear other people’s opinions.

Interesting, I have grappled with similar issues, not on a regular basis, but it can come up, more so when people visit for me…

I am certainly conscious of tailoring my rules for when there is more than one person in the house (not a common situation for me). You can’t always rely on a predictable sequence of events in terms of motion detection, contact sensors, etc, when trying to map out rules for a room, particularly in areas such as lighting. My bathroom, even when it is just me, has wracked my brain trying to make the lighting smart enough so the lights don’t go out when I am “contemplating the complexities of my smart home…”, if you get my drift…

Where was I…

Ah Yes… I think the crux of what we both want is an ability to capture and make use of the status of a room. That can be a challenging task, not just due to limitations with an device or system, but just the physical makeup of a space and the options we have to monitor it.

Putting device capabilities and other complexities to one side, my personal preference in terms of what a “system” should provide would be an ability to capture the status of a space, whatever that means for a home. But that ability does rely on the user providing the right level of monitoring (sensors) to suit the space being controlled, the system you install can’t do it all for you (I’m not suggesting that is what you were saying…)

I must admit I skim read your post and I wouldn’t blame people for doing the same with mine… Probably should get to the point…

I want rooms as a built in feature, with the concept of “modes” to extend to individual rooms, allowing for per-room mode logic in rules, still with home-level modes like we are used to.

Simon

1 Like

Yeah I agree, in a perfect world, I would love to think of everything as a room and the sensors or switches or plugs are just objects in the room that either set or respond to the state of said room, but until there is a commercially available OCCUPANCY sensor that does not rely on CV or some other high power consumption method, I don’t think this is possible.

I have my “occupancy” check as just a motion recheck after a single timeout cycle of my motion sensor, and it is working well so far, but this has its own issues.

Do you have any experience in using context variables and using them in relation to virtual devices though?

1 Like

I guess what I was proposing was not so much that we needed a physical device to provide us with an occupancy status, but more that systems such as that provided by Oh-La or HE had a built in concept of a room that could have a mode of its own driven by various sensors or other methods for determining occupancy.

Like I said, not an easy thing to put in place… But something I would certainly like to see.

1 Like

Don’t want to get too off-topic, but I think someone has done this with a community app, but I found it after setting my whole house up and it was not the most user friendly iirc, but it did seem promising.

1 Like

I felt like this was entirely on-topic, but like I said, I only skimmed over your original post…

Room manager is what I had in mind as well when thinking about this, I saw it when it came along as well and thought it was a great concept, but I hadn’t moved my lighting over to HE at that point, so didn’t pursue it. I intend to look at it or something similar once my lighting setup is settled in.

Simon

1 Like

The main topic was more about the use cases for Node-RED’s context variables versus virtual devices and ways of storing data. My specific use case was just a back story for why I came up with this thought and why/how these features might be used.

1 Like

I only skimmed the topic as I’m at work, but my first thought was a global variable? You’d need to use that in your logic for the rooms but if it can be thought, it can be done. My apologies if I’m way off base as I don’t have time to thoroughly read the topic until later.

1 Like

I began mostly with virtual devices, mainly since I knew of them, and they are reliable/consistent.

Then I got sick of “needing” a device for everything I wanted to store/display in NR. I started using global/flow variables depending on the use. I did not like the fact that I could not “see” the current value, like a device would show. I asked around, and was informed on how to make a debug node display the value.

Now that I can store the data, AND see what the current data is; my OCD is starting to adjust. In the end it saves me several steps, so I vote variables with debug node display :wink:

Just my test sample, obviously unnecessary, but again I’m learning to use them as well.


Sample for Import
[{"id":"b13d65d6.193d18","type":"hubitat device","z":"7442e075.dd28a","deviceLabel":"","name":"Porch - Multi Sensor ","server":"b1088aaa.95e9e8","deviceId":"187","attribute":"illuminance","sendEvent":true,"x":340,"y":440,"wires":[["da11ba51.58e058"]]},{"id":"da11ba51.58e058","type":"change","z":"7442e075.dd28a","name":"set currentLux","rules":[{"t":"set","p":"currentLux","pt":"global","to":"payload.value","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":560,"y":440,"wires":[["ddb858fa.5c3838"]]},{"id":"ddb858fa.5c3838","type":"change","z":"7442e075.dd28a","name":"global.currentLux","rules":[{"t":"set","p":"payload","pt":"msg","to":"currentLux","tot":"global"}],"action":"","property":"","from":"","to":"","reg":false,"x":750,"y":440,"wires":[["7e724b22.c61804"]]},{"id":"7e724b22.c61804","type":"debug","z":"7442e075.dd28a","name":"Global Lux","active":true,"tosidebar":false,"console":false,"tostatus":true,"complete":"payload","targetType":"msg","statusVal":"payload","statusType":"auto","x":940,"y":440,"wires":[]},{"id":"36879edd.d64432","type":"inject","z":"7442e075.dd28a","name":"","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":150,"y":440,"wires":[["b13d65d6.193d18"]]},{"id":"b1088aaa.95e9e8","type":"hubitat config","name":"Z-WaveHub","usetls":false,"host":"10.20.1.23","port":"80","appId":"5","nodeRedServer":"http://10.13.9.28:1880","webhookPath":"/hubitat/webhook_","autoRefresh":true,"useWebsocket":false}]
2 Likes

Yeah I feel like I am on the same path as you, I just need to be more comfortable with the stability of my NR instance and I’ll probably make the switch.

You can also view the current values of all context variables from the right sidebar, under the context? tab I believe. It has a weird system where it doesn’t seem to refresh on its own, but other than that, it works great.

Also I had no clue you could set context variables via the change nodes, I was always using the function nodes. How do you specify where you want to save the variable in change nodes?

1 Like

Hey looky there! But that’s like three clicks and shit :rofl:

1 Like

But how do you initially create the variable and specify if it is on memory or on the “disk”?

You don’t I didn’t. All you I did is make up a name for it. Once I set it it exists, like magic. lol

I never took “extra step” to create currentLux, that is just my word for it.

importable sample posted above so you can test.

1 Like

Interesting, this is how I interface with my context variables, and I like the extra granular control, i.e. specifying file or memoryOnly storage, which you first have to create in the /.node-red/settings.js:


image

1 Like

:bowing_man:

:laughing:

2 Likes

Yup maybe, it’s probably just the computer engineer in me :joy:. As a side note, is it possible to use context variables as a trigger when it changes?

Update: OMG I think you just introduced me to a much nicer world haha
image

Before I switch everything over to change nodes now, does anyone know if one has an advantage over the other in terms of speed or reliability or flexibility with updates to NR?

Also sidenote again, any idea how to change those icons so I can actually see which one is being selected and not just trust that it is the right one?

interesting option, I don’t seem to have that choice. Maybe since I don’t have anything in setting.js?

Yes that is definitely why, see my settings.js:
image

Do you know if those icons can be changed, them being the exact same does not make much sense to me.

Not TMK, but it must be set somewhere, so it’s changeable somehow. Might be deep in the program code though. I did some quick Googling, and got nothing, so it must not be “easy”

1 Like