Data flood from Light/Temperature sensor

Python
1

After upgrading to Dia 1.2.19 over the weekend, I’ve uncovered a bug in the XBeeSensor driver and behavior from the actual sensor that I believe is new.

Immediately after starting Dia and once the XBee sensor is seen on the network and configured, I start seeing the following exception logged, approximately 60 times:


XBeeDeviceManager(xbee_device_manager):
Exception during rx callback for addr = ('[00:13:a2:00:40:55:9b:a5]!', 232, 49413, 146, 1, 0)
Traceback (most recent call last):
File "src/devices/xbee/xbee_device_manager/xbee_device_manager.py", line 328, in __select_rx_cbs_for
File "src/devices/xbee/xbee_devices/xbee_sensor.py", line 405, in sample_indication
File "src/devices/xbee/xbee_devices/xbee_sensor.py", line 406, in 
 KeyError: 'AD1'

I’ve modified the sample_indication method so that this exception is properly handled; what’s happening is that the io_sample dict doesn’t contain values for AD1, AD2, or AD3 keys; DIO11 (low battery) seems to be there reliably, however.

After implementing this fix, however, the inrush of packets is causing a bottleneck. My logging shows that the sample_indication method is processing 2-3 packets per second for 30 seconds, which effectively stops any other packets from being processed in a timely fashion (although they don’t seem to get dropped). I’ll accept that my additional logging may now be contributing to this overhead, but the stack traces that were being logged before took a non-trivial amount of time…

After the initial startup of Dia, I see this burst of packets happening at an irregular frequency: 8 times between noon and 1pm today, only once between 11 and noon, 7 times between 10 and 11, 5 times between 9 and 10, and only twice between 7 and 9.

I don’t know for sure that this is brand new behavior introduced by Dia 1.2.19, but I suspect it is.

Any thoughts on what might be causing this? What else can I provide to help diagnose the problem?

2

Confirm your battery isn’t low/dying.

Confirm that the XBee is correctly configured (meaning the D1/D2/D3 are set to 2 for analog input).

The routine which the ‘sample_indication’ uses MERELY parses the raw binary data packet, and if the flags for AD0 to Ad3 are missing, so is the field in the output dictionary. If the low-battery signal is being sent, then it will LACK the AD1 etc - it is only the digital bits.

On my LTH:

  • D1/D2/D3 are 2
  • D0/D5/D7/PO are 1
  • D4/D6/P2 are 0
  • P1 is 3
  • IC is just 0x0800

I can’t say why the flood, but a poorly set IC CAN create a flood since it creates 1 packet each time it detects change.

In fact, could this be only that your “low_battery” signal has finally gone True? I don’t know if this causes bugs - I personally turn those OFF & set IC to zero (0) since the “low_battery” bit is included within every data packet anyway. The report on change doesn’t seem useful to me.

3

Thanks, Lynn. All of my settings match yours. I replaced the batteries; we’ll see if that helps!

4

I replaced the batteries in my sensor and I don’t seem to be losing other data, now. I’m cautiously optimistic that the problem’s fixed, now. :slight_smile: Thanks!

5

I think the upgrade to 1.2.19 and the problem was a coincidence.

If you look at the xbee_sensor.py file, then you’ll see that method sample_indication() blindly assumes AD1, AD2, AD3 and DIO11 all exist. If (as example) AD1 was not in the sample (as it won’t be in a digital IC/change alert), then the call aborts, so ironically once the low-battery alerts start arriving, the low_battery channel never gets updated at that time. It will only update the next time the sensor sends analog data.

So it is a bug/logic issue which has probably existed since first rev of that driver.