Date   
Upcoming Event: EdgeX Device and Device SDK WG Meeting (Weekly) - Mon, 08/19/2019 8:00am-9:00am, Please RSVP #cal-reminder

EdgeX-TSC-Device-Services@lists.edgexfoundry.org Calendar <EdgeX-TSC-Device-Services@...>
 

Reminder: EdgeX Device and Device SDK WG Meeting (Weekly)

When: Monday, 19 August 2019, 8:00am to 9:00am, (GMT-07:00) America/Los Angeles

Where:https://zoom.us/j/314411765

An RSVP is requested. Click here to RSVP

Organizer: EdgeX-TSC-Device-Services@...

Description: EdgeX Device and Device SDK WG Meeting. Meeting content posted to Device and Device SDK WG Wiki.
Meeting Lead: Steve Osselton, Device and Device SDK WG Chair, steve@...
-----Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/314411765

Or iPhone one-tap :
    US: +16699006833,,314411765# or +16465588656,,314411765# 
Or Telephone:
    Dial(for higher quality, dial a number based on your current location): 
        US: +1 669 900 6833 or +1 646 558 8656 or +1 877 369 0926 (Toll Free) or +1 855 880 1246 (Toll Free)
    Meeting ID: 314 411 765
    International numbers available: https://zoom.us/u/dYf323vjV

Upcoming Event: EdgeX Device and Device SDK WG Meeting (Weekly) - Mon, 08/12/2019 8:00am-9:00am, Please RSVP #cal-reminder

EdgeX-TSC-Device-Services@lists.edgexfoundry.org Calendar <EdgeX-TSC-Device-Services@...>
 

Reminder: EdgeX Device and Device SDK WG Meeting (Weekly)

When: Monday, 12 August 2019, 8:00am to 9:00am, (GMT-07:00) America/Los Angeles

Where:https://zoom.us/j/314411765

An RSVP is requested. Click here to RSVP

Organizer: EdgeX-TSC-Device-Services@...

Description: EdgeX Device and Device SDK WG Meeting. Meeting content posted to Device and Device SDK WG Wiki.
Meeting Lead: Steve Osselton, Device and Device SDK WG Chair, steve@...
-----Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/314411765

Or iPhone one-tap :
    US: +16699006833,,314411765# or +16465588656,,314411765# 
Or Telephone:
    Dial(for higher quality, dial a number based on your current location): 
        US: +1 669 900 6833 or +1 646 558 8656 or +1 877 369 0926 (Toll Free) or +1 855 880 1246 (Toll Free)
    Meeting ID: 314 411 765
    International numbers available: https://zoom.us/u/dYf323vjV

Re: [EdgeX-tsc-certification] [Edgex-tsc-QA-Test] [Edgex-tsc-device-services] Prototype- Blackbox test of Device-Virtual with Robot Framework

Rodney
 

While scanning through the log and report files found in Playground_RobotFramework I stumbled across this:

/*                                                                                                                                                                                                          
    Copyright 2008-2013                                                                                                                                                                                     
        Matthias Ehmann,                                                                                                                                                                                    
        Michael Gerhaeuser,                                                                                                                                                                                 
        Carsten Miller,                                                                                                                                                                                     
        Bianca Valentin,                                                                                                                                                                                    
        Alfred Wassermann,                                                                                                                                                                                  
        Peter Wilfahrt                                                                                                                                                                                      
    Dual licensed under the Apache License Version 2.0, or LGPL Version 3 licenses.                                                                                                                         
    You should have received a copy of the GNU Lesser General Public License                                                                                                                                
    along with JSXCompressor.  If not, see <http://www.gnu.org/licenses/>.                                                                                                                                  
    You should have received a copy of the Apache License along with JSXCompressor.                                                                                                                         
    If not, see <http://www.apache.org/licenses/>.                                                                                                                                                          
*/                                                                                                                                                                                                          

Were you aware of these?

~Rodney

On Aug 8, 2019, at 12:39, Cloud Tsai <cloud@...> wrote:

Thanks for the feedback, Lenny and Jim,

I thought we could put "how to run" aside for now, and focus on whether we could define the spec in Robot file.
I believe we still need to make some development in test script to achieve the complex scenario, not only resource.robot, but also some Python script.

On Fri, 9 Aug 2019 at 00:19, Goodell, Leonard <leonard.goodell@...> wrote:

Hi Cloud,

  Great start!! I think you should also point out that all developers running/creating tests (that’s all of us 😊 ) will be required to install the robot tool chain outlined in the prerequisites here: https://github.com/FelixTing/Playground_RobotFramework/blob/master/README.md

 

Thanks!

   Lenny

 

From: EdgeX-TSC-Device-Services@... <EdgeX-TSC-Device-Services@...> On Behalf Of Cloud Tsai
Sent: Thursday, August 08, 2019 12:31 AM
To: edgex-tsc-qa-test@...; edgex-tsc-device-services@...; EdgeX-TSC-Certification@...
Subject: [Edgex-tsc-device-services] Prototype- Blackbox test of Device-Virtual with Robot Framework

 

Hi all,

 

We made a prototype of blackbox test of device-virtual using Robot.  Please help take a look whether it is appropriate.  I plan to present the attached slide in the next Certification working group meeting.  It hasn't been applied the taf structure, but it is runnable with the standard Robot framework.

https://github.com/FelixTing/Playground_RobotFramework  

 

The plan is to use robot file to define the spec (test cases) for all the services, and the test report is easy to understand by all kinds of users.

 

--

Best Regards,

Cloud Tsai





--
Best Regards,
Cloud Tsai

Re: [Edgex-tsc-QA-Test] [Edgex-tsc-device-services] Prototype- Blackbox test of Device-Virtual with Robot Framework

Cloud Tsai
 

Thanks for the feedback, Lenny and Jim,

I thought we could put "how to run" aside for now, and focus on whether we could define the spec in Robot file.
I believe we still need to make some development in test script to achieve the complex scenario, not only resource.robot, but also some Python script.

On Fri, 9 Aug 2019 at 00:19, Goodell, Leonard <leonard.goodell@...> wrote:

Hi Cloud,

  Great start!! I think you should also point out that all developers running/creating tests (that’s all of us 😊 ) will be required to install the robot tool chain outlined in the prerequisites here: https://github.com/FelixTing/Playground_RobotFramework/blob/master/README.md

 

Thanks!

   Lenny

 

From: EdgeX-TSC-Device-Services@... <EdgeX-TSC-Device-Services@...> On Behalf Of Cloud Tsai
Sent: Thursday, August 08, 2019 12:31 AM
To: edgex-tsc-qa-test@...; edgex-tsc-device-services@...; EdgeX-TSC-Certification@...
Subject: [Edgex-tsc-device-services] Prototype- Blackbox test of Device-Virtual with Robot Framework

 

