I don't want every TRV on its own gauge, but if I did, setting that up was dead easy - I simply configured a switch node for that TRV. The "value format" on every other gauge knew which attribute to display, e.g.
{{payload.currentTemperature}}°c
Every time I added a new TRV to the central heating system, all I had to do was copy and paste 3 existing nodes, tweak the switch node, then tweak the captions.
Cut a long story short, that Pi died and rather than rebuild the legacy v1 dashboard I decided to build it in Dashboard 2. Instead of the new nodes using "value format" they're all hardcoded to use payload which basically means I now need to use change nodes to modify the payload feeding into each new Dashboard 2 gauge (or text field etc.)
While this works, it just feels spectacularly inefficient compared to the old way of doing it, and it clogs up the flow UI. So, is there a simpler way of doing this, that I am missing?
No there is not. It seems every widget needs it's own change or function node to set up the payload.
It does seem a surprising design choice that a DB2 gauge can only display msg.payload rather than eg msg.payload.temperature.
I wish too that the mustache value formatting ( which was performed by the vue library (?) ) had been replicated in the DB2 front-end but currently it is not.
Instead we have config inputs for prefix and suffix, which are I suppose less cryptic.
You can of course do that with DB2 as well, but since each widget only knows msg.payload, the function would have to emit customised messages through multiple outputs.
I could do, but that isn't the point. Why is this an issue? Well, this is just the first page of the dashboard, the one for the heating controls and it's already TREBLED the maintenance effort on just that first flow.
And this isn't even the most complicated flow I'm going to be rebuilding in v2...
This is an excerpt of what my v2 flow currently looks like:
That function receives a payload from an external API that in my test environment picks up data from ten different TRVs - one property is the name of the room the TRV is in.
The v1 logic was set up that way because I was in the process of installing more TRVs, so I tested it with 6 TRVs and over time added another four. The way this was set up made it near-effortless to add and remove TRVs from the dashboard. Clone an existing switch node, change its parameter, then duplicate another v1 guage and connect it to the switch. Job done.
In v2, to do the same thing, I've gone from needing ten nodes for ten guages, to needing 30 nodes for 10 guages. It works, but it doesn't look efficient.
I accept that things are not as they were in D1, but you were asking for alternatives to multiple nodes.
Another option (if the Repackage Payload nodes are all the same) is to have a function nodeRepackage Payload node (only 1) and then a Switch node with each of your rooms. Then any additional TRV only require an extra line in the Switch node.
I wasn't relishing doing this with the continuous monitoring of my MODBUS and MQTT kit though, because each different input from each serial interface generates a payload containing several properties, which then feed multiple dials and charts presenting different perspectives.
It's taken me about seven hours to swap out the next and gauge nodes from D1, to their D2 equivalents, simply because I keep having to add something new to transform the payload going into the new control. For example...
A "set msg.payload" step is only needed here because I can't just tell the Dashboard 2 text node to display msg.mydate instead of displaying msg.payload.
Depending on what your switch node is doing, you should be able to have one change node prior to th switch node to move the value to payload, while also moving the switching property to its own property.
If you had provided an exported example flow and data a simple example could have been provided in return.
