power cut alarm for pt502

I'm trying to get this alarm from one of my devices using the pt502 protocol (port 5017). I can see from the source code that this alarm is not implemented although I've seen other platforms successfully reporting power cut event for the same device. Any ideas on how to get this working?

Do you have protocol documentation with information on how this alarm is reported to the server?

I have no documentation, but I captured some messages from my device:

08:56:40 [49EE1860] HEX: 24504f532c333736303937312c3134353633372e3030302c412c323033362e333838332c4e2c31303332332e393833362c572c302e302c3131392e352c3238313131372c2c2c412f30303030302c30303030302f302f302f2f0d0a
08:56:47 [49EE1860] HEX: 24504f532c333736303937312c3134353634382e3030302c412c323033362e333838332c4e2c31303332332e393833362c572c302e302c3131392e352c3238313131372c2c2c412f30303030302c30303030302f302f302f2f0d0a
08:57:20 [46D3781E] HEX: 406002040631382e3030301300020d0a
08:57:25 [46D3781E] HEX: 24504f532c333736303937312c3134353730332e3030302c412c323033362e333838332c4e2c31303332332e393833362c572c302e302c3131392e352c3238313131372c2c2c412f30303030302c30303030302f302f302f2f230a
08:57:32 [46D3781E] HEX: 24504f532c333736303937312c3134353733332e3030302c412c323033362e333838332c4e2c31303332332e393833362c572c302e302c3131392e352c3238313131372c2c2c412f30303030302c30303030302f302f302f2f0d0a
08:57:47 [46D3781E] HEX: 404d02040634382e3030300900083236383135363335
08:58:02 [46D3781E] HEX: 406b0203073830332e3030300900053131392e35
08:58:17 [46D3781E] HEX: 404102040631382e303030
08:58:32 [46D3781E] HEX: 404b02040633332e303030
08:58:47 [46D3781E] HEX: 404202040634382e303030
08:59:02 [46D3781E] HEX: 404e0203073930332e303030
08:59:17 [46D3781E] HEX: 404002040631382e303030
08:59:32 [46D3781E] HEX: 404a02040633332e303030
08:59:47 [46D3781E] HEX: 404302040634382e303030
09:00:02 [46D3781E] HEX: 404f02010935303030342e303030
09:00:12 [46D3781E] HEX: 404a00010343504102040631332e3030300406033932350607033933390901022e31
09:00:17 [46D3781E] HEX: 405d000103504f53020505392e303030
09:00:32 [46D3781E] HEX: 404902040633342e303030
09:00:47 [46D3781E] HEX: 404602040634382e303030
09:01:02 [46D3781E] HEX: 404d0203073130332e303030
09:01:17 [46D3781E] HEX: 404302040631382e303030
09:01:32 [46D3781E] HEX: 404902040633332e303030
09:01:47 [46D3781E] HEX: 404002040634382e303030
09:02:02 [46D3781E] HEX: 404c0203073230332e303030
09:02:17 [46D3781E] HEX: 404002040631382e303030

the one sent at 09:00:12 (the moment I disconnected the power) says CPA wich probably stands for Cut Power Alarm. What is the best way to integrate the code to handle this?

Without documentation there is no way to know how to decode it.

I'm reverse engineering the protocol because I can't find documentation out there. It seems that the messages where the devices reports the alarm don't travel with device information, so it must be retrieved from a previous message.

Is it possible to store device information with the connection for this purpose?

These are the captured messages from my device, they show a common structure so I'm sure this is how the device reports power cut alarm. Each line represents a message captured in a different capture session.

404100010343504102040634322e303030
407400010343504102040633332e3030300900053233362e39
407c00010343504102040631332e3030300407023336060802393209010435332e34
400a000103435041020505362e303030

So what's the result of your reverse engineering? How to decode these messages? Handling messages without location or device info is not a problem here. The problem is that we don't know the format.

This is the format

• an @ symbol
• an arbitrary byte
• the three following bytes: 0x00, 0x01, 0x03
• the three characters CPA
• the byte 0x02
• five arbitrary bytes
• two 0s
• zero or more arbitrary bytes

So if the server receives a message with the previous form a Power Cut Alarm should be triggered.

Also, I received a message reporting the alarm in the usual place. Here is the code for such scenario: https://github.com/tananaev/traccar/pull/3663

Sorry, but that won't do it. I need to know full format.

that is how the alarm is reported to the server most of the time. How do you identify a full format?

Because it's a binary format the only way I can think of is by getting protocol documentation.

I wrote a couple of emails to the manufacturer and got this. Although it doesn't cover the individual messages sent by the device that start with an @ symbol.

I have much interest in having this working. If this works, traccar's support for pt502 will be much better because there are other kinds of data being sent in this same way.

I realized that in order to have this working I might have to deal with Pt502FrameDecoder. Do you have any advice? The smaller messages that I'm trying to process don't have a common delimitator at the end (for the already processed messages it's \n which is used to stop reading from the buffer).

I believe second byte is the length which you can use to separate frames.

mmm, I'm not sure, because some messages have different length and same second byte and vice-versa. But you were right, there are bytes for lenght:

@5f 000103 504f53 020505 362e303030 080003 302e30 090400

Ignoring the first two bytes (the @ symbol and whatever comes next) the format is a two bit code (that probably says the kind of information that follows) and the next byte says the length in bytes of the information.

Thus, in the previous sample message the first two blocks 0001 probably says what follows is a command, then the 03 says read three bytes and that's how we can find the word POS.

I wrote the code to manage that here. The only thing that I need is to understand how can I recover device information for this smaller frames so I can fire the PowerCut alarm.