Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] randomInt() is not re-evaluated in Trigger conditions #3297

Open
2 tasks done
arikorn opened this issue Feb 18, 2025 · 3 comments
Open
2 tasks done

[BUG] randomInt() is not re-evaluated in Trigger conditions #3297

arikorn opened this issue Feb 18, 2025 · 3 comments
Labels
BUG Something isn't working

Comments

@arikorn
Copy link

arikorn commented Feb 18, 2025

Is this a bug in companion itself or a module?

  • I believe this to be a bug in companion

Is there an existing issue for this?

  • I have searched the existing issues

Describe the bug

If a Trigger is set to an time interval, with condition set as internal: Variable: Check boolean expression with the expression randomInt(0, 5)==1 (see screenshot). This either never triggers the action (to trigger a toggle button) or always evaluates true. After several tests it appears that the expression is only evaluated when the condition is defined or enabled (disabling the entire Trigger does not appear to cause re-evaluation).

Image

Steps To Reproduce

See screenshot in the description:
Time Interval 1 s
Condition randomInt(0, 5) == 1
Add any actions.

Expected Behavior

It should trigger, on average once every 5 seconds. Instead it either never triggers, or triggers every second

Environment (please complete the following information)

- OS:Windows 10
- Browser:Chrome 132.0.6834.160 (Official Build) (64-bit)
- Companion Version: v3.5.2

Additional context

This was an attempt to provide random intervals. A work-around was to add an internal variable that updates every second, such as $(internal:time_s)

Perhaps a better solution to my specific issue would be to allow random time intervals in the Events section. I will as that as a separate issue shortly.

@arikorn arikorn added the BUG Something isn't working label Feb 18, 2025
@Julusian
Copy link
Member

The basic problem here is that we cache the output of expressions, and don't consider that certain functions (eg randomInt) can introduce entropy into the result.
We do this caching primarily because all feedbacks do this, but I think it makes sense for these expressions so that we don't have to reevaluate them unnecessarily. for example, if this didn't use ranomInt, then there would be no need to reevaluate it.

So a couple of ideas:

  • Track that the expression called randomInt, and disable caching for this feedback. This needs some thought on if this will work with the trigger event 'on condition becoming true'. It might be fine, it might not. If the only condition on a trigger is an expression of randomInt(0, 10) > 5, how often should that be checked?
  • Be able to tell expressions that they should be re-checked on an interval. This would require the user to manage how often to recheck the expression, which gives them more control, but could be annoying and would likely result in us rechecking the expression a lot more than necessary.

@arikorn
Copy link
Author

arikorn commented Feb 22, 2025

@Julusian, I am wondering if the only place this matters is in Trigger conditions?

  • In actions, the expression is evaluated each time it's encountered. (Make a button to set a variable to the expression...)
  • In feedback, one could conceivably use "Check boolean expression" with randomInt() = xxx as the expression, but this makes little sense, since it's not actually reflecting any state. (i.e. if one want to test a randomly-generated state, one would store the random number/object in a Variable and then test the variable)
  • So, with my limited knowledge of Companion, that leaves Trigger conditions, where most likely the main use would be to make up for the lack of a random time-interval (my use-case ;)

Are there other places using randomInt() would make sense? or maybe there's concern about using unixNow() possibly as an arg to other timefunctions in a feedback?

@arikorn
Copy link
Author

arikorn commented Feb 27, 2025

I just realized that my comment about feedback isn't entirely correct:
An example of a reasonable use that would be affected by the update question might be to trigger after a certain time. For example
"Check boolean expression" with condition unixNow() > $(custom:targettime)
And even more so if expressions are allowed in text labels. Then one could create a countdown timer
"Button text string" with expression: "unixNow() - $(custom:targettime)
This is also an example of an expression that has both variables and functions but wouldn't update since the variable never changes.
(in this particular example, a workaround would be to use the variable $(internal:time_unix), FWIW)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
BUG Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants