The good news is that binding is running on my Openhab instance and controlling thermostats nicely with the SDM API. I went to start the code upload and did an mvn clean install and came across a dependency that I cannot fix…
I can put this in another conversation but it is stopping me from uploading the code for you
I’ll post here in case there is any insight.
I’ve tried many options:
Download the dependency from oracle and include manually via mvn install:fileinstall… mvn addition to the POM. No matter what I try this dependency does not get resolved. So any insight is appreciated.
ERROR] Failed to execute goal org.apache.karaf.tooling:karaf-maven-plugin:4.2.7:verify (karaf-feature-verification) on project org.openhab.binding.nestdeviceaccess: Feature resolution failed for [openhab-binding-nestdeviceaccess/2.5.5.SNAPSHOT]
[ERROR] Message: Unable to resolve root: missing requirement [root] osgi.identity; osgi.identity=openhab-binding-nestdeviceaccess; type=karaf.feature; version=2.5.5.SNAPSHOT; filter:="(&(osgi.identity=openhab-binding-nestdeviceaccess)(type=karaf.feature)(version>=2.5.5.SNAPSHOT))" [caused by: Unable to resolve openhab-binding-nestdeviceaccess/2.5.5.SNAPSHOT: missing requirement [openhab-binding-nestdeviceaccess/2.5.5.SNAPSHOT] osgi.identity; osgi.identity=org.openhab.binding.nestdeviceaccess; type=osgi.bundle; version="[2.5.5.202010220052,2.5.5.202010220052]"; resolution:=mandatory [caused by: Unable to resolve org.openhab.binding.nestdeviceaccess/2.5.5.202010220052: missing requirement [org.openhab.binding.nestdeviceaccess/2.5.5.202010220052] osgi.wiring.package; filter:="(osgi.wiring.package=com.sun.jndi.dns)"]]
That package is probably a dependency of a Maven dependency you’ve added. If the classes in that package are unused you can make it optional by adding an optional import for it with a <bnd.importpackage> property (see this example). Sometimes you have to add multiple. If it is not an optional dependency you need to add a compile dependency for that transitive dependency in the pom.xml of the binding. That way it will also be embedded into the binding.
When the dependency can be replaced with an existing openHAB dependency it would be even better because that would reduce the bundle size and prevent issues like these.
I can also have a look at it after you’ve pushed the code to GitHub. Then I’ll refactor the existing Nest Binding so it can use both APIs and add your code to it.
Google Assistant has started asking me if I want to set my home to “Away” when I leave the house. Will we be able to access the GA home/away status in openHAB? That might be valuable for presence detection.
You are awesome… Thanks for the tip… I’m surprised about the amount of dependencies that I had to skip due to them not being used… I was able to do a successful mvn clean install with adding the optional resolutions in the pom file.
I also have a single jar file with dependencies added that works… I’ll add both of those here…
I’ve updated the readme file with instructions for the binding. The biggest thing is that people can use my sandbox project or create their own via the Google Nest Device Access documents if they prefer to have their own project. If you use my project, it will say it is a development project and not signed. i.e. Proceed at your own risk. The binding will work across any project by updating the nestdeviceaccess.cfg file in the code link above (Put it in your services/cfg location)
Thanks a lot for your work and investigations @BHigg! I will start refactoring/adding it to the existing Nest Binding. Maybe I can also find a way to reduce the number of dependencies because it has a lot now.
Sorry to hear that you had issues… The Activate method is used to retrieve configuration information from Karaf for the binding. The configuration is used to perform discovery. Since the error is NULL, it is more than likely caused because the properties don’t exist in Karaf. You will need to copy the nestdeviceaccess.cfg file into the services directory. On Unix it is /etc/openhab2/services. Once you do that, the openhab log will show that it processed configs… You can check the properties in Karaf via “openhab-cli console” using the following command:
At minimum you should have:
projectId
clientId
secretId
and
authorizationToken or refreshToken
Once those exist, discovery should work. Let me know if that helps…
BTW, I will need to check configuration via paperUI for “nestdeviceaccess” and whether that is working as I had originally planned that the configurations would come from nestdeviceaccess.cfg file in karaf. I’ll do that later today and see if it needs a code update.
It seems to no recognize the binding because in the consolle it is not green highligthed, for example if I put in config:list “(service.pid=org.openhab.ephemeris)” it became green.
Maybe I need to install also the “old” binding from paper UI?
Of course my nestdeviceaccess.cfg is on \OHInstallDIR\conf\services\ and I put the needed info such as projectID, clientID, clienSecret and refreshToken
I would verify why services is not picking up the cfg file and updating karaf appropriately.
As an alternative, you can update karaf manually. However, the cfg file is supposed to do this… Here are the manual updates:
config:delete org.openhab.nestdeviceaccess
config:edit org.openhab.nestdeviceaccess
config:property-append projectId projectId value
config:property-append clientId clientId value
config:property-append clientSecret clientSecret
config:property-append authorizationToken authorizationToken or blank if using refreshToken
config:property-append refreshToken refreshToken or blank if using authorizationToken
config:update
Note: For a blank value, you can use “” simply… i.e. config:property-append authorizationToken “”
You should now see the configuration in Karaf via
config:list “(service.pid=org.openhab.nestdeviceaccess)”
Hope that helps… I would like to know what the CFG file didn’t update automatically. I’ve tested this under ubuntu 20.4 LTS and placing nestdeviceaccess.cfg in the /etc/openhab2/services directory. I don’t have a windows instance unfortunately to test against.
Hi @BHigg,
to avoid messing up with my production system, I just deployed a new quick installation (OH2.5.10)
Found why the prevoius “config:list…” command was not working… was my fault because of wrong quotes. This is to confirm the nestdeviceaccess.cfg is read correctly by binding, now in the console I can see may project data (xxx = data removed for privacy)!
Going back to hopenhab.log I got more or less the same errors as previous posts, I put here the full log after configuring the binding and a clean start of OH:
2020-10-27 16:18:28.589 [WARN ] [g.eclipse.smarthome.core.net.NetUtil] - Found multiple local interfaces - ignoring 10.242.2.2
2020-10-27 16:18:29.536 [WARN ] [g.eclipse.smarthome.core.net.NetUtil] - Found multiple local interfaces - ignoring 10.242.2.2
2020-10-27 16:18:31.595 [INFO ] [thome.model.lsp.internal.ModelServer] - Started Language Server Protocol (LSP) service on port 5007
2020-10-27 16:18:31.908 [INFO ] [.dashboard.internal.DashboardService] - Started Dashboard at http://192.168.1.204:8080
2020-10-27 16:18:31.908 [INFO ] [.dashboard.internal.DashboardService] - Started Dashboard at https://192.168.1.204:8443
2020-10-27 16:18:31.917 [INFO ] [ernal.nestdeviceaccessHandlerFactory] - supportsThingType reporting nestdeviceaccess:nest-device-thermostat
2020-10-27 16:18:31.918 [INFO ] [ernal.nestdeviceaccessHandlerFactory] - supportsThingType reporting nestdeviceaccess:nest-device-access
2020-10-27 16:18:31.938 [INFO ] [ernal.nestdeviceaccessHandlerFactory] - supportsThingType reporting nestdeviceaccess:nest-device-thermostat
2020-10-27 16:18:31.938 [INFO ] [ernal.nestdeviceaccessHandlerFactory] - createHandler reporting nestdeviceaccess:nest-device-thermostat
2020-10-27 16:18:31.973 [INFO ] [ernal.nestdeviceaccessHandlerFactory] - supportsThingType reporting nestdeviceaccess:nest-device-access
2020-10-27 16:18:31.973 [INFO ] [nal.thermostat.NestThermostatHandler] - refreshChannels process a timer for Updating thing Channels for:nestdeviceaccess:nest-device-thermostat:56a76a29
2020-10-27 16:18:31.973 [INFO ] [ernal.nestdeviceaccessHandlerFactory] - createHandler reporting nestdeviceaccess:nest-device-access
2020-10-27 16:18:31.979 [ERROR] [nal.common.AbstractInvocationHandler] - An error occurred while calling method 'ThingHandler.initialize()' on 'org.openhab.binding.nestdeviceaccess.internal.nestdeviceaccessHandler@5ad8a642': null
java.lang.NullPointerException: null
at org.openhab.binding.nestdeviceaccess.internal.nestdeviceaccessHandler.initialize(nestdeviceaccessHandler.java:65) ~[?:?]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_271]
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) ~[?:1.8.0_271]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) ~[?:1.8.0_271]
at java.lang.reflect.Method.invoke(Unknown Source) ~[?:1.8.0_271]
at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:152) [bundleFile:?]
at org.eclipse.smarthome.core.internal.common.Invocation.call(Invocation.java:52) [bundleFile:?]
at java.util.concurrent.FutureTask.run(Unknown Source) [?:1.8.0_271]
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) [?:1.8.0_271]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) [?:1.8.0_271]
at java.lang.Thread.run(Unknown Source) [?:1.8.0_271]
2020-10-27 16:18:31.984 [ERROR] [core.thing.internal.ThingManagerImpl] - Exception occurred while initializing handler of thing 'nestdeviceaccess:nest-device-access:c5ff4c2d': null
java.lang.NullPointerException: null
at org.openhab.binding.nestdeviceaccess.internal.nestdeviceaccessHandler.initialize(nestdeviceaccessHandler.java:65) ~[?:?]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_271]
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) ~[?:1.8.0_271]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) ~[?:1.8.0_271]
at java.lang.reflect.Method.invoke(Unknown Source) ~[?:1.8.0_271]
at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:152) [bundleFile:?]
at org.eclipse.smarthome.core.internal.common.Invocation.call(Invocation.java:52) [bundleFile:?]
at java.util.concurrent.FutureTask.run(Unknown Source) [?:1.8.0_271]
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) [?:1.8.0_271]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) [?:1.8.0_271]
at java.lang.Thread.run(Unknown Source) [?:1.8.0_271]
2020-10-27 16:18:32.114 [INFO ] [ui.habmin.internal.servlet.HABminApp] - Started HABmin servlet at /habmin
2020-10-27 16:18:32.138 [INFO ] [panel.internal.HABPanelDashboardTile] - Started HABPanel at /habpanel
2020-10-27 16:18:32.160 [INFO ] [openhab.ui.paper.internal.PaperUIApp] - Started Paper UI at /paperui
2020-10-27 16:18:32.951 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception:
java.lang.NullPointerException: null
at com.google.common.base.Preconditions.checkNotNull(Preconditions.java:878) ~[?:?]
at com.google.api.client.util.Preconditions.checkNotNull(Preconditions.java:125) ~[?:?]
at com.google.api.client.auth.oauth2.RefreshTokenRequest.setRefreshToken(RefreshTokenRequest.java:142) ~[?:?]
at com.google.api.client.googleapis.auth.oauth2.GoogleRefreshTokenRequest.setRefreshToken(GoogleRefreshTokenRequest.java:119) ~[?:?]
at com.google.api.client.googleapis.auth.oauth2.GoogleRefreshTokenRequest.setRefreshToken(GoogleRefreshTokenRequest.java:74) ~[?:?]
at com.google.api.client.auth.oauth2.RefreshTokenRequest.<init>(RefreshTokenRequest.java:95) ~[?:?]
at com.google.api.client.googleapis.auth.oauth2.GoogleRefreshTokenRequest.<init>(GoogleRefreshTokenRequest.java:85) ~[?:?]
at org.openhab.binding.nestdeviceaccess.internal.nesthelper.NestUtility.refreshAccessToken(NestUtility.java:143) ~[?:?]
at org.openhab.binding.nestdeviceaccess.internal.nesthelper.NestUtility.getDeviceInfo(NestUtility.java:129) ~[?:?]
at org.openhab.binding.nestdeviceaccess.internal.thermostat.NestThermostat.getThermostatInfo(NestThermostat.java:349) ~[?:?]
at org.openhab.binding.nestdeviceaccess.internal.thermostat.NestThermostatHandler.refreshChannels(NestThermostatHandler.java:119) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) ~[?:1.8.0_271]
at java.util.concurrent.FutureTask.runAndReset(Unknown Source) ~[?:1.8.0_271]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(Unknown Source) ~[?:1.8.0_271]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown Source) ~[?:1.8.0_271]
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) [?:1.8.0_271]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) [?:1.8.0_271]
at java.lang.Thread.run(Unknown Source) [?:1.8.0_271]
I’ve migrated my Nest account already months ago, without thinking too much about it and assuming the devices would be supported by Google Home and the Device Access API.
Unfortunately Google refuses to migrate my account back to a legacy Nest account, so no API support for now.
There is some hope, because the Protects were added (in an incomplete form) to Google Home a while back and removed again. So I guess they are working on it.
For me it is a reminder to never ever rely on anything which is only cloud based. There MUST be a way to control things with no internet connection is present.
As for replacing my Nest Protects I am looking at Shelly https://shelly.cloud/products/shelly-smoke-smart-home-automation-sensor/ Their TLD is .cloud, but the devices do work locally as well and you can even flash your own firmware (maybe for the smoke detector will be limited because of safety regulations)
Great to hear! Sounds like we solved one problem and found another… Looking at the log, it looks like there are thermostats that were discovered and added. However, the nestdeviceaccess handler is finding a thing not a thermostat (At least from the log read.) The error occurs when the nestdeviceaccessHandler tries to read a configuration property from the generic thing. I think you may need to delete the “nestdeviceaccess” thing that was created during troubleshooting because it is not required when you run discovery.
Can you confirm that you don’t have a thing called “Nest Device Access”?
Here is why I called this out from the log: supportsThingType reporting nestdeviceaccess:nest-device-access
vs
supportsThingType reporting nestdeviceaccess:nest-device-thermostat
I was actually able to reproduce this by adding a manual “Nest Device Access” which is unnecessary because of the discovery process… I may add code to fix this… LMK if this is your issue or not. Thanks
Correct… I don’t know why Nest Protects were excluded from the traits. I would have gladly added this to the binding because I have a few as well… In the same boat with you… For now, there is a binding here that can get you going on your Nest thermostats if you have them… On the Nest protect note, I don’t understand why the traits were excluded… The Nest Protects are the simplest devices to program/control
I will start refactoring/adding it to the existing Nest Binding. Maybe I can also find a way to reduce the number of dependencies because it has a lot now. 
