Sorry you had such a rough time. I know the setup process is pretty painful. If you're willing to give it one more go, could you switch on debug logging in the Hubitat app before you link and send me the log that's generated during the process? That could shed some light on what's going wrong and hopefully help me improve the process so others don't have such a bad time.
I had debug logging on and I still have the logs from this morning. I'll PM them to you, since they are QUITE long and I'm not sure what in them is "safe" and what isn't.
1 Like
i have both installed and working fine, they don't have the same devices exposed though.
That gives me much more hope. If I can try the community integration while keeping the native one it's lot less painful if the new one doesn't work right. Cause as it stood, i didn't have any voice control and then had to set up every single room again. That's a PITA. Next time I'll try adding this next to the native app and see how it works.
I also removed the native integration thinking that was the cause of my problems getting it to link at all, since there was a note about that. Now that I know that didn't fix it...
1 Like
Whoops, sorry. I though I had removed that note. I initially added that because I thought the two were causing problems with each other, but that turned out not to be the case.
1 Like
I will let John Stewart speak for me.....
1 Like
I moved 70 devices to this app today, working great!
I did make one change in the code, sorted the Device Selection screen to be alphabetical, my OCD was kicking in big time! lol
Changed Line 87:
def allDeviceTypes = deviceTypes()
to:
def allDeviceTypes1 = deviceTypes()
def allDeviceTypes = allDeviceTypes1.sort() { a, b -> a.display <=> b.display }
Looks much better!
2 Likes
I had some free time, so I went ahead and implemented the LockUnlock trait. I don't actually have any smart locks myself, so I've only tested the trait with the Virtual Lock driver.
Note that there are no UI controls for locks or the LockUnlock trait in the Google Home app, but touch controls should be available on standalone Google Home/Nest devices with screens.
2 Likes
This is AWESOME. Thanks for all of your work on this!
New Trait: Color Setting
I just added the Color Setting trait. This trait is primarily for smart lights that are capable of having their color set. It supports both full-spectrum HSV color and color temperature control.
Again, I don't actually have any color-capable lights, so I've only tested this with the Virtual RGBW Light driver. Let me know if there are any issues with it.
1 Like
You are awesome! As suggested I had started to get my head around the code and the google docs linked above. Didn't get to far but very impressed with your code.
Thank you.
I tried lock/unlock trait last night, and it works great!
I added my door lock, set "require pin for unlock", and tested via voice command. As expected, requesting to unlock, and my hub requested a PIN.
As an FYI, taping the lock in the Home App, or on hub, does not do much, just kind of spins. Also, the icon does not change for locked and unlocked; but asking "is the front door locked?", and Google responds the correct state.
Thank you again for the great work!
P.S. are temperature and humidity traits on the horizon?
Temperature is definitely on my list. I'll have to try some things to see if TemperatureControl or TemperatureSetting works better for temperature sensors.
I'll add humidity to my list. Should be pretty straightforward to implement.
Hmm... reading the traits document, both seem to be about controlling temperature (or humidity), but don't seem to cover sensors reporting those values. Unless I'm missing something in that document.
It does suggest that TemperatureControl is "Trait for devices (other than thermostats...".
I look forward to what you come up with.
Both have a queryOnly* attribute that can be used for sensors. For me it will mostly be up to which one will let me say something "Hey Google, what's the temperature in the kitchen?" and get either a report for all of my sensors or an average or something. From the documentation, TemperatureControl seems to be more about setting/measuring the temperature of the device itself, while TemperatureSetting seems to be more about ambient temperature. We'll see.
Update: Added support for ambient temperature sensors
I just pushed and update that adds support for standalone ambient temperature sensors using the "Query Only Temperature Setting" attribute of the Temperature Setting trait.
It's not perfect, but this allows you to set up ambient temperature sensors and query their temperature by asking the Google Assistant things like "What's the temperature of {device}?" or "What's the temperature in {room}?". When the Assistant responds it will say that the sensor is set to its current temperature reading. When you ask for the temperature of a room the assistant will respond with the temperature of each temperature sensor in the room individually.
For instance:
4 Likes
Got everything up and working again...much easier the second time around.
I also found that in order to turn the fan off you have to add the on/off trait to the fan also. If you select it as a fan type, it still shows up as a fan though.
I did have one question about the blinds though. It seems that we have access to open/close but does the Google Blinds trait allow for levels as well or do we have to keep it exposed as a light?
UPDATE: Never mind...added the brightness along with open/close and it works. Sorry.
You shouldn't need the Brightness trait for blinds. Open/Close allows you to set the position as a percent if you leave the "Discrete Only Open/Close" option unset. With that setup you can say "Hey Google, open the blinds" and it will open them to 100% or say "Hey Google, open the blinds 50%" to open them part way.
Brightness may give you more options though. For instance, my tilt blinds are fully open at 50%, so I have to keep "Discrete Only Open/Close" set in the Open/Close trait for "Hey Google, open the blinds" to work right. Adding the Brightness trait would also allow me to control the position as a percent. I hadn't even thought of doing that.
ALL blinds are open at 50%, that's the odd thing. I don't know why someone didn't think of that. Shades are open at 100%. Whatever engineer at google who coded this must not have ever had blinds before. lol Mine had a default setting for "on" and I tried to use the on/off trait also and that didn't work either.
I did at first but I removed it and it still seems to be working. Maybe I was too quick on the draw. 
To be fair, this is more a limitation of how I built the Hubitat app than how Google implemented it. Google just uses 0% to mean fully-closed and 100% to mean fully-open; it's up to the device integrator to translate that into the correct commands to send to their particular device. At some point I'll probably add options to the Hubitat app set the fully-open position and open direction. What's there is really just a first-pass "good enough" implementation.
Yeah, I actually have my blinds' Open/Close trait set up to use the on and off commands since a couple of the devices I exposed to Google Home are actually groups from the builtin groups and scenes app. This is how I have mine configured:
It works well-enough, but I rarely want to do anything other than fully-open or fully-close my blinds.
