Homebridge-Hubitat - Added support for HSM and button devices

🧰 Built-In Apps and Drivers
1

For those using the Homebridge-Hubitat plugin to support Hubitat on iOS devices (homebridge-hubitat - npm) (which is not the same as homebridge-hubitat-tonesto7), this plugin has now been updated with two new features:

  1. You can now Arm / Disarm the HSM Intrusion feature, and get alarm reports, in iOS Home. Arming / Disarming / and alerts are presented as a iOS Security System device.

    image
    image1242×2208 81.9 KB

  2. If you have button devices (or Z-wave Central Scene switches), the plugin can now create corresponding iOS Button devices. One use of these is to trigger HomeKit Automations when a Hubitat button device is activated. For example, by double-tapping on a Z-wave switch, you can now trigger HomeKit automations that have been associate with the "Double Press" of a button.

    image
    image1242×2208 177 KB

Both these features are configure through the plugin's config-ui-x interface. See the plugin's Readme for more information. If you encounter any issues, please raise them in the issues section on github: Issues · jvmahon/homebridge-hubitat · GitHub

3 Likes
2

You can do the same thing by adding a keypad to @dan.t or @tonesto7 plug-ins.

1 Like
3

That's great - so maybe I'm just catching up in my plugin implementation. Just curious - do you have to write rules or do anything to connect the keypad in the dan.t or tonesto7 plugins? I've set mine up so you don't need to do anything except check a box on the config-ui-x interface.

4

Nope, it just shows up as a device. I’ve been using this since I started with Hubitat a few years ago.

image
image1242×2688 77.9 KB

1 Like
5

Nice! In any case, for those who might be starting out on homebridge plugins, one of things I like about Hubitat is the ability to set up different MakerAPI instances with different device sets, so if the other Hubitat plugins work, that's great, but you can also combine features of different plugins using homebridge 1.3 and setting different plugins into their own child bridges each connected to a different Maker API instance. I'm not sure if the other homebridge plugins support the HomeKit stateless buttons feature that I just added (and, thereby, let you activate HomeKit devices and automations by using z-wave central scene commands), but if not, you can use my plugin with a separate MakerAPI instance just for the few devices where you may want to use the button feature. Its a convenient way to combine features without having to do a major change to your setups.

1 Like
6

image
image1242×2688 205 KB

7

I love that you spent the time to create this plugin and share it but have to ask what the motivation is?
What is missing from mine and Dan's plugin? I actively develop this plugin and it's fully customizable and feature-rich.
Please don't take this as being a territorial or negative post. I'm genuinely curious what's missing.

8

I suspect they are very similar. This wasn't about anything missing.

I think one difference (but I haven't checked your plugin enough to be sure) was the way I had handled multi-function devices. If I recall, your plugin generates a separate accessory for each, while mine had generated a single multi-function accessory (so a 4-function sensor would appear as a single accessory in my plugin with 4 functions, rather than 4 separate accessories). This was something I preferred (as I could use iOS's show-as-separate function if I wanted them ungrouped), but not a major feature in any case.

As for motivation, when I moved from HomeSeer to Hubitat, I simply ported over my existing HomeSeer plugin (homebridge-homeseer4 - npm). I had that port about 90% complete when I discovered yours existed. Since I knew my plugin worked for months at a time without problem on HomeSeer, I completed it and figured I'd keep using it for myself as I was most familiar with it and shared it as another example of how to interface with HomeSeer over MakerAPI.

On this point about this motivation and one of my continuing movitations being to provide another example of how to interface with Hubitat over MakerAPI: at this point, I think the biggest difference between plugins may be that the code base and operation model. My plugin is based on a Javascript Event Emitter model (i.e., this library: Events | Node.js v21.6.2 Documentation) which I think functions quite different from your code. The emitter model allows the more complex platform-specific (i.e., HomeSeer versus Hubitat) code to be fairly small (the most complex part of the platform-specific code really just needs to grab events from the platform and emit them to devices using a javascript emitter). So this most complex of the platform code is only about 250 lines (homebridge-hubitat/lib/HubitatSystemObject.js at master · jvmahon/homebridge-hubitat · GitHub) and really just consist of an initialize, send, listenForChanges, refresh, and "registerObjectToReceiveUpdates" function.

