I have to admit, so far I did not test the humidity function.
I will add this to my todo list.
Agree its very strange… And yes, the label has been like that for months… well since OH supported GA I would say…
I guess whats needed here is someone with an iphone, and having a dimmer tagged through OH.
To give you a small update on this…
The Android app have problems as well. When I enter a dimmer (light) it always show 0, even though the dimmer is on at 30% or anything else.
Look at this… The bottom lamp is one of my IHC dimmers. It´s actually turn on at 30% right now. But the app shows 0.
This next screenshot is from my livingroom where I have Hue lamps… Notice, it DO show their actual state:
For some reason is seems like devices tagged through openhab does not update correctly. But devices added directly to Google Home service (such as Hue) updates just fine.
I can still controle the dimmer from the GH android app, but not the GH iphone app.
fyi, GA humidity as a component of an OH thermostat (including mode, temp, setpoint, hum) works fine for me. Created it with PaperUI.
It’s best to just report spam instead of responding to it. It’s less confusing as once the post is marked as spam it get’s hidden and eventually removed and your reply ends up hanging out there looking to be disconnected from anything.
1 Like
I am having issues with my thermostat not working in Google assistant since the update.
(I updated to 2.5 m5 at the same time the Google assistant integration was being updated)
I have tried multiple ways of setting my thermostat tags and I never get it to show up in the home app or work properly thru the home speaker.
Info and steps taken in this thread.
There are something weird going on with both thermostats and ligthning at my setup. But it seems to be concentrated on the GUI of the Iphone Google Home app, which is caused from the latest update.
All my devices shows fine using Android Google Home app. And all devices works fine using voice commands.
Why I´m saying this: Because I´m pretty sure the lastest update has cause some problems, which may also be the reason why your´s not working… However, I have to admit, I find it very strange that Google Assistant dont even see your devices… That should always work, even if there is no “real” device behind.
@michikrug
Hi Michael… A short question…
What exactly is the targetHeatingCoolingMode depending on? According to the docs, it´s either “heat, cool, on or off”. It can be set by a Numer item or a String…
Pleas correct me if I´m wrong, but isn´t the targetHeatingCoolingMode a state to tell, if the heater is On/Off or Heating/Cooling, and in Google Home app it will change the visual color from red to blue? (heating/ cooling or on/off) ?
Reason I ask is, my underfloor heating setup is not having an exactly specific Mode. It´s a simple temperature sensor, and the logic just detamins if the temperature is above or below the setpoint. If temperature is above setpoint (incl thresshold), then turn off the actuator/telestat. If it´s below, then turn on the actuator/telestat…
Just plain and simple heating control system.
Now I wonder… Thinking about the above, shouldnt the actuator be used to set the actual targetHeatingCoolingMode then? I´m pretty sure it is suppose to work like this. But there is a slight problem. The actuator/telestat is a Switch type item, not a Number and not a String.
So in order to make this work, we will need the targetHeatingCoolingMode to have a Switch type option as well.
Couldn´t/shouldn´t it be done like this?
EDIT:
I just tried the above by using a String “proxyitem” for targetHeatingCoolingMode, and a rule which change the item to either “heat” or “cool” when the actuator/telestat changes… And it works exactly as descriped above… In Google Home app, the thermostat will change color, red when “heat” and blue when “cool”.
This is the rule:
rule "heatingmode"
when
Item telestat1_stort_bad changed
then
if (telestat1_stort_bad.state.toString == "ON" ) {
stort_bad_Mode.postUpdate("heat") }
else {
stort_bad_Mode.postUpdate("cool") }
end
So it does work as it is now. But if we could have a Switch type item for targetHeatingCoolingMode, then we wouldn´t have to use a rule to do this and not even a String, as the telestat/actuator can be used to set tagetHeatingCoolingMode.
Google assistant can see my device. But it just gives me a blank dial with no info when I open it. On iPhone or Android.
This is the most I get - first I just get the gray blank dial but if I touch the gear icon then go back I get this.
So it actually do see your thermostat. [ “Thermostat” ]
But it doesnt get any value from the temperature, [ “CurrentTemperature” ]
And it doesnt get any Heat mode either, [ “homekit:TargetHeatingCoolingMode” ]
And it probably dont get any setpoint either, [ “homekit:TargetTemperature” ] (Thats the wheel).
Something is wrong either in your setup (items files) or the values are not number values.
Could you post these four items here, (One Group, two Numbers and last Number/String), and fencecodes please.
Do you see any change states (value) for temperature, setpoint and heatmode in your logfile, if you try to manipulate it? (turn up/down for the heating as you usually would, without the use of GA).
Here is my entire item file (4 lights and a thermostat - thermostat is split in two due to the dual setpoints)
I don’t know what you mean by fencecodes.
The thermostat works fine via openhab paperui or habpanel. Nothing in the logs.
This is the thermostat for one of my rooms, showen by the use of code fenses:
(code fense is a visual way to show in the forum, which makes it alot easier to read).
Group g_marc_TSTAT "Marc Thermostat" [ "Thermostat" ]
Number marc_Temperature "Marcs værelse Temperatur [%.1f °C]" <cu_heating> (g_marc_TSTAT,Temperatur,gTvaer) [ "CurrentTemperature" ] { channel="ihc:controller:elko:marc_temperatur_fb" }
Number marc_Tempsetpunkt "Marcs værelse Temperature setpunkt [%.1f °C]" <temperature> (g_marc_TSTAT) [ "homekit:TargetTemperature" ] { channel="ihc:controller:elko:marc_temperaturSet_fb", autoupdate="false" }
String marc_Mode "Marcs værelse Mode [%s]" (g_marc_TSTAT) [ "homekit:TargetHeatingCoolingMode" ]
These are your items (I deleted everything else than what to be focus´d on):
Group g_Housecool "House Cooling" [ "Thermostat", "Fahrenheit" ]
Number Housecoolmode "House Heating/Cooling Mode" (g_Housecool) [ "homekit:TargetHeatingCoolingMode" ] {channel="zwave:device:c8787433:node3:thermostat_mode"}
Number CoolCurrentTemp "House Temperature" (g_Housecool) [ "CurrentTemperature" ] {channel="zwave:device:c8787433:node3:sensor_temperature"}
Number HouseSetTempCool "House Setpoint Cool" (g_Housecool) [ "homekit:TargetTemperature" ] {channel="zwave:device:c8787433:node3:thermostat_setpoint_cooling"}
Now, what you need to look at is, what state/value is posed TO openhab from these zwave channels:
{channel="zwave:device:c8787433:node3:thermostat_mode"}
{channel="zwave:device:c8787433:node3:sensor_temperature"}
{channel="zwave:device:c8787433:node3:thermostat_setpoint_cooling"}
If you are sure the log shows nothing for these three channels, then I would believe this is an issue between openhab and the zwave device… And not relate to the GA integration.
The first channel item Housecoolmode should state ON/OFF, cause it´s your [ “homekit:TargetHeatingCoolingMode” ] mode. If its a string, you would have to change the item type to String insted of Number.
You second channel item CoolCurrentTemp should state a value of the actual temperature cause its your [ “CurrentTemperature” ]
The third channel item HouseSetTempCool should state a value of your setpoint, cause its your [ “homekit:TargetTemperature” ]
Please verify that these items actually has a state/value. I have a very bad feeling, this is where you problem might be.
Sidenote:
I actually wonder if you need to set the unit of each items (in the label), like I do in mine… It shouldn´t make a difference, but on the other hand, it does make sense if it´s required, cause GA do read the labels in other items. Give it a try and add [%.1f] to the CurrentTemperature and TargetTemperature items. It wont hurt to try.
This setup works perfectly in openhab - I have checked it by changing things in paperui and habpanel and watching the thermostat change. There is no errors thus nothing in the log. Mode shouldn’t be on\off because it is for both heating and cooling sides. So the options should be off\heat\cool\auto (maybe not in that order). I have tried both number (what the thermostat defaults to) and string. All items work as intended with openhab just not with ga.
I will try the unit once my baby gets up from his nap (he is in the room where the computer is)
The targetHeatingCoolingMode has to be either, “heat”, “cool” or “on”, “off”.
So your zwave channel would have to pose this to your openhab item Housecoolmode in order to set the Mode in GA.
EDIT just re-read the doc again… It´s mentioning something about a “Zwave thermostatMode format”. I have no idea what that may be… But, someone else (on another forum) found, that using Number for the targetheatingcoolingmode, it has to be a value > 1.
But this is just one of the issue you seem to be suffering… You should be getting values to GA, not matter if heatingcoolingmode is working or not.
To make it more simple, (for an test). You could try with just the Group item and the currentTemperature. GA should then show the actual temperature in Google Home app.
If it works, you can add the setpoint and the mode.
If the “simple setup” doesnt work, there is for sure something weid going on with your setup…
Btw… You do remember to sync your devices, when you make changes, right? 
Interesting request. Actually, I also use a proxy item with a similar rule to translate to the required modes. But for a simple “heat/off” or “on/off” thermostat, a switch item could work too. This would need some additional logic in the cloud function to send and read the correct values.
Because on Google’s side it is not a boolean value but can distinguish between multiple states. At least cool is something different than off. While on could be the same as heat.
Tldr: will add this to my todo list.
1 Like
Perfect!
Number for mode is translated to a setting - and vice-versa. I can’t remember what number goes to what setting but the valid modes for my thermostat are heat\auto\aux heat (not used)\off\cool - these match the mode settings that show on my thermostat if I press the mode button.
I will try the “simple” setup and see if that helps.
Yes I sync after every change - I also swipe down to refresh the Google home app after syncing.
Ahh so fx “heat” update the item to = 1, “cool” = 2 etc ? That is a logic way I would say, and sure makes sense…
But this doesnt help you much, if you cant get the communication to GA to work proberly. Its mainly tells us which issues you´ve got.
I have a single test temperature sensor running. (Aeotech Mutilsensor6).
I have the group tagged [ “Thermostat” ] and then just the temperature sensor item [ “CurrentTemperature” ].
(I do have the targetHeatingCoolingMode as well, but it doesnt work. And it doesnt make any sense having either, as this is not a thermostat (not even functioning as a thermostat)). I just added the String item to see what will happen. ie… nothing!
Group g_zwave_TSTAT "Zwave Thermostat" [ "Thermostat" ]
String ZwaveThermostatMode "Zwave thermostat Mode [%s]" (g_zwave_TSTAT) [ "homekit:TargetHeatingCoolingMode" ]
Number ZWaveNode5ZW100MultiSensor6_SensorTemperature "Multisensor6 Temperatur Sensor [%.1f °C]" <cu_heating> (Temperatur,g_zwave_TSTAT) [ "CurrentTemperature" ] {channel="zwave:device:zstick:node5:sensor_temperature"}
This is how it poses in GH app:
Notice is say 24 under the wheel. Thats the actual temperature from the sensor right now.
So a simple setup just showing the actual temperature should work just fine.
The wheel is grey out cause I have not set the setpoint.
The heatingcooling mode (where is says “Varmetilstand”) is grey out, cause I havn´t set the targetHeatingCoolingMode.
This is a good way to try find whatever issue you may be having.
Temperature item does same thing - no readout and blank dial.
The weird thing is before the 2.0 rollout it worked (just not always stable as some parts of the old setup were less stable). I of course didn’t have the “homekit” tags in it at the time because those were making the old system fail for everyone. But now it won’t work.