This project is read-only.

About Adapters and Views

Mar 21, 2014 at 1:49 AM

I am working on adding some functionality in the Platform. I was hoping that there would be an interface of Platform.cs and adding one/two functions would be really simple. But it looks like the platform code is inter-wined with Adapters and Views, specially when a module tries to access a function of the platform. What is the purpose of Adapters, Views, C2V, and V2C?

Thank you.
Mar 21, 2014 at 5:27 AM

Hi, Munir –

Adapters, Views, etc. are enforcing strict interfaces between modules (drivers and apps) and between modules and platform. This is needed to get a viable plug-in model. Gory details here:

What functionality are you trying to add? More importantly, where will it be invoked from?

- If it will be invoked from a module, then you do need to extend the Contract and Adapter. This should be straightforward if you are only passing and returning simple data types. Follow the examples, and let me know if you hit a roadblock.

- If it is will be invoked from someplace else (Scouts, within-Platform), then you don’t need to do that.


Mar 21, 2014 at 5:06 PM
Hi Ratul,

Thanks for the quick reply! The URL you gave is very helpful.

I am trying to add some checking that will enable detection and resolution of the conflicts when multiple apps try to access the same Z-wave device. The checking will be invoked from Common\ModuleBase.cs, where before the Invoke() operation we will do the checking.

I have extended the Contract and Adapter. I have checked that we can successfully send the necessary parameters to the Platform, where we will instantiate an object of our class which will do the checking.

Mar 22, 2014 at 12:37 AM

Glad you got that working.

What you are doing sounds interesting, and generally useful. So, I am curious: Who keeps state about which apps are trying to access a device?


Mar 26, 2014 at 1:54 AM

maybe the module I'm trying to develop in a forked repository can help? :
...this solution is right now situated in Hub\Platform\EnvironmentMonitor for dealing with unsteady situations in home environment.

The detection checking of multiple access to the given module could be as simple as writting another implementation of IValidator interface here. The only thing to improve is that right now it keeps states about apps in a loop (another thread is ran when Platform starts) and checks it periodically - maybe better would be raising an event if sth is taking for the module...

What do you think about that? Maybe there is a moment to commit it to the main repo?

Mar 27, 2014 at 5:09 AM
Hi Ratul,

We are writing a new class, say, Conflict Resolver (CR) which will keep track of these. CR will maintain a queue for each device. Each queue will contain all the current requests from apps for this device. CR will access app priority. CR will resolve conflicts by considering requests from other apps in the queue and then grant/deny control request accordingly. There will be an instance of CR object in the Platform.

Mar 27, 2014 at 6:38 AM

Munir –

Can you give an example of how this will work in a concrete context?

I am confused because the requests will not stay in the queue for long for you to detect conflicts (if I understand your method correctly). Say two apps, one of which wants the light to be on and another off. This request is processed pretty quickly, and you might never see the off and on requests simultaneously in the queue. How will you detect this conflict?


Mar 27, 2014 at 6:57 AM
Hi Ratul,

Our solution is not finalized yet. We are working on it.

For the example scenario you gave, to resolve such conflict we need additional metadata from the apps. We are going to exploit additional metadata for resolving such conflicts.

One such meta-data may be whether the app wants to maintain the turn on/off event. For example, assume that a security app turns on a light at 8 PM and turns it off at 9 PM to discourage burglary. It will notify that the 8 PM event needs to be continued (we will keep this request in the queue), but 9 PM event does not need to be continued (we will remove the request from the queue). Assume that an energy app turns on lights when motion is detected and turns off lights when there is no motion for 10 minutes. For this app, we need to keep both requests (on and off) in the queue. When there are multiple requests in the queue, then we may satisfy the app with the highest priority. We are investigating what additional metadata we need to understand the context and resolve the conflicts accurately.