[RELEASE] Homebridge Hubitat v2.0

the bind doesn't help - getting same error.

Its documented in the link up above from Denny, although I am not totally sure if the bind works right because hb-service still listens on 0.0.0.0 (which just means all interfaces). I set the settings on mine using the web UI but I assume you do not have access to that at the moment? If you do, its in the UI settings also. Switching it to avahi though got rid of all the other homebridge childs on port 5353 for me.

got it - I tried avahi and it said that advertiser is not available on my system. I tried Ciao and it didn't help either. Man, I'm really stumped here. It previously worked fine so I have no clue what broke it

Hmm.. you sure you don't have avahi running on that same port? This was the only thing I found and it specifically about FreeBSD: FreeBSD: Unsupported advertiser setting: 'avahi' · Issue #3147 · homebridge/homebridge · GitHub

According to that, even with avahi running homebridge was saying it was not available and failing with that same error.

I’m sure. I found the issue. There is a custom service used by UD EISY on that port. I killed it and Homebridge now works. I need to now figure out what that service does and how it can be modified. It’s part of their complex Polyglot ecosystem so I’m sure it breaks something when I kill it. If so I will have to install Homebridge on a rPI or my NAS. I like the idea of the NAS anyway.

3 Likes

EDIT I think by spending the last 1/2 hour typing up my question, that I might have answered it. Is the only purpose of this app/plugin to expose devices that are in your HE to HK? :man_facepalming:t2:

OMG I'm an idiot! I can't believe it took me this long, but I guess I'll still post to see if anyone sees anything else stupid that I"m doing! I knew that the built-in HomeKit integration was relatively new and did basically the same thing in regard to exposing devices from HE to HK, but since I started all of this AFTER the native HK integration already existed, I just completely view Homebridge as an app that gets ALEXA devices into HK and forgot anyone would use it for anything else.... I'm going to bed now... read on if you want a chuckle...

EDIT EDIT : WOW! re-reading everything below now that my brain got unstuck and I simply can't believe how much of that I could type without getting it!!! This is the densest version of me I can image :smiley:

----------- you can stop reading here unless you just want a laugh :man_facepalming:t2: -------------

I've been reading forums the past couple days until my eyes are bleeding DETERMINED to find my answer without having to ask... but I digress... I apologize if this is a stupid question:

What does the Homebridge Hubitat v2 App/Plugin do?

Is it a way to use a HE device as the target of a HB installation thereby removing the need to buy an rPI just to host the HB app? Does HB actually run ON the HE??? That can't be it, so...

Is it a way to simply expose devices in HE to an HB server running elsewhere like on an rPI?

If it is that, why might I want that?

My current setup is that I connect all devices that I can natively to HE and then use the new HK integration app to expose them to HK and for devices that I can't get into HE natively (like my stupid CARRO fans) I add them into Alexa and then use an rPI to run HB which exposes those Alexa devices to HK.

So basically...

Hubitat -> HomeKit Integration -> Home.app (any device that works with some HE driver)
Alexa -> Homebridge running on an rPI -> Home.app (Only devices w/o native HE nor NK drivers)
Hubitat -> Alexa Integration -> Alexa (virtual devices so I can kick off Alexa routines from HK)

I'm almost certain I must be making something too hard on myself since I can't fully grasp how this HB/HE apps could help me. What am I missing? Why would I want devices to go from HE into HB before getting exposed to HK instead of going directly from HE to HK like I'm doing?

At this point, unless virtual switches get out of sync or something I haven't thought of yet happens, I pretty much never have to open the Alexa app and I can control all of my devices from HomeKit. Setting up the virtual devices and matching them to predefined Alexa routines to control everything on that side from HK is tedious and exhausting.

