A word about HA -> HE integration

🚧 Developers Code Share
,
202

The flow for a disconnect/reconnect is:

  • Disconnect
  • Attempt reconnect. If successful, done.
  • If reconnect failed, schedule another reconnect. Repeat (with growing interval) if necessary.

The problem with @SmartHomePrimer'a log is that it shows the disconnection but no failed retries. Which means that it seemed to succeed on retry the first time, but later is not functional. And no retries were scheduled as a result. Initialize just kicks it to get it working again.

I wonder if something like this could be related: Node Red losing websocket connection - Node-RED - Home Assistant Community .

What is unique about your different environments, @SmartHomePrimer, @ymerj, and @ogiewon

Another potentially useful tidbit: Node Red losing websocket connection - Node-RED - Home Assistant Community

203

OK. Works on the other hub. @ymerj Try deleting the parent device and recreating.
I will now try again on my main hub with a newly created device.

Screen Shot 2021-02-16 at 1.21.36 PM
Screen Shot 2021-02-16 at 1.21.36 PM873×359 84.8 KB

1 Like
204

What is actually at port 8123? Is it the HA installation directly or a mapping through something else, like docker?

205

My HA is in docker.

And I have a C7. Does it matter?

206

Ah shoot! I just last night moved all my sensors over. I will have to fix all my rules when I recreate the parent. :pleading_face:

207

Both hubs I'm testing on are C7, but different platform versions. Let see if that matters.

208

Yes that is the fix. My main C7 with Platform 2.2.4.148 and a test C7 with a beta platform build both work if the device is removed and recreated with the driver v0.1.18. Running Virtual Box is fortunately not a problem!

So it works! :grin:

Screen Shot 2021-02-16 at 1.41.42 PM
Screen Shot 2021-02-16 at 1.41.42 PM864×163 32.3 KB

209

As an experienced HA user, my first thought when I saw this project was "why?". A few weeks later, looking at it again, I'm still scratching my head. lol I'm not trying to knock on anybody's work, so please don't take this the wrong way. I do see a use-case for taking advantage of HA's massive integration abilities and bringing non-supported devices into HE. And I'm positive that's what sparked this project.

But here's my thought process when I say "why?". To use this integration, somebody is going to have to learn how to setup and how to use HA. Which is arguably the biggest barrier to entry for HA. So once someone has done that, why wouldn't someone make use of the rest of the advantages that HA offers?

To name a few:
The ability to run on more powerful hardware
Amazing dashboards
Offloading automations from HE which speeds up the HE hub

As someone who started down the HA path because of the daily slowdowns I was getting on HE, automations not firing, corrupted RM rules, etc... just the thought of bringing in 500+ entities to HE and trying to control them here with RM would scare the living crap out of me! On the flip side, leaving HE to handle all of the radios and using HA on a more powerful device to handle all of the heavy lifting as well as the amazing dashboard has by far been the most powerful and stable home automation setup I've ever used.

I guess in my head this would be like leaving the Ferrari in the garage to go drag racing with your Civic. Maybe this integration is like a gateway drug to get more people to install HA and then snatch them up later! hahaha

Now with that all said, and hopefully without having pissed anybody off :stuck_out_tongue:, if this project gets to the point where you can selectively bring in a few entities instead of all of them, I could be open to help test some devices. But as it sits I'm not willing to go down that path and potentially bring my HE hub to a crawl with 100's and 100's of new devices.

210

I am testing on a Hubitat C-7 running 2.2.5.131. Home Assistant is running on a RPi4, using the HASS image. I have been keeping this HA installation fully up to date with all HA updates to Supervisor, Core, and the Hass-OS.

211

This :point_up:

Setup is simple. I plan to help the project by adding instructions, but you can be certain the parts on loading HA will be minimal because I'll be posting them here, and the idea is to primarily bring in cloud integrations that so many want, but aren't available here. The idea is not to promote the use of HA as the primary hub over HE. Setup of HA is very simple thanks to the pre-built image. Installing either HomeKit Controller, HomeKit and even ZHA with some kind of Zigbee stick is also dead simple. Joining devices, also very simple. So you don't need to learn much.

Unnecessary

They're fine. If someone wants to do that, go ahead. There's nothing stopping them, from using @jason0x43 's integration to get HE devices into HA for that reason if you want. But this particular integration isn't intended for that.

Because in my opinion, Rule Machine is significantly easier to use and more powerful without needing to get intensely into writing automations in YAML :nauseated_face:
And I'll add that this is a perpetual myth. I have over 100 Rule Machine Automations and my hub is fast. I have noted that everyone I've asked about their HA use, almost always uses Node-Red for their automations. That says something about how horrible it is to try to do complex automations in HA.

So why not Node-Red, well I'm likely in the minority, but I just find it foreign. Uninviting and feels like I need to learn a new language just to use it. It tries to be the simple drag and connect UI that Stringify was, but it isn't. The idea here is a simple way to leverage the device support of HA to fill the current gaps in HE device support (primarily cloud devices people want to use). I'm finding my own benefits with a Conbee 2 and Xiaomi devices. Others may find benefits from the HomeKit Controller Integration.

