Improvement #35

Blacklisting of device

Added by Stefano Lenzi about 8 years ago. Updated almost 8 years ago.

Status:New Start date:10/02/2010
Priority:Low Due date:10/02/2010
Assignee:Stefano Lenzi % Done:


Category:zigbee.basedriver Spent time: -
Target version:org.aaloa.zb4osgi.zigbee.basedriver-1.X Estimated time:12.00 hours
Has a patch:No Has license agreement signed:No


The ZBD SHOULD provide a blacklist mechanism, for the identification and later ignoring faulty ZigBee device. For example, it is very common for a device to seems registered even if it turn off (i.e. exhausted battery), thus after a certain number of failed attempt to communicate with such device it should be removed from the available ZigBeeDevice service.

The implementation should consider:
  • Controlling the blacklist mechanism by parameters: at least Enable/Disable it
  • It must allows the access to a device that returns to work correctly (e.g. the battery is changed)

Related issues

follows Improvement #64: Base Driver should monitor the health status of device New 10/01/2010

Associated revisions

Revision 640
Added by Stefano Lenzi over 5 years ago

Merging zigbee.basedriver in progress ( refs #183 ), merging incomplete see following note:
- Activator depends to it.cnr.isti.zb4osgi.api.Eventing which is going to be removed?
- NetworkBrowserThreadi, ImportingQueue replace the old discovery algorithm whihc should be added instead of removed ( refs #180 )
- DeviceBuilderThread defines a sort of blacklisting which has to be discussed ( refs #35 )
- ConfigurationService is not used anymore, why?

Fixed wrong end-of-line coding


#1 Updated by Stefano Lenzi about 8 years ago

  • Target version changed from unplanned to org.aaloa.zb4osgi.zigbee.basedriver-0.7.0

#2 Updated by Stefano Lenzi almost 8 years ago

  • Target version changed from org.aaloa.zb4osgi.zigbee.basedriver-0.7.0 to org.aaloa.zb4osgi.zigbee.basedriver-1.X

Moved to the next release cycle

Also available in: Atom PDF