Homebridge Plug-in

šŸš§ Developers
525

I donā€™t suspect the node server, but I would need to confirm with the new code. Previously, I completely shutdown my node server and still experienced the issue. But if at least Homebridge isnā€™t running on the node server, Iā€™ll get errors from the Homebridge app in HE and that could influence the results.

I didnā€™t try the app with no devices enabled. Iā€™m about to travel, so remote testing will be out of the question. I can try tomorrow morning, but wonā€™t be able to test further until the end of April. A lot could change here in that time, so my test might not even be valid or at all helpful by that time.

526

I was thinking on the HE side. in the app there is a listener to listen to events coming from the node server. Who knows if its getting a lot of commands at that time that is contributing. Its just something else to look at.

Well then.. by the end of april we will have a whole new environment. Thanks for leaving us hanging here. :slight_smile:

2 Likes
527

I won't really be home until Saturday. :joy:

528

Hi Dan,

First of all thanks for your modified code.

I'm using your latest code and the web sockets method. Working great except for HSM updates. Homebridge crashes with the following error when changing HSM mode. Any idea what's going on?

[Hubitat Plugin Action] Command: stay | Value: Nothing | DeviceID: (alarmSystemStatus_1) | local_cmd: false

/usr/lib/node_modules/homebridge-hubitat-tonesto7/index.js:313
                        newChange.push( { device: 'alarmSystemStatus_' + $jsonData['locationId'], attribute: 'alarmSystemStatus', value: jsonData['value'], date: new Date(), displayName: jsonData['displayName'] });
                                                                         ^
ReferenceError: $jsonData is not defined
    at WebSocket.ws.onmessage (/usr/lib/node_modules/homebridge-hubitat-tonesto7/index.js:313:74)
    at WebSocket.onMessage (/usr/lib/node_modules/ws/lib/event-target.js:120:16)
    at emitOne (events.js:96:13)
    at WebSocket.emit (events.js:191:7)
    at Receiver.receiverOnMessage (/usr/lib/node_modules/ws/lib/websocket.js:789:20)
    at emitOne (events.js:96:13)
    at Receiver.emit (events.js:191:7)
    at Receiver.dataMessage (/usr/lib/node_modules/ws/lib/receiver.js:422:14)
    at perMessageDeflate.decompress (/usr/lib/node_modules/ws/lib/receiver.js:379:23)
    at _decompress (/usr/lib/node_modules/ws/lib/permessage-deflate.js:298:9)
    at _inflate.flush (/usr/lib/node_modules/ws/lib/permessage-deflate.js:376:7)
    at afterWrite (_stream_writable.js:383:3)
    at onwrite (_stream_writable.js:374:7)
    at afterTransform (_stream_transform.js:79:3)
    at TransformState.afterTransform (_stream_transform.js:54:12)
    at Zlib.callback (zlib.js:625:5)
529

Hey Tim,

Thanks for the feedback. The Websocket implementation is still in an alpha state and I am working on some bugs in there. This feedback is great though! Iā€™ll have something posted to fix this later this afternoon, have to get some work items done.

Iā€™ll let you know ASAP.

530

Awesome! Thanks for your work on this. I was able to fumble along so far...not being a real programmer but knowing just enough to barely get by :wink:.

If anyone else wants to try out the socket method that Dan has been working on here is what I did to get it working.

First install the websocket module using this command (I'm using a Raspberry Pi)

sudo npm i -g install ws

Next add the "update_method": "socket", to your config,json under the Hubitat platform

Example:

            "platform": "Hubitat",
            "name": "Hubitat",
            "app_url": "http://10.0.0.54/apps/api/9/",
            "update_method": "socket",

I wasn't experiencing any of the hub slowdown that others have been having issues with but I love to tinker and try the latest and greatest code. :grin:.

Hopefully using the websockets will help others who have been having issues with the direct updates method.

1 Like
531

All, just keep in mind that this is not a stable implementation yet!!!! I am working on it though :slight_smile: . Once I am done, I am going to create a pull request to @tonesto7 for him to review the work I have done. This is still his code and I am just trying to tinker....

@tsviper: I did fix the hsm issue that you had and updated the file in my repo.

2 Likes
532

Nice! Thanks Dan, worked like a charm.

1 Like
533

Hopefully we can collaborate on this whole project more. It would be nice to have more ideas and perspectives in the code other than just mine.

@dan.t pm me your github ID and I will add you as a collaborator on the homebridge repo so you can commit code.

I will hopefully pry myself away from this over the top client tool Iā€™ve created for my company. I just keep coming up with new use cases for more features and further down the rabbit hole Iā€™m going.

3 Likes
534

Would love to work on this with you. I actually have a version now that uses the MakerApi and the Event Websocket instead of the original Hubitat App. So far it works wonderfully for me, however, there are some limitations right. E.g. the MakerApi doesnā€™t support setting modes or the HSM. There is a feature request open to add those though.

I can say that I have not seen ANY slowdowns anymore but I am still testing myself.

PM with my GitHub ID is on its way.

3 Likes
536

Hey Dan, any update on this? I would love to try out your version that uses the MakerAPI and Event Websockets.

1 Like
537

Me too!

538

Me three...

29%20PM

I guess maybe I am trying it out one of the two. :slight_smile:

It's a debugging session.. I really just wanted to tease... :imp:

1 Like
539

E-v-i-l

1 Like
540

Hey, sorry for the delayed reply. I have a pretty decent version working. I actually "just" waiting to get the next Hubitat release to be able to support Modes and hopefully HSM status messages. Once I have this, I will see how we get this published. I can say that it is working pretty good for me so far, I haven't seen any hub slowdowns or lockups what-so-ever.

And as @csteele is teasing, I am also working on a second homebridge plugin that does not rely on the MakerAPI or the original app but uses the great HubConnect implementation is "just" another "hub" in that context. It is pretty slick as it will make it very easy for people with multiple Hubs (Hubitat and Smartthings or multiple Hubitats) to integrate with HomeKit. HubConnect will release their next version today which has some features that are required for this to work and @csteele and I are still working on a few details. I hope to publish a beta of this plugin shortly after HubConnect release their next version today.

5 Likes
541

Any indications if it's running more efficient than the current solution? Not to disparage anyone's efforts but I'd be interested in switching if it lessens the load on my hub.

542

Let's put it that way, with the original Homebridge app installed, I had regular slowdowns and hub lockups. At least every 3 days.
Now I have two homebridge plugins running simultaneously (one via MakerAPI and one via HubConnect) and haven't seen a single lockup in quite some time. It looks really promising.

2 Likes
543

Awesome to hear.
I look forward to using it when you feel it's mature enough.
I love using SIri, not so much looking at that Apple Home app...
I guess it could be worse...

544

I don't know how to measure "efficient" with the tools we have.. :frowning: "feels like" seems like it's as close as we can get :smiley:

I have 2 instances: the current Tonesto7 running on one computer and Dan's HubConnect version on a rPi and "it feels like" it's much snappier. Click a tile in the iOS Home app and the tile on the Hubitat dashboard changes more quickly than clicking a different tile on the original. "Feels like" :smiley:

1 Like
545

I get what you mean man.
The metrics are in your mind!