When server and device ids change after each reboot it hurts productivity and joy in the Zetta browser

[landlessness]

Whenever I change code, I have to reboot the server. Whenever I reboot, the server and device IDs change. Every time the server and device IDs change I have to hop out of my current Zetta browser state and start over at the Zetta browser home.

Building a device driver involves quite a bit of repetition on the same device page. So what should be a quick form submission becomes a 3-click productivity drag.

[AdamMagaluk]

The server's id changes at startup when it is generated and thus the urls change. In some refactoring I did yesterday here it will no longer generate unique ids for the servers.

The new way of addressing the server through the api is based on the servers name. Which does not change after you restart. After the PR is merged you will only have to refresh the page.

As for device id's depending on your scout/driver implementation they should not changing after a reboot.

a) When not using a scout, .use(<some_driver>), zetta will look in the registry for a device with the type in the driver and if found create it using the previous id. You should see provision in the log statements.

b) If you specifically use a scout to discover devices, you may need to use .discover() and .provision accordingly to allow zetta not to generate a new id when a device already exists in the registry. See: https://gist.github.com/mdobson/05d72d37d771eb4bb13f

[landlessness]

I understand the server part. Thanks for the heads-up. I look forward to the next rev.

As for the device part, is that also part of a future release? Or should it be working now? If now, then is the key part to include the provision() function? I have a discover function working already.

[mdobson]

yep. Provision will help keep the ids consistent. Link below is to a basic
use of provision.

https://github.com/zettajs/zetta/blob/master/sample/BasicServer/devices/Spark/index.js

--
Matthew Dobson | apigee https://apigee.com/ | m: +1.734.634.5472 |
twitter @mdobs http://twitter.com/mdobs @apigee
https://twitter.com/apigee

On Fri, Oct 10, 2014 at 3:07 PM, brian mulloy [email protected]
wrote:

I understand the server part. Thanks for the heads-up. I look forward to
the next rev.

As for the device part, is that also part of a future release? Or should
it be working now? If now, then is the key part to include the provision()
function? I have a discover function working already.

—
Reply to this email directly or view it on GitHub
#9 (comment).

[landlessness]

thanks.

although I don’t want to understand what all is going on here, it sounds like I need to in order to build the driver well.

if there an explanation somewhere?

when I call provision() what is actually happening under the covers?

same with discover(). what is it actually doing?

-b

On Oct 10, 2014, at 3:10 PM, Matthew Dobson [email protected] wrote:

yep. Provision will help keep the ids consistent. Link below is to a basic
use of provision.

https://github.com/zettajs/zetta/blob/master/sample/BasicServer/devices/Spark/index.js

--
Matthew Dobson | apigee https://apigee.com/ | m: +1.734.634.5472 |
twitter @mdobs http://twitter.com/mdobs @apigee
https://twitter.com/apigee

On Fri, Oct 10, 2014 at 3:07 PM, brian mulloy [email protected]
wrote:

I understand the server part. Thanks for the heads-up. I look forward to
the next rev.

As for the device part, is that also part of a future release? Or should
it be working now? If now, then is the key part to include the provision()
function? I have a discover function working already.

—
Reply to this email directly or view it on GitHub
#9 (comment).

—
Reply to this email directly or view it on GitHub.

[mdobson]

No worries. I'll break down the process.

• Scout#discover

  • This method is used for when devices have never been found.
  • When a scout is wired up into the system a listener is placed out
    for a specific protocol
  • When something is actually found discover is called, and that
    instantiates the driver.

   - It will make sure the device has a uuid
   - It makes sure it's exposed in the API
   - It will make sure all the extra args are sent to the constructor
   that you specify as well.
  

  • Scout#provision
  • This method is typically used for already existing devices
  • When a scout is wired into the system a listener is placed out for
    a specific protocol
  • When something comes online we query the registry to see if it's
    come online before
  • If it has we then transfer data to it from the registry
    • It gives the device it's previous uuid
    • Makes sure any user data is given to it as well
    • It will give the device it's last initial state as well
  • Scenario
  • We'll use the Hue driver as an example
  • Zetta starts up
    • We .use() the hue device
    • That scout will search for the hue device
    • Scout finds a hub
    • The scout looks up using a unique hue id to see if it has been
      in the registry before
    • It hasn't found it in the registry
    • The scout uses discover
      • It gets saved in the registry at this point
    • We perform the register transition on it, and get an access token
      • We update the registry with this token
    • Zetta crashes!
  • Zetta starts up again
    • We .use() the hue device again
    • The scout will search for the hue device
    • Scout finds a hub
    • The scout looks up using a unique hue id to see if it has been
      in the registry before
    • It finds it in the registry
    • The scout uses provision
      • It takes data found in the query and creates a device for
        exposing in the API
    • The hue is set to color-loop, and doesn't have to be
      authenticated again because we use the saved data

