v0.3.8

Avoid repeat sending of battery low by disabling interrupt, in the case that battery voltage bounces around.

v0.3.7

Compiling now with SDCC version 4.3.0

v0.3.6

Changes to the code should settle down by now.
By default sending a packet count and battery status regularly are disabled by default.

However, a startup check or interrupt is still available to indicate a low battery with radio code.
Alarm trips will now only send every ten minutes or battery status (if enabled) about twice per hour.
Of course switch interrupts send once immediately.

The goal is to save battery, avoid periodic transmission (prohibited by CFR), and avoid sending multiple packets at a time which can confuse some receivers and interfere with users that have dozens of sensors.

I think the goal now should be to test firmware with as many receivers as possible to confirm packet reliability (or not).

v0.3.5

We need to obey the federal register for alarm and periodic transmission above 70 MHz:
https://www.law.cornell.edu/cfr/text/47/15.231

This dictates the direction that some features need to go.
However, it seems we can emphasize alarm conditions and send some battery state when switches are human actuated.

Delay between different packets (guard time) was increased a little to improve receiving at sonoff r2 v2.2.

The code needs to now be mostly unchanged so that reliability testing with different receivers can proceed.
Also the consequence on home automation software of including a packet count in the upper four bits of the sent code needs to be considered based on user reports.

v0.3.4

Using conditional compilation to choose between features (e.g., interrupt versus heart beat modes).
With every feature enabled there is potential for redundant code sending or missing events.
Also it was cumbersome to stay under 1kb of flash code space.

There is also a new debug feature that ORs a packet count with the sent code.
This should help in detecting missed events versus missed packets.

v0.3.3

Main bug fixed was to limit flash code size.
End of flash space above 1017 bytes contains unique id and so cannot contain program bytes.
Failure to limit code space was causing lots of confusion between model 101 and 104 MCUs.

v0.3.2

There seems to be a difference between boards containing mcu 101 versus mcu 104.
Startup check for tamper closed (to enter bootloader) appears to be getting stuck on 101 board.
My 101 board did not come with a tamper switch installed and also had a broken radio.
So it makes troubleshooting difficult, however I do not even get a startup blink with tamper check so that must be the problem.

I need to examine the circuit boards more closely and scrutinize code as well.
The tamper check should just be skipped over since no tamper switch is installed...

v0.3.1

The unique id should now work on both mcu parts.
Added a startup check so that if tamper switch is held on power up we reset processor into bootloader.

Events seem to be sending okay.
However we are missing multiple tamper presses.
Let's check out stock sensor and see if it can detect multiple presses or if we only need to distinguish a quick press/release but not multiple quick presses/releases.

v0.3.0

Added very basic switch debouncing. Added small delay between retransmissions to give receive processing time to interpret and/or wake up.

v0.2.0

Additional discussion of timings with stock versus modified sonoff bridge rf receiver hardware were included in source files and readme. This should not change the generated hex file but producing a new release in line with recent commit.