You're such a tease @srwhite 
I had hub link setup for a while but the atrribute/device type limitation made it incomplete and not worth the trouble for me. I think this would let me completely separate my custom/web based apps and drivers.
This sounds fantastic and I'll be reaching out to you and @csteele for advice when I'm ready setup my coordinator. Sooo glad you stuck around!
4 Likes
@srwhite
This is exactly what I was hoping the native link to hub app would do! I'll give it a try one it's released and report back how it's working for me.
How are you implementing the Ring Doorbell without Hubitat intergration? I have it setup on Smartthings right now with WebCoRE on ST to do a few things and using Alexa to turn on virtual switches with Hubitat.
1 Like
You can also do this natively in Alexa with the Ring skill. Alexa sees the doorbell as both a motion sensor and a button. I'm using 2 Alexa routines to flip a virtual switch in HE on motion and another one on doorbell press, but without having to go through the ST cloud to do it. 
4 Likes
That's exactly what I'm doing, I just have ST with WebCoRE to turn on lights for my other Ring devices.
Example:
If motion at front doorbell or front doorbell is pressed. turn on light at front garage (Ring Floodlight Camera).
I have it setup to turn off on that instance after 5 minutes. It's also setup to do that based on how much the illuminance level is outside as well, definitely can't be done that way with Alexa
Really nice at night if someone was outside my house.
3 Likes
I don't have a spotlight, but I do have a Floodlight and I can control it directly from HE using the details listed in this thread
2 Likes
I'll have to check that out when I get home.
2 Likes
This is true, however bridging through SmartThings is more flexible. It allows the Ring doorbell to be exposed as both a button AND motion sensor natively within Hubitat. I thought the Alexa integration virtualizes those as switches.
2 Likes
@srwhite Really looking forward to this .. thank you so much in advance for the time and effort to bring it to a release state.
1 Like
It does but can be easily remapped to motion with a custom driver or simply using on/off instead of active/inactive.
I originally used my ST hub to send events to HE but the delay was too much to be used with a lighting automation. The Alexa->HE virtual switches were MUCH faster and more consistent.
1 Like
In Alexa, it exposes the doorbell as a Camera type. For Routines, you have a choice of motion or button press.
But, I get what you are saying about native device types in HE based upon button and/or motion sensor and that makes perfect sense.
2 Likes
@srwhite Sounds pretty interesting. I'll be interested in seeing if a thermostat device type is doable within your architecture. I'm guessing that it might not since you need >8 variables for a thermostat device type.
Cool development, though!!!
1 Like
the 8 limit is for 'custom'. There's no limit for a built-in / native HubConnect driver.
To ALL NEW Readers of this topic...
This topic is 3300 posts long and covers items and issues that may be 2 years old and fixed. Skip Forward to maybe #2800
2 Likes
Bad assumption on my part then. And now that I look closer it seems the smoke/co has 10. Cool. Will look forward to taking a peek at this after released (and I'm back on the same continent as my hubs).
1 Like
I don't own a ZWave Thermostat. but using the Virtual Thermostat as a guide, I found only these 7 attributes:
"temperature", "thermostatFanMode", "thermostatMode", "thermostatOperatingState", "thermostatSetpoint", "coolingSetpoint", "heatingSetpoint"
My 'real' Honeywell WiFi Thermostat also shows the same attributes.
What are the additional >3 you see?
You are right on the properties (although I have at least 1 more than you listed - I miscounted the 1st time). If you include commands (again, I haven't seen the actual app so I don't know what is possible), there are more....
Commands (12):
AUTO, COOL, EM HEAT, FAN AUTO, FAN CIRC, FAN ON, HEAT, OFF, Cooling SP, Heating SP, Fan Mode (enum), Thermostat Mode (enum)
Properties (8):
coolingSetpoint, currentSensorCal (that is specific to my thermostat drivers), heatingSetpoint, temperature, thermostatFanMode, thermostatFanState, thermostatMode, thermostatOperatingState
1 Like
A Virtual Thermostat shows:
Current States
coolingSetpoint : 75.0
heatingSetpoint : 68.0
supportedThermostatFanModes : [auto, circulate, on]
supportedThermostatModes : [auto, cool, emergency heat, heat, off]
temperature : 68.0
thermostatFanMode : auto
thermostatMode : off
thermostatOperatingState : idle
thermostatSetpoint : 68.0
And when I pass that over HubConnect, I get:
Current States
coolingSetpoint : 75.0
heatingSetpoint : 68.0
temperature : 68.0
thermostatFanMode : auto
thermostatMode : off
thermostatOperatingState : idle
thermostatSetpoint : 68.0
1 Like
Yup, those are the 7 states I have. And I have one more custom to my thermostat drivers. So 8 total properties for me.
I miscounted the 1st time, thus my comment on >8.
No point in my speculating any further at this time I guess. I'll see what it can all do when it gets released. Looking forward to it.
1 Like
Do you use currentSensorCal in an automation or Dashboard? If not, then it's absence won't matter 
1 Like
Looks really great, @srwhite ! I'm looking forward to the simplification of my ST<->HE integration. I don't see any mention of modes. Will HubConnect sync HE and ST modes?
1 Like
