Custom Component: Hubitat

Share your Projects! Custom Integrations
465

Along with stream and a ton of other things, looks like this integration has been broken with the 0.110 release

2020-05-20 18:24:19 WARNING (MainThread) [homeassistant.components.climate] ClimateDevice is deprecated, modify HubitatThermostat to extend ClimateEntity

2020-05-20 18:24:19 WARNING (MainThread) [homeassistant.components.cover] CoverDevice is deprecated, modify HubitatCover to extend CoverEntity

2020-05-20 18:24:19 WARNING (MainThread) [homeassistant.components.cover] CoverDevice is deprecated, modify HubitatDoorControl to extend CoverEntity

2020-05-20 18:24:19 WARNING (MainThread) [homeassistant.components.cover] CoverDevice is deprecated, modify HubitatGarageDoorControl to extend CoverEntity

2020-05-20 18:24:19 WARNING (MainThread) [homeassistant.components.cover] CoverDevice is deprecated, modify HubitatWindowShade to extend CoverEntity

2020-05-20 18:24:19 WARNING (MainThread) [homeassistant.components.light] Light is deprecated, modify HubitatLight to extend LightEntity

2020-05-20 18:24:19 WARNING (MainThread) [homeassistant.components.lock] LockDevice is deprecated, modify HubitatLock to extend LockEntity

2020-05-20 18:24:20 WARNING (MainThread) [homeassistant.components.binary_sensor] BinarySensorDevice is deprecated, modify HubitatBinarySensor to extend BinarySensorEntity

2020-05-20 18:24:20 WARNING (MainThread) [homeassistant.components.binary_sensor] BinarySensorDevice is deprecated, modify HubitatAccelerationSensor to extend BinarySensorEntity

2020-05-20 18:24:20 WARNING (MainThread) [homeassistant.components.binary_sensor] BinarySensorDevice is deprecated, modify HubitatCoSensor to extend BinarySensorEntity

2020-05-20 18:24:20 WARNING (MainThread) [homeassistant.components.binary_sensor] BinarySensorDevice is deprecated, modify HubitatContactSensor to extend BinarySensorEntity

2020-05-20 18:24:20 WARNING (MainThread) [homeassistant.components.binary_sensor] BinarySensorDevice is deprecated, modify HubitatMoistureSensor to extend BinarySensorEntity

2020-05-20 18:24:20 WARNING (MainThread) [homeassistant.components.binary_sensor] BinarySensorDevice is deprecated, modify HubitatMotionSensor to extend BinarySensorEntity

2020-05-20 18:24:20 WARNING (MainThread) [homeassistant.components.binary_sensor] BinarySensorDevice is deprecated, modify HubitatPresenceSensor to extend BinarySensorEntity

2020-05-20 18:24:20 WARNING (MainThread) [homeassistant.components.binary_sensor] BinarySensorDevice is deprecated, modify HubitatSmokeSensor to extend BinarySensorEntity

2020-05-20 18:24:20 WARNING (MainThread) [homeassistant.components.switch] SwitchDevice is deprecated, modify HubitatSwitch to extend SwitchEntity

2020-05-20 18:24:20 WARNING (MainThread) [homeassistant.components.switch] SwitchDevice is deprecated, modify HubitatPowerMeterSwitch to extend SwitchEntity

I have a bunch of exceptions like the following, and none of the entities are showing available.  HE seems to be fine and is on the latest version.

2020-05-20 18:24:20 WARNING (MainThread) [homeassistant.components.switch] SwitchDevice is deprecated, modify HubitatAlarm to extend SwitchEntity
466

Those are just warnings. I mean, that definitely needs to be fixed (and I just wrote a bunch of type stubs for HA last night for better type coverage), but I update to 0.110 this morning and everything still appears to be working.

467

Something else must’ve be wrong, I think it might be related to ONVIF integration changes. Once I got rid of that integration, the hub has stopped crashing and HE connected devices are working.

Thanks again!

468

Working fine here on 0.110. Any info on my post above about using the ‘unlocked_with_code’ trigger? I searched in here and couldn’t find anything.

Thanks!

469

Hmmm…I’ll have to look more into that trigger. For the time being, you could use an event trigger:

event_trigger
event_trigger1223×565 22.5 KB

The integration only emits one type of event, hubitat_event. An “unlocked with code” event will have an attribute of “code_name”, so that should definitely be in the trigger’s event data. If you want to listen for events from a specific hubitat device, you can include the device’s Hubitat ID in the data as device_id (be sure to surround the ID with quotes so it will be interpreted as a string). If you want to listen for a specific code, you can add a value property to the data, where the value is the “name” of the key in the lock codes list, like value: Family.

470

Completely off topic, but have you found anything over on the HA side that handles presence like your presence governor app does?

471

There is something a little funky in the lock events.
The code_name attribute does come through and can be used as a trigger. The problem is, the code_name attribute comes through even on a manual unlock/lock.

