Ok so the thread has been a bit tough to follow. Has the "Connection Refused" issue been resolved amongst you guys? I was silly and updated everything and am now getting it as well.
Things seem to be working it, just don't want any issues like this mucking about.
Thanks!
First, backup your persist and accessories directory, along with your config.json file before going any further 
For me it was a combination of having the wrong HE Homebridge app, needing the client OAuth cert regenerated, and having the direct port setting (which isn't doing anything anymore except changing the port).
- What version of Homebridge are you running?
- What node plugin and app versions are you running?
- Post your config.json file without the api key
- Can you verify the api key and api directory in your config.json file match the requirement in the new app?
2 Likes
So... the curtains close action stopped working.
I have no idea why.
When I run Curtains Open from Homebridge I receive the following log:
However, I receive no logs whatsoever when I run Close Curtains.
Very odd indeed.
they may have tweaked the device handler...
It seems like the homebridge app doesn’t work correctly with the new “armed night” mode of HSM. My home app gets stuck with the system reporting “arming” when switching to that mode.
Hi all
Can I just ask, probably a silly question (only got my Hubitat yesterday so bear with me) can this HE version be installed and coexist with ST HomeBridge at the same time? I’m migrating over from ST but HomeBridge is kind of important for me as it has holds my entire presence Automations/SHM routine trigger (nothing else has been 100% successful for presence detection for me, I’ve tried ST presence, Life360, WebCoRE etc but never had 100% success and also no need to install a non native app on iOS)
Actually something is up w/ the new HomeKit I imagine. I get the same with a couple of my devices showing "arming", "locking" etc. Lights work well. Locks dont and I remember a while back there was an issue where Siri or Homekit wasnt getting the expected verbiage back from the devices. It would be "true" instead of 1 or something like that. I was thinking of setting it up as an issue on Github so @tonesto7 can help look into.
Should be no issue doing that. They're different plugins, just make sure you do not specify the port in the config.json file for the HE plugin and it will default to 8005, while the ST will stay on port 8000.
1 Like
Amplifying what @SmartHomePrimer said...
The Homebridge app on Hubitat exposes the exact commands for config.json. It's the minimum required so unless you know the exact impact, don't start with anything else. 
The commands shown assume it will be the only entry, but since you're trying to have two, the syntax is hard to just guess.
As offered:
{
"platforms": [
{
"platform": "Hubitat",
"name": "Hubitat",
"app_url": "http://192.168.x.y/apps/api/???/",
"access_token": "xxx-xxx-xxx-xx-x"
}
]
}
But you'll already have the "platforms" row for your ST.
Between the square brackets, add only the "meat" of the config:
,
{
"platform": "Hubitat",
"name": "Hubitat",
"app_url": "http://192.168.x.y/apps/api/???/",
"access_token": "xxxxx-xxx-xxx-xx"
}
NOTICE that it starts with a comma !!!
1 Like
Hi all, can anyone help me figure out how to remove a capability from a virtual presence switch I have? I pasted the following into my config.json:
"excluded_capabilities": {
"PresenceGuest": [
"Presence Sensor",
"Sensor"
]
}
And this is what I how I have set it up in HE:
Did you find documentation that said that's possible? I thought the ability to exclude had to be part of the Homebridge plugin. I used to use a Wink Homebridge plugin and the author had added the ability to exclude devices from discovery, but that same method did not work for other plugins.
I know @tonesto7 added the ability to exclude temperature from water and contact sensors, by conveniently changing an option in the HE app, but I'm unaware of the capability to do what you're trying to do.
Interesting. How do you find out what that known capabilities of a device are so you're certain you have the correct syntax in the config.json file? For example, my terminal only shows me unknown capabilities when I start Homebridge. It doesn't show me the known capabilities.
[11/7/2018, 9:06:59 PM] [Hubitat] Unknown Capabilities: ["SmokeDetector","PowerSource","ChangeLevel"]
You look to be using a text id not the device id (a number).
in logs, for example, there's the dev:# -- it's that #
dev:8 2018-11-17 11:10:51.664 am info MultiSensor6C (office) is active
8 in my example.
I would think both would be viable. I'm just not sure about the capabilities @walksonair has listed in the config.json file. I see Presence Sensor, but two word capabilities never have a space as per my example of the Unknown Capabilities in my installation.
https://docs.smartthings.com/en/latest/capabilities-reference.html#presence-sensor
metadata { definition (name: "Virtual Presence Sensor", namespace: "csteele", author: "C Steele") { capability "Presence Sensor" capability "Sensor" capability "Switch" command "arrived" command "departed" }
From Hubtiat's github example driver:
metadata { definition (name: "Generic Z-Wave CentralScene Dimmer",namespace: "hubitat", author: "Mike Maxwell") { capability "Actuator" capability "Switch" capability "Switch Level" capability "ChangeLevel" capability "Configuration" capability "PushableButton"
So you may or may not know I'm not a developer, so forgive my ignorance. Isn't this a difference between groovy and the javascript runtime in Node.js ?
this.knownCapabilities = [ 'Switch', 'Light', 'LightBulb', 'Bulb', 'Color Control', 'Door', 'Window', 'Battery', 'Polling', 'Lock', 'Refresh', 'Lock Codes', 'Sensor', 'Actuator', 'Configuration', 'Switch Level', 'Temperature Measurement', 'Motion Sensor', 'Color Temperature', 'Illuminance Measurement', 'Contact Sensor', 'Acceleration Sensor', 'Door Control', 'Garage Door Control', 'Relative Humidity Measurement', 'Presence Sensor', 'Carbon Dioxide Measurement', 'Carbon Monoxide Detector', 'Water Sensor', 'Window Shade', 'Valve', 'Energy Meter', 'Power Meter', 'Thermostat', 'Thermostat Cooling Setpoint', 'Thermostat Mode', 'Thermostat Fan Mode', 'Thermostat Operating State', 'Thermostat Heating Setpoint', 'Thermostat Operating State', 'Thermostat Heating Setpoint', 'Thermostat Setpoint', 'Fan Speed', 'Fan Control', 'Fan Light', 'Fan', 'Speaker', 'Tamper Alert', 'Alarm', 'Alarm System Status', 'AlarmSystemStatus', 'Mode', 'Routine', 'Button' ];
That's what Homebridge knows about.
It's going to receive the values from the Homebridge app, which can only be values from Groovy code.
Thanks very much for the response thus far! I changed the ID to what @csteele mentioned. One issue was that I didnt know how to find this out other than looking in logs and there was nothing there. I added some trace lines and got a number ID. Thanks!
So it looks like the plugin is able to remove one of the two capabilities I want removed (see SS below). Any idea how to trouble shoot the inability to remove the second capability?
Oh and I should also add that the "Presence Sensor" capability thats being difficult to remove isnt really doing anything when I change the state of the virtual device (meaning, it wont show as present when I switch it to that).
My own Virtual Presence Sensor driver is a "Hybrid" driver attempting to allow it to be seen as EITHER a switch or a sensor, depending on the app's selection criteria. None of us have access to Hubitat's source for that driver, but I thought that the ordinary Virtual Presence driver was only a presence sensor. It would therefore have two capabilities: "Presence Sensor" and "Sensor".
Yet you're trying to exclude both...
Don't you end up with a zero, a nothing, and therefore the best way to exclude it is to not add it to Homebridge ?
