How do I setup presence using Homekit and Homebridge?

Here you go:

{
    "bridge": {
        "name": "Homebridge",
        "username": "CC:22:3D:E3:CF:30",
        "port": 51827,
        "pin": "216-30-116"
    },
    "platforms": [
      {
          "platform": "Hubitat-MakerAPI",
          "name": "Hubitat Zigbee",
          "app_url": "http://192.168.10.170/apps/api/129",
          "access_token": “your-access-token”
      }
    ]
}

Is the MakerAPI better than the Homebridge app? My config.json so far has "app_url": "http://192.168.42.30/apps/api/108/" because my reading of the instructions led me to the homebridge app.

There is also some linkage between the device in homebridge and the device in Hubitat that I am trying to work through. When I launch Homebridge it says it "initializes platform accessory 'Chris Presence'" so it sees the switch I set up in Hubitat, but I do not see a device in HomeKit.

Sigh. I admire that everyone spends so much time building all of this great stuff. I just wish they would spend a few minutes writing non-trivial examples of how set things up.

Thanks for your quick response. I'll beat my head against a few more walls before I give up completely. :slight_smile:

I can only recommend to read this thread here:

There are also instructions on top.

The Homebridge MakerAPI integration reduces a lot of overhead on the hub site and is in my opinion much more reliable. But I am biased here a bit.... I wrote that plugin.

