Webhooks, the console and Ubidots

[DRCO]

Hi @scruffr and @aguspg,
OK, started from scratch and created a simple version of my code based on @aguspg ‘s new example. I followed the guide on using the integrations manager – my hook, called “BINGO” looks like this

In the code provided by @aguspg he has a String variable called temp, I created one from my compiled incoming string called “staTstring”.
The relevant code is as follows:
Particle.publish(“BINGO”, staTstring, PRIVATE);
delay (5000);
When I load the code and look at the Particle console, I get constant
“error status 404 from things.ubidots.com” messages
which when expanded returns:
{“data”:“error status 404 from things.ubidots.com”,“ttl”:“60”,“published_at”:“2016-09-07T02:03:17.900Z”,“coreid”:“particle-internal”,“name”:“hook-error/BINGO/0”}
The Ubidots page does not create a new variable…
I do see BINGO being published, and the data attributed to it is correct from the sensor. The console looks like this…

OK, so now if I replace the basic code with @scruffr ‘s previously suggested code
char msg[64];
snprintf(msg, sizeof(msg), “{“STATIC_PRESSURE”:”%d"}", staTConvert);
Particle.publish(“BINGO”, msg, PRIVATE);

I get this error;
{“pressure”: [{“status_code”: 400, “errors”: {“value”:
which when expanded returns
{“data”:"{“pressure”: [{“status_code”: 400, “errors”: {“value”: ["’{“STATIC_PRESSURE”:“691”}’ value must be a float."]}}]}",“ttl”:“60”,“published_at”:“2016-09-07T02:10:59.840Z”,“coreid”:“particle-internal”,“name”:“hook-response/BINGO/0”}

HOWEVER – A new variable recognising my Photon IS created in Ubidots – but has no data. As the error message stated the value must be a float - I converted the staTConvert integer to a float - but same result.

Sorry for being longwinded – but really confused by this. Hope you guys have the patience to help.

[aguspg]

The first option should have worked, I would recommend to do the POST request manually first, to make sure it’s correct. For example, this is what I get when doing this curl command in my computer’s terminal:

curl -X POST -H "Content-Type: application/json" https://things.ubidots.com/api/v1.6/devices/1234567890/?token=MYTOKEN -d '{"PRESSURE":200}' 

Response:

{"pressure": [{"status_code": 201}]}

This creates a data source with label=1234567890.

On the other hand, I do know why the second option didn’t work though; your code is sending a body that looks like this:

{"pressure":{"STATIC_PRESSURE":"691"}}

It should be just {“pressure”:“691”}

[DRCO]

Thanks again @aguspg. OK, I’ll go over the first iteration - as you said, it should work. So I’ll strip it down to exactly your code and try that to start with. But in my project I have several sensors - if I’m understanding this right, the “pressure” you said is killing the code originally put forward by @ScruffR as follows:

{“pressure”:{“STATIC_PRESSURE”:“691”}}

is generated in the particle integrations console here:

Does that mean you could only have one descriptive for one data set? I should clarify that I tried the code without the PRESSURE included in the console and the error it generated said that a field was missing.

My actual code using @ScruffR 's code has 3 sensors - and looks like this:

char msg[64];

snprintf(msg, sizeof(msg), “{“NODE_2”:”%d", “NODE_3”:"%d", “NODE_4”:"%d"}", InConvert2, InConvert3D, InConvert4);
Particle.publish(“BINGO”, msg, PRIVATE);

It is working - but as mentioned there are a ton of parse errors and timeouts. If I expand to many (10 or more) sensors, I think something will break.

If the answer is - go and do some homework, I’m fine with that - you’ve been generous with your time and I’m pretty new at this. But if I need to find another way to broadcast to Ubidots (my preferred API) - I need to get this sorted from the start.

[ScruffR]

If you want to send a custom JSON string, you might want to change the type from Form to JSON in the Advanced Settings.

[DRCO]

Yes, that is what I’m using now - and was using in the first place. With your “best case” code - it works and is pretty reliable - but generates a lot of the error codes I mentioned first up.

[ScruffR]

Just out of interest, what’s the reason for using a webhook rather than the Ubidots library?
I’ve no comparison about data consumption, but I’d assume that the library pack the data tighter than a general purpose webhook.

[DRCO]

I have commissioned this product previously as a webhook, it is for a commercial trial and it is just a lot easier to manage - even when I was using the CLI and a .json file. I guess it’s an established practice,really. I’m not keen on re-writing the code but I guess it’s not a show-stopper.

Being able to monitor it with the console is also a bonus

[aguspg]

@DRCO using the custom JSON is the right way. If you look at ubidots’ endpoint it supports multiple variables in a single body, so if you send such data it should work (again, I recommend testing the request manually first)

{"NODE_2": 123, "NODE_3": 123, "NODE_4": 123}

or

{"NODE_2": "123", "NODE_3": "123", "NODE_4": "123"}

[DRCO]

Just a note to thank everyone who offered their time and expertise. In the final washup, I was unable to get a “clean” version of the Ubidots /webhook going. @ScruffR 's JSON version did operate well, and pretty reliably but threw up a lot of parse and the occasional “too many” errors on the Particle console. For now, I’ve taken his other advice and looked at modifying my code to accommodate the Ubidots library. Gotta say, no comparison in performance - using the standard library version without a webhook was much faster and reliable, with almost instantaneous updates on the Ubidots dashboard.

I will revisit the webhook integration, but too pressed for time right now - if I get a result I will publish it on the forum.

[Viscacha]

This is old I know but I was confusing myself with this over the weekend and came across this thread. It is worth reading the Ubidots webhook format carefully. If you accidentally have variables that are strings for instance that will upset it and you get back the Status Code 400 message. So if what you are sending is not a number it would appear you can only send it as “context”.
In my case I had a version number in the form 1.23a I had forgotten about as I was recycling the code from my Azure experimenting. For whatever reason rather than simply blocking that one variable from updating this stops the webhook call.

[DRCO]

Hi @Viscacha, I gave up on the webhook, as it really only added another layer of unnecessary complexity to my requirement - and instead used the direct ubidots library code to tx. That said, my attempt did only include integers or separate strings. I created a separate particle event so I could monitor on the console.I have to say, Have moved on so no time to go back and test this.

[Viscacha]

That’s fair enough but it does require you to be happy with unencrypted communication between your device and Ubidots.