i beg to differ:
String NestTStat_HVAC_Mode “Mode [%s]” { channel=“nest:thermostat:2965c7dd:KeD484GZZTFkb3eBbV4EzVBPx9yKQrvJ:mode” }
Hmm, guess I don’t know then. The wiki here:
https://docs.openhab.org/addons/bindings/nest/readme.html
Shows “state” reporting “heating”, “cooling”, etc and mode reporting
"HEAT", “COOL” etc.
I’ve created a WIP PR for using the QuantityType for temperature values in the Nest Binding. It’s mostly finished and uses Thermostat temperature scale setting to determine which values are used for reading/writing Nest API temperature values:
https://github.com/openhab/openhab2-addons/pull/3150
It seems to work well with both Celsius and Fahrenheit values after some testing. Now it’s just waiting for the upstream PR to get merged and review comments on my PR. 
Great, thank you for letting me know! I’ll check this out.
Thanks Wouter. I created a PR on your fork to fix the error where we can’t change the setpoint. Can you please merge, rebuild and post link to the new JAR here for everyone?
Thanks @Danny_Cohn!
I’ve uploaded a new org.openhab.binding.nest-2.2.0-fahrenheit.jar which will fix setting the Thermostat target temperature with Fahrenheit values.
It also includes the following OH 2.3.0 pull requests:
Hi all, I’ve been using the openhab 1.x version of the nest binding since using openhab 1 and after migrating to openhab 2. I’m going to attempt to change to this version today now that fahrenheit is supported. I am currently running the 2.3.0-SNAPSHOT, Build #1206.
I just want to confirm the correct channel syntax for temperature. Do we need any special configuration like:
Number Thermostat_Temperature "Temperature [%.1f °F]" { channel="nest:thermostat:demo_account:living_thermostat:temperature_F" }
or just leave it as is and the binding will manage automatically?
Number Thermostat_Temperature "Temperature [%.1f °F]" { channel="nest:thermostat:demo_account:living_thermostat:temperature" }
*Many thanks to everyone who has ever worked on this binding.
Just refer to temperature, not _f. This version of the binding only talks in F, but does so without qualifying it as such via _f like the Nest API does
I’ve just switched over, updated my things and items. The cameras and protects are working fine, but the thermostat is not working. Throws the following error every few seconds…
2018-02-08 16:36:57.382 [DEBUG] [g.nest.handler.NestThermostatHandler] - Updating thermostat DEVICEID_HERE
2018-02-08 16:36:57.416 [WARN ] [nternal.rest.NestStreamingRestClient] - An exception occurred while processing the inbound event
java.lang.NullPointerException: null
at org.openhab.binding.nest.handler.NestThermostatHandler.getChannelState(NestThermostatHandler.java:56) ~[?:?]
at org.openhab.binding.nest.handler.NestThermostatHandler.getChannelState(NestThermostatHandler.java:1) ~[?:?]
at org.openhab.binding.nest.handler.NestBaseHandler.lambda$0(NestBaseHandler.java:135) ~[?:?]
at java.util.ArrayList.forEach(ArrayList.java:1257) ~[?:?]
at java.util.Collections$UnmodifiableCollection.forEach(Collections.java:1080) ~[?:?]
at org.openhab.binding.nest.handler.NestBaseHandler.updateChannels(NestBaseHandler.java:135) ~[?:?]
at org.openhab.binding.nest.handler.NestThermostatHandler.onNewNestThermostatData(NestThermostatHandler.java:160) ~[?:?]
at java.lang.Iterable.forEach(Iterable.java:75) ~[?:?]
at org.openhab.binding.nest.handler.NestBridgeHandler.broadcastDevices(NestBridgeHandler.java:213) ~[?:?]
at org.openhab.binding.nest.handler.NestBridgeHandler.lambda$1(NestBridgeHandler.java:208) ~[?:?]
at java.util.concurrent.CopyOnWriteArrayList.forEach(CopyOnWriteArrayList.java:891) ~[?:?]
at org.openhab.binding.nest.handler.NestBridgeHandler.broadcastDevices(NestBridgeHandler.java:208) ~[?:?]
at org.openhab.binding.nest.handler.NestBridgeHandler.onNewTopLevelData(NestBridgeHandler.java:388) ~[?:?]
at org.openhab.binding.nest.internal.rest.NestStreamingRestClient.lambda$4(NestStreamingRestClient.java:206) ~[?:?]
at java.util.concurrent.CopyOnWriteArrayList.forEach(CopyOnWriteArrayList.java:891) ~[?:?]
at org.openhab.binding.nest.internal.rest.NestStreamingRestClient.onEvent(NestStreamingRestClient.java:206) ~[?:?]
at org.glassfish.jersey.media.sse.EventSource$EventProcessor.notify(EventSource.java:687) [180:org.glassfish.jersey.media.jersey-media-sse:2.22.2]
at org.glassfish.jersey.media.sse.EventSource$EventProcessor.notify(EventSource.java:681) [180:org.glassfish.jersey.media.jersey-media-sse:2.22.2]
at org.glassfish.jersey.media.sse.EventSource$EventProcessor.onEvent(EventSource.java:668) [180:org.glassfish.jersey.media.jersey-media-sse:2.22.2]
at org.glassfish.jersey.media.sse.EventSource$EventProcessor.run(EventSource.java:614) [180:org.glassfish.jersey.media.jersey-media-sse:2.22.2]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
at java.lang.Thread.run(Thread.java:748) [?:?]
It’s also marked as “waiting to refresh”:
The binding does appear to be getting all of the information from nest:
2018-02-08 16:44:33.440 [DEBUG] [nternal.rest.NestStreamingRestClient] - Received ‘put’ event, data: {“path”:“/”,“data”:{“devices”:{“thermostats”:{“DEVICEID_HERE”:{“humidity”:25,“locale”:“en-US”,“temperature_scale”:“F”,“is_using_emergency_heat”:false,“has_fan”:true,“software_version”:“5.6.6-4”,“has_leaf”:false,“where_id”:“WHEREID_HERE”,“device_id”:“DEVICEID_HERE”,“name”:“Thermostat”,“can_heat”:true,“can_cool”:true,“target_temperature_c”:20.5,“target_temperature_f”:69,“target_temperature_high_c”:24.0,“target_temperature_high_f”:75,“target_temperature_low_c”:20.0,“target_temperature_low_f”:68,“ambient_temperature_c”:20.0,“ambient_temperature_f”:68,“away_temperature_high_c”:24.0,“away_temperature_high_f”:76,“away_temperature_low_c”:12.5,“away_temperature_low_f”:55,“structure_id”:“STRUCTUREID_HERE”,“fan_timer_active”:true,“fan_timer_timeout”:“1970-01-01T00:00:00.000Z”,“hvac_mode”:“heat”,“name_long”:“Thermostat Thermostat”,“is_online”:true,“last_connection”:“2018-02-08T21:34:36.468Z”,“hvac_state”:“heating”}},“smoke_co_alarms”: …etc
It looks like the fan_timer_duration property is missing which causes the exception @omatzyo . You can probably fix this by making sure the “Thermostat read/write v6” permission is enabled in the Nest Developer console. This property was added in v6. See also the earlier discussion in this thread.
I’ll put in a PR in the future so null values no longer result in such exceptions.
You are absolutely correct. I’m not sure how I missed that. Sorry. Updating to v6 fixed the error. Thank you!
I am seeing the same behavior.
openhab> smarthome:status Nest_hvac_mode
HEAT
2018-02-09 07:04:15.273 [DEBUG] [nternal.rest.NestStreamingRestClient] - Received ‘put’ event, data: {“path”:“/”,“data”:{“devices”:{“thermostats”:{“”:{“humidity”:20,“locale”:“en-US”,“temperature_scale”:“F”,“is_using_emergency_heat”:false,“has_fan”:true,“software_version”:“5.6.6-4”,“has_leaf”:false,“where_id”:“”,“device_id”:“”,“name”:“Thermostat”,“can_heat”:true,“can_cool”:true,“target_temperature_c”:19.0,“target_temperature_f”:67,“target_temperature_high_c”:24.0,“target_temperature_high_f”:75,“target_temperature_low_c”:20.0,“target_temperature_low_f”:68,“ambient_temperature_c”:19.0,“ambient_temperature_f”:67,“away_temperature_high_c”:24.0,“away_temperature_high_f”:76,“away_temperature_low_c”:12.5,“away_temperature_low_f”:55,“eco_temperature_high_c”:24.0,“eco_temperature_high_f”:76,“eco_temperature_low_c”:12.5,“eco_temperature_low_f”:55,“is_locked”:false,“locked_temp_min_c”:20.0,“locked_temp_min_f”:68,“locked_temp_max_c”:22.0,“locked_temp_max_f”:72,“sunlight_correction_active”:false,“sunlight_correction_enabled”:true,“structure_id”:“”,“fan_timer_active”:false,“fan_timer_timeout”:“1970-01-01T00:00:00.000Z”,“fan_timer_duration”:15,“previous_hvac_mode”:“”,“hvac_mode”:“heat”,“time_to_target”:“~0”,“time_to_target_training”:“ready”,“where_name”:“Thermostat”,“label”:“”,“name_long”:“Thermostat Thermostat”,“is_online”:true,“last_connection”:“2018-02-09T12:00:03.411Z”,“hvac_state”:“heating”}},“smoke_co_alarms”:…etc
So, the binding does have the correct value:
"hvac_mode":"heat"
Here is my item:
String Nest_hvac_mode "HVAC Mode [%s]" (Nest_Therm_ground,changed_restored,Weather) { channel="nest:thermostat:my_home_account:ground_thermostat:mode" }
It also retains the “heating” value when the “hvac_state” updates to “off”.
Is there something that is processing this and changing to all caps? Perhaps its related to the strange behavior we’re noticing?
1 Like
case CHANNEL_MODE:
return new StringType(thermostat.getMode().name());
case CHANNEL_PREVIOUS_MODE:
Mode previousMode = thermostat.getPreviousMode() != null ? thermostat.getPreviousMode()
: thermostat.getMode();
return new StringType(previousMode.name());
I’m taking a stab here, but what if we remove the .name()?
I don’t mean to hijack this thread with issues, but I seem to be running into quite a few. I want to say thank you again to everyone for the great work on this binding.
Has anyone had an issue coming up against the rate limit?
I have some rules that change the temperature in the house - similar to those mentioned above. It is not changed excessively… Maybe every hour or every two hours. With this version of the binding I’m getting a lot of “blocked” messages. I’m not updating any other values. I have noticed (unless I’m reading the log incorrectly) that the updating seems to happen every few seconds (or even every second). I’m not sure how to control for this.
Here is a snippet from my debug log when I try to update the temp:
2018-02-10 10:06:03.923 [DEBUG] [nternal.rest.NestStreamingRestClient] - Received 'keep-alive' event, data: null
2018-02-10 10:06:03.924 [DEBUG] [nternal.rest.NestStreamingRestClient] - Received message to keep connection alive
2018-02-10 10:06:10.334 [DEBUG] [nding.nest.handler.NestBridgeHandler] - Putting data to: https://firebase-apiserver17-tah01-iad01.dapi.production.nest.com:9553/devices/thermostats/THERMOSTAT_ID
2018-02-10 10:06:10.491 [DEBUG] [nding.nest.handler.NestBridgeHandler] - PUT content: {"target_temperature_f":67.0}
2018-02-10 10:06:10.492 [DEBUG] [nding.nest.handler.NestBridgeHandler] - Re-using access token from configuration: MY_TOKEN
2018-02-10 10:06:10.809 [DEBUG] [nding.nest.handler.NestBridgeHandler] - PUT response: {"error":"blocked","type":"https://developer.nest.com/documentation/cloud/error-messages#blocked","message":"blocked","instance":"0f42fcd1-dc4c-4f6b-8721-63523bb98e75"}
2018-02-10 10:06:10.810 [DEBUG] [nding.nest.handler.NestBridgeHandler] - Nest API error: ErrorData [error=blocked, type=https://developer.nest.com/documentation/cloud/error-messages#blocked, message=blocked, instance=0f42fcd1-dc4c-4f6b-8721-63523bb98e75]
2018-02-10 10:06:10.811 [WARN ] [nding.nest.handler.NestBridgeHandler] - Nest API error: blocked
2018-02-10 10:06:23.301 [DEBUG] [nternal.rest.NestStreamingRestClient] - Check: Receiving streaming events, millisSinceLastEvent=19378
2018-02-10 10:06:27.401 [DEBUG] [nternal.rest.NestStreamingRestClient] - Received 'put' event, data: {"path":"/","data":{"devices":{"thermostats":{...etc
2018-02-10 10:06:27.405 [DEBUG] [nternal.rest.NestStreamingRestClient] - Data has changed (or initial data sent)
...a bunch of things are handled
2018-02-10 10:06:28.497 [DEBUG] [nternal.rest.NestStreamingRestClient] - Received 'put' event, data: {"path":"/","data":{"devices":{"thermostats":...etc
2018-02-10 10:06:28.504 [DEBUG] [nternal.rest.NestStreamingRestClient] - Data has changed (or initial data sent)
...a bunch of things are handled
2018-02-10 10:06:30.792 [DEBUG] [nternal.rest.NestStreamingRestClient] - Received 'put' event, data: {"path":"/","data":{"devices":{"thermostats":...etc
2018-02-10 10:06:30.799 [DEBUG] [nternal.rest.NestStreamingRestClient] - Data has changed (or initial data sent)
...a bunch of things are handled
2018-02-10 10:06:33.924 [DEBUG] [nternal.rest.NestStreamingRestClient] - Received 'keep-alive' event, data: null
2018-02-10 10:06:33.925 [DEBUG] [nternal.rest.NestStreamingRestClient] - Received message to keep connection alive
2018-02-10 10:06:36.774 [DEBUG] [nternal.rest.NestStreamingRestClient] - Received 'put' event, data: {"path":"/","data":{"devices":{"thermostats":...etc
2018-02-10 10:06:36.778 [DEBUG] [nternal.rest.NestStreamingRestClient] - Data has changed (or initial data sent)
2018-02-10 10:06:44.439 [DEBUG] [nternal.rest.NestStreamingRestClient] - Received 'put' event, data: {"path":"/","data":{"devices":{"thermostats":...etc
2018-02-10 10:06:44.458 [DEBUG] [nternal.rest.NestStreamingRestClient] - Data has changed (or initial data sent)
...a bunch of things are handled
2018-02-10 10:06:53.303 [DEBUG] [nternal.rest.NestStreamingRestClient] - Check: Receiving streaming events, millisSinceLastEvent=8867
2018-02-10 10:07:03.926 [DEBUG] [nternal.rest.NestStreamingRestClient] - Received 'keep-alive' event, data: null
2018-02-10 10:07:03.929 [DEBUG] [nternal.rest.NestStreamingRestClient] - Received message to keep connection alive
2018-02-10 10:07:09.625 [DEBUG] [nternal.rest.NestStreamingRestClient] - Received 'put' event, data: {"path":"/","data":{"devices":{"thermostats":...etc
2018-02-10 10:07:09.630 [DEBUG] [nternal.rest.NestStreamingRestClient] - Data has changed (or initial data sent)
Hey @omatzyo I just submitted some PRs to change the code of the original binding pinkfish created. I haven’t touched the naming/casing which is indeed a bit different from the OH1 binding. I think it is a little late in the game to change it now everybody is using it. The possible states are listed in the channel descriptions of the binding documentation.
The OH2 binding no longer polls the state every minute. Instead it now uses the Nest REST Streaming API so it is instantly notified of every change. I can imagine if you send a command each time an update occurs you can quickly run into the rate limit. The rate limits may also become an issue when you reuse the same OAuth token in multiple OH instances
I’ve already changed all my rules to use the all caps version of things and that is working fine. I just think it’s odd that the display string is different from the actual state of the item. Most things in openhab don’t work like this. The state is “HEAT” but the displayed string is “heating”. I know there are exceptions. I though perhaps this was not by design. Regardless, it has been working in my rules
But I don’t. That’s why I’m confused. It only sends a command every hour or two… or longer. And this is my only instance in which I’m running a nest binding. Is your log constantly updating this this, every second?
HEAT is the constant that can also be used in rules. In Java all constants are capitalized so I guess that is why it is all caps. “heating” is the English UI translation for this constant. When translations are provided people using another locale will see a localized string.
The more Nest devices you have the more updates you will receive. I have 6 Nest devices and sometimes I have several updates in one second. Sometimes it may take a minute to get another. The keep-alive is usually sent every 30secs when there is no update.
You may also hit the rate limit when the connection is unstable. The binding may then try to reconnect too often which could stress the Nest servers. When it reconnects it logs this with “Reopening EventSource”.
1 Like
Is there something specific needed to get the nest into F units? I’m on v2.3.0-SNAPSHOT and just starting to play around with my nest setup.
Not to be a pain, I’m on 2.2 stable and just installed the most recent .jar from the post a few days ago. Everything works great except, I’m pulling Current Outside Temp from the Nest and it’s still showing in Celsius. Of course, it’s pretty likely it’s just something I did wrong and I just can’t figure out what, but wanted to give you a heads up, just in case it wasn’t me.