Fleet Management/telematics integration updated to latest

Hey everyone,

There were reports from users that the fleet management / vehicle telematics integration of OpenRemote (found here) was not working OOTB. I am happy to report that the issues are now fixed, and you’re now able to deploy it to your liking. The issue was related to newly updated OpenRemote images which needed to be updated in the software. This also means that the fleet management integration now runs on the latest version of OpenRemote.

Enjoy!

1 Like

Hi @panos ,

thanks so much for the update and it is working perfectly.
I am not struggling with two items:
a) implementing a custom map
b) implementing the support for Teltonika legacy devices (i.e. TCP connection).

Focussing on a) at the moment: I have followed the steps as in Developer Guide: Working on maps · openremote/openremote Wiki · GitHub and the instructions in the video but I am struggling with the fact that I still get the Rotterdam map at the end.
I have followed also the issue in Easy way to change map to another city? - #2 by Denis but I have the impression that the structure is slightly different as I get get a duplicate mount point when I add the folder as follows:
manager:
image: pankalog/fleet-management:${MANAGER_VERSION:-latest}
restart: always
depends_on:
keycloak:
condition: service_healthy
volumes:
- manager-data:/storage
- deployment-data:/deployment
- ./deployment:/deployment

Last question: shall I modify this variables as follows?
OR_MAP_TILES_PATH: …/deployment/map/mapdata.mbtiles
OR_MAP_SETTINGS_PATH: …/deployment/map/mapsettings.json

OR_MAP_TILES_PATH: ‘/efs/europe.mbtiles’

Just an additional hint for you: on Quickstart · openremote/fleet-management Wiki · GitHub there is probably a typo error as the instruction is: sudo docker cp -L fleet-management-proxy-1:/deployment/letsencrypt/live/{your FQDN}/fullchain.pem {path to your directory}/fullchain.pem

While the image is actually fleet-management_proxy_1

Just for the sake of being picky :wink:

Cheers,
Antonio

Good afternoon @glodea ,

Happy to hear everything works!

Now onto the issues:

To add your own custom map, you first need to download your own map, then add it as a Docker mount to the manager. Then you would need to set the in-container directory of the map file as a full path.

For example, you can download your own MBTILES from here: here or here. I’ll assume you have it stored at /Users/panos/openremote/customMap.mbtiles

To then add the file in the container, you need to add it as a volume. For example:

  manager:
    image: pankalog/fleet-management:${MANAGER_VERSION:-latest}
    restart: always
    depends_on:
      keycloak:
        condition: service_healthy
    volumes:
      - manager-data:/storage
      - deployment-data:/deployment
      - /Users/panos/openremote/customMap.mbtiles:/map/customMap.mbtiles
    environment:
      # Here are some typical environment variables you want to set
      # see openremote/profile/deploy.yml for details
      OR_ADMIN_PASSWORD: ${OR_ADMIN_PASSWORD:-secret}
      OR_SETUP_TYPE: # Typical values to support are staging and production
      OR_SETUP_RUN_ON_RESTART:
      OR_EMAIL_HOST:
      OR_EMAIL_USER:
      OR_EMAIL_PASSWORD:
      OR_EMAIL_X_HEADERS:
      OR_EMAIL_FROM:
      OR_EMAIL_ADMIN:
      OR_HOSTNAME: ${OR_HOSTNAME:-localhost}
      OR_ADDITIONAL_HOSTNAMES: ${OR_ADDITIONAL_HOSTNAMES:-}
      OR_SSL_PORT: ${OR_SSL_PORT:--1}
      OR_DEV_MODE: ${OR_DEV_MODE:-false}
      OR_MAP_TILES_PATH: '/map/customMap.mbtiles'

Theoretically, this would set the file that the manager would use for the map to the file you have mounted there.

About OR_MAP_SETTINGS_PATH , this defines the JSON file to be used by the manager to set various settings related to the map, like the borders, maximum and minimum zoom, box zoom, etc. If you just want to get up and running, you can ignore this for now and edit it on OpenRemote’s UI directly. If you want to take the JSON file from it, access the jsonsettings.json file in the container here: /deployment/map/mapsettings.json or by requesting https://{your FQDN}/api/master/map, but only take the options element. Or, if you do want to set this file, you would again have to mount it into the manager in the same way, edit your JSON file using this file as a base.

