Automation Variable Handling Issue

[juzz197]

Version 3.14.1

Custom Variable: Performers

OSC Automation:
Address: /ontime/message/timer/text
Arguments: "Next Up: {{eventNext.custom.Performers}}"

If Performers is not Null it works as expected. If Null the message is set to: Next Up: {{eventNext.custom.Performers}}

[cpvalente]

Hi @juzz197
Do I understand correctly that the Screenshot is unrelated to the issue? The timer message doesnt currently support templates

As for the issue itself:

when we first implemented templates, we thought that it would be helpful to not send null in the cases where there is no value. This specifically helps when users are creating the automation and just want to test that it works, they likely do not have the correct data loaded at this point. The decision was to send the template itself as in "we did not have data to parse this".
This explains the behaviour you are seeing

Although I still believe that sending null is not ideal (the word doesnt mean much outside of a programming environment), I agree that sending the template itself is not particularly helpful since it doesnt distinguish a working template from a non working one.

Question from my side:
often users will try to parse and use the template value. What is a meaningful value that indicates the lack of data?

In your example, should we send Next up: ? or Next up: <empty>?
How about on timer values? what do we send when a timer is not running?

[juzz197]

Hi @cpvalente

The image was there just as a demonstration of the effect.

In this scenario, a blank string would be preferable, but appreciate this doesn't work well - certainly for non-string values.

A '?' or ' <Not Set> ' could also work here.

Perhaps a better approach would be to use the filter logic to test:

but this didn't seem to work - is there a way to test for Null/Not Null?

[cpvalente]

Hi @juzz197

In this scenario, a blank string would be preferable, but appreciate this doesn't work well - certainly for non-string values.

I had to get back to some discussions we had when implementing this.

This was something we didnt completely agree and decided for the most unopinionated implementation.

null and undefined are constructs (from the language in this case) of a empty value which are tied to how we implement the data
In my point of view, the user should not be exposed to this as it shouldnt matter what structures we use internally to signify empty values in the different cases

But we still need to show the user something, for the time values, they will often be parsed and stringified, so sending a '' could be problematic for users

In this case, maybe we can coerce all numeric values to null and string values to empty string like ''?

Perhaps a better approach would be to use the filter logic to test:
but this didn't seem to work - is there a way to test for Null/Not Null?

I agree. The initial idea was to have the empty / no value equating to null or undefined, but I see we forgot to do it in the not-equals comparison. If this is correct, you should be able to check if your custom field is undefined with the equals comparison and an empty value to match

Do you think it would be preferable to have a explicit is null / undefined and is not null / undefined or should we maintain the abstraction of these values and allow the empty value to signify any empty value?

[juzz197]

In this case, maybe we can coerce all numeric values to null and string values to empty string like ''?

This would work for me, hopefully others too!

Perhaps a better approach would be to use the filter logic to test:
but this didn't seem to work - is there a way to test for Null/Not Null?

I agree. The initial idea was to have the empty / no value equating to null or undefined, but I see we forgot to do it in the not-equals comparison. If this is correct, you should be able to check if your custom field is undefined with the equals comparison and an empty value to match

Confirmed it works for the 'equals' comparison and empty value.

Do you think it would be preferable to have a explicit is null / undefined and is not null / undefined or should we maintain the abstraction of these values and allow the empty value to signify any empty value?

I have a (slight) preference for the explicit 'is/is not null/undefined' as personally I'd fine it easier to interpret when looking at the screen quickly.