udp vs virtual text input + command recognition

[J V]

Hello,

I'm full reworking my config and realized something when I upgraded my router.

A lot of communication is done by udp, especially as I have Squeezeboxes and have their status send on the network via xAP. This is a udp packet, out of which the miniserver can extract data.
Now I'm using EventGhost to send other data to the Loxone (amplifier status, ...), and started doing that with udp broadcasts. Now it dawned on me that I could send it via an http call to a virtual text input and use a command recognition blocks. This would mean less broadcasts/traffic on the network.

I could use EventGhost to do the same with the data from LMS, sending an entire udp packet to a virtual text input. After that, I could put the music server and players on their own subnet and vlan, and thus no longer have the udp broadcasts on the part of my network with computers. In the Loxone tree, there would also not be a large number of udp inputs, but just a single virtual text input for each device, and a single page where all commands for this input are recognized.

I know that a couple of udp packets are probably not an issue on a gigabit lan, but with more use of vpn, remote desktop and videoconferencing software, perhaps everything helps. (2 people working remotely now) I also now there is no point if the broadcast domains will not be limited.

1. is there a functionality difference between udp input and virtual text input + command recognition that I'm overlooking?
2. is there a performance difference on the Loxone?
3. is there a point to limit broadcast traffic this way?
4. would it be more structured in Loxone Config (subjective question, I know)

What di you think?
Thanks,

Jörg

[Christian Fenzl]

My first thought is - if you send data by http, why at all do you still want to use command recognition instead of directly setting the different values to different VI/VTI’s?

UDP is easier to handle in the network stack for both sender and receiver than TCP/HTTP (shoot&forget, receive&forget).
But command recognition at all is load on the Miniserver, that does not appear if you directly set VI/VTI’s via HTTP.

[J V]

Good points...

I have to send the status of my amplifier from rs232 to the Miniserver. Best way I've found is to use Eventghost that takes the rs232 data and passes it on. It can do this any way you can imagine (protocol, packaging).

In my previous version, I used a huge amount virtual inputs and set all data on individual inputs (it was my very first attempt, I was a very newbie in both Miniserver and EventGhost, and all data from both amplifier and squeezeboxes were passed this way - far from ideal). This large number of VI/VTI's became difficult to organize.

I now parse the Squeezebox data in the Miniserver using UDP inputs, apart from text data (even though that is possible with a solution I've found on the wiki, which reads byte by byte ). Anyway...

1. Tthe problem with this approach (let's call it approach 1) is that I have to decode the rs232 data on EventGhost (this means making an entry for every event), and send each individually decoded command differently (many small custom Python scripts, where the path is the main difference....(*)). At the Miniserver, it meant having many virtual inputs whose name and data have to be fully matched with the Python scripts in EventGhost. This turned out to be quite difficult to maintain, as there are many such events.
2. From this I thought to just pass on the rs232 data via UDP (approach 2). In EventGhost this means taking any event from rs232 and almost blindly pass it on. In the miniserver, this would mean multiple UDP inputs, but at least no issues with matching them with EventGhost (it really just passing things); all decoding would ONLY be in the Miniserver, based on the amplifiers API.
3. It was from this idea that I thought of going to a text input and the command-recognition to have less broadcasts on the network (approach 3). I'm not sure I have an issue with broadcasts, but have just installed a more professional network infrastructure (entry-level Ubiquiti), and realized that I could try to limit broadcast domains. So I'm trying to maximize the possibilities of the equipment.

So there are two issues I wanted to avoid: the big number of manually made connection points between EventGhost and the Miniserver (which have to match), and the broadcasts...
While typing this (*), I realized that these scripts could be parametrized into a single one, so I would not need to make a script for each event and I would not need to treat each event, just wildcard it as with the second approach...

Thanks!!!!

It is great to bounce ideas of you here... You've made me realize that I can make a mix of approaches 1, 2 and 3, with a single entry in EventGhost, where an rs232 event triggers a script that selects the correct VTI/VI and posts data. I would still have a number of VI/VTIs on the Miniserver, but as they have to match the http paths generated in the python script, there is just one side to maintain (now not with the amplifier's API, but with what EventGhost sends, something which could be the same as the amplifier's API but does not have to be).

I may still try to limit the broadcasts range of the xAP data from LMS, but that may be achieved by some network settings (broadcast address, subnets, vlans), or by a similar construction... That is not a priority as of now, priority was to find the most efficient method for the amplifier communication (and as I have to choose both sides, I have plenty of options), so first let's try to get the parametrized python script to work.

Thanks!