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
