Custom Component: Hubitat

I’m assuming this is what you were referring to, this is the debug logging from the MakerAPI integration in Hubitat.

app:11122022-09-20 06:57:02.250 am debugdevice event: {"name":"lastActivity","value":"2022 Sep 20 Tue 6:57:02 AM","displayName":"Front Door Mantle Light","deviceId":"1314","descriptionText":null,"unit":null,"type":null,"data":null}
app:11122022-09-20 06:57:02.235 am debugdevice event: {"name":"switch","value":"off","displayName":"Front Door Mantle Light","deviceId":"1314","descriptionText":null,"unit":null,"type":"physical","data":null}
app:11122022-09-20 06:57:00.185 am debugdevice event: {"name":"saturation","value":"100.0","displayName":"Front Door Mantle Light","deviceId":"1314","descriptionText":null,"unit":null,"type":null,"data":null}
app:11122022-09-20 06:57:00.178 am debugdevice event: {"name":"hue","value":"37","displayName":"Front Door Mantle Light","deviceId":"1314","descriptionText":null,"unit":null,"type":null,"data":null}
app:11122022-09-20 06:57:00.147 am debugdeviceItem called
app:11122022-09-20 06:57:00.145 am debugExecuting with secondary command: setColor [[hue:37, saturation:100.0]] on device: Front Door Mantle Light
app:11122022-09-20 06:57:00.066 am debugdevice event: {"name":"lastActivity","value":"2022 Sep 20 Tue 6:57:00 AM","displayName":"Front Door Mantle Light","deviceId":"1314","descriptionText":null,"unit":null,"type":null,"data":null}
app:11122022-09-20 06:57:00.056 am debug[COLOR_MAP]
app:11122022-09-20 06:57:00.048 am debug[childOff, childOn, childRefresh, childSetLevel, componentOff, componentOn, componentRefresh, componentSetLevel, configure, customEffectStart, customEffectStop, hold, off, on, pixelEffectNext, pixelEffectPrevious, pixelEffectStart, pixelEffectStop, push, refresh, reset, setAssociationGroup, setColor, setColorTemperature, setConfigParameter, setHue, setIndicator, setLevel, setSaturation, startLevelChange, startNotification, stopLevelChange, stopNotification]
app:11122022-09-20 06:57:00.045 am debug[{"hue": 37, "saturation": 100.0}]
app:11122022-09-20 06:57:00.044 am debugsetColor
app:11122022-09-20 06:57:00.043 am debugfindDevice called
app:11122022-09-20 06:57:00.042 am debugsendDeviceCommandSecondary called
app:11122022-09-20 06:56:59.980 am debugdeviceItem called
app:11122022-09-20 06:56:59.979 am debugExecuting command: on on device: Front Door Mantle Light
app:11122022-09-20 06:56:59.962 am debugfindDevice called
app:11122022-09-20 06:56:59.961 am debugsendDeviceCommand called
app:11122022-09-20 06:56:54.123 am debugdevice event: {"name":"power","value":"6","displayName":"Front Door Mantle Light","deviceId":"1314","descriptionText":null,"unit":"W","type":null,"data":null}
app:11122022-09-20 06:56:54.119 am debugdevice event: {"name":"lastActivity","value":"2022 Sep 20 Tue 6:56:54 AM","displayName":"Front Door Mantle Light","deviceId":"1314","descriptionText":null,"unit":null,"type":null,"data":null}
app:11122022-09-20 06:56:51.165 am debugdevice event: {"name":"lastActivity","value":"2022 Sep 20 Tue 6:56:51 AM","displayName":"Front Door Mantle Light","deviceId":"1314","descriptionText":null,"unit":null,"type":null,"data":null}
app:11122022-09-20 06:56:51.156 am debugdevice event: {"name":"switch","value":"on","displayName":"Front Door Mantle Light","deviceId":"1314","descriptionText":null,"unit":null,"type":"digital","data":null}
app:11122022-09-20 06:56:49.993 am debugdeviceItem called
app:11122022-09-20 06:56:49.992 am debugExecuting command: on on device: Front Door Mantle Light
app:11122022-09-20 06:56:49.951 am debugfindDevice called
app:11122022-09-20 06:56:49.950 am debugsendDeviceCommand called

