contrary to the example in docs_1.2.19/user/devices/xbee/xbee_devices/autoenum.html the xbee_autoenum device does not need (or want) an extended_address setting.
You are correct, but I would NOT even include the setting as “”. Just delete that line, plus you do NOT need the xbee_device_manager setting in the ‘devices’, because they inherit this from the ‘xbee_autoenum’ base.
You should look at the sample YML in demos\autoenum\dia.yml
I am doing my own testing of this feature. My experience is that sleeping devices are very hard to ‘auto-enum’ since they have to be awake and in the XBee network list to be detected. Are you finding it works well with your sleeping AIO?
I’m not using XBeeAIO (yet), trying to get things going with Sensors and Wall Routers for starters.
I have been having trouble getting the sensors to sleep for the correct amount of time. It turns out that dia wasn’t setting the period multiplier (SN). I wanted 3 minutes, 180000ms = 10 * SP * SN. That was translating to SP=0x30 (48) and SN=0x177 (375), but only SP got set so the sensor only slept 480ms!
Funny thing is that xbee_config_block_sleep.py calculates SN but then neglects to set it. Here’s a patch for xbee_config_block_sleep.py that adds SN to the list of parameters set during sleep configuration:
Index: xbee_config_block_sleep.py
— xbee_config_block_sleep.py (revision 51)
+++ xbee_config_block_sleep.py (working copy)
@@ -93,7 +93,7 @@
for XBee nodes via the :meth:sleep_cycle_set method.
“”"
Sleeping devices are not ONLY hard to ‘auto-enum’, Sleeping devices hard to be configuring by dia also with static-configuration. When device awake for small time period (about 1s) the device manager unable to send all configuration parameters, the device isn’t go to running state. It is big trouble - dia+Sleeping devices.