Sorry for the wall of text. Hopefully this clears some things up.

-Matt

--
Matthew Dobson | apigee https://apigee.com/ | m: +1.734.634.5472 |
twitter @mdobs http://twitter.com/mdobs @apigee
https://twitter.com/apigee

On Fri, Oct 10, 2014 at 4:08 PM, brian mulloy [email protected]
wrote:

thanks.

although I don’t want to understand what all is going on here, it sounds
like I need to in order to build the driver well.

if there an explanation somewhere?

when I call provision() what is actually happening under the covers?

same with discover(). what is it actually doing?

-b

On Oct 10, 2014, at 3:10 PM, Matthew Dobson [email protected]
wrote:

yep. Provision will help keep the ids consistent. Link below is to a
basic
use of provision.

https://github.com/zettajs/zetta/blob/master/sample/BasicServer/devices/Spark/index.js

--
Matthew Dobson | apigee https://apigee.com/ | m: +1.734.634.5472
|
twitter @mdobs http://twitter.com/mdobs @apigee
https://twitter.com/apigee

On Fri, Oct 10, 2014 at 3:07 PM, brian mulloy [email protected]

wrote:

I understand the server part. Thanks for the heads-up. I look forward
to
the next rev.

As for the device part, is that also part of a future release? Or
should
it be working now? If now, then is the key part to include the
provision()
function? I have a discover function working already.

—
Reply to this email directly or view it on GitHub
<
https://github.com/zettajs/zetta-browser/issues/9#issuecomment-58702176>.

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
#9 (comment).

[landlessness]

That does help. Very clear.

So, at this point I think I understand why I as the scout author would need to create a discover method: most importantly seems to be mapping to my device constructor at the time of discovery. Zetta doesn't know how to call the constructor otherwise. Cool.

I can also understand why at times I might want to get my hands on the provision function: to have control at a critical point of device re-discovery.

