Hi,
I had the exact same issue with the Opta RS485 interface.
After debugging and sniffing the RS485 line with a USB‑RS485 adapter, I found that the Opta modifies the last byte of every RS485 frame, even when sending raw data.
Because of this, the CRC of any Modbus RTU frame is always wrong, so no Modbus slave will ever reply.
In my case the problem wasn’t the addressing or the Modbus function code — it was the RS‑485 transmission timing on the Opta. The Opta was cutting the DE line too early, so the last byte of the Modbus frame was getting corrupted. Because of that, the slave never recognized the request, and it looked like “no communication”.
What fixed it for me was:
- calling
RS485.flush()before ending the transmission - and adding a proper post‑delay (using
RS485.setDelays()) so the last byte has time to leave the transceiver
Once I did that, Modbus started working immediately and the slave finally responded.
So if your wiring and addressing are correct, you might be running into the same RS‑485 timing issue. It’s not obvious at first because everything looks correct, but the frame is actually corrupted on the wire.
I documented the full issue here, with code and solution:
Opta RS485 bug: last byte of any frame is modified (CRC always wrong)
Hope this helps.