Another surely doomed attempt using an RC and a transistor. As expected, it did not work.

Although it is inherently flawed, I’ll put it here:

Transistor is a 2N3904.

This obviously does create a delay starting the LED. Then there’s nothing to stop it. The futile idea was to add a second transistor between “ground” and the battery minus side to cut the circuit. Problem is that there’s nothing here that would generate something suitable to trigger it. Something like this:

An even easier way to blink a LED is to not use a LED. An ESP32 or an Arduino Nano both have a LED onboard. All I need is the smallest program that would turn on the onboard LED on a timer/interrupt, and ideally keep the CPU sleeping/idle/suspended the rest of the time.

Some ESP32 dev boards come with a connector designed to power them from a battery, like the “Heltec Wifi Kit 32” ones I have.

The Arduino Nano dev boards have 4 leds (RX, TX, PowerOn, IO). The Power-On is always one when the device is powered. The trace leading to the LED can be cut. A quick online search indicates it can be powered by 3xAA (~ 6V) using the last 2 pins (GND / VIN). However the same research indicates on a Nano board, the FTDI/USB chip will use about 30-40 mA all the time, rendering the effort quite moot.

Another choice is the Digistump Digispark 1. It also has a green Power-On LED as well as an IO LED.

What about the Arduino? How do you “suspend” the Atmega328P in a Nano or the ATTiny?

• From this thread: https://thekurks.net/blog/2018/1/24/guide-to-arduino-sleep-mode avr/sleep.h defines a sleep_enable() + set_sleep_mode(SLEEP_MODE_PWR_DOWN).
• It also indicates the only way to wake it up is using an external RTC timer on an interrupt (for example an Adafruit DS3231 Precision RTC controlled via I2C).

The ESP32 for sure has APIs to put it in deep-sleep mode. It’s designed for that: https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/system/sleep_modes.html 

• esp_bluedroid_disable(), esp_bt_controller_disable(), esp_wifi_stop().
• rtc_gpio_isolate(pins...) to disable pullups/pulldowns on IOs.
• esp_light_sleep_start() or esp_deep_sleep_start().
• esp_sleep_enable_timer_wakeup() ⇒ wake up from deep sleep using timer.

Can the ULP Processor be used to trigger the LED directly?

• https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/ulp.html
• No, it won’t drive IOs but it can wake up the processor.

Goal: blinking led in the garage when the side bolt is closed. Ideally battery powered.

• Idea is to have it blink to save energy and work longer in battery.
• What is the simplest way to blink a led, or more exactly the less current usage?
• How much can I expect of e.g. an AA battery? Or a couple add I have a holder for that.

Random idea: use a led forward voltage, resistor slowly charging a cap and when above the led voltage it would discharge.

Resistor-Capacitor (RC) Time Constant Calculator | DigiKey Electronics

• To compute a RC time:
• Tau = R.C = 63% of final charge time.

This does not work, as tried in National Instruments Multisim:

For the daily Xmas lights, what I’d like is to have:

• Person detection, likely using an existing PIR.
• Light detection, to turn it on when it gets dark.
• Server/wifi control so that I could rifle it from the phone.

One option is to take the existing timer plug and control it from an ESP32. Doesn't even have to be a cam one, using a PIR in max range could work.

I'd like to have a second ESP+PIR across the room for more coverage. Whenever any of these detect motion, light would stay on for e.g. 15 minutes. The second ESP can send an ESP-NOW data packet to the first one.

A local button toggle would be ideal.

The other option would be to use a dedicated wifi plug like the sonoff. I do want something absolutely local that does not use any cloud.

8 Channel Smartphone Relay WiFi Remote Control Kit: https://amzn.to/3VZSvw1

Note: Not a SainSmart, seems like “TOSR08” but really looks like the former

More description in the kit here: https://www.tinyosshop.com/8-channel-wifi-relay-module-remote-control-kit [$88 !!]

• TOSR0x module has a FT232RL USB-to-UART input + 5V barrel DC
• Control done by sending one byte.
• Module has a switch: USB or separate “extension port” (not both)

And the kit provides:

• WifiBee wireless module
• XBee USB adapter

(so wait, do they mean phone > wifi > wifi-to-xbee > xbee-to-usb > usb-to-uart? Very likely.)

A better option is to get the TOSROx module and plug that on an arduino / ESP32.

But that $88 cost is definitely a non-starter.

Sonoff 4-channel “R2” wifi w/ Android app [$28]: https://amzn.to/3VXmuVf

Is “R2” a “revision 2”? It must be as there’s a “4CHR3” for about the same price.

Described as “is an ESP8285 WiFi module based 4 channel (4-way) WiFi wireless switch.”

Somehow “Sonoff” and “ITEAD” are the same thing/company/something related?

https://www.itead.cc/wiki/Sonoff_4CH

⇒ Question: is there an API to use that without their app? ⇒ Not the 4CH one.

