I have had good success using HTTP: access to get and update Datastream values using the documented
/external/api/ commands. (Blynk API is much more powerful than the old Bridge Widget, thanks!) No problems with
char values as long as they contain no blanks.
How do I update external datastreams with
String values containing blanks?
Is there a JSON format with
I’m solved the embedded blanks problem in IFTTT using JSON POST commands to IFTTT, but cannot figure out how to use JSON with Blynk.
Spaces should probably be replaced with
%20 but you might be able to get away with quotation marks - you’d have to try.
Thanks Pete. I’ve tried quotation marks in the http text string. No such luck. It still breaks on the blank character.
So without a JSON alternative, your substitution-for-blanks notion may be the best way. Ugh.
Actually, it was a one-line edit using the String replace function:
stringvar.replace ( "fromSubString", "toSubString" ); Easy, thanks.
I am surprised a simple JSON Blynk API request is not supported. (IFTTT supports both, makes it easy, documents it well.)
Could you please provide an example of what you need? I’m not sure I understand the problem.
That’s defined by HTTP protocol. This is how it should work.
Thanks Dmitriy. When using HTTP GET requests to send data from one Blynk device to another using your API, it works wonderfully. Thanks. Much better than the old Bridge Widget.
However, when one device wants to send a character string with an embedded blank, like “Is this for you,” it does not work in the HTTP text string. The blank ends the HTTP request string, breaking the communication. I have to manually substitute %20 for the blanks in my code. .
I use simple JSON strings to communicate between IFTTT and my Blynk devices. Using JSON, every sent value is enclosed in quotation marks in the HTTP POST string, so embedded blanks in character strings work without translation. It Would Be Nice if we had similar capability with the Blynk API.
This is not urgent. My issue is resolved with the %20 workaround. However, JSON’s power in device-to-device data communications would be welcome. Thanks.