Arriving where? Does the ‘where’ have logs you can see? Is there activity for the application in the console?
You only need a downlink API key if you want to trigger downlinks using a link embedded in the message.
Arriving where? Does the ‘where’ have logs you can see? Is there activity for the application in the console?
You only need a downlink API key if you want to trigger downlinks using a link embedded in the message.
Thanks,
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.
There was a period last week when WebHooks weren’t working. But I can see incoming data on two different web hosts.
As you can put in as many as you want, can you try the snippet above: Webhooks - Custom Webhook - #9 by descartes
Hi Nick,
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.
Hi Kersing,
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.
It’s in the reference section for uplinks …
https://www.thethingsindustries.com/docs/reference/data-formats/#uplink-messages
Thank you,
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!
Anyway, now we know. progress should be swift.
Once again thanks for all the help
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:
https://www.thethingsnetwork.org/conference/ttc-events/getting-started-with-webhooks/
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.