I upgraded to the latest (synology) snapshot the other day, and since then I’ve had my three nest things (home, account, thermostat) going off-line at regular intervals. They come back online if I go into the edit mode of the thing using paperUI and re-save (without changing anything).
Any ideas for how I could stop this happening please?
Does anyone have a working .jar they can share? The latest build on cloud bees (180) doesn’t seem to work “Bridge handler error”.
I’d like to give this a try.
Thanks.
I just upgraded my OH to 2.2 release.
Apparently, with this release new Nest binding is required.
I managed to connect and configure my Nest via PaperUI. However, my preference is to have the configs in .items and .things files (for simple management and backup options)
Unfortunately, I can’t find anywhere instructions how to do that.
Could you please help me with the instructions?
Yes there is a readme with examples for that:
http://docs.openhab.org/addons/bindings/nest/readme.html#full-example
We also have the away channel and I can set my away status, I just tested it. This is maybe something different then telling when you are on your way home, so I don’t know what you need.
Is there a way to monitor main heating relay is on/off?
@wborn - It looks like the “hvac_state” item is used for this - I’ve tried adding this as an Item (I too prefer an .items file for my config) but not getting any value come through.
If you could update the binding to include this, it’d be great 
Seems there’s another property for that indeed! It’s easy to get lost in so many properties. 
According to the code the binding already receives the data but doesn’t create a channel for it yet. I’ll create a PR for that!
There is a PR now!
Brilliant, thanks for the quick turnaround, as well as @martinvw for accepting the PR so quickly too!
Hello, i have it up and running. I see my outdoor cam thing online. It happens that i only see 3 channels available:Streaming WebUrl and PublicShareUrl
in the wiki i see that it should be even some kind of snapshot url available.
By the way i am not able to see any image or video in sitemap using the weburl provided
EDIT:
The snapshot channel is not discovered but adding it manually in items file get it working
String Cam_Snapshot_URL "Snapshot URL [%s]" { channel="nest:camera:demo_account:fish_cam:snapshot_url" }
EDIT 2: It was present, it’s hidden and must select show more as there are many channels available
sorry to bother 
Hello, I just tried the Nest v2 binding with the latest snapshot, build 1119. I am able to create a Nest things file and I can get the things for account, structure, and Protect working just fine, but the thermostats seem to all fail. This happens whether I use discovery or not. I get the following exception repeatedly in the log:
2017-12-08 19:24:40.183 [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:53) ~[?:?]
at org.openhab.binding.nest.handler.NestThermostatHandler.getChannelState(NestThermostatHandler.java:1) ~[?:?]
at org.openhab.binding.nest.handler.NestBaseHandler.lambda$0(NestBaseHandler.java:131) ~[?:?]
at java.lang.Iterable.forEach(Iterable.java:75) ~[?:?]
at org.openhab.binding.nest.handler.NestBaseHandler.updateChannels(NestBaseHandler.java:131) ~[?:?]
at org.openhab.binding.nest.handler.NestThermostatHandler.onNewNestThermostatData(NestThermostatHandler.java:155) ~[?:?]
at java.lang.Iterable.forEach(Iterable.java:75) ~[?:?]
at org.openhab.binding.nest.handler.NestBridgeHandler.broadcastDevices(NestBridgeHandler.java:211) ~[?:?]
at org.openhab.binding.nest.handler.NestBridgeHandler.lambda$0(NestBridgeHandler.java:206) ~[?:?]
at java.util.concurrent.CopyOnWriteArrayList.forEach(CopyOnWriteArrayList.java:891) ~[?:?]
at org.openhab.binding.nest.handler.NestBridgeHandler.broadcastDevices(NestBridgeHandler.java:206) ~[?:?]
at org.openhab.binding.nest.handler.NestBridgeHandler.onNewTopLevelData(NestBridgeHandler.java:428) ~[?:?]
at org.openhab.binding.nest.internal.rest.NestStreamingRestClient.lambda$4(NestStreamingRestClient.java:157) ~[?:?]
at java.util.concurrent.CopyOnWriteArrayList.forEach(CopyOnWriteArrayList.java:891) ~[?:?]
at org.openhab.binding.nest.internal.rest.NestStreamingRestClient.onEvent(NestStreamingRestClient.java:157) ~[?:?]
at org.glassfish.jersey.media.sse.EventSource$EventProcessor.notify(EventSource.java:687) [182:org.glassfish.jersey.media.jersey-media-sse:2.22.2]
at org.glassfish.jersey.media.sse.EventSource$EventProcessor.notify(EventSource.java:681) [182:org.glassfish.jersey.media.jersey-media-sse:2.22.2]
at org.glassfish.jersey.media.sse.EventSource$EventProcessor.onEvent(EventSource.java:668) [182:org.glassfish.jersey.media.jersey-media-sse:2.22.2]
at org.glassfish.jersey.media.sse.EventSource$EventProcessor.run(EventSource.java:614) [182: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) [?:?]
Is this a known issue? Is anyone else able to get thermostats working on the latest build?
Mine works just fine. The NPE seems to occur because your Thermostat returns a null value for “fan timer duration”.
Do you also have the “Thermostat read/write v6” permission enabled in your Product in the Nest developer account? I can imagine when the version is lower than v6 it could miss some properties.
Over the last couple of days my binding keeps going offline, and I see this in events.log:
2017-12-10 14:28:44.804 [hingStatusInfoChangedEvent] - 'nest:account:abcdef01' changed from ONLINE: Receiving streaming data to OFFLINE (COMMUNICATION_ERROR): Streaming data disconnected
2017-12-10 14:28:44.809 [hingStatusInfoChangedEvent] - 'nest:thermostat:012345670:xxxxxxxxxxxxxxxxxxxxxxx-xxxxxxxx' changed from ONLINE to OFFLINE (BRIDGE_OFFLINE)
2017-12-10 14:28:44.810 [hingStatusInfoChangedEvent] - 'nest:structure:01abcd23:-xxxxxxxxxxxxxxxxxx_xxxx_xxxxxxxxxx-xxxxxxxxxxxxxxxxx' changed from ONLINE to OFFLINE (BRIDGE_OFFLINE)
.
.
.
2017-12-10 14:35:00.457 [ome.event.ItemCommandEvent] - Item 'Nest_target_temperature_c' received command 24.0
2017-12-10 14:35:00.465 [hingStatusInfoChangedEvent] - 'nest:account:abcdef01' changed from OFFLINE (COMMUNICATION_ERROR): Streaming data disconnected to OFFLINE (COMMUNICATION_ERROR): Not transmitting events because bridge is OFFLINE
The only other thing I can see from openhab.log at around that time is:
2017-12-10 14:28:11.415 [INFO ] [io.openhabcloud.internal.CloudClient] - Disconnected from the openHAB Cloud service (UUID = xxxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx, base URL = http://localhost:8080)
2017-12-10 14:28:13.377 [INFO ] [io.openhabcloud.internal.CloudClient] - Connected to the openHAB Cloud service (UUID = xxxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx, base URL = http://localhost:8080)
So - is my internet connection dropping for a fraction, which is losing connection to the Nest API?
Looks like the same kind of reconnection issues @chibbert reported in this issue:
It would be nice to have at least the workaround implemented before OH 2.2.0 is released. 
It’s happened again - but I also noticed that my Skype briefly disconnected and reconnected - so must be my internet connection at fault.
However, yes, it would be good to have it auto detecting the offline status and be able to reinitialise the connection
You seem like a good candidate to test the workaround fix in this Pull Request!
You can test the changes by first uninstalling the Nest binding.
Then adding the JAR from the pull request (remove the .zip extension so it ends with .jar) to your /addons directory
That should automatically start the Nest binding with the changes. All the Nest Things including their configuration will remain unchanged. You can revert it by just removing the .jar from the /addons dir and installing the Nest Binding as usual.
Downloaded and up and running.
Will keep an eye on it over the next day or so and report back!
Cheers!
I have good news and bad news
The good news, is overnight, I had a couple of times when the binding disconnected from Nest, and did reconnect itself.
The bad news, is that it only reconnected itself when I sent a command to it. This meant that for ~4 hours, one room was cooling down way below its target temperature, until another room cooled enough to trigger the rule which updates the Nest’s target temperature!
The other couple of times it’s logged a disconnection, due to the way my rules are configured, it is sending multiple commands, it’s gone back online immediately - the first command detects it’s offline, the 2nd command a split second later re-initiates the connection.
Thats is bad news indeed! 
What would help is if we see what is happening when the data is no longer updating. Maybe you can enable the debug logging of the Nest Binding via the Console so we can see whats happening?
You can enable debug logging in the console with the command:
log:set debug org.openhab.binding.nest
It will then log if it is connected, trying to reconnect and all received data and keep alives that Nest sends through the connection.
Disabling the debug logging is done by setting the log level back to info with:
log:set info org.openhab.binding.nest
I had just shut down laptop, but saw the email just as I was about to go up to bed so have fired it up again and have enabled the logging.
Will give it a shot overnight.
I have also added a rule running every 10 minutes to send the target temperature to the Nest - hopefully this means a maximum of 20 minutes without a proper update!
Will report back with some logging in the morning if it fails overnight again
Cheers!