# Next Developer Call will be on 04/08/2015 - Guest : Jeff Hagins

**URL:** <https://community.smartthings.com/t/next-developer-call-will-be-on-04-08-2015-guest-jeff-hagins/13938>\
**Category:** Groups & Events\
**Tags:** developer\_discussion\
**Created:** [April 6, 2015, 9:05pm UTC](https://community.smartthings.com/t/next-developer-call-will-be-on-04-08-2015-guest-jeff-hagins/13938 "2015-04-06T21:05:40Z")\
**Posts on this page:** 1\
**Showing post:** 22

<div class="post-metadata">

**Author:** ![yvesracine](https://yyz2.discourse-cdn.com/smartthings/user_avatar/community.smartthings.com/yvesracine/32/95271_2.png) [@yvesracine](https://community.smartthings.com/u/yvesracine)\
**Post date:** [April 8, 2015, 12:15pm UTC](https://community.smartthings.com/t/next-developer-call-will-be-on-04-08-2015-guest-jeff-hagins/13938/22 "2015-04-08T12:15:36Z")

</div>

Hello @April,

I have another question for Jeff Hagins about the hybrid cloud/hub architecture that will be put in place for Hub V2:

- It was said that all devices except those with cloud-to-cloud integration will run locally in hub V2.

But, what about the Nest or Ecobee thermostats (or any other wi-fi thermostats) that also require local processing to be more responsive and reliable? Any thermostat should be able to run locally as much as possible to avoid unnecessary delays/errors in processing commands.

The way I coded my custom Ecobee device would allow some local processing: I decoupled the  
service manager (smartapp) as much as possible from the device type (or device controller). Actually, the child devices (device controller) only use the parent (service manager) to refresh their tokens when they expire once the child devices are instantiated.

So, in theory, the child devices that I coded should be able to run in the hub V2 as much as possible and eventually use the cloud only as a proxy for processing their requests.

That way, the hybrid architecture would be best used and we’ll get better availability, responsiveness, robustness and reliability even for cloud-to-cloud integrated devices.

See my code at github as reference:

[https://github.com/yracine/device-type.myecobee/blob/master/ecobee.devicetype.groovy](https://github.com/yracine/device-type.myecobee/blob/master/ecobee.devicetype.groovy)

P.S. That’s why I was asking for non-functional capabilities in some threads such as:

> [@Capability localProcessing](http://community.smartthings.com/t/capability-localprocessing/11778):
>
> One capability that would be useful is local processing (with Hub V2). It would identify local processing needs for a device type. Its core attribute could be “true” or “false”. Of course, there would be other attributes and methods related this capability such as : percentLocal (desired local processing percentage) emergencyIndicator: indicate if device type’s local processing is required when emergency situation arises (ex. smoke/CO2 alerts,power outage) This would allow ST to better control these types of devices… Regards.

> [@Capability multiThreading](http://community.smartthings.com/t/capability-multithreading/11777/24):
>
> @JDRoberts Also, I’d say that some of my z-wave devices (locks and thermostats for example) would also benefit from non functional capabilities… I don’t know why exactly there are so much performance lags, but I think that just relying on the 4 OSI layers (up to transport) for performance improvement is not enough.

Regards,

---

_[View the full topic](https://community.smartthings.com/t/next-developer-call-will-be-on-04-08-2015-guest-jeff-hagins/13938)._