You can enable debugging logging for the Hubitat integration in HA:

logger:
  default: info
  logs:
    hubitatmaker: debug
    custom_components.hubitat: debug

Then in your HA log you’ll see messages like this when working with devices:

2020-05-19 08:28:18 DEBUG (MainThread) [custom_components.hubitat.light] Turning off Basement Hearth Lights
2020-05-19 08:28:18 DEBUG (MainThread) [hubitatmaker.hub] Sending command off() to 1510

After looking at your log again, though, I wonder if the issue is that the integration is only sending hue and saturation with the set color, and possibly the light driver you’re using is filling in the level with 0, which would turn off the switch. I’ll try to get out a beta release you can try in a bit.

I just published v0.8.2b1. Assuming you’re using HACS, go to the Hubitat integration card in HACS, click the three-dot menu, and click Redownload, then choose “Show beta versions” and install 0.8.2b1. You may also need to click the Update button first.

1 Like

Awesome, I’ll give it a shot now!

Just downloaded that version and gave it a test and am happy to say that fixed the issue! Thanks for your help!

1 Like

@jason0x43 would you mind having a look at this post? I’m unsure where the problem lies, but I suppose its possible that it might be something with the habitat integration.

Hmmm…so the Hubitat integration is installed and working on that system? This isn’t a blueprint being created on a system with the hubitat integration installed and then used on a system without it? Or maybe the system had two instances of the Hubitat integration installed, and the one used to create the integration that was used as the basis for the blueprint was removed?

From the error, it looks like HA was trying to load a config entry for the Hubitat integration that doesn’t exist. I’ve never used blueprints, so I’m not sure how much information a blueprint contains about a system when device triggers are used. I’ll try to take a look at it in the near future.

Yes, hubitat integration has been installed and working on this system, without issue. I’m going down the path that you’ve gone down apparently, in moving everything but zwave/zigbee onto Home Assistant. This is the first issue I’ve run into with the integration, IF that’s where the issue is. Only one habitat integration has ever been installed on this system, and it was only installed once. I haven’t removed and readded or anything like that. The only thing I do with the integration itself is add additional devices on the habitat maker API side, and then reload the integration to pick them up. I took what you’ve taken from the log snippet, thinking there could be something wrong with the specific habitat entity I was using in the automation I made from the blueprint, even though that same entity seems to work fine if I just make an automation from scratch. So I removed the entity on the hubitat maker api side, reloaded the integration in HA, and removed the orphaned entity, restarted, and added the entity back all around. No change. Then I made another automation from this same blueprint using a DIFFERENT hubitat entity AND lifx entity compared to the first time. Same result, same error. What I really don’t understand is what gets loaded on reboot that apparently doesn’t cause any problems until then. As I said, the automation from the blueprint works perfectly when used immediately after creation. No issues, no delays, no errors, no crazy log entries, nothing. On reboot however, something is being checked that is causing some sort of reference problem, even though its not presenting a usage issue, or any issue at all that I can tell, until its checked. I turned on debug logging and there’s the log output below. It looks like there’s an issue with how one of the triggers from the blueprint is being passed? I don’t know why it would be any different than a scratch automation with the same trigger. In this case its showing device 514 which is the one I originally used to discover this problem. I can confirm however that this same error follows whatever hubitat device I use when creating the automation from the blueprint.

2022-09-29 08:21:57.367 DEBUG (MainThread) [hubitatmaker.hub] Loaded device list
2022-09-29 08:21:57.367 DEBUG (MainThread) [hubitatmaker.hub] Loading device 514
File "/config/custom_components/hubitat/device_trigger.py", line 90, in async_validate_trigger_config
hubitat_device, _ = get_hubitat_device(hass, device.id)
File "/config/custom_components/hubitat/device_trigger.py", line 213, in get_hubitat_device
File "/config/custom_components/hubitat/hub.py", line 471, in get_hub
2022-09-29 08:21:57.483 DEBUG (MainThread) [hubitatmaker.hub] Loaded device 514

I was able to replicate the issue locally. It looks like it’s only happening when devices in the blueprint are in the “hubitat” domain. The only such devices I know of offhand are push buttons, which are handled differently than other device types. Devices that are managed by Hubitat but that use standard HA domains, like lights and switches (which are in the “light” and “switch” domains) seem to work fine.

