Prevent from sending more then one Modbus TCP response
for a single request.
This might happen in the following scenario where,
shortly after the first response has been sent (4),
the second one will be send (8) (note the same
'TransactionId') triggered by the response to the
'ModbusSend' request issued by Berry (5).
The log excerpt from such a situation:
(1) 21:13:20.510 MBS: MBRTCP to Modbus TransactionId:520, deviceAddress:4, functionCode:3, startAddress:8193, count:1, recvCount:1, recvBytes:2
(2) 21:13:20.523 MBS: Serial Send: 04 03 20 01 00 01 DE 5F
(3) 21:13:20.647 MBS: Serial Received: 04 03 02 0A 28 72 FA
(4) 21:13:20.652 MBS: MBRTCP from Modbus TransactionId:520, deviceAddress:4, writing:11 bytes to client (error:0)
(5) 21:13:20.724 CMD: Grp 0, Cmd 'MODBUSSEND', Idx 1, Len 89, Pld -99, Data '{"deviceAddress":4, "functionCode":6, "startAddress":8192, "type":"uint16", "Values":[6]}'
(6) 21:13:20.743 MBS: Serial Send: 04 06 20 00 00 06 02 5D
(7) 21:13:21.009 MBS: Serial Received: 04 06 20 00 00 06 02 5D
(8) 21:13:21.014 MBS: MBRTCP from Modbus TransactionId:520, deviceAddress:4, writing:12 bytes to client (error:0)
Use 'tcp_transaction_id' field to denote that we already
sent a response.
Signed-off-by: Damian Wrobel <dwrobel@ertelnet.rybnik.pl>
* Add heat/dry/cool isee operation mode to xdrv_44_miel_hvac.ino
This add heat, dry, and cool isle operation mode to support new AC devices. Closes also #10937
* remove duplicated wide vane mode
* final ported range_extender
* removed #define USE_WIFI_RANGE_EXTENDER_PORTADD, because new framework-arduinoespressif32 @ 3.1.0+sha.22a3b096 is available with CONFIG_LWIP_IPV4_NAPT_PORTMAP=y
* Refactor and fix PID sensor (PID_USE_LOCAL_SENSOR) read race condition
Refactor PID since it was calling pid.tick willy-nilly upon demand
from MQTT and the web instead of on a periodic basis (and was being
called with time interval of 0 when those times lined up!). Refactor
web/mqtt display because there was shared code (that code turned out
to be misguided and belonged in Every_Second loop, but now we are also
similar to 39 thermostat)
Logging revealed that the vast majority of the time the sensor JSON
was parsed to obtain current sensor data when using PID local sensor,
it was failing to parse (and it would typically only work for a second
around TELE_PERIOD, but even then, not reliably). This bug almost
certainly affects xdrv_39_thermostat too, but using
xsns_75_prometheus.ino as a template, we are able to update PV once
per second, which allows us to be a lot more responsive. There is no
danger of being "too responsive" because that's the point of PID, and
the PID loop already scales feedback by interval between ticks.
* Reduce logging of PID now that query side-effects removed
* Comment out all new logging, but leave present for next debugger
Theo Arends
s-hadinger
Grzegorz
Barbudor
Damian Wrobel
pharaocurt
Jason2866
gemu
Tim Connors