@fblackburn Another question on this...
How does it work if you use the same device and attribute in multiple separate nodes (for example, in different flows)?
I did the same thing with a sub flow:
The Home Assistant events:state node keeps track of previous and current states among a few other useful things. Is that functionality theoretically implementable for Hubitat nodes? Pardon my programming ignorance.
For used devices/attributes, yes current state is tracked via event updates. Previous state is not.
I guess my question is could it be? I don't know if the HA functionality is part of HA or part of Node-red.
It is part of the HA node programming. Could it be done in the Hubitat node-red nodes? Technically, yes.
You just have to present a need/business case that is compelling enough for @fblackburn to program it in. Or, of course, program it on your own and submit a PR in gihub.
What exactly do you want/need the previous state for anyway? Genuinely curious. Even when I used Home Assistant in Node-RED, I never used the previous state for anything. And have never needed previous state on Hubitat nodes in my time using them in Node-RED.
I don't really see a need for it myself, but in addition to linking HE to my NR/MQTT, I am also linking Homebridge to NR/MQTT. The palette for doing that includes a node keeping the previous state. The use case it talks about is something like this. Husband is using 1 light in the Living Room. Wife comes home and there is a flow that says turn on all of the lights for 5 minutes when anyone comes home. This turns on 10 lights, but then after 5 minutes, all of them return to their previous state (9 on, 1 off).
I think I would just build the logic myself or store the previous value in a flow variable, if I wanted to do such a thing, but this implies others do find it valuable.
As you said, easy enough to save in a variable. I'd hate to see us requesting so many more complications that can be accomplished with functions or other nodes.
Finally got my hub issues sorted and was able to try your flow
This works perfectly!!
Thanks a million!
Does anyone know what this means? It's a switch coming from Senisbo Sky? Just curious to the meaning as it is working?
"Unable to cast to dataType. Open an issue to report back the following output: DOUBLE: 68"
There is no difference for initialization when you select All or other attribute. Since you can request any attribute with the msg.attribute the node need to keep the state of all attributes.
Yes it's independent. If you have 100 device nodes configured to the same deviceId, then it will trigger 100 requests on initialization. If really needed a cache can be implemented, but as developper, implementing a cache system must be justified because it often implied some corner cases to handle.
Honestly I don't really understand all your worries about number of requests for the init part. The last time I asked about the number of device node some of you had, it was always <100. IMO, with the rate limit of 4 simultaneous requests to HE, this process can be safety done without randomize the init time or external mechanism.
If you have issues with the device node init, then I would like to know your setup and the issue, because for now, all of this is only theoretical for me 
What is the impact on HE if you have 10000 sequential requests? When I've done it to benchmark, my hub continued to work ....
p.s.: I talk only for the device node. I can understand randomize init process to avoid trigger command node at the same time (and there is no rate limit on this node).
I'm not sure there is a "problem" to solve. My questions are more around understanding. Without knowing the details it is impossible to know if there is a "better" or "worse" way of setting up the node-red side - or if it really doesn't matter.
I would agree that since the device node requests are throttled to 4/s, randomizing or throttling that probably does not make any practical sense/benefit.
Good comment, though, on the command node not throttling. I don't think that is a problem how I have things set up, but it is good to know nonetheless.
For event based updates to the caches, I assume all nodes that use the device/attribute all have their cache updated on the single event? I guess it would have to, really, so probably a stupid question... 
Yeah events are received by the config node and dispatched to the appropriate device nodes (with the deviceId)
I try to move token into a NR credential type (to ignore it on export and save it in the flows_cred.json). But I cannot decide myself if the application ID should be considered as a credential or not?
At beginning, I considered AppID as a username and the token as a password. But the more I think about it, and the more I think that to link token and AppID is a implementation details. I mean, having an URL without AppID could have be done on the HE side and only check the token and related internal information about it.
I know no one cares, but it's a headache for me now 
Someone has hint if we should consider AppID as a secret or not?
I vote for not, but as such I am ok if it is as well.
In order of security importance to me:
IP and AppID aren't really that security important to me.
IP is only interesting if you have already compromised my network as they are private IPs. So I don't really care if that isn't secret, as if you compromised my network MakerAPI/Hubitat access is the least of my issues.
Knowing the AppID isn't useful without the token.
Just obfuscating the token would be enough /2-cents
It's especially problematic on forum software like here where "deleting" a post is more a soft delete
I have been watching this thread for Hubigraph and the first thing I thought of was "I bet that could be done in Node Red."
I found a palette node-red-contrib-googlechart and thought I was well on my way. Unfortunately, it installs but there is an error triangle in the Node Palette Manager window and the nodes don't show up.
However, since there is an API, it could be done in Node Red I assume. I am just curious if anyone has tried it. Time to start researching Google Charts' API.
This timeline is the graph I really want that Home Assistant has similar and I really liked:
I use node-red-contrib-ui-state-trail (node) - Node-RED for state trail (gantt) charts.
It isn't quite as good, as it is 1 "swim lane" per node, and you can't put the label on the left (only above).
I've made a few feature requests (multiple graphs in 1 object, and labels on left) on the author's git, but I don;t know how energetic he is about adding features right now.
Example:
In the meantime for now you can use a text node on the left, and set the graph to not show its label.
Could probably do this, too. But I haven't tried it:
https://flows.nodered.org/flow/3827f07ed08826b01bd71b2c874f7fdc
Well, tested it real fast, seems like it could work. Would need tweaking/work though. As-is it only accepts 2 events (true/false) per variable. So if you had something w/3+ states it wouldn't work as-is. The benefit is that this method automatically makes a new row based on msg.topic, which would work well paired w/the event node.
Would be pretty easy to take motion, contact, and switch, convert them to true/false, and dump them in the chart.
Here is an example of exactly that - just taking motion, contact, and switch - converting active/open/on to "true" otherwise "false" and dumping it to the chart. Note that the colored bars on the bottom version are all jacked up (too thick, don't line up correctly):
1st version on top, catch-all version on bottom:
That's EXACTLY what I want to do w/ motion sensors & light switches. Thank you.
Download the Hubitat app
