This works, however I’d like to still send my coreid (Device ID) through. I realise I could do this by setting noDefaults to false, however this seems a bit inefficient as then the webhook is sent with two versions of the voltage and power data. Is there any way I can include the coreid without sending the default data? @ScruffR?
And I’ve also read, that for one member adding a blank after the opening and before the closing curly braces made a difference.
The next thing was the “need” to have your values wrapped in double quotes in your outgoing JSON.
But just recently there was a possible workaround mentioned by @jvanier to use body instead of json to allow for non-double-quoted values.
I’m not sure if you want to do it that way, but you can always add the device ID to the JSON.
I should have mentioned also, I’m trying to avoid sending the deviceID as part of the dataString to save data (using an electron) thought that since the deviceID was available as part of the webhook response I shouldn’t have to.
My bad, I misunderstood your actual question, hence what I said doesn't apply to your use case, since you said (and I missed at first), that this setup already works as is.
But other users had problems with their target server expecting a JSON template that provides numeric values in the key-value-pair without the double-quotes (which seems no issue for your target).
And hence a workaround like this would be a solution
But for the device ID, I'd have to refer you to @Dave
Also about this, since I can't really see the reason for that
Since this was an “unreflected” quote from a post by @jvanier, I’d have to leave it to him (or @Dave) to jump in.
Julien seemed to be successful with that workaround.
What do you get with that template?
It shouldn’t matter, but how about changing Post to POST and Data to data?
I’m reworking the webhook docs to add more advanced examples.
The short version is that right now using the “json” key in the webhook config only allows string values. There’s a workaround to send integers or booleans using the “body” key that I’m documenting. I should post those docs by the end of today.
Thanks @harrisonhjones, I realise the device ID is a string, that’s ok. Since I’m using API Gateway and a simple mapping template to wrap the dynamoDB API there isn’t any smarts in the middle to do the conversion. Perhaps I could store the data as a string and deal with it later but I thought if I could find a solution to this it would be good
Create the webhook with the CLI particle webhook create hook.json
Publish a test event from the command line (this is to make it easy to reproduce. Normally you’d publish from your firmware) particle publish testevent '{"VGE":10,"PWR":20}' --private
I’m creating the webhook through the console as I’m testing on a product (which I think also means particle publish testevent… won’t work for me either)
Copying your code in however (and just changing eventName and url) doesn’t seem to send the correct Content-Type:
I wonder if this is an anomaly from product webhooks being in ‘beta’
Perhaps I should just use a lambda function instead of template mapping and parse the data on input…
Ok so it’s not a problem with product webhooks but a difference in behavior when creating the webhook via CLI vs console. I tried creating a non-product webhook via console and still had the same problem. I then followed your process @jvanier by creating it manually via CLI and observed the desired output as you did. Can anyone else replicate this?
Thanks for clarifying that this is for a product webhook created on the console. I see the issue. At the moment it’s not possible to create a webhook with a custom “body” parameter through the console. I’ll bring this up internally.
As a workaround for the CLI not creating product webhooks at the moment, I created this simple script. I haven’t tested it with the body workaround, but since it just passes up the JSON unmodified, I think it should work.