requestPhoto: How to Request a Remote Photo from Traccar

A camera that only fires on an event is useful for reconstructing an incident. A camera you can request a photo from whenever you want is also useful for verifying a load, checking that the driver is where they say they are, or settling a phone dispute in thirty seconds.

Traccar has a command type dedicated exactly to that: requestPhoto.

What requestPhoto is

It's one of the standard command types in Traccar's command model (TYPE_REQUEST_PHOTO, whose literal identifier is requestPhoto). Command types are generic: the interface shows you "request photo" and each protocol takes care of translating it into the specific frame its hardware understands.

Alongside it there are videoStart and videoStop, which are a different story entirely — those go through the live streaming path, which I cover in live JT1078 video.

Which protocols implement it

Here's the filter that saves you the frustration. The command existing in the interface doesn't mean your device understands it: its protocol's encoder needs to have implemented it.

The encoders that translate requestPhoto into an actual frame are:

• Fifotrack
• Meitrack
• PT502
• Ruptela
• Meiligao
• GPS103

In addition, other protocols trigger the photo request through their own path, without going through requestPhoto:

• Teltonika — requests the photo via its camera command (Codec12)
• GT06 / Concox — has its own photo request, which in some cases fires automatically upon receiving certain messages from the unit

If your device isn't on either of these lists, sending requestPhoto isn't going to produce anything. It isn't a configuration failure.

Sending it from the interface

1. Open the device in the panel.
2. Commands menu → new command.
3. Type: request photo (requestPhoto).
4. Send.

If the device is offline, Traccar can queue the command and deliver it on the next connection. That explains the queuedCommandSent events you see in the log: the command went out, not that the photo has arrived.

Sending it from the API

The endpoint is the same one used for any other command:

curl -u user:password \
  -X POST https://your-server.com/api/commands/send \
  -H 'Content-Type: application/json' \
  -d '{
    "deviceId": 12,
    "type": "requestPhoto"
  }'

Some protocols accept additional attributes (for example, the camera channel). That depends entirely on each protocol's encoder, so check the behavior of your specific model before assuming channel is going to do anything.

On-demand photo vs. event-triggered photo

These are two different flows and it's worth not confusing them:

Event-triggered photos (harsh braking, SOS, fatigue detection on DSM-equipped units) are not configured in Traccar: they're configured on the tracker, with the manufacturer's tool. Traccar only receives whatever the unit decides to send it. This trips up a lot of people who go looking in traccar.xml for an option that isn't there.

Where the photo ends up

Once the photo arrives, it's saved to disk under media.path, in the device's subfolder, and an image attribute with the file name appears on the corresponding position. Full detail is in how the media system works and in the media.path configuration guide. If you're still choosing hardware, see which cameras actually work with Traccar first.

When nothing arrives

In order of likelihood:

1. The protocol doesn't implement it. Check the list above. It's the number one cause.

2. The device is offline and the command got queued. Check its status before writing off the send as failed.

3. The transfer exceeded media.bufferSize (32 MB by default) and the server discarded it. Uncommon with photos, common with video clips.

4. The camera isn't properly connected to the tracker. On units with an external camera, the cable is a usual suspect before the software.

5. The file saved but you don't see it in the interface. Then it's a user permission issue on the device, or the reverse proxy. Check disk first:

   ls -la /opt/traccar/media/YOUR_IMEI/
   

That ls cleanly separates the two worlds: if the file is there, the problem is delivery to the browser; if it isn't, the problem is with the device or the protocol.