Any chance there will be support for sirens in the future?
Sure. I created https://github.com/jason0x43/hacs-hubitat/issues/26 to track development of that.
2 Likes
Waiting also for keypad support.
I started looking into that more a couple days ago. So, the kind of keypad you’re talking about is a security keypad that can be armed or disarmed? Assuming that’s the case, I think the implementation will work something like locks; the codes will be available on the device state, there will be services to set and delete codes, and the UI will provide a way to arm and disarm the keypad. (I don’t have a keypad, so I just want to make sure I understand how they’re normally used with Hubitat.)
Yes, that’s correct. They would ideally show up in Home Assistant as an alarm.
Great, that’s what I was thinking.
Almost 100% migrated off HE. This component was pivotal is helping make that happen. Thanks for the great work!
2 Likes
Congrats Doug. I truly wish I had this when I migrated. Took me a few days to build out bi-directional flows in Node-red. Then days of testing each device type before migrating. Painfully slow process for me.
With this I probably could have been done start to finish in a couple days.
Great work.
2 Likes
Do you mean you’ve moved over to HA Z-Wave and Zigbee?
No more Hubitat at all? Just asking.
Version 0.4.14
This version adds initial support for security keypads and alarms! Like locks, this is only lightly tested, because I don’t have any security keypads or alarms. Unlike locks, Hubitat doesn’t even provide a virtual security keypad driver. Good times!
Security keypads will end up as one or more entities in Home Assistant. At the very least there will be an alarm control panel, and there may also be other sensors (battery, temperature, etc.).
Standalone sirens, and keypads that also support the Alarm capability, will have an associated switch device to turn the alarm on and off.
Security keypads, like locks, provide services to set and delete codes, and to set the code length.
Alarms provide services to turn on the the strobe and siren separately (if the alarm supports both functions). Turning an alarm “on” will activate both the strobe and light, while turning it off will disable both the strobe and siren.
2 Likes
Ya, I’m almost ready to shut down HE hubs, depending upon a couple remaining devices’ support on HA. One I have covered, but it’s in the dev branch, which I’m not ready to get into yet. The other equation is managing lock codes on Kwiksets.
How are you finding your Z-Wave experience?
Are you using the native HA Z-Wave?
I can’t remember if we talked about this already. 
I had a miserable time.
As with most things on HA, I find the setup process cumbersome and a bit glitchy. The operation of things is not trouble free either, I still have small hiccups. Compared to HE, far superior performance everywhere, including and especially z-wave.
The real key is in the transparency. I can pretty much get into every metric or line of code I can imagine, helping me diagnose things that the HE is staff is unable or unwilling to do. The real nail in the HE coffin is the staff’s intransigence and tendency for ass covering and finger pointing and their continuance of enhancement work, rather than addressing the gremlins.
2 Likes
Just out of curiosity, what do you mean here? Z-wave performance (or at least stability) is the main reason I made this integration, since this seems to be one of HA’s weakest areas. At least, that’s the impression I’ve gotten from these forums (I haven’t tried HA’s native zwave support myself yet).
Maybe the speed.
I’ve been experiencing on Hubitat the Sloooooow Z-wave commands when doing more than one thing at a time.
I had to really make a sequence of events for my good night automation.
I could not get my devices to Add for the life of me, and the last time I tried a few did but then they all went to “dead”. I was like alright, I’m out.
Interesting. It’s been pretty instantaneous for me, at least when I control up to 3 or 4 devices at once. If I’m hitting many more than that it can slow down (my own “good night” scene takes a few seconds to update every light), but so far as I know that’s just because z-wave is a fairly slow protocol and can get bogged down when a bunch of commands hit the mesh at once.
Agreed, I assumed that was just “the way it is”…
I’m happy with my performance.
The Z-Wave isn’t perfect but I probably won’t buy any more anyway.
Unless those Inovelli dimmers really twist my arm.
I only had 10-15 active devices devices on zwave when I migrated (also had 10 iris v2 outlets as well but they only acted as repeaters). 3 were outdoor outlets, 1 GE zwave+ dimmer, 2 locks, a few contact sensors, a couple of button controllers and a motion sensor. Only 4 light related devices (where performance really counted in my book) and only 1 of those were indoors where I could really SEE the performance…so my experience is limited.
With that said, HA has performed at least as well, if not better with both zwave and zigbee for me with regard to speed. There are a lot of quirks and customizations needed to get it all going…but once set, they have worked really well. I was pleaseantly surprised.
I have a bias towards zigbee based on my perssonal experience with zwave in general so I’m migrating over anyway. The main thing I dislike on HA’s zwave implementation is the time it takes for it to initialize and settle after a reboot…WAY to long.
1 Like
I like the speed and flexibility of zigbee, but I’ve ended up with more z-wave devices since there are a lot more z-wave options, and I was experimenting with various use cases.
Yeah, that’s where I think a device like HE can be worthwhile. I’ve had a bunch of standalone bulbs, and I have a bunch of Hue bulbs. In general, the Hues have been much easier to deal with since the hub handles all the low-level details (maintaining the mesh, updating firmware, etc.), and I just need to deal with a REST API (when I’ve written things that work with Hue). Dealing with individual devices directly gives you more insight and more power, but it’s also more hassle than having a dedicated hub to manage them. I’ll probably migrate to HA eventually, though, maybe after the next z-wave overhaul.
HE has a core problem. I do not believe it is protocol exclusive. If I had to guess they have a memory leak(s) and poorly structured inefficient database. I’ve described my trials with them in great detail in the Hubitat forums, I won’t get real detailed here. The short of it is, a stacking delay of up to 30 seconds for automation to be triggered. I’ve done a tremendous amount of research on their behalf, which has fallen completely on deaf ears. One of them in particular instead favors blaming other people’s work. I think it’s a mistake to neglect the platform maintenance in favor of enhancement, and I believe it’ll result in a collapse of their user base if they don’t get this under control soon, if they even can.
I’ve had a few z-wave devices that don’t play nice with HA. Jasco Fan In wall Switch for example are giving me a fit, sometimes they join, other times they don’t. And dealing with the pairing process in HA for zwave is a pain, it’s a poor UX. But I have the same experience in zigbee, with some devices, though the UX is much better. That’s the one thing HE is doing, they’re adding device support like crazy, again, to the detriment of tech debt.
2 Likes