Hi all,

 

We made a prototype of blackbox test of device-virtual using Robot.  Please help take a look whether it is appropriate.  I plan to present the attached slide in the next Certification working group meeting.  It hasn't been applied the taf structure, but it is runnable with the standard Robot framework.

https://github.com/FelixTing/Playground_RobotFramework  

 

The plan is to use robot file to define the spec (test cases) for all the services, and the test report is easy to understand by all kinds of users.

 

--

Best Regards,

Cloud Tsai



--
Best Regards,
Cloud Tsai

Re: Prototype- Blackbox test of Device-Virtual with Robot Framework

Goodell, Leonard
 

Hi Cloud,

  Great start!! I think you should also point out that all developers running/creating tests (that’s all of us 😊 ) will be required to install the robot tool chain outlined in the prerequisites here: https://github.com/FelixTing/Playground_RobotFramework/blob/master/README.md

 

Thanks!

   Lenny

 

From: EdgeX-TSC-Device-Services@... <EdgeX-TSC-Device-Services@...> On Behalf Of Cloud Tsai
Sent: Thursday, August 08, 2019 12:31 AM
To: edgex-tsc-qa-test@...; edgex-tsc-device-services@...; EdgeX-TSC-Certification@...
Subject: [Edgex-tsc-device-services] Prototype- Blackbox test of Device-Virtual with Robot Framework

 

Hi all,

 

We made a prototype of blackbox test of device-virtual using Robot.  Please help take a look whether it is appropriate.  I plan to present the attached slide in the next Certification working group meeting.  It hasn't been applied the taf structure, but it is runnable with the standard Robot framework.

https://github.com/FelixTing/Playground_RobotFramework  

 

The plan is to use robot file to define the spec (test cases) for all the services, and the test report is easy to understand by all kinds of users.

 

--

Best Regards,

Cloud Tsai

Re: [Edgex-tsc-QA-Test] Prototype- Blackbox test of Device-Virtual with Robot Framework

Cloud Tsai
 

Hi Jim,  Sorry for the unclear description.  Here is the further explanation.

  • “It hasn't been applied the taf structure” – what does this mean?
    TAF stands for Test Automation Framework contributed by Intel team.  It is based on Robot and defines a good file and folder structure, util libraries, and naming convention.  Intel will help present in the QA WG meeting.
    https://github.com/edgexfoundry-holding/edgex-taf  
    https://github.com/edgexfoundry-holding/edgex-taf-common  
  • “The plan is to use robot file to define the spec (test cases) for all the services” – so we would get rid of the current blackbox tests long run??  Is this work that each work group needs to do or be involved in?  Would the goal be for all services by Geneva or which release is the target?
    We won't get rid of the current blackbox tests soon.
    It should be a gradually process, and follow the pace of certification work.  We need a place clearly define the spec.  Thus, it would start from Device Service.  Yes, we will need the help from each working group to define or review the spec in Robot files.
  • Any idea of how long it takes to run Robot tests verses postman tests?  Just a general idea of whether it takes more or less time to run tests?
    The duration of running the test does not depend on the test framework, but the complexity of test cases.  The tests of postman are all simple API test, so it would be quicker.  The tests in system integration level would take longer time, but in API level should be similar.
  • I assume the device test suite (which you show against the device virtual on slide 4) would be set up for each device service??  How or would the Robot tests be setup to test each new device service?  Do we need a separate test suite for each device service or would this be the same suite for all device services?  How would that work/look?
    This needs further discussion, and applying TAF might help achieve that.
  • While you say that people (users) writing the tests don’t really have to know how to program to write test cases (you summary slide), it would seem that they will need a developer to write the resource.robot as that is pretty detailed to the API and all the parameters, etc. and I think it would require the developer to write this – correct?
    That's the goal, but we are still figuring out how to make it easier.

On Thu, 8 Aug 2019 at 22:29, <James.White2@...> wrote:

Cloud and team – good work to start this.  Couple of questions/comments…

  • “It hasn't been applied the taf structure” – what does this mean?
  • “The plan is to use robot file to define the spec (test cases) for all the services” – so we would get rid of the current blackbox tests long run??  Is this work that each work group needs to do or be involved in?  Would the goal be for all services by Geneva or which release is the target?
  • Any idea of how long it takes to run Robot tests verses postman tests?  Just a general idea of whether it takes more or less time to run tests?
  • I assume the device test suite (which you show against the device virtual on slide 4) would be set up for each device service??  How or would the Robot tests be setup to test each new device service?  Do we need a separate test suite for each device service or would this be the same suite for all device services?  How would that work/look?
  • While you say that people (users) writing the tests don’t really have to know how to program to write test cases (you summary slide), it would seem that they will need a developer to write the resource.robot as that is pretty detailed to the API and all the parameters, etc. and I think it would require the developer to write this – correct?

 

jim

 

From: EdgeX-TSC-QA-Test@... <EdgeX-TSC-QA-Test@...> On Behalf Of Cloud Tsai
Sent: Thursday, August 8, 2019 2:31 AM
To: edgex-tsc-qa-test@...; edgex-tsc-device-services@...; EdgeX-TSC-Certification@...
Subject: [Edgex-tsc-QA-Test] Prototype- Blackbox test of Device-Virtual with Robot Framework

 

[EXTERNAL EMAIL]

Hi all,

 

We made a prototype of blackbox test of device-virtual using Robot.  Please help take a look whether it is appropriate.  I plan to present the attached slide in the next Certification working group meeting.  It hasn't been applied the taf structure, but it is runnable with the standard Robot framework.

https://github.com/FelixTing/Playground_RobotFramework  

 

The plan is to use robot file to define the spec (test cases) for all the services, and the test report is easy to understand by all kinds of users.

 

--

Best Regards,

Cloud Tsai



--
Best Regards,
Cloud Tsai

Re: [Edgex-tsc-QA-Test] Prototype- Blackbox test of Device-Virtual with Robot Framework

James.White2@...
 

Cloud and team – good work to start this.  Couple of questions/comments…

  • “It hasn't been applied the taf structure” – what does this mean?
  • “The plan is to use robot file to define the spec (test cases) for all the services” – so we would get rid of the current blackbox tests long run??  Is this work that each work group needs to do or be involved in?  Would the goal be for all services by Geneva or which release is the target?
  • Any idea of how long it takes to run Robot tests verses postman tests?  Just a general idea of whether it takes more or less time to run tests?
  • I assume the device test suite (which you show against the device virtual on slide 4) would be set up for each device service??  How or would the Robot tests be setup to test each new device service?  Do we need a separate test suite for each device service or would this be the same suite for all device services?  How would that work/look?
  • While you say that people (users) writing the tests don’t really have to know how to program to write test cases (you summary slide), it would seem that they will need a developer to write the resource.robot as that is pretty detailed to the API and all the parameters, etc. and I think it would require the developer to write this – correct?

 

