Hi there,
I have been fiddling around with Dia, a Connect Port X4, several L/T/H sensors, and an AIO.
All my devices are sleeping devices, waking up every minute to send their samples.
I’m using Autoenum (Dia 1.3.8).
I have setup XBeeDeviceManager with 5 worker threads, and modified DDO_GLOBAL_TIMEOUT to 90.0 (assuming seconds, assuming 30.0 was too short for 60-second sleeping devices).
Still, it takes over 2 hours after reboot to get all devices back up and running.
I did notice a few things that might be in the way:
frequently: “XBeeConfigBlockDDO.apply_config: DDO req to ‘[xx:xx:xx:xx:xx:xx:xx:xx]!’ of ‘NN’ failed (ddo_set_param: error setting DDO parameter.) (NN being any of P1, D2, D1, DH, IC, etc.)”
immediately followed by
“Xbee Worker Thread: Failed attempt - will retry, ddo_set_param: error setting DDO parameter.”
then
“worker thread assigned to [xx:xx:xx:xx:xx:xx:xx:xx]!'” . (same MAC address).
In the current case, this has been happening 22 times for one single device, 11 times for another one, 7 times for a third one, 4 for a fourth one, in the course of past 2 hours post_reboot, and I’m yet to get them all online !
not so frequently, but puzzling:
XBeeDeviceManager(xbee_device_manager): exception while preparing network for sleep support: ddo_get_param: error fetching DDO parameter.
Traceback (most recent call last):
File “xbee-sensor-site/src/devices/xbee/xbee_device_manager/xbee_device_manager.py”, line 955, in _xbee_device_configuration_heuristic
File “xbee-sensor-site/src/devices/xbee/xbee_config_blocks/xbee_config_block_sleep.py”, line 229, in prepare_network
File “xbee-sensor-site/src/devices/xbee/xbee_config_blocks/xbee_config_block_sleep.py”, line 134, in __is_sleep_mode_available
File “xbee-sensor-site/src/devices/xbee/xbee_device_manager/xbee_device_manager_configurator.py”, line 112, in ddo_get_param
File “xbee-sensor-site/src/devices/xbee/common/ddo.py”, line 75, in retry_ddo_get_param
Exception: ddo_get_param: error fetching DDO parameter.
This last issue showed 4 times in the same 2-hour run.
I’m probably doing something wrong here, but I don’t have a clue what it is…
Your best solution is to use the ‘skip_config_addr_list’ setting for the xbee_devcie_manager. The 5 worker tasks is probably hurting you more than helping because the ‘DDO’ commands are rather single-threaded so you just have 5 tasks fighting over a single context anyway.
Unfortunately, your setup is the worst of all worlds. Having the end device NOT sleep (or sleep & wake say in 15 seconds) works fine. Having the end device sleep for 15 minutes or hours works … not bad. (I do that all the time)
The problem is like this:
one of your devices (which is already configured) sends in a data report, this causes Dia to assign a worker thread.
yet because the system is ‘starting up’, something else hogs enough XBee-channel time so that by the time Dia tries to check the config of your good device, it has gone to sleep.
unfortunately, this causes that worker to block for up to a minute, waiting for a response. But the request is not resent.
Unfortunately, the request will be discarded by the time your device wakes again (after 28 seconds), so setting the DDO_GLOBAL_TIMEOUT didn’t really help as this only effects Python, not the underlying XBee firmware.
Worse, by the time the DDO block exits, all of your other nodes have talked, so get queued for worker attention. So in effect Dia is always wasting it’s time on the wrong nodes (the ones which just went back to sleep in a First-In-First-Out design - it should probably time-stamp the activity & discard it after a few seconds).
I routinely have nodes sleeping for 10 to 60 minutes, and it doesn’t suffer this since the probability of 2 end devices waking within the same 30 seconds is much lower.
I am not sure the answer, other than changing the XBee firmware to allow checking the config with something other than DDO (the ‘set AT commands’). For example, if normal serial requests were used, then there is NO block on the coordinator waiting for a response.
one of your devices (which is already configured) sends in a data report, this causes Dia to assign a worker thread.
Is this a behavior I could change in Dia, assuming I have the right Python skills, or is it in a compiled library, unless perhaps it would not help at all?
unfortunately, this causes that worker to block for up to a minute, waiting for a response. But the request is not resent.
Why a minute? Can I change that? I’m assuming that by “request is not resent” you mean “by the XBee firmware”, nothing that could be changed outside said firmware.
I routinely have nodes sleeping for 10 to 60 minutes, and it doesn’t suffer this since the probability of 2 end devices waking within the same 30 seconds is much lower.
So I guess I’ll revert the settings to 1 worker thread, and consider the implications of having my devices sleeping more — even 3 minutes should reduce the probability you mention by as much, right?
What if I wanted to change the device configuration AFTER it’s running? Would that be permitted by Dia?
XBeeDeviceManager(xbee_device_manager): exception while preparing network for sleep support: ddo_get_param: error fetching DDO parameter.
Now, with regards to the exception above, I’m yet to find its root cause. Any idea?
The exception is NO exception. All it is saying is that the end device did not answer. That should be handled more gracefully in the code than it is. A single text line saying "Node X didn’t answer reqest YY’ would be better - and I’m lobbying the powers that be to change it.
ZigBee was designed to be used with fully-powered devcies, or sleeping devices which woke at least every 28 seconds. ZigBee doesn’t require this, but rather leaves the ‘management’ of nodes sleeping longer than 28 seconds as something for you or me to do.
Dia could support changing settings on the fly, but all the pieces aren’t in place. For example, the sleep time is ONLY sync’d to the device at start-up. So you’d need to modify the Dia driver to accept an RCI setting-change, then try to propagate this down to the device next time it’s data-received callback is triggered.