How to limit the frequency of sending data through a virtual output?

[Dmode90]

How to limit the frequency of sending data (JSON) through a virtual output in Loxone Config to ensure that data is sent no more frequently than once every 30 seconds, instead of every time the value changes as it currently does?

I am assembling a JSON using STATUS blocks tree and sending it directly to a virtual output. However, the data is being sent too frequently. I tried using a TEXT_GENERATOR block before the virtual output and triggering it with a pulse every 30 seconds. But when the trigger output value is low, it lacks values, and the virtual output interprets this as a change and attempts to send the empty value.

[duncan]

if you cant reduce the sampling rate directly from your virtual inputs, one option is to connect them to your status blocks via an analog memory block, and put a pulse every 30 mins onto the set input - this will transfer the input value to the output value every 30 mins

[Tico]

What about changing the Virtual Output 'Command for ON' to just <v>. The full 'Command for ON' is constructed in the Status-text field. In the Status-text field, place <v1> where the constructed text would normally go. Text input goes to I1 of the Status block. A pulse generator (29 secs off, 1 sec on) goes to I2 of the Status block. Then Status block logic -

If I2 ==1, Status-text Command for on <v1> here

The second line of the Status block is empty. Nothing will be sent on off.

[Dmode90]

if you cant reduce the sampling rate directly from your virtual inputs...

Could you please explain what you meant by reducing the sampling rate directly from virtual inputs?

one option is to connect them to your status blocks via an analog memory block, and put a pulse every...

Analog memory block converts string to 1.

[Tico]

I think duncan was referring to the raw numeric value coming from the virtual inputs and memory flags. An analogue memory needs to be placed on every input (x12?). The analogue memory will only retain numeric values. It won’t retain the unit appended to each value.
You can re-create the unit in the status-text field ( eg. <v1.3>rpm )
It’s probably simpler to execute the approach at post #3.

[Dmode90]

What about changing the Virtual Output 'Command for ON' to just <v>.

Done.

The full 'Command for ON' is constructed in the Status-text field. In the Status-text field, place <v1> where the constructed text would normally go. Text input goes to I1 of the Status block. A pulse generator (29 secs off, 1 sec on) goes to I2 of the Status block. Then Status block logic -

If I2 ==1, Status-text Command for on <v1> here

The second line of the Status block is empty. Nothing will be sent on off.

Done (if I understood correctly). But pulse placed to i4 input. And set to 15s (0.1ON, 14.9OFF)

But as a result, requests are still made more frequently than the pulse settings (15s).

[Tico]

From the last Status block you have pictured here -



Take the Txt output into a new Status block before the Virtual Output. This last Status block will contain the argument that will prevent changes flowing through to the Virtual Output.




I1 is the Text input. I2 is the Pulse Generator. Only when the Pulse Generator is high, will the command be executed by the Virtual Output.

To ensure you don't have any extra messages during the brief time that I2 is held high, I would make the Pulse Generator very fast. ie. Duration On = 0.2, Duration Off = 29.8.

The Txt output of the last Status block goes to the Virtual Output with Command for ON <v>

[Dmode90]

Take the Txt output into a new Status block before the Virtual Output. This last Status block will contain the argument that will prevent changes flowing through to the Virtual Output.

I did everything just like on your screenshots.

But unfortunately, when there's no pulse, the string disappears from the output of the status block.

So, the virtual output considers this a change and sends an empty message.

[Dmode90]

However, the solution you proposed here, with an analog memory block on each input of the status block, solves the problem but requires many monotonous steps.
It would be much more efficient if everything could be resolved by the last status block without analog memory...

Thank you so much for the tip. I would be even more grateful if you could help finalize the solution with the last status block.

[Tico]

I hadn't appreciated that all your data is going in the 'HTTP Body for ON'. The use of <v> in this field isn't effective for subduing unwanted messages.

When <v> is used for the 'Command for ON', it effectively kills the structure of the POST command. I don't have a solution unfortunately.

The analogue memories might be the only option.

[Tico]

Also try entering a white space (space-bar) on the second line of the Status Text. If you hover over the space, it will look like this -

[Dmode90]

Also try entering a white space (space-bar) on the second line of the Status Text.

Didn't help, the string still disappears from the output of the status block when the pulse block is at a low state.

[Tico]

The string should disappear when the pulse block is at a low state. What we really want to assure is that nothing is sent to the Virtual Output in the low state.
If a condition isn't satisfied in a Status Block, the final line in the Status-Text or Value will be output. That would normally be a zero in the low state. The white-space has had some success before in not being recognised as a value. Therefore, no value change and no POST command is sent.
Does the POST command send anything when the white-space is used? Does it cause issues in the downstream application?

[Dmode90]

What does the POST command send when the white-space is used?

White space as POST request body

Does it cause issues in the downstream application?

No issues, except for an unnecessary POST request, and the response with an error code.

[romildo]

...maybe in this way

[Tico]

Very nice romildo. Is it your view that the Status block behaviour has changed over recent upgrades?

[romildo]

no, I do not think so, but I don't know.