openHAB Google Assistant Integration v2.0

Funny you should mention that…

I’m trying to get the Velbus thermostat working with Google metadata

Current Temperature is okay

But Target Temperature only works when I don’t try to get the Mode mapped.

I can change the mode with the Google assistant, but the commands always get sent to the Item as the Google options, rather than the mapping I’m trying to do

This is what I am trying

// New Google Assistant Metadata tagging (I'm still experimenting with)

		Group MiddleBedroomGP2_Thermostat	"Middle Bedroom"																																				{ ga="Thermostat" [roomHint="Middle Bedroom"], alexa="Endpoint.Thermostat" }
		Number MiddleBedroomGP2_CurrentTemperature 			"Middle Bedroom Current Temperature" 			( MiddleBedroomGP2_Thermostat ,WholeHouse_CurrentTemperature		)							{ channel="velbus:vmbgp2:VelbusNetworkBridge:17:input#CH9", 								ga="thermostatTemperatureAmbient" ,		 alexa="TemperatureSensor.temperature" }
		Number MiddleBedroomGP2_CurrentTargetTemperature 	"Middle Bedroom Current Target Temperature"		( MiddleBedroomGP2_Thermostat ,WholeHouse_CurrentTargetTemperature	)							{ channel="velbus:vmbgp2:VelbusNetworkBridge:17:thermostat#CURRENTTEMPERATURESETPOINT",		ga="thermostatTemperatureSetpoint",		 alexa="ThermostatController.targetSetpoint"}
		String MiddleBedroomGP2_ThermostatMode 				"Middle Bedroom Thermostat mode"	  	 		( MiddleBedroomGP2_Thermostat	)																{ channel="velbus:vmbgp2:VelbusNetworkBridge:17:thermostat#MODE", 							ga="thermostatMode" [ modes="off=SAFE,eco=NIGHT,on=DAY,heat=COMFORT" , lang="en" , ordered=true ] ,					 alexa="ModeController.mode" [friendlyNames="@Setting.Preset", supportedModes="SAFE=Safe,NIGHT=Night,DAY=Day,COMFORT=Comfort"]}
		String MiddleBedroomGP2_ThermostatOperatingMode 	"Middle Bedroom Thermostat operating mode"		( MiddleBedroomGP2_Thermostat )																	{ channel="velbus:vmbgp2:VelbusNetworkBridge:17:thermostat#OPERATINGMODE"	,														alexa="ThermostatController.thermostatMode" [COOL="COOLING",HEAT="HEATING"]	}

And this is what I’m seeing in the Events.log when I try to set a mode in Google

2020-03-26 14:41:23.265 [nt.ItemStatePredictedEvent] - MiddleBedroomGP2_ThermostatMode predicted to become heat // This should have been mapped to COMFORT
2020-03-26 14:41:23.273 [vent.ItemStateChangedEvent] - MiddleBedroomGP2_ThermostatMode changed from SAFE to heat
2020-03-26 14:41:24.344 [vent.ItemStateChangedEvent] - MiddleBedroomGP2_ThermostatMode changed from heat to SAFE // This is the Velbus binding rejecting the "heat" command and defaulting to SAFE
2020-03-26 14:42:03.334 [ome.event.ItemCommandEvent] - Item 'MiddleBedroomGP2_ThermostatMode' received command heat // This should have been mapped to COMFORT
2020-03-26 14:42:03.360 [nt.ItemStatePredictedEvent] - MiddleBedroomGP2_ThermostatMode predicted to become heat
2020-03-26 14:42:03.373 [vent.ItemStateChangedEvent] - MiddleBedroomGP2_ThermostatMode changed from SAFE to heat
2020-03-26 14:42:05.402 [vent.ItemStateChangedEvent] - MiddleBedroomGP2_ThermostatMode changed from heat to SAFE// This is the Velbus binding rejecting the "heat" command and defaulting to SAFE
2020-03-26 14:42:39.097 [ome.event.ItemCommandEvent] - Item 'MiddleBedroomGP2_ThermostatMode' received command off
2020-03-26 14:42:39.114 [nt.ItemStatePredictedEvent] - MiddleBedroomGP2_ThermostatMode predicted to become off // This should have been mapped to SAFE
2020-03-26 14:42:39.121 [vent.ItemStateChangedEvent] - MiddleBedroomGP2_ThermostatMode changed from SAFE to off
2020-03-26 14:42:40.420 [vent.ItemStateChangedEvent] - MiddleBedroomGP2_ThermostatMode changed from off to SAFE // This is the Velbus binding rejecting the "off" command and defaulting to SAFE