jim

 

From: EdgeX-TSC-QA-Test@... <EdgeX-TSC-QA-Test@...> On Behalf Of Cloud Tsai
Sent: Thursday, August 8, 2019 2:31 AM
To: edgex-tsc-qa-test@...; edgex-tsc-device-services@...; EdgeX-TSC-Certification@...
Subject: [Edgex-tsc-QA-Test] Prototype- Blackbox test of Device-Virtual with Robot Framework

 

[EXTERNAL EMAIL]

Hi all,

 

We made a prototype of blackbox test of device-virtual using Robot.  Please help take a look whether it is appropriate.  I plan to present the attached slide in the next Certification working group meeting.  It hasn't been applied the taf structure, but it is runnable with the standard Robot framework.

https://github.com/FelixTing/Playground_RobotFramework  

 

The plan is to use robot file to define the spec (test cases) for all the services, and the test report is easy to understand by all kinds of users.

 

--

Best Regards,

Cloud Tsai

Prototype- Blackbox test of Device-Virtual with Robot Framework

Cloud Tsai
 

Hi all,

We made a prototype of blackbox test of device-virtual using Robot.  Please help take a look whether it is appropriate.  I plan to present the attached slide in the next Certification working group meeting.  It hasn't been applied the taf structure, but it is runnable with the standard Robot framework.
https://github.com/FelixTing/Playground_RobotFramework  

The plan is to use robot file to define the spec (test cases) for all the services, and the test report is easy to understand by all kinds of users.

--
Best Regards,
Cloud Tsai

Upcoming Event: EdgeX Device and Device SDK WG Meeting (Weekly) - Mon, 08/05/2019 8:00am-9:00am, Please RSVP #cal-reminder

EdgeX-TSC-Device-Services@lists.edgexfoundry.org Calendar <EdgeX-TSC-Device-Services@...>
 

Reminder: EdgeX Device and Device SDK WG Meeting (Weekly)

When: Monday, 5 August 2019, 8:00am to 9:00am, (GMT-07:00) America/Los Angeles

Where:https://zoom.us/j/314411765

An RSVP is requested. Click here to RSVP

Organizer: EdgeX-TSC-Device-Services@...

Description: EdgeX Device and Device SDK WG Meeting. Meeting content posted to Device and Device SDK WG Wiki.
Meeting Lead: Steve Osselton, Device and Device SDK WG Chair, steve@...
-----Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/314411765

Or iPhone one-tap :
    US: +16699006833,,314411765# or +16465588656,,314411765# 
Or Telephone:
    Dial(for higher quality, dial a number based on your current location): 
        US: +1 669 900 6833 or +1 646 558 8656 or +1 877 369 0926 (Toll Free) or +1 855 880 1246 (Toll Free)
    Meeting ID: 314 411 765
    International numbers available: https://zoom.us/u/dYf323vjV

Provision Watchers

Iain Anderson
 

Hi everyone,

Unless there are objections I'm going to confirm the Provision Watcher design as being that specified in https://github.com/edgexfoundry/go-mod-core-contracts/issues/111

The most recent updates being that:

1) The map used for blacklisting is to contain string slices. IE, multiple possible match strings for the blacklist.
2) The content of said match strings are to be POSIX regular expressions, as supported by the standard libraries in C and Go.

So if you think this is wrong, please say so before or during the WG meeting on Monday.

Regards,
Iain

Upcoming Event: EdgeX Device and Device SDK WG Meeting (Weekly) - Mon, 07/29/2019 8:00am-9:00am, Please RSVP #cal-reminder

EdgeX-TSC-Device-Services@lists.edgexfoundry.org Calendar <EdgeX-TSC-Device-Services@...>
 

Reminder: EdgeX Device and Device SDK WG Meeting (Weekly)

When: Monday, 29 July 2019, 8:00am to 9:00am, (GMT-07:00) America/Los Angeles

Where:https://zoom.us/j/314411765

An RSVP is requested. Click here to RSVP

Organizer: EdgeX-TSC-Device-Services@...

Description: EdgeX Device and Device SDK WG Meeting. Meeting content posted to Device and Device SDK WG Wiki.
Meeting Lead: Steve Osselton, Device and Device SDK WG Chair, steve@...
-----Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/314411765

Or iPhone one-tap :
    US: +16699006833,,314411765# or +16465588656,,314411765# 
Or Telephone:
    Dial(for higher quality, dial a number based on your current location): 
        US: +1 669 900 6833 or +1 646 558 8656 or +1 877 369 0926 (Toll Free) or +1 855 880 1246 (Toll Free)
    Meeting ID: 314 411 765
    International numbers available: https://zoom.us/u/dYf323vjV

Re: Confirming Flow Around Value Descriptor :Creation

Cloud Tsai
 

Sounds good to me.  I can handle 404 and treat the same as 1.0.x


On Wed, 24 Jul 2019 at 06:39, <Trevor.Conn@...> wrote:

OK, I have no problem adding a /version endpoint but realize you might not see that in an Edinburgh release. At a minimum it won't be there until we do another dot release. And if a customer is still using the initial Edinburgh releases, then the DS will receive a 404 when it tries to call /version. So just plan to create the descriptors in that case.


Trevor Conn
Technical Staff Engineer
Core Working Group Chair of EdgeX Foundry
Dell Technologies | IoT DellTech
Trevor_Conn@...
Round Rock, TX  USA

From: EdgeX-TSC-Device-Services@... <EdgeX-TSC-Device-Services@...> on behalf of Iain Anderson <iain@...>
Sent: Tuesday, July 23, 2019 4:55 AM
To: EdgeX-TSC-Device-Services@...
Subject: Re: [Edgex-tsc-device-services] Confirming Flow Around Value Descriptor :Creation
 

[EXTERNAL EMAIL]

For core-metadata the return string from ping is undocumented. That being said I prefer "/version".

- Iain


On 23/07/2019 03:44, Cloud Tsai wrote:
Hi Trevor,

In this case, Device Service SDK also need a configuration property for this, or the new Device Service can't work with Edinburgh core services.
I thought another alternative way is to add a "/version" API to return the version number for now.
In Geneva, we could remove "/version" API and use "/ping" to return version number or always keep "/version" API.

It's an usability trade off.  

On Tue, 23 Jul 2019 at 02:29, <Trevor.Conn@...> wrote:

Ian Johnson has pointed out that the proposed change breaks documented API compatibility. Therefore we cannot return the version from the ping API endpoints in the Core Services until Geneva.


