StaleHandling

From ago control wiki
Jump to: navigation, search

Stale Handling

Current system

"lastseen" time stored in device structure is updated regularly using discover procedure triggered by resolver. Discover procedure sends a command to all devices and only controllers answer to this command returning all handled devices. If a device doesn't respond or doesn't exists, the controller is supposed to not announce the device to the resolver and device will be detected as stale. Moreover developer can use "resumeDevice" and "suspendDevice" functions to force stale status of a specific device.

Pros:

  • Better than nothing

Cons:

  • Need to overwrite reportDevices method in each controller
  • Flood all system components with regular discover command (default each 5mins)
  • event.device.announce event is the answer of discover command that it implied no difference between a new created device or a reported device


New proposal

Resolver catches all device events to keep up to date inventory. It means it is able to know when a device is "alive" or not. So no need to overwrite something specifically while system can do it automatically. But it means a way to customize (or not) the duration after detecting a device is stale or not. This introduces a new structure into device structure (called "parameters") that store all device specific parameters like "staleTimeout" (or temperatureOffset or dashboardDeviceVisibility....) This new structure is specific to each devices, available in inventory and customizable by developers or users (using GUI) sending a command to resolver. This structure is stored regardless of inventory that can be persistent or not (stored into a file or not) and injected within inventory during resolver startup. Side effect of this is resolver doesn't need to perform every 5 minutes a discover command that flood system. I propose to keep it (needed when resolver starts to fill inventory when it isn't persistent) but to launch this command every hours to make sure inventory is up to date. I also propose to replace "event.device.announce" by "event.device.discover" as answer of discover command and to filter this new event on agorpc to avoid flood or remote system. So "event.device.announce" event will be reserved to new created device.

Pros:

  • No need to handle stale status. It is automatically handled by system according to user preferences or developer preferences.
  • It introduces specific device parameters (that can give opportunity to develop specific device details popup)
  • It dedicates event.device.announce to only new created devices.
  • It avoids message flood of GUI

Cons:

  • None of course :)
Personal tools