OH3 Smartthings binding - error with Nest Protect

I have my old Smartthings v2 hub working with Openhabian OH3 using the Smartthings binding - except I can’t quite get the Nest Protects to work.

My use case is to leave the 3x Nest Protects on the Smarthings Hub because that is the only way I can carry on using them (they are on the old NEST API which I cannot renew or transfer, and I don’t want to “upgrade” to a Google account for them.)

I have done some troubleshooting and found this from the logs. Please note the three events from the Nest Protect are:

  • 15:57:33 simulated smoke alarm
  • 16:00:33 smoke alarm stops
  • 16:30:33 Low battery warning
    I’ve only included the lines from the Smartthings Openhab log and Openhabian log associated with the Nest Protect.

So the Smartthings hub is communicating with Openhabian but results in the error message

“Nest_Protect_-_Kitchen tried updating channel smoke although the handler was already disposed.”

Any ideas how to fix this?

Smartthings Nest Protect log
d8b16768-0c61-4a42-a492-0767ce7bb7a8 4:30:33 PM: debug Nest Protect - Kitchen (v5.4.3) | UI Color is: (yellow) | Original State: (green)
d8b16768-0c61-4a42-a492-0767ce7bb7a8 4:30:33 PM: debug Nest Protect - Kitchen (v5.4.3) | Battery is: replace | Original State: (ok)
d8b16768-0c61-4a42-a492-0767ce7bb7a8 4:00:33 PM: debug Nest Protect - Kitchen (v5.4.3) | UI Color is: (green) | Original State: (red)
d8b16768-0c61-4a42-a492-0767ce7bb7a8 4:00:33 PM: debug Nest Protect - Kitchen (v5.4.3) | Nest Smoke State is: (OK) | Original State: (EMERGENCY)
d8b16768-0c61-4a42-a492-0767ce7bb7a8 3:57:33 PM: debug Nest Protect - Kitchen (v5.4.3) | UI Color is: (red) | Original State: (green)
d8b16768-0c61-4a42-a492-0767ce7bb7a8 3:57:33 PM: debug Nest Protect - Kitchen (v5.4.3) | Nest Smoke State is: (EMERGENCY) | Original State: (OK)
d8b16768-0c61-4a42-a492-0767ce7bb7a8 3:51:33 PM: debug Nest Protect - Kitchen (v5.4.3) | UPDATED | Last Manual Test was: (Feb 14, 2021 - 3:49:49 PM) | Original State: (Feb 4, 2021 - 11:45:09 AM)

Smartthings Openhab device log

cc718981-b137-4015-9f0c-7ae96e73397d 4:30:33 PM: debug Sending ‘{“path”:"/smartthings/state",“body”:{“deviceDisplayName”:“Nest Protect - Kitchen”,“value”:“5”,“capabilityAttribute”:“battery”}}’ to 10.0.0.60:8080 with mac: B8:27:EB:6D:17:10

cc718981-b137-4015-9f0c-7ae96e73397d 4:00:33 PM: debug Sending ‘{“path”:"/smartthings/state",“body”:{“deviceDisplayName”:“Nest Protect - Kitchen”,“value”:“clear”,“capabilityAttribute”:“smoke”}}’ to 10.0.0.60:8080 with mac: B8:27:EB:6D:17:10

cc718981-b137-4015-9f0c-7ae96e73397d 3:57:33 PM: debug Sending ‘{“path”:"/smartthings/state",“body”:{“deviceDisplayName”:“Nest Protect - Kitchen”,“value”:“detected”,“capabilityAttribute”:“smoke”}}’ to 10.0.0.60:8080 with mac: B8:27:EB:6D:17:10

Openhabian log

17:30:33.252 [WARN ] [b.core.thing.binding.BaseThingHandler] - Handler SmartthingsThingHandler of thing smartthings:battery:ddd5ea715e:Nest_Protect_-_Kitchen tried updating channel battery although the handler was already disposed.

17:00:33.194 [WARN ] [b.core.thing.binding.BaseThingHandler] - Handler SmartthingsThingHandler of thing smartthings:smokeDetector:ddd5ea715e:Nest_Protect_-_Kitchen tried updating channel smoke although the handler was already disposed.

16:57:33.197 [WARN ] [b.core.thing.binding.BaseThingHandler] - Handler SmartthingsThingHandler of thing smartthings:smokeDetector:ddd5ea715e:Nest_Protect_-_Kitchen tried updating channel smoke although the handler was already disposed.

I’ve seen this error before and don’t remember if I ever figured out a solution. Sorry. There are lots of other Community posts about “handler was already disposed”. I didn’t find a compelling solution but it seemed at least one person had this error when they had multiple definitions for the same device.

Question: it seems that the smartthings binding is seeing the nest products. In your Smartthings app on your phone - were you able to select your nest products in the smartthings smartApp? From your other post it looks like they were returned when you ran the discovery curl command. That make me think they should work.

I have a Nest thermostat but a while back I upgraded it to a Google account so I really can’t try to do any diagnostic myself.

I saw some of the posts and have rebooted the Smartthings hub as that worked for one person. Also some about clearing the cache. Will test again.

Not sure what you mean by ‘multiple definitions for the same device’. I each Nest Protect added to Smartthings with the NST Manager device handler and it is ‘in use by’ your OpenHabAppV2 and Action Tiles v6. In the OpenHabAppV2 settings on the Groovy IDE under Event Subscriptions, all the right channels (smoke, battery, carbonMonoxide, powerSource) are associated with an inputHandler and the OpenHabDevice is associated with openhabMessageHandler. So it looks OK to me, to the level of my knowledge (not great).

It feels like it is almost working so will persevere.

I have it working! Not that I have done anything in particular to make it happen however.

To begin with it didn’t work (reporting NULL in all fields) and I was seeing smartthings errors in the log. So I left it alone for a while and did other things. Meanwhile all the devices would have been re-booted - Nest Protects, Smatthings hub and Openhabian - while I fiddled and then I noticed that it was reporting correctly.

Persistence isn’t working but maybe that is a matter of loading a different profile. And, I was wondering if it was possible to add in some of the other Nest Protect functions to the app handlers etc? To get at things like ‘last checked’ from Openhab. That would be great but don’t know how difficult it would be to do.

More information to feedback from my troubleshooting. I had found that 2 of my 3 Nest Protects were reporting NULL for smoke and CO (although battery was being reported). I find I can reliably fix this by going into the NST Manager on the Smartthings app on my phone and simulating a smoke/carbon/low battery event. This shows up in the Smartthings log, the Openhab log and triggers Openhab to report real data.