Openhab2 Nest binding - 2.2.0.SNAPSHOT An Updated 2.0 Binding that works!

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:

  • #3018 - Remove deprecated auto-away state
  • #3024 - Add last_connection, last_online_change and last_manual_test_time channels

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 ] [] - An exception occurred while processing the inbound event
java.lang.NullPointerException: null
	at org.openhab.binding.nest.handler.NestThermostatHandler.getChannelState( ~[?:?]
	at org.openhab.binding.nest.handler.NestThermostatHandler.getChannelState( ~[?:?]
	at org.openhab.binding.nest.handler.NestBaseHandler.lambda$0( ~[?:?]
	at java.util.ArrayList.forEach( ~[?:?]
	at java.util.Collections$UnmodifiableCollection.forEach( ~[?:?]
	at org.openhab.binding.nest.handler.NestBaseHandler.updateChannels( ~[?:?]
	at org.openhab.binding.nest.handler.NestThermostatHandler.onNewNestThermostatData( ~[?:?]
	at java.lang.Iterable.forEach( ~[?:?]
	at org.openhab.binding.nest.handler.NestBridgeHandler.broadcastDevices( ~[?:?]
	at org.openhab.binding.nest.handler.NestBridgeHandler.lambda$1( ~[?:?]
	at java.util.concurrent.CopyOnWriteArrayList.forEach( ~[?:?]
	at org.openhab.binding.nest.handler.NestBridgeHandler.broadcastDevices( ~[?:?]
	at org.openhab.binding.nest.handler.NestBridgeHandler.onNewTopLevelData( ~[?:?]
	at$4( ~[?:?]
	at java.util.concurrent.CopyOnWriteArrayList.forEach( ~[?:?]
	at ~[?:?]
	at$EventProcessor.notify( []
	at$EventProcessor.notify( []
	at$EventProcessor.onEvent( []
	at$ []
	at java.util.concurrent.Executors$ [?:?]
	at [?:?]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201( [?:?]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ [?:?]
	at java.util.concurrent.ThreadPoolExecutor.runWorker( [?:?]
	at java.util.concurrent.ThreadPoolExecutor$ [?:?]
	at [?:?]

It’s also marked as “waiting to refresh”:
Untitled 2

The binding does appear to be getting all of the information from nest:

2018-02-08 16:44:33.440 [DEBUG] [] - 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

Untitled 3

2018-02-09 07:04:15.273 [DEBUG] [] - 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:


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

@wborn, Just looking here

            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(;

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] [] - Received 'keep-alive' event, data: null
2018-02-10 10:06:03.924 [DEBUG] [] - Received message to keep connection alive
2018-02-10 10:06:10.334 [DEBUG] [nding.nest.handler.NestBridgeHandler] - Putting data to:
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":"","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=, 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] [] - Check: Receiving streaming events, millisSinceLastEvent=19378
2018-02-10 10:06:27.401 [DEBUG] [] - Received 'put' event, data: {"path":"/","data":{"devices":{"thermostats":{...etc
2018-02-10 10:06:27.405 [DEBUG] [] - Data has changed (or initial data sent)

...a bunch of things are handled

2018-02-10 10:06:28.497 [DEBUG] [] - Received 'put' event, data: {"path":"/","data":{"devices":{"thermostats":...etc
2018-02-10 10:06:28.504 [DEBUG] [] - Data has changed (or initial data sent)

...a bunch of things are handled

2018-02-10 10:06:30.792 [DEBUG] [] - Received 'put' event, data: {"path":"/","data":{"devices":{"thermostats":...etc
2018-02-10 10:06:30.799 [DEBUG] [] - Data has changed (or initial data sent)

...a bunch of things are handled

2018-02-10 10:06:33.924 [DEBUG] [] - Received 'keep-alive' event, data: null
2018-02-10 10:06:33.925 [DEBUG] [] - Received message to keep connection alive
2018-02-10 10:06:36.774 [DEBUG] [] - Received 'put' event, data: {"path":"/","data":{"devices":{"thermostats":...etc
2018-02-10 10:06:36.778 [DEBUG] [] - Data has changed (or initial data sent)
2018-02-10 10:06:44.439 [DEBUG] [] - Received 'put' event, data: {"path":"/","data":{"devices":{"thermostats":...etc
2018-02-10 10:06:44.458 [DEBUG] [] - Data has changed (or initial data sent)

...a bunch of things are handled

2018-02-10 10:06:53.303 [DEBUG] [] - Check: Receiving streaming events, millisSinceLastEvent=8867
2018-02-10 10:07:03.926 [DEBUG] [] - Received 'keep-alive' event, data: null
2018-02-10 10:07:03.929 [DEBUG] [] - Received message to keep connection alive
2018-02-10 10:07:09.625 [DEBUG] [] - Received 'put' event, data: {"path":"/","data":{"devices":{"thermostats":...etc
2018-02-10 10:07:09.630 [DEBUG] [] - 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 :slight_smile:

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.

I’d just like to add that I’ve been using this binding for a couple of months now, getting the current temperature/humidity, Away state, heating state, and setting the target temperature on the Nest to either 13 or 24 (as an “on/off” switch for my heating in general), it is working great.

Although I do still have an additional rule running every 30 minutes to send my target temperature (13 or 24) just in case, I don’t think it’s actually been needed for a long while (I’ve just not got round to removing it, and as openHAB is in charge of my heating, rather than the Nest, it’s a sensible fail-safe)

I have a nest smoke alarm, have installed binding and configured it up, it mostly works - however the “last_connection” date/time does not.

/* NEST Smoke Alarm */ 
Switch   		hallway_Nest_battery            "Low Battery"                        <battery>                                                    { channel="nest:smoke_detector:halway:low_battery" }
String          hallway_Nest_smoke              "Smoke Status [%s]"                  <smoke>                                                      { channel="nest:smoke_detector:halway:smoke_alarm_state" }
String          hallway_Nest_co                 "CO Status [%s]"                     <carbondioxide>                                              { channel="nest:smoke_detector:halway:co_alarm_state" }
DateTime        hallway_Nest_lastconnect        "Last Connect [%s]"                  <time>                                                       { channel="nest:smoke_detector:halway:last_connection" }


	Frame label="Nest Protect" {
		Text item=hallway_Nest_battery
		Text item=hallway_Nest_smoke		
        Text item=hallway_Nest_co 
		Text item=hallway_Nest_lastconnect

In PaperUI, under config of the nest smoke alarm thing, it only shows battery, smoke and co as options to link to items. I tried manually just entering the channel in the items file above anyway (eg: { channel=“nest:smoke_detector:halway:last_connection” } ) but this does not display any date / time.

Any ideas?

The last_connection channel is only available since OH 2.3.0-snapshot.

Also there is an issue in OH that new channels do not automatically get added to existing Things. A workaround is to delete and add the Thing again.

1 Like

Hey All,

I have my Nest account online but the thermostat offline. i read all the replies above where it’s mentioned that the read/write Thermostat permission v6 will solve the issue. but it’s not working. every time i changed the set temperature in /nest Thermostat i got a lot of error messages on OH logs.

Can please someone advise what i still missing? Noting that the Thermostat has been automatically discovered once i linked my Nest account in OH paper UI.

Thank you in advance,.

The recent openHAB 2.3.0-SNAPSHOT builds (#1230 or newer) now support units (see announcement). So it now possible to use the updated Nest Binding (PR #3150) that natively supports Fahrenheit temperature values.

Here is a org.openhab.binding.nest-2.3.0-SNAPSHOT.jar for people who want to help testing this PR.

You’ll also need to update your Nest temperature item definitions. See the updated README for some examples.

What kind of error messages do your logs show? I’ve made a fix in the updated Nest Binding (see text above) so it can handle missing values due to missing permissions or older API versions. Any missing values will now be updated to null instead of throwing exceptions.