Node-RED nodes for hubitat

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

[Shaneb]

Didn't know that. Learnt something new today

[TechMedX]

I do mine more by trigger, but I'm still learning (not sure I'll ever stop)

[mike]

I used to do it by room, but now areas/ideas.

3 of my flows are now full, so may have to think about changing again.

[MRobi]

I group by function.
So one flow for lighting, one flow for modes, one flow for thermostats, etc.. etc..

A lot of my flows would be nightmares trying to setup and organize by room, I'd have a million link nodes kicking around lol

Now if we're talking front-end.... that one is all sorted by room.

[erktrek]

I'm still doing it by floor/location/functions (control, health, testing).. I also have a ton of standardized subflows which I use to "hide" the complexity of various sequences. Also use lots of comments to separate/group sequences in a flow.

[Shaneb]

anyone come across this error ?

"Websocket error: {"errno":"ETIMEDOUT","code":"ETIMEDOUT","syscall":"connect","address":"192.168.86.32","port":80}" I keep getting it.

EDIT: restart seemed to fix it. I don't have any thing on 192.168.86.32

[erktrek]

A thought..

Take a look at your config nodes to see if there are any extra HE configs and remove them. If you've imported any flows sometimes the HE config can get included..

[Shaneb]

That's what I did I was stealing one of @april.brandt (I think) flows and she broke my NR

[erktrek]

You have to watch out for her (and others)... with their cool projects and nifty devices they will ruin whatever free time and money/budget you have. Very dangerous.

edit: and sanity -- forgot that too..

[JasonJoel]

You guys wouldn't have that problem if you would stop using the websocket connection method.... ( <---- just teasing, of course )

[aaiyar]

@JasonJoel

if you would stop using the websocket connection method...

More seriously - the improvement in performance for my flows with websocket was so marginal that I went back to using webhook.

[JasonJoel]

I went back once I started cataloging how much data I was losing on various events in websocket vs webhook.

I think @fblackburn use methodology is the best -

Have 2 config nodes, 1 of each flavour, and:

• Use webhook for everything by default
• Use websocket for specific devices/functions that you need more speed, and can live with the event data loss/differences
  • motion lighting might fall in this category

For me, I can live with motion lighting being 50-100ms slower, and just using webhook for everything.