- Add command ``DaliSend <address>|<address+256>,<command>`` to send command (address+256 is repeat) on DALI bus
- Add command ``DaliQuery <address>|<address+256>,<command>`` to send command (address+256 is repeat) on DALI bus and wait up to DALI_TIMEOUT ms for response
On ESP32, with `#define JPEG_PICTS` without the scripter, build fails due to the function `Draw_jpeg` being defined after use. Order swapped to satisfy the compiler.
Change tested to compile without errors, but not being 100% sure of when/how it is supposed to work, no verification of this.
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
- Fix cases where the subsequent Modbus packet
can be send to the serial port (triggered either by
'ModbusSend' command or request from TCP bridge)
before an answer was received to the previous packet.
This can happen in a setup where simultaneously:
- two (or more) modbus TCP clients are sending requests
through the modbus-proxy [1] to Tasmota,
- ModbusSend commands are executed (e.g. using Berry).
Log excerpt (from build with TASMOTAMODBUSDEBUG enabled):
14:51:18.940 MBS: Serial Send: 04 03 01 00 00 09 84 65
14:51:19.054 MBS: Serial Send: 04 03 10 0A 00 05 A1 5E
14:51:19.136 MBS: Serial Received: 04 03 0A 00 00 00 D0 00 00 01 AB 00 00 89 62
Fix adds 'waitingForAnswerFromSerial' flag which is set after
we send data to the serial port and prevents sending another
requests before we receive an answer or timeout happened.
Fix stores temporarily a 'ModbusSend' command data and tries
to execute it after Modbus response has been received or
timeout has happened.
- Add 'ModbusSerialTimeout' command which sets timeout in [ms]
for how long we will be waiting for an answer from the client device.
Default value is 1000 [ms] and it is not restored after reboot.
- Sends error 11 (0xB) (as TCP response) when no answer was received
from the serial port within the timeout set by 'ModbusSerialTimeout'
command.
- Add Modbus 'TransactionId' to the logging.
[1] https://github.com/tiagocoutinho/modbus-proxy
Signed-off-by: Damian Wrobel <dwrobel@ertelnet.rybnik.pl>
* add support for nexus protocol to RCSwitch library
Nexus protocol is used by temperature and humidity sensor that operate at 433 MHz.
It is used by various brands.
* calc separation limit for RCSwitch library automatically
Theo Arends
s-hadinger
sfromis
Grzegorz
Damian Wrobel
pharaocurt
gemu
Tim Connors
stefanbode
pbrinette
Steffen