(Partially Solved) Google Home & Virtual Device's Brightness/Color

Platform information:

  • Hardware: DiskStation 1511+
  • OS: 6.2.2
  • Java Runtime Environment: Java SE Development Kit 8u212
  • openHAB version: 2.4.0


I’m finally able to do a few things, thanks to this great community! I’ve unfortunately encountered my next problem(s). I’m trying to control a virtual device through Google Home:

Color Virtual “Test” [“Lighting”]

It shows up in Google Home and I can control it. I’ve set up a rule which is triggered when the item is changed.

rule “Virtual”
Item Virtual changed
logInfo(“Virtual”, Virtual.state.toString)

That all works, but I’m getting some weird behavior when I control it from my phone. There’s an on/off button, a brightness bar and a color picker. The logInfo in the code above allows me to see what is going on through the logs.

So if I turn on the light and set it to a certain brightness, I’ll see something like:
27 is the brightness.

If I press the off button I then get:

If I press on the brightness bar to turn it on (I figured pressing the on button always gives me 100) I get:
And then a subsequent call coming from god knows where is giving me a few instants later:

In this last step, I would like it to stay at 27, the display on my phone actually shows the brightness still at 27. Eventually there’s some auto-update which moves the brightness indicator to full 100.

Also, the on/off/brightness buttons will lock up in Google Home from time to time, I don’t understand what’s going on there. And last the color picker does not work at all, I can control the color through my voice but selecting it manually does no trigger the changed event.

Any information is greatly appreciated.


openHAB Item states are quite different from commands.
A Color type Item only ever has a HSB state, regardless of the command sent. You’ll understand that for e.g. command ON.

So for experiments it may help to have the partner rule

rule “Virtual comm”
   Item Virtual received command
   logInfo(“Virtual”, "command " + receivedCommand.toString)

although in truth all that can already be seen in events.log

Well, that’s debatable. “Turning on” a dimmer - you might expect 100% brightness, but someone else might expect the last brightness to resume. Both are valid.

I wonder what you would see at your app if the app assumes ‘resume’ and the remote system assumes ‘full on’.

Okay, let’s do autoupdate.
As we said, commands and states are different.
Sending a command to an ideal OH Item would get sent out via a binding to a device. Some time later, the device would respond with a new status, the binding would update Item state to suit.

That breaks down with devices that don’t respond in good time, or ever. Also with Items like yours not associated with real devices. Even when it works, the user experience can be rubbish due to delayed responses.

So openHAB has an autoupdate feature - it acts like a psuedo binding, listening for commands, predicting/guessing the likely outcome, and issuing its own update to Item state.
That’s how your virtual Item changes state at all. See events.log again for its predictions.

Hope that helps understanding the workflow.

Thanks for the reply! Trying it out as I write this reply.

So I added the rule, it follows exactly the changed event. It does say “command ON” when I press the brightness bar to 50% for example. Looks like it’s not issuing set to 50% commands.

The UI in Google Home seems to support both, I would love to be able to support both. Press the power button to get full ON/OFF and press the brightness bar to get “RESUME”/OFF. It seems to want to do the latter, I just need to figure out where the 100% brightness command is coming from.

Is this what you had in mind?

Color Virtual “Test” [“Lighting”] {autoupdate=“true”}

So far everything seems to act the same.

I’m a little more wary of this now. In Google Home, just below the item label is the connection state, usually says “Linked to you” but recently I’ve noticed it often switches to something about not being connected (I can’t replicate it as I’m writing this for some reason, even with or without autoupdate).

I have seen the predictions in the logs in the past, not so much anymore even when playing with autoupdate. For now I can’t see the difference between autoupdate true or false or not set. I’m not sure if you were alluding to the system predicting 100% and thus issuing the 100% command but I see it every time I set brightness to a level from OFF and I don’t see the prediction message in the log, so I’m gonna guess it’s not coming from a prediction.

I read in another thread someone was having a similar issue with brightness/On/Off and they were suggesting the only way of achieving this without the buggyness is to separate it into 2 virtual channels (One Color, one Switch), but I honestly don’t see how that’s going to help me much. I’m still going to get a power button on the Color side with all the troubles.

Any ideas about the color picker?


No, it was offering an explanation of the feature. It is enabled (“true”) by default for each Item.

You’ve misunderstood OH commands, Item states, and autoupdate. Autoupdate never ever issues commands. It may make state changes. The distinctions are important. “Do this” instructions, “It’s like this” status.

I know nothing about Google Home. Whatever commands it may issue that successfully arrive at openHAB, you will see in the events.log
If you are puzzling over what is going on, you might show us the relevant snippet.

Nope. This is something in the Google Home UI?

So I didn’t quite know where to go from here, so I simply kept tinkering. I realized I didn’t really need the virtual device, I simply used the real LED light I wanted to control through that. It’s still a little buggy but I can live with it.

Anyone else has an idea about the issues with the Google Home color picker?


I’ve been working quite a bit on this project lately, this issue completely disappeared at some point, I can’t say for certain what partially solved the issue but I think it had to do with the fact that I was missing the stateTopic in my MQTT channel definition. Google Home still doesn’t always reflect the current state properly but at least I can control the color using the color picker which was the biggest annoyance of all of this.

I’ll report back here if I ever find a complete solution.