Feature: delayed commands

[Abyss777]

There are some devices that do not keep tcp connection. Send data and close it.
Other devices can be configured to wake up rather rarely (once a hour/day/week).
Sometime it is really hard to catch when device is online.
We can implement some kind of delayed commands.

I see it like:

• Accept commands even if device is offline
• If device is offline place command to some per-device-queue
• As soon as device becomes online try to send all commands from queue to it.

There are some possible problems that also should be solved: interface to flush queues, command expiration and may be others.

Or we should not spent time to such solution and direct our efforts to fallback on sms commands...

@tananaev what do you think?

[tananaev]

It's a very useful feature. I know quite a few users implemented similar functionality themselves.

Not sure about SMS commands. Technically SMS commands can be more useful, but require some gateway to send messages. Probably mobile phone can be used for that.

[Abyss777]

I have not found any open-source android application for remote SMS sending.
We can consider some open-source SMS gateway and implement its support.
Like https://playsms.org/ or https://www.rapidsms.org/

Anyway, I think it's worth to implement internal delayed commands, we can re-use part of its infrastructure to sens SMS in future.

[jaimzj]

I have few a suggestion to make on sending SMS.
There are three methods that can be used.

1. Mobile Phone or GSM SMS Modem

• This might be the best solution, to provide interface to connect a Phone or GSM Modem.
• As most tracking devices would need to send response back to the sender of the command. (Thhis can be the best solution, as responses can also be seen and or read).

2. Web-API web-services of providers.

• Most Bulk Transactional SMS providers, have and do provide Web-services, which can be queried to push SMS.
• In traccar a provision can be made where Users can set their SMS providers api url and certain authentication and additional parameters to be called with the URL. including the message content etc.
• Easiest to implement, probably and will work with all and or majority such sms providers.
• And most traccar users might prefer this.
• DRAWBACK, In many countries, SMS sent' via this option do not have a virtual number or actual telephone number, thus the responses from devices will never reach back to the sender.

3. SMPP Protocol (This is the best method to connect to the SMSC of operators).

• https://jsmpp.org/ (Open source library for connecting to SMSC's of telco operators and or providers)
• Few but many well known SMS providers also provide SMPP protocol based connectivity to their SMSC.
• This might be the most difficult to implement, However this is the industry standard protocol for Communication between SMSC's of operators.

[Abyss777]

The first one covers only part of users, that installed traccar on real hardware. But big part use VPS/VDS and can not install modem/connect phone to server.

Also, some devices accept SMS only from approved numbers, they won't work with services which do not send CallerID or send dinamic CallerID

[jaimzj]

@Abyss777 Yes both of it is true you are right.

But some providers, do allow sending SMS from VNM (Virtual numbers) so maybe we can make provision for web-services based SMS sending option. this way if the user has an option to have Virtual Number, he can keep that number as approved number and utilize this feature.

The same is possible with SMPP protocol as well. (But like you said, not all providers or region support) dynamic or numeric valid numbers.

[Abyss777]

Another problem with web-services is they really Zoo. I studied a few push-services API to implement push notification. It is really impossible cover all. One use POST, other GET, one accept authorization in request, other in header, one use JSON, other XML and so on. Wrapper will be really complicated.

[jaimzj]

Then, All I can think of is implementation of SMPP Protocol for SMS.

• All SMS Aggregators Providers.
• All Telecom Service Providers.
• And All Medium to Large SMS Providers do provide SMPP accounts and access.

---

SMPP can also have virtual numbers assigned to the account.
SMPP is the Standard protocol used by telco's to interconnect their SMSC's and does not change. (The methods)
Implementing SMPP Client in Traccar could not just help in sending, but also reciving SMS's.

[tananaev]

I think SMPP is the best option. It would also be nice to find or implement a mobile app that would act like SMPP server.

[Abyss777]

I've found one https://play.google.com/store/apps/details?id=com.ozeki.androidsmppsmsgatewayfull
There is also free version https://play.google.com/store/apps/details?id=com.ozeki.androidsmppsmsgatewaylite

[tananaev]

Nice, so there is already an existing solution.

[jaimzj]

If there is a ever a need for SMPP accounts, for testing, Please do let me know I can try to get a LIVE SMPP accounts for testing purposes. (In the country you would want to test it for). from my current SMS Provider who does have international routes.

