Node-RED nodes for hubitat

[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".

[fblackburn]

Thank you for the information.

Since you are two with the same kind of issue, I will need to read a little bit more about websocket connect/reconnect behavior. It's the first time I implement websocket with JavaScript, so I probably not handled all possible situation. I don't really know what I need to have to help me to fix it (except time ). But if I need something more, I'll ask

Moreover, It's difficult to me to investigate websocket issue because I'm not at home until September and I (still) have issues with my hardware at home that complicate access to my HE

Meanwhile, you can use webhook

[JasonJoel]

Funny example of why webhook is superior in many cases shown below.

TL;DR: For locks websocket doesn't report the code used at all, webhook does.

Combining node messages - Node Red

Weird, I guess it is a driver difference then. As an example of webhook vs websocket differences, on websocket here is what I get on an unlock on the exact same lock. Note, no code info at all. Which, again for others, is why I strongly recommend using webhook by default, and websocket only if you have a specific reason to (and even then only on the specific devices you have the need for it on) [image]

[fblackburn]

If you set your Node-RED to print debug message would help to identify the sequence of websocket connection/reconnection.
Node-RED logging
You can add the following section in the config file:

logging: {
    // Console logging
    console: {
        level: "debug"
    }
}

[jason-lane]

@fblackburn

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).

If I wanted to try this out, would I need to set up a new Maker API instance for websockets, or would both NR config nodes connect to the same instance? I don't see any particular option in the Maker API screen regarding websockets.

[JasonJoel]

Both can connect to the same one. The websocket connection part really has nothing to do with Maker API (technically).

[fblackburn]

As @JasonJoel said, you can use the same Maker API for your both config nodes

• In both config nodes (websocket and webhook), Maker API is used to:
  • populate dropdown choices in each configuration panel nodes (list devices, commands, etc..)
  • init some nodes state (devices, mode, hsm, etc..)
  • used directly by nodes (command, mode-setter, hsm-setter)
• If the config node use webhook, then Maker API is used to:
  • receive events from webhook
• If the config node use websocket, then Maker API is:
  • not used to receive events
    (it's why you don't need to configure webhook section when you select websocket)

Then, you need to have a Maker API instance even when you use websocket

[Shaneb]

Do you guys have one flow per room or stick all the motion lighting in one flow?

[JasonJoel]

I tend to group by type more than room. I have a couple of lighting flows (too many nodes to fit in one flow). Have a "vent" flow, thermostat scheduler, etc.

It is so easy to search on Node-RED I haven't found it all that necessary to organize in a very strict fashion. CTRL-F, first few letters, and I'm there - regardless where it is.