Notice on the bottom sequence - the device node has a "filled in" blue box in the status line underneath? That indicates that "send events" is turned on. Nice little visual reminder. On the other device node the box is hollow indicating send events is turned off...
Clicking on the inject node at the top sends a simple message (could be anything) to the device node that causes it to report it's current state. It does this by reading the stored device cache for the HE config and generating a new message (overwriting the inject node's message) and sending it to the debug node.
The second sequence is waiting for a new event (trigger) to happen. If I manually (or digitally) turn on the lights the HE config cache gets updated with the new info and a new message automatically gets generated in the device node and travels to the debug node.
As you can see when the coolingSetpoint attribute is selected and of course "Send events" toggled, there is a filled square with the attribute listed, but when "All" attributes is selected and "Send events" also on, it does not seem to work.
Note: Everything has been deployed, I just wanted a single screenshot to show everything.
Currently I just do multiple instances and just pull all of the attributes I need individually, but I have no clue if that is efficient or what is the best practice in this regard, i.e. less HE nodes versus having more switch and change nodes to get the data I want.
You could use "all", but then you'd need switch nodes afterwards to select the right attribute.
But the best way is to have multiple Hubitat Nodes (of the same device), because @fblackburn has made the code so efficient, that the Hubitat state is stored in Node Red memory. It's not resource intensive.
Yeah that is what I am doing currently, b̶u̶t̶ ̶w̶h̶e̶n̶ ̶I̶ ̶h̶a̶v̶e̶ ̶"̶a̶l̶l̶"̶ ̶s̶e̶l̶e̶c̶t̶e̶d̶,̶ ̶i̶t̶ ̶n̶o̶ ̶l̶o̶n̶g̶e̶r̶ ̶s̶e̶e̶m̶s̶ ̶t̶o̶ ̶s̶e̶n̶d̶ ̶e̶v̶e̶n̶t̶s̶.̶ ̶I̶t̶ ̶o̶n̶l̶y̶ ̶s̶e̶e̶m̶s̶ ̶t̶o̶ ̶s̶e̶n̶d̶ ̶e̶v̶e̶n̶t̶s̶ ̶o̶f̶ ̶a̶ ̶s̶p̶e̶c̶i̶f̶i̶c̶ ̶a̶t̶t̶r̶i̶b̶u̶t̶e̶.̶
I am mistaken, it seems to be working properly, I just did not test it enough and I think the lack of the filled square led me to the wrong conclusion.
So if I want to do something based on presence, then I need to have "send events" checked on the node? If I do that, I get duplicate events (i.e. multiple notifications, even if I am throttling one event per X).
I seem to get 3-4 events fire for a present event - could it be something that MQTT is doing? Using the default node-red mocsca MQTT broker.
I mistakenly clicked on a Hubitat Command Node so immediately clicked Done to close the Edit window and was surprised to see the blue dot indicating that I needed to deploy. I then clicked on other Hubitat Device & Command Nodes and got the same blue dot. I then ran a Node Red Restart and clicked on some more Hubitat Nodes. Still, more blue dots indicating that I needed to deploy. It doesn't happen with nodes from other palettes. The nodes definitely didn't change positions.
I haven't noticed anything wrong; it's just curious. Any theories? I have no intention to click on each Hubitat Node to re-deploy.
It can happen if you had changed the name of your device in HE and leave the NR name empty.
Then each time you'll open a node (with a device) it will fetch the new name and mark the node as dirty
To see what changed, you can look at the node attributes (without double clicking on it)
ex:
I use Node-RED to schedule lights on/off and I was looking for a way to account for seasonal shifts (DST, longer/shorter daylight hours). I have light sensors that I currently use to turn the lights on/off during the day if it is cloudy and I thought I could use the same devices to turn on lights after a certain time (sunset - 60 mins) if the lux reading goes below a certain threshold. I currently have the triggers as offset from sunset, but the light levels are not consistent across the months, so the lights come on when not needed in summer or come on when it's too dark during winter (unless I fiddle with the offset number).
I am currently using a node that has sunrise/sunset and offsets. The issue is that the offsets need to change. The light level at sunset -60 in winter is much lower than sunset -60 in summer..
You can change the offsets by month. Or, at least select month in the initial node, and then send it out one path for those months, with an appropriate offset. And then send it out another path for the other months with a different offset.
Alternatively, you could use the alt. start (right at bottom). I'm not sure how that works, because I dont use that part.
This is my fire fan, and I only want it to turn on in (southern) winter.
That's the direction I'm leaning in as well. I have 2 light sensors that automate the lights during the day but they are triggered on/off through the day. For the PM lights, I need them to turn on but not off, hence my approach of reading the lux setting at a point in time (say sunset - 60) but then not turning the lights on until the level hits the threshold.
I just set mine up for the max pre-sunset adjustment and leave it there all year. Yes that means it turns on 30-60 minutes early some days. Don't care.
I do use my Weatherflow weather station brightness reading to turn on lights outside of the night light hours if it gets too dark outside.
