I keep circling back to these and I think it’s time I consider some “real” project for it.

I tried Rust for rig4, and I wasn’t impressed. I think of C and Rust as “embedded” development languages, not server ones.

In fact the main reason I’ve never been impressed by neither Kotlin nor Rust is the debilitating amount of hype around them. Rust, like Go, has a lot of idiosyncrasies, not to mention arbitrary conventions on what should go where. It seems to be the new trend to endocrine the structure at the compiler level.

I see Kotlin as pure hype. There’s nothing Kotlin seems to add that can’t be done in plain ol’ Java. Software engineers are kids, they always look at shiny new toys and disregard the perfectly valid ones they already have.

So anyhow, are there serious projects I can try to slowly accomplish on both? Ideally they would not be long-term projects, quick yet good enough to get some real sense of the languages and move on?

Wannabe projects I have around:

• ESP32 grade crossing. Would be ideal for Rust, except I don’t see good ESP32 support.
• Conductor 2… Currently Groovy + Java. Could use Kotlin as a DSL instead of Groovy.
• I did try Kotlin back then but its DSL was not enough for my needs.
• Rig4… Currently Java, with a (failed?) attempt at Rust. Could be using Kotlin.

One of the new directions for Rig4 is to have 2 tools (fetch + produce) so it’s possible for each to be in their own language. Seems a bit messy and quite undesirable though. If anything, it means dealing with two toolchains.

On the Android side, I have no immediate small project. Otherwise Kotlin would be a good choice there. I have some small game idea, and those would be in Godot / GDScript likely.

There seems to be something for ESP32 with Rust:

• https://github.com/esp-rs
• https://github.com/MabezDev/rust-xtensa

But one thing to remember is that I don’t just want “Rust on ESP32” (via llvmc, why not). What I really want is the Espressif SDK w/  FreeRTOS API, and e.g. access to the camera, hardware, etc. As the project author says “I've laid the compiler ground work, it's simply a case of writing the drivers and HAL's for it”, but really that’s the most important part of the project, there’s nothing of a “simple case” here. Without that, there’s an obvious chicken-and-egg problem.

The other side of the coin is that the whole point of the grade crossing project is to use OpenCV, which means I need OpenCV Rust bindings. There are some, but who knows how good they are on ESP32 (I don’t care if Rust + OpenCV works on desktop).

So conclusion:

• Rust: No candidate.
• Kotlin: Maybe Rig 4.3 reboot or Conductor 2.1 ?

So here’s yet another approach: use a small PIR module, like the tiny “arduino” ones I use at Randall. This thing has a 1k Ω resistor on the output, and we can already trigger repeats & duration, so it’s essentially mirroring what a 555 timer would do and at the same time it would only blink the LED when presence is detected in the garage.

That would save on the battery by not blinking it when there’s no one around.

The sensor still needs to be powered.

Links from when I used that kind of sensor at Randall:

Sensor is a HC-SR501. Datasheet link via Aliexpress.

• The SR501 uses a 7133 voltage regulator. We can feed it with the 5V from the AIU’s 7805.
• The BISS001 drives the OUT pin directly via a 1kΩ resistor.

Main component is a BISS0001, datasheet link from Ladyada.

Of note:

• Input voltage: 5-20 V; and on another page it says 4.5-20 V..
• Power consumption: 65 mA.
• Quiescent current: < 50 uA.
• Output TTL 3.3 V.
• Jumper L = single trigger, H = repeat trigger.
• Pot on the jumper side = sensitivity.
• Pot farther from the jumper = time delay (5-300 s).
• Must be mounted horizontal for a variation left/right (e.g. pins at top or bottom).

One thing I had noticed at Randall is that these do not work when powered by 3 V. The unit “blinks” the output repeatedly. My guess is it fails to initialize (they go through a 1-min stabilization phase when first powered).

In my case, that means I need a 3-AA battery holder instead of my current 2-AA battery holder. It does work well with a 3-AAA holder.

On the output side, I got the illumination I want using a 1k Ω resistor on the output and a green LED. Red one was a bit weak for the value, although I could remove the extra 1kΩ.

I installed that and it works nicely as I want.

Update: I got about 1-2 years out of 3 AAA batteries powering this with moderate daily usage.

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”.