@michikrug @MARZIMA
Can either of your gentlemen provide any clarification on if this is even possible or what the correct syntax should be?

I’ve tried to follow these instruction to the letter

Should the mode mapping be places in the Themostat group Item as suggested?
Or with the Thermostat Mode String item?
(I’ve tried both, with the mapping in various forms)

We / I am so close to having a complete solution that it’s getting really frustrating…

What’s really curious is that openHAB2 is obviously sharing the current mode with Google, because shortly after sending the mode command to openHAB2, Google rolls back to “Other” mode

Can you change the Thermostat Mode from a sitemap? (I havn´t tried myself).

I have not the first clue about sitemaps…

From HabPanel, NodeRed, PaperUI — YES :smile:
So I assume that it’s possible from a sitemap

Just sitting here looking at the Velbus binding docs… It really lacks info :frowning:
I have no clue about Habpanel or NodeRed, so I´ll need to have the modes for making at sitemap mapping…

But. If you can set the mode from habpanel, I really dont understand why it shouldnt work with GA. According to your log, it does work, but for some reason the Velbus panel don´t accept the command. Normally I would say, it shouldnt work from habpanel/sitemap/NodeRed either, as it´s the exact same.

Will give it a few shots from here (using sitemap). Just need to know the modes the glaspanels accept.



The Velbus Thermostat Mode accepts - SAFE,NIGHT,DAY,COMFORT
The Velbus Thermostat Operating Mode accepts - HEATING,COOLING

Google seems to be sending, heat,off,cool (But no sign of eco or auto)

It’s the mapping between what Google sends and Velbus thermostats accept.

There is a [ modes="off=SAFE etc option mentioned in the Google assistant page, but no matter what I try it doesn’t seem to change what is sent to the Velbus panel.

With habjes’ assistance, we’ve got Alexa mapping correctly, for both the Operating Mode and the Thermostat modes (or as Alexa prefers to call then “Presets”

Where are you seeing that ?

I see the new mode coming in from Google and being sent to the Velbus Item, then being rejected (because it hasn’t been mapped) and the thermostat defaulting back to SAFE

As an example, I have just used Alexa to “Set the middle bedroom preset to xxx” and this is what I see in the logs

2020-03-26 16:18:31.735 [vent.ItemStateChangedEvent] - BackBedroomGP2_CurrentTemperature changed from 21.3125 to 21.75
2020-03-26 16:18:31.736 [GroupItemStateChangedEvent] - WholeHouse_CurrentTemperature changed from 20.0313 to 20.25 through BackBedroomGP2_CurrentTemperature
2020-03-26 16:18:53.813 [ome.event.ItemCommandEvent] - Item 'MiddleBedroomGP2_ThermostatMode' received command DAY
2020-03-26 16:18:53.839 [nt.ItemStatePredictedEvent] - MiddleBedroomGP2_ThermostatMode predicted to become DAY
2020-03-26 16:18:53.848 [vent.ItemStateChangedEvent] - MiddleBedroomGP2_ThermostatMode changed from COMFORT to DAY
2020-03-26 16:18:53.871 [vent.ChannelTriggeredEvent] - velbus:vmbgp2:VelbusNetworkBridge:17:thermostat#HEATER triggered RELEASED
2020-03-26 16:18:53.894 [vent.ItemStateChangedEvent] - MiddleBedroomGP2_HeatingRelay changed from ON to OFF
2020-03-26 16:18:56.210 [vent.ItemStateChangedEvent] - MiddleBedroomGP2_CurrentTargetTemperature changed from 20.0 to 18.0
2020-03-26 16:18:56.211 [GroupItemStateChangedEvent] - WholeHouse_CurrentTargetTemperature changed from 16.0 to 15.0 through MiddleBedroomGP2_CurrentTargetTemperature
2020-03-26 16:19:06.101 [ome.event.ItemCommandEvent] - Item 'MiddleBedroomGP2_ThermostatMode' received command NIGHT
2020-03-26 16:19:06.119 [nt.ItemStatePredictedEvent] - MiddleBedroomGP2_ThermostatMode predicted to become NIGHT
2020-03-26 16:19:06.125 [vent.ItemStateChangedEvent] - MiddleBedroomGP2_ThermostatMode changed from DAY to NIGHT
2020-03-26 16:19:06.167 [vent.ChannelTriggeredEvent] - velbus:vmbgp2:VelbusNetworkBridge:17:thermostat#ALARM3 triggered RELEASED
2020-03-26 16:19:06.169 [vent.ChannelTriggeredEvent] - velbus:vmbgp2:VelbusNetworkBridge:17:thermostat#ALARM4 triggered RELEASED
2020-03-26 16:19:08.512 [GroupItemStateChangedEvent] - WholeHouse_CurrentTargetTemperature changed from 15.0 to 13.5 through MiddleBedroomGP2_CurrentTargetTemperature
2020-03-26 16:19:08.513 [vent.ItemStateChangedEvent] - MiddleBedroomGP2_CurrentTargetTemperature changed from 18.0 to 15.0
2020-03-26 16:19:17.287 [ome.event.ItemCommandEvent] - Item 'MiddleBedroomGP2_ThermostatMode' received command SAFE
2020-03-26 16:19:17.306 [nt.ItemStatePredictedEvent] - MiddleBedroomGP2_ThermostatMode predicted to become SAFE
2020-03-26 16:19:17.320 [vent.ItemStateChangedEvent] - MiddleBedroomGP2_ThermostatMode changed from NIGHT to SAFE
2020-03-26 16:19:19.499 [vent.ItemStateChangedEvent] - MiddleBedroomGP2_CurrentTargetTemperature changed from 15.0 to 12.0
2020-03-26 16:19:19.502 [GroupItemStateChangedEvent] - WholeHouse_CurrentTargetTemperature changed from 13.5 to 12.0 through MiddleBedroomGP2_CurrentTargetTemperature

Just a quick try using sitemap (with this mapping) on the Thermostatmode item… It works like a dream:

		Selection item=VmbeloMode mappings=[SAFE="SAFE", NIGHT="NIGHT", DAY="DAY", COMFORT="COMFORT"]

But I guess what you´re trying to do is to control the acutal heater, right? Thats the OpMode item and not the ThermostatMode item.

This tells that your item changed from SAFE to heat…
BUT! thats the ThermostatMode item… And it does not accept the “heat” command as far as I understand… So it reject the command ofcouse.

You problem is, you´re trying to control the thermostat with commands belonging to another item…
Thats why I asked for the possible modes for the glasspanels :smiley:

But are these two modes read/writeable or only readable?
It takes only a few seconds to test using sitemaps :smiley:

Tested the OpMode in sitemap using this mapping:

		Selection item=VmbeloOpMode  mappings=[HEATING="HEATING", COOLING="COOLING", OFF="OFF"]

This is the outcome.

2020-03-26 17:33:58.780 [ome.event.ItemCommandEvent] - Item 'VmbeloOpMode' received command COOLING
2020-03-26 17:33:58.797 [nt.ItemStatePredictedEvent] - VmbeloOpMode predicted to become COOLING
2020-03-26 17:33:58.832 [vent.ItemStateChangedEvent] - VmbeloOpMode changed from HEATING to COOLING
2020-03-26 17:33:59.005 [vent.ItemStateChangedEvent] - Vmbelo1TempSet changed from 22.0 °C to 21.0 °C
2020-03-26 17:33:59.355 [vent.ChannelTriggeredEvent] - velbus:vmbelo:1e8ce9e5:02:input#CH12 triggered PRESSED
2020-03-26 17:33:59.359 [vent.ChannelTriggeredEvent] - velbus:vmbelo:1e8ce9e5:02:thermostat#COOLER triggered PRESSED
2020-03-26 17:34:30.565 [ome.event.ItemCommandEvent] - Item 'VmbeloOpMode' received command OFF
2020-03-26 17:34:30.574 [nt.ItemStatePredictedEvent] - VmbeloOpMode predicted to become OFF
2020-03-26 17:34:30.599 [vent.ItemStateChangedEvent] - VmbeloOpMode changed from COOLING to OFF
2020-03-26 17:34:30.614 [vent.ItemStateChangedEvent] - VmbeloOpMode changed from OFF to COOLING
2020-03-26 17:34:30.877 [vent.ItemStateChangedEvent] - Vmbelo1Temp changed from 24.4375 °C to 24.5 °C
2020-03-26 17:34:54.052 [ome.event.ItemCommandEvent] - Item 'VmbeloOpMode' received command HEATING
2020-03-26 17:34:54.060 [nt.ItemStatePredictedEvent] - VmbeloOpMode predicted to become HEATING
2020-03-26 17:34:54.075 [vent.ItemStateChangedEvent] - VmbeloOpMode changed from COOLING to HEATING
2020-03-26 17:34:54.415 [vent.ItemStateChangedEvent] - Vmbelo1TempSet changed from 21.0 °C to 22.0 °C
2020-03-26 17:34:54.853 [vent.ChannelTriggeredEvent] - velbus:vmbelo:1e8ce9e5:02:input#CH12 triggered RELEASED
2020-03-26 17:34:54.857 [vent.ChannelTriggeredEvent] - velbus:vmbelo:1e8ce9e5:02:thermostat#COOLER triggered RELEASED

Notice… OFF did not work. HEATING and COOLING worked fine, and it triggered a input channel.

@jeshab described it perfectly…

The combination of the ThermostatMode and the ThermostatOperatingMode creates a matrix of options.

You can assign 4 different values to the ThermostatMode - SAFE,NIGHT,DAY & COMFORT

and change the ThermostatOperatingMode between HEATING & COOLING

Creating in effect 8 different modes of operation.

Jeshab described it as 2 thermostat modes, each with 4 presets.

Which in Alexa terms was perfect.


I have all the Velbus side of things working perfectly and with Jeshab’s assistance, Alexa seems to be happy too.

What I can’t do yet is get Google Assistant’s incoming commands to be mapped to something that the Velbus (binding) is happy with, (IE, Values that are valid for the thermostats)

So to go through your comments…

Unlike the Alexa metadata that can be mapped and Alexa informed as to the Presets and Modes that are available, we must accept whatever Google understands and map it to whatever our brand of thermostats accept.

(I could be very wrong here)

Either of the following is right

  • Google only knows it’s own options for modes and those have to be mapped to our thermostats

  • I haven’t worked out how to inform Google of the Modes that are available

That is the Google mode (heat) being sent to the Velbus thermostat.
The following line in the log is the Thermostat rejecting that command and resetting to SAFE

(Everything is READ/WRITE)

This is where the confusion is

The ThermostatOperatingMode can be either HEATING or COOLING

Whereas the ThermostatMode can be any of the 4 options, SAFE,NIGHT,DAY or COMFORT

		String MiddleBedroomGP2_ThermostatMode 				"Middle Bedroom Thermostat mode"	  	 		( MiddleBedroomGP2_Thermostat	)																{ channel="velbus:vmbgp2:VelbusNetworkBridge:17:thermostat#MODE", 							ga="thermostatMode" [ modes="off=SAFE,eco=NIGHT,on=DAY,heat=COMFORT" , lang="en" , ordered=true ] ,					 alexa="ModeController.mode" [friendlyNames="@Setting.Preset", supportedModes="SAFE=Safe,NIGHT=Night,DAY=Day,COMFORT=Comfort"]} // Accepts SAFE,NIGHT,DAY,COMFORT
		String MiddleBedroomGP2_ThermostatOperatingMode 	"Middle Bedroom Thermostat operating mode"		( MiddleBedroomGP2_Thermostat )																	{ channel="velbus:vmbgp2:VelbusNetworkBridge:17:thermostat#OPERATINGMODE"	,														alexa="ThermostatController.thermostatMode" [COOL="COOLING",HEAT="HEATING"]	} // Accepts HEATING & COOLING

The behaviour that you’ll see in the Velbus panel is that when in HEATING mode, the HEATER channel is “PRESSED” when the target temperature is ABOVE the current temperature

Whereas in COOLING mode the COOLER channel is PRESSED when the Target temperature is BELOW the Current temperature.

(It’s possible to create a kind of AUTO mode by assigning actions to the Thermostat Alarm channels and the OperatingMode, where if the Current temperature is +10° above the target, the unit changes to COOLING and another where if the Current Temperature is -10°c below the target temperature the unit changes to HEATING mode)

This is, to my understanding, how it is.
And yes, you´ll then need to map Velbus Modes to Google modes, (just like you did). But I think you mapped them wrong.
This is just a wild guess, but based on your previous log, where I see openhab trying to send “heat” to your ThermostatMode, maybe you need to swap the commands? Like this:

[ modes="SAFE=off,NIGHT=eco,DAY=on,COMFORT=heat" , lang="en" , ordered=true ]

I´m a bit “handicaped” here, cause my Velbus setup is running on the Odroid, and my GA connection is running on my Rpi. And on my Rpi, I havn´t got true Thermostats with modes. So I cant test it directly, only through sitemaps, which is only half the test worthy :frowning:
(And I need a 20meter USB cable to get the Velbus setup to my Rpi :smiley: ).

Second, I have some issues understanding how come the Modes has been splitted into two items? (I think thats the Velbus binding doing this). I know Velbus panels can handle it. But I dont see how Google would be able to. And I fail to understand how Alexa can.

Indeed, I’ve tried all kinds of variations on that theme.

(I’ve just tried this {again} and it doesn’t make any difference :sob: )

I’m not sure if it is openHAB2 that does that mapping (so I would expect it to be operational as soon as the Item file is updated and accepted.)

Or if that information has to be synchronised with Google during a refresh.

You could…

Add the Velbus binding to your RPi and use the Network Bridge to connect it to your Odroid.

(But why you haven’t simply restored your RPi configuration onto the Odroid I don’t know… it would be easy enough to add VelServ to your RPi is you wanted to isolate the Velbus kit)
Or you could poll the Odroid for Velbus Item values…

Openhab should do the mapping. Otherweise it makes no sense to me.
I always do syncronise whenever I have made any changes regarding GA.

Ahmm… Sorry I havn´t thought about this before :frowning:

It´s not that I wanted to isolated Velbus… Quite opposite infact… But I simply had this idea, I had to connect the Velbus USB module to the Rpi to get it to work :frowning:

1 Like

I’ll PM you so we can get you up and running.
It’ll be a very quick process

The modes config option needs to be set at the thermostat group and not on the mode child item!

lang="en" , ordered=true
Can be removed. Has no effect at all here.

No. It was correct.

Furthermore. I am still not sure if marziman has already published the version that included the modes features or if it just was merged into the master branch and stopped there…

That may explain it.

I did try putting the modes into the Group Item. Doesn’t seem to be deployed either?

Hmm, could you perhaps speed this up, since the doc´s has been updated?

I have no other or special contact to him than everybody else here.


I see… Lets see if this will do any changes then…

In the mean time… I noticed you answered Stuart (MDAR), that the mode mapping should be applied to the Thermostat group… Is this correct? According to the doc, it should be added to the ga="thermostatMode"

(Mandatory) Mode: Number (Zwave THERMOSTAT_MODE Format) or String (off, heat, cool, on, ...). { ga="thermostatMode" }

If you have deployed the new Mode mapping for thermostat, then it doesnt work.
If you havnt deployed it yet, could you please do so, or at least remove it from the doc.

If you read this very slowly, it is very clear

to custom ones for your specific setup, you can use the modes config option on the thermostat group

I missed it many times