Here’s the scenario:
My front door lock has 5 codes, 1 for me, 1 for the wife, and 3 others for family members. Setting up a notification to notify the wife and I if one of the 3 family members unlocks the door using their code. So let’s say my parents come by, unlock the door, and the notification comes in. Everything is good. But now every time that door gets unlocked from the inside, it continues to send that notification until someone else enters a code.

This happens because the lastCodeName is being passed along with the unlock event but there is nothing to say if the door was unlocked using a code or manually. So using code_name as a trigger will cause it to continue to trigger even on a manual unlock.
In HE it distinguished how the lock was locked/unlocked
“Side Door Lock was locked by thumb turn [physical]”
This info is only in the logs and not stored as an attribute so I’m not sure if it’s passed along in MakerAPI or not.

472

Interesting. I only have Hubitat’s virtual lock to play with. With that, I get different events for lock, unlock, and unlock-with-code. For lock and unlock, hubitat emits one event with an attribute name of ‘lock’ and a value of ‘locked’ or ‘unlocked’. For unlock-with-code, hubitat emits 2 events: one for ‘lock’, one for ‘lastCodeName’.

Of all of those events, the integration currently only emits an event for the ‘lastCodeName’ event; none of the other events are emitted on the HA event bus.

In your case, then, are you seeing HA events with a code_name attribute, or HE events for lastCodeName, even when the lock is unlocked physically?

473

(Also, the fact that not all the events are being emitted on HA’s event bus is bad. Maybe.)

474

When I go into Dev Tools/Events and listen for hubitat_event I see nothing on a manual unlock, only when using a code. However in node-red, I see both. That seems very odd to me because the event is obviously there since I’m using event state as a trigger. When I saw the post above I knew this was on my roadmap of things I wanted to setup so I just did a quick and dirty flow in node-red to test it.

Capture
Capture816×127 6.8 KB

The trigger is any state change on the lock. Goes to a switch for locked/unlocked, if unlocked goes into another switch to check code used, and if the code used matches goes into a debug node. A manual unlock is still triggering the code used switch. Expected would be nothing since no code was used.

Here is the payload I’m receiving for a manual unlock

{"topic":"lock.side_door_lock","payload":"unlocked","data":{"entity_id":"lock.side_door_lock","old_state":{"entity_id":"lock.side_door_lock","state":"locked","attributes":{"code_format":"^\\d4$","codes":{"1":{"name":"Mike","code":"XXXX"},"2":{"name":"CODENAME","code":"XXXX"},"3":{"name":"CODENAME","code":"XXXX"},"4":{"name":"CODENAME","code":"XXXX"},"5":{"name":"CODENAME","code":"XXXX"}},"code_length":X,"last_code_name":"Mike","max_codes":30,"friendly_name":"Side Door Lock"},"last_changed":"2020-05-21T13:20:14.141930+00:00","last_updated":"2020-05-21T13:20:14.141930+00:00","context":{"id":"ca5dca24c02c4277b081dbef5125112c","parent_id":null,"user_id":null}},"new_state":{"entity_id":"lock.side_door_lock","state":"unlocked","attributes":{"code_format":"^\\d4$","codes":{"1":{"name":"Mike","code":"XXXX"},"2":{"name":"CODENAME","code":"XXXX"},"3":{"name":"CODENAME","code":"XXXX"},"4":{"name":"CODENAME","code":"XXXX"},"5":{"name":"CODENAME","code":"XXXX"}},"code_length":4,"last_code_name":"Mike","max_codes":30,"friendly_name":"Side Door Lock"},"last_changed":"2020-05-21T13:40:34.774895+00:00","last_updated":"2020-05-21T13:40:34.774895+00:00","context":{"id":"9ff8737a174c4817bcaf4dc6c4db7d77","parent_id":null,"user_id":null},"timeSinceChangedMs":33}},"_msgid":"51d18139.b241a"}

Here is the payload I’m receiving for a code unlock

{"topic":"lock.side_door_lock","payload":"unlocked","data":{"entity_id":"lock.side_door_lock","old_state":{"entity_id":"lock.side_door_lock","state":"locked","attributes":{"code_format":"^\\d4$","codes":{"1":{"name":"Mike","code":"XXXX"},"2":{"name":"CODENAME","code":"XXXX"},"3":{"name":"CODENAME","code":"XXXX"},"4":{"name":"CODENAME","code":"XXXX"},"5":{"name":"CODENAME","code":"XXXX"}},"code_length":X,"last_code_name":"Mike","max_codes":30,"friendly_name":"Side Door Lock"},"last_changed":"2020-05-21T13:40:38.445235+00:00","last_updated":"2020-05-21T13:40:38.445235+00:00","context":{"id":"87b93b4d5ce74b2eb03ec59207cbdf96","parent_id":null,"user_id":null}},"new_state":{"entity_id":"lock.side_door_lock","state":"unlocked","attributes":{"code_format":"^\\d4$","codes":{"1":{"name":"Mike","code":"XXXX"},"2":{"name":"CODENAME","code":"XXXX"},"3":{"name":"CODENAME","code":"XXXX"},"4":{"name":"CODENAME","code":"XXXX"},"5":{"name":"CODENAME","code":"XXXX"}},"code_length":4,"last_code_name":"Mike","max_codes":30,"friendly_name":"Side Door Lock"},"last_changed":"2020-05-21T13:40:43.436877+00:00","last_updated":"2020-05-21T13:40:43.436877+00:00","context":{"id":"415838fe907548b3a174a5062bb45a2f","parent_id":null,"user_id":null},"timeSinceChangedMs":24}},"_msgid":"b859aada.e7a318"}

