+1
Auto lock out feature
+1
Firmware version blink feature
Edit: For Anduril
Done: [WIP] [Anduril] Automatically lock after inactivity · SammysHP/flashlight-firmware@feda65f · GitHub
In lockout click 5 times to enable auto lockout. Click 5 times and hold to disable it. If enabled, the flashlight will lock itself after 15 minutes of inactivity in the off state.
@ToyKeeper
That patch is not tested yet and I’d like to hear your feedback. AFAICS there is currently no way to measure time during standby because you don’t know the frequency of the ticks (although the manual says that it is 2 Hz). The EV_click5_hold check has an if(arg==0) like the manual memory feature. Not sure how exactly the events are emitted and if it is necessary. The auto lockout requires TICK_DURING_STANDBY, but I didn’t want to enable it automatically as it might require different configuration for each driver. Thus I added a preprocessor warning if it is not enabled.
edit: Here is another version with configurable timeout. In lockout, click 5 times. Then click the number of minutes you want for the timeout. Even less tested, review welcome.
Can you help me change the code of D4v2 to make it work with RGB anode led ?
Demo of the Andúril autolock feature:
Helpful especially for flashlights without aux LEDs like the FW3A because you don’t have to guess if it is locked when you pick it up from the desk.
That autolock is great! I will try it soon in one of my flashlights.
Could a similar timer be implemented to reset mode memory?
Sure, but on most flashlights (all that use the ATtiny85) you have to remove some other features as the flash memory is almost full. Hardcoded timeout would still fit, but configuration might be too much.
(You could remove the whole blinky flashy section with strobe, candle, beacon etc of course.)
Would like to see a tint mixing firmware based on time of day eventually.
I added support for Lexels aux board for my fw3a. Running build-all returns
I checked the build.sh script and it does have the -Os option which seems to have been a root cause for someone elses concern but now mine. Any idea? This ir unning linux.
Which version of gcc do you use? Newer versions use slightly different ways to optimize the code (probably related to c standard compliance), but usually just a few bytes. But without your code it’s hard to check what causes the issues.
hmmmm gotcha, this is what is being compiled
here is the full output of what im seeing for context
heres the files im modifying for aux led support (lexels awesome aux boards of course)
(i simply added line 27-37)
and hwdef-FW3A.sh (38-42)
resetting the repo back to original, it generates hex files fine from TK’s repo.
for TK;
Why bazaar vs git repo?
Any feedback is appreciated. Not sure why adding a few lines of code makes this bork out 
Because aux LED requires many lines of code. The FW3A needs three ramping tables and has no aux LEDs by default which is not a problem (currently). But both together might require some tuning so that it fits.
This is an interesting idea, and merging it is on the todo list.
Unfortunately, Fireflies used the PL47 driver and firmware for the E07. So it was never really calibrated for the E07 properly and there isn’t a build target for it.
This is more complicated than it may seem at first. Basically, there are reasons why software has version numbers like “1:8.11+urwcyr1.0.7~pre44-4.4:amd64”. But version strings long enough to uniquely identify each build are … difficult to blink out with a single LED.
It could perhaps use just the build date, which would get the version string down to 8 digits… but it wouldn’t uniquely identify versions for different lights or made by different people or different branches. Maybe that’d be enough though?
OTOH, adding something to the .hex file which changes during each build would break all the tricks I use to compare checksums. Like, usually if I’m adding a new compile-time option, I check to make sure the checksum didn’t change afterward unless the feature is turned on. And when uploading builds to my site, it compares checksums to determine which builds to upload. That sort of thing wouldn’t work any more. I suppose I could make sure the version string always goes at a predictable location, and strip that data out before doing the comparison, but that’s an unusually complicated way to check if anything meaningful changed.
Using a similar method, yes. It could reset the automatic memory level to a default after an arbitrary timeout. This would require enabling sleep ticks on all lights though, even ones which otherwise have no need for it. There’s also a space limitation to consider, but the feature could perhaps only be enabled for devices which have enough room left.
I use the autolock feature in this state for two weeks now on a D4S and FW3A. Works without issues and especially with the FW3A it is nice because I can always grab it and put it in my pocket without checking if it is locked or not.
I had to rip out all the bike functionality from anduril to fit the aux code. Seems like attiny85/anduril.c is at its max capacity.
How do I know what version of anduril I’m working off of ToyKeepers trunk?
You likely use a newer build of the anduril.c?
I never had issues so far getting 3 channel with aux compiled