Unique ID's and more, for smart devices

ke5stl9 years ago

Hey Anton,

not sure if this has come up elsewhere, but, I gather the idea with the device-id entry capability is to allow people to set what their ID is, even though a pseudo-random initial value is provided already.

I understand that.

However:

If I have 2 people (or more) that have devices, and they happen to have manually plugged the same value plugged into the device-id field, this causes issues, and, without digging too much, it appears that there's no good way of being able to deal with this.

ie: on the web site, the marker will hop from place to place based on the location of whichever device happened to report most recently, right?

This is actually something I've experienced! It's rather unsettling, and undermines the ability to really trust what the site is showing.

Here is a proposal for you:

it has the following components:

a) allow for the device to either set locally or obtain from the server upon initial contact, a unique id, and keep that id forever, or, at least, make it less easy to change, perhaps buried behind a button.

b) allow the device user to enter a 'friendly' identifier 'alias' that they would like to be known as, in the case where nothing else is defined on the server to override it. Just like how you don't want to typically see the imei of trackers, and can conveniently supply a more friendly label.

c) allow the user to also voluntarily provide their phone number, so that, if something happens, it will be easier for people to contact them.

If the tracker is using a TCP session, then these 'id' values would only have to be passed at the beginning of each session, or, if the values are updated, so I'd think they would cause minimal long term data bloat.

this would really help to keep the devices separate in the database at least, which would then allow you to disable a device that's being troublesome for some reason, or, override the device/user supplied 'alias' to something that you really want it to appear as on the map.

what do you think?

best regards,
peter

Anton Tananaev9 years ago

Traccar server supports more than 600 different device models or apps and Traccar Client is just one of them. I don't think it's a very good idea to develop that much additional functionality (e.g. generating ids on the server side and having aliases) that would only apply to one specific app.

One option I can think of is to display some warning to the user if he tries to change the id.

Another possibility is to lock user to some device-specific ID. There are several problems with this approach. One is that if user changes a phone and wants to keep history or for some other reason wants to continue old identifier, he won't be able to do it. Second problem is the device-specific unique id generated by Android or iOS is usually very log an it would be very inconvenient for user to type it on the server side.

I guess the main question here is... is it really such a common problem or is it a one time issue? Do you know if many people are manually changing their ids?

jaimzj9 years ago

Dear All,

There is a very rare chance of such a possibility or occurrence where two clients have same ID. even such that two users have defined a same ID for themselves knowingly or unknowingly.

  1. The server side database device list table has to be updated with the new ID set by the 2nd user duplication can be avoided.

  2. Using IMIE is the most appropriate way, As per me, as even if the user changes the mobile device, the new IMIE can be updated and mapped to the existing device of the same (person / user). records will still work historical as long as queries or not based on imie or Unique id but the device tables Index Id.

Just my opinion, and thoughts.

What I have done is, In My Android Client I have disabled the option for changing the ID by end user, that's about it and I capture all unknown devices from Log and has put in a system in place operationally to manage re-install of apps by user :)

ke5stl9 years ago

hello Anton and Jamejo,

I do appreciate the feedback and consideration.

But, my situation might be a bit different from yours.

in my case, the traccar system is being used to support sporting events, to show where the likes of service vehicles, lead competitors, last competitor, medics, ambulances, etc, are located.

On each sporting event, the role names tend to be repeatedly used. eg: SAG1, SAG2, etc.

Currently, people like being able to plug those names in as the device ID, which, from one standpoint, is good, because there is no having to go into the server side, and give devices labels - they are coming from the clients directly.

However, you can see that this will most definitely lead to a situation where, either, over time, or, while supporting multiple such events simultaneously, there is a high likelihood of duplications.

My ideal case would be:

  1. have a unique id that's displayed, but not changeable on the device, except in rare cases of duplications.
  2. allow the user to supply their phone number.
  3. allow the user to supply a 'tactical id' or 'label' value.

send this information to the server each time the client opens a session.

You do already have the situation where some trackers report additional information, such as the battery percentage, and whether the vehicle engine is running or not. why not allow this information to be captured in similar fashion?

best regards,
peter.

Anton Tananaev9 years ago

I think your problem can be solved by administrative measures. You just need some instructions on how to configure client and add new devices on the server. I guess you already have something in place as you need to change server address to your own one (unless you use demo server of course).

There are many use cases for tracking app. In your case it might be fine to allow app user to change label. In other cases it might be a security issue.

I am trying to keep app as generic and simple as possible. If you think you really need this custom behavior, it should be fairly easy to create a custom app for you. Let me know if you are interested and we can discuss this option.