We provide a reference C++/Arduino implementation of the library. It is very extensible and modular, just look at the list of supported hardware. Adding new connection types and Arduino-compatible boards is easy.
But some devices are programmed in other languages and environments, like:
Vendor-specific SDK and IDE
This document hints how to write a custom library.
Blynk library main functions
Provide easy-to use API
Virtual pin handlers registration
Provide comfortable wrappers for some widgets
Should support different connection type/hardware, if applicable
Serialize/deserialize Blynk protocol
Should be portable across similar devices (or same technology/programming language), if possible
Should detect and notify the user about troubles where possible (especially Flood)
Handle direct pin operations [optional]
Adding new HW board to the Blynk mobile app
Different boards can be added by creating JSON board description file - look at the examples here. You can send us your own board description files for review and App integration.
There may be a problem that you want to start testing your implementation, but your board is not listed int the Blynk App. We have a "Generic Board" specially for such purposes. Or you can just select UNO board and check how it works using just virtual pins. Most digital pins should also work. Analog IO/PWM will not work in general, until we add your board to the App.
Blynk transfers binary messages with the following structure:
Command Message Id Length/Status Body
1 byte 2 bytes 2 bytes Variable
Message Id and Length are big endian. Body has a command-specific format.
Typical Blynk library knows how to send(S) and process(P):
S BLYNK_CMD_LOGIN + auth token
HARDWARE/BRIDGE command body
The body of these commands are encoded as a sequence of strings, separated by '\0' (Null character). Please note that the last value may be not Null-terminated.In the following command examples '\0' chars are replaced with spaces.
PinMode command is received by library after connection, or when a mobile application starts.
pm <pin> <mode>
pm <pin> <mode> <pin> <mode> <pin> <mode> ...
in - INPUT
out - OUTPUT
pu - INPUT_PULLUP
pd - INPUT_PULLDOWN
Digital pin operations
dw <pin> <val>
Analog pin operations
aw <pin> <val>
Virtual pin operations
vw <pin> <param0> <param1> <param2> <param3> ...
Values in HW commands are plain text.
In response to dr/ar command, library should send dw/aw command on the same pin and with the same message id.
These situations should cause a connection drop or reconnection attempt: Message with ID=0 is received, Message with unknown type is received
Use these to play with the protocol and understand the basics: