Node-RED nodes for hubitat

[JasonJoel]

Ah yes, but for that you don't have to do a devices/all. I was assuming that is what you were saying you manually do.

You're right that you do have to tickle the device node to get it to cough up the value, but it already has the value in cache so that is basically free/non-performance impacting.

@fblackburn Maybe a thought it to have an option on the device node to re-send its configured value (where attribute isn't "all") on node/node-red restart? Many nodes have a feature similar to that.

Just an idea - I haven't really thought my way through it though.

[DementedDragon]

So has anyone else begun the adventure into FCM notifications?

Currently I am able to send push notifications to my phone and android tv, including images. I can also send repliable action messages that trigger automations.

First goal is this...

Doorbell/motion sensor triggered - > ffmpeg grabs and encodes a single frame from my rtsp and encodes is as a jpg -> uploads image to a https server -> Node red sends a push notification via google fcm servers to the tv/phone with that image of who is at the door. Message on phone includes options to unlock/lock the door, and trigger a message saying come in or no ones home etc..

Other ideas... Remote automation controls without the need for VPN DDNS etc.. Notification upon arrival with trigger to allow you to unlock the door (eliminate a lot of logic around presence and create an easy way to unlock the door for the maid/ups/friends/etc when home or away) Im sure there are a lot of potential uses for this..

So who else has stumbled into the FCM world? and how many of you who were unaware of it are now planning to go down the rabbit hole?

[JasonJoel]

Not me.

[stephen_nutt]

@DementedDragon

So has anyone else begun the adventure into FCM notifications?

I wasn't before because I had never heard of it. Now I have to take a look.

[erktrek]

That's sounds like fun.. but of course once I started looking into it I got sidetracked... now looking into the NextCloud nodes and possibly triggering events using node-red-contrib-ical-events.. trying not to use google calendar / drive etc too much..

Curse you internet / my short attention span!!!!!

[stephen_nutt]

@erktrek

node-red-contrib-ical-events

That looks like another cool one. I am playing with it now but not having luck getting a calendar info to show up in debug window.

[fblackburn]

@stephen_nutt

When I have been watching when this injected, there is a status of "Requesting" for minutes under the node.

Yeah it's not a effective solution .. But IMO if the request takes 30sec or 10 min, I don't care since I don't restart my Node-RED except for updates

@erktrek

Edit: mmmm now seeing a long "requesting" for the top "Get Devices" which is my main hub.. took about 30 seconds to clear. I do have a bunch of devices on that hub though.

I thought you've made this flow only for the state of the art , but yeah you should never request all devices twice. Otherwise you should send the result of one request and put it in a variable instead of requesting many time HE for the same information

@stephen_nutt

I'm wondering, if I was working on another flow and hitting deploy multiple times within a few minutes, would that have multiple simultaneous requests going to my hub?

Why not deploying only changed node? (but be careful if you use smartthing nodes, when I copied it, I saw bugs with this behavior )

@stephen_nutt

You don't need to Get All Devices after every time you Deploy anywhere in your flows which is what it was doing on mine.

Yeah, in my example it was only to populate graphic because battery events can take time to arrive

---

Personally, I make tests and development on another instance of NR and when it's ready to go to prod, I export/import the flow. It avoid to leave garbage in NR and/or restart for nothing

[fblackburn]

I don't know, maybe doing an export of all you flows and grep for deviceId

@JasonJoel

Pretty sure if you reboot the hubitat hub, the node-red hubitat config node will auto-repopulate once connection is re-established. No need to do it manually.

no auto-repopulate will be done
The populate will be done only if the first attempt to populate fail (ex: if you restart NR while HE is down, on the next event/trigger, NR will try to populate device)

If your HE comes down, your change a device state manually, HE comes up, then NR will be not notified because no event will be sent by HE

@JasonJoel

@fblackburn Maybe a thought it to have an option on the device node to re-send its configured value (where attribute isn't "all") on node/node-red restart? Many nodes have a feature similar to that.

you can just use a inject to request the value you want, no?
(maybe after a day of work I no longer understand the explanations )

[fblackburn]

@tmichael

so I would have 2 device nodes set to all (1 triggered on startup but not sending events; 1 sending events but not triggered by startup).

That's what i would have done too

@tmichael

Just to verify, I take this to mean that I will actually decrease the load on HE by switching from 1 node per attribute (current config) to 1 node requesting all and then breaking it out into individual attributes in NR.

Yes, decrease the load on HE when NR restart/deploy

[erktrek]

I thought you've made this flow only for the state of the art , but yeah you should never request all devices twice. Otherwise you should send the result of one request and put it in a variable instead of requesting many time HE for the same information

All my sequences are "art" what are you talking about?

I am now only requesting those devices on a HE hub startup.. each get was for a different hub.. but I understand what you are saying. Thank you.

[JasonJoel]

@fblackburn

no auto-repopulate will be done
The populate will be done only if the first attempt to populate fail (ex: if you restart NR while HE is down, on the next event/trigger, NR will try to populate device)

Interesting. I stand corrected! Thanks for educating me.

So maybe what we should have is an RM rule that turns a virtual switch "on" at hubitat startup... Then use that device event in node-red to trigger re-sync of the node-red cache... I'll go test that.

EDIT: My idea was dumb. @fblackburn comment below is the right way to do it.

@fblackburn

you can just use a inject to request the value you want, no?

Yes, you can. And I'm OK with that. It was just an idea that I've seen on a lot of the node-red nodes.

[fblackburn]

@JasonJoel

So maybe what we should have is an RM rule that turns a switch on at hubitat startup maybe... Then use that device event in node-red to trigger re-sync of the node-red cache... I'll go test that.

Hehe you can only listen on the systemStart from the location/event node

[JasonJoel]

@fblackburn

Hehe you can only listen on the systemStart from the location/event node

Duh.... :smack head: That would be even better/smarter.....

Although it would be nicer if the config node listened for it, then automatically make the devices actually used go refresh the value on its own without me having to trigger every node...

[fblackburn]

But yeah maybe it will be nice to have an advance menu in the config node with a checkbox to reload all hubitat nodes if we receive systemStart event.

For now, you can only restart NR if you have this event

[JasonJoel]

@fblackburn

But yeah maybe it will be nice to have an advance menu in the config node with a checkbox to reload all hubitat nodes if we receive systemStart event.

LOL. I was just typing that

Requested New Option: "Rebuild Cache on Hubitat systemStart Event"

Desired Behavior:

• Upon receiving a systemStart event, node-red side rebuilds the cache of Hubitat devices/values
• When rebuilding the cache:
  • Do not trigger a message being sent from a configured device node if new value = existing cache value
  • Do trigger a message being sent from a configured device node if new value != existing cache value

-- or --
If it is too complicated to generate msgs on mismatch then generating no msgs, but updating the cache value, would be the next best.

That would allow for very seamless restoration of continuity on Hubitat hub restarts.

[bdydrp]

Looked into this for my needs, but just cant seem to get my head around it for how i want it to work.
And since i'm no programmer, function nodes and the alike, seem alien!!

I'll keep looking and trying with built in nodes.

If anyone else has an example of how they use modes in NR (without HE) id love to see!
Cheers

[erktrek]

This is a job for one of @aaiyar's favorite nodes - "node-red-contrib-boolean-logic-ultimate" I think...

(Warning! I have NOT used this yet so hopefully this is correct!)

Take the msgs from both switches, change the payloads to "true/false" based on "on/off" then plug them into the BLU - in the BLU set "filter those to only true" option and hook the outputs to your mode changes... something like that.. you may have to play around with it.

node-red-contrib-boolean-logic-ultimate

edit: whoops you were trapping false conditions too - so don't set the filter above. It's a little trickier cause you have to take into consideration the XOR. Maybe when connecting to the BLU, ignore the XOR and just bypass BLU for both switch OFF/FALSE nodes...

[bdydrp]

Thanks
I had a quick play with that one and bool-gate.
Actually got it to work somewhat with bool-gate, but found whenever i would hit redeploy, it would lose the correct state - in fairness i didn't really look into why

I will checkout boolean-logic-ultimate again
Cheers

[erktrek]

Okay cool.. I was thinking something like this..

(switches are just for testing)

Note the change node is using JSONATA to change the "on/off" to "true/false"..

$contains(payload.value,"on") ? true:false

Got me thinking on this one thanks!!

The other way would be a simple function node that accumulates the msgs until full (store in flow var). then do the logic and spit out a result.

edit: of course there is a bug in my sequence.. sigh. coffee not working as expected this morning. BLU will fire on both AND and OR conditions I think so need to filter those...

[bdydrp]

Cheers
I will tinker again.....