Guess what… I’m in PA and I already want to add a couple features to Bearing:

• Create a marked location list + auto save/load.
• When marking a location:
• Add it to the list. Names a “Location 1…” + auto-inc (use list length).
• TBD later ⇒ dialog to edit name before adding it + cancel.
• But to get started, generate name automatically.
• Display name in small font below marked location.
• Add a little “3-dot menu” on the “Marked Loc” line. Popup a menu:
• Recall / Edit…         ⇒ goes to marked loc fragment (see below).                  [done]
• Share…                 ⇒ share location as text/etc                                        [done]
• V2: Rename…         ⇒ dialog with one text edit field.
• V2: Save                 ⇒ enabled/visible if marked loc is not in current list (e.g. upgrade or deleted).
• Share bearing (as text, to google maps).                                                        [done]
• Marked locs fragment:
• Reuse the current pattern (fragments in a single activity).                        [done]
• Simple text list. Select an item : [Delete] / [Recall] / [Rename (v2)].        [done]
• List items: GPS loc + date/time + name on 2nd line.        [done]
• V1: Not listing the time
• Delete with confirmation ⇒ does not remove current marked loc.                 [done]
• Recall: honor the pref setting “ask before override marked loc”.                [done]
• Recall would erase the current mark loc,
• Then go directly to the compass view.
• V2: Share selected mark.
• V2: Export all marks as text.
• V2 or +: reorder, rename.
• Consider renaming “marked locations” to “waypoints”?
• Split screen:
• Bottom is list view
• V2: top is map view of selected list item.
• V2: top is detail info for item. Name edit field to rename. Trash icon for delete with confirmation. Eye or compass icon to make it the mark in compass.

This is something I need to look into at some point: MQTT to send messages between ESP32 nodes on a local network.

There’s a group (MQTT4MR) that uses that to control sensors via JMRI (instead of C/MRI over RS485 wires).

MQTT is also used typically with LoRa and such for larger distance networks, I believe using brokers/hubs. However that’s not really my first usage.

https://learn.adafruit.com/mqtt-adafruit-io-and-you?view=all MQTT very high overview:

• Designed for sensors … small payloads, infrequent data, not heavy streams.
• Which is why it works well with LoRa (bandwidth vs distance, pick one).
• It’s a N-to-1 design: one server somewhere, multiple clients.
• Either one device acts as a server, or a “broker” app/script runs on a network computer.
• JMRI uses the latter design for obvious reasons.
• There are internet-wide brokers like adafruit.io
• To connect to a broker, need server/ip, port, username, and a key.
• The whole concept is a pub-sub:
• Devices publish to the server.
• Devices subscribe to the server.
• Subscribers need to send a ping (e.g. every 5 minutes).
• Failing to ping disconnects the device.
• Adafruit_MQTT is such a lib for arduino.
• They warn it’s single-duplex: a subscription message would be lost if the device is transmitting (ping or publication) at the same time.
• Quality-of-service:
• QOS 0 = send publication message without checking they arrived.
• QOS 1 = send publication message with an OK / ack.
• A “will” is a message defined such that the broker sends it when the client disconnects.

It’s been 2 years now that I started the rewrite of Conductor 2. Back then I chose Groovy, after trying Kotlin and deciding it wasn’t mature enough. In between, Kotlin usage has expanded a lot, so time to revisit.

(N.D.L.R.: the goal of the Conductor 2 project is to replace the custom language from Conductor 1 by a new DSL based on top of Groovy, or Kotlin. That would allow the script to have more flexibility.)

Overall Conductor2 with Groovy would work. Although the engine isn’t 100% operational, I rewrote most of the main automation script using Groovy and I updated it to a few new concepts that I miss in my current custom language.

The Conductor 2 design doc has more details on the new syntax.

Through the implementation, I evolved the syntax.

In conductor 1, we have basically a “global” namespace of “conditions --> actions”.

These can be expressed in the Groovy script using:

On { closure expression return a boolean } --> { actions block }

However I later rewrote the script to be more oriented for each route / block.

A route is defined as a sequence of blocks that must be traversed, and there are actions for each block. This avoids the soup of global state variables that must be maintained in Conductor 1 to achieve the same thing (e.g. “passenger train on this block going forward”). The new syntax looks like this:

Name = route {

        Route = [

                BlockNumber.forward {

                        onStart { actions }

                        onEnter { actions } then_after delay { actions }

        after delay { actions } then_after delay { actions }

} ] }

This scheme basically encodes most of the complexity in Conductor 1’s script, which is using timers and global state to limit actions to certain routes/blocks/directions.

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?)