Attempting to use particle.io webhook to send tracking data to traccar
Well I was able to work around the issue by using a raw tcp connection where I could control the closing of the connection manually -- holding the connection open for a little as 150ms after receiving the response allows the data to be decoded. Unfortunately this means that particle.io webooks cannot be used because they close the connection immediately after receiving the response.
I think this is anomalous behavior since the server has already sent the HTTP/1.1 200 OK message indicating success on the operation. If it isn't able to handle the message it should not send a success response I think.
I'm not an expert in this situation, but maybe two things I noticed could guide you to solve the issue.
This is what I get using traccar client
POST /?id=663423×tamp=1552093991&lat=25.6701811&lon=-100.2449368&speed=0.0&bearing=0.0&altitude=0.0&accuracy=98.4000015258789&batt=48.0 HTTP/1.1
Content-Type: application/x-www-form-urlencoded
User-Agent: Dalvik/2.1.0 (Linux; U; Android 8.1.0; Moto G (5) Build/OPPS28.85-13-4)
Host: sub.domain.tld:5055
Connection: Keep-Alive
Accept-Encoding: gzip
Content-Length: 0And this is what your message states is receiving
POST /?id=77326&lat=33.064682&lon=-97.003609&accuracy=11.047&altitude=125.691002×tamp=2019-03-09T03:15:40Z HTTP/1.1
Content-Length: 13
host: magnoliamanor-traccar.ddns.net:5055
Connection: close
1552102059621I noted two things:
1- Your timestamp in the string is in ISO Format, when in my example is unix format.
2- I see a timestamp after Connection header and a line break.
Could this be also a problem?
are you missing any headers?
Hope this helps.
Yes the ISO format string is now supported in Traccar, but I tried both formats just to be sure -- no effect.
The timestamp in the HTTP body is just an artifact of how the Node-Red flow triggered the HTTP request, the msg.payload field in Node-Red held a timestamp from the Inject node so the Http Request node places it in the request body. I took it out and tested too and it made no difference.
What finally fixed it was holding the connection open for about 150ms after the HTTP 200 reply was received. I think that is a bug, but I've seen that behavior in a lot of IoT systems -- the standard allows the HTTP client to close the connection immediately after sending its payload, it doesn't even have to wait for a reply but many systems seem to not handle that correctly.
It looks like this is behavior in netty -- I don't know whether the traccar team can do anything other than perhaps not send the HTTP 200 message until the incoming payload is processed.
https://github.com/netty/netty/issues/7285
I am attempting to use a particle.io electron with the particle asset tracker to send position information to my traccar server. The traccar server is working fine with the traccar android client, but I cannot get data transmitted via particle webhooks to decode properly.
I have tried sending position information via the following:
I send the following HTTP POST :
Particle and Node-red both substitute the parameters producing a valid osmand URL request as far as I can see:
With logging turned up fully I see the following when the message is not decoded (cases 2-4 above):
I am running java version 11.0.1 on a Ubuntu server hosted in the cloud.
Startup logging info here for traccar version information:
Any thoughts on what I can do to make this work -- I'm guessing I need to somehow force the connection to stay open longer? I'm a bit surprised by that but I guess its because the osmand protocal is not really a web server perhaps? (totally guessing about this).
Thanks!
Mitch