I would like to use my Node-Red dashboard to control a Blynk IOT ESP32 that is connected through Bklynk.cloud.
I installed the blynk-iot Node-Red library and connected using the 3 required identifiers: Template ID, Template Name and Auth Token (same token associated with the ESP32 hardware).
I created a Node-Red dashboard that attempts to mimic my existing Blynk App in functionality and appearance.
However, where my old Blynk App widgets receive data changes in an event-driven manner, the node-red-contrib-blynk-iot requires polling with the “sync” node for data to flow in for display.
Additionally, when I change a virtual pin value, say pin V2 from 300 to 350 using a slider widget on the node-red dashboard, this change of value does not trigger the BLYNK_WRITE callback function to run on the ESP32. The value is changed on the blynk-cloud server and the value is propagated for display on both the APP and the dashboard interfaces, but the change event is not triggered on the device.
Project Setup
Microcontroller Device:
ESP32 DEV Module
Blynk 1.3.2 - Arduino lib with these Blynk #defines:
You can’t do that.
Node-Red needs to be a separate device in Blynk, and Blynk doesn’t allow two devices with the same Auth token to be connected at the same time.
Personally I think life is far harder when you run Blynk code on the ESP32. It’s a bit of a learning curve, but it’s better to run MQTT code on the ESP32 so that it talks to your Node-Red server, then use Node-Red as the rules engine to translate data coming from from and going to Blynk.
Also, I find if hard work using the Node-Red dashboard, especially if you want to try to mimic and synchronise with the Blynk app.
I guess it depends what you’re trying to achieve though.
My Home Automation systems have around 25-30 devices connected to Node-Red , but Blynk only sees one device - the Node-Red connection. Everything that happens behind Node-Red is hidden from Blynk, unless I want data from the devices to be sent to Blynk, or want Blynk to control one (or more) devices.
I used Blynk for a couple pretty large projects just to learn it. If I cannot use Node-Red to send events to Blynk devices, then I’ll probably covert them off of Blynk, as you suggest. I don’t see why Blynk managers wouldn’t want to provide an event channel to Node-Red, it would be a great strategic partnership despite some competing overlaps.
I will convert those projects to MQTT and Node-Red, I guess. I have lots of stuff in that setup now and I am digging Java Script and Node-Red coding.
I actually like Blynk on the device, with no work they are elevated out of the local network for global access and data streams are collected with no work as well. Remote code release will be great for commercial deployments.
Use of the term “events” in your posts is actually quite confusing from a Blynk point of view, as an Event has a specific meaning in Blynk. From what I understand of your requirements, “commands” would be a better term to use, and I’ll assume that’s what you mean by “events” in my comments below…
It is possible to send commands to Blynk devices via Node-Red, just not in the way you were trying to do it. As I said, adding the Auth token of an existing device into Node-Red isn’t the way to do it.
You can control Blynk devices from Node-Red without even having the Blynk IoT contrib installed - simply by using an API call. The details of how to do this are in this post…
(Note that this example is actually about logging an Event in Blynk, but the process can be used to upload values to a virtual datastream, or change widget properties, where those actions are supported via the HTTP(S) API).
The disadvantage to this is that you don’t get the BLYNK_WRITE(vPin) notificatiins in Node-Red when a virtual datastream value changes, so you have to poll the Blynk server looking for virtual datastream changes, which gets messy and isn’t as responsive as the alternative method.
Using my preferred method (one Blynk device in Node-Red along with the Blynk IoT contrib) still allows global access to all of your devices that talk to Node-Red via MQTT.
Using Blynk.Air for MQTT updates is the one thing you can’t do with my system, because Blynk isn’t aware of the devices that are being controlled by Blynk via Node-Red and MQTT. I use Arduino OTA still, but that requires access to a PC running on the same network as the devices.
However, in practice this isn’t really as big of an issue as you might think. I have two home automation setups using Blynk, Node-Red and MQTT, one in Spain and the other in the U.K. I have a method of doing OTA updates remotely using a mini computer that I can fire-up remotely (via Blynk of course) but I very rarely have to do this.
The reason is that the code running on my remote devices is quite simple - it simply connects to WiFi and MQTT and processes theMQTT commands it receives and sends the data that is required. After the initial development and testing, no maintenance is required unless additional functionality is required. All of the changes to how the system operated are made via the Node-Red flows, and that’s simple to do remotely (I use ZeroTier for that, but there are other alternatives available).
So, for me, the reason to use Blynk is the mobile and web user interfaces as a way to control and monitor devices. The 20+ devices in each of my home automation setups do things like control lights, air conditioning, heating, ventilation, blinds, door access etc, as well as monitoring outside weather, indoor temperature and humidity, solar power production and intruder alerts.
This is done via a single device as far as Blynk is concerned, which allows me to create a single UI with multiple tabs, and data/controls for multiple devices on a single screen.
That’s something you can’t achieve when using multiple Blynk devices,NAS there’s no method for combining data or controls for multiple devices on the same UI screen.
Personally, I have my doubts about commercial use of a Blynk/Node-Red/MQTT setup, simply because of the additional hardware/software required to achieve this. It certainly isn’t an end-user turnkey solution, but it does create a far more powerful solution, especially when you start integrating thing like Alexa and Zigbee/Matter devices into the equation via Node-Red.
I will call that asynchronous, event-driven programming ability a “command” to avoid confusion.
I understand that my node-red flows are unable to force a BLYNK_WRITE to occur on a Blynk device. This lack of “command” control totally blows and I consider it a bug. I realize I could use MQTT or a dozen other transports and protocols to gain this control, but those options are for other forums!
We both know that the node-red Blynk library could technically be written to allow for “command” behavior, like the Blynk app has. You cannot write this off as “it’s just not possible have multiple devices share one auth code” when we can have dozens of Blynk Apps share the same auth code and have shared “command” control to a single Blynk device. This “command” limitation is a design decision. I believe it is a poor design decision to only allow for Blynk Apps to have such tight “command” control over Blynk devices and not other clients or peers wanting “command” control through the same cloud as the apps use.
I get it: You don’t like to use Blynk on your many devices and you suggest that I should consider a similar abandonment! What I am pushing for here is to develop more powerful device capabilities and integrations. It seems that you have relegated Blynk to be a control panel when it has so much more capability and even more promise on the end-points. Just image when Blynk provides robust hooks to players like Node-Red, Alexa and HomeKit! Let’s make that happen instead of pulling the plug.
That’s not true. You can use the API as I out,Ines earlier.
It’s not a bug, it’s part of the basic design architecture of Blynk. Auth tokens are unique to a device, and you are using the same Auth token on your ESP32 device and your Node-Red device.
Both of these devices are attempting to create an always-on connection to the Blynk server using the same Auth token, and the server rejects that (it will actually be accepting the most recent connection attempt and disconnecting the earlier connection).
The HTTP(S) API doenst create an always-on connection, so isn’t a problem, and does allow the datastreams associated with your ESP32’s Auth token to be updated - provided you haven’t also used that Auth token in a Node-Red Blynk IoT contrib connection.
It can’t as outlined above, and the Blynk server doesn’t allow bultiple devices running the Blynk C++ library to share the same Auth token.
You can’t do this, it’s just not allowed - try it and see.
You seem to be very angry about me sharing years of experience of using Blynk and Node-Red alongside each other, and apparently feel that Blynk should change its basic precept of unique Auth tokens per device.
If you’re prepared to accept that Blynk isn’t going to change its underlying architecture, and that this isn’t a bug, then you’ll find that Blynk and Node-Red make a very good paring. You’re welcome to re-invent the wheel when it comes to the best way to use the two products together, I was simply trying to make that journey less painful for you, but as with all advice, it’s up to you whether you heed it or not.
FACTS:
(1) Blynk allows for many UI devices and one hardware device to be associated with a single auth token. So, many devices can share an auth token currently.
(2) This above group of devices (many UI’s and one piece of hardware) share a privileged ability that allows them all to receive “NEW DATA” signals from the cloud.
(3) The hardware device can leverage the NEW DATA signal using a callback function (BLYNK_WRITE) and the UI devices are able to receive data streams for its widgets without polling and tracking for changes.
(4) Blynk NR nodes can currently only be of the hardware device class.
DISCUSSION:
I would like to create a Node-Red dashboard that includes a single Blynk hardware participant. I would expect Blynk to allow NR nodes to participate as one of the many UI class devices and be able to publish data such that NEW DATA signals are created and received just like the other UI participants.
Can Blynk provide developers a “UI” optional tick box in the NR nodes that would allow interaction with the Blynk cloud as a “UI” class device? If the answer it “NO”, then is there a technical reason or does it break a product/pricing model? Or does this limitation provide some other functionality or benefit that I cannot see?
I would argue (with idealistic passion that your perceived as anger) that all Blynk devices, in both the UI and hardware classes, should be peers into the Blynk cloud rather than differentiated and limited as they are now. They should all be able to send/receive NEW DATA signals to allow for true event-driven programming everywhere in this ecosystem. Blynk “data group” associations should be granted just as arbitrarily as MQTT provides.
BTW- I scanned your document but so far only gleaned that you had connected NR to your end-points using MQTT. I would like to know the API that would trigger the BLYNK_WRITE callback on a micro-controller, if you could please present that information then I would certainly try the technique.
In your “Facts” section you refer to devices in a way which confuses Blynk users. In Blynk speak, a device is an MCU running the Blynk library and negotiating an always-on connection to the Blynk server using an Auth token as the security token.
The UI devices are Blynk dashboards, either with mobile hardware such as tablets of phones that run the Blynk app, or on a web dashboard via the web console.
The Blynk IoT contrib for Node-Red (which incidentally is not developed or maintained by Blynk) acts as a virtual MCU, not a Blynk dashboard.
The protocol used for communication between devices and the server is publicly available (by looking at the C++ library files) and this information, plus the data available by using B,ynk debug, has allowed the Node-Red contrib to be developed to emulate hardware devices within Node-Red.
The protocol used by the mobile app and web console to pull the dashboard configuration data from the Blynk server and display/update the widgets is not publicly available, so the only “UI devices” available are those created and managed by Blynk in the form of the app and web console.
I’m not speaking for Blynk here, but I’m 100 certain that this will never be made public.
Having Node-Red act as a Blynk dashboard isn’t feasible.
I’m not 100% sure what you’re saying here, I guess largely due to the language being used.
Blynk provides two methods of sending data to Blynk cloud…
via the app or web dashboards - toggling a widget switch for example
from a hardware device that has negotiated an authenticated (via Auth token) always-on connection to the Blynk server. This is normally done via the Blynk.virtualWrite() command
via the HTTP(S) API.
Data sent via routes 1 or 3 will trigger a corresponding BLYNK_WRITE() callback function on the hardware device (or trigger the Write node in Node_Red). Data sent from the device (route 2 above) doesn’t trigger the corresponding BLYNK_WRITE() callback as (a) it’s unnecessary and (b) it could cause a never ending loop to be triggered.
The section where I said this…
Shows how to call a Blynk API from within Node-Red. As I said earlier in our conversation, this was an example of how to log a Blynk Event.
It you want to do something different, such as write data to a Blynk virtual datastream and therefore have that data displayed on the Blynk dashboards and also trigger the BLYNK_WRITE() callback on the appropriate hardware device, then you simply substitute the API call with a different one.
In this case that would be the “Update Datastream Value” API…
More experimenting leads me to hypothesize that datastreams of String type will trigger and Integers will not trigger.
I can also see that the NR Blynk iot library will also trigger BLYNK_WRITE when they are String types! Great news. I guess I can just pack all my numbers through as Strings and cast the types on the MCU after they cause the trigger.
Something may be buggy in the cloud listener when it casts the incoming values to Integer. Perhaps it is filtering min/max values before catsing to Int? The bug allows the data to pass through but the BLYNK_WRITE is not called.
No error is returned to the browser in either case and the value is set properly in the cloud also in both cases. The only difference is the lack of callback trigger when datastream type is Int.
If I intentionally send a string to an Int datastream, I can provoke the error:
message “Value doesn’t match the Datastream data type”
However, sending number characters to either type of datastream does not produce an error. You may want to reproduce for yourself and share it with the cloud coder at this point (I assume you’re a Blynk staffer?)
I was on the free-meal plan which allowed for 12 datastreams. In my experimenting, I removed a datastream and now see that the free allotments have dropped to 5 datastreams and I cannot restore the missing stream without paying for more misery.
The platform structure is simply too volatile. It’s like building sandcastles between each tide. I’m done and ripping out Blynk from my house. It was fun using for the first years, though.
