Node-RED nodes for hubitat

[danfox52]

I don't see anything in the release notes about passing arrays (such as colors) in and out of MakerAPI.

[JasonJoel]

Nope. I don't even think that is on their radar to add at this point. Apparently it is quite a lot of work to add.

[fblackburn]

Hehe I got some free hours now
... hubitat upgrade 2.2.0 in progress..

Yeah some new stuff for the next release and more for the next + 1 release
In fact I think that event type is already supported by this commit

I will do some tests and release a new version this evening I hope

[fblackburn]

Well I don't know what the physical/digital mean. With my button it's always digital when I trigger manually or with API. Maybe a driver issue (I have the Samsung Zigbee Button driver) or something that I don't understand?

[stephen_nutt]

I think it is physical if you flip a switch that is actually hardwired to your load (the light) and doesn't need Hubitat to do it's job? Digital is anything that passes thru HE like your button that is not connected directly to the load.

[mik3]

Can you show me what's set under the stop timer?

[JasonJoel]

@fblackburn

Well I don't know what the physical / digital mean. With my button it's always digital when I trigger manually or with API. Maybe a driver issue (I have the Samsung Zigbee Button driver) or something that I don't understand?

It is all up to the driver. You can put anything as a type in the driver. Some authors leave it blank, some make them all digital, others separate them out.

Pretty much all in-box drivers should generate physical on physical presses. All of my switch/dimmer user drivers do as well.

Events should be of type physical when you initiate the command or state change by physically interacting with the device (aka not from the hub/digital command). If they don't show up that way in Hubitat that means either the driver is sub-par (common), or the device does not give enough information to the driver to distinguish physical vs digital (rare, but happens sometimes depending on device type).

So in the end it isn't a very useful field/attribute - except when it is. Any time you want to distinguish between humans doing something and the hub it is absolutely invaluable. Otherwise you have to try and trap the initiating on/off programmatically and lock out the other on/off initiators, which sometimes works if there is only 2 initiators but it gets problematic if there are multiple.

[fblackburn]

new version 0.0.31

I would like to dedicate this release that include support of type digital/physical to @JasonJoel

Changes

• add new event node to allow to receive all events (see this issue for an example of use case)
• add new request node to allow to make a generic request to Maker API
• device: rename the Undefined attribute to All and allow to input a message without attribute to output all atttributes (thank you to @erktrek and @JasonJoel for the idea)
• device: bind extra event properties to the output messages (unit, descriptionText, type, etc..) (thank you to @olddoggy for report)
• device: fix status display for VECTOR3 dataType (thank you to @JasonJoel for report)
• config: improve error message when configuring webhook (thank you to @acucarestar for report)
• fix a random behavior that can empty dropdowns for all dynamic listing

Ongoing

• HSM nodes (someday )
• storing credential into a special type (It will avoid to export token). You can participate to the discussion here
• Internationalization (it's not ongoing but you can comment here if you are interested)

[aaiyar]

Sure. I've pasted the configuration for the three nodes that matter. The switch node, the change node, and the stoptimer node. When the change node received "msg.payload.value = active" from the switch node, it sends a msg.payload of "stop" to the stoptimer node - so the timer stops running.

When "msg.payload.value = inactive" is received by the change node, it is sent unchanged to the stoptimer node so it starts running again.

switch node

change node

stoptimer node

[JasonJoel]

@fblackburn

I would like to dedicate this release that include support of type digital / physical to @JasonJoel

LOL.

The event node is intriguing. I was following that discussion on git. I need to noodle on that some, I bet there is something I can use that for!!!

[bravenel]

@danfox52

I don't see anything in the release notes about passing arrays (such as colors) in and out of MakerAPI.

@JasonJoel

I don't even think that is on their radar to add at this point. Apparently it is quite a lot of work to add.

This is planned, coming up next. As well as URLdecode for secondary device params.

[JasonJoel]

Wow, wasn't expecting that. Shows what I know!!!!

Always happy to be wrong in that direction. lol

[morningz]

@bravenel

This is planned, coming up next. As well as URLdecode for secondary device params.

Thanks for the update!

[danfox52]

@fblackburn Are you aware of this?

⚠️Flow Library not detecting updated modules

[olddoggy]

That's why I couldn't see the latest version... run npm update, still name

[mike]

That would explain why I have no update yet.

[fblackburn]

No thank you for pointing out. I've requested a refresh

[JasonJoel]

FYI - It just showed up for me.

[aaiyar]

@fblackburn @JasonJoel

I'm happy - digital vs physical events works for locks as well! Let's me create sequences that distinguish between the maid arriving and leaving.

digital event

physical event

[JasonJoel]

Yup. Thanks @fblackburn for the type field (and in RECORD time)!

I'm off testing the new nodes as well, so far no issues.