Publish data - webhook - dashboard...I surrender! [SOLVED]

Why am I not getting this simple process working:

  1. Argon read temperature and humidity
  2. Argon publish both data values, not just one.
  3. Webhook gets data and posts it to initial state
  4. Initialstate draw amazing graphs.

I have done my homework, spent days reading all the threads and tutorials but no luck. My knowledge in json and web related coding is limited but this seems like something people do with dataloggers all the time. Here’s what I have so far:

Argon code

char outgoing[50]; 
float temperature = 12.5;
float pressure = 1.4;

void setup() {}

void loop() {

sprintf(outgoing,"{\"key\": \"mytemp\", \"value\": \"%.1f\", \"epoch\": \"1419876021.778477\"}",temperature);
delay(50);
Particle.publish("testhook",outgoing , PUBLIC);
delay(20000);
}

Looks like this in Particle Console

image

Setting up the webhook is confusing. This is the point where I really need a hand. I have had some luck getting the connection to initialstate but always received a bad request error 400 complaining no events.

I think I´ll stop here though I have a lot of questions still.

Not sure about your data target, but the JSON doesn’t seem to fit the usual format.
Usually you’d use mytemp as the key designator on the left side of the colon and 12.5 on the right side as value. You wouldn’t separate the key and the value into two independent key/value pairs using key and value as the respective keys.

I’d construct your JSON like this

  snprintf(outgoing, sizeof(outgoing) 
          , "{\"temp\":\"%.1f\","
            " \"hum\":\"%.1f\","
            " \"epoch\":\"%d\"}"
          , temperature
          , humidity
          , Time.now()
          );

And in your webhook you would refer to {{temp}} and {{hum}} instead of {{{PARTICLE_EVENT_VALUE}}}

1 Like

Thank you @ScruffR for the reply!

I read the initialstate streaming API instructions and got my idea from there. Here's a couple screenshots incase the link doesn't work.

image
image

I suppose my biggest frustration has to do with the particle webhook creator. I can't seem to understand how and where the data in my code goes in the so called webhook. SO when you say ...

... I don't know what to do. Sorry! Your code suggestion replacing sprintf results in
image
so there seems to be an issue with Time.now() .

Sorry forgot the placeholder for the value :blush: (corrected above)

1 Like

Looks better now…
image
…but still doesn’t match the format suggested at initialstate:
image

And as I mentioned before: in particle console-integrations its the webhook builder fields I don’t know how to fill properly. I know I need to set initialstate url, bucket key and accesskey somewhere so the argon data gets sent to the right place. But there are so many alternatives and believe me I have tried them all :confused:

This is what I have now:

The docs for the API say this

The format I provided adheres to the UNIX epoch format with full seconds resolution. I don't think you'll get much better realtime resolution from the Argon.

I now see that this API actually expects you to split your key/value data into two key/value pairs (which is odd IMO).
However, in that case you can try this

  snprintf(outgoing, sizeof(outgoing) 
          , "[{\"key\":\"temp\", \"value\":\"%.1f\", \"epoch\":\"%d\"}"
            ",{\"key\":\"hum\" , \"value\":\"%.1f\", \"epoch\":\"%d\"}"
            "]"
          , temperature
          , Time.now()
          , humidity
          , Time.now()
          );

and stick with {{PARTICLE_EVENT_VALUE}} and use that with custom body format like this

Alternatively you could go with my original JSON and use that with URL encoded no-JSON events.

1 Like

Published data looks really good in console, thanks.
image

Had to edit...

char outgoing[200]; 

...though. I then changed request format to custom body and made the changes as suggested. I put the access and bucket keys first in the url field and then in the html header field. However it seems as if there is still no data being posted.

  1. Initialstate stream is empty (usually full of data)

  2. postbin (free online service) body empty as well.

I suppose it would be easy to test if somebody had a particle device hooked up, uploaded the code, made a webhook and tested it against postbin service.

Interested in this too. But first I feel we should make the json alternative work first, I mean I can't be the first one to struggle with this. BTW thanks so far for the help!

Might I add the response


I copied this…

[
0:{
"key":"temp"
"value":"12.5"
"epoch":"1582142338"
}
1:{
"key":"hum"
"value":"1.4"
"epoch":"1582142338"
}
]

…and tested it in jsonlint.com and got this

For the JSON validator try wrapping the entire string in a set of { ... }

1 Like

Not sure what you mean but this…

[{
	"key": "temp",
	"value": "12.5",
	"epoch": "1582142338"
}, {
	"key": "hum",
	"value": "1.4",
	"epoch": "1582142338"
}]

…works in the validator.

You should not try to validate the “PRETTY” version of the JSON string but “RAW”.
Then you will see the same JSON (without the line breaks and indentation) as the one that validates in your last post :wink:

I tested with requestbin and the data arrived as expected.
So I guess your issue either lies in the documentation of their expected format or the way how you provide the access creds.
But I cannot test that without creating an Initial State Streaming account.

1 Like

Oh man, sorry about that.

Well that's good news because then there's more hope getting the data to initialstate too. I´ll have to figure out why I don't get the data to postbin. I´ll get back soon.

I have now managed to target their mock-up server and got the job running
There were some minor adoptions to the JSON format and the webhook definition required

So this is how the JSON should be built

snprintf(outgoing, sizeof(outgoing) 
          , "[{\"key\":\"temp\", \"value\":\"%.1f\", \"epoch\":%d}"
            ",{\"key\":\"hum\" , \"value\":\"%.1f\", \"epoch\":%d}"
            "]"
          , temperature
          , Time.now()
          , humidity
          , Time.now()
          );

(epoch should not be wrapped in double quotes)

And here is the webhook definition


(tripple handlebars instead of double)

as copyable text
{
    "event": "test",
    "responseTopic": "",
    "url": "https://private-anon-083dcd9b5e-initialstateeventsapi.apiary-mock.com/api/events",
    "requestType": "POST",
    "noDefaults": true,
    "rejectUnauthorized": true,
    "headers": {
        "Content-Type": "application/json",
        "X-IS-AccessKey": "1234",
        "X-IS-BucketKey": "apiary_bucket",
        "accept-version": "~0"
    },
    "body": "{{{PARTICLE_EVENT_VALUE}}}"
}
1 Like

That’s it, thank you so much @ScruffR :clap:. A couple of ending thoughts.

  1. Postbin gave me this result…
    image
    …which has a novice like me thinking something is wrong whereas Requestbin gave me this
    image

  2. In Particle console pretty looks like this…
    image
    …whereas in Requestbin pretty looks like this…
    image
    …seems like too small a detail to even mention here but I think in a world where one character can fail everything its actually confusing.

  3. Yep, triple handlebars!

  4. I have enjoyed reading the forums of this community for about 2 years now but only 2 days ago I registered in the community and this was my first post. What a pleasure to be helped by the legendary @ScruffR. I really leared a lot!

1 Like

“Pretty” is not a standardised format :wink:
The console PRETTY view doesn’t profess to be the same as requestbin’s “PRETTY” version, but when you look at requestbin’s “STRUCTURED” representation you will find the similarities.

If you want to see the actual data you always should go for raw

BTW, postbin’s [object Object] result correctly indicated that there actually was some data but didn’t know or care how to unwrap it.

Hah, one day I might laugh at myself for thinking that, but right now, that's just the kind of thing I might spend hours trying to understand and read about. Anyway I'm just really glad it all worked out!

Ok, good to know!

1 Like

This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.