I’ll try to look into it more this weekend to see what’s going on.

1 Like

I’m sharing a nest doorbell from hubitat to HA. In Hubitat the button is exposed to trigger actions but it doesn’t appear to be come over to HA. I tried the native nest/HA integration but it’s not exposed there either.

=== Nothing to do with this Hubitat integration thread, but in the spirit to help @potts-mike ===
In the HA integration page for Nest, the doorbell press would be a device trigger event to kick off your automation(s).

And on the Nest integration page there’s this screen capture:

… so are you saying you are not seeing the “Doorbell pressed” trigger from the drop-down?

======

(Maybe we should move to a new thread to discuss the Nest Doorbell and the HA Nest Integration…)

I was wanting to pull the button press over from hubitat but the native integration seems easy enough. I can fleets if we’re to far off topic.

Whether the button shows up or not depends on what kind of device information Hubitat is sending over. If you want to post the capabilities for your Nest device here I can take a look. However, I’d say that if you’re already running HA, you may want to just go with that. Support for cloud-based devices like Nest is generally going to be better (or at least more up-to-date) in HA than Hubitat.

I just published v0.8.2b2 with a fix for the Blueprint issue. Give that a try and see if it resolves your issue.

1 Like

Thank you for the fast review. I can confirm that the issue is resolved. Automations function as expected when created via blueprint, and there are no errors present on HA reboot.

Hi,

Got a problem with Hubitat Integration. I could import all Hubitat devices. However, all sensors would not get updated in HA dashboard. I could turn on some lights in HA but the button would immediately “spring” back to off even the lights are still on. But in Hubitat, the device status are reflecting correctly, which is still on.

Is there anyway, you can get correct and real-time status if all Hubitat devices?

Thanks in advance

Hi All,

I’ve been using the Hubitat integration for quite a while now with 2 different Hubitat hubs acting just as radios for my HA installation. It’s been working perfectly until one of my Hubitat’s just died. I’m about to replace it with a new hub.

Is there any guidance on anything I should do on the HA side to ease the transition and be able to re-use all of the entities already created for the old hub? I know I’ll need to manually re-set up all of my devices again on the Hubitat side, and I can name each device with the same name as before, but I assume that it’s likely that the maker API IDs will change for the devices so it won’t be plug-and-play.

Any thoughts? Is there any way in HA to see what Maker API IDs are associated with each Hubitat device and manually update them?

There’s not an official smooth path to switching out a Hubitat hub. You could probably do this:

  1. Shutdown HA
  2. Edit configuration/.storage/core.config_entries and find the entry for the Hubitat you’re replacing. Record the first part of its data.access_token value; it will be a string of letters and numbers like 9f8312ab5. Update the entry’s title, data.host, data.app_id, and data.access_token to match the new hub (the title is just “Hubitat (first part of access token)”).
  3. Search the files in configuration/.storage and replace all occurrences of the first part of the old access token with the first part of the new access token.
  4. Update the all the Hubitat device IDs (short integer values) to match the IDs no the new hub
  5. Restart HA.

I’m having an issue with the Hubitat integration since a recent reboot. I’m guessing maybe I made a change on the Hubitat side that the integration doesn’t like… I’m not sure what change in Hubitat broke the HA integration.

Below is the error when the integration tries to load in HA. In particular it is complaining about ATTR_ALARM. I’m not sure what this is used for? Any ideas or references I could look up to get the integration working again?

Logger: homeassistant.config_entries
Source: config_entries.py:810
First occurred: November 10, 2022 at 3:24:07 PM (4 occurrences)
Last logged: 11:07:36 AM
Error occurred loading configuration flow for integration hubitat: cannot import name ATTR_ALARM from hubitatmaker.const (/usr/local/lib/python3.10/site-packages/hubitatmaker/const.py)

Thanks

That’s an issue somewhere on the Home Assistant side. Basically, it’s saying the Hubitat integration code in HA is trying to use a value named ATTR_ALARM from the hubitatmaker python package, and for some reason it can’t find the value.

What version of the integration are you using, and what version of HA are you running?

One thing you might try is to open the integration page in HACS (assuming you’re using HACS), click the three-dot menu button in the upper right of the page, choose Redownload, and the click Download.