Loxone Config 12.2.12.1 breaking change (HTTP outputs)

[Rob_in]

Heads up... looks like 12.2.12.1 breaks something with HTTP virtual outputs here.

Or rather, makes them slow. When I open up a debug log notice that a request is performed, seems to time out then a second' request happens and that does the work. Due to the timeout this makes the system respond slowly.

More to come... (when I figure out exactly what is going on and if there is a fix).

Robin 

[Rob_in]

Well... something odd is going on. I see things like this in the debug log:

> 00001006 10.1.1.20 08:27:59.015 08:30:10.136 ARP Incoming TCP packet from 10.1.1.1 has different MAC 70:4F:57:10:06:10 - 70:4F:57:10:06:10

 Erm... that MAC doesn't look any different to me!

The HTTP requests in question were regarding feedback to a lighting controller (ie. our Miniserver makes an HTTP request back to itself which should be instant but takes a second or so!). I did see that changing the HTTP host from the physical address of the Miniserver to 'localhost' worked a little, but still isn't great (or as it was before the 12.2.12.1 update).

Awaiting response from Loxone on a ticket I opened.

[ICT]

Please try http instead of https . It's working for me.

[Rob_in]

On Wednesday, 2 February 2022 at 14:15:04 UTC+1 i...@infiniti.om wrote:

Please try http instead of https . It's working for me.

I am using HTTP. And it does work. It's just slow. And it wasn't slow before the recent update which was my point. 

[Jonathan Dixon]

FWIW I updated to 12.2.12.1 (miniserver v1) yesterday and not seeing this issue at all.

TCP and HTTP virtual outputs all seem to be working as well as they ever did, sub second latency. (I don't have any loopback virtual outputs though)

Where exactly does that debug log message appear? I've not seen anything like that before. (Maybe I don't have the miniserver debug log set very high? I try and minimise use of  metric/logging that might cause it extra writes to SD card).

Just thinking out loud... What is IP 10.1.1.1 on the network? I'm guessing it's your switch/router.  Why does that debug message talk about ARP and TCP in one statement? are you expecting inbound TCP requests from the router? What do you see if you run "arp 10.1.1.1" from some other (linux) box? I'm guessing the 10.1.1.20 is the miniserver, so is there some weirdness that it's lost the route to itself on that addr and needing to send through the default gateway... still shouldn't be so slow though.

Hate to be that guy, but have you tried turning it off and on again? I've occasionally seen a hard power cycle is needed if the miniserver TCP stack gets into a weird state after reprogramming [normally manifests as inbound UDP packets not being delivered]

Sorry, probably not a lot of help!

--
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/bb77deb2-49bd-461d-a6f5-d2a60d9297b2n%40googlegroups.com.

[Rob_in]

On Wednesday, 2 February 2022 at 14:53:42 UTC+1 Joth wrote:

Where exactly does that debug log message appear?

In the 'Debug Information' (aka. Loxone Monitor) window reached in the 'Diagnostics' part of Loxone Config.

This thing shows CPU usage and the Miniserver usually bumbles along around 30%. Goes up to about 50% when turning things on and off with this API feedback. You can actually get it to 100% if pressing the switch fast. This sounds like an issue TBH - how does sending a single HTTP request few times a second max out the Miniserver?

Another oddity is that on my Windows VM that I use for Loxone Config this window just appears and is blank. Luckily it runs fine under Linux Wine so can see what's going on in almost native Linux.

Just thinking out loud... What is IP 10.1.1.1 on the network? I'm guessing it's your switch/router.

yes

 

Why does that debug message talk about ARP and TCP in one statement?

who knows?

 

are you expecting inbound TCP requests from the router?

no

 

What do you see if you run "arp 10.1.1.1" from some other (linux) box?

Looks fine.

 

I'm guessing the 10.1.1.20 is the miniserver, so is there some weirdness that it's lost the route to itself on that addr and needing to send through the default gateway... still shouldn't be so slow though.

Dunno, but I changed the feedback to use 'localhost' on the Miniserver and to begin it appeared to be slightly better. Than worse. It's OK again now. Something fishy for sure.

 

Hate to be that guy, but have you tried turning it off and on again? I've occasionally seen a hard power cycle is needed if the miniserver TCP stack gets into a weird state after reprogramming [normally manifests as inbound UDP packets not being delivered]

Urgh. This isn't good to hear :(

Thanks for your ideas anyhow,

Robin