[zb4osgi Dev] Attribute subscription - why not attribute specific?

Philipp Buluschek philipp.buluschek at adhoco.com
Wed Dec 3 09:37:39 CET 2014

Hi Stefano

What you propose is basically what happens today, only that today you 
can also get notified when the attribute is not present at all.
In both cases, the listener still has to iterate over all transmitted 
attributes/values to check if and where its expected value is present.

Why not simply have a listener interface like:

   public interface ReportListener {
       public void  receivedReport(Object newAttributeValue);

and let the dispatcher or better the ClusterFilter do the job of 
selecting which Subscription and listener gets which event.

Are there use-cases you know of, where getting notified of several 
(unrelated) values of one cluster in one call has benefits? If one is 
specifically interested in getting updates for two attributes, one can 
register the same listener in two attribute subscriptions...

Regards Philipp

On 02.12.2014 18:53, Stefano Lenzi wrote:
> Hi Philipp,
> I think that the current behavior is just a bug. In fact, the ZigBee 
> device may send a Report Attribute message containing multiple 
> attributes for optimizing the network overhead, but the ReportListener 
> (as it is defined) is linked to a specific subscription which is 
> linked to a single attribute, thus the callback should happen only 
> when the attribute reporting not only is coming from the right 
> Device/Cluster, but also from the Attribute that the developer decided 
> to subscribe to.
> So, I think that it is reasnoable to recieve notification containing 
> several attributes as long as at least the one of the attributes is 
> the ont that the developer is subscribed for.
> Do you agree?
> Ciao,
> Stefano
> Il 02/12/2014 17:14, Philipp Buluschek ha scritto:
>> Hi Stefano, hi all
>> When subscribing for attribute reports ( Attribute.getSubscription() 
>> etc.), the actual reports/events which are sent to the listeners 
>> contain all reported attributes, not just the ones you subscribed to.
>> For example: you subscribe with listener 1 to get attribute 1 reports 
>> , and (unrelated) with listener 2 to get attribute 2 reports. Now if 
>> both attributes are part of the same cluster, any report will be 
>> calling both listeners.
>> If a report message from Att1 comes in, it gets reported to both 
>> listener 1 and 2. Listener 2 is not interested in reports from 
>> attribute 1 and must ignore this call, as it is not relevant for it.
>> I would have expected Listener 1 to get only reports from Att1 and 
>> the same for 2.
>> Why was it chosen to do it like this? Or is this unintended? (in 
>> which case I can file a bug)
>> NB: relevant code is in 
>> SubscriptionBase.ReportListenerNotifier.handleCluster(ZigBeeDevice, 
>> Cluster)
>> Regards Philipp
>> _______________________________________________
>> Dev mailing list
>> Dev at zb4osgi.aaloa.org
>> http://zb4osgi.aaloa.org/mailman/listinfo/dev
> _______________________________________________
> Dev mailing list
> Dev at zb4osgi.aaloa.org
> http://zb4osgi.aaloa.org/mailman/listinfo/dev


  Philipp Buluschek, Dr.-Ing.
  Adhoco AG
  Althardstr. 70
  CH-8105 Regensdorf

  Phone:  +41 52 264 5081
  Mobile: +41 79 800 8218

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://zb4osgi.aaloa.org/pipermail/dev/attachments/20141203/99817b50/attachment.html>

More information about the Dev mailing list