Local alarm compile

[t-pi]

• Some optimizations to the sound sequencer
• Added alarm sequence & function
• Added userdefines.h parameters for enable and threshold
• Added IotWebConf parameters for enable and threshold
• Alarm will sound once every 10 s (every publish) if
  • accumulated dose rate > set threshold (default 0.5 µSv/h)
  • current dose rate > 3x accumulated dose rate

[t-pi]

Adresses #416

[ThomasWaldmann]

can you please update your master branch and rebase this onto the current master?

[t-pi]

this is mixing a fix/optimization(?) to existing hard-to-get-right code (the sequencer isr / mutex) with a new feature in the same commit. please avoid.

Question: How can I work on basically two branches at the same time? E.g. for the alarm I needed to work on speaker, that's why this got mixed up. Is there a preferred way to work on "lower level" commits in one branch and "higher level" commits in a second one?

[t-pi]

Fixes #416

[ThomasWaldmann]

You could do 2 branches and (re)base the feature branch onto the bugfix branch now and then.

master -> bugfix -> feature

Of course, there could be conflicts now and then depending on how changes overlap.

Or just do the same within 1 branch, but keep fixing and adding stuff in separate commits always. If you need multiple commits for each, you can later use git rebase -i and s(quash) or f(ixup) to merge some commits again, e.g squash fix1 fix2 fix3 commits, squash feature1 feature2 feature2 commits, so you'll end up with 1 fix commit and 1 feature commit.

[ThomasWaldmann]

I am still having troubles to review this / to see why the ISR code got changes / whether they improve the code.

So, may I suggest:

• don't tell "some optimizations", but specifically which / why
• don't tell "adjusted mux_audio back", but specifically tell what you changed and why you changed it.
• differentiate between bug fixes (if you found a bug, tell why it is a bug) and other changes (also tell why)

[ThomasWaldmann]

Thanks!