HTTP Virtual input Timeout? (or how to detect a dead HTTP server)

[Rob_in]

Hi all,

Another piece of information missing (or just buried?) in the doco? I can't find any reference to what is supposed to happen when a Virtual HTTP input experiences a timeout.

I have a couple of HTTP Virtual inputs running from a server on a Raspberry Pi which work fine.

However... I would like to ignore these when the Pi is offline. To this end I created an 'alive' Virtual input on the Pi. This simply responds '1' on the given URL. In Loxone Config I set up a 1000ms timout for this input, and validation (either 1 or zero) with a default value of zero. I would therefore hope that when the Pi is dead, this input would timeout and the 'alive' value would be recorded as it's default - zero.

But that doesn't happen.

In fact, from what I can tell, if there is a timeout reading a Virtual HTTP input the Miniserver just does nothing and keeps the previous value for any 'commands' under that input.

Is it just me, or is this pretty useless behaviour? Does anyone know if this is supposed to happen? And if so, how is one supposed to determine when HTTP services are offline and their values stale/unreliable?

TIA,

Robin

[Viktor Granbom]

Hi, use a ping block and this will work as expected!

[Rob_in]

Thanks. But...

... sounds like that will tell me when the Pi is up and not when the Pi is up but my helper process is dead.

I asked the question as it seems like a fundamental flaw in these inputs.

Robin

[Tico]

Could the validation be entered as 'Minimum value = 1' and 'Maximum value = 1'? Then, when it's not between that range (URL unreachable), it defaults to 0. Or does it still just read '1' after the timeout?

Polling interval could be set to an arbitrary 5 secs. The timeout needs to only reflect the latency in the polling response with a buffer.

But you are correct in discerning a major limitation of VI's...

For a check of an 'alive' state on a Pi, I've used a constantly changing variable (a time register) and have a logic comparison to discern if it's not changing.

[Viktor Granbom]

I guess there are several ways to try this but first, if it’s node js are you running the ‘forever’ program? Did the trick for me.

[Rob_in]

This isn't a discussion about how to keep your server alive. It doesn't matter what you do, eventually either the server is going to die, or connectivity between the Miniserver and Pi will be lost, or something else funky will happen. I'm looking for a way to detect this.

I like Tico's constantly changing value approach, but the original question is unanswered: what is the Miniserver supposed to do on a timeout?

Robin

[Tico]

I can provide my observations of what the timeout does in regard to Modbus polling. By extension, I think the same thing happens with HTTP VI's -

Let's say you have 20 modbus sensors and have a timeout of 500ms. The regularity of any particular sensor updating is influenced by the timeout. Increase the timeout, the sensors poll less often. Reduce the timeout, and the sensors update more regularly (but only to a point). I can 'tune' the timeout for my modbus network to effect the best update rate.

One modbus server operates over a wifi link and is best at 4000ms timeout.

A different modbus server is on ethernet and is best at 500ms timeout.

So the timeout is essentially an interrupt that pushes the Miniserver to the next sensor.

For HTTP VI's, I anticipate the same thing -

Practically, the Miniserver doesn't 'do' anything on a timeout. Except for cycling to the next VI. In the absence of a timeout, the Miniserver would conceivably get 'stuck', waiting for a response. If you had 20 HTTP VI's, that would slow the system down immensely.

It's just a pity that the timeout doesn't provide some feedback to the user. It's frustrating to realise I'm looking at 3-day old weather data when the VI has failed.