Considering approach to an Elmish.Meadow

[houstonhaynes]

Since you helped me with getting the example app "AutoUpdate" button status into "the Elmish loop" I thought I'd throw this tanget over the fence to see what you think. I hope you don't mind the minor digression. Thanks! 🙏

So, I've been working with Akka.NET quite a bit for some larger projects - and like any other novelty I see "actors" everywhere I look. One of my interests is to use actors "all the way down" including at the edge. 🔬 I've played around with the idea of using Akkling/Wakka in the WildernessLabs Meadow - understanding that running full Akka.NET on a microcontroller might be a form of "overkill" - unless it's part of a larger code base where Akka is used on the backplane. At least that was my early concept. 🤔

But now - as is the reason for this post - I'm thinking that Elmish likely makes more sense here. The idea of using the F# mailbox as an actor directly in Meadow F# code occurred to me, and now that I've had a brush with Elmish here I'm starting to see it - like my early days with Akka - everywhere I look. 👀 The idea is for a more organized, message-based structure to the code. The "obvious" benefit is to have a form of semantic and mechanical (to borrow a phrase from "Stylish F#") distinction from side-effects. This involves both writing out to Meadow resources/pins/endpoints as well as the plethora of peripherals that are "mutable by default" because of the way that Wildernesslabs.Core is structured to support hardware requirements in a resource-constrained microcontroller.

To skip ahead a bit, here's an example of something I wrote to process values from a CO2 sensor and display changes in various elements of a 'canvas' - which is a GC9A01 display. 📺 Some of these are "easy pickings" (like all of the CO2values that get updated) where I think "oh this would be a great place to use MVU". But then there are others - such as the instantiation of canvas which (along with any other resource on the Meadow) uses direct interfacing under the hood to reduce housekeeping overhead on the processor. Trying to be clever with immutability in those cases just BREAKS. 💥

🚧 I'm already starting to "module out" certain things like managing the onboard LED and creating a structure for addressing BLE and handling onboard config. From that bit of head-scratching 🤔 Elmish seems to fit into the logical extension of keeping segmenting the mutable/immutable aspects in a way that will make more complex projects easier to manage. So what I want to do is create some semblance of "managed effects" such as writes to the display, controlling the on-board LED or posting logs/events to a web endpoint for managing telemetry, etc, etc.

My Ask: I'm looking for your perspective on whether you think this might be a worthwhile exercise. And if so, how would you think about creating a "view" distinction where the view might be an LED or relay control to switch an external device?

I know this is a LOT to take in - thanks in advance for letting me bounce this off of you. 🧠

[JordanMarr]

Sounds very interesting.

If what I'm hearing is that each IoT device runs a mailbox and operates its own Elmish loop to maintain state and handle all IO effects, then yes, I think that would be a great design.
You mentioned canvas; are you using a UI framework like Avalonia for the LED?

[houstonhaynes]

Well - great question! So the answer is "not yet". 😄 There is a "micrographics" layer that can be used to write some simplistic text and polygons to the display. That's what I'm using here. But there's an Avalonia framework for more complex devices and larger HMI'ish screens. There's a few threads about this as there are people that are throwing themselves into it (but in C#) 😏 I think it's a brilliant idea to make smarter edge devices with a rich end user experience. The only thing I've seen so far is a handheld game prototype but the proof is tantalizing.

For my part - I've been mulling around an MQTT arrangement - client on the Meadow, broker on a server backplane with an adjacent service running SignalR with Akka (and in some cases Elmish MVU "digital twin" for state tracing of the edge device). So some edge devices would be "headless" and just have an LED or some other simplistic status display for troubleshooting. The "mid-level" would be devices with small-ish screens and perhaps one or two button controls. Here's a photo of my CO2 sensor proof that's sitting on my desk.

That's the "middle of the pack" in terms of sophistication where the device is driving a UI. And of course the "full blown" version is the aforementioned large screen HMI device.

I see that last case as perhaps being another "target" for XPlat, but the notion is little more than a fleeting idea in my head.

[JordanMarr]

I took a stab at what an Elmish solution might look like.
Draft PR here: houstonhaynes/MeadowCCS811#3

[houstonhaynes]

Brilliant! I just spotted them. I really appreciate it. It looked like you might have branched from something other than my latest update (on the JpegLoad branch) which is my fault/laziness. But I think this will give me a chance to follow in your footsteps and integrate the changes kinesthetically. 😄

