Won't that typically come from the thermostat with the report that it's started cooling or heating?
Yes.
- If mode=heat, then thermostatSetpoint=heatingSetpoint
- If mode=cool, then thermostatSetpoint=coolingSetpoint
- If mode=auto, then thermostatSetpoint=setpoint of the last mode the thermostat reported was running, or the heatingSetpoint if the last running mode is unknown (as heatingSetpoint is safer - things can freeze, but houses don't get hot enough to boil.
).
1 Like
Sometimes it feels slow going but this stuff is really starting to make sense.
Right, there's no separate setpoints for Heat/Cool mode (what Hubitat calls "auto"). It uses the same setpoints as Heat mode and Cool mode. If you select Heat, Cool, and Heat/Cool modes as the available modes, you should get preferences to set a heating setpoint attribute and command and a cooling setpoint attribute and command.
What Google calls Auto mode is totally different, and something that Hubitat doesn't really do. It's intended as a learning/AI type of mode.
Oh...okay. So, there is no Google Equivalent to what Hubitat (and every thermostat I've ever seen) calls auto mode?
But google home can show thermostats in "hubtiat style" auto... And they do...
Yes, what Hubitat calls "auto" mode Google calls "Heat/Cool" mode. That mode shares its setpoints with Heat and Cool mode.
When I set up heat/cool in the app, the only selections for mode I get in Google Home are heat, Cool and Off.
that's the part I'm not seeing in the Google Home UI. Did something you just "fixed" break it maybe?
The settings are:
Heat Mode:
- Heating Setpoint Command
- Heating Setpoint Attribute
Cool Mode
- Cooling Setpoint Command
- Cooling Setpoint Attribute
Heat/Cool Mode
- Heating Setpoint Command
- Heating Setpoint Attribute
- Cooling Setpoint Command
- Cooling Setpoint Attribute
Heat/Cool mode shares its configuration with Heat mode and Cool mode
1 Like
Yes...I understand that. But if i have Off, Heat, Cool and Heat/Cool selected in the app, shouldn't i have 4 modes in Google Home?
Correction, I SHOULD have 4 modes in Google Home.
Also, you know the supported modes can be queried from the device, correct? That's how other hubitat apps like Rule Machine populate the drop-downs for modifying thermostat settings. Every thermostat should publish "supportedThermostatModes" as an attribute.
Oh, it's missing in Google Home, sorry, I'm apparently dense. Yes, you should see all four listed in the Google Home app. For instance, here's what I see when I set up my Ecobee thermostat:
If you're missing some, can you send me the for your thermostat from the Sync response? In the log, it should look something like this:
[id:24, type:action.devices.types.THERMOSTAT, traits:[action.devices.traits.TemperatureSetting], name:[defaultNames:[Ecobee Thermostat], name:Downstairs Hall], willReportState:false, attributes:[thermostatTemperatureUnit:F, queryOnlyTemperatureSetting:false, availableThermostatModes:[off, heat, cool, heatcool]]]
Note that you do still have to select Heat/Cool from the Supported Modes drop-down. Selecting Heat and Cool does not automatically give you Heat/Cool.
I was aware of the supportedThermostatModes attribute, but I'm trying to keep this app very generic. The Temperature Setting trait should support any device; not necessarily just ones that properly implement Hubitat's Thermostat capability. Maybe that's going a bit overboard in this case, but it follows the pattern of the other traits (for instance, On/Off doesn't depend on the Switch capability).
I may, at some point, implement an "auto-discover traits" type setting that guesses traits based on a devices's declared capabilities, but I'm focusing on getting as many devices as possible supported before doing anything like that.
AH HA! I get this error when I enter a value for the spread between the setpoints. When I remove it, it works perfectly. 
@Ryan780 I just fixed that issue with the heat/cool buffer as well as removing the settings for the "off" mode setpoint since, as you pointed out, they don't really make much sense.
Apparently Hubitat is content to just accept an invalid input type and treat it as a String. Fixing that highlighted another flaw in my logic as well. The heat/cool buffer is a number of degrees, not a temperature, so fahrenheitToCelsius doesn't convert it correctly. Fixed that as well.
Does anyone here have any experience writing virtual device drivers? I searched and searched but couldn't find much info. I wish the Hubitat Virtual Fan controller driver had on/off switching included also. Or maybe a virtual heater or any device really with some assignable toggles. That would be cool to mess around with too.
I like the idea of having one device showing in Google home with multiple controls. For example my Range hood, I currently have the the light and the exhaust fan as separate devices in the kitchen. If we had a virtual Range hood driver both could be controlled in one device. Actually a Virtual fan controller would work for this as well if it just had the separate on/off trait.
Any thoughts?
Virtual drivers are fairly simple to write. The only thing that you have to implement are the commands and the associated events for the capability. I had written this virtual fan driver before the built-in one was available.
/*
* Virtual Fan Advanced
*
*
*
*/
metadata {
definition(name: "Virtual Fan Advanced", namespace: "Ryan780", author: "Ryan780") {
capability "Actuator"
capability "Fan Control"
command "cycleSpeed"
}
}
preferences {
section() {
input name: "logEnable", type: "bool", title: "Enable debug logging", defaultValue: true
}
}
def logsOff() {
log.warn "debug logging disabled..."
device.updateSetting("logEnable", [value: "false", type: "bool"])
}
def updated() {
log.info "updated..."
log.warn "debug logging is: ${logEnable == true}"
if (logEnable) runIn(1800, logsOff)
}
def parse(String description) {
if (logEnable) log.debug(description)
}
def setSpeed(value) {
if (logEnable) log.debug "Fan speed set to " + value
sendEvent(name: "speed", value:value, isStateChange: true)
}
def cycleSpeed(){
if(device.currentValue("speed")=="off"){
sendEvent(name: "speed", value:"low", isStateChange: true)
}
else if(device.currentValue("speed")=="low"){
sendEvent(name: "speed", value:"medium-low", isStateChange: true)
}
else if(device.currentValue("speed")=="medium-low"){
sendEvent(name: "speed", value:"medium", isStateChange: true)
}
else if(device.currentValue("speed")=="medium"){
sendEvent(name: "speed", value:"high", isStateChange: true)
}
else if(device.currentValue("speed")=="high"){
sendEvent(name: "speed", value:"off", isStateChange: true)
}
}
As far as integrating the two devices into one, theat can be done, but if the device isn't actually communicating with anything, if it is totally virtual, then it really doesn't buy you anything to have both devices in one virtual device. You won't ever control them together since hey have separate attributes. But it would be very easy to add the switch capability to this driver. If it's going to control a light, you might also want to add the light capability as well.
2 Likes
Thanks for providing this!! I have no experience but I will see what I can do.
With on/off switch capability and possibly brightness and/or color I should be able to do what I want to do.
I have an electric fireplace in our bedroom that I control with a blaster from my harmony hub, and monitor power with an iris plug. I can turn it on/off,change the heat between off, high, and low. and i can also cycle the flame color. I control all of the functions with a pico now. But I can only turn it on /off with google. This should fix that
A dynamic device isn't going to import correctly until you assign the correct attributes in this app. You should be able to do exactly what you have said with your existing devices. I'm not sure why you need another virtual device. If anything, you'd need another device in your Harmony integration. If you can do it today from Hubitat, I'm almost certain you could find a way to integrate with Google home without additional virtual devices.
You can add as many traits as you want, but if the device doesn't support them then it doesn't really work....Right now the electric fireplace is just a virtual switch...I would of course have to write rules to make the virtual fan device function. But If i had the capabilities of the hampton bay fan controller for example, I could turn it off/on tell it to set fireplace to Low,High, auto (could be no heat) if i change the brightness or color that could trigger the color change. Make sense?
No, not really. You have to implement a way to control the actual device. That's the part that I'm not understanding. You can't just use a virtual device. A virtual device is just that....virtual. How are you going to get your real device to do the things you are proposing?
If you already have a device that does the fan speed, then just implement that device in Google Home. Setting the device up in Google home will not get control over a real-world device unless that real-world device is already connected to Hubitat.
I would write rules in rule machine to make the virtual device work. A more simple example would be the stove hood. The light controls would correspond the a sengled bulb and the fan controls would correspond with a zigbee on/off relay.