About the second question, the legacy server is a bit more difficult to configure, because of all of the environment variables that need to be set. You can either add the docker container into the main OpenRemote docker-compose.yml file or run it independently. In any case, you would have to set the environment variables using this file, adjusting for your case: TeltonikaLegacyCodecSupport/.env at main · pankalog/TeltonikaLegacyCodecSupport · GitHub

Most/some of them can be left untouched (for docker-compose to use the default values automatically), but I would have to listen to what your issues are to help you further.

Best of luck!

Panos

Hi @panos,

thanks so much for the excellent explanation.
I have gone through the steps and it worked perfectly.

Just for the sake of other potential readers.

  1. Just a note regarding the storage and the settings: initially it didn’t work, then I have realised, checking also the indications in Developer Guide: Working on maps · openremote/openremote Wiki · GitHub that I should have used the full path both for the volume. In my case it looks like:
    • manager-data:/storage
    • deployment-data:/deployment
    • /home/ubuntu/openremote/deployment/map/mapdata.mbtiles:/deployment/map/mapdata.mbtiles
    • /home/ubuntu/openremote/deployment/map/mapsettings.json:/deployment/map/mapsettings.json

and of course for the environment accordingly:
OR_MAP_TILES_PATH: ‘/deployment/map/mapdata.mbtiles’
OR_MAP_SETTINGS_PATH: ‘/deployment/map/mapsettings.json’

Here a snapshot of the site, including a perfectly working connection through MQTT with a vehicle, using an FMC003.

  1. As for the legacy support I agree it is best to add an additional container, running it independently, so that I can keep the two functionalities separated and isolated.

I would have questions specific to maps topics but I will open another thread on this.

Thanks so much.
Kind regards,
Antonio

Happy to hear that you’ve figured everything out with the map.

About the legacy server, if you look at its GitHub repository, it is available as a Docker container, but maybe adding it to the docker-compose of your main OpenRemote instance is going to be better for you. We didn’t do that as it is a bit more difficult to configure and it is not quite necessary (if anything, it builds upon OpenRemote’s MQTT capabilities for devices that do not support MQTT).

Let me know if there’s anything else!

Panos

Hi @panos,
I am back again.
I have installed the image as per GitHub - pankalog/TeltonikaLegacyCodecSupport: NodeJS-based Typescript server that can receive TCP connections and data from any Teltonika device, and forward it to an MQTT broker in Codec-JSON format also modified the .env as follows:
mqttOptions__host=fleet.mydomain.com
mqttOptions__port=8883
mqttOptions__protocol=mqtt
orOpts__commandTopic=command
orOpts__dataTopic=data
orOpts__realm=master
orOpts__teltonika_keyword=teltonika
udpServerOptions__port=myport

I have tried also with mqttOptions__protocol=mqtts.

I see from the console that the device is connecting to the legacy server:
Listening on all interfaces on port: myport
New Teltonika device connected with UUID f358e918-63c6-45a0-88b8-358e918d450c4856527
answered on socket
CONNECT: Device with IMEI 86463606xxxxxxx connected
86463606xxxxxxx Mon Apr 08 2024 1
86463606xxxxxxx Mon Apr 08 2024 1
86463606xxxxxxx Mon Apr 08 2024 1
86463606xxxxxxx Mon Apr 08 2024 1
86463606xxxxxxx Mon Apr 08 2024 12
86463606xxxxxxx Mon Apr 08 2024 1
86463606xxxxxxx Mon Apr 08 2024 1
86463606xxxxxxx Mon Apr 08 2024 12
86463606xxxxxxx Mon Apr 08 2024 12
86463606xxxxxxx Mon Apr 08 2024 12
86463606xxxxxxx Mon Apr 08 2024 12
86463606xxxxxxx Mon Apr 08 2024 12
86463606xxxxxxx Mon Apr 08 2024 12
86463606xxxxxxx Mon Apr 08 2024 12
86463606xxxxxxx Mon Apr 08 2024 12
86463606xxxxxxx Mon Apr 08 2024 1
86463606xxxxxxx Mon Apr 08 2024 12
86463606xxxxxxx Mon Apr 08 2024 12
86463606xxxxxxx Mon Apr 08 2024 12
86463606xxxxxxx Mon Apr 08 2024 12
86463606xxxxxxx Mon Apr 08 2024 12
86463606xxxxxxx Mon Apr 08 2024 12
86463606xxxxxxx Mon Apr 08 2024 12
86463606xxxxxxx Mon Apr 08 2024 1
86463606xxxxxxx Mon Apr 08 2024 12
(I am masking domain, port and other values for security reasons).