http://developers.sonoff.tech/sonoff-diy-mode-api-protocol.html “The DIY Mode is designed for IoT home automation users and developers who would like to control the SONOFF device via existing home automation open-source platform or local HTTP client instead of eWeLink App.”

Supported: “BasicR3”, “RFR3”, “MINI”, “D1” (dimmer) (these only toggle 1 output)

One direct application would be control of the xmas lights from server -- time based and/or image based. Ideal detection would be “any kind of motion detection” in living room, kitchen, and hallway leaving the lights on for 10+ minutes.

• An ESP32-CAM with the widest lens possible would be ideal, or even 2 of them (one by chimney).

Options on how to control the lights:

• DYI:
• Add a 3-to-5V converter.
• Add a 250V 2-channel relay (to switch both L1+N).
• Use something like a Sonoff or a more “serious” option for the plug control.
• Modify an existing timer switch.
• The one I’m using right now is essentially a relay switching the hot wire (small prong of the polarized plug).
• It has 2 boards: power + relay vs control board.
• Connector with 3 wires: Vss, Vcc, On. (voltages?)

Rig4j has some unit tests. As with other unit tests, I’m always dubious of their quality, coverage, or usefulness. Writing these tests takes a lot of time, and maintaining them is a PITA.

However, I did a change in Rig3. I was glad to see this old project had some tests. Lots of verbose warnings when running them, but at least they gave me a baseline for the one change I had to make… it showed me how my own code was running, since I had largely forgotten. And I was able to break the tests as expected with my change, then adjust the tests. Thus they served their role in a TDD scenario.

Now I’m looking at Inkblot2 and I skipped the testing part for all the React code. After all it’s just presentation, right? I have only a couple unit test methods for computational functions.

A decade ago, I wrote a little backend for Timeriffic to enable themes per user. It’s just a simple REST API served by a Go app-engine with a CRUD admin frontend. And it’s written in Go 1.1 (IIRC), and now I need to update to Go 1.9. I seriously hope I wrote some tests, and here’s what I expect of these tests:

• First run them ideally with a Go 1.1 runtime (assuming I still have that), and validate they work.
• Next run them with a Go 1.9 runtime, and if the app builds, see which part of the test works or breaks. In essence, I just want a baseline of what’s broken by the change.

Which parts do I expect to be covered?

• On the backend REST API side, a get without a valid auth, and a get with a valid auth. That last one should also cover reading from a mock db.
• On the admin frontend, render the page without login, with login, and validate a simple CRUD usage (create an entry, see it listed, remote it, see it gone).

These tests are not designed to do 100% coverage, yet they should cover the basic usage scenarios. Even if a full CRUD cycle is not exercised, the viewing part should be tested, e.g. login and display an empty list, login and display a list with known data.

I want to emphasize this is not the TDD philosophy here. We’re not using tests to validate every single inch of the app, every single little possible case. At the contrary, the tests should cover large strokes, making sure the obvious is not broken.

Thus Inkblot2 really needs something like that.

I do remember that my little dabbing in Go did not show great ways to mock whole components such as database or logging auth. That’s one of the reasons I went back to liking Java all because of Dagger and how it enables that trivially, all at compile time. I’m curious what React JS has to offer in that regard.

In my perpetual reshuffling of home projects, I need to bump up rig4j, and abandon rig4r.

Rig4r: It was somewhat useful to learn Rust lang. However I really don’t care much about it. That language does not solve any problem that I don’t really have.

That said, it wasn’t a complete loss. The rig4r project showed me there’s some value in splitting rig4 in a gdoc-downloader vs a generator.

In the current train site+blog, a simple blog update results in a 6-7 minutes rig4j run time.

90% of that time is in checking images/graphics have not changed -- it takes about forever to pull them off gdoc using the current gdoc API… this will get addressed whenever I focus on rig4j again and implement the caching I specified from the start yet never fully implemented yet.

It’s also worth noting that the current rig4j is really “0.1-exp”.  There would be some value in taking the learnings from that experiment -- what worked well, what did not work --, cross-reference that with the initial spec, and maybe re-implement from there.

The main pain point is looking up all these gdoc images instead of relying on cached blobs.

The second pain point is the HTML exported by gdoc. I have it somewhat cleaned up, yet I think even more could be done. On one hand I’d like to strip it down as much as I can to the level of what is/was supported by izumi’s syntax, and on the other hand I’d like to retain some complex elements such as tables.

The latest Debian Busty offers Java 11 via OpenJDK. There’s also a comment on the OpenJDK web site that from now on all official Java releases are done via the OpenJDK (site/framework)... does that mean one no longer has to wonder about Java vs OpenJDK compatibility? That would be nice.

Of note: Debian has an openjdk-11-headless… no more need to drag X libs pointlessly.

It also begs the question of “what’s new in Java 11”... and what can be used on Android.

https://simply-how.com/getting-started-with-java-11

