I don't mind going through MQTT, just that putting the nodes and required paths everywhere is just more work and more opportunity to fat-finger stuff. Would be nicer to just link things up and elsewhere configure how to map to MQTT paths and which MQTT nodes to use, etc.
All this brings up more fun thoughts:
- You now have that flow for your whizzbang controller
- But of course, you really have three whizzbang controllers in your hand...
- Now what???
- Would be nice to have that MCU flow in a subflow, no? (I know it's not yet supported but on their roadmap [and I know how much fun it is to hack around the subflows...])
- Now what? You'd still have to create 3 flows just to plop down 3 copies of the subflow...
- WHAT IF the whole MCU flow thing wasn't attached to flows but to subflows, i.e., all flows run on the server, but you can have subflows that run on MCU
- Now you could have your overall flow, which includes inputs from a dashboard or other devices (all std server-side NR stuff), wires into the three MCU subflow instances for your three controllers, and then wires coming out of the subflow instances going to (server-side) visualization nodes.
- This seems like it would be very compelling to me, and more scalable too
Re: "ui_nodes", you realize these are implemented for local display on an LCD, right? If I can make friends with the moddable mcu stuff you can bet on FlexDash making an appearance...