Unfortunately I don’t see any teltonika devices showing up on the fleet-management side.

I am not sure if I am missing something or done something wrong in the settings. Maybe you can help me quickly here please?

Thanks
Antonio

Good morning @glodea ,

This more than likely indicates either a connection issue to the manager or an authentication issue to the manager.

Just as a quick explainer, basically the script creates a new MQTT connection to the manager for each device, and then uses that MQTT connection to post device data. If no data is popping up, it may be because the device was unable to connect to the manager. The logs you pasted show that the device was correctly connected to the TCP server and its payloads were properly parsed (the number on each line of the logs with the date represent the amount of parameters sent by the device that were correctly parsed).

If you can, please attach/look at OpenRemote’s logs, as they usually contain information about if a message was sent to the manager or if an MQTT connection was made. Otherwise, take a look at the logs of haproxy, as they will also indicate any SSL/connection failures and also MQTT connections.

If you’d like to test it out, you can use your environment variables to:

Connect to OpenRemote’s MQTT broker (using MQTT Explorer / MQTTX) on {mqttOptions__host} and port {mqttOptions__port}, and then subscribe to topic ${opts.realm}/${uuid}/${opts.teltonika_keyword}/${imei}/${opts.dataTopic}

Are you attempting to run this on the same machine as the main OpenRemote installation? Then you could potentially use unsecured MQTT (port 1883) by referencing the manager’s IP address.

Let me know what you tried and what you got as output.

Best of luck!

Panos

Dear @panos ,

I have checked all settings and discovered, connecting to OR’s MQTT broker that at the end one of the issues was that I was using “command” and not “commands” in the settings.
Nevertheless, manually it is subscribing or kind of, but the device is still not showing up.
The log from the UI shows my manual subscriptions, but kind of no life signs from the TCP-to _MQTT client:

04/10/2024 17:06:53 INFO API ActiveMQORSecurityManager Un-supported request sub: topic=master/#, connection=/192.168.0.3:41570, clientID=6f2b3e5c-b704-41e0-9f53-d4c9643e83ae, subject=anonymous
04/10/2024 17:00:32 INFO API ActiveMQORSecurityManager Un-supported request sub: topic=master/#, connection=/192.168.0.3:45504, clientID=1dd4b618-d546-4092-b3aa-8b3692bc0e38, subject=anonymous
04/10/2024 17:00:29 INFO API ActiveMQORSecurityManager Un-supported request sub: topic=master/#, connection=/192.168.0.3:45496, clientID=d6184d4b-71ee-4e36-b276-047506a154c0, subject=anonymous
04/10/2024 16:59:29 INFO API ActiveMQORSecurityManager Un-supported request sub: topic=master/#, connection=/192.168.0.3:43142, clientID=2bbf2b66-5c53-43cb-9665-6a36a1d7ecf7, subject=anonymous
04/10/2024 16:27:40 INFO API ActiveMQORSecurityManager Un-supported request sub: topic=master/r/test-uuid/teltonika/350317178627737/data, connection=/192.168.0.3:57446, clientID=471c2fe2-cd31-403f-918c-0b5de6379657, subject=anonymous
04/10/2024 16:27:23 INFO API ActiveMQORSecurityManager Un-supported request sub: topic=master/r/test-uuid/teltonika/test-imei/data, connection=/192.168.0.3:50342, clientID=2b00ded0-cd8b-4479-8331-b00bd863045a, subject=anonymous
04/10/2024 16:23:36 WARN ASSET Error processing from N/A: AttributeEvent{timestamp=2024-04-10T14:23:35Z, ref=AttributeRef{id=‘7lJnQEF595e1f0vWmCMci7’, name=‘182’}, valueType=java.lang.Double} - INVALID_VALUE (Event processing failed value failed constraint validation: realm=master, attribute=AttributeRef{id=‘7lJnQEF595e1f0vWmCMci7’, name=‘182’}, event value type=java.lang.Double, attribute value type=class java.lang.Double)
04/10/2024 16:23:36 WARN ASSET Error processing from N/A: AttributeEvent{timestamp=2024-04-10T14:23:35Z, ref=AttributeRef{id=‘7lJnQEF595e1f0vWmCMci7’, name=‘181’}, valueType=java.lang.Double} - INVALID_VALUE (Event processing failed value failed constraint validation: realm=master, attribute=AttributeRef{id=‘7lJnQEF595e1f0vWmCMci7’, name=‘181’}, event value type=java.lang.Double, attribute value type=class java.lang.Double)

