UDP Virtual Out Stopped Working!

[Jedi Tek'Unum]

Looking for suggestions on how to debug this.

For years I've been using UDP Virtual Output to communicate on/off state to another system (that controls indicator LEDs). The other system is on the same subnet connected via a dumb switch. To make this reliable it was necessary to have 2 separate "outputs", one for "on" and one for "off" (because Loxone doesn't/didn't? repeat off state). All were set to repeat the packet every 60 seconds.

As a side, this same other system accepts button input from hardware and sends UDP packets to Loxone for switch action. (If anyone cares the switches are Wattstopper LVSW.) Loxone receives via UDP Virtual Input. This continues to work fine.

Recently I added some stuff (to receive input from a Shelly Button 1) and since making those changes I noticed that none of my UDP VO work. Loxone never sends a packet.

I was running the latest 13.1. Upgraded to current 14 as of today and no change.

LiveView activity shows all the expected behavior. I've checked the receiving application and I can send packets to it myself and it continues to have expected behavior.

This isn't the first time stuff like this has happened. I remember my Virtual Inputs (UDP) stopped working a few years ago and only through luck was I able to get it working again - simply by changing the UDP port! I have tried that here too but no luck.

[Jonathan Dixon]

Sorry to be the IT guy, but if you haven't already, try doing a hard power cycle.  Certainly for Virtual Inputs I've had it suddenly stop working, and changing port number "fixes" it, but eventually found a hard reboot also resolves it.

I imagine the PLC and TCP stack are on separate CPUs and sometimes get out of kilter with each other, and the soft reboot from reprogramming doesn't resolve it (the TCP stack stays up while most of the reprogramming happens after all).

* hmmm now I'm installing the PSU with battery backup. I might have to put in a dedicated kill switch on the MS specifically for this

--
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 on the web visit https://groups.google.com/d/msgid/loxone-english/9356ef69-442f-4bed-80cb-d023d19b30e4n%40googlegroups.com.

[Jedi Tek'Unum]

Old retired (c)rusty software engineer here. Thought never crossed my mind. Sigh.

I tried power cycling the whole mess. Lox, the other system, and the switch all together. Didn’t change anything. Tomorrow I will try going back to the original port number. I vaguely recall it was very fickle about which ports work.

I’ve got the same situation, battery power. I wonder if a timed relay would work to trigger a hard power cycle - from within Loxone. One would expect the “digital” outputs would power up with a 0 value and stay there until explicitly told otherwise. Will have to look for a relay.

I am not a fan of products that work “most the time”.

[Rob_in]

On Friday, 5 May 2023 at 22:24:23 UTC+2 Jedi Tek'Unum wrote:

I am not a fan of products that work “most the time”.

No, not at all. This problem sounds very annoying.

FWIW, I used to have a Legrand power measuring device that would sometimes just stop working for apparently no reason and needed a power cycle after that. Eventually I changed the network cable and this issue went away. Sounds unlikely, but you could give that a go?

Robin

[Jonathan Dixon]

On Fri, 5 May 2023, 21:24 'Jedi Tek'Unum' via Loxone English, <loxone-...@googlegroups.com> wrote:

Old retired (c)rusty software engineer here. Thought never crossed my mind. Sigh.

I tried power cycling the whole mess. Lox, the other system, and the switch all together. Didn’t change anything. Tomorrow I will try going back to the original port number. I vaguely recall it was very fickle about which ports work.

I’ve got the same situation, battery power. I wonder if a timed relay would work to trigger a hard power cycle - from within Loxone. One would expect the “digital” outputs would power up with a 0 value and stay there until explicitly told otherwise. Will have to look for a relay.

I am not a fan of products that work “most the time”.

Yeah I eventually made piece with this fault on the basis it only occurs from repeatedly reprogramming the device, which implies someone technical is around to administer the reboot when needed. Still pretty poor.

I'm considering writing some automations (maybe a Sequencer block) to perform power on self test of a lot of this stuff so if there is a fault I know asap after system startup

I also had (for first time) the internorm extension stop working this morning, fixed by a reboot :(

On Friday, May 5, 2023 at 12:00:17 PM UTC-5 Joth wrote:

Sorry to be the IT guy, but if you haven't already, try doing a hard power cycle.  Certainly for Virtual Inputs I've had it suddenly stop working, and changing port number "fixes" it, but eventually found a hard reboot also resolves it.

I imagine the PLC and TCP stack are on separate CPUs and sometimes get out of kilter with each other, and the soft reboot from reprogramming doesn't resolve it (the TCP stack stays up while most of the reprogramming happens after all).

* hmmm now I'm installing the PSU with battery backup. I might have to put in a dedicated kill switch on the MS specifically for this

On Fri, 5 May 2023 at 17:17, 'Jedi Tek'Unum' via Loxone English <loxone-...@googlegroups.com> wrote:

Looking for suggestions on how to debug this.

For years I've been using UDP Virtual Output to communicate on/off state to another system (that controls indicator LEDs). The other system is on the same subnet connected via a dumb switch. To make this reliable it was necessary to have 2 separate "outputs", one for "on" and one for "off" (because Loxone doesn't/didn't? repeat off state). All were set to repeat the packet every 60 seconds.

As a side, this same other system accepts button input from hardware and sends UDP packets to Loxone for switch action. (If anyone cares the switches are Wattstopper LVSW.) Loxone receives via UDP Virtual Input. This continues to work fine.

Recently I added some stuff (to receive input from a Shelly Button 1) and since making those changes I noticed that none of my UDP VO work. Loxone never sends a packet.

I was running the latest 13.1. Upgraded to current 14 as of today and no change.

LiveView activity shows all the expected behavior. I've checked the receiving application and I can send packets to it myself and it continues to have expected behavior.

This isn't the first time stuff like this has happened. I remember my Virtual Inputs (UDP) stopped working a few years ago and only through luck was I able to get it working again - simply by changing the UDP port! I have tried that here too but no luck.

--
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 on the web visit https://groups.google.com/d/msgid/loxone-english/9356ef69-442f-4bed-80cb-d023d19b30e4n%40googlegroups.com.

--
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 on the web visit https://groups.google.com/d/msgid/loxone-english/5e70e852-fcab-47e1-9bce-354af61bfcfbn%40googlegroups.com.

[Jedi Tek'Unum]

I've tried a variety of things with no success.

Poking around in desperation I discovered the attached device configuration. The gateway and primary DNS are wrong. I don't recall if they were correct before my network redesign over a year ago but they are definitely not on my network now.

So I power cycled. I corrected the gateway and DNS and was able to hit "Send" and it restarted. However, after a restart (more than once) it comes back with the OLD VALUES.

My other automation devices are on the same subnet so the gateway shouldn't matter. The Miniserver communicates fine with them for doing http things, just not UDP send. I really don't like anything pointing to oogle DNS servers although any DNS requests are going to be redirected at my router anyway (pfSense).

Fortunately this sudden unexplainable - and un-debuggable - problem only affects indicator LEDs. Upset would not begin to describe my state of mind if it was some functionality I absolutely needed. There is no excuse for this kind of basic failure.

After 5 years (for me) it seems there is zero hope this product will fulfill its potential. It's even more disappointing that "the market" can't do better.

[Jedi Tek'Unum]

Turns out the issue with network config is a problem with that part of the UI. That dialog comes from "Network Periphery" -> "Configure Device".

When the Miniserver is selected in the Periphery list then the Miniserver tab appears at the top and in it there is a Configure Miniserver. This is also available via pop-up menu and then Edit Properties. The dialog that opens is a different one with a Network tab. There I see the new parameters I configured.

I grabbed the log and it shows the correct net config as well.

Of course that leads to the next question... is the bad data in part of the UI actually used for anything? And why are the same config parameters appearing in two different places?

As a side, the log contents lead me to believe that the kernel does not restart when the program is updated. Power cycling shows "Reboot Loxone Miniserver" yet program update restarts show "PRG start program". So Joth is correct that a power cycle is different.

But... fixing the network config did nothing for the UDP send problem.

[Jedi Tek'Unum]

Re rebooting kernel vs program update...

"Reboot Loxone Miniserver" line in the def.log only happens when it is doing a software upgrade.

After a power cycle the log shows "PRG Reboot" followed by the version.

After a program update (save) the log shows "PRG start program".

[Jedi Tek'Unum]

SOLVED or more correctly BUG WORKED AROUND

Persistence sometimes pays off!

In Network Periphery -> Network Intercommunication is a field called Local ID. This was blank in my config and in fact I had never gone into this area. This is supposedly only for communicating with other Miniservers and I have none. This blank field was highlighted in pink and the object showed "not completely configured". I also have that in other places that don't matter.

Once I put a dummy value in there my UDP Virtual Outputs started working again!

I suppose someone will point out that if I had done a Project Cleanup and resolved every last one of it's complaints that this would have been caught. I don't do cleanups as I've got MANY complaints and little interest in going through and resolving every last one. Lots of them are simply objects that are not fully connected because I'm simply not using them at the moment.

At any rate, that is not an acceptable excuse for this problem. If they allow one to Save a configuration then it better not have this kind of bizarre misbehavior. If something is truly this catastrophic then either the Save should not be allowed - with appropriate obvious error message - or there should at least be an error in the log. It's 100% unacceptable to have a silent failure.

It's times like this (really most the times I touch this product) that I yearn for a good manual. This product is complicated enough that it really deserves a BOOK. Having said that, I once again laugh at the excuse that we can't have macros because it would make the product too complicated!

Finally, Network Periphery -> Configure Device (tool bar) still shows a dialog with incorrect gateway and DNS servers and I still can't correct them. Oddly, these incorrect values do NOT appear in the project config file and are there even when I haven't yet connected to the Miniserver.