Yes, you can run multiple instances of Homebridge.
Create a new directory (.homebridge2 perhaps?) and put a valid config.json in it.
Run homebridge using the -U to point to the new directory (not the file, the directory.)
to change ports, in config.json, add one line to it:
"direct_port": "8006",
inserted above the "app_url" line. Also, change the "name" line to have a unique name.
That will give you one instance running on the default hubitat port of 8005 and the new instance on 8006.
This will show up in the iOS Home App as two Homes.
I don't have shades as I mentioned. I did create a virtual window shade driver and and I can set them to "partially closed", even down to 1%, I agree that "close" isn't working.
"hey siri, set testshades to open" yields "done" and Position goes to 100%
"hey siri, set testshades to 60%" yields "ok, I set test shades to 60%" and position shows 60%
Thanks you for verifying this for me, it’s nice to know I am not crazy
I can recreate that log as well, however I have never been able to automate partially open shades using any platform HE or ST, but I do get the logs to show 60%
Ok, i’m running two instances of homebridge now (i spun up another docker instance). I changed the port to 8006, but I had to change the bridge port from 51827 (to 51828) in order for both of them to run simultaneously, otherwise it errored and wound’t start.
initially i was trying to just add it all in a single instance of homebridge and just have a repeat module in the config.json. this seemed to work, but after I changed the port to 8006, i was never able to get it to come up in the home app.
Along with "bridge" port to change, the "username" and "pin" need to be unique.
Then you have to start a new Home in the iOS app. Click the home icon (upper left) on the Home page of the Home App, then Add Home.
I did all of that and it works, but I hated having two homes when they were just the two floors of my house. The Third Hub solves that (but injects a different problem) by using Link to Hub from each Floor's Hub to the Third Hub. Homebridge runs there on the third hub and if there's some impact to the Hub by Homebridge, it's only affecting the third hub, not the pair of Hubs with radios.
Are you saying the UI shows a partial, but the shade itself doesn't move?
If I press/hold on the iOS Home app Tile for my testshade, I get the usual dimmer and I can slide that to any value. In my virtual window shade driver I receive multiple setPosition() calls.
Obviously the source to Generic z wave blinds isn't available to me and so I cannot say what the ZWave commands are being sent. I altered my virtual driver to special case setPosition() =0 or =100 and to convert them into close() and open().
NOW:
"hey siri, set testshades to closed" yields "done" and:
Current States
position : 0
switch : off
windowShade : closed
"hey siri, set testshades to open" yields "done" and:
Current States
position : 100
switch : on
windowShade : open
"hey siri, set testshades to 60%" yields "ok, I set test shades to 60%" and:
Current States
position : 60
switch : on
windowShade : partially open
Now my Virtual Window Shade driver performs perfectly IF all ya care about is the Current States
I think this is all I can contribute to this discussion about shades I don't have. It looks like the iOS Home app to Homebridge to Hubitat flow is 'correct.' However, that may be miles away from what Hubitat's Generic ZWave Shades driver is processing. If, for a crazy example, it processes presetPosition() and ignores setPosition(), your symptoms would match. SmartThings spec seems to suggest presetPosition() is the correct method.
So when I try to close the curtains from the home app this is my log:
2019-02-16 02:58:59.702 pm [error](http://192.168.7.201/device/edit/12)groovy.lang.GroovyRuntimeException: Ambiguous method overloading for method java.lang.Integer#minus. Cannot resolve which method to invoke for [null] due to overlapping prototypes between: [class java.lang.Character] [class java.lang.Number] (setPosition)
Yes, I ran into that error in my Virtual driver and solved it by treating 0 and null as "close."
try setting to 2%... Does it actually move ?
The Homebridge code has:
if (curPos > 98) {
curPos = 100;
} else if (curPos < 2) {
curPos = 0;
}
in other words: 2% is the smallest value before closed, 98% is the largest value before open.
I altered my instance of Homebridge to use 'presetPosition()' but Hubitat doesn't send that to the driver, so I think 'setPosition' is the correct method.
I got it working. I think the issue was changing the username so it comes up as a different serial number. I was able to add both homebridge instances (and thus, both hubs) to my single ios home. so now I don't have the limitations of hub link. now I just have a few devices on each hub that are connected and I get things like battery info on my locks (which did not seem to be passed via hub link).
Also, happily, even though my garage doors only come up in the sensor devices list in the homebridge app, homekit interprets it correctly, displays a garage door icon, and allows me to open and close the doors.
The limitation is Link to Hub. All it "delivers" over the link is a Contact Sensor. Homebridge has nothing else to choose from and thus it doesn't do more. (Sensors aren't setable.)
I've created a Virtual Garage Door hybrid that installs on the Hub that is running Homebridge and reveals itself to Homebridge as a switch + contact + garage door.
Homebridge says I've selected 43 devices and only the GarageDoor opener has needed this workaround.
I use Link to Hub on that Hub to send it back to the Hub with the actual Garage Door Opener and have a Rule there that tracks the switch and drives the garage door opener.
It's a hack, but until Hubitat figures out how to send "everything" over the Link to Hub connection, (it's a receiving end problem) I'm stuck with this hack. In the grand scheme of things this is pretty low 'pain' but we're pretty spoiled here in HubitatLand with near instant gratification.
I'm not using link to hub anymore. I've got two instances of homebridge running, each hub is connected to a different instance, and I added them separately to the same home on homekit. its all seamless on my ios devices.
the homebridge app on hubitat lists the garage door as only a sensor device. its using the generic z-wave garage door opener device driver.
everything actually works like a charm, no custom drivers, no virtual switches. it looks just like it should in homekit. it was just confusing as I had to choose it from the sensor list in the homebridge app. I suppose i'm just posting in case anyone else runs into the same issue.
and for sure, i've never been happier with a home automation solution than with hubitat. the developer community here is awesome.
Just remember that Homebridge is on the 'bad apps' list. By having zero non-built in apps on my hubs-with-radios, I don't expect to be reporting "my hub is slow" anymore. If I do, I expect to shortcut the "are you running any..." question
Running HE 2.0.5.114 platform and getting the "Connection refused" error again. Trying to refresh the client secret by checking the box in OAuth (this was the fix before as I recall), but it's the same each time. Does not update the client secret.
Anyone have any ideas why the client secret will not update?
[Edit]Just ignore me. I should read my own posts more carefully. I've been doing some testing for a new way of connecting to Insteon, and I must have grabbed an old config.json file at some point. I accidentally pasted the incompatible bit back in Removed it, and the connection error is now gone.
I have 2 HE hubs each with their own corresponding Ubuntu VM running homebridge. I'm now thinking of adding a 3rd hub, linking devices from the other 2, without radios just for homebridge.
I have exactly that config and the issue of what data gets transferred across the Link to Hub app remains. For me, it's not horrible because I am delighted in Hubitat's evolving. They are more than aware of the limits and have thought about what to do but are hampered by priority, as we are well aware. less than a dozen of us are using the hub in this way and I think we'd like Dashboard or the Mobile App or ... whatever our favorite improvement is. I'm satisfied with all of those so for ME, this is high priority in the wish department.
I have the Garage Door 'problem' but I worked around it by creating a Virtual Garage Door Hybrid driver. It's a switch and a contact (tilt) and a Garage Door Controller all in one. I added that as a virtual device on my Third hub and let Dashboar, Alexa/Echo and Homebridge know about it. Then, via Link to hub I sent that device to the hub that has the real garage door opener. A rule to 'convert' the switch state to Garage Door commands and I'm good to go.
SRWhite took a different road and built his own app, including drivers, etc. Hubitat will get there someday, I have little doubt, and then I can discard my crude solution. Probably with a smile.
I setup my 3rd hub tonight and it's what's doing the homebridge thing now. In your setup were you able to get "virtual motion", "virtual contact", "virtual omni", etc sensors to show up as available in your homebridge setup? If so, how? I've used "Link to hub" on my other 2 hubs to share all devices with hub #3 but only "Linked switch", "linked dimmer", etc are showing up in the homebridge setup.
Removed it, and the connection error is now gone.