Right now I'm caught up putting together a dual-board proof I started to work on during lock-down but never finished. Since I'm proposing to move to a better/newer VOC sensor and putting them to use at the Asheville Maker space (to measure the particulate in the air when the lasers/resin/3D printers are in service) I'm putting the proof on display as part of a conf here in town at the end of September. So once that's done and tested out I'll circle back to the code.

[houstonhaynes]

Right now I'm trying to find my CO2 bike tire inflator to attach to the front right corner of the enclosure to inject CO2 from a cannister - and I just had my hands on it... I put it down to find something and lost it in the process. That's my life with ADD. 😸

[houstonhaynes]

Found it! 😹

[JordanMarr]

Oh, that makes sense. I was wondering why the arrow wasn't being set.
Well, I might do that one too just for fun. The meadow kit looks really nice to work with!

[houstonhaynes]

That's amazing! I'd love to see more F#'ers get involved - vested self-interest. 👍

There's an add-in board that can be mounted via USB which can allow desktop emulators actually put Adafruit/Sparkfun styled board (like I'm using) on the Windows Emulation in order to have real sensors informing the desktop runner. Unfortunately it's SPI only for the time being. So all of the I2C devices that I use for direct sensing will have to wait. (or if for some reason I run out of things to do, I might give it a go to contribute my own driver) https://a.co/d/gT33oWz

[houstonhaynes]

Hey @JordanMarr I just saw your PR for the "JpegLoad" branch which looks really tight. I'll be trying it this morning. The 1.3 updates for Meadow just came through last night and I put them on all of my boards before I called it a night. So this will be one of the first I'll try this morning. 👍

[houstonhaynes]

Brilliantly done! Worked without a hitch! There was one nit which I found in the old version - likely my code misleading you. There's an assign at the end of `toggleVentilator'

        let toggleVentilator enabled =
            if enabled then
                if not relayOne.IsOn then 
                    Resolver.Log.Info "Ventilator ON..."
                    relayOne.Toggle()
                if not led.IsOn then
                    led.SetColor(onboardLEDColor)               
            else 
                if relayOne.IsOn then
                    Resolver.Log.Info "Ventilator OFF..."
                    relayOne.Toggle()
                if led.IsOn then
                    led.IsOn <- false

That's it!

[houstonhaynes]

I just checked in the update to your repo on that branch and will pull in the PR - then merge it to my main branch. (I've given up on using SimpleJpegDecoder for now and am just using BMPs for the time being)

[JordanMarr]

Woohoo! That was a lot of fun. I really enjoyed working on it.

[houstonhaynes]

There's a LOT more work to do in order to make this something I'd call "idiomatic" - as the idioms in certain cases have yet to form. 😸 I'm so grateful for the huge springboard you provided - and the fact that you did it with no actual board/sensors to work with is just astonishing to me. Thanks again!

[houstonhaynes]

FYI - I might have just roped you into an "Amplifying F#" video conf session to talk about Elmish and WildernessLabs (my original topic was going to be my solar tracker but I may digress into the VOC/CO2 project oo)

[houstonhaynes]

One last note before close this out... I updated the app to use the VOC value (the "back half" of the tuple returned from the device driver) instead of CO2. I found two interesting nits that likely carried over from some of my old code.

1. There's a difference between CO2 and C02 😆 ... I know I've done that so many times I've lost count. Probably the most expensive mistake in technology (putting O and 0 adjacent on a QWERTY keyboard) aside from the introduction of 'null'. 🙄 😀

2. There were places in writing to the canvas that didn't have Units declared. So model.PreviousVOCValue placed a whole number when it was (assumed) PartsPerMillion. But as soon as I switched to VOC (which is parts per billion) then I started to see whacky decimal values on the display. I thought it was a bug in the Units.Concentration spec but the color coding was still working. I finally figured out that the canvas DrawText needed to be similar to model.PreviousVOCValue.PartsPerBillion that everything lined up as integer values - the same as the CO2 at parts per million.

That was a genuine head-scratcher for a minute. I still think that's some kind of latent bug but I'm not entirely sure I want to put the time in to ferret it out. 😸

[houstonhaynes]

FYI https://blog.wildernesslabs.co/creating-lightweight-hmi-with-microlayout/ 👀