Thanks!
@fblackburn 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.).
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? Or do you also consider them complete at this point?
The only ideas I can really think of (and none are "necessary" in my opinion) are:
- Throttling on command (and maybe device?) node to prevent high frequency calls to Hubitat overloading Maker API.
- 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.
- Future node maintenance additions such as new features that are added to Maker API (like the color setting changes)
1 Like
in the alexa2 node, the name of the device is passed in the payload. (msg.payload.name)
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.
Do we have a solution for reading/writing HE Global variables yet? I don't recall seeing that and certainly I don't know how to do it.
That isn't possible through Maker API as far as I know.
Hubitat would have to add maker API support for those before we could do that externally. I don't think anyone has ever make a feature request to Bruce for that.
You could always use a HTTP Node in NR and use the RM HTTP API Interface to do that (at least for writing)
1 Like
Ohh.... good point. I hadn't considered that.
1 Like
What's in your rbe node? Block unless value changes (ignore initial value?). If I do this, Clean goes and blocks, after time edge runs but immediately after edge it goes to charge. I just want it to edge until I get home or until the battery dies. I tried setting rbe to block until the payload is greater than or equal to stop, but it complained it wasn't a number
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.
.
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
5 Likes
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.
1 Like
@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.
2 Likes
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.
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.
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?
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.
3 Likes
This is definitely a useful node. I get around it using little loops with a switch node at the end ....
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:
1 Like
This matches my experience, that the flows continue to work despite the error notice.