Aside from a different message ID I’m seeing no difference.

475

Ah, I think we’re talking about different events. :slight_smile:

So, there are (at least) three kinds of events in play here:

  • Hubitat sends events to the integration in HA
  • The integration emits events of type hubitat_event on HA’s event bus
  • HA emits entity events when an entity’s state changes

The first kind of event appears to be working as expected.

The second kind of event (hubitat_event in HA) is emitted in two cases: 1) at startup (to signal the integration is initialized), and 2) when an HE event that can be used as a device trigger is received from Hubitat. Only “triggering” HE events will be emitted as hubitat_events on the HA event bus. Those are just the 3 button events (pushed, held, double tapped) and the unlockeds-with-code event. No other HE events will be rebroadcast in HA.

The third kind of event (entity state changes) is handled by HA. When the integration receives an HE event and updates the state of the corresponding entity in HA, HA will emit a state change event.

476

You’re looking at HA state events, which include all the HA’s entity’s attributes. For lock triggering it’s better to look at the hubitat_event, which contains only the data relevant to a particular event.

477

Not exactly, no. I’ve written an appdaemon app to do that, but it’s not as sophisticated yet with thresholds and what not. I’m fooling around with Bayesian sensor, to add to the mix. Given we’ve been homebound for so long it hasn’t been top of mind. :smiley:

1 Like
478

That’s how I’m doing it. Codes come in on the hubitat_event. In fact, I just grab the description that comes across and use that for TTS.

479

Manual unlock is an automatically created device trigger; it’s not one that relies on hubitat_events.

The whole trigger system in HA is rather…complex. :smiley:

480

Really, lastCodeName probably shouldn’t be a device attribute; it’s only meaningful when an event actually happens. But, that’s how HE does it, and I think someone requested it at some point, so there it is.

Hmmm…I could emit all HE device events on the HA event bus as hubitat_events, but that might get messy. Alternatively, for locks I could wipe out the lastCodeName property the next time a lock is unlocked, so that you could use normal HA events. If new state is ‘unlocked’, ‘lastCodeName’ will have the code, or not, used to unlock the lock, not just the last code name that was used to unlock it successfully (at any point in the past).

481

I’m using the event type you specified above, will see how that works. Not a lot of leaving the house and coming home late, so I probably won’t know if it works for a while.

On another note, ever since I went “all-in” on HA this weekend and moved ALL of my custom apps (alexa, ring, ecobee) and automations to HA, I’m shocked at how fast everything is and also how fast the Hubitat devices/apps pages load.

I know the guys over at Hubitat say their device has enough power, but there’s no way. My stuff moves faster than it ever has now that it’s not doing anything but being a Z-Wave/Zigbee event collector and forwarder. Sucks I had to spend $100 to get that, but I suppose it’s still better than dealing with HA’s native Z-wave support.

482

That’s been my experience, too. Hubitat performance has been rock solid since I offloaded most things, and from all I’ve read, it’s still (for now) a more stable Zigbee/Z-Wave platform than HA.

483

My biggest/only issue with this hub is still z-wave locks. They’re slow as molasses and god forbid you issue two lock commands at once. I just changed out one door to zigbee trying to ease my pain a little bit, but my other two locks don’t have a user swappable module.

484

Your idea of wiping out the lastCodeName might work. The data field on a thumb turn unlock is null whereas when a code is use it’s populated with the code.

Thumb Turn

{
  "content": {
    "name": "lock",
    "value": "unlocked",
    "displayName": "Side Door Lock",
    "deviceId": "1222",
    "descriptionText": "Side Door Lock was unlocked by thumb turn [physical]",
    "unit": null,
    "type": "physical",
    "data": null
  }
}

Using Code

{
  "content": {
    "name": "lock",
    "value": "unlocked",
    "displayName": "Side Door Lock",
    "deviceId": "1222",
    "descriptionText": "Side Door Lock was unlocked by Mike",
    "unit": null,
    "type": "physical",
    "data": "{\"1\":{\"name\":\"Mike\",\"code\":\"XXXX\"}}"
  }
}