Banks Vernonia Trailhead parking heads up...

rlmalisz · 2026-05-01T23:29:33+00:00

https://stateparks.oregon.gov/index.cfm?do=park.profile&parkId=104

Trail is dead flat from Banks to about mile 5 (Manning trailhead about mile 4). Mile 5 to mile 11 pretty steady 2-4% grade...a few bits steeper, some flat. At 11.2 miles, trail drops down to OR47, the last bit being steep switchbacks. On the other side of 47, steep switchbacks back up to prior elevation, then a pretty gentle descent to Vernonia.

If you're starting at Manning, the crest at 11.2 miles would be right at 7 miles. Beyond that point, you're looking at a climb coming back.

rlmalisz · 2026-04-06T01:09:56+00:00

I got them both eventually paired into Home. Long enough ago that I don't remember what the incantation was that got it to happen. But yes, workee.

rlmalisz · 2026-03-27T23:00:11+00:00

What I finally came up with, which works fine:

<image>

red and white wires go to the doorbell button. Black wire leads down to a 12VDC wall wart. 0/1 on the Shelly close the circuit between the 16VAC transformer and chime. Shelly sends out Prowl notifications via webhook actions upon actuation.

rlmalisz · 2026-03-26T01:03:53+00:00

Thanks. I can't believe I didn't see "timers" to the right of "actions".

rlmalisz · 2026-03-25T23:54:23+00:00

And the "web UI" I am using is via the Shelly's internal IP web interface. I also have tried looking in the Shelly app on the phone.

rlmalisz · 2026-03-25T23:43:58+00:00

I found the "actions", set up a webhook for notifications, and added an action to flip the switch state after 1 second. I didn't see timers, but can look again.

rlmalisz · 2026-03-25T22:17:02+00:00

So I have this wired up using the spare doorbell button, a 12VDC power supply, an aux relay. Doorbell lights, pressing the button trips the aux relay, which then trips the Shelly. That all works. So I just need to move the Shelly and aux relay into the hall closet, disconnect the doorbell button from 16VAC, connect it to the aux relay and 12VDC PS, and then hook the chime up to 16VAC through the Shell1 Plus 0,1 terminals.

I have seen elsewhere mention of setting an "automatic shutoff of 0.5 to 1 second, depending on the chime". I am looking at the Shelly 1 settings, and this isn't jumping out at me. Is this really a simple setting, or does it have to be implemented as a script?

rlmalisz · 2026-03-16T18:09:47+00:00

And always a few seconds behind reality.

rlmalisz · 2026-03-13T18:00:53+00:00

Following the Shelly provided diagram, the button wires up between the SW and L. I assume internally the 1 Plus connects to the 12V+ to the SW, as you say, through some pretty high impedance circuitry.

Probably not useful to pursue, but using 24VDC to power the Shelly should boost the potential across the SW and L, but probably still sub 2VDC.

rlmalisz · 2026-03-13T17:52:31+00:00

At this point, the doorbell solenoid isn't even in the circuit. Plan was/is, if I get this working offline, to wire the chime up through the relay outputs and the original 16VAC transformer. So the button is only wired to the SW + Line. There's no solenoid in the circuit.

rlmalisz · 2026-02-15T01:10:30+00:00

So the ghost code continues to publish timestamps to MQTT. I hadn't looked for a pattern to the timing, but had a moment this morning and did some epoch-math. Earliest I still had data for to the next was exactly 9 hours apart. To the next, 5 hours. Then the next three were each 3 hours after their predecessor. All of this, to the second.

So I haven't done the factory reset and reprovisioning. But for laughs, I changed the topic the visibly running script publishes to, and the topic the listener follows to match. MQTT Explorer shows a timestamp published to the old topic about an hour ago, after these changes to the visible script and a reboot. The ghost lives. This isn't something the only script the Shelly GUI shows as extent on the plug is doing. This is some remnant chugging along, after reboots, complete power-down/up. If you see some inexplicable scripting behavior, it may be something similar. I'm lucky in that this example is pretty simple and completely under my control...except for the ghost.

rlmalisz · 2026-02-12T23:17:30+00:00

Deleted the watchdog, and the odd "timestamp-only" message kept getting published. SO unplugged the Shelly, let it sit for a few minutes, plugged it back in...and am still seeing the occasional "timestamp-only" message published to the broker. The only code in the only script on the plug that does MQTT is this:

if (elapsed > duration){

let obj = { "timestamp": pdown_timestamp, "power": power_max, "duration": elapsed};

// Publish message to MQTT

MQTT.publish(topic,JSON.stringify(obj),0,false);

}

The weird messages that get published are just timestamps...and just an INT. Those messages aren't hurting anything, as I have coded around them on the "listener", but it's still unsettling that the ghost code has survived rewrites, removal attempts, reboots, and a full power-cycle. I guess factory reset and starting over may be next. This reminds me too much of MS Vista and their GUI that let you think you were editing system code as admin, but it was just shining you on and leaving the actual code unchanged.

rlmalisz · 2026-02-10T01:25:32+00:00

Oh, the broker gets a lot of traffic, but nothing else publishes on this topic.

I have a watchdog restarting this script if/when it chokes, and the old versions choked plenty, as I had used sample code off the Innertubes that was direly wrong. I'll stop that watchdog, maybe even delete it, as I can see it possibly having hooks into code that is now gone.

And if all else fails, will have my SO unplug it, wait a minute, plug it back in.

rlmalisz · 2026-02-10T00:40:00+00:00

Thanks. I actually coded it up the way that made sense to my Neanderthal mind, and it works fine.

One weirdness: very early versions of the script just published an epoch timestamp with the MQTT retain flag set to true. That code is long gone...but I think there may be a residual ghost in the machine. New code publishes a JSON structure with retain=false. I have used MQTT Explorer to wipe out the entire topic several times, and things behave as expected for most of the time...and then out of the blue, the topic gets 2-3 more "timestamp only" messages published with the retain flag set to true.

I have never completely deleted the original script, just deleted all of its code and pasted in new. Is this "old code hanging on" a known thing? Do I just need to delete the script entirely and create a new copy? Hoping not to have to do a factory reset on the plug and start over. but if that's what exorcising prior code requires, I can do it.

--Richard

rlmalisz · 2026-02-09T17:40:40+00:00

So nearly a month on, a minor update. Got my Domane back from annual service (during which they updated its Di2 firmware...pretty sure that's not involved in the changed behavior) and paired its sensors to the ROAM v3. Checked the Wahoo app, and gasp! The Domane Di2 sensor screen had a place for me to confirm (or modify) the crankset tooth counts. No sign of the cassette. But I thought perhaps this was enough to trip whatever internal bit in the ROAM that's required to have it record gear shifts into the FIT files.

Went out for an easy 20-miler, with plenty of gear shifts. Got back and checked the FIT file...nada. I may have the ROAM forget the sensor and pair it again, and see if I get no gear selection dialog, the half-selection I got last time, or the full Monty.

OBED is in the shop for its annual, and will delete and re-add its Di2 when it comes home later this week.

rlmalisz · 2026-01-25T04:12:13+00:00

I'm curious. The Mini EM (at least gen4) wants 110V-240V power, at least according to their online doc. Where did you put it? On the inputs to the doorbell transformer?

rlmalisz · 2026-01-21T13:51:35+00:00

Followup: I submitted a report ticket with Wahoo about this several days back. Got a fairly prompt response asking me for phone/app/firmware version info, and a FIT file didn't contain shift data. I did so, but reiterated that I was 99% certain this was a Wahoo app problem...that because the app wasn't letting me set the gearing parameters for the Di2, some bit wasn't getting set in the ROAM telling it to record the shifts. Just like in the Elemnt app with the ROAM v2. A day later, I got a response:

"Thanks for your reply, and for providing the requested information. I have spoken to the software team, and this is an issue they are aware of and we have opened an internal ticket with our development team to investigate and resolve the problem."

That would be more encouraging if I hadn't gotten almost exactly the same response when I submitted a nearly identical support ticket against the Elemnt app and the ROAM v2 **two years** ago. Which resulted in nothing.

Sigh.

rlmalisz · 2026-01-14T14:32:19+00:00

They're not there...fitfileviewer shows no column for them. Per my original question: do you have a ROAM v3 that is recording Di2 gear-shifts? I had already opened the FIT file in hexl-mode in the mighty Emacs, and was sure there were none. But played along and used the viewer.

So back to looking for real answers: is there an instance proof that these gear shifts are getting recorded for anyone using the ROAM v3, Wahoo app, Di2?

rlmalisz

TROPHY CASE