Further, Z-Wave on HA isn't using the new Z-Wave 700 series, and at least currently it cannot, and HE users with C7 hubs will have Z-Wave Long Range too.

Everyone had a choice of using HA. Some have said they tried it, but didn't like it, so they're here. I didn't start with HA, I started with Insteon, moved to Wink for a bit, went to SmartThings, and ended up here. Now that I've tried HA, I still don't like it all the much, but it's serving a purpose for me. Maybe others will find that useful too. To me HE is an overall much more capable hub and far easier to use. It's commercial, so there's support and the community is engaged.

212

I'm not in the mood of redoing all my rules. So I tried rebooting the hub: no change. I disable my current instance of the driver and setup a new one: same thing.

Having to recreate a new instance to allow that part of the code to work makes no sense to me. But what do I know.

213

I agree. I think something is going wrong that we ought to be able to track down. Is there a log on the HA side that we could look at to see if there is any indication as to what is going wrong?

214

I think you emphazise eloquently the point of this driver:

It's NOT for HA users! It's for HE users.

3 Likes
215

I cannot tell you why it occurs, but this isn't the first time that just changing the driver code and resaving has resulted in this kind of thing. Where it works, but not totally. If I remember correctly, it was the Homebridge Maker API plugin where I once had the same issue. Once it was recreated, everything worked fine. :man_shrugging:

216

Can you please show your Parent Device's State Variables? be sure to refresh the web page before doing so, as State Vars do not automatically update.

217

Screenshot_20210216_145133

2 Likes
218

I guess state.remove doesn't work? We can set state.wasExpectedClose to false instead.

1 Like
219

same thing

Screenshot_20210216_150158

220

@SmartHomePrimer @ymerj thanks for not jumping down my throat. I'm not trying to argue, just bring more conversation which will ultimately put more eyes on this topic :wink:

While this is not for HA users and is for HE users, it requires the use of setting up and maintaining HA, which will then make these people users of both. Which there is nothing wrong with, I'm currently a user of both and have been for a while.

The purpose of my post was not to try to convince anybody to abandon HE to switch to HA. In fact, as a current user of both, I feel the setup to really be a "best of both worlds" scenario. Sure once you're on HA you can setup ZHA, Zwave JS, etc.. etc.. but if you already have a HE hub, I would ask the same question of "why?". HE has great radios, support for most zwave/zigbee devices, and overall they're quite stable.

Once you've setup HA alongside HE and become a user of both, why wouldn't one want to take advantage of the strengths of both? HE definitely has strengths over HA like I mentioned with the radios. HA definitely has strengths over HE as far as hardware capabilities and frontend design. And for automations, just browse through the node-red post to see countless stories of faster automation response once offloading the automations onto another piece of hardware. (@SmartHomePrimer yes I'm a node-red user too).

I guess my point, it was said there's a hope to attract the advanced user with lots of HA experience. That advanced user who will see this will likely have that same reaction as I and be concerned that the HE hub may not be able to handle everything HA throws at it. I may be wrong, but my C5 struggled at times to keep up with handling automations for 100 some devices. I just took a look, I've got 1,098 entities on HA. I think if I tried to load that all onto my HE hub it would grow a set of arms and slap me in the face LOL (Is there anybody with 1000+ devices on one hub?)

Having that ability to decide what the HE hub actually brings in would be at the top of my list. If that happens, I would happily bring over some of those entities to help test things out. Like I said, I do see the purpose of this and a use-case for those one-off integrations that just aren't supported by HE. Ultimately though, as people get comfortable maintaining both I envision a lot of these users will start thinking "hmmm maybe I'll try one of those fancy dashboards" or "hey look, I can easily setup that node-red thingy from that topic with 4,000+ posts over here, maybe I'll try it" and then all of a sudden they've started going in the opposite direction.

I swear, both this integration and Jason's custom component over on HA are going to be like gateway drugs. You start off with these and before you know it you wakeup on the floor of a server room with a usb cable coming out of your arm hahaha

221

I tested some changes in the code and it works now.

def webSocketStatus(String status){
    if (logEnable) log.debug "webSocket ${status}"

    if ((status == "status: closing") && (state.wasExpectedClose)) {
        state.wasExpectedClose = false
        return
    } 
    else if(status == 'status: open') {
        log.info "websocket is open"
        // success! reset reconnect delay
        pauseExecution(1000)
        state.reconnectDelay = 1
        state.wasExpectedClose = false
    } 
    else {
        log.warn "WebSocket error, reconnecting."
        reconnectWebSocket()
    }
}

I changed also initialize( )

state.wasExpectedClose = true    instead of    closeConnection()

and closeconnection( )

@tomw and @ogiewon could you review it?

2 Likes