Take Modbus device offline?

[Rob_in]

Hi,

We have a few Modbus devices in our system:

- A load of relays used to control roller shutters. Simple stuff.

- A ventilation system. Loxone controls the flow rate on this depending on humidity, etc. and monitors various parameters (air input/output temperatures for example).

When left alone, these devices work just fine, but there is an option to put the ventilation system into standby and I would like to use that, but...

When one puts the ventilation system into standby it no longer responds to the requests for monitoring. Ie. Loxone cannot query air temperatures - and this is to be expected I guess as there's nothing happening in this device.

The problem is this: I have noticed that the Loxone system seems to have a queue for I/O on the Modbus... erm... bus. If the ventilation system is offline Loxone sends queries anyhow, and when no response is received, waits, then sends the request again, then waits some more, then gives up. It does this for all the parameters it's monitoring. No big deal you might think, but when one activates a roller shutter command while this request-wait-resend-wait process is going on then nothing happens with the shutters. It seems the command to turn on relays is queued and not sent until Loxone has finished messing around waiting for the ventilation and only then will the shutters move. This waiting is not insignificant and annoying as you can imagine.

Solutions I can think of:

- Mark the ventilation system as 'offline' when it's in standby mode and prevent Loxone from trying to communicate with it. I don't think this is possible, but would love to hear if it is!

- Change the polling period for the ventilation monitoring to something long and hope no-one commands the roller shutters during the 20-30s period Loxone will be busy waiting to talk to an offline device. This is hardly elegant and not a real solution.

- At least modify the Modbus query so for X parameters it reads multiple registers in one query and thus is waiting for a much shorter time. Again, not elegant or ideal and TBH, don't know why Loxone doesn't do this anyway.

- Something else? Any ideas?

Cheers,

Robin

[Duncan]

rather than put the ventilation system in standby, can you use loxone and modbus to turn its fan rate so low as to effectively be off, but still repond to monitoring requests?

[Rob_in]

On Thursday, 18 January 2018 18:01:01 UTC+1, Duncan wrote:

rather than put the ventilation system in standby, can you use loxone and modbus to turn its fan rate so low as to effectively be off, but still repond to monitoring requests?

Sadly not :( 

[Tico]

The behaviour you're experiencing is interesting..... I've had a similar experience with the MODBUS flow 'stalling', or getting sluggish, but the root cause was too many parameters being monitored. After I reduced superfluous sensors to only the essentials, and tweaked both the polling rate and the timeout, the systems work fine. The system uses both actuators and sensors and it's using MODBUS TCP (no extension).

Are you using the Loxone MODBUS extension? That would be a significant difference to my situation.

           

In the images above, 'Datamanager 2.0 Modbus Server' goes to standby at night and doesn't respond to queries. The Hybridmanager Modbus Server runs constantly and the polling rate doesn't vary by more than 0.1 second.

[Rob_in]

On Friday, 19 January 2018 13:48:38 UTC+1, Tico wrote:

Are you using the Loxone MODBUS extension? That would be a significant difference to my situation.

Yes, I am using the Loxone Modbus extension.

I will try changing some of the polling, etc. parameters and see what happens.

Robin 

[Rob_in]

On Friday, 19 January 2018 22:01:27 UTC+1, Rob_in wrote:

I will try changing some of the polling, etc. parameters and see what happens.

Ahh... so there's the problem. On 'auto' setting the Modbus timeout is 1 second. Which doesn't sound a lot, but if you are reading 5 parameters and each has a 2 x retry when there is no reply then there's 10 seconds in the queue immediately.

I changed the timeout and delay parameters to 0.05s each and everything seems to work much better. Thanks for the tip.

Cheers,

Robin