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

Thought the same . . .just don;t want to set to 24 . . then OH crashes and I burn gas at an unprecedented rate :slight_smile:
Should work well enough though - thanks.

Are you then letting Nest handle home / away?

I have some weird behavior going on with this binding. I was using the old binding which would give you a mode of “heat” or “cool” etc.

This new binding seemingly does the same thing, but when I try to display the mode in the basic ui i get “heating” rather than “heat”

REST shows that it’s “HEAT” and the log shows it as “HEAT” as well, but in the UI its “heating”

Text item=NestTStat_HVAC_Mode

basic

any ideas why this might be?

You are using the wrong “thing”. You are looking at the current status of
the HVAC (is is heating, cooling, off etc) and not the mode setting (HEAT,
COOL, ECO, etc).

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. :slight_smile:

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:

  • #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 ] [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”:
Untitled 2

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

Untitled 3

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

@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(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?

Opciones para desarrollar apps  |  Google Home Developers

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 :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?