I had a look at the codebase, in order to achieve this result, I should alter the code as following:
1- in CommandsManager.java assume device is always offline, so command goes to the device queue.
2- in BaseHttpProtocolDecoder.java fetch the queued command with a code similar to the one in the sendQueuedCommands
function, and store it into a buffer called payload.
3- if there is a queued command, create a new object DefaultFullHttpResponse(HttpVersion.HTTP_1_1, status, payload)
where payload is the buffer, otherwise create standard object DefaultFullHttpResponse(HttpVersion.HTTP_1_1, status)
4- get command length and pass the appropriate value to the CONTENT_LENGTH header
5- add CONTENT_TYPE header
6- send the response
No one has a clue about this?
Cheers,
Nick
@Anton do you think this approach is feasible? I can attempt to write code, although I don't have Java experience.
Hi to all, anyone has feedback on this?
The ability to send data to the device on the same connection used to send position data back to Traccar would enable huge power savings, as it would stay in sleep mode instead of waiting for TCP transmission.
Hi to all,
I understand device commands are queued if device is offline, and when online it is sent through TCP connection or through SMS gateway.
I'm working on a device with limited memory and battery life, I'd like to know if there is a third way of sending commands, that would work in this way: the command is sent to the device in the response header when the device establishes the HTTP connection to the server to send the position. Currently the server replies only with a HTTP 200 OK.
In this way I don't have to leave the device awake and with an open TCP connection in order to receive commands, but it can go to sleep and get commands with a single TCP connection when it awakens to send the current position.
Thanks
Nick