there are some issues anyway with attributes 181 and 182 (just FYI).
I have tried to check the Haproxy logs, but it is to stdout.

I am going to check if the client is working properly, but if you have any good ideas in the meanwhile it’s more than welcome.
Thanks
Antonio

Hey,

If you are running the server in the same host as the manager, can you try out using localhost for the host and 1883 for the broker port, and mqtt for the protocol? This makes the client point to the unsecured OpenRemote port using localhost (only accessible in the same host machine). Thus this will avoid connecting through haproxy. This will remove a layer of complexity so that maybe we can understand what’s going on.

Panos

Also, you can set your haproxy logging level by setting environment variable PROXY_LOGLEVEL on the haproxy service to either info or debug. The default value is info, which means that you should be able to view the logs. Are you not able to view the docker logs? You can also view the file /var/log/proxy.log that is inside the container, that contains logs.

OK I will try and let you know

While I set the system for getting a log, I have modified the index.js to insert some additional logs in there and got following:

Listening on all interfaces on port: myport
New Teltonika device connected with UUID 7b76fa87-d316-43c6-a32b-df822d5b843f
answered on socket
CONNECT: Device with IMEI 35031717xxxxxxxx connected
Error subscribing to command topic master/7b76fa87-d316-43c6-a32b-df822d5b843f/teltonika/35031717xxxxxxxx/commands: Error: Connection closed
at /usr/src/app/node_modules/mqtt/build/lib/client.js:714:49
at Array.forEach ()
at MqttClient._flushVolatile (/usr/src/app/node_modules/mqtt/build/lib/client.js:711:40)
at Socket. (/usr/src/app/node_modules/mqtt/build/lib/client.js:258:18)
at Socket.emit (events.js:400:28)
at TCP. (net.js:686:12)
Error subscribing to data topic master/7b76fa87-d316-43c6-a32b-df822d5b843f/teltonika/35031717xxxxxxxx/data: Error: Connection closed
at /usr/src/app/node_modules/mqtt/build/lib/client.js:714:49
at Array.forEach ()
at MqttClient._flushVolatile (/usr/src/app/node_modules/mqtt/build/lib/client.js:711:40)
at Socket. (/usr/src/app/node_modules/mqtt/build/lib/client.js:258:18)
at Socket.emit (events.js:400:28)
at TCP. (net.js:686:12)
Message received from device with IMEI 86463606xxxxxxx and UUID 7b76fa87-d316-43c6-a32b-df822d5b843f
Timestamp: Wed Apr 10 2024
Element count: 12
Published MQTT message: {“state”:{“reported”:{“16”:246,“21”:4,“66”:19566,“67”:0,“68”:0,“69”:1,“181”:18,“182”:16,“200”:0,“239”:1,“240”:1,“241”:22288,“latlng”:“xxxxx,yyyyy”,“ts”:1712771739000,“alt”:“145”,“ang”:“271”,“sat”:“7”,“sp”:“0”,“evt”:“0”}}}
Message received from device with IMEI 86463606xxxxxxx and UUID 7b76fa87-d316-43c6-a32b-df822d5b843f
Timestamp: Wed Apr 10 2024
Element count: 12
Published MQTT message: {“state”:{“reported”:{“16”:257,“21”:4,“66”:19590,“67”:0,“68”:0,“69”:1,“181”:18,“182”:16,“200”:0,“239”:1,“240”:1,“241”:22288,“latlng”:“xxxxx,yyyyy”,“ts”:1712771749000,“alt”:“143”,“ang”:“277”,“sat”:“7”,“sp”:“6”,“evt”:“0”}}}
Message received from device with IMEI 86463606xxxxxxx and UUID 7b76fa87-d316-43c6-a32b-df822d5b843f