[Abyss777]

@tananaev how do you feel, what is the ratio of protocols where:

• GPRS and SMS commands are the same

and

• GPRS and SMS commands are different

I mean which are more?

[tananaev]

I don't have much insight into SMS commands, but I think most of the time they are different. Or often SMS commands are wrapped into a packet with some special header and ending to be transmitted over GPRS.

[Abyss777]

The next question is, how do you think, should SMS commands be some kind extension of protocol encoders and be like fallback transport or they will be something totally different?

Also may be... some day... we will implement SMS decoders to some protocols.

[tananaev]

I guess they can be separate encoders.

Decoders can also be separate from GPRS versions.

But everything can still be based about Netty framework.

[Abyss777]

I'm not sure if we can put SMS (received by other library) to Netty queue. But if we can it would be great.

[tananaev]

If we use SNMP protocol for SMS, we can use Netty for it. That was my idea.

[Abyss777]

Hello, @jaimzj
Is your offer about testing accounts still up to date?
If yes, it would be great to get account for Russia. My mail is in profile or project readme.

[jaimzj]

Hello @Abyss777

Yes I can provide you the accounts, but I might need a day or two, as I am currently travelling (around 19th february i can email you with the details is that okay?)

[Abyss777]

@jaimzj Sure, it is OK.

[Abyss777]

Want to come back to queued/delayed protocol commands because of a few reasons...

• We have SMS, but it costs money, It is really necessary only in a few cases like: configure server IP or do something urgently. In many other cases it would OK to wait when device comes online and send command.
• I remember you discussed somewhere commands to Traccar Client and send them in HTTP response. I think to implement this we anyway need some mechanism to temporary store commands until osmand client connected to put commands in response. We would use the same queue mechanism.

[tananaev]

Sure. It's one of the frequently requested features.

[Abyss777]

I believe fallbackToText flag is meaningless when queues are implemented. If it is enabled command never be queued. What do you think?

[tananaev]

Maybe user wants to execute something immediately. For example stop engine, so he can't wait and wants to force use SMS straight away.

[Abyss777]

He can tick "Send via SMS" in Send Command dialog.
Also I see some confusing thing in current behavior. User can get "Unsupported command" error if he sends supported channel command, fallback to SMS, but it is unsupported via SMS.

[tananaev]

Then I agree that it's basically useless if we implement queue. The only corner case I can think of is when server is stopped we would probably lose all the buffered commands, so user might want to send SMS as a last resort. Or do we plan to store commands in the database? It might be too complicated.

[Abyss777]

No, I do not have plan to store buffered commands in DB, at least for now.
But I'm not understand how will we send SMS as a last resort after server restart if nothing buffered?

[tananaev]

Not after, but before. In the Main class we have shutdown hook which can execute some code before shutdown. Basically we can send remaining commands in the buffer using SMS before shutting down.

[Abyss777]

Interesting idea, but I think we need other config flag for that textCommandsOnShutdown or something.

For me corner case is when user select online device, want to stop engine immediately (his car is stolen), but while he selecting command device becomes offline. He push "Send" and command is put in buffer. If he noticed that device became offline he have to send command again via SMS, but if he misses that he may lost priceless time.

[tananaev]

I suggest we remove the flag for now and don't implement shutdown until people ask for it. It seems like a real rare corner case.

[Abyss777]

OK. One more thing...
My vision of handling send buffered commands errors when device becomes online:

• Successfully sent commands are removed from queue
• Command that causes RuntimeException (usually Unsupported) also removed from queue
• Any other exceptions not handled and interrupt process of sending buffered commands (I believe they related with connection and basically mean that device become offline again), rest of commands will be sent when device become online again.

[Abyss777]

Noticed one thing, why do not we remove device from activeDevice lists when its state become unknown? Traccar tries to send commands to such devices, I believe it should not. I have only doubts about UDP devices. What do you think?

[Abyss777]

It's interesting, are there any other protocols accepted commands in response?

[tananaev]

I believe we should buffer commands only if device is not online. We should not catch exceptions.

Unknown status can go either way. I don't really have any preference. Unknown can still be connected, but just not reporting, but it also can mean dead connection. Probably makes more sense to remove them.

[tananaev]

We already support commands queue.