mc-Products => mc-Module => Topic started by: Nick_W on September 09, 2016, 09:01:27 am

Title: Modules drop off network
Post by: Nick_W on September 09, 2016, 09:01:27 am

I have had several modules running now for some time. I have noticed the following behavior:

Module 1, which has been running continuously for many days, transmits data and beacons normally. It is running a very simple program, which transmits every 10 seconds. Range to the gateway does not seem to be a factor, as this is actually the module furthest away from the gateway.

Module 2, is close to Module 1, and is running a complicated sensor program, using the external BME280 sensor, it also transmits every 10 seconds. Occasionally this module reboots (I transmit boot messages), and sometimes the beacons disappear for a while, but then re-appear later. So question, why would beacons stop and start? I can understand rebooting (perhaps a bug in my program, or memory error, Watchdog reset etc).

The real problem is Module 3, which is currently a door open/close sensor, and hence has to be reliable. It is running a complicated program, that uses the accelerometer to detect door knocks. It is closest to the gateway, but I have noticed over a few days operation that it will stop sending for a while. It currently transmits door status every 1 minute. What seems to happen is that updates stop, but beacons continue. The beacon data does not update however - indicating to me that the program has stopped (not just the transmitting). Then, some time later (minutes to hours) the module reboots, and starts transmitting again. I just observed this, and at the time of the reset, the beacons stopped sending. So now it is transmitting data once per minute, but no beacons! Battery voltage is currently 2.6V, so it's running down slightly.

My ultimate plan is for the door sensor not to transmit every minute (to save power) but to use the beacon to send status, actual transmissions would only happen on an event (such as door open, door knock detected etc). The problem is that data transmissions are unreliable, and now the beacons seem unreliable also.

Quick follow up - as soon as I transmitted to the module (sent an enable knock sensor message), the beacons reappeared! I may be wrong about the beacons data not updating - there is a bug which makes this appear to be the case. Fixing that now...

My code is here (
You need the MQTT and MMA8652 libraries from the same repository (in libraries) for the project.

Maybe you could take a look to see if I have something wrong, or to see if you get the same behavior. No external hardware required, should work as is on a standard module (110 I'm using). You'll need a magnet to simulate a door open/close (I have mine on an actual door).

Let me know what you think...
Title: Re: Modules drop off network
Post by: kbrooking on September 09, 2016, 10:36:03 pm
Hello Nick,

How are you transmitting the boot messages and capturing in your code?
Title: Re: Modules drop off network
Post by: Nick_W on September 09, 2016, 10:46:25 pm
Just publishing a "boot" message via mqtt in the Shared Event Boot()

Like this:

Code: [Select]
Class Main
    Shared Event Boot()
         //mqtt.publish("topic","booted").  // put your message here (I have an mqtt class for publishing)
     End Event

     //other things here

End Class

The boot event is the first thing run after the module resets, so you initialize variables, instansiate objects, etc. here.

Hope this explains.
Title: Re: Modules drop off network
Post by: Nick_W on September 10, 2016, 09:47:00 am

I believe I was wrong about the program not running, I now think it continues to run fine (maybe reboots from time to time, but still).

The problem is communications. I have tracked it down to one wooden interior door. With this door closed, communications becomes intermittent. With it open, communications is good. I have relocated my gateway, and will monitor. I have also implemented a scheme that tells me if the module is offline.

Still don't know what the deal is with disappearing beacons though.