Google is QUITE specific about temperature, you need at least items for:
Mode
Setpoint / Target Temperature
Current Temperature / Ambient Temperature
(See the HomeKit addon page for further info on item setup, grouping, and tag usage).
I made my own “thermostat” with a temperature sensor and a dry contact so I had to have a Mode item for Google to properly provide temperature details.
There are also variables for high and low range, but there does not exist the HomeKit tag convention yet to support.
I’m having the same problem with items set up like that. Seems right, from what I’ve read, but I’m not very experienced with this. Just problems with the mode. It doesn’t seem like Google Home is using the item tagged with [“homekit:HeatingCoolingMode”]. Can’t reach openHAB when I try to set the thermostat mode, and Google always tells me it’s off, even when it’s set to HEAT or AUTO.
I can read the current temperature, and set the target temperature. Just not the mode.
Can someone please post a working example of items for a thermostat?
Hi is there a fix being worked on for the multiple tag issue i use imperihome addon, the workaround i use now is just sync the devices with google then add the additional tags, but if i resync i lose google assistant control after.
For anyone that had the “Sorry I am unable to process your request” issue due to previous IFTTT linkages, it looks like it might finally be fixed. Mine started responding to “turn on/off” commands a few days ago, and just had a reply on my support case confirming that they’ve fixed a number of ‘minor glitches’ including the IFTTT one that I had. So if you were affected too - give it a shot now. ;p
I’m having some difficulty controlling my devices in Google Routines. I have a number of “Switchable” and “Lighting” tagged items, each with an associated rule that issues a simple sendHttpGetRequest to an internal server that has a json interface. For example:
rule "Living Room Lamp"
when
Item LR_Lamp_1 changed
then
if (LR_Lamp_1.state == ON)
sendHttpGetRequest("http://192.168.8.8/JSON?request=xxxxxxxx")
else
sendHttpGetRequest("http://192.168.8.8/JSON?request=xxxxxxxx")
end
This works great when simply asking Google to turn on (or off) a given device. However, when I try to add a device control action to a routine by clicking “Adjust lights, plugs, and more” in the routine and selecting “Turn on” for a given device, Google Home says “Sorry, I am unable to reach xxxxxx right now. Please try again”. I’ve confirmed that the action request never gets logged in my openHAB cloud account “Event log”.
I get the same error when modifying one of the predefined routines, or by creating a new custom routine.
Someone else mentioned previously in this thread that they too were getting this error, but I didn’t see a reply. Any pointers would be most appreciated… thx.
I don’t think there is a working configuration yet @aart - I tried all combinations in my post above. Especially for the heat/cool mode, the two setpoint tags need to be split out into separate controllable tags. I did raise an issue on Github so hopefully it’ll get sorted out in an upcoming release.
The integration works fine for me,but I have a little concern. I have added some new lights to my openhab, it works fine. Updated the config through Google Home by issuing the sync openhab command. It updated everything, however I can’t see the new lights in the app… I can say commands and it will toggle the switch, but I can’t select room for these new lights, etc… Are there any workaround for that? Or I have unlink and re-link openhab with Google Home?
@MARZIMA
can we add
thermostatHumidityAmbient ( Float 0-100) please?
I have thermostat with Humidity value to read…
So after sample command
“What is kitchen thermostat inside ?”
Response should be:
"Heating is set to [thermostatTemperatureSetpoint], with current temperature of [thermostatTemperatureAmbient] and humidity of [thermostatHumidityAmbient]
I’m experiencing the same thing. Using Google Routines I set two thermostats (two temperature setpoints) and one virtual switch when waking up or going to bed. Up till recently these actions in Google Routines did get executed just fine for me although Google Routines reported 3 errors on the 3 actions:
‘It looks like openHAB is unavailable right now’ (3 times)
or
‘Sorry, I couldn’t reach openHAB (2x). It looks like openHAB is unavailable right now’.
Needless to say that these actions are performing well when trying to set them through Google Assistant (I have no Google Home) directly. Also when asking for the temperature in the room I get a perfect answer back on heating/cooling mode, the current temperature and the temperature setpoint. All is well.
But ‘sync openHAB’ or ‘sync devices’ is currently not working for me anymore. ‘Sync Philips Hue’ is still working fine. openHAB servers seem to be up and running and I only have Lighting, Switchable and Themostat tags in my openHAB setup. I can’t help but feel that something is still missing / is reporting incorrect values back to Google Assistant / Routines.
Especially the ‘sync openHAB’ not working for me anymore is worrying as I don’t want to have to relink my openHAB setup (85 devices to put in rooms, give nicknames etc).
GA uses the following modes: off, on, heat, cool, heatcool (e.g. auto). Currently the OH Action currently supports translating the OH ZWave format (0,1,2,3) to the above so it can tell you the current mode.
Changing the mode is a little it trickier since it would need to use GA’s convention and translate to what the item expects (some are Numbers and some are string). I am not sure of all conventions that thermostats use in OH, but if we can confirm it may be possible to add.
This was a miss on my part, I think I added Humidity later on when I was working on the commit and left it out of one section of the code (where GA parses the members of a thermostat group).
When I tested, if you have a Thermostat Humidity item (as float) it should return 0-100 (as %). If you do not have a Humidity item in the thermostat group it will say “cannot reach [x] Thermostat”.
This will need to be tested and such before deployed and added to production.