I have asked Anthony to include a configurable feature toggle to enable the Core Services to create Value Descriptors as part of his current PR. This was an alternate strategy we discussed on the call this morning. I propose adding a key to the [Writable] section of the config.


Given that, I think the only work to be done from a DS SDK perspective is to remove the relevant logic in the master branch. This is because if someone were running an Edinburgh-based device service with Fuji Core Services, they would simply disable the feature toggle in the Core Services.


Trevor Conn
Technical Staff Engineer
Core Working Group Chair of EdgeX Foundry
Dell Technologies | IoT DellTech
Trevor_Conn@...
Round Rock, TX  USA

From: Conn, Trevor
Sent: Monday, July 22, 2019 10:32 AM
To: edgex-tsc-device-services@...
Subject: Confirming Flow Around Value Descriptor :Creation
 

I'm summarizing here thoughts from this morning's discussion on integrating the SDK with Core Services in terms of creating Value Descriptors. As discussed on the call they can't both do it b/c a name collision will result.


For the Edinburgh release, we want to support the ability to determine if the SDK should create value descriptors or not. This would be in the scenario where an Edinburgh SDK is deployed and running against a Fuji version of the Core Services. In order to support this, the output of the /ping endpoints of the Core Services will return the service version number (such as 1.1.0 for Fuji). In my thinking, a change will need to be made to an Edinburgh "dot" version of the SDK to make this determination. For Fuji, the SDK shouldn't make this check at all. It should just remove the responsibility.


So as I see it, the tasks involved are as follows (seeking confirmation)

  • Change Core Service API /ping endpoint to return version (see issue 1449)
  • Device-SDK Edniburgh branch -- Decide whether or not to create the Value Descriptor based on the /ping version response
  • Master (Fuji) branch -- Remove the capability to create value descriptors from the SDK altogether
We'll go ahead and get started on issue 1449. Please comment if the DS team doesn't think definition of the last two tasks makes sense.


Trevor Conn
Technical Staff Engineer
Core Working Group Chair of EdgeX Foundry
Dell Technologies | IoT DellTech
Trevor_Conn@...
Round Rock, TX  USA


--
Best Regards,
Cloud Tsai



--
Best Regards,
Cloud Tsai

Re: Confirming Flow Around Value Descriptor :Creation

Trevor.Conn@...
 

OK, I have no problem adding a /version endpoint but realize you might not see that in an Edinburgh release. At a minimum it won't be there until we do another dot release. And if a customer is still using the initial Edinburgh releases, then the DS will receive a 404 when it tries to call /version. So just plan to create the descriptors in that case.


Trevor Conn
Technical Staff Engineer
Core Working Group Chair of EdgeX Foundry
Dell Technologies | IoT DellTech
Trevor_Conn@...
Round Rock, TX  USA


From: EdgeX-TSC-Device-Services@... <EdgeX-TSC-Device-Services@...> on behalf of Iain Anderson <iain@...>
Sent: Tuesday, July 23, 2019 4:55 AM
To: EdgeX-TSC-Device-Services@...
Subject: Re: [Edgex-tsc-device-services] Confirming Flow Around Value Descriptor :Creation
 

[EXTERNAL EMAIL]

For core-metadata the return string from ping is undocumented. That being said I prefer "/version".

- Iain


On 23/07/2019 03:44, Cloud Tsai wrote:
Hi Trevor,

In this case, Device Service SDK also need a configuration property for this, or the new Device Service can't work with Edinburgh core services.
I thought another alternative way is to add a "/version" API to return the version number for now.
In Geneva, we could remove "/version" API and use "/ping" to return version number or always keep "/version" API.

It's an usability trade off.  

On Tue, 23 Jul 2019 at 02:29, <Trevor.Conn@...> wrote:

Ian Johnson has pointed out that the proposed change breaks documented API compatibility. Therefore we cannot return the version from the ping API endpoints in the Core Services until Geneva.


I have asked Anthony to include a configurable feature toggle to enable the Core Services to create Value Descriptors as part of his current PR. This was an alternate strategy we discussed on the call this morning. I propose adding a key to the [Writable] section of the config.


Given that, I think the only work to be done from a DS SDK perspective is to remove the relevant logic in the master branch. This is because if someone were running an Edinburgh-based device service with Fuji Core Services, they would simply disable the feature toggle in the Core Services.


Trevor Conn
Technical Staff Engineer
Core Working Group Chair of EdgeX Foundry
Dell Technologies | IoT DellTech
Trevor_Conn@...
Round Rock, TX  USA

From: Conn, Trevor
Sent: Monday, July 22, 2019 10:32 AM
To: edgex-tsc-device-services@...
Subject: Confirming Flow Around Value Descriptor :Creation
 

I'm summarizing here thoughts from this morning's discussion on integrating the SDK with Core Services in terms of creating Value Descriptors. As discussed on the call they can't both do it b/c a name collision will result.


For the Edinburgh release, we want to support the ability to determine if the SDK should create value descriptors or not. This would be in the scenario where an Edinburgh SDK is deployed and running against a Fuji version of the Core Services. In order to support this, the output of the /ping endpoints of the Core Services will return the service version number (such as 1.1.0 for Fuji). In my thinking, a change will need to be made to an Edinburgh "dot" version of the SDK to make this determination. For Fuji, the SDK shouldn't make this check at all. It should just remove the responsibility.


So as I see it, the tasks involved are as follows (seeking confirmation)

  • Change Core Service API /ping endpoint to return version (see issue 1449)
  • Device-SDK Edniburgh branch -- Decide whether or not to create the Value Descriptor based on the /ping version response
  • Master (Fuji) branch -- Remove the capability to create value descriptors from the SDK altogether
We'll go ahead and get started on issue 1449. Please comment if the DS team doesn't think definition of the last two tasks makes sense.


Trevor Conn
Technical Staff Engineer
Core Working Group Chair of EdgeX Foundry
Dell Technologies | IoT DellTech
Trevor_Conn@...
Round Rock, TX  USA


--
Best Regards,
Cloud Tsai

Re: Overview of Pre-Delhi Dynamic Device Discovery design

Iain Anderson
 



On 23/07/2019 16:34, Trevor.Conn@... wrote:

Some thoughts after reading this and going back over the discussion thread


1.) Are we sure the Provision Watcher isn't something that should live solely in the device service? Metadata will still contain devices/profiles/services that are active and part of the landscape, but the DS is the arbiter of onboarding.

2.) Putting the ProvisionWatcher in the DS eliminates reliance on the Scheduler b/c you can manage the rediscovery of devices internally, the same way we do with AutoEvents.