Also, I am not sure if you are running on a Rasberry PI, but I had one use who tried HOOBS (https://hoobs.org/) and said it was very easy to get running.

Looks interesting, I’ll give that a try. I'm not running on a Pi, I have a small desktop running Fedora that runs node-red, mosquitto and some custom bots along with Homebridge.

You said that you see the line "initializes platform accessory 'Chris Presence'", which means homebridge is running.

Have you added the bridge in Homekit? As in:

  • Open Home app on iPhone
  • Add Accessory
  • Either scan barcode given by Homebrigde or enter the code that is in the config.json

?

Do you have a good overview of what you're "building"??

MakerAPI is the "tool" that picks devices that will be seen by the Homebridge Plugin. That plugin passes the device info to/from HomeKit.

In the example config.json that Dan pasted above, there's 4 places MINIMUM you have to customize for your specific implementation...

  • app_ur* l must be YOURs.. and it seems you've found that. ( Your hub's IP + the app # (129 is what you pasted)

  • access_token again, must be yours. When you finish installing MakerAPI, it provides BOTH pieces of information. Unique information, no one here can guess or predict the values.

  • username can probably work, BUT I've had to alter that when Apple caches it and won't let go. For now, just use the value Dan pasted in.

  • pin -- same as username, occasionally there's a need to change, but for today, just use Dan's value.

Don't put anything else in config.json.

Yes, I did all of that and no love. However, I started over again with the MakerAPI plugin and after only 20 minutes my presence sensor is working. It's amazing how much easier things go when there is actually documentation. Thanks!

1 Like

I was building a simple presence sensor using HomeKit. I do know what MakerAPI and all of the other bits do, it is just that the documentation on setting up the homebridge app (that I was using) is kind of a hot mess when it comes to what should be in config.json.

I am a developer too, and I get it: nobody wants to write documentation. But there is so much inside knowledge required to configure this stuff, things like "username will probably work not not always, and pin may need to be changed by try this" that makes it very difficult to get a foothold. And all of the examples show bits and pieces of config.json, never a whole file. It is not just those 4 pieces, there is a "bridge" section that nobody includes in their documentation because they expect you to know that already.

Thanks for reaching out, I really appreciate that you took the time to respond, even if I did detect a bit of snark in the quotes around "buidling". :wink:

No snark intended.

My quotes meant (to me) that I didn't know exactly what to call it that would communicate. Communicate as in: transfer knowledge or improve understanding.

I'm happy to use snark with people I've communicated with enough times that they'd (probably) understand my humor... I never intentionally use snark on people I've never conversed with before.

I agree that the documentation for EVERYTHING (HomeKit/Homebridge related) is splattered all over the internet, with various vintages of advice too.

This Homebridge-Hubitat-MakerAPI and it's related homebridge-hubitat-hubconnect plugins are new.. 'paint's not dry' new.

It works many, many times better than the previous method(s) but my point is, it's unique. Any other documentation for other plug-ins will be wrong, in a big or little way.

Yes, there is an expectation that people get Homebridge working before adding plugins. Or at least the documentation I read years ago took me down that path. Everytime I spin up a new instance, it seems I have to go that way.. I have to see the "no plugin's installed" error messages to know I've got everything right. Then when I install the plugin, the errors make me focus on just the plugin area of config.json

In other words, this part is strictly for Homebridge, zero plugins:

{
"bridge": {
"name": "Homebridge",
"username": "CC:22:3D:E3:CF:30",
"port": 51827,
"pin": "216-30-116"
},
"platforms": [
]
}

Every appliance will need a plugin and you can have multiple appliances (with a platform <-- singular) within the platforms <-- plural section. Example of two dissimilar appliances:

{
  "bridge": {
    "name": "Homebridge",
    "username": "CC:CC:CC:CC:CE:3C",
    "port": 51826,
    "pin": "012-45-369"
  },

        "description": "My HomeBridge: Hubitat and TCC",

  "platforms": [
     {
            "platform": "tcc",
            "name" : "Thermostat",
            "username" : "csteeleemail",
            "password" : "passwd",
            "devices" : [
                  {"deviceID": "123456","name": "Main Floor"}
                ]
     },
        {
            "platform": "Hubitat",
            "name": "Hubitat",
            "app_url": "http://192.168.7.66/apps/api/874/",
            "access_token": "91d31b-token-311f9"
        }
  ]
}
1 Like

I just wanted to say thank you to all the posters on this thread. Thanks to it I've been able to get both Hubitat - HomeKit virtual presence, which works so much better than the official app because on iOS 13 apps get shuffled off too easily and it just wasn't triggering presence. Not to mention that getting the kids to let me tweak their phones is almost impossible.

And then I found a Homebridge Nest plug-in. This really made my day because they all work together. I won a new latest model Ecobee from the local power company (part of TVA) so the old Nest thermostat was gone, but I still have a Hello and 8 Protects. Two of us are stuck at home most of the time so finding that gap where the Protects can run their test can be hard. Especially when the kids don't keep the phones in proper shape. I dreaded getting raked over the coals because they did a self test with someone home. Use the same idea of a virtual button, I can set away and have it in homekit set Nest away or home, based on the current Hubitat Mode.

Also now I have a virtual representation of all of the Nest Protects in Hubitat that I can use for the HSM rules. So things like turn on a path of lights to nearest exit now become possible.

Since this thread was a huge help and I swiped and tweaked the virtual presence sense I felt like I ought to offer it here. I'd coded for around 20 years professionally, but it left me seriously burned out and heavily traumatized so I won't be posting it to github or tweaking it further.

Virtual Smoke and CO Sensor

/**

  • Virtual Smoke and CO sensor (Homebridge - Nest and Homebridge - Hubitat : intended use to expose nest protect to HSM rules)
  • Copyright 2017 Daniel Ogorchock
  • Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except
  • in compliance with the License. You may obtain a copy of the License at:
  •  http://www.apache.org/licenses/LICENSE-2.0
    
  • Unless required by applicable law or agreed to in writing, software distributed under the License is distributed
  • on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License
  • for the specific language governing permissions and limitations under the License.
  • Change History:
  • Date Who What

  • 2019-11-02 LostJen Made into Virtual Smoke and CO sensor (Homebridge - Nest and Homebridge - Hubitat intended use
  • 2018-07-18 C Steele Revamped into Presence
  • 2018-07-18 Dan Ogorchock Original Creation as "Virtual Illuminance Sensor"

*/
metadata {
definition (name: "Virtual SmokeCO Hybrid", namespace: "LostJen", author: "LostJen") {
capability "Smoke Detector"
capability "Carbon Monoxide Detector"
capability "Sensor"
capability "Switch"

}

  preferences {
      //standard logging options
      input name: "logEnable", type: "bool", title: "Enable debug logging", defaultValue: true
  }

}

def logsOff(){
log.warn "debug logging disabled..."
device.updateSetting("logEnable",[value:"false",type:"bool"])
}

def on() {
sendEvent(name: "smoke", value:"detected", descriptionText: "smoke", unit: "")
sendEvent(name: "carbonMonoxide", value:"detected", descriptionText: "carbonMonoxide", unit: "")
sendEvent(name: "switch", value:"on", descriptionText: "Alarming", unit: "")
if (logEnable) log.debug("on")
}

def off() {
sendEvent(name: "smoke", value:"clear", descriptionText: "smokeClear", unit: "")
sendEvent(name: "carbonMonoxide", value:"clear", descriptionText: "carbonMonoxideClear", unit: "")
sendEvent(name: "switch", value:"off", descriptionText: "All Clear", unit: "")
if (logEnable) log.debug("off")
}

def installed(){}

def configure() {}

def updated() {
log.trace "Updated()"
log.warn "debug logging is: ${logEnable == true}"
if (logEnable) runIn(1800,logsOff)
}

1 Like

With automations now being available in the shortcuts app as well, does it make more sense to create these automations in shortcuts rather than in the home app? Shortcuts gets straight down to "when I arrive" instead of "when anyone arrives". I guess the trade off is that each person's automation has to be configured in the shortcuts app on their phone, instead of configuring them all in the home app on one phone. Hmmm.

You can do the same in the home app. Just press the little information icon next to the “when anyone arrives” and you can select the individual person that that automation is for

Thanks for these instructions, I'm very happy with the results. :slight_smile:

1 Like

This is beating me... I do not have a + in automations. Did I mess up the HomeBridge setup?

Do you have an iPad, Apple TV or HomePod? One of those needs to be assigned as a home hub in the iOS home app to enable the automations feature.

I see now... darn. Not one that is always at home.

You could use a Homepod mini.

Thanks, will consider if I can find an ROI above presence.

This is what I've been using recently, I like it.

Yes, I've been reading. The whole family has iPhones, Apple TV, etc. Trying to resist.....