We are using Blynk to connect our devices using MQTT. Our firmware doe snot contain the Blynk library, we are managing sending and receiving of messages through MQTT topics ourselves.
The version of our firmware is determined by the git hash of the commit, so it is a 8 character hexadecimal string, and we publish that version through the info/mcu topic.
We want to publish new versions of the firmware using Blynk.Air, implementing receiving messages on the downlink/ota/json topic.
The documentation states that the payload on this topic will contain type, ver and build if Blynk.Cloud can extract this information from the uploaded OTA package file.
As we do not use the Blynk library, we cannot use the BLYNK_* defines to include this information in our binary. I assume that the Blynk library include this information in a recognizable form in the binary.
Is there another way to include this information in the binary so that Blynk.Cloud will recognize this info and include it in the json payload?
I don’t think that typing a #define somewhere in code without using it anywhere will result in anything in the binary. As I said, we are not using the Blynk library.
I assume that the Blynk library will use this define to include those version bytes in a fixed position, or on some other identifyable place in the binary. I would like to know how this is done, so I can use the same method in our binaries.
I would like to know how the version is parsed from the uploaded firmware, so I can prepare our binaries and make that parsing it will result in our githash versionstring.
In C/C++ just definining a macro with #define does not create any code or bytes in the binary. The macro has to be used somewhere. That is why I’m asking how the Blynk.libary is using the defines to include that data into the binary.
My limited understanding is that the Blynk library simply passes the version number to the server on startup, so you can see in the web console what software version your device is running. When using MQTT you’re passing this info yourself anyway.
Your challenge is to put the version number into the binary file so that it can be parsed by Blynk.Air.
I assume that the same challenge exists with BLYNK_TEMPLATE_ID and possibly BLYNK_TEMPLATE_NAME, because (as far as I’m aware) Blynk.Air checks that the template name is correct in the binary before allowing the OTA upload…
Ok.
When the firmware is uploaded for shipping with Blynk.Air,
does the interface check if the templateId is defined and the same as the devices I wanna deploy it to? Are there maybe any other checks done in Blynk.Air?
Yes. This is the main check during OTA. Also, on the business plan, it’s allowed to skip this check (for the emergency cases, when for example, wrong firmware was uploaded to the hardware).
Yes. The other checks depend on your Shipment setup. Like time of the day, and what field to compare (firmware version, blynk friware version, build date, etc)
Or from the device firmware (if the device uses blynk firmware - blynk firmware sends this info on the initial device login).
Blynk library version: Where does it get this?
It’s taken from blynk firmware (you can search by BLYNK_VERSION).
Yes.
It comes from the blynk firmware. It’s hardcoded there. This is the same value you should see as “Board type”.
Firmware type: “MCU” What does this mean?
Blynk currently has 2 types of firmware: MCU and NCP. The difference is explained here - Blynk.NCP overview | Blynk Documentation. To put it simple - if your hardware has 1 core - it’s MCU type (blynk firmware runs on the single core available, doing networking + app logic). If your hardware has multiple cores it may be a NCP type (meaning blynk firmware runs only on 1 core doing all the networking, while app logic is run on another core doing business logic).
