Second Traccar platform driven from same GPS
You can use OsmAnd protocol to forward the data, but it's not possible to forward data in the original format.
The Osmand protocol is the key. With it I have worked out how to run a second (slave) Traccar platform from the same GPS device.
The single tracker device now appears simultaneously on each the two separate Traccar platform instances.
The following entries in the traccar.xml config file (of the Primary Traccar instance) are required to transmit a copy of received messages to the secondary Traccar instance.
<!-- transmit in Osmand protocol -->
<entry key='forward.enable'>true</entry>
<entry key='forward.json'>false</entry>
<entry key='forward.url'>http://<SECONDARY_URL>:5055/?id={uniqueId}&timestamp={fixTime}&lat={latitude}&lon={longitude}&speed={speed}&gprmc={gprmc}</entry>It is a close approximation of the Osmand protocol format. It can be improved on.
The <SECONDARY_URL> is the destination: the second instance of a Traccar platform. 5055 is the standard port.
Devices are added to the secondary platform in the usual way, replicating the Identifier.
Multiple protocols received on respective ports on the Primary are translated into a single psuedo-Osman format and sent to a single port 5055 on the Secondary.
The gprmc={gprmc} part is probably unnecessary. It's basically location data that you already have.
&gprmc={gprmc} can be removed from the querystring
What is the benefit of showing a device on a secondary Traccar server ?
Seeing the device displayed is the easiest way to quickly confirm meaningful data is being received.
Isnt that already the purpose of the main traccar server ?
You can't check data is received at a secondary server by looking at the main server.
edit: Ah I think I realise what you're asking. A secondary system. In the same way as DNS servers are doubled / dual-circuit brakes on cars, RAID disks on computers, prime and redundant control surface cabling on airframes, etc etc :-_
I understand professional/mil grade GPS tracker devices are capable of registering with more than one server , making this unneccesary
Can you tell me what the main traccar server cant do, what the secondary can ?
I dont get the purpose of the idear.. On the main server you can already see all incoming data on the map, logfile, etc and see the device on the map.
Why would you need to see that on a secondary traccar server ?
I think our posts had crossed.
This hack is about as close as can get to simultaneous parallel server registration using simple GPS devices which can only support one connection. Of course any failure with the primary server will be in common mode, but at least the secondary instance will remain accessible with previous data.
"edit: Ah I think I realise what you're asking. A secondary system. In the same way as DNS servers are doubled / dual-circuit brakes on cars, RAID disks on computers, prime and redundant control surface cabling on airframes, etc etc :-_
I understand professional/mil grade GPS tracker devices are capable of registering with more than one server , making this unneccesary"
I see the logic of redundant connection. For instance in a datacenter you can have two different internet cables going to your switch. In case one internet connection is dropped it will automaticly switch to the other. Thus it is redundant. The same for servers which have double powersupplys and even extra ups.
But in your case when your main server stops working, it wont be sending data to the secondary server either.
Ah yes, for history data i could understand that.. doesnt seem the most logic thing to do though.
In 'mission critical' reliablity level everything would be completely duplicated including a separate GPS device, but there's all kinds of compromises that re-use some part of the chain or other and they each deliver different levels of redundancy.
This one may be useful for people using Cloud computing who are concerned about losing access to their historical data. They have another backup and ready to switch to at any moment. They do say regarding preserving digitized recordings it's best to copy the data to another place and preferably to different media formats.
I imagine this scheme would also be useful for anyone moving to a different server who cannot afford any downtime interruption in service. The new service (running as a secondary instance) can be almost fully tested using forwarded data. When the moment of switch over arrives it's just a case of migrating the GPS devices over to the secondary, which then becomes the main server.
Yes correct, and for you it might be the best way to go.
For my purpose (to have a backup system) I think it would be easier and better to make a copy of the traccar install and database.
And after that make a backup of the database on a regular basis.
In that case you will have the whole database ready to import on the secundary server (with all data like geofences and device details, groups etc etc).
Because i think you only get the position info when you use the OsmAnd protocol to send to the secundary server..
So i do not see how you could switch to the secundary server to become main server without the database from the main server which has your gps devices etc in its database..
The big differences is, that you do not need to have two servers running all the time. In case main server 1 goes down. start server 2 restore the backup database and you are up and running.
I have just starting using this scheme now and it's perfect. I am planning to retire a server that's currently running on a physical server and replace it with a cloud VM in another country. The two systems are running simulataneously for evaluation and later a choice will be made whether to stay with the physical or move to cloud.
To have a backup ready to restore after a calamity with zero configuration, what some people do with Cloud is periodically create an entire VM machine image which clones everything like a 'restore point'. From this stored MI one can easily restore things as they were after a calamity with no configuration at all. Or one could just as easily and within the same Cloud account, create another VM as a mirror server and assign to it an external IP address of its own.
One can also create this "secondary live server" on the same Cloud account, but the disadvantage is if your whole cloud account breaks you're in trouble because you can't access the machine image, either server or its databases or anything.
This secondary server I'm describing is intended to be running in a different account/country/city and it carries on running if the primary server is lost (but of course minus the live data).
The disadvantage is the inherent protocol translation can act as a filter unless the 'query-string' is carefully loaded up to deliver everything needed. (Because the primary server receives and translates diverse realtime data sources into a common format, Osmand).
Apologies if this has already been answered before. I tried to find answer in the forum history but couldn't.
Can a Traccar server relay a copy of its received GPS messages to a secondary Traccar server, so that the GPS device appears on both?
I imagine it is through configuring
<entry key='forward.enable'>true</entry> <entry key='forward.url'>http://{URL}:{PORT}/?{QUERYSTRING}</entry> <entry key='forward.json'>false</entry>But the part I cannot understand is how can this emulate a GPS tracker.
Unless the Secondary server maybe has a 'Protocol' for taking this. ("relayed_message" protocol??)