Initial test (sample of one, so use with caution).

So far, so good.

I have been running two modules overnight, one rebooted during the night (don't know why), but the other ran all night, and is still publishing (I have a third module another running different code that stopped publishing a couple of hours after booting, so the publishing problem is still there).

So testing the one module that has been publishing for 10 hours - reedswitch and accelerator interrupts no longer cause reboots.

Here are my logs from this morning (wife leaving for work):

MCThings/000111C2/BatteryVoltage 2910
MCThings/000111C2/Temperature 17.93
MCThings/000111C2/Rssi -93
MCThings/000111C2/KnockEnable True
MCThings/000111C2/PublishEnable True
MCThings/000111C2/Door False
MCThings/000111C2/Door 0.0
MCThings/000111C2/Rssi -86
MCThings/000111C2/Uptime 36778
MCThings/000111C2/UptimeString 0:10:12:58
MCThings/000111C2/Door 0.0
MCThings/000111C2/Rssi -90
MCThings/000111C2/Door True
MCThings/000111C2/Door False
MCThings/000111C2/Door 0.0
MCThings/000111C2/Rssi -91

Just to explain this log:

These:
MCThings/000111C2/Temperature 17.93
MCThings/000111C2/Rssi -93
Are decoded beacons. These:
MCThings/000111C2/KnockEnable True
MCThings/000111C2/PublishEnable True
MCThings/000111C2/Door False
Are actual publishing events.

So this:
MCThings/000111C2/Door 0.0
MCThings/000111C2/Rssi -86
is the door state decoded from a beacon (not a publishing event, so it's not real-time).

This is how I can tell that publishing has stopped (or is still going as it is in this case), but the program is still running, as I just get the decoded beacons in that case. Uptime over 32768 is not encoded in the beacons, (as I only have 2 bytes to store the value in), so if publishing has stopped, but uptime is over 9 hours, I can't tell how long it has been running. I mention this because that is the state of my third module currently.

The last Door True/Door False is her leaving, and would normally have caused a reboot (without publishing). Notice uptime at 10 hours, 12 minutes 58 seconds. This is good. The module did miss a transition a few minutes later (when she came back for something), but this is just a failure to publish, the module continued to work afterwards.

I did notice the signal strength was a little low, so I repositioned the gateway slightly, and conducted a few more test. This is my log of some door open/close tests and a "knock" (accelerator interrupt) test:

MCThings/000111C2/BatteryVoltage 2910.0
MCThings/000111C2/Rssi -77
MCThings/000111C2/Door True
MCThings/000111C2/Door False
MCThings/000111C2/Temperature 18.187500
MCThings/000111C2/Door True
MCThings/000111C2/Door False
MCThings/000111C2/Doorknock True
MCThings/000111C2/Door 0.0
MCThings/000111C2/Rssi -78
MCThings/000111C2/Door 0.0
MCThings/000111C2/Rssi -79
MCThings/000111C2/Door 0.0
MCThings/000111C2/Rssi -79
MCThings/000111C2/Door False
MCThings/000111C2/KnockEnable True
MCThings/000111C2/PublishEnable True
MCThings/000111C2/Door 0.0
MCThings/000111C2/Rssi -81
MCThings/000111C2/Door 0.0
MCThings/000111C2/Rssi -79
MCThings/000111C2/Uptime 38240
MCThings/000111C2/UptimeString 0:10:37:20

I opened/closed the door twice, waited then "knocked" on the door to generate an accelerometer interrupt ("Doorknock True"), and waited for the uptime report to prove the module had not rebooted.

I have another module running the same code (but that is the one that rebooted during the night). That also worked correctly, but has only 4 1/2 hours uptime.

So altogether much better results with the new version of firmware.

Keep up the good work! Now if we could just get the "stop publishing" bug fixed...