The intent as I understand it is that core-metadata handles the persistence of PWs, provides the interface for managing your PW collection and handles consistency issues (a DeviceProfile may not be deleted if a PW specifies it). The DS is where the matching logic will live. So the DS will hit the provisionwatcher/servicename endpoint on core-metadata at startup, and listen for updates on its callback handler - in the same way as it does for Devices. Then when discovery occurs the DS will use its local cache of PWs to determine whether to create new devices.

As far as the Scheduler goes, the intention is to perform discovery in various circumstances:
1) When the DS /discovery endpoint is hit (by support-scheduler or otherwise)
2) On a configurable schedule internal to the DS
3) On programmatic request from the DS implementation

Regards,
Iain

Re: Overview of Pre-Delhi Dynamic Device Discovery design

Trevor.Conn@...
 

Some thoughts after reading this and going back over the discussion thread


1.) Are we sure the Provision Watcher isn't something that should live solely in the device service? Metadata will still contain devices/profiles/services that are active and part of the landscape, but the DS is the arbiter of onboarding.

2.) Putting the ProvisionWatcher in the DS eliminates reliance on the Scheduler b/c you can manage the rediscovery of devices internally, the same way we do with AutoEvents.

3.) The pushback to point 1 above might be that giving Metadata the responsibility for ProvisionWatchers could prevent a moving device -- such as a wearable going from building to building -- from onboarding via any DS. This would require a split deployment of EdgeX where the DS is on a gateway and the core services are running in a central location. Alternatively, we could support the ability for DS to talk horizontally to each other in environments with multiple complete deployments of EdgeX. I would prefer a pub/sub (not ZeroMQ) for this instead of a REST call.

4.) Another objection could be -- if the DS controls the Provision Watcher and the DS goes down, how does it re-hydrate that information? There could either be a simple persistence layer to handle this or, in the case where DS can talk to each other, it could request the ProvisionWatcher criteria from another service instance.


Thinking out loud.


Trevor Conn
Technical Staff Engineer
Core Working Group Chair of EdgeX Foundry
Dell Technologies | IoT DellTech
Trevor_Conn@...
Round Rock, TX  USA


From: EdgeX-TSC-Device-Services@... <EdgeX-TSC-Device-Services@...> on behalf of Iain Anderson <iain@...>
Sent: Tuesday, July 23, 2019 9:46 AM
To: EdgeX-TSC-Device-Services@...
Subject: Re: [Edgex-tsc-device-services] Overview of Pre-Delhi Dynamic Device Discovery design
 

[EXTERNAL EMAIL]

I've updated https://github.com/edgexfoundry/go-mod-core-contracts/issues/111 in light of the suggestions here. Please review and comment.

Regards,
Iain


On 22/07/2019 18:54, espy wrote:

On 6/3/19 6:53 PM, Tony Espy wrote:

As discussed during today's Device Service working group meeting, I volunteered to write a description of the original dynamic device discovery mechanism.

[Jim - feel free to comment and/or correct my description]

Regards,
/tony

---

Prior to the Delhi release, EdgeX Foundry and device services based on the Java SDK supported a feature called "dynamic device discovery". This feature was originally created in order to support wireless device protocols such as Bluetooth Low Energy, where a given device might not always be available. In such a scenario, the idea was to provide EdgeX with a set of filtering rules which could be used to dynamically add a "discovered" (i.e. available) device to the system if the rules produced a match.

This mechanism relied on Core Metadata object called a ProvisionWatcher which was used to define filtering rules.  A ProvisionWatcher has the following fields:
  • name
  • device-service - name of the owning service
  • device-profile - profile assigned to new matching devices
  • identifiers - map of attributes used to identify a device (eg. name, port, MAC, uuid, …)
  • operating-state - initial operating state for new devices
Note - identifiers can be fully-qualified or could use the wildcard ('*') for pattern matching. This allows a single ProvisionWatcher to be used to match multiple devices.

Device services (via code provided by the Java SDK) provided an endpoint called /discovery. Calling this endpoint resulted in the device service calling an internal Scan method in the device service's ProtocolDriver. The result of the Scan method was a list of available devices. For each device in this list, the ProtocolDriver provided a map of attributes that can be used to identify devices of a given protocol.  For instance for BLE devices this map might contain a MAC address and a service UUID.

The device SDK code would iterate through the scan results looking for new devices. If a new device was detected, then the SDK would attempt to match the device against any existing ProvisionWatcher objects associated with the device service.  When matches were found, the SDK would add the new device using the device profile and operating state specified in the ProvisionWatcher.

As long promised, here's my suggestion on how we handle blacklisting devices. As pointed out above, a ProvisionWatcher has a field called "identifiers" which is a map of strings which represent device attributes which can be used to identify a device. The key in this case identifies the attribute to match against (e.g. 'Name', 'MAC', 'uuid', ...). When a device service ProtocolDriver returns a list of devices in response to a Scan call, a corresponding map of device identifiers is returned. The SDK then looks for matches between the devices in the scan list and it's current ProvisionWatchers. The values in the ProvisionWatcher identifiers map support a basic glob-style [1] wildcard character "*".

So if a ProvisionWatcher defined identifiers as [["Name", "acme*"], "MAC", "38:Fc:E7*"], then any devices found in a subsequent scan results list with 'Name' that matches "acme*" and MAC address with the prefix "38:Fc:E7" would be added (if they don't already exist).

In order to exclude specific devices when a pattern has many potential matches, the idea has been tossed about to add a blacklist. Although you could argue that adjusting identifiers to exclude devices is one way to go, adding an explicit blacklist mechanism also has merit.

I think the simplest approach would be to add a new field called "blacklist" which is map of string arrays/lists which define values which if found in the attributes of a scanned device, prevent it from being added.  With the example above, if the device "acme13" was found to be compromised, all you'd need to do is add "acme13" to the "Names" list, and the original identifiers would still match against all other devices with the name prefix "acme". Likewise you could also specify a different identifier (if supported by the device service) in the blacklist (i.e. a specific MAC address).

To keep it's simple, let's just call the new field blacklist and make it a map of string slices:

blacklist    map[string][]

Two questions:

1) Should the blacklist support the "*" wildcard char?

2) Should we implement glob style pattern matching (eg. '?' or [...])?

Regards,
/tony

[1] https://en.wikipedia.org/wiki/Glob_(programming)


The final piece of the puzzle is Support Scheduler, which via Schedule and ScheduleEvent objects could be used to periodically call a device service's /discovery endpoint.

= Problems =

There are a few problems with this approach to dynamic device discovery.

1. Device deletion - if a device is deleted from the device service (and Core Metadata), on subsequent scans if the device was found to be available again, it would be re-added.

This problem is where the idea of device blacklists came from. In addition to deleting a device, you'd also add it to a blacklist object (in the ProvisionWatcher?). I'd argue that this is just adding to already complicated approach. Instead of black-listing the device, why not modify (or delete) the matching ProvisionWatcher before deleting the device?