I think this emitter model gives a bit of code simplicity. For example, this past week I wanted to add support for for stateless programmable switches, to do that, I didn't need to touch any complex code. I just need to create the StateLessProgrammableSwitch service and call a simple function

.updateOnHubEvents(that.currentAccessory.id, "pushed", "held", "doubleTapped" )

And the emitter will send the device emitted events for pushed, held, doubleTapped to the HomeKit Service for the Hubitat Accessory with the designated Hubitat device ID # (that.currentAccessory.id). I think the simplicity of this can be seen by the Stateless Switch example: See Sign in to GitHub · GitHub

1 Like
9

I'm not sure where you saw the individual accessories being created but that has never been the case. It combines multiple services/characteristic into a single accessory.

In my other JS projects, I love using event emitters. In the plugin, I just decided to use homebridge's native event subscription system...
As far as adding new features the v2.0 of my plugin was designed to make adding support for new services/characteristic extremely easy.

The problem I've encountered with the maker API is that is slower than my new optimized app and is far more customizable for add/remove capabilities from devices in HomeKit.
In my experience, the MakerAPI app slowed down my hub.

Either way, I'm glad you moved over to Hubitat. It's always nice to have options for different integrations.
Maybe we could collab at some point on optimizing our plugins to make them better.

1 Like
10

Probably confusing your plugin with something else (as mentioned, I wasn't completely sure about that point!)

Thanks. I suspect that, like others, I combine the webSockets interface with MakerAPI. Maker API is used only when I want to send a control action from HomeKit to Maker API. Changes originating at the Hubitat side are "listened to" by the plugin using the EventStream / webSocket interface. Are you using something other than Maker API for the control from iOS back to Hubitat?

If your interested in another project I"m working on, check out this driver project: https://github.com/jvmahon/HubitatCustom
I think this is a pretty cool dimmer / switch / everthing code for z-wave devices. There's a readme on github, but as a highlight, it has a few features that I think are really unique, including:

  1. It can generate parameter settings for almost any device. It does this by querying the https://www.opensmarthouse.org/ database and learning about all the parameters a device supports and generating parameter setting controls automatically.
  2. It implements the z-wave "supervision" function for supported devices, which increases reliability of a z-wave network
  3. It supports devices with endpoints (automatically creating child devices)
  4. It requires very little user configuration for different device models / brands. This is because it learns about the devices by querying and caching z-wave reports about the endpoints, the z-wave class versions supported, central scenes, etc.
  5. It supports multiple z-wave button taps (3-5) .
11

My knowledge of Z-wave device params is rather limited, but it sounds pretty amazing... Having a universal z-wave driver is sort of a game changer.

I will take a look when I have some free time.

12

The app acts as the WebSocket and sends all events and is the command interface. It's incredibly fast.
HomeKit command to actual device actuation is <100ms.

1 Like
13

It actually all started with two simple concepts:

  1. It would be great to have a single driver that could adapt to the z-wave parameters actually present in a device, and this could be done if you just looked them up in a database. Fortunately, that database existed, has data on thousands of devices, and gave very complete results about z-wave parameters in JSON format so it could be done.

  2. If Hubitat had a simple function, which gives the class version implemented by a z-wave device, and both for the root and for each endpoint, you could write a much more powerful "generic" driver that supports many devices, with and without endpoints. I was able to do that by implementing a function:

ImplementsZwaveClass(classNo: [z-wave class], endPoint: [null or endpoint])

which returns a Integer giving the Z-wave class implemented by the root or an endpoint, or null if the class isn't implemented in the root or endpoint device. The trick with this function was that it has to respond in a device-specific way without having to make any changes to the driver so that the driver can work for any possible device. There's a lot of code behind that simple function (mostly gathering and caching z-wave reports), but it really lets the code adapt to the device well. There was also a lot of optimizing - if I have 100 of the same devices, the information only has to be gathered once!

1 Like