UDP Virtual Output stopped working in recent releases?

[Jedi Tek'Unum]

Anyone else have UDP output stop working in the last year or so? Possibly with the version 16 release.

I've been using the same config for years that updates LED state in some custom hardware and it has worked fine. Appears no UDP packets are being sent by Miniserver. Only "network" between them is a dumb switch and UDP Virtual Input from same device works fine.

Long ago I remember that something to do with UDP died with a release. Eventually stumbled on a workaround which was to just change to different port numbers. I tried that today and it didn't help.

My VO address is /dev/udp/10.11.50.50/7123 (port 7123, it was 38000). The VO command is a string, "22 1", with HTTP Method for ON of "GET" (as it's always been). (I've never understood the logic of HTTP crap in this situation - the receiver only gets the raw string.) Use as Digital Output is checked.

Would sure be nice if they would actually test releases.

[Rob]

My UDP Virtual Outputs still seem to be working in Config 16.1, sending on/off command to external smart sockets just using their network IP.

[Evert van Es]

I also experienced this. I use about four different udp ports, and one stopped working.

Strangely when I changed the udp port on the sender and in Loxone the same logic started working again.

I never found the underlying issue.

Verstuurd vanaf mijn iPhone

Op 17 jan 2026 om 20:32 heeft 'Jedi Tek'Unum' via Loxone English <loxone-...@googlegroups.com> het volgende geschreven:

Anyone else have UDP output stop working in the last year or so? Possibly with the version 16 release.

--
You received this message because you are subscribed to the Google Groups "Loxone English" group.
To unsubscribe from this group and stop receiving emails from it, send an email to loxone-englis...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/loxone-english/57388ca0-0855-480a-82d4-a7bf04b47216n%40googlegroups.com.

[Jedi Tek'Unum]

Thank You!

I suspect this has been a bug for a very long time. Very odd that it goes for years through various releases and then once a given port starts having trouble it seems to stick forever.

I shall keep trying alternative ports.

[Jonathan Dixon]

Just to check was that issue with UDP virtual input, not output?

I used to get that quite regularly. Changing the receiver port number in Loxone would fix it, but also a hard reboot (hard power off the miniserver for 20sec) would also fix it. 

My hunch was it happened if i pushed too many config updates without a reboot, perhaps the thing that runs the TCP stack wasn't resetting properly. 

I haven't seen it for a couple years tho. Perhaps since I updated it to gen2 miniserver. 

For the OP I'd suggest using netcat in udp listen mode and send datagrams to that. And also use netcat to send test messages to the receiving side. I often do this and confirm both are working fine and it's some other thing stopped Loxone sender see the intended receiver (firewall or name resolution error)

Also does the miniserver log file or live diagnostics view have any clues? 

Hth

--

You received this message because you are subscribed to the Google Groups "Loxone English" group.
To unsubscribe from this group and stop receiving emails from it, send an email to loxone-englis...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/loxone-english/401c2d88-c0de-435c-bf84-84342f8f432bn%40googlegroups.com.

[Jedi Tek'Unum]

Only UDP Virtual Output. I would be in a world of hurt if UDP Virtual Input breaks - some 50+ switches come in that way!

Thanks for reminding me of the hard - and somewhat lengthy - power cycle.

Don't see anything relevant in the log (if I turn on logging for the VO I see entries for those events). I use netcat (and Wireshark if I'm desperate). It doesn't see anything from Loxone either. The box on the other end still responds as it should. It's not my network.

This is the same problem I had a couple of years ago. The apparent workaround then, fixing Network Periphery -> Network Intercommunication, is gone. In Network Periphery -> Configure Device  it shows gateway and dns values that are invalid. No matter how many times I correct them, apply, wait for reboot, they are still wrong (except...). They also don't appear in the config file!

My Miniserver and the box it is talking to are on subnet 10.11.50.x (a VLAN used for IoT). My desktop is on another VLAN/subnet 10.11.100.x. That Configure Device dialog has been showing 10.0.2.2 for gateway and dns for years and no matter what I do it won't accept corrections (I can type them in, apply, and reboot, and the old values come back). (Was showing that bad info even when VO UDP was working fine.)

In the process of trying to figure out where the H the UDP Monitor went, I tried to send Diagnostics (I'm on 16.1.x) to my desktop (which didn't show ANYTHING). I'm actually running Config in VirtualBox on a Mac and the VM was set to use NAT which happened to assign 10.0.2.2 to the VM. I changed VBox to Bridged mode and then got a 10.11.100.x DHCP value on the same subnet/VLAN as the Mac. By pure accident I discovered that Configure Device dialog in Loxone Config now CHANGED the gateway and dns to be... the ones for the 10.11.100.x VLAN! So it is overriding anything I enter with what it thinks is correct based on my client host!?

Now I have absolutely no idea if the Network Periphery has anything to do with my VO UDP problem but this behavior looks mighty suspicious. I don't have any other Loxone devices (except for DMX Extension) so no Loxone gateway is involved.

I've tried half a dozen ports, hard reboot (lengthy), etc with no joy.

My patience has about run out on this product. Still a flaky POS. For 7 years. I download to Miniserver and after it reboots it frequently comes back immediately with program not identical!

I suppose at some point I'm going to have to dump 7+ years of configuration with a factory reset and start over. Idiots.