When the Teltonika device connects to OpenRemote and there are a lot of payloads to be delivered (that were not able to be delivered while the device cannot get a solid connection to OpenRemote), it seems that the set timestamps for the attributes are not being stored. We can see this by the fact that any attribute of the payload in question does not have the correct timestamp, but the attribute "lastContact", that stores that timestamp, has a completely different value compared to the attributes. The attributes have the timestamp of the current time.

Using a debugger, I can see that the timestamps are being stored properly until and when the attributes are passed to AssetProcessingService.

Research why Attribute.getTimestamp() is not being used when storing the timestamp as an Attribute Datapoint.

The Teltonika parameter list also includes a Description field, that describes exactly what each parameter means. For example, if it is describing a state variable, it explains which value represents which states, etc.

It would be useful to integrate this within each Attribute for OpenRemote.

If there is no pre-implemented UI element for this, I thought of adding a icon like this one next to the update attribute icon (if the asset is not read-only). When pressed, a pop-up appears with a title like "Attribute Description" and the body being the description provided by Teltonika.

I have come across using openrouteservice. It can be hosted locally as a docker container, it is open-source, and it returns the routes in GeoJSON format. It not only allows calculating routes, but also allows isochrone maps, time-distance matrices, and route optimization. In the same way that an mbtiles file is required for Maps to be rendered, openrouteservice requires a PBF file that contains all the metadata for shops, roads, streets, traffic indices etc. to then generate a route. It is able to generate a route by walking, biking, driving, through bus schedules, and even hiking, and the files are easily publically available for all regions of the world.

I have gotten the container up and running within my laptop, and it offers routes between points in stellar accuracy and efficiency, all within localhost, and automatically returns the result in GeoJSON format that is easily understandable by MapLibre. All that with minimal setup.

Using openrouteservice would allow OpenRemote to figure out which assets/cars are closest to a certain point of the map, create pre-planned routes for assets to follow, figure out routes between a car and a location it needs to go to, and even make an optimization feature about the efficiency of the routing a driver preferred over the optimal. By implementing openrouteservice, a considerable amount of features are then allowed to be implemented within OpenRemote.

There is a plethora of use-cases for which an integration of openrouteservice within OpenRemote would make development much faster and more efficient.

Maybe it would be a good idea to implement openrouteservice as a ContainerService, allowing for dependency injection, and thus accordingly disable specific features if the openrouteservice container is not present.

I am imagining something like ManagerKeycloakIdentityProvider or more appropriately MapService, the part of the TileServer implementation. That is, if we are unable to generate a connection to the ORS docker container, use the limited MapLibre functionality.

To allow different parameter ID lists for different device models, we require to create a new Asset Type that can contain the configuration data for each device type. That would include a list of TeltonikaParameters, maybe some other metadata, etc. We also need to insert a default configuration on handler creation if it does not exist.

We would also need a general configuration asset type, for setting default model number, and any other parameter data we would require.

SendAttributeEvent() ONLY updates the value of the Attribute, not any of the attribute's parameters. We could use this, by retrieving all of the already-created Attributes, seeing if they already exist in the Attribute, and if they do, only parse the value. If we do that, we reduce computation time for each packet.

Got pankalog/solingenDemo back up to working, needed to rebuild docker-compose and reconstruct the OSM graph.

Ideally:

• Write docker-compose to maybe wget files from geofabriek automatically, and properly mount them to the correct volumes? Users would just enter their PBF file link as an env var and automatically retrieve it and mount it and recreate the graph for it

• Need to decide if I should use MQTT with paho and native communication or the TCP server ( Python <-> TCP server <-> OpenRemote)

Hi
I followed the quick start and tutorial (just had to use docker compose instead of docker-compose). I tried it on a remote server running Server 22.04 LTS with a FQDM and on Docker Desktop on Windows 10. In both cases I get running images, but cannot login or do anything with the fleet-management. There are errors loading parts in the dev tools:

I tried to install openremote images to see if the issue was on my side. But this one works as expected:

Is there a known issue? which logs could I check to get what's going wrong?

The plan is to ask Teltonika directly about the meaning of all those parameters after updating them on the project's progress.

Ideally use the alerts implementation to send alerts depending on the priority value.