Node-RED nodes for hubitat

If it's working fine, I wouldn't worry about it.

.
New toy alert, new toy alert!

4 Likes

Oooh. That looks like fun! I need a new toy, too!

Edit: Ouch, kind of pricey. But very cool. Hmm...

Save 5% with code JOINUS. They've run better deals, but that appears to be the current offering.

It's a moderately interesting device. Pretty good for announcements. Someone ported the ST driver to Hubitat. It didn't really work well in my experience. So I pass switches to ST via HubConnect. Node-red should be more flexible.

1 Like

Hubitat is nothing but a way to get devices to show up in Node-RED for me at this point, I didn't look to install anything on HE to make this LaMetric work.

The node setup is pretty straight forward

2 Likes

Woohoo!

  • Maker API: Add evt.type for events (physical/digital)
3 Likes

Dang, I was about to post that and tag you @JasonJoel :grin:

Does @fblackburn have to do anything to his Nodes to make that available?

Yeah, he does, but it is pretty minor (I took a peek when the feature was added to the beta release). All in due time...

I was going to try and make a PR for it, but he is changing so many things in the nodes/making new nodes right now I wasn't sure I could keep up... Lots of commits in the code right now.

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

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.

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

Yeah some new stuff for the next release and more for the next + 1 release :laughing:
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 :slight_smile:

Screenshot from 2020-04-21 15-54-32

3 Likes

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?

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.

1 Like

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

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.

3 Likes

new version 0.0.31 :tada:

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

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 :wink: )
  • 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)
7 Likes

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
Untitled

change node
Untitled2

stoptimer node
Untitled3

1 Like

LOL. :slight_smile:

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!!!

1 Like

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

9 Likes

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

Always happy to be wrong in that direction. lol