Custom Component: Hubitat

Ahh - re-read that - you don’t mean MQTT you mean my app !

I am one of the fortunate people with three HE hubs (S4) and I have never experienced slowdowns - I have an uptime of several months on one hub running my app.

I think the initial ‘pointing the finger’ by HE at 3rd party apps is perhaps misjudged. Agreed it can happen but I’m sure there are other issues that are the real culprits - whether that’s S5, Z-Wave or Zigbee (I only have a couple of devices on each) or perhaps Rule Machine I’m not sure. I hope my app will not be cited as an issue and I can only say it hasn’t been raised as an issue in the alpha testing. But until HE sort their hub slowdown issue minimising everything on HE has to be a viable path for those that do experience slowdowns. It’s a bad (and quite frankly broken) situation to have to deal with.

I’m just grateful not to experience this HE hub slowdown issue at all, ever. If I had I think I would consider moving platforms.

1 Like

Definitely no need to apologize. Your work on the mqtt app will definitely be appreciated by the community. My post wasn’t meant as a knock on your app but more that this integration seems more tailored to my personal needs i.e. HA only. Also, given the current situation with regard to stability, utilizing only native components in hubitat seems like a big plus…at least for anyone tired of troubleshooting slowdowns.

You obviously put a LOT of work into your app and it’s amazing what you have accomplished already. As a wise man once said. Options are good :sunglasses:

3 Likes

Yeah I for one am not sold it’s the your app.
I’m convinced there’s some little leak that they can never find that happens when many users (myself included) have some combination of devices and apps.

I’m just looking forward to a way to remove everything third party, except a few unavoidable drivers.

1 Like

Sorry - that’s a bit ambiguous !

You don’t think it’s my app - or you do ?
I’m pretty certain it’s not.

Anyway Jason’s app will probably suit you much better…

options are indeed good

Honestly, I don’t think it’s ANY app on HE that causes the slowdown (and I think that’s what @keithcroshaw was alluding to as well). I’ve said this for a long time now, I believe the slowdowns on HE are due to some sort of runaway process that consumes RAM and CPU cycles like a kid devours a bag of sugar. Before I shut my C5 hub down, I could pretty much pinpoint when my hub was going to start having issues and this was after support’s “suggestion” to disable all apps and drivers (which is a stupid suggestion anyhow). For instance, Ecobee, a supported integration, caused all sorts of headaches for me.

1 Like

Version 0.2.0

Version 0.2.0 of the integration is out. The updated version no longer requires access to the hub’s admin page. As a consequence the hub’s ID (and all entity IDs derived from it) have a different format, so if you did manage to get it working on your own setup, all entities will be recreated. (Or you can do what I did and edit .storage/core.entity_registry, manually update all the unique IDs of the original entities and remove all the new ones :laughing:.)

Note that this integration has only been tested in my local environment, so don’t be too surprised if something doesn’t work. I’m happy to try to fix things if you let me know. Also, both the integration and associated API library are on GitHub, and I’m always open to PRs if anyone gets ambitious. :slight_smile:

Also, Discourse’s “only 10 replies allowed during your first day” limit is super annoying. (I published the update last night, but Discourse wouldn’t let me make this post.)

1 Like

Version 0.2.1

Version 0.2.1 is a bugfix or enhancement, depending on how you look at it. :slight_smile: Some climate devices apparently don’t report their temperature units (or at least Hubitat doesn’t). The integration was defaulting to Celsius, which isn’t that great if your thermostat is reporting Fahrenheit temperatures. The updated version guesses the proper units based on the current reported temperature.

1 Like

When I try to install this through HACS I get the following error:

I’m running the latest version of hassio (0.104.3) in a docker environment. Any thoughts on how to resolve this?

Thanks in advance!

Weird. I’m also running 0.140.3, and it installed normally. The integration’s hacs.json does specify homeassistant 0.130.0, but that’s (according to the HACS developer docs) a minimum version, not the only version the integration will work with.

In any case, the hacs.json file apparently isn’t necessary (at least many other HACS-installable integrations don’t have one), so I removed it. Try installing the integration again. If it still gives you the same error, I’ll make a new release.

I’ve tried the install again with the same results.

Ok. I published 0.2.2, which doesn’t contain an hacs.json file, so there’s nothing tying the integration to any specific version of HA. Give that a try.

1 Like

That worked! Thanks for the quick response!!

Wow, thanks for this! I am pretty happy with Kevin’s MQTT integration, but this seems like it would fit my use case more and I’ve been hoping someone would release a MakerAPI version for a loooong time. HA’s ZHA is actually really good these days and keeps improving, I only keep Hubitat running on a different Zigbee channel for those few devices that ZHA doesn’t have native support yet.

1 Like

I, too, just wanted to chime in and say thanks for this! I’ve only done limited testing but it seems to be working great!

2 Likes

Version 0.3.0

Version 0.3.0 has a number of internal changes, but the one that matters the most is that the integration no longer uses Home Assistant’s webhooks for receiving device events. Using HA webhooks was causing a couple of different issues. Some users had configured their HA instances to use a public URL, which Hubitat couldn’t always reach. In another case, a webhook config wasn’t being updated properly, which caused the integration to set the wrong event URL on the Hubitat hub.

This version also adds an options flow, which allows component settings to be updated after the integration is installed. There’s only one setting that can be adjusted right now, the port for the event listener server (and you shouldn’t generally need to set that), but more options may be added in the future.

3 Likes

I’m loving this component!!!

I’d love support for buttons on Hubitat to HA. If there is a wish list, I’d put that on it.

Coincidentally, that’s what I’m working on right now. I’ve had a three-button zigbee control sitting around for ages, and now I actually want to do something with it. :smiley:

2 Likes

Also, the issue tracker on the GitHub repo is a great place to make and track feature requests.

1 Like

So it worked!
Last night I disconnected my internet and the link between HA and Hubitat stayed up.
Everything was working as expected.
Also was a good opportunity to prove that Hue and HomeKit work locally as I’ve been told they do.
Thanks for the hard work! I’ll look into the issue tracker to request locks and blinds at some point.

2 Likes

Thank you for creating this!! I’m been using a mqtt-bridge for over a year but would rather have a component for intergation.

I tried to setup it up but I received an “Unexpected error”

2020-02-13 13:51:43 ERROR (MainThread) [custom_components.hubitat.config_flow] Unexpected exception
Traceback (most recent call last):
  File "/config/custom_components/hubitat/config_flow.py", line 51, in async_step_user
    info = await validate_input(self.hass, user_input)
  File "/config/custom_components/hubitat/config_flow.py", line 35, in validate_input
    "id": hub.id,
AttributeError: 'Hub' object has no attribute 'id'
  File "/config/custom_components/hubitat/config_flow.py", line 51, in async_step_user
    info = await validate_input(self.hass, user_input)
  File "/config/custom_components/hubitat/config_flow.py", line 35, in validate_input
    "id": hub.id,
AttributeError: 'Hub' object has no attribute 'id'

HA: 0.105.3
HassOS: 3.10
hacs-hubitat - v0.3.1

Any ideas?