No, i haven't tried that, didn't even know having multiple instances of Maker was even possible. Thanks for the tip.
I need to do a better job of grouping my rooms together so i can make a single call to answer the question "is something in the room on" but i have yet to really be able to mess with that.
I can only highly suggest to store states of frequent devices that you like to use in flows for decision making in flow or global variables. It will reduce your load extensively instead of querying each attribute when you need it
I understand how to store info in flow or global variables but not how to utilize to relieve stress on hub. Could you please post an image of a flow that does that? Thank you.
This flow would trigger, than request the current state of my presence device and decide if to turn on the light or not
Now, instead of checking the "presence" device at runtime, you can store the presence device state in a global variable and use that variable in our flow, like this:
I do a lot of this (although could/should do more). I only do it where there are events/states that I need to use frequently. If it is just an occasional extra call, I don't always go through the work to stick it in a variable.
Technically you could shove every device/attribute into variables, and never poll events manually. Would be a lot of work, but could be done... Would take more node-red memory, although not much - and that isn't a problem for me anyway.
Thanks I will take a look in the next week (I'm not at home for some days and I need to read about HSM?)
Do you have some error or debug log? Maker API can support a sh*t load of load (just not simultaneously )
I don't get your point. When you input a device state, it will NOT trigger a request to hubitat. It only read its current state (its current state is updated with events). It is exactly the same as setting it in a global variable (and probably better than setting a global variable because you need less nodes)
Great to know! I've been making it too hard on myself I guess.
Is that true for ALL attributes on the device? Or just the one specified in the node config? What if you specify a new/different attribute in the incoming msg (or have attribute undefined in the node)?
Yes it's true for all atributes on device. Since we already have the message, why not saving all attributes
So whatever attribute specified. the device already have all its attribute states
The device is initialized with a resquest HTTP
And kept up to date ONLY with events
EDIT: common guys, you know we are doing a better job than this
Awesome. I didn't know that (and obviously never took the time to look in the code either).
Does the same apply to the mode node (and hopefully the upcoming HSM node)? If you tickle the mode node input, does it just give you the known/cached mode?
I use a switch with the current mode in probably 50 different flow places, so I shoved it in a flow variable to ensure I wasn't making too many "mode" requests. That may have been unnecessary...