Hello,

This shows that something closed the connections made to the MQTT broker. Now this could mean that the requests have not been routed correctly, IE they’re not reaching the MQTT broker, or they’re being closed automatically on connect.

Is this connection being made using a real IMEI? Depending on your configuration assets, there is a setting for only allowing connections from real IMEI values (actually calculates if the IMEI value is a valid one). I would try to get a payload from the ones you listed, and then on the same machine try to use an MQTT client to log in using the same host and MQTT port, subscribing to the data topic, and posting that payload. This is basically what the program does. Make sure to remember to use the same UUID as a client ID and on the topic.

I have rebuilt the fleet-management container exposing 1883, changed .env accordingly:
mqttOptions__host=localhost
mqttOptions__port=1883
mqttOptions__protocol=mqtt
orOpts__commandTopic=commands
orOpts__dataTopic=data
orOpts__realm=master
orOpts__teltonika_keyword=teltonika
udpServerOptions__port=56001

still get the same issue with local connection and MQTT instead of MQTTS:

Error subscribing to command topic master/dfefafed-233d-4783-af52-7abb95b505d0/teltonika/35031717xxxxxx/commands: Error: Connection closed
at /usr/src/app/node_modules/mqtt/build/lib/client.js:714:49
at Array.forEach ()
at MqttClient._flushVolatile (/usr/src/app/node_modules/mqtt/build/lib/client.js:711:40)
at Socket. (/usr/src/app/node_modules/mqtt/build/lib/client.js:258:18)
at Socket.emit (events.js:400:28)
at TCP. (net.js:686:12)
Error subscribing to data topic master/dfefafed-233d-4783-af52-7abb95b505d0/teltonika/35031717xxxxxx/data: Error: Connection closed
at /usr/src/app/node_modules/mqtt/build/lib/client.js:714:49
at Array.forEach ()
at MqttClient._flushVolatile (/usr/src/app/node_modules/mqtt/build/lib/client.js:711:40)
at Socket. (/usr/src/app/node_modules/mqtt/build/lib/client.js:258:18)
at Socket.emit (events.js:400:28)

Hi,
yes, at the moment it is a real FMB140 online and sending data = it is absolutely a real IMEI. I am testing only with real devices.
I will try tomorrow with an FMC003, since there the firmware allows to use MQTT and will switch between TCP and MQTT on the same device. As for the UUID I will need to change the code to override the automatic UUID generation, so I will keep the same…let’s see.
On the Openremote (Fleet-management version) I have created differente Teltonika Device Configurations based on the original FMC003 you had, with the AVLs generated as per your guidance.
The first time, with the device you see, I had just switched on the device and it marvellously popped up without any issues, therefore I guess this side is working perfectly.

I keep you updated as soon as I have news.
BTW have you tried it with a real device and it was working on your side? Just to understand if it is potentially a setup issue.
Cheers,
Antonio

Good afternoon,

I personally have tested this functionality using an FMC003 (switching between MQTT and Codec 8) device on its Codec 8 mode. I assume that it works with all Codec 8 devices, but I will try again with an FMC003 device to make sure that everything still works (Maybe recent updates have changed something).

Unless something is going terribly wrong, then since the packets are being parsed (as there are multiple elements and payloads are being generated), it seems like it’s an issue between the connection of the two containers. If it was a parsing/device issue, the application wouldn’t have been able to report the amount of parameters.

Panos

Good afternoon @panos,
I have run the tests with the very same device on MQTT directly to the Openremote and then switching on Codec 8 extended to the UDP-to-MQTT: the MQTT works, the Codec 8 nope.
I have taken the logs, separated in stdout and stderr and see overall the same behaviour.
Dumb question: when I connect directly over MQTT the connection is TLS with the certificate. When I connect on TCP I have disabled the TLS encryption, but I have the doubt about how is the MQTTS accepting a non-encrypted connection from the UDP-to-MQTT script.
If I activate the TLS encryption I obviously get following:
New Teltonika device connected with UUID 1a9ecde4-de06-4186-b51c-eedfa5f96015
/usr/src/app/node_modules/complete-teltonika-parser/build/Scripts/ProtocolParser.js:30
throw new Error(Preamble should be 0.);
^