But I don't understand why I NEED to create a provision function for what feels like ought to be default behavior. This logic:
if(results.length) {
self.provision(results[0], SparkDriver);
cb();
} else {
seems like it ought to be taken care of by Zetta unless I indicate otherwise. It just feels like extra work. And something I will forget and/or mess up. I can't make it better only the same or worse.

That is the aspect that I'm still not understanding.

Are there common situations where including that logic would be a mistake?

Sent from my iPhone

On Oct 10, 2014, at 7:55 PM, Matthew Dobson [email protected] wrote:

No worries. I'll break down the process.

• Scout#discover
• This method is used for when devices have never been found.
• When a scout is wired up into the system a listener is placed out
  for a specific protocol
• When something is actually found discover is called, and that
  instantiates the driver.
• It will make sure the device has a uuid
• It makes sure it's exposed in the API
• It will make sure all the extra args are sent to the constructor
  that you specify as well.
• Scout#provision
• This method is typically used for already existing devices
• When a scout is wired into the system a listener is placed out for
  a specific protocol
• When something comes online we query the registry to see if it's
  come online before
• If it has we then transfer data to it from the registry
• It gives the device it's previous uuid
• Makes sure any user data is given to it as well
• It will give the device it's last initial state as well
• Scenario
• We'll use the Hue driver as an example
• Zetta starts up
• We .use() the hue device
• That scout will search for the hue device
• Scout finds a hub
• The scout looks up using a unique hue id to see if it has been
  in the registry before
• It hasn't found it in the registry
• The scout uses discover
• It gets saved in the registry at this point
• We perform the register transition on it, and get an access token
• We update the registry with this token
• Zetta crashes!
• Zetta starts up again
• We .use() the hue device again
• The scout will search for the hue device
• Scout finds a hub
• The scout looks up using a unique hue id to see if it has been
  in the registry before
• It finds it in the registry
• The scout uses provision
• It takes data found in the query and creates a device for
  exposing in the API
• The hue is set to color-loop, and doesn't have to be
  authenticated again because we use the saved data

Sorry for the wall of text. Hopefully this clears some things up.

-Matt

--
Matthew Dobson | apigee https://apigee.com/ | m: +1.734.634.5472 |
twitter @mdobs http://twitter.com/mdobs @apigee
https://twitter.com/apigee

On Fri, Oct 10, 2014 at 4:08 PM, brian mulloy [email protected]
wrote:

thanks.

although I don’t want to understand what all is going on here, it sounds
like I need to in order to build the driver well.

if there an explanation somewhere?

when I call provision() what is actually happening under the covers?

same with discover(). what is it actually doing?

-b

On Oct 10, 2014, at 3:10 PM, Matthew Dobson [email protected]
wrote:

yep. Provision will help keep the ids consistent. Link below is to a
basic
use of provision.

https://github.com/zettajs/zetta/blob/master/sample/BasicServer/devices/Spark/index.js

--
Matthew Dobson | apigee https://apigee.com/ | m: +1.734.634.5472
|
twitter @mdobs http://twitter.com/mdobs @apigee
https://twitter.com/apigee

On Fri, Oct 10, 2014 at 3:07 PM, brian mulloy [email protected]

wrote:

I understand the server part. Thanks for the heads-up. I look forward
to
the next rev.

As for the device part, is that also part of a future release? Or
should
it be working now? If now, then is the key part to include the
provision()
function? I have a discover function working already.

—
Reply to this email directly or view it on GitHub
<
https://github.com/zettajs/zetta-browser/issues/9#issuecomment-58702176>.

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
#9 (comment).

—
Reply to this email directly or view it on GitHub.

[mdobson]

Nope. The only scout that I know of where this set of functionality is well harnessed is the hue module for Zetta.

CC: @AdamMagaluk Remember your motivations for this stuff at all?

[AdamMagaluk]

The main reason for having .provision() vs .discover() is to allow device re-discovery and allowing a device to not be created by zetta if it was already online.

If I understand your issue @landlessness you would expect zetta to figure out if the device was already in the registry vs a new device then run the correct logic behind each method. Currently zetta does not have enough information to know if a device is unique/existing, zetta only has the device type and zetta's id. In the case of the Hue the scout it determines if the hub/bulb are unique based on their hubId and bulbId on the driver, these id's come from ids built into the hardware which many devices will have in the form of a MAC address or serial number.

Currently all we allow is a scout author to create a unique query to figure out which parameter on a device is the unique and run the desired logic when the query returns.

There was a card in the backlog (or maybe freezer now) that addresses this issue with regards to finding out if there could be better ways of doing this.

Few options i've explored:

a) Add some property on the config that would determine if its unique. config.unique(bulbId). Then would have information to perform a query on all hue bulbs that match that id.

b) The scout author could pass zetta the query for each type of device it's scouting for. This would at least remove the responsibility of running the query from within the scout.

[landlessness]

ok. lots to think about there.

On Oct 13, 2014, at 10:02 AM, Adam Magaluk [email protected] wrote:

The main reason for having .provision() vs .discover() is to allow device re-discovery and allowing a device to not be created by zetta if it was already online.

If I understand your issue @landlessness you would expect zetta to figure out if the device was already in the registry vs a new device then run the correct logic behind each method. Currently zetta does not have enough information to know if a device is unique/existing, zetta only has the device type and zetta's id. In the case of the Hue the scout it determines if the hub/bulb are unique based on their hubId and bulbId on the driver, these id's come from ids built into the hardware which many devices will have in the form of a MAC address or serial number.

Currently all we allow is a scout author to create a unique query to figure out which parameter on a device is the unique and run the desired logic when the query returns.

There was a card in the backlog (or maybe freezer now) that addresses this issue with regards to finding out if there could be better ways of doing this.

Few options i've explored:

a) Add some property on the config that would determine if its unique. config.unique(bulbId). Then would have information to perform a query on all hue bulbs that match that id.

b) The scout author could pass zetta the query for each type of device it's scouting for. This would at least remove the responsibility of running the query from within the scout.

—
Reply to this email directly or view it on GitHub.