UDP Port Issue with Loxone Miniserver

[Gast]

Hi all,

I've encountered a baffling issue with my Loxone Miniserver that I hope some of you might shed light on. For years, I've had a virtual input on the miniserver configured to listen to port 55556 for UDP messages. This setup has been working flawlessly until recently.

Yesterday, I noticed that no messages were being received on this specific port. Initially, I suspected the device sending the messages might be malfunctioning, but this theory was quickly disproven when attempts to send messages from a different device to port 55556 also failed to show up in the UDP monitoring of the miniserver. As soon as I changed the listening port to 55557, everything started working again as if nothing had ever happened.

I have not made any changes to the configuration of the miniserver or the router recently (regarding ports), which makes this behavior even more perplexing. No reboots have changed the situation. Messages sent to 55556 do not show up in the UDP monitoring of the miniserver.

Has anyone here experienced something similar, or does anyone have technical expertise that might explain this sudden port anomaly?

Thank you all in advance for your time and help.

[Tico]

I have a similar issue I'm currently trying to resolve. The external device is a Bond Bridge Pro. This is a wireless transmitter used to control fans. The device has a keep-alive function that replies with a UDP message to the Miniserver when it is polled with a 'Command for ON' of \n. This message is received successfully.

The device is also meant to send it's current state via UDP whenever a state change occurs. These messages aren't received. The Bond tech support assures me the UDP feedback function is working.

The Miniserver appears 'deaf' to UDP messages on this port (outside of the immediate keep-alive response).

[Gast]

Encountered this phenomenon again: port 55557 (which I had chosen last time) has stopped receiving data via UDP. Here is what it looks like (picture below). Interestingly, last time, port 55556 stopped working, and it only started to receive data the day after I switched to port 55557.

[Tico]

Your symptoms sound like something I had a while ago. It was in fact a failing SD Card that was the culprit. I still have the same device connected, and the UDP failure is the best indicator to change the card over.
It's even better than the Loxone internal SD Card health check.

[Christian Fenzl]

I’ve experienced a strange behaviour of Miniserver during the core MQTT plugin development:
In the case that you use the same port as an OUT port on the Miniserver, the IN port gets locked somehow, not receiving any data.
IN and OUT port are independent usually, but that doesn’t seem to be true on the Miniserver (at least with Gen1).
Thats why the MQTT plugin/widget now uses different in and out ports to receive and send data from/to the Miniserver.

[Jan W.]

Hi Gast,
this really looks strange. Which version of Loxone Config do you have and which generation of the MS?

In regards to the post from Christian Fenzl : I'm not sure how the Loxone OS / kernel is operating, but in Linux it's not unusual that a program needs to allocate a local port from the OS first. I found an example in Java: https://stackoverflow.com/questions/...ng-udp-packets . Here the port (called socket) is allocated by datagramSocket = new DatagramSocket(); and in this example an unused local port is choosen randomly by the OS. In my opinion the OS is pointing to that process via socket, so whenever a packet is received on that port it will be forwarded to that process. With UDP typically the local process would send a request and may expect a response from the remote side.

I had a look on my MS and I've seen that I have a UDP input on port 7000 and at the same time I'm also using this port as an output for an ethernet to DMX converter. When I receive a packet from the remote system it is using a random remote port to send the data and the destination port on the Loxone MS on port 7000 (last four packets in the example). I would have expected that a UDP output connector on the MS would do the same, but Loxone is using the same port 7000 as the local port:



Technically it's working on my MS so far, but this shows that Loxone OS is not similar to Linux and my assumption that a local port / socket needs be allocated first, is wrong.

I would recommend to open a ticket with Loxone to solve the problem. It may be worth to choose a complete different port, e.g. 7000.

[Gast]

Which version of Loxone Config do you have and which generation of the MS?

Loxone Config 14.7.2.23
Miniserver Gen1

It may be worth to choose a complete different port, e.g. 7000.

The first thing I did when I encountered this phenomenon for the first time was to change the port. Everything worked on the new port. By the way the old port resumed working about the next day. However, after some time, the same thing happened with the new port as well.

Currently, I haven't changed anything yet in order to observe whether there will be any spontaneous recovery. And so far, there have been no changes. I'll try to open a ticket.

[Gast]

Today, I conducted a test and see that the port is working again. I opened a ticket yesterday. Now, support probably won't be able to understand what the issue was, since the malfunction has disappeared.

[J V]

This just happened to me... Miniserver Gen 1, version 16.1.11.6. The incoming UDP port sees nothing coming in. I just spent a whole day debugging if my device stopped sending, or if my rs232/eth converter is not behaving, until I found this thread... Moved up one port number and it just works.

I was using the same port of input and output, which was working for a long time (output port was set to close the connection after sending - don't know if that matters).

Tico: should I be looking for a new SD card? :-)

[Benjamin Jobst]

Some time ago I also encountered this issue with a spontaneously not working UDP Port. I had been using this port for my communication with self-made Arduino heat control for some years and from one day to the other the communication stopped. There was no obvious reason as I hadn't even touched the config nor the firmware for a while.

Here it was the same I swapped the used port and it started working again. But I'm quite sure I don't use this port numer for outgoing traffic as I configured the ports for several Arduino devices by counting upwards.
Currently I'm having trouble with the udp communication again but now it's spontaneous failure for some time - between 10 minutes and several hours until it just fixes itself without me doing anything. Until now I suspected the wifi or a disturbance by DECT repeater in the same socket as the problem got better after replacing the DECT repeater. But now I'm wondering if there might be also a spontaneous kind of blackout in the UDP of the miniserver...maybe I have to change the Rx port for this com and have a closer look...

But I'm also wondering how an old SD card could be the problem for UDP failure - I thought all the program is running on RAM. So far the SD problems occurred in saving issues like statistics or a miniserver reboot?

[alex1289]

Schönen Abend,

auch bei mir wurden nach einem Miniserver‑Programmupdate – das die betreffende UDP‑Verbindung eigentlich überhaupt nicht betraf – keine UDP‑Nachrichten mehr über den Port 55555 empfangen.
Nach dem Tausch der SD‑Karte hat es sofort wieder funktioniert.
Ich bin sehr froh, diesen Thread gefunden zu haben, denn auf diese Ursache wäre ich niemals gekommen und hätte wohl ewig weitergesucht.

LG, Alex