Polling for broadcast messages in ZStack

As I remember, the default value of NWK_INDIRECT_MSG_TIMEOUT is 7 which means the message will be only hold for 7 ms on the parents. I would suggest you to enlarge this value to at least more than device polling rate.

Thanks for the quick reply!

I spent a long time looking at those different polling parameters, and if I understood them right (which, admittedly, I may not have done) that 7 means the messages are held for 7 seconds (NWK_INDIRECT_MSG_TIMEOUT X CNT_RTG_TIMER X RTG_TIMER_INTERVAL = 7 X 1 X 1000 = 7000 ms).  And with the current parameters, it works just fine for polling if I send the message unicast, just not if I send the message as a broadcast.  Would the router hold messages for different lengths of time for broadcast messages vs. unicast messages?

In Z-Stack Compile Options.pdf, it says that NWK_INDIRECT_MSG_TIMEOUT means Number of milliseconds the parent of a polling End Device will hold a message. However, the document might be wrong. As I remember, the broadcast data seems not kept on coordinator or router. It is no grantee that ZED can receive broadcast message.

Hmm, you're right, it does say that.  I tried significantly increasing NWK_INDIRECT_MSG_TIMEOUT (to 7000) as well as significantly decreasing POLL_RATE on the end device (to 10ms), but it still doesn't receive any broadcast messages.  (I should note, by the way, that if I set RxOnIdle to TRUE, it will receive broadcast messages, which is why I think it's an issue with polling and not something else).

I'm beginning to think that broadcast data isn't kept for polling, although the developer's guide suggests otherwise, and I thought I saw postings in the forum saying that people had gotten polling of broadcast messages to work.  If it doesn't save broadcast messages, will I just have to do something like iterate through the list of associated devices and unicast messages to each?

In my projects, I always use unicast to send messages to ZED and I would suggest you compliant to it.

Cool, I'll give that a try then.  Thanks for your help!

As I know, this is about Zigbee spec and no Zigbee solution vendor would keep broadcast message on ZC/ZR.

Hi Chen,

               how could ZC check  Msg（ManufacturerName，HWRevision）of all the device in the network,

               unicast ？ or broadcast ？ 

               if ZED was on PM2 mode,  and POLLRATE is 60S？ how could ZC make sure the ZED will get the read MSG？

Hi Bolmsjo，

     do you means the ZED should send the MSG（which included its base device information and use MAC address？） to ZC again and again for letting ZC knows which device is on the network？

     if like that ，should we make a timeout event every 60s for achieve it in coding？

Hi The Seven,

You can implement supervision signal sent from ZED to ZC. I won't suggest 60 seconds duration to send supervision signal because it would use up ZED's battery very soon. However, this depends how fast you want your system detects any device doesn't exist in your system. For example, if you have to know any device is out of radio coverage not longer than 5 minutes, than you have to send supervision no more than 5 minutes.

Thank you, Magnus. This is exactly how I read the documentation, and I lost a couple days trying to figure out why my end devices were not getting messages that were broadcast, when they were getting messages that were unicast. I had made sure that the BCAST_DELIVERY_TIME was fine, checked that it was being received when the ZED had the receiver_on_when_idle flag on, played with different settings on the AF_DataRequest flags, I was stumped. The documentation clearly leads one to believe that broadcasting to end devices is possible, or at least it doesn't say it doesn't work, especially since there are separate flags for all devices and router+coordinator devices, which means to me that when the all devices flag is set for a broadcast, then end devices should get them.

Anyway, now that I know I can get around the problem, and I hope this thread is helpful to those in the future who also wish to broadcast messages to children end devices.

Hi Magnus！

     Thanks for you reply！

     but i have different idea of your.

     1.  Turn off polling to preserve battery life time in sample sensor node is not good for User Experience，it seems we need to cut some functions.

           How could we let the consumer knows how many sensor is working now ?

           And how could consumer knows when should be change the battery?

           As you said "You'll be amazed how much battery you'll save by turning off the poll. You'll double life time at least."

           yes i will ,i do really care about the  User Experience!

    2.    Send the data to routers and let rounter keeps the Msg ,then  resend the Msg to   ZED (when wake up)

           if there is not any router, how could we do ?

Best Regards!

Hi Seven

Number of sensors: the ZC knows because all ZED's reports to it - so customers can request a summary report from the ZC

Battery change: if a sensor no longer reports, the ZC will detect this (reports missing) and may notice the user. Another way is to include battery voltage in the reporting to the ZC and notify user when voltage drops. On the other hand - if you use Li-battery you want see a voltage drop before the battery dies - in that case you need to monitor battery status in another way. 

User experience: don't know what you mean. Users usually don't care about polling

If you only have the ZC, then its a star network where ZC is the parent and all ZED's will be listed in ZC's assocation table so you can just scan through that table and unicast directly to each and every ZED (but then you need to have the poll turned on).

Best /m

Hi Magnus~

     Maybe i make a mistake of your opinion.

     Do you mean turn off polling but report  activly to its parent in cycle？

Hi Seven,

My take is: keep it as simple as possible. Polling yes if you need 2-way communication between the sleeping device and the parent. But if you really don't need 2-way communication, leave it out - just let the device report its message and then go back to sleep. Regardless of which method you choose, an end device will anyway poll its parent a single time in conjunction with transmitting the message so even with polling turned off, there is always a kind of two-way communication enabled, although not so frequent as a regular poll would be.

Polling / no polling also touches the robustness of the system. Nobody wants a system where end devices suddenly dies because the battery drained prematurely and unexpectedly. The upside of skipping poll is: you'll get a more deterministic system with few uncertainties built in, meaning that you'll easily double the battery life time to perhaps 20 year or more. Although a battery in itself only cost a few dollar, to change it can easily cost 100 USD or more (you have to call in maintenance people and so on....), so battery life time is in my mind the most critical factor of all. 

On robustness: Wireless technologies are inherently susceptible to disturbances and one must accept that messages doesn't always get through and design for it. How many times a poll may fail before an end device will start a rejoin (a rejoin event is very costly from battery standpoint) is set by MAX_POLL_FAILURE_RETRIES (default is 3 which in my opinion is way to small). One can therefore argue that a no-poll unit will always be more robust than a polled unit because the number of possible failures / rejoins will always be much smaller during its lifetime. Same thing with APS ACK which from a theoretical standpoint is a nice feature but from a battery standpoint pretty dangerous. Use it when you must but else leave it out. If you're not cautious, APS-ACK can cause your battery to go down faster than you can blink.

Best / m