HomeKit

I don’t mind at all.

1 Like

https://raw.githubusercontent.com/ogiewon/Hubitat/master/Drivers/virtual-presence-switch.src/virtual-presence-switch.groovy

1 Like

Any chance of a virtual doorbell? I realize I could use a switch or button, but I believe Homekit will only expose the Chime option to allow selection of HomePods for announcements. At least I think that is what is necessary.

1 Like

In my experience, HomeKit requires a doorbell button and a camera feed in order to allow selection of HomePod chimes. I've tried using Homebridge to expose only a doorbell button without a camera feed; and although HomeKit will see the device and sometimes acknowledge button presses, all HomePods will chime. The user interface for selecting which ones will chime only exists on a camera accessory with a doorbell attached.

Maybe this is acceptable for some people, but it's the unreliability that baffled me. I came to the conclusion that Apple never intended for a doorbell button to exist as a standalone accessory in HomeKit.

I can't find just a doorbell w/o camera that is HomeKit compatible. I can live with it chiming everywhere - that is actually what I am trying to do.

It doesn't exist. I think it's a use-case that Apple didn't consider (or care to develop).

I don't actually know how to do this with Hubitat, as my experiments with this use-case are from the Homebridge plugin I wrote for the Securifi Almond platform. @gopher.ny might be able to add it as an alternate export to Button, as it's very similar to the Stateless Programmable Switch accessory (uses the same Characteristic), but it's neither reliable nor supported by Apple. That means an iOS update could easily kill it. Besides, who wants a doorbell that only occasionally rings when it's pressed? :wink:

1 Like

Strange, the advanced vThermostat is unsupported for me.

As is the Wemo integration I use and the LG ThinQ integration.

(Test is the advanced vThermostat linked above, Cats Blankets is a Wemo integration)

CleanShot 2022-12-06 at 10.38.01

One of the restrictions Apple places on certified HomeKit bridges is that IP-based devices (like Wemo and ThinQ) cannot be published. It is technically possible, of course, as demonstrated by the fine Homebridge plugins available for Hubitat. Homebridge is not Apple-certified, so they do not have this restriction.

Another restriction is user-created virtual devices (which I'm guessing is the case with your advanced vThermostat).

From earlier in the thread:

Bah - there goes my dream setup to totally replace the horrible Heatmiser heating system I have then - I could have had somethings super rock solid with fewest points of failure there but it looks like i'll have to use Homebridge to keep it running if I want access in Homekit as well.

Being as Siri has some how got worse and worse over the last few years - my main aim with Homekit now is to just use it as a beautiful dashboard.

Sorry to deliver the bad news. :pensive:

The builtin integration is shaping up nicely for everything else, however. I am grateful for @gopher.ny's hard work. Once Hubitat receives certification from Apple, I'm planning to move all the devices over that I can. Yes, I will still have Homebridge running on the side for the garage door, locks, and anything else that doesn't fit the mold. A shame, but what can you do? :man_shrugging:

2 Likes

Virtual switches....

1 Like

That's what I did. Doesn't look nearly as good but it works the same. :slight_smile:

1 Like

This is why I won't use virtual switches. :laughing:

I thought you liked finding solutions... :smiley:

The problem I see is that this is all so new. Hubitat hasn't gotten Certification and we aren't privy to the conversations with Apple and how much NOT a bridge a Hub is. We don't much about anything and yet there ARE workarounds to what we all hope are just speed bumps along the way.

2 Likes

There is also a non-aesthetic caveat of virtual switches. If you like to turn on rooms of lights at a time with Siri ("turn on the lights in the garage") and you sometimes forget—like me—to include the accessory class ("turn on the garage"), it will likely open your garage as it turns on the lights. In this case, anything that has a switch will be flipped on in that room.

Another thing to be a aware of is security. Siri requires authentication for a HomeKit command that will grant physical access to the home. Unlocking locks and opening garage doors are in this category.

For example, if you say "unlock the front door" to your phone while the phone is locked, Siri will first ask you to unlock your phone (Face ID, passcode, etc.). It is the same with an Apple Watch, although the watch (once unlocked) remains unlocked while it's on your wrist.

For HomePods, it's a different story. Siri on a HomePod has no way to authenticate you, so it will not directly allow entry into the home. Instead, it will try to identify your voice (assuming you've set up Personal Requests) and then forward the command to your iPhone. You'll get a prompt to unlock your phone, after which it will unlock your door.

While this may seem heavy-handed to some, consider a burglar at your front door. That burglar can try shouting through the door or an open window "Hey, Siri, unlock the door," but it won't work because of the above measures.

If you use virtual switches, Siri has no idea that you've "hidden" a lock or a garage door behind a switch, and will unknowingly allow the burglar into the home (assuming it could hear the command).

This is perhaps a ridiculous scenario, but I hope it illustrates the point. In the end, you might consider it a feature to bypass this security with virtual switches. :rofl:

1 Like

Nice. :smile:

1 Like

I agree with you to an extent but honestly, if someone want in your home, they can bust a window. A lock isn't going to slow them down....

Strongly agree. :sunglasses:

I was just trying to explain how HomeKit deals with "secure" devices and the possible rationale behind it. I would be very surprised to know if someone ever gained unauthorized access to a house via voice assistant… :rofl:

The only restriction I'm aware of is that they don't allow them via "bridges," which is what Hubitat believes the hub will be classified as for purposes of certification. They are supported if directly connected--or via non-certified means regardless of connection type, as seen with HomeBridge. Why Zigbee or Z-Wave locks are subject to this while other Zigbee and Z-Wave devices aren't -- suggesting they know direct connection isn't an option -- I don't know (assuming they just want as much control over the connection as possible for these? At least with LAN devices, there could be a way).

We don't know what the future will bring. Apple, might be forced to reconsider if they take a different path when Matter forces the issue. It seems likely that the people approving the Certification are not the creators of the Certification limitations.

I continue to believe that waiting for a beautiful solution is just punishing myself. All those door locks/unlocks and GDO open/closes I'd miss out on if I had to wait for a certified solution haunt me. :smiley: I did that with Ceiling Fans.. I delayed installing Zigbee Fan Controller because I didn't like having to buy a repeater for each fan.

1 Like