Another area where initialization can bite you is rbe nodes... I've had them get 'stuck' in the wrong place before after restarts (until the next flip/flop of states) if I'm not careful. Sometimes ignoring the 1st value works, sometimes it takes more elaborate methods.
Really dumb question. What's the difference between msg.payload, msg.attribute etc.
Here I've got an output in the debug window, for possible answer(s).
Thanks to this thread, I've got HE integrated (somewhat) into Node-Red, with status, modes etc. Thanks for all the friendly helpful answers and questions.
msg.payload is the message payload from the preceding node(s). It will contain whatever the preceding node(s) put in the message chain. In the context of the Hubitat nodes in Node-Red, msg.payload.currentValue coming off of an event node is probably what you will use most.
msg.attribute is a variable you can add to a message chain and then feed into the input of a Hubitat event node to force it to go fetch the current value of that attribute from that device. You would only do that when you need to manually poll the status, for whatever reason, as opposed to waiting for a Hubitat generated event to report back automatically to Node-Red. Example: setting msg.attribute to "level" and shoving that into the input of an event node will tell it to get the current "level" attribute from Hubitat.
msg.command is a variable you can add to a message chain and then feed into the input of a Hubitat command node to tell it what command to execute on the device. It overrides whatever command was specified in the command node setup. Example: setLevel to tell the device to execute a setLevel command.
msg.arguments is a variable you can add to a message chain and then feed into the input of a Hubitat command node to tell it what extra parameters to use in the command to execute on the device. Example; 25 for a setLevel command to specify the device to go to 25%.
7 Likes
Question when i send this to my hub http://MyHubIP/apps/api/1411//attribute/switch?access_token=MyToken I get the status of all my switches but when trying to get the status of one particular switch with http://MyHubIP/apps/api/1411/device/962/attribute/switch?access_token=MyToken it does not work?
correct. To my knowledge you can't ask for just 1 parameter on a specific device. Correct me if I'm wrong, of course! Maybe there is a way I don't know of...
1 Like
So there is no way to query the hub for the status of one particular switch?
Just poll all attributes on the device and parse out what you don't want.
1 Like
Where everyone takes their documentation about Hubitat API !?
Never seen the /attribute/<name> neither mode API in any documentation ...
That's because it isn't documented. Isn't that fun?
The real question is - does that mean it might be removed/changed later, since it wasn't official to begin with? So is it safe to use or not?
3 Likes
I don't know if I laugh or cry .... no is really not fun
1 Like
Maybe we need to get Hubitat to chime in?
@bravenel or @mike.maxwell or @chuck.schwer Not sure who owns Maker API (Chuck?)... But there are some commands that are known to exist, but are not in the Maker API documentation. Examples include /attribute and some of the mode stuff.
- Are those "official" endpoints? Can they be safely used without fear that they might change suddenly, as they weren't listed as official to begin with?
- If they are "official" can we get them added to the Maker API documentation?
- If they aren't official (especially the mode items), can they be considered for "official" status, as there is no alternative in Maker API for those values/functions?
4 Likes
If the endpoints are being served by Maker API, then they aren't going anywhere, they are official, and this is just a documentation shortcoming.
Any examples you can show me would be of help.
3 Likes
Thankyou Thankyou Thankyou. This was really helpful. Especially my bolding/italics of your answer.
1 Like
Could you please explain this a little more? I understand what problem this solution fixes, just not sure which "message from a node" it's responding too. Is it the Hubitat device, or a node in node red? Because, the Parlor lights are responding to a message from a node right? The previous node in the flow.
My understanding is that you leave that unchecked if you want device node to only send a message on when there is an incoming message to that device node in your sequence. If you leave it checked, that device node will also send a message if device status changes/updates outside of sequence. For example, if checked, a device node will send a message every time it reports motion or goes inactive.
You have to be careful because it will also send on a msg.payload when it reports its battery state. You can also create an infinite loop if that is checked in a device that in turn sends a command to that same device to change it. Since the device changed, it will trigger your sequence again that then triggers the command node and on and on. Don't ask me how I know. 
That was kind of what @aaiyar was experiencing above.
Is that clear as mud?
3 Likes
I already forwarded Bruce the mode and attributes endpoint items.
If anyone has any other super-secret Maker API endpoints they know about and are not documented, we should try to get them to Bruce so that he can do any documentation updates one time - instead of death by a thousand cuts.
2 Likes
How do I correct this error?
With this flow I'm trying to accomplish. If either motion sensor detects motion turn light on (works fine). Then if both sensors are inactive for 5 seconds (which I'm good up to this point) AND the door is open (where my issue is) then turn the light off.
Here is my current flow.
How does your msg.attribute look like when it is passed into the "Bathroom Door" node? I am guessing that you are trying to query the current status which would mean that you need a msg.attribute = "contact" if it is a contact sensor
EDIT: Basically, any time you have an input to a device node you need a function node that set's the attribute that you are trying to query
I put a debug after the second switch (active/inactive after delay) and this is what it returns after deployed.
Is there anyway you can show an example of this. I'm slowly but surely grasping this learning very steep learning curve.
Here is an example:
and this is the content of the "Query contact" function node:
The output will then have the current state (open/close) in the currentValue of the message
In your case the function node needs to go right here:
Node-Red is a wonderful bottomless endeavor that will never cease to challenge your learning...
3 Likes