Error: Preamble should be 0.
at new ProtocolParser (/usr/src/app/node_modules/complete-teltonika-parser/build/Scripts/ProtocolParser.js:30:19)
at processPacket (/usr/src/app/out/listenForDevice.js:20:25)
at listenForDevice (/usr/src/app/out/listenForDevice.js:8:27)
at Socket. (/usr/src/app/out/UdpServerManager.js:48:72)
at Socket.emit (events.js:400:28)
at addChunk (internal/streams/readable.js:293:12)
at readableAddChunk (internal/streams/readable.js:267:9)
at Socket.Readable.push (internal/streams/readable.js:206:10)
at TCP.onStreamRead (internal/stream_base_commons.js:188:23)

But even there, solving the encryption at the TCP connection would not solve the issue between the MQTT client and MQTT broker.
Am I shooting in the wrong direction here?

Using what you have just told me, and what I can see from the code, this problem is most likely related to the connection not being made from the legacy server to the MQTT broker.

If you give me more detail about networking between the broker and the server, I can see maybe what the issue is.

I dont think the issue could be related to using different devices. I’d focus on figuring out why the server cannot reach the MQTT broker. The main openremote documentation (Manager APIs) could give you more insight into how that works.

Best of luck,

Panos

The Preamble should be 0 message just means that the Codec 8 parser was unable to parse the message, which does make sense for this.

Just to make sure, does the device and the TCP server have the same exact hostname for connection with OpenRemote?

OK I think that is the case (connection not being made from the legacy server).
About the setup and answering also the question on the hostname:

  • the TCP server is running on an EC2 instance of AWS with hostname (let’s say mydomain.com). It is a FQDN with an elastic public IP and a specific private IP for the instance. I have defined a specific Port for the TCP server and the firewall is set to relay this one
  • Openremote is running on exactly the same instance, meaning that they have the very same network setup in terms of private and public IP, hostname, domain name and firewall
  • I have installed a mosquitto on the instance, tried to connect to the MQTT broker of Openremote both using localhost on 8883 and 1883 and it works. The same is working if I subscribe to the MQTT broker using the FQDN.
    Example like below:
    I used: mosquitto_sub -h mydomain.com -p 8883 -t “master/FMC003/teltonika/3503xxxxxx27737/data”

and suddenly this line shows up on the fleet-management container log:
2024-04-11 16:34:23.960 INFO [Thread-2 (ActiveMQ-serve…58b)] atics.teltonika.TeltonikaMQTTHandler.API : CONNECT: Device FMC003 connected to topic master/FMC003/teltonika/3503xxxxxx27737/data.

It means that the connection is OK, I need now to understand why it is not working from the TCP server.
I am going to deep dive into the Manager APIs and keep you updated.

Addendum:
I have reconnected the device and checked what happens on the very same log. Surprisingly no signs at all on the side of the fleet-management container log. On the TCP server log I get following for stderr
Error subscribing to data topic master/FMB140/teltonika/8646xxxxx772189/data: Error: Connection closed
at /usr/src/app/node_modules/mqtt/build/lib/client.js:714:49
at Array.forEach ()
at MqttClient._flushVolatile (/usr/src/app/node_modules/mqtt/build/lib/client.js:711:40)
at Socket. (/usr/src/app/node_modules/mqtt/build/lib/client.js:258:18)
at Socket.emit (events.js:400:28)
at TCP. (net.js:686:12)

while stdout continues to report publishing actions from the device, even though the subscription has not worked:
Published MQTT message: {“state”:{“reported”:{“16”:65217315,“21”:4,“24”:0,“66”:19374,“67”:4109,“68”:0,“69”:1,“181”:48,“182”:47,“200”:0,“239”:1,“240”:1,“241”:22288,“latlng”:“x,y”,“ts”:1712844955000,“alt”:“124”,“ang”:“109”,“sat”:“6”,“sp”:“0”,“evt”:“0”}}}

Thanks
Antonio