Ahh yeah I forgot these two things! I've now added them when CUE is first mentioned in "The system architecture" section, although not at the very beginning as I was trying to give an overview of the project and why I started building my custom solution first

> That's a really nice article, thanks. And I can see how separating the validation logic from processing code is useful. > What's not clear to me is why you chose this approach over existing OOP techniques, such as GoF Adapter Pattern, or even just interface implementation (as Go looses a lot of the ceremony of Java/C#).

Thanks for that feedback! Really appreciate it and glad you liked it. I'm planning to try get a series of posts written about the project and also CUE.

You are right I could have used adapters and/or interfaces. The main reason I went with CUE was to keep the transformation logic declarative and in one place. With adapters, I'd still need to write Go code for each sensor type

The goal I had was to minimise the amount of changes I have to make in my Go code. With my current approach I have minimal Go changes and just additions to my CUE schemas. When firmware updates land or I add new sensors, I update the schema and the generic processing code just works.

The CUE schemas are also portable. I can take them to other projects without trying to make generic reusable Go code that works across multiple codebases. The schemas double as documentation too, so if someone asks what a sensor reports, I point them at the CUE file rather than explaining how various structs fit together.

Honestly I also just wanted to try building something with CUE and this felt like a good use case for it