Virtual HTTP input

[Gast]

Hello,

The way I'm using virtual HTTP input is working just fine. I'm taking values from some miniservers and collecting them to one other miniserver.
I set it up by following the instructions on loxone website.

I add an image so maybe you could understand what I'm going to ask.
Is there a way of splitting the URL somehow so I would not have to do so many individual Virt HTTP inputs.
The links under KRT1 and KRT2 are similar. There will be more of them to around KRT50.
Every KRT is one different miniserver where data is being taken from.
And instead of doing all the different HTTP inputs for every single VI from KRT miniservers, Could I just do one Virt HTTP input for KRT1 and put many commands under it? Make it as a template and change only the IP of KRT miniservers.

[Christian Fenzl]

Hi,

is it necessary to pull the values?

A better way would be to push the values via UDP, and receive them with an Virtual UDP input.

If the Miniservers are in one house, an easier way to connect multiple Miniservers would be to use the Client-Gateway-Concentrator functionality. Then, you have one single program, and can use every input and output and memory object on every Miniserver. The communication is handled (invisible for you) directly by the Miniservers.

[Gast]

Thank you for the fast response.
Actually it is not necessary to pull the values.
UDP works aswell. But as I see, I need to set individual UDP recieve ports for every value. This still makes a long list of Virtual UDP inputs, instead of Virtual HTTP inputs.
I understand that HTTP and UDP are just different protocols, but the result is the same and the ammount of writing is about the same aswell.
Concentrator functionality is a really strong tool, but at the ammount of miniservers that are in the project, it is not reccommended to use this.
I think I just stick to Virtual HTTP inputs and write a macro to speed the work up a bit

[Christian Fenzl]

I think you are wrong regarding different ports for different values.

On the senders side, you create one Virtual Output with, for example, /dev/udp/192.168.0.77/9090
Port is 9090.
For every value you create a virtual command with some unique text, e.g. outdoor_temp <v.2>

On the receivers side, you create one UDP input with port 9090 and several input commands with search strings, for example "outdoor_temp \v".

Advantages are: Value updates are received realtime, and if nothing changes on the senders side, the receiver has no work at all.

[Gast]

Oh, I see what youd did there.
This is indeed the superior method!
Thank you, Christian!