Hi,
I’m trying to use the OpenRemote Fleet Management setup with Teltonika FMC650 devices, following the tutorial for the FMC003.
The FMC003 works correctly, but the FMC650 is rejected by the MQTT broker.
The FMC650 is configured as follows:
-
Firmware:
03.01.01.Rev.15 -
MQTT Client Type:
AWS IoT Custom -
Device ID: empty
-
Data Topic:
xxx/FMC650Test/teltonika/%imei%/data -
Commands Topic:
xxx/FMC650Test/teltonika/%imei%/commands -
Only the root CA certificate is configured, same as on the working FMC003
I captured the MQTT CONNECT packet on the OpenRemote Docker network. The FMC650 sends:
Client ID: <IMEI>
Username: x.x.de/<IMEI>
Password: empty
For example:
Client ID: 862xxxx6159
Username: x.x.de/862xxxx6159
The CONNECT flags are 0xC2, so username and password are explicitly present.
OpenRemote then immediately responds with:
20 02 00 05
which is MQTT 3.1.1 CONNACK: Connection refused - Not authorized, and the connection is closed.
This happens consistently with two different FMC650 devices.
The FMC003, using the same general OpenRemote setup, works correctly. My suspicion is that the FMC650’s newer AWS IoT Custom MQTT implementation automatically generates the username <broker hostname>/<IMEI>, while the OpenRemote Teltonika MQTT handling expects the Teltonika connection to be anonymous.
The FMC650 never reaches the publish/subscribe stage, so the configured data and command topics do not seem to be the immediate problem.
Have you encountered this behavior with FMC650 devices before? Would it make sense to adjust the OpenRemote Teltonika MQTT authentication handling so that an FMC650 connection with:
Client ID = IMEI
Username = <broker>/<IMEI>
Password = empty
can be treated similarly to the anonymous Teltonika connection used by the FMC003?
I can also provide the full tcpdump/hex capture if useful.