They are completely on par when it comes to attributes. Just ordered my fourth hub and in the middle of migrating things but I will try tomorrow to add a virtual valve to test it out... it should work just by looking at the code
Valve is not in v1.4
It is in next release. I'll look into a HotFix.
2 Likes
I will work on getting ST moved over to HubConnect
EDIT: complete
So I am still stuck understanding this... How does just changing the stub driver make the sending side know to send the new events over?
Ah wait... Are you using the eventsocket connection method, or the original subscription model between the hubs?
I can see how this may work if using the eventsocket method (as all events are coming over whether you ask them to or not), but I don't think just changing the stub driver would work at all in getting attributes over to the virtual device when using the subscription method...
HubConnect 1.4 HotFix 2 has been released!
This release fixes three critical issues that were reported in 1.4.1:
- Missing Valve device support (regression)
- Repetitive system errors generated in Hubitat logs during HubConnect http event processing when a virtual HubConnect device cannot be found on the remote system. (@chuck.schwer)
- Additional filtering to fix possible race condition when bi-directional HSM changes are enabled. This was caused by HSM generating duplicate events on calls to setLocationMode() causing events to bounce continuously between server and remote hubs.
Files Changed:
- Server Instance
- Remote Client (Hubitat & SmartThings)
As always, I employ a team of blind sloths to write my code so please report any issues that are encountered!
3 Likes
For those using the homebridge-hubitat-hubconnect plugin, there is a new corresponding version available that addresses a shortcoming with the valves, a small fix around turning fans on/off and a change in the interaction with HubConnect when sending commands to control a device. So, if you use homebridge and update to HubConnect 1.4 HotFix 2, don't forget to update your homebridge plugin too!
1 Like
@srwhite and @dan.t
you guys rock! I now have a neat little spigot icon on my homekit dashboard to control the garden drip irrigation.
1 Like
Dopey question time....
A couple of times (including today) I managed to screw up the communications between hubs and couldn't figure out any way to fix it other than deleting the connection and re-making it.
When one does that, it orphans all of the stub devices that previously were communicating between the hubs.
Is there any way to KEEP the old stub devices and get communication going again after the connection is re-built?
It is a HUGE pain to have to delete the old stub devices, re-add them to HubConnect (thus getting the stub devices rebuilt automatically), and then manually rebuild every RM the devices were in (which is quite a few in my install).
Can you elaborate on how you screwed up the communications? It might be fixing that is 'more correct' -- dunno at this stage. 
Second issue... I have a dimmer device type going from hub 1 to hub 2.
- Changes made on hub 1 show up on hub 2 as expected.
- Changes made on hub 2 (the stub driver device) do not get made on the physical device. I see an event on the hub 1 that says:
app:10022019-05-28 05:51:10.694 pm infoReceived command from server: ["Music Room Smart Vent": setLevel]
But the level most certainly did not change....
SWITCH on/off events do make it from Hub 2 back to Hub 1, but dimmer setLevel do not.
EDIT: It may be because this is really a vent, and not a bulb... The stub driver forces duration=1, and I'm not sure the smart vent driver has a function for level + duration... Not sure, since it is using an in-box driver.
EDIT 2: Yes, that is the issue. Even on the physical device if I do level + duration it does nothing/rejects it. I guess I'll have to make a custom stub driver.
EDIT 3: Side note, WHY does the dimmer stub driver for duration to 1, anyway? Why not just pass through the duration specified?
ok... I was unable to duplicate it with a real dimmer:
on the Server:
app:3 2019-05-28 03:56:48.854 pm info Received event from ZeeRadioUpper/Multisensor6H (masterBath sink): [temperature, 74.7 °F] app:33 2019-05-28 03:56:47.443 pm debug Sending event to ZeeHomebridge: MasterBath WallDimmer [switch: on null] app:33 2019-05-28 03:56:47.333 pm debug Sending event to ZeeHomebridge: MasterBath WallDimmer [level: 22 %] app:3 2019-05-28 03:56:47.332 pm info Received event from ZeeRadioUpper/MasterBath WallDimmer: [switch, on null] app:3 2019-05-28 03:56:47.296 pm info Received event from ZeeRadioUpper/MasterBath WallDimmer: [level, 22 %] app:33 2019-05-28 03:56:46.373 pm debug Sending event to ZeeHomebridge: MasterBath WallDimmer [level: 22 %] app:33 2019-05-28 03:56:46.343 pm debug Sending event to ZeeHomebridge: MasterBath WallDimmer [switch: on null] app:3 2019-05-28 03:56:46.294 pm info Received event from ZeeRadioUpper/MasterBath WallDimmer: [level, 22 %] app:33 2019-05-28 03:56:46.246 pm debug Sending event to ZeeHomebridge: MasterBath WallDimmer [level: 22 %] app:3 2019-05-28 03:56:46.238 pm info Received event from ZeeRadioUpper/MasterBath WallDimmer: [switch, on null] app:33 2019-05-28 03:56:46.143 pm debug Sending event to ZeeHomebridge: MasterBath WallDimmer [switch: on null] app:3 2019-05-28 03:56:46.129 pm info Received event from ZeeRadioUpper/MasterBath WallDimmer: [level, 22 %]
On the Remote, where the real physical dimmer is:
`
app:837 2019-05-28 03:56:45.883 pm info Received command from server: ["MasterBath WallDimmer": setLevel]
`
See above, it is because it is a vent and will not accept a duration value.
OK. I think 2 changes should be made in the dimmer driver:
def setLevel(value, duration=1)
{
// The server will update status
parent.sendDeviceEvent(device.deviceNetworkId, "setLevel", [value, duration])
}
Should be:
def setLevel(value, duration)
{
// The server will update status
parent.sendDeviceEvent(device.deviceNetworkId, "setLevel", [value, duration])
}
And then add a second function:
def setLevel(value)
{
// The server will update status
parent.sendDeviceEvent(device.deviceNetworkId, "setLevel", [value])
}
That makes it the same as most physical dimmer drivers. They pretty much always have both a [value] and [value, duration] setLevel function.
On the to-do list for HC 1.5 is a "disconnect" feature to clear out all connection strings so the connection can be completely reset.
I think that's reasonable but I'll need to see if that will have any unintended consequences for other devices. Some of the drivers I studied at did have a default value set, which is why it was written this way.
@srwhite: The System Version Report shows incorrect latest versions after updating to 1.4 Hotfix 2 (see bold text below).
| Component | Type | Platform | Installed | Latest |
|---|---|---|---|---|
| HubConnect Server for Hubitat | app | Hubitat | 1.4.0 | 1.4.0 |
| HubConnect Server Instance | app | Hubitat | 1.4.2 | 1.4.1 |
| HubConnect Remote Hub | driver | Hubitat | 1.4.0 | 1.4.0 |
| Component | Type | Platform | Installed | Latest |
|---|---|---|---|---|
| HubConnect Remote Client | app | SmartThings | 1.4.2 | 1.4.0 |
| HubConnect Dimmer | driver | SmartThings | 1.3.0 | 1.3.0 |
No worries. I made a new dimmer driver on my end with those changes already, so I'm OK either way.
Also, I must say that when using the eventsocket connection method, 'user drivers' are much easier to do... Really you only need the stub driver with the needed functions in it, and then the rest just magically works after adding the device to HubConnect on the sending side (and then manually changing the receive side driver to the custom stub driver, of course).
Quite a bit different than the subscription connection model where you have to define things on both sides. I wish I would have tried eventsocket connections a lot sooner!
I am still having trouble with a water valve showing up in ST. Have the driver installed on ST and have the latest code on both HE and ST.
Don't know what "Missing Valve device support (regression)" means though.
It is a WaterCop water valve.
So much better than what he calls me in PMs. 
2 Likes
Programmerese for "mistakenly, it got removed and now has been put back."
You have WaterCop on HE and you're looking for it to appear on ST? What's the driver in use for the 'real device' on HE?
