Tweet
Regarding timeout: it's also my understanding that this time is the maximum amount of time that the miniserver waits for a reply. The next polling cycle might start when either an answer was received or a timeout.
Regarding Tico's observations: the miniserver might only have a single "unit" to process all modbus queries, so the miniserver waits for a reply or timeout after any request was send out. In my case with a very short answer time from the polled device and a relatively high polling time, it does not reduce the total number of sensors that can be polled. However if the device has an answer time of 500 ms for a request and you have 20 sensors, it takes 10 seconds if only a single request can be processed at a time.
For curiosity I've reduced the polling time to 1s for all of my 38 sensors and have increase the timeout to 1000ms at the same time. The result: it does not work and I get a lot of errors "sensor does not deliver values". With Wireshark I can see that the polling for a specific parameter is about every 43 seconds. Well it's not exactly 38*1000ms=38sec, but I also have a few actors in addition to the sensors.
Then I've reduced the timeout back to 50ms: now I can see a polling cycle of about 2,3 sec for each parameter. Again it's not exactly matching 38*50ms=1,9sec.
It looks that Loxone has still build in some "safety" regarding modbus polling interval.
In a next test I've reduced the timeout to 10ms and kept the polling cycle at 1s: now I can measure a polling time of about 1s.
I found this in the release notes for 14.4.9.25:
Lessons learned: there is a correlation between the number of sensors for a single device, the polling cycle and the timeout. The actual polling cyle is at least <number of sensors> * <timeout> . This might especially affect modbus devices that require a higher timeout value. You should carefully set the timeout if you need a short polling cycle and have many sensors.
Regarding fragmentation: I have this option checked. The first sentence in the explanation from Loxone is wrong (in my opinion):
Fragmentierte Pakete - Es wird erwartet, dass das Gerät die Pakete fragmentiert sendet. Ist diese Option nicht aktiviert, wird die Antwort des Geräts beim Empfang des ersten Paktes ausgewertet.
With Wireshark I was able to verify that the device does NOT send fragmented IP packets. The answers are always short enough to fit into a single packet (packet length is about 60 to 66 bytes). In my opinion there is no need for a device to send fragmented packets, because Loxone is querying only a single register and the answer would always fit into a single packet. However it does not hurt to check this box. Somebody might ask Loxone about this option - to me it it does not make any sense.
Tico: you may try to create a second (or even more) modbus servers with the same IP address, split your sensors among these and see if this affects your results.
Regarding Tico's observations: the miniserver might only have a single "unit" to process all modbus queries, so the miniserver waits for a reply or timeout after any request was send out. In my case with a very short answer time from the polled device and a relatively high polling time, it does not reduce the total number of sensors that can be polled. However if the device has an answer time of 500 ms for a request and you have 20 sensors, it takes 10 seconds if only a single request can be processed at a time.
For curiosity I've reduced the polling time to 1s for all of my 38 sensors and have increase the timeout to 1000ms at the same time. The result: it does not work and I get a lot of errors "sensor does not deliver values". With Wireshark I can see that the polling for a specific parameter is about every 43 seconds. Well it's not exactly 38*1000ms=38sec, but I also have a few actors in addition to the sensors.
Then I've reduced the timeout back to 50ms: now I can see a polling cycle of about 2,3 sec for each parameter. Again it's not exactly matching 38*50ms=1,9sec.
It looks that Loxone has still build in some "safety" regarding modbus polling interval.
In a next test I've reduced the timeout to 10ms and kept the polling cycle at 1s: now I can measure a polling time of about 1s.
I found this in the release notes for 14.4.9.25:
- A3D9-T1055 Modbus High Performance Input
- reduce common minimum polling-cycle to 1s (except Air-Devices)
- up to 2 Sensors per Modbus-Server or Extension allow a minimum time of 0.1s
- if multiple modbus-servers with same IP (TCP) or multiple devices with same Device-ID(TCP + RTU) exists, performance sensors are disabled for these devices
Lessons learned: there is a correlation between the number of sensors for a single device, the polling cycle and the timeout. The actual polling cyle is at least <number of sensors> * <timeout> . This might especially affect modbus devices that require a higher timeout value. You should carefully set the timeout if you need a short polling cycle and have many sensors.
Regarding fragmentation: I have this option checked. The first sentence in the explanation from Loxone is wrong (in my opinion):
Fragmentierte Pakete - Es wird erwartet, dass das Gerät die Pakete fragmentiert sendet. Ist diese Option nicht aktiviert, wird die Antwort des Geräts beim Empfang des ersten Paktes ausgewertet.
With Wireshark I was able to verify that the device does NOT send fragmented IP packets. The answers are always short enough to fit into a single packet (packet length is about 60 to 66 bytes). In my opinion there is no need for a device to send fragmented packets, because Loxone is querying only a single register and the answer would always fit into a single packet. However it does not hurt to check this box. Somebody might ask Loxone about this option - to me it it does not make any sense.
Tico: you may try to create a second (or even more) modbus servers with the same IP address, split your sensors among these and see if this affects your results.
Kommentar