2. Scan are synchronous - the /discovery endpoint didn't support asynchronous scan results.

3. ProvisionWatchers contain device profiles. This is the same problem we currently have with embedded device profiles in devices.  This makes ProvisionWatchers fairly heavy-weight objects, and adds complexity if/when a device profile is updated.

4. Scanning in a fixed period is less than ideal, as scanning can impact performance and also may impacts battery life for certain devices. Ideally the logic for determing when to scan should be the responsibilty of the device service, not pre-configured using Support Scheduler.

Example Java configuration for BLE ProvisionWatchers:

default.watcher.name=BLE-Watcher,BLE-Watcher-2,BLE-Watcher-3
default.watcher.service=device-bluetooth,device-bluetooth,device-bluetooth
default.watcher.profile=SensorTag,XDK,BLELight
default.watcher.name_identifiers=.*CC2650.*,XDK.*,.*beLight.*

Food for thought…

Instead of the ProvisionWatcher approach, should devices be explicitly added individually and a new attribute added which indicates "presence"?


Re: Overview of Pre-Delhi Dynamic Device Discovery design

Iain Anderson
 

I've updated https://github.com/edgexfoundry/go-mod-core-contracts/issues/111 in light of the suggestions here. Please review and comment.

Regards,
Iain


On 22/07/2019 18:54, espy wrote:

On 6/3/19 6:53 PM, Tony Espy wrote:

As discussed during today's Device Service working group meeting, I volunteered to write a description of the original dynamic device discovery mechanism.

[Jim - feel free to comment and/or correct my description]

Regards,
/tony

---

Prior to the Delhi release, EdgeX Foundry and device services based on the Java SDK supported a feature called "dynamic device discovery". This feature was originally created in order to support wireless device protocols such as Bluetooth Low Energy, where a given device might not always be available. In such a scenario, the idea was to provide EdgeX with a set of filtering rules which could be used to dynamically add a "discovered" (i.e. available) device to the system if the rules produced a match.

This mechanism relied on Core Metadata object called a ProvisionWatcher which was used to define filtering rules.  A ProvisionWatcher has the following fields:
  • name
  • device-service - name of the owning service
  • device-profile - profile assigned to new matching devices
  • identifiers - map of attributes used to identify a device (eg. name, port, MAC, uuid, …)
  • operating-state - initial operating state for new devices
Note - identifiers can be fully-qualified or could use the wildcard ('*') for pattern matching. This allows a single ProvisionWatcher to be used to match multiple devices.

Device services (via code provided by the Java SDK) provided an endpoint called /discovery. Calling this endpoint resulted in the device service calling an internal Scan method in the device service's ProtocolDriver. The result of the Scan method was a list of available devices. For each device in this list, the ProtocolDriver provided a map of attributes that can be used to identify devices of a given protocol.  For instance for BLE devices this map might contain a MAC address and a service UUID.

The device SDK code would iterate through the scan results looking for new devices. If a new device was detected, then the SDK would attempt to match the device against any existing ProvisionWatcher objects associated with the device service.  When matches were found, the SDK would add the new device using the device profile and operating state specified in the ProvisionWatcher.

As long promised, here's my suggestion on how we handle blacklisting devices. As pointed out above, a ProvisionWatcher has a field called "identifiers" which is a map of strings which represent device attributes which can be used to identify a device. The key in this case identifies the attribute to match against (e.g. 'Name', 'MAC', 'uuid', ...). When a device service ProtocolDriver returns a list of devices in response to a Scan call, a corresponding map of device identifiers is returned. The SDK then looks for matches between the devices in the scan list and it's current ProvisionWatchers. The values in the ProvisionWatcher identifiers map support a basic glob-style [1] wildcard character "*".

So if a ProvisionWatcher defined identifiers as [["Name", "acme*"], "MAC", "38:Fc:E7*"], then any devices found in a subsequent scan results list with 'Name' that matches "acme*" and MAC address with the prefix "38:Fc:E7" would be added (if they don't already exist).

In order to exclude specific devices when a pattern has many potential matches, the idea has been tossed about to add a blacklist. Although you could argue that adjusting identifiers to exclude devices is one way to go, adding an explicit blacklist mechanism also has merit.

I think the simplest approach would be to add a new field called "blacklist" which is map of string arrays/lists which define values which if found in the attributes of a scanned device, prevent it from being added.  With the example above, if the device "acme13" was found to be compromised, all you'd need to do is add "acme13" to the "Names" list, and the original identifiers would still match against all other devices with the name prefix "acme". Likewise you could also specify a different identifier (if supported by the device service) in the blacklist (i.e. a specific MAC address).

To keep it's simple, let's just call the new field blacklist and make it a map of string slices:

blacklist    map[string][]

Two questions:

1) Should the blacklist support the "*" wildcard char?

2) Should we implement glob style pattern matching (eg. '?' or [...])?

Regards,
/tony

[1] https://en.wikipedia.org/wiki/Glob_(programming)


The final piece of the puzzle is Support Scheduler, which via Schedule and ScheduleEvent objects could be used to periodically call a device service's /discovery endpoint.

= Problems =

There are a few problems with this approach to dynamic device discovery.

1. Device deletion - if a device is deleted from the device service (and Core Metadata), on subsequent scans if the device was found to be available again, it would be re-added.

This problem is where the idea of device blacklists came from. In addition to deleting a device, you'd also add it to a blacklist object (in the ProvisionWatcher?). I'd argue that this is just adding to already complicated approach. Instead of black-listing the device, why not modify (or delete) the matching ProvisionWatcher before deleting the device?

2. Scan are synchronous - the /discovery endpoint didn't support asynchronous scan results.

3. ProvisionWatchers contain device profiles. This is the same problem we currently have with embedded device profiles in devices.  This makes ProvisionWatchers fairly heavy-weight objects, and adds complexity if/when a device profile is updated.

4. Scanning in a fixed period is less than ideal, as scanning can impact performance and also may impacts battery life for certain devices. Ideally the logic for determing when to scan should be the responsibilty of the device service, not pre-configured using Support Scheduler.

Example Java configuration for BLE ProvisionWatchers:

default.watcher.name=BLE-Watcher,BLE-Watcher-2,BLE-Watcher-3
default.watcher.service=device-bluetooth,device-bluetooth,device-bluetooth
default.watcher.profile=SensorTag,XDK,BLELight
default.watcher.name_identifiers=.*CC2650.*,XDK.*,.*beLight.*

Food for thought…

Instead of the ProvisionWatcher approach, should devices be explicitly added individually and a new attribute added which indicates "presence"?