• Java 9:
• A new concept of “modules”, a “self describing collection of code and data”.
• Jlink, a tool with a link time phase vs compile time phase, using modules.
• Jshell, a REPL … that can come in handy.
• Multi-release JAR files: version-specific of classes in the same JAR.
• Private methods on interfaces, which can be used by default methods.
• Rx compliant Flow API.
• Factory/collections methods: Set.of, List.of…
• Stuff I don’t care, e.g. garbage collector changed. (skipping those below).
• Java 10:
• “Var” keyword for local type inference.
• Optional.orElseThrow.
• Unmodifiable collections: List.copyOf, etc.
• Java 11:
• HTTP Client API (do I care?)
• “Singe-file source-code programs”... sounds like scripting to me.
• “Var” keyword can be used in lambda parameters.
• Java 12:
• More garbage collector whatever this or that.
• Mostly nothing except some *preview* of a condensed switch/case/break syntax (e.g. the “break” also acts as a “return”, and can be further condensed to an -> arrow syntax)... meh.

Bottom line: mostly nothing to see here.

So overall a fairly incremental update to the language. The most notable useful thing is the “var” keyword. Since it is type-inference, I expect it can generate backward-compatible bytecode running fine with older JREs. New APIs like collections would obviously require the latest JRE to run.

We still don’t have support for “safe-dereference” (?. which was proposed for Java 7!) and folks horrendously suggest using Optional instead.

For gradle, the usual:

targetCompatibility = 11

sourceCompatibility = 11

Or

compileOptions {

    targetCompatibility JavaVersion.VERSION_12

    sourceCompatibility JavaVersion.VERSION_12

}

Thus it seems to me overall I’d want something along the lines of “target 8… source 11”.

Currently working on Inkblot v2 Scoring Web App.

The suggestion was to evaluate AWS vs Firebase (nodejs based, not Android as I usually do).

AWS is working really well work Inkblot v2 right now, so there’s little incentive to also do a Firebase version.

I’d still like to do a web app using Firebase to have a comparison with AWS, and Seeds seems like a good candidate for this. I have the Android app working fine, however my old Chrome extension does not work anymore since the AppScript-based apps have been deprecated.

Rebuilding it using Firebase would be a good target:

• Rely on their free tier, and measure cold latency (one of the big drawbacks of app engine in their free tier, which I do not see in AWS).
• Nodejs + React + Bootstrap, similar to what’s used in Inkblot v2.
• Google-only auth… how well do they integrate that in Firebase?
• Backend storage… how does it compare with GraphQL + DynamoDB?
• Note: the only thing I really need is to store the GDrive doc id.
• Deployment/hosting… this one would likely go on something like “seeds.alfray.com”.

Updated 2020-09-24: That project could also be a candidate to look again at Angular. I remember looking at Angular before React and couldn’t figure out the model… However now that I’m familiar with React (non native), looking at Angular a second time would be worth it, for a good comparison.

Current projects, either actually ongoing or started/pending:

• Conductor 2, the rewrite using a Groovy DSL. Want to continue. Perpetual hold.
• Low interest as the current version is “working fine” (with its limitations).
• I would have some renewed interest combined with home usage.
• Timeriffic 3…
• 2019 attempt did not work, it crippled most of the functionality, the impl was borked, it didn’t even really work well for basic stuff.
• That needs a full reboot if it’s going to go anywhere.
• This could be a candidate to do an app using RxJava + Kotlin.
• Jump Godot game.
• This is mostly a “technology” demo for Godot 3d to understand limitations.
• Got initial MVP (without the IAB part) on Play.
• There is no interest in making it a full blown complex play.
• I should take the MVP down, e.g. keep it alpha instead of public.
• Asqare.
• A reboot using Godot 2d.
• Sudoku
• May have some limited interest if it were to be a Kotlin + RxJava test bed.
• Risks having the usual issue of not going past the MVP.
• Dcc Cab:
• Current version is on Play. Not advertised much. Does what I need from it.
• Rig4r:
• Limited interest in Rust itself, however I can see how it is appropriate here.
• May continue… slowly?
• ESP32 vision.
• The 2 initial targets for this are crossing signal and virtual block detection.

Starting one and exploring a tech is easy and fun. Jump/Godot is an example where I had fun starting it. It fell a bit flat once I had the premise of a working version. I lack a push to complete these, and once the novelty wears off, there’s little incentive to continue adding to it instead of focusing on another idea.

For Rig4r, the initial objective was to spend a long week-end learning what Rust is all about. I’ve done that. I have no specific love for the new language, but neither did I for any other new language I’ve tried recently (Haskell, Go, Kotlin,... and now Rust). That’s because these languages do not fill any need that I don’t really have -- they really do not do anything Java can’t already do, no matter what the fanboys say. For example I’m not really happy with the current implementation of Rig4j, and that’s really not a Java/Dagger issue at all.

No amount of language hype is going to magically fix an implementation.

The other realization I made with Rig4j, the Java version, is that external libraries are what matters. In this case, the availability of a G Drive API and the HTML jsoup parsers were keys.