Consider these stupid CARRO fans that I bought and installed before I knew anything, they have a "white" light, a "yellow" light, 10 fan speeds, and 2 fan directions. I started with the native CARRO app allows Siri shortcuts (but no HK integration) and that was a lot of creating scenes in the CARRO app and then shortcuts to them in Siri... until I realized those shortcuts only worked when the iOS device was on and connected to WiFi, there's no way to sync the shortcuts to my HomePod Minis. It would be amazing if I could simply expose these Alexa device components directly into HE and then use HE to expose them to HK, but instead I have to create a routine to turn the white light on and the yellow one off and the fan set to winter using speed 3, etc. and then I have to create another routine that is the opposite of thet to turn it off, and another routine if I want that fan at speed 4 instead of speed 3, etc., etc., etc,

Thank you everyone!!

1 Like

Looking to get some help with attribute and capability filtering. I have some garden soil sensors that I have added to HHv2. They come with extra capabilities (all I need is moisture), and I'm able to filter most of these out with the standard filters (water, illuminance, etc.), but there's no standard filter for Air Quality, which is still showing up in HomeKit. So per the instructions, I viewed the debug data (shown below) and found the Air Quality parameters. I have added these globally to both capability and attribute filtering (shown below), but Air Quality still get sent to HomeKit (I realize that I have added the attributes and capabilities to both sections, but this was just my second attempt to get them to work, in case they needed to be in both sections). I'm also getting Homebridge log errors for PM 2.5 (shown below), which I have also tried to filter out, but that also still produces errors with filtering applied.

I've never been able to get custom filters to work. I tried in the past and gave up. But I've had enough! :grinning:. Any help would be greatly appreciated. Sure I'm missing something stupid.

Sample Device Debug Data

Summary



Additions to Custom Attributes and Capabilities

Summary


pm25 Log Errors

Summary

The capability filtering is a little wonkey sometimes but I just tested the attribute by adding "pushed" in mine and it worked. I think if you get the attributes filtered out that will prevent it from showing in HK.

image

image

Thanks for the input. I wonder why it hates me. Trying everything I can think of to get them filtered out, and it’s not working.

Are you sure that you don’t already have this device added under the standard “Remove Pushable Buttons from these Devices” section? Attributes and Capabilities for my devices show up as allowed in the device debug data. (Even the ones that I have added the standard filters and do filter out properly.)

Yeah I spared the before and after screenshot but I checked it with and without the filter. I do feel like something is broken though, I know I played around with it before and I could not get it all to work.

Thanks. This is a custom driver, so I just did an end run around this one and commented out the capabilities and attributes I don’t need in the device driver since they are not valid for my devices.

1 Like

I'm having an issue where the virtual security keypad is getting stuck on "arming". Seems similar to this issue reported before. Any idea how to address?

@tonesto7 Any other reports of this issue with security keypad? It seems like from logging homebridge receives the commands ok but never updates the HomeKit status appropriately. Just gets stuck. What would be a good way for me to help troubleshoot?

Oh no, did we lose @tonesto7 ?? Last post I see is from September of last year?!? Not looking promising for much help on this issue :smirk: or is anyone maintaining this still?

I’m still alive. Just don’t check in here very much

6 Likes

Ok cool - so err any suggestions on the virtual security keypad issue?

Is the 'wonkiness' something you can duplicate easily? If you can give a device handler or attribute you've noticed doesn't filter properly I will gladly fix it ASAP.

where did you get a virtual security keypad?

I have a couple of the iris v2 security keypads, I can test on.

I want to apologize for being so absent!
I haven't had to mess with my setup much anymore so I don't work on the code much.
I recently read the notice about the breaking changes to Homebridge 2.0 and started reviewing the plugin code for compatibility.
I've made a few changes to the internal build to be compliant. The biggest change is enforcing the device name (Characteristic.Name) It no longer supports characters like the dash (-). You can edit the name under homekit to include the dash.

I will be doing some more testing and will try to address some of your issues.

3 Likes

Not quite sure what you're asking. But I am using the virtual security keypad to effectively bring my real security system into Apple Home. My real security system is a wired system that I bring into Hubitat using Konnected. It's worked for a long time now, but for whatever reason has stopped working. Homebridge seems to get the commands ok, both ways, but Apple Home just gets stuck on "arming" or "disarming" without ever transitioning states. Happy to test or provide logs, or whatever help you might need to figure out the issue. I've looked at the code myself but can't seem to pinpoint the problem.

1 Like