This is a fantastic app. I'm so glad it was pointed out to me when I was seeking a solution for being able to use some of my dimmers/lights with my 2 Harmony remotes' home control buttons. I use the app to push 4 sets of lights/dimmers to ST, which I still use for it's native Harmony Hub integration.
My ST hub sees the lights/dimmers from HE and I configured the Harmony Hub ST integration to use those lights. Doing so allowed me to set the home control buttons on my Elite and Companion remotes to control those lights/dimmers. One press turns on the lights. A press and hold turns them off. And, the best part, is that the up/down toggle button controls the dimming.
Hey all... There will be a couple new things in 1.3 which I was saving for 1.4...
First, Custom Drivers will support up to 18 attributes since @JasonJoel asked nicely.
Second, I'm introducing a version report that I was going to save for the next release. It's going to be a useful tool for upgrading so I've decided to release it early as a "beta" feature.
I was hoping this feature app was discontinued. when I woke up this morning...... because it wasn't it cost me the price of 2 more hubs I ordered this morning
Bi-Directional Mode Support. Remote hubs can now send mode changes to the server, which then pushes them out to all remote hubs. This behavior is configurable on a per-hub basis. Hub Tools. From the server hub web UI, reboot and shutdown Hubitat hubs that are located on the same LAN.
HomeBridge Support! HomeBridge (HomeKit) users can now connect directly to HubConnect without installing any additional apps simply by using the excellent Remote Client created by @dan.t.
Mode Report. A single view that queries all hubs and displays the available system modes and whether which direction that mode changes can flow.
Custom Driver Enhancement. Custom drivers can now have up to 18 attributes!
BETA: System Version Report. Queries all hubs for all app and driver versions to made updating easier. This is in preparation for update notification that will be coming soon.
Anyone who wants to play with this Homebridge plugin, here are the instructions.
On your coordinator, go to the HubConnect Server App and add a new Hub.
and restart Homebridge. Once restarted, you can go back into your Homebridge Hub Instance on Hubitat and select the devices you want to have available under "Connect local devices to Client Hub"
You still need to restart your Homebridge server once after you selected the devices that you want to have available or make any changes to that selection in the future.
The "old" Homebridge App for Hubitat is not required anymore with this setup
And last but not least, I want to make sure that I thank @tonesto7 for the base work he had put into the original Homebridge integration, I just merely adjusted what he had created.
Not a huge deal, but SYNC doesn't really seem to do anything anymore on the drivers. Before it would fetch all of the attributes right away, on 1.3 I click it and nothing populates, and no entries in the logs on either side.
For the sync code, though, it is the same as the stock thermostat driver:
def sync()
{
// The server will respond with updated status and details
parent.syncDevice(device.deviceNetworkId, "thermostat")
sendEvent([name: "version", value: "v${driverVersion.major}.${driverVersion.minor}.${driverVersion.build}"])
}
I'll go delete the devices and re-add them and see if it does something different.
EDIT: No change. I confirmed SYNC does work on stock drivers, but it does not seem to work on my user driver.
Any plans for adding a universal driver for fans sometime soon? I can share my fans (Hampton Bay Zigbee) but only as on/off switches. It would be nice to have Off, Auto, Low, Medium, Medium High and High or temporarily have them share as a dimmer.
Now that I can connect to Homebridge I'd love to use that feature but I can't until fans are an option.
Just comitted an update that should fix that. Stupid typo on my part that broke it. Also made a small tweak to the selector too. Give it a try when you get a chance.
I don't see why not. I'm trying to cover as many of the popular device types as possible.
Updated earlier today and all working well for me on 1.3--thanks!
Still getting the groovy.lang.MissingMethodException: No signature of method: zenZigbeeThermostat.fahrenheitToCelsius() is applicable for argument types: (java.lang.String) values: [55.0] (setHeatingSetpoint) error on my real thermostat (which lives on my remote hub) when I change it from SmartThings (remote) > coordinator (server) > "real" thermostat hub (remote). I think HubConnect is maybe trying to pass the "real" thermostat a string value for what should really be a float, but it could just be something weird with my thermostat (a Zen, which shouldn't support non-integer values for °F anyway but reports and takes them sometimes anyway). As before, this only happens if all three of the above passes are made, since modifyng the HubConnet thermostat on the "middle"/server hub does successfully manipulate the "real" thermostat on the "remote" HE hub where the real thermostat lives (just when I add ST to the beginning of this chain as a different remote hub).
I've discovered I can work around it by modifying the Remote Client source on the hub where the real thermostat lives to do a string-to-float conversion in remoteDeviceCommand when params.deviceCommand == "setHeatingSetpoint" || params.deviceCommand == "setCoolingSetpoint", which I'm sure is a terrible way for me to do it, but it does work. While doing this, I also noticed that once in a while it actually did get an integer instead of a string/float, and thus my attempted conversion to a float from string failed, but the Remote app successfully manipulated the real thermostat (which lived on that hub) anyway since that part wasn't necessary.
I suppose my float vs. int hypothesis could be tested by a virtual thermostat in centigrade mode where non-integer setpoints are (I assume) allowed. (Unless all the other thermostat drivers besides the Zen automatically do conversion from string when "needed.") Maybe tomorrow.
This is awesome! thanks @srwhite and @dan.t for your hard work.
I now have all my sensors in homebridge and native per room dashboard on my ios devices. I will say, that was a huge pain in the butt importing and manually specifying the room for all those. It would be nice to be able to specify the room in homebridge or somewhere more efficient.
also, I’ve noticed some odd behavior when setting color/color temperature from homekit. It seems to drift from the color selected. Watching the logs, it will set the correct hue/saturation, then immediately change them. Pressing multiple time eventually gets it to set correctly.
I updated the 3 apps, removed the device sync/deleted the device, and re-added it. Still nothing happens when clicking sync. Nothing in either side's log either.
HubConnect is only passing values and not doing any string to int conversion. I sampled several SmartThings thermostat drivers and all of the ones I looked at perform the string to big decimal conversion prior to performing any actions within the driver itself. It appears that driver is not doing that.
Here’s an example from one of the public drivers in Samsungs repo..
// Get stored temperature from currentState in current local scale
def getTempInLocalScale(state) {
def temp = device.currentState(state)
if (temp && temp.value && temp.unit) {
return getTempInLocalScale(temp.value.toBigDecimal(), temp.unit)
}
return 0
}
I suggest seeing if you can modify the driver being used to make sure the conversion gets put into the proper place first. I’ll definitely see if there is anything I can do to fix this without having to modify the remote client.
