Trigger button with multiple feedbacks

Wouter van der Post 6 years ago updated by Dennis Piet 4 years ago 14

I've created a trigger button with the following properties:

Image 25886

I've linked multiple feedbacks (that each return a value between 0 and 100) to it's value:

Image 25887

When all 4 feedbacks have a value 100, the button is in the "On" state (which is good).

However when 1 of the 4 feedbacks goes to 0, the button goes to the "Off" state. But there are still 3 feedbacks that return a value of 100. Why does this happen?

Under review


The Item takes the value of feedback. If you receive values from several feedbacks and you want to track them all, then make a group of triggers - one item per feedback. You can make a separate trigger that enables/disables this group. Ie sends 4 commands, but without feedbacks.

I do not understand what you mean.

Can you create a screen recording of how to set this up?


Simple, you need create 4 trigger with off state trasparent and connect only 1 feedback for each. Next set all item on same position.

On bottom item set the off state with your graphic.

Is not a best solution, but it's a simple.

I get it, you're right.. it not the most elegant solution.

Would rather like iRidium to change the functionality (or limit the relations to 1 if they are not planning to support multiple relations).


Francesco Zangara right. His proposal deserves attention.

Multiple feedbacks per graphic element are not forbidden to drag, but the reaction will be to change any feedback, the values of the others are ignored.


I don't think this work-around is an answer. Are you going to look at how this functionality is implemented now and change it to make it more logical? So support multiple relations, or limit it to 1.....

I'll try to clarify ...

The current logic is used by some installers, so it will be wrong to change something.
For your task there is a clear solution that will work well without the use of JS.
The question is answered precisely because I do not see what we could change, so that the logic does not break down existing objects? And again - because your question has a solution, why do not you want to use it?

Most installers have common knowledge about PLC systems and understand the "OR", "AND", "NOR", etc. logic very well. The current behavior is none of these and also strange in the context of a button. Who would want "the last state change of several feedbacks" reflected on a button? :s I honestly can't think of a scenario in which that would make sense.

Making it work like an "OR" or "AND" would make much more sense and would also be easier to explain. So if you don't want to change the functionality of the current trigger button, add another type of button "Logic button" that allows you to choose between OR/AND and that can work with multiple relations.

At this moment I've solved this by building a scheme with an OR construction for all the relations/feedbacks that is being written to a tag (see screenshot below). I've had to create more than 10 of these schemes in my project now.

Why not use the other solution?

Our projects are being worked on by multiple people, it's not easy to carry over a project (not only iRidium, but any project) that has 'dirty hacks' (because that's what I call it) in it to accomplish something. Layering buttons on top of each other is not elegant, not in any way. I want my projects to be self explanatory so that people can continue working with it, make changes and add functionality even when I'm not available to explain strange constructions that have been used. Using a scheme is also not the best solution in terms of self explanatory because you can't trace back the project tag to the scheme.


Good solution for buttons, switches and others!

OR, AND, NOT items can be used only for Boolean variables. But it is difficult to do something like this for several items that control one dimmer (for example). There are non-Boolean variables: "multiple relations" give an elegant solution to a task of controlling from several places.

OR, AND, NOT items can be used only for Boolean variables

That is not true, in the scheme above the "From Tag" items are linked to feedbacks that return a value between 0 and 100. And that works fine because everything other than 0 in a boolean world is true. So in the scheme if any of the Tag feedbacks return a value >0, the end result "To Tag" is true. If all return 0, the To Tag is false.

Ok. 0/100 values are logical levels of "boolean" signals again.

I have keep in mind the controlling the brightness (0-100%) of one lamp from several places simultaneously.

>> However when 1 of the 4 feedbacks goes to 0, the button goes to the "Off" state. But there are still 3 feedbacks that return a value of 100. Why does this happen?

Multiple relations behavior is easy to understand: a value is set by the last relation which tag is changed.

Why multiple relations are not recommended: there may be a problem -  if many relation tags change often, quickly and simultaneously, it may not be clear to end-users as it may seem to be uncontrolled changes. In addition an end-user may not understand why a relation that is interesting for him at the moment does not work (as you thought about those three relations with "100" values).

But multiple relations may be used successfully if you think properly how to organize them.

I just started with Iridium and found out the hard way about the strange handeling of feedbacks. I got completely different results than what I expected after adding multiple feedbacks to one button.

Then I started reading the manual and it said: "The feedback channel can be assigned only once. Otherwise the incoming data will be processed incorrectly."

Why does Studio accept assigning multiple feedbacks, when the manual says it can only be assigned once ?

Why is the behavior of these multiple feedbacks not clearly described in the manual ?

I think Wouter has a good point : there should be some logic

I also understand that Aleksandr wants to keep backwards compatibility.

So, I propose the following, that can do both:

Please add an extra property to the general tab of an item:


This property has at least the following options:

LTP (default) = last takes priority  (So last changed feedback sets value/text of the item. This is current behavior)

HTP = Highest takes priority





This way, when developer does not change the property it will work as before and all others can set the behavior they need.

In my case: I needed to have an error indicator that has 10 inputs that are 1 if no error and go to 0 when there is an error for that input. So I ended up writing Javascript to combine al these inputs to one project token "error". I had to subscribe to tagchanges for the 10 inputs, etc etc.

Much easier would be to drag the 10 inputs to my error-button as feedback and then set the new Multiple-feedback-handeling property of my button to "AND".