Problem solved! It was nothing to do with TTN but I’ll detail the fix for anyone else who may have this problem.
The domain where my endpoint lives can either be found at https://mydomain.com or https://www.mydomain.com. Using the former involves a hidden redirection to the latter. In the process of redirection the payload is shed and the web hook arrives at its destination empty. Adding the full url to my webhooks solved the problem and I am now swimming in data.
Hi Guys,
I am still rather confused here.
I am still not sure as to the setting for the http integration. they seem pretty basic as on v2.
my devices still on v2 are sending data to my end point no problem. the devices i have change to v3 are sending data to the v3 server, visible in the live data, which says its sending the data by my url, but i am not receiving any body data i,e the json data. So i must have something wrong with my v3 settings if you are saying it does work. Again if i set the device back to v2 i get my data as expected.
so what am i missing.
It may be a bugette in the v3 stack - I went back in to my v3 WebHooks, ensured all the check boxes were checked and clicked Save. It wasn’t very scientific but it suddenly resulted in incoming payloads. Worth a try. Let us know how you get on and I can try & setup some testing if no joy.
Hi Nick, I have made a slight modification to the debug code that you posted, to provide a prettier output and a useful crib sheet for further coding.
<?php
//print("Start");
$json = file_get_contents("php://input");
$data = json_decode($json, true);
ob_start(); //Start buffering
print_r($data); //print the result
$output = ob_get_contents(); //get the result from buffer
ob_end_clean(); //close buffer
// Save a raw copy of the message in a debug directory
// this will fill up quickly so don't leave it turned on
// Save a raw copy of the message in a debug directory
// this will fill up quickly so don't leave it turned on
$pathNFile = "debug/".date('Y-m-d H:i:s') .".txt";
file_put_contents($pathNFile, $output);
$fp=fopen($pathNFile,"a");
fwrite($fp,date('Y-m-d H:i:s'));
fclose($fp);
For those coming along at a later date, this will return a response to a browser or any HTTP client type utility or command line curl request as @dhmitchell provided above.
It will not provide any benefit for deployment to be accessed by a WebHook as you never get to see the response. The stack doesn’t and can’t really do anything with a response.
Right, so the Download API key does not need anything in it.
OK - I have a single application - configured on the v2 server running perfectly and has been for last 18 months. Using the http to send the device data to my server.
having ‘moved’ a number of the devices to the new v3 server, we can see the data arriving on the v3 server via the live data.
my server has logs and i can see data coming in from the v2 server now problem, i can also see the connection arriving from the v3 server but the body empty. i.e no JSON data.
Now i am sure it is probably a configuration issue, missing header or something, but the setting look the same to me on v3 as on v2 and if i move the device back to v2, it all works fine.
I have done some digging, as we are running webservices on a windows 2012 server, it would appear that the lack of json data arriving in the webservice controller, maybe due to the webservice is rejecting the body content rather than there not being any body content, i assume because of a missing header or error in the content-type header. I am now investing the headers and raw data and will let you know when i track it down. This may only be an issue with the Microsoft web services.
very early in this thread you said that the data format in v3 is different to v2. Is the data format documented anywhere. I can not see any reference to it in the V3 documentation. This format being different would explain why we are receiving the connection but failing to decode the JSON data. I am expecting a json data object with following attributes.
app_id , dev_id; hardware_serial , payload_raw ,
Take a look at the packet shown in the consoles application data, that is what I used to find the fields I want to extract. And the fields you list are definitely not where you get them in V2.
That is indeed the answer, I guess it may have helped if the notes on migrating from V2 to V3 had made it REALY clear that simply moving your device from v2 to V3 and setting up the webhook would not mean you should expect it to work!
Feel free to post an issue on the stack docs section on GitHub - that’s how things get better and the more I don’t have to post issues, the more time I have to answer questions.
Hi
Is it possible to send only my sensor payload thru Custom Webhook. Now on the endpoint I receive 99% of the data not relevant to my project.
Thanks.
Not at present but there are ways to help focus the content - either by only choosing the message types you want and/or putting fields in to the path to help discriminate between applications or devices quickly.
It does seem a bit verbose but it is the most efficient integration with the lowest impact on the servers - all the data that we see is pulled together anyway, so the AS can just send it without any processing. A bit of filtering of which messages, adding paths and substituting path variables isn’t a huge task in the heart of the compiled Go code.
I gather that a world renowned expert is doing a session at the mini-conference next Friday: