Can I spawn some independent child devices?


(Yves Racine) #1

Hello,

I’ve read the few lines of documentation under:

http://docs.smartthings.com/en/latest/cloud-and-lan-connected-device-types-developers-guide/building-cloud-connected-device-types/building-the-service-manager.html?highlight=createaccesstoken#cloud-connected-device-types-building-the-service-manager

And I have the following question:

Can I create some child devices that can manage their authentication tokens themselves?

As per the ecobee connect (smartapp) example, I can see that the smartapp (service manager) handles all the authentication tokens (and more) for its children (device type).

For a given device type (such as my ecobee custom device type, see https://github.com/yracine/device-type.myecobee), I’d rather leave that to the child device so that it becomes a fully independent & autonomous device handler. As such, the device handler’s code would be self-contained. This may
allow also the child devices to be spawn under different accounts, which, in my case,
would be ideal as each ecobee user is granted a limited number of transactions (queries/updates) per
month.

In brief, the service manager would spawn the child devices to the world and be done with it!!

In my book, the tight integration between the smartapp (service manager) and
the device type is not always a good software engineering approach, and a source of potential errors/issues.

Your input is appreciated.


Capability multiThreading
(swanny) #2

From what I’ve seen, I think the child devices could handle everything themselves once created as long as you don’t uninstall the SmartApp. The children will be automatically deleted if you delete the SmartApp. I can see why you would want to decouple this as much as possible for the thermostats. People don’t really add and remove them very often, so the management function is less valuable. You still may want the SmartApp to handle the case where someone needs to set up their OAuth settings or things like that.

For things like the Hue Connect or the Wireless Tags Connect that I’m working on, there is a lot more management that can happen as people add and remove new devices. You could also have the logic in the SmartApp and share it between multiple related device types that can be children.

In the Wireless Tags integration I’m working on, I have about 900 lines in the SmartApp and 2 Device Types that have about 100-175 lines. The two Device Types have 70% the same functionality, so it’s a lot less maintenance having most of the code in the SmartApp. In normal software engineering practices, you would have all this code in a separate library, but this way works nicely in the current ST architecture.

My 2 cents…


(Yves Racine) #3

Hi Swanny, thnx for your input. However, I understand that SmartThings will be adding local capabilities soon in the next hub (hardware) version.

So, I think it would be beneficial that SmartThings allows a looser decoupling between the service manager (parent in the cloud) and its child devices (may be spawn at the local level).

What do you think?

This is an architecture question that needs to be addressed soon (preferably) or later…

My 2 cents.


(swanny) #4

The hub v2 question and local processing is a good one. It would help us to build for the longer term to understand how the processing might work between remote and local. It doesn’t seem like just devices local and SmartApps remote would allow for much automation in the local processing. The way it is now, so much intelligence of the “Smart Home” is already in the SmartApps.

@Ben, is there any information you can give that would help us architect our code better for the hub v2 world?


(Ben Edwards) #5

I don’t have much yet because much is still in flux.


(swanny) #6

Ok, thanks. We’ll do our best with what we know now. :smile:


(Yves Racine) #7

@Ben, based on this thread, I think that our input could be helpful for the hub V2’s architecture. How can we be involved?

Thnx.


(Yves Racine) #8

@Ben, hello,

Like I wrote to you at the developers’ discussion yesterday, I strongly believe that the service manager’s design is flawed: its coupling with its spawned child devices is too tight and this is not a good OO engineering practice.

This causes robustness and reliability issues for many device types out there. For example, many ecobee users prefer to use my custom ecobee device than the ST stock for that reason.

The service manager should follow OO patterns like Inversion of Control and the Factory patterns. This should be taken into account for the hub v2.x or 3.x architecture, especially for local processing.

In my books, a device handler (device type) should be a self contained object with no dependencies to other objects.

I’m available to get into some architecture sessions with you guys… Cheers.


(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy) #9

Yves – I clicked “Like <3” because I like the sound of what you are pointing out … but, honestly, I don’t really understand the details.

I have some OO knowledge (obviously need some in order to do even basic SmartThings development), but not enough experience or education to know the best practices or the Patterns you reference.

I’d like to learn more. Maybe we can spawn a thread or you could give other references and examples?

Thanks!
…CP (Terry)


(Yves Racine) #10

Hello tgauchat,

Please refer to http://en.wikipedia.org/wiki/Factory_(object-oriented_programming) for more details
about object factory pattern.

Inversion of Control is described also here:

http://www.codeproject.com/Articles/380748/Inversion-of-Control-Overview-with-Examples

Regards.


(Yves Racine) #11

@Ben, @urman, @swanny

Hi guys,

After some trials and errors, I created a new Service Manager that allows better decoupling between
a parent and its child Device types (device handlers). The service manager then doesn’t
need to maintain its child devices’ states and be involved in their daily operations.

This design could be useful in the new Hub V2 architecture as the parent could run in the cloud while its child devices could run locally.

This new Service Manager’s design provides better performance and reliability as a device handler (device type) should not rely on any other objects for generating and processing events (in my book).

Finally, I must also give credits to the original ST Service Manager’s authors (Scott and JLH) , swanny and another follow developer named Kevin Lewis for their Service Manager work that inspired me for this code.

Happy Thanksgiving to all!


(swanny) #12

Very cool! I’ll upgrade to the new version soon.