Re: Confirming Flow Around Value Descriptor :Creation

Iain Anderson
 

For core-metadata the return string from ping is undocumented. That being said I prefer "/version".

- Iain


On 23/07/2019 03:44, Cloud Tsai wrote:
Hi Trevor,

In this case, Device Service SDK also need a configuration property for this, or the new Device Service can't work with Edinburgh core services.
I thought another alternative way is to add a "/version" API to return the version number for now.
In Geneva, we could remove "/version" API and use "/ping" to return version number or always keep "/version" API.

It's an usability trade off.  

On Tue, 23 Jul 2019 at 02:29, <Trevor.Conn@...> wrote:

Ian Johnson has pointed out that the proposed change breaks documented API compatibility. Therefore we cannot return the version from the ping API endpoints in the Core Services until Geneva.


I have asked Anthony to include a configurable feature toggle to enable the Core Services to create Value Descriptors as part of his current PR. This was an alternate strategy we discussed on the call this morning. I propose adding a key to the [Writable] section of the config.


Given that, I think the only work to be done from a DS SDK perspective is to remove the relevant logic in the master branch. This is because if someone were running an Edinburgh-based device service with Fuji Core Services, they would simply disable the feature toggle in the Core Services.


Trevor Conn
Technical Staff Engineer
Core Working Group Chair of EdgeX Foundry
Dell Technologies | IoT DellTech
Trevor_Conn@...
Round Rock, TX  USA

From: Conn, Trevor
Sent: Monday, July 22, 2019 10:32 AM
To: edgex-tsc-device-services@...
Subject: Confirming Flow Around Value Descriptor :Creation
 

I'm summarizing here thoughts from this morning's discussion on integrating the SDK with Core Services in terms of creating Value Descriptors. As discussed on the call they can't both do it b/c a name collision will result.


For the Edinburgh release, we want to support the ability to determine if the SDK should create value descriptors or not. This would be in the scenario where an Edinburgh SDK is deployed and running against a Fuji version of the Core Services. In order to support this, the output of the /ping endpoints of the Core Services will return the service version number (such as 1.1.0 for Fuji). In my thinking, a change will need to be made to an Edinburgh "dot" version of the SDK to make this determination. For Fuji, the SDK shouldn't make this check at all. It should just remove the responsibility.


So as I see it, the tasks involved are as follows (seeking confirmation)

  • Change Core Service API /ping endpoint to return version (see issue 1449)
  • Device-SDK Edniburgh branch -- Decide whether or not to create the Value Descriptor based on the /ping version response
  • Master (Fuji) branch -- Remove the capability to create value descriptors from the SDK altogether
We'll go ahead and get started on issue 1449. Please comment if the DS team doesn't think definition of the last two tasks makes sense.


Trevor Conn
Technical Staff Engineer
Core Working Group Chair of EdgeX Foundry
Dell Technologies | IoT DellTech
Trevor_Conn@...
Round Rock, TX  USA


--
Best Regards,
Cloud Tsai

Re: Confirming Flow Around Value Descriptor :Creation

Cloud Tsai
 

Hi Trevor,

In this case, Device Service SDK also need a configuration property for this, or the new Device Service can't work with Edinburgh core services.
I thought another alternative way is to add a "/version" API to return the version number for now.
In Geneva, we could remove "/version" API and use "/ping" to return version number or always keep "/version" API.

It's an usability trade off.  

On Tue, 23 Jul 2019 at 02:29, <Trevor.Conn@...> wrote:

Ian Johnson has pointed out that the proposed change breaks documented API compatibility. Therefore we cannot return the version from the ping API endpoints in the Core Services until Geneva.


I have asked Anthony to include a configurable feature toggle to enable the Core Services to create Value Descriptors as part of his current PR. This was an alternate strategy we discussed on the call this morning. I propose adding a key to the [Writable] section of the config.


Given that, I think the only work to be done from a DS SDK perspective is to remove the relevant logic in the master branch. This is because if someone were running an Edinburgh-based device service with Fuji Core Services, they would simply disable the feature toggle in the Core Services.


Trevor Conn
Technical Staff Engineer
Core Working Group Chair of EdgeX Foundry
Dell Technologies | IoT DellTech
Trevor_Conn@...
Round Rock, TX  USA

From: Conn, Trevor
Sent: Monday, July 22, 2019 10:32 AM
To: edgex-tsc-device-services@...
Subject: Confirming Flow Around Value Descriptor :Creation
 

I'm summarizing here thoughts from this morning's discussion on integrating the SDK with Core Services in terms of creating Value Descriptors. As discussed on the call they can't both do it b/c a name collision will result.


For the Edinburgh release, we want to support the ability to determine if the SDK should create value descriptors or not. This would be in the scenario where an Edinburgh SDK is deployed and running against a Fuji version of the Core Services. In order to support this, the output of the /ping endpoints of the Core Services will return the service version number (such as 1.1.0 for Fuji). In my thinking, a change will need to be made to an Edinburgh "dot" version of the SDK to make this determination. For Fuji, the SDK shouldn't make this check at all. It should just remove the responsibility.


So as I see it, the tasks involved are as follows (seeking confirmation)

  • Change Core Service API /ping endpoint to return version (see issue 1449)
  • Device-SDK Edniburgh branch -- Decide whether or not to create the Value Descriptor based on the /ping version response
  • Master (Fuji) branch -- Remove the capability to create value descriptors from the SDK altogether
We'll go ahead and get started on issue 1449. Please comment if the DS team doesn't think definition of the last two tasks makes sense.


Trevor Conn
Technical Staff Engineer
Core Working Group Chair of EdgeX Foundry
Dell Technologies | IoT DellTech
Trevor_Conn@...
Round Rock, TX  USA



--
Best Regards,
Cloud Tsai

Re: Confirming Flow Around Value Descriptor :Creation

Trevor.Conn@...
 

Ian Johnson has pointed out that the proposed change breaks documented API compatibility. Therefore we cannot return the version from the ping API endpoints in the Core Services until Geneva.


I have asked Anthony to include a configurable feature toggle to enable the Core Services to create Value Descriptors as part of his current PR. This was an alternate strategy we discussed on the call this morning. I propose adding a key to the [Writable] section of the config.


Given that, I think the only work to be done from a DS SDK perspective is to remove the relevant logic in the master branch. This is because if someone were running an Edinburgh-based device service with Fuji Core Services, they would simply disable the feature toggle in the Core Services.


Trevor Conn
Technical Staff Engineer
Core Working Group Chair of EdgeX Foundry
Dell Technologies | IoT DellTech
Trevor_Conn@...
Round Rock, TX  USA


From: Conn, Trevor
Sent: Monday, July 22, 2019 10:32 AM
To: edgex-tsc-device-services@...
Subject: Confirming Flow Around Value Descriptor :Creation
 

I'm summarizing here thoughts from this morning's discussion on integrating the SDK with Core Services in terms of creating Value Descriptors. As discussed on the call they can't both do it b/c a name collision will result.


For the Edinburgh release, we want to support the ability to determine if the SDK should create value descriptors or not. This would be in the scenario where an Edinburgh SDK is deployed and running against a Fuji version of the Core Services. In order to support this, the output of the /ping endpoints of the Core Services will return the service version number (such as 1.1.0 for Fuji). In my thinking, a change will need to be made to an Edinburgh "dot" version of the SDK to make this determination. For Fuji, the SDK shouldn't make this check at all. It should just remove the responsibility.


So as I see it, the tasks involved are as follows (seeking confirmation)

  • Change Core Service API /ping endpoint to return version (see issue 1449)
  • Device-SDK Edniburgh branch -- Decide whether or not to create the Value Descriptor based on the /ping version response
  • Master (Fuji) branch -- Remove the capability to create value descriptors from the SDK altogether
We'll go ahead and get started on issue 1449. Please comment if the DS team doesn't think definition of the last two tasks makes sense.


Trevor Conn
Technical Staff Engineer
Core Working Group Chair of EdgeX Foundry
Dell Technologies | IoT DellTech
Trevor_Conn@...
Round Rock, TX  USA

Re: Overview of Pre-Delhi Dynamic Device Discovery design

espy
 

On 6/3/19 6:53 PM, Tony Espy wrote:

As discussed during today's Device Service working group meeting, I volunteered to write a description of the original dynamic device discovery mechanism.

[Jim - feel free to comment and/or correct my description]

Regards,
/tony

---

Prior to the Delhi release, EdgeX Foundry and device services based on the Java SDK supported a feature called "dynamic device discovery". This feature was originally created in order to support wireless device protocols such as Bluetooth Low Energy, where a given device might not always be available. In such a scenario, the idea was to provide EdgeX with a set of filtering rules which could be used to dynamically add a "discovered" (i.e. available) device to the system if the rules produced a match.

This mechanism relied on Core Metadata object called a ProvisionWatcher which was used to define filtering rules.  A ProvisionWatcher has the following fields:
  • name
  • device-service - name of the owning service
  • device-profile - profile assigned to new matching devices
  • identifiers - map of attributes used to identify a device (eg. name, port, MAC, uuid, …)
  • operating-state - initial operating state for new devices
Note - identifiers can be fully-qualified or could use the wildcard ('*') for pattern matching. This allows a single ProvisionWatcher to be used to match multiple devices.

Device services (via code provided by the Java SDK) provided an endpoint called /discovery. Calling this endpoint resulted in the device service calling an internal Scan method in the device service's ProtocolDriver. The result of the Scan method was a list of available devices. For each device in this list, the ProtocolDriver provided a map of attributes that can be used to identify devices of a given protocol.  For instance for BLE devices this map might contain a MAC address and a service UUID.

The device SDK code would iterate through the scan results looking for new devices. If a new device was detected, then the SDK would attempt to match the device against any existing ProvisionWatcher objects associated with the device service.  When matches were found, the SDK would add the new device using the device profile and operating state specified in the ProvisionWatcher.

As long promised, here's my suggestion on how we handle blacklisting devices. As pointed out above, a ProvisionWatcher has a field called "identifiers" which is a map of strings which represent device attributes which can be used to identify a device. The key in this case identifies the attribute to match against (e.g. 'Name', 'MAC', 'uuid', ...). When a device service ProtocolDriver returns a list of devices in response to a Scan call, a corresponding map of device identifiers is returned. The SDK then looks for matches between the devices in the scan list and it's current ProvisionWatchers. The values in the ProvisionWatcher identifiers map support a basic glob-style [1] wildcard character "*".

So if a ProvisionWatcher defined identifiers as [["Name", "acme*"], "MAC", "38:Fc:E7*"], then any devices found in a subsequent scan results list with 'Name' that matches "acme*" and MAC address with the prefix "38:Fc:E7" would be added (if they don't already exist).

In order to exclude specific devices when a pattern has many potential matches, the idea has been tossed about to add a blacklist. Although you could argue that adjusting identifiers to exclude devices is one way to go, adding an explicit blacklist mechanism also has merit.

I think the simplest approach would be to add a new field called "blacklist" which is map of string arrays/lists which define values which if found in the attributes of a scanned device, prevent it from being added.  With the example above, if the device "acme13" was found to be compromised, all you'd need to do is add "acme13" to the "Names" list, and the original identifiers would still match against all other devices with the name prefix "acme". Likewise you could also specify a different identifier (if supported by the device service) in the blacklist (i.e. a specific MAC address).

To keep it's simple, let's just call the new field blacklist and make it a map of string slices:

blacklist    map[string][]

Two questions:

1) Should the blacklist support the "*" wildcard char?

2) Should we implement glob style pattern matching (eg. '?' or [...])?

Regards,
/tony

[1] https://en.wikipedia.org/wiki/Glob_(programming)


The final piece of the puzzle is Support Scheduler, which via Schedule and ScheduleEvent objects could be used to periodically call a device service's /discovery endpoint.

= Problems =

There are a few problems with this approach to dynamic device discovery.

1. Device deletion - if a device is deleted from the device service (and Core Metadata), on subsequent scans if the device was found to be available again, it would be re-added.

This problem is where the idea of device blacklists came from. In addition to deleting a device, you'd also add it to a blacklist object (in the ProvisionWatcher?). I'd argue that this is just adding to already complicated approach. Instead of black-listing the device, why not modify (or delete) the matching ProvisionWatcher before deleting the device?

2. Scan are synchronous - the /discovery endpoint didn't support asynchronous scan results.

3. ProvisionWatchers contain device profiles. This is the same problem we currently have with embedded device profiles in devices.  This makes ProvisionWatchers fairly heavy-weight objects, and adds complexity if/when a device profile is updated.

4. Scanning in a fixed period is less than ideal, as scanning can impact performance and also may impacts battery life for certain devices. Ideally the logic for determing when to scan should be the responsibilty of the device service, not pre-configured using Support Scheduler.

Example Java configuration for BLE ProvisionWatchers:

default.watcher.name=BLE-Watcher,BLE-Watcher-2,BLE-Watcher-3
default.watcher.service=device-bluetooth,device-bluetooth,device-bluetooth
default.watcher.profile=SensorTag,XDK,BLELight
default.watcher.name_identifiers=.*CC2650.*,XDK.*,.*beLight.*

Food for thought…

Instead of the ProvisionWatcher approach, should devices be explicitly added individually and a new attribute added which indicates "presence"?