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.
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
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.
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.
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 .)
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.
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.)
Version 0.2.1 is a bugfix or enhancement, depending on how you look at it. 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.
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.
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.
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.
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.
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.
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.
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'
.)
