[SOLVED] Button that passes through events as clicks but not config messages?

Dashboard
1

I have a Dashboard (v1) button that gets text and color property messages from a bespoke logic. And when clicked in the UI dashboard, it also triggers a complex logic behind it. That all works fine. Messages for config (font, color, label) arrive on input, and the button changes.

Now, I have a hardware button in the house that "noobs" shall be able to push without the need to fiddle with the dashboard UI on a device and locate that specific UI button.

So: I want the "hardware button pressed" event to arrive at the UI button and trigger it to fire the logic behind it. So I would normally simply active "If message arrives on input, emulate a button click". But I can't do that in this case, because if I do, every "config message" arriving also triggers a button click.

How can I control the buttons appearance AND only have those "hardware button trigger events" passed through? With dashboard v1 preferrably to not be forced to migrate/rebuild my whole complex logic (several dozen buttons on that dashboard also from various other flows; so I'd have to migrate them ALL just because of this one problem to keep all in one place - nightmare, even with half-automatic migration I fear).

Last resort, V2, if only that makes it possible... hope not :slight_smile:

2

You can define the button with HTML in a template node, listen to incoming messages, analyze them and decide whether to pass them to the button click handler.

3

Welcome to the forum @Radoom .

To distinguish between an actual button click and a passed-on message, set some extra message property eg

source: "inject"

That property will be passed on by the button, but an actual button click will not set it.

I expected to be able to do this with msg.topic but it seems not to work.

4

jbudd, thanks, that was a hint in the right direction. I had that in the back of my head yesterday but it was too late to allow it to come forward :slight_smile:

I have now added a property msg.isconfig to the inbound nodes sending format properties to the UI button node. I set it to be boolean (and true), but that really doesn't matter, as only the existence of a distinguishing property does the trick.

The hardware button node's messages do not have this property at all.
Also, the UI button will not add this property if it is clicked, nor will it remove it if it emulates a click on any incoming message.

So:

  • When a config message arrives, the UI button "auto-clicks", and the "unwanted" forwarded message still has the msg.isconfig property.
  • When a hardware event arrives (also, and as intended auto-clicking the UI button), or the UI button is actually clicked, the "wanted" forwarded or UI-triggered messages lack this property.

Behind the UI button node a switch node checks: msg.isconfig is null. With this:

  • only the intended messages (i.e. those that do not have the isconfig property) pass through this switch node
  • Config messages pass (i.e. fake-trigger) the UI button, but get lost at this post-filtering switch node.

Happy :slight_smile:

1 Like