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

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

Seems there’s another property for that indeed! It’s easy to get lost in so many properties. :crazy_face: 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!

1 Like

There is a PR now!

1 Like

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

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

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

You seem like a good candidate to test the workaround fix in this Pull Request! :slight_smile:

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!

1 Like

I have good news and bad news :slight_smile:

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! :grimacing:

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

Cheers!

1 Like

That was indeed the issue, I think it was on v4 from an old integration. I updated the permissions and it now works fine.

1 Like

Hi,

Same here, nest structure, account and thermostat goes offline.
I can control Nest itself with android app, so it can send / receive data.
After I restart Openhab, nest is online in Things meniu again, after arround 3,5 h it went offline again.
Now it happens when i switched my routers, with the old one as I remember it was always online.

Can’t enable log as you wrote, maybe doing it not in the right place, see:
image

Did you also test with openHAB 2.2.0 that got released today @Justas?

Some additional bug fixes were merged just before the openHAB 2.2.0 release was made. Time will tell if they solve all connection issues.

The old (1.x) binding was using a polling mechanism (max 1 update per minute due to Nest API rate limits) whereas the new binding is now using Server-sent Events (SSE). So you should instantly have the data when it is sent by your devices to Nest. Especially with a fire/smoke alarm that can make a big difference (when it works ofcourse :roll_eyes:).

The Jersey library used by the binding for SSE seems to have some issues when connections disconnect for which a workaround was created.

Those commands are executed in the Console. :slight_smile:

I’ve created another org.openhab.binding.nest-2.2.0-fahrenheit.jar with all the features and fixes as in the final openHAB 2.2.0 release but using Fahrenheit instead of Celsius.

The code is in the same nest-fahrenheit branch on GitHub.

3 Likes

I was just about to ask about this. Thanks!!