Due to this problem: (I´m still at 2.5M2, but Rest Doc has ALWAYS been a huge problem).
Thats what I thought, But wouldn´t that require to make a rule for each thermostat (I have 12 thermostats).
How to make the calls without the Rest doc? I suspect its using the commandline and POST ? But this is where my knowledge come to its limits.
That REST Docs problem has been fixed for months. As of 2.5 M4 I believe, definitely in 2.5 M5.
You know Rules better than that. Just add a postUpdate to each Item you want to update in the one Rule.
Using curl construct the command to update the Item. But it’s probably not worth the time to figure out. Just create a Rule.
that is correct, REST docs work
Yeah, and it was suppose to be fixed in M2 as well, (read the thread I´d link to).
This has been an ongoing issue with Rest Doc several times… I have only managed to get it to work one time, (dont recall which version I was running)… And each time I install it, it breakes something else…
In this particular case, it´s not worth hunting for a fix.
I do 
Just did a test rule with one item, it worked just fine, and the mode is now set for “heat”, which resulted in both the Google Home app, as well as the Nest Hub works. I cant get respons about the humidity though… But thats a secondary problem.
It was, there were two different and unrelated problems. I was in fact the person who created the Issue on GitHub for the first one and I was running one of the bindings that caused problems with the REST API for the second one, so I do know the history here.
In both cases the problem was reported, a solution was found, and the fix has been put into place after just a weeks or so in both cases.
That’s how it’s supposed to work with a “testing” release.
Really? I’ve never not got it working, I consider the REST docs essential. It was broken in M2 and fixed in M4. Alex found the bug
I know Rich… But if you read the link I´d post, then notice how different informations appears about wether Rest Docs worked or not… Having Rest Docs working all depending on some bindings doesnt make things any better. Thats why I gave up on Rest Doc, uninstalled it, untill today.
I dont mind testing. But testing something which I know wont work isn´t a good or constructive way of testing, unless I have ideas how to solve it 
But all this is a different story in this thead…
Regarding the GA and thermostat… I think there is something odd going on…
When I ran the rule for update the string items (it actually ran itself when I saved the rule), I noticed it did update all items to “heat” state… But for some reason I have yet to find, it also did reset the setpoint to “-” (I suspect it´s NULL or “nothing”). This means the heating system no longer had a setpoint, which is a very unfortunate setting for a heating system…
Did you notice the same when you tried?
For a fast “fix” I manually updated all setpoints.
I have not tried to restart the system yet to see what happens cause I want to be sure this is not the way its suppose to do.
For having a Thermostat only appearing in Google Home it should be just enough to have the group with the Thermostat tag. For the sync the group members are not used at all.
They are only used for updates and queries.
So having a Thermostat not apprearing should not be related to missing mode items.
The functionality on the other hand strongly depends on having all items properly defined.
Furthermore, for the items also the tags without the homekit: prefix are supported. I implemented this with compatibility to current setups as well as the new recommended homekit variants.
See https://github.com/openhab/openhab-google-assistant/blob/master/functions/devices.js#L558
So basically, as already said. You guys should not need to change anything.
Btw. for updating items or setting a value I can totally recommend to use the built in console of openHAB and use the smarthome:send (or update) command.
I will take this into account in the metadata PR.
This should not be a problem to also allow contact item types.
Ofc. with the limitation of not being able to control things.
Yes, Google issue. The Google Home app seems to not have proper support for a lot of device types.
But voice control works for all of them.
I read that thread when it was posted and you will see I was a participant. I too was affected by that bug so I followed that thread and the GitHub issue very closely. It worked for some people and not others. Over time it was discovered that certain bindings broke the REST Docs. And IIRC the order that bindings were installed makes a difference too.
Exactly. At that time no one knew why the REST Docs were broken. That thread (and other threads) were everyone collaborating to try to figure out what was broken so it could be fixed. Thanks to the effort of one user who systematically installed and uninstalled bindings to see which ones broke the REST Docs we were able to figure out what was broken and how to fix it. Within a day or two of discovering the source of the problem, the fix was available in the snapshots.
If you are only willing to test things you can fix yourself you are not a very useful tester for openHAB. Just reporting problems here and on GitHub and participating in threads where other users are dealing with the same problem is how you help by testing.
Don’t suspect. Check. Look in events.log, or since you’ve installed the REST API, query for it’s current state. It can be informative to know if it’s NULL versus UNDEF.
I’ve never looked at the Target_Temp in my setups. I’ve only one usable thermostat and that’s a Nest (for now) with native integration with GA. All the rest are just sensors exposed to GA through openHAB so the target temp is non-functional. I only have it defined because the docs say it’s required.
I can not see from the event.log that it ever changed from a value to NULL. But I can see them changed from NULL to a value, when I manually entered the setpoint after I discovered this change.
This tells me the setpoints all changed to NULL when I updated the String items for the Mode setting.
Sorry forgot to answer this… I did uninstall rest doc again… It didn´t work, as I mentioned… I believe when I have updated to 2.5M5 I may give it a chance again. Thats what I meant with, no reason to test something knowing it doesnt work.
Michael, did you see my previous post about the setpoint beeing reset (to NULL), when I updated the item for heating mode?
Yes. I think this is a normal openHAB behavior when updating item definitions. The connected thing should update it afterwards.
It’s possible, volume, channel, stop, pause, play … etc with action.devices.traits.Volume , action.devices.traits.Channel and action.devices.traits.MediaState, but it’s not official, I know @michikrug looked at this traits . It will be perfect with a group action.devices.types.TV (look like thermostat group) with inside this differents traits 
Hmm. I´m not really sure how to force an update on a temperature setpoint. Normally this only update from a manual interfeering… Perhaps @pauli_anttila have an idea for the IHC binding, as that is the thing in question here.
Wow thank you so much for that Progress. Makes Google Home much more enjoyable now.
One issue i figured out is that i added the Humidity Fuction. Item have a Number Value of for example 74. But when i ask Google how ist Humidity in LivingRoom he says 0. Did i miss sth?
Im also looking forward to the new integration with more possibilities :-))
@michikrug
I´m not sure if this is a openhab issue or Google issue or perhaps a mix. But something is wrong somewhere. And I dont see others mentioning the same issue. But…
I´ll try explain as clear as I can… Hold tight, cause it is quite confusing.
Google Home app on my iphone no longer recognize my IHC dimmers lights, which are tag´d through openhab. The app see the light as simple on/off. (no cogwheel to change the dimming).
But…
Google Home app on my Android phone my IHC dimmers works fine. There is a cogwheel and dimmer works fine…
This could sound like a GH app failer on the iphone, right?
But…
Google Home app on my iphone works fine with my Philips Hue lights (with dimmer/cogwheel)…
Differences:
Hue is directly connected to Google Home via the app services…
IHC dimmers are connected through openhab service.
Then I´m no longer sure if this is really a iphone app issue anymore… Sounds very odd…
It gets more strange…
On my Google Nest Hub:
Hue lights works fine (dimmer and cogwheel). But all my IHC dimmers do not work at all. The Nest Hub tries to connect to the dimmer, but returns back to main screen.
And just to make things even worse:
Using voice control works fine, both controlling, turn on/off or dimming IHC dimmers. So it may seem it´s a visual problem in the iphone app and the Google Nest Hub.
This is how I have tagged my IHC dimmers. They have worked just fine for several months, just untill you made the lasted update.
Dimmer stort_badDimmerLys "Loftlys i Stort Bad [%.0f %%]" <cu_spot> (vLys) [ "Lighting" ] { channel="ihc:controller:elko:stortbad_dimmer", autoupdate="false" }
This really sounds strange and will be super hard to debug from my side, since I a) have no iDevice and b) also no Nest Hub.
Also I have no access to logs or anything helpful here.
In two weeks I will try play with some settings to see if I can find some clues. But no promises here.
Could the label with the special chars be an issue?
But I think they were also attached the same way before…
No real idea atm.
I have to admit, so far I did not test the humidity function.
I will add this to my todo list.