Node-RED nodes for hubitat

[erktrek]

So I was just copying your sequence.. I'm not sure it's needed now that I look at it. When the timer times out the message passes through. If it is "stop"ped then nothing happens which is what you want I think. Hope this makes sense.

[morningz]

.
So I have my IKEA blinds paired to my Hubitat and are controlled through NR on my Home Assistant system.

I picked up this pretty slick "HASP" (Home Assistant Switch Plate) which pretty much just bangs out MQTT commands to stuff. The device doesn't necessarily have to be tied to HA in any way, it's just MQTT in and out. My HA install doesn't even know about it, I interact with it 100% in NR.

I've got these three sliders working great to control my blinds but the HASP floods MQTT commands as it's sliding along.

That "varidelay" node was the fantastic solution for this to pretty much hold back the stream of messages it generates and only send the final one...

MQTT is the greatest thing ever btw... makes it so much easier to write automations in the sea of platforms

[LosinIt]

I currently have the grand sum of 2 flows (used NR before but now with the topic nodes) and 1 of them gets this error MOST of the time while the other gets it RARELY.

The NR log has this

[error] [hubitat config:Steve's Hubitat] Websocket error: {"errno":-111,"code":"ECONNREFUSED","syscall":"connect","address":"redacted","port":80}

They both use the same config node, of course. The main difference is that the node with the error is reading an integer while the other is reading a switch.

The kicker? If I remove the connection to the next node and deploy the error goes away. And when I then reconnect the next node the error does NOT return. I saw this same behavior when simply moving a debug node! Seems crazy to me.

I also tried a stop/start of NR because there's no way to stop a single flow ( ) and that seems to fix the issue but it later returns upon edits to the flow.

I'm stumped. Ideas of how to resolve this? In the end it's mostly an annoyance to my OCD because the flow works as intended.

[JasonJoel]

@fblackburn will probably have to chime in.

For my part, the 1st thing I always suggest when there are weird errors like this is to stop using the unsupported (by Hubitat) websocket connection method and use the 100% supported (by Hubitat) webhook method instead. These weird connection errors simply don't happen with webhook...

I don't use the websocket connection on any of my production node-red to hubitat connections (although I do on my Dev system to try and help with testing). The speed difference (which is minimal) was not worth the issues it causes on occasion.

But that is just my opinion - do as you see fit. Personally I wish websocket was never added to the nodes, but since I don't have to use it I didn't argue about it.

[cjkeenan]

@morningz

So as an example, my node was listening for a routine named "Random Station" and i could then parse out what device that was spoken to so NR would send the command to that device.

Could you send me an example of what this flow looks like? What specific nodes did you use to start the flow? Sorry this is my first foray into Node-RED so bear with me. node-red-contrib-alexa-remote2 is installed correctly and I got Hello World to work with TTS.

[Angus_M]

@LosinIt

Websocket error

I get these a lot. Edit a node and redeploy and it goes away. Strangely I've found the flows mostly seem to continue to work despite the websocket error message.

[LosinIt]

@Angus_M

Edit a node and redeploy and it goes away.

Maybe 5% of the attempts, in my case.

I'll capture the Ethernet traffic and hopefully learn something useful . @fblackburn, any thoughts on this issue?

[MRobi]

@JasonJoel

While I am happy if the node set stays as-is at this point, I wanted to ask if you had any thoughts or plans for future versions of the nodes?

One node I make extensive use of in the HA node pallet is the get-entities node. It allows for me to evaluate multiple entities or a group of entities against a state or multiple states and return a list of those that match, or if I choose those that don't match. Or >=, <=, etc.. etc..

Another that I could recommend would be a "wait until" node. It's useful for things like "wait until door is closed". Sure there's other ways to do it by expanding the node pallet, but could be a nice one to have built-in.

I think those are the only 2 I really use that aren't already in the HE stack. Overall the HE stack looks fairly complete, and any suggestions would only be to make things a bit more efficient not necessarily to add new features.

I also like how the HA state nodes (equivalent to the device node) essentially have the switch node built-in. It doesn't add any functionality that isn't already there but it does allow for cleaner looking flows, especially when you're dealing with multiple device states in a flow. I don't remember the exact number, but I imported a HE flow and was able to remove something like 8 switch nodes since the device node was able to evaluate and act as a switch for me.

[aaiyar]

@MRobi

Another that I could recommend would be a "wait until" node. It's useful for things like "wait until door is closed". Sure there's other ways to do it by expanding the node pallet, but could be a nice one to have built-in.

This is definitely a useful node. I get around it using little loops with a switch node at the end ....

[LosinIt]

I captured both failed and successful connections and they are the same, except for the temperature and humidity values, so I don't know what else I can do to track this down. Here's the ASCII view of the streams with the fail on the left:

Remember that the flow works fine in either case and the only difference seems to be the WS ERROR reported under the node instead of the value of the item.

I did happen to capture a Switching Protocols stream 4 times at widely varying intervals. I do not know why or what it means in this context but here is an example in case it figures into what I'm seeing:

[Angus_M]

This matches my experience, that the flows continue to work despite the error notice.

[bdydrp]

@cjkeenan

Could you send me an example of what this flow looks like? What specific nodes did you use to start the flow? Sorry this is my first foray into Node-RED so bear with me. node-red-contrib-alexa-remote2 is installed correctly and I got Hello World to work with TTS.

Are you after how to only have a specific device listen & act on commands?
if so, you can filter for device

I have this flow, that only will only act on the device in the switch node

If spoken to any other echo, it wont open the garage!!

[cjkeenan]

Yes that is exactly what I was looking for thank you, but I have a couple of questions.

1. What purpose does the Strip Wake Word node and Listen for phrases node serve?
2. Are they there since any device activity is picked up, not just when a certain phrase is said?
3. What is the configuration of those nodes?
4. Can I have multiple instances of the On Device Activity node without issue or should I just have all actions branched from a single On Device Activity node? What I mean by this is have the Listen for phrases node branch for each phrase, and then check which "room" it's in, or can I have each phrase have its own flow?

Alternatively, could you share me the code for that flow and I can just figure out what you are doing?

Also do you have to do anything on the Alexa app side?

[bdydrp]

I largely followed this guide when setting up the echo commands.

Approaches to room aware voice commands for Alexa with Node-Red

From the link - A “change” node is used to strip the wake word from the command, if present (i.e. if the user didn’t pause for Alexa to respond before uttering the command); the wake-word is stripped ahead of time rather than simply being matched in the regex-based router for reusability (specifically, for sharing with you all, as some of you may use a custom wake word) and also to shorten the required pattern string

If you follow along with his guide, it should give you some idea on further possibilities.

Here my flow anyway, so you can import and play..

[{"id":"23f2dc01.f66814","type":"switch","z":"20728976.2fb466","name":"Listen for phrases","property":"payload.description.summary","propertyType":"msg","rules":[{"t":"regex","v":"i'm home","vt":"str","case":false},{"t":"regex","v":"open (the )?garage door","vt":"str","case":false},{"t":"regex","v":"close (the )?garage door","vt":"str","case":false}],"checkall":"false","repair":false,"outputs":3,"x":530,"y":1260,"wires":[["be24efda.3b073"],["be24efda.3b073"],["be24efda.3b073"]],"outputLabels":["Turn on","Turn on",""]},{"id":"3c8a85e7.b229fa","type":"hubitat command","z":"20728976.2fb466","name":"Garage Door Control ","server":"26c9a23e.36f4ce","deviceId":"708","command":"childPulse","commandArgs":"1","x":940,"y":1260,"wires":[[]]},{"id":"be24efda.3b073","type":"switch","z":"20728976.2fb466","name":"Which device","property":"payload.deviceSerialNumber","propertyType":"msg","rules":[{"t":"eq","v":" G0W0SW08011403F1","vt":"str"}],"checkall":"true","repair":false,"outputs":1,"x":730,"y":1260,"wires":[["3c8a85e7.b229fa"]]},{"id":"fedde32a.da8ef","type":"change","z":"20728976.2fb466","name":"Strip Wake Word","rules":[{"t":"change","p":"payload.description.summary","pt":"msg","from":"^(alexa )?","fromt":"re","to":"","tot":"str"}],"action":"","property":"","from":"","to":"","reg":false,"x":330,"y":1260,"wires":[["23f2dc01.f66814"]]},{"id":"1d551c35.05eb04","type":"alexa-remote-event","z":"20728976.2fb466","name":"","account":"49135c4f.6bdd74","event":"ws-device-activity","x":110,"y":1260,"wires":[["fedde32a.da8ef"]]},{"id":"26c9a23e.36f4ce","type":"hubitat config","z":"","name":"Hubitat","usetls":false,"host":"192.168.20.11","port":"80","appId":"545","nodeRedServer":"http://192.168.20.10:1880","webhookPath":"/hubitat/webhook","autoRefresh":true,"useWebsocket":false},{"id":"49135c4f.6bdd74","type":"alexa-remote-account","z":"","name":"","authMethod":"proxy","proxyOwnIp":"192.168.20.10","proxyPort":"3456","cookieFile":"/data/cookie/alexa-cookie.json","refreshInterval":"3","alexaServiceHost":"alexa.amazon.com.au","amazonPage":"amazon.com.au","acceptLanguage":"en-US","userAgent":"","useWsMqtt":"on","autoInit":"on"}]

On the alexa side, i had to make a blank routine, to listen for "open garage door, then say ok"
If i didnt have this, when i said "open garage door" door would open, but alexa would respond with - "i cannot find a device called garage door"
You can use the palette node-red-contrib-amazon-echo to mimic a local device, so you don't have to use routines, but i could not get it to work, as i cant run nodered as root user!!

[fblackburn]

@JasonJoel

In an attempt to get this thread back on topic to Node-red nodes for Hubitat (at least for a few minutes ... EDIT: Well, only took 9 minutes to go back off topic lol.).

thank you for trying

@JasonJoel

I wanted to ask if you had any thoughts or plans for future versions of the nodes? Or do you also consider them complete at this point?

Since version 1.0.0, I consider these nodes roughly complete. All subsequent update are mostly bug fixes and features sugar (I cannot find the good English expression for what I want to say )

I'll continue to update it, but probably less actively than before (it's summer after all ). And because it's possible to make workaround for known issues/improvement (mostly listed below),

@JasonJoel

Throttling on command (and maybe device?) node to prevent high frequency calls to Hubitat overloading Maker API.

Planned, it should not be very hard to do

@JasonJoel

Refactoring the code changing from a local node based cache to a global cache. This is a fairly big change, but could have both memory benefits as well as reduce initialization time when there are a high number of duplicate device nodes. It also makes it trivial to make deviceId, attribute, or command an input settable variable in all cases, as they would already be in the global cache and available for use.

Yeah it can be done in two steps:

• global cache
• make deviceId dynamic

I implemented some proof-of-concept on global cache to view blockers. It a little bit harder than I though, but definitely possible. It will be probably the next change

@JasonJoel

Future node maintenance additions such as new features that are added to Maker API (like the color setting changes)

Sure, I try to read changelog on new MakerAPI version, but I also count on the community to point me new change too

@MRobi

I think those are the only 2 I really use that aren't already in the HE stack.

Thank you for pointing out. I'll take a look on these nodes if they can give me ideas
But I prefer to leave utility nodes external to HE nodes (easier to maintain, can be reuse without HE dependency, etc..)

[JasonJoel]

Thanks for all of your work on this. Many of us use this as a key part of our home automation, and it wouldn't be possible (or at minimum would be SIGNIFICANTLY harder) without these nodes.

So I very much appreciate it.

[fblackburn]

@JasonJoel

For my part, the 1st thing I always suggest when there are weird errors like this is to stop using the unsupported (by Hubitat) websocket connection method and use the 100% supported (by Hubitat) webhook method instead. These weird connection errors simply don't happen with webhook...

arrggg
I just notice that I totally miss my documentation about the use websocket option. This option look like if it was fully supported and/or recommended, but it was not my intention. It's more an option for people with critical speed needed (ex: have one config node with webhook for most automatons, but one another config node with websocket for motion detector).

I'll rework documentation and will add you as reviewer

[bdydrp]

Big thankyou to @fblackburn for these nodes.
Really appreciated!

[aaiyar]

@fblackburn

features sugar (I cannot find the good English expression for what I want to say

In Louisiana, the Acadians (cajuns) use the word lagniappe, which I think means a little bit extra as a gift.

[Angus_M]

In England we would say "icing on the cake".