Looking for Blynk 2.0 and Node-Red simple example

New user here. Is there a simple tutorial showing how to get my data from Blynk into Node-Red and show the data on a Node-Red dashboard?

My ESP32 is connected to Blynk and I can see my data in my Blynk dashboard. I would now like to go one step further and show the data on a Node-Red dashboard (or even simply show the data in the debug window so I know it is coming across)

I have installed the blynk-IOT v0.2.0 nodes and have configured the “write event” node, and it says it is connected to my virtual pin at Blynk. But when I then connect that node to the debug node, no data comes across. I must be missing something simple, but cannot find what it is…

I am pretty sure my debug node is working correctly because I can use the Inject node connected to the debug node, and I do get the msg to show in the debug window.

Node-Red v1.2.9

dmwengineering

I don’t know of any simple tutorial but I also use Blynk, MQTT, and Node-Red dashboard. Here is a screenshot of a basic flow from Node-Red. What type of data are you sending?

Paul

For my immediate test, I am simply sending a random number between 0 and 10, once every second.

dmw

It may not help but you could try updating Node-Red I am at 2.0.6

Paul

How are you triggering the virtual pin?
If you do that from Node-Red, with a Write node then it won’t trigger a Write Event.
You should do it from an app on the Blynk console or App.

Personally, I don’t run Blynk code on my devices, I use MQTT to communicate between the device and Node-Red, and use the Node-Red Write Event and Write notes to send data to and and from the Blynk server/app

Pete.

Did you configure the blynk node?
Have you already restarted the flow?

@PeteKnight, I probably have a misunderstanding of how the virtual pins and the data movement works.

My esp32 does a write to V2, which then shows up correctly on the blynk dashboard. I assumed using the blynk-IOT node “write event” and connecting it to V2 that it would automatically collect the data from V2 at blynk and bring it into Node-Red. Are saying I am missing a step by not “triggering” the virtual pin in another way?

@bazzio, Yes to both questions.

Yes. The Write Event node will trigger whenever a BLYNK_WRITE() would trigger in the sketch. Writing to a virtual pin from a device won’t do that.

You can trigger a Sync node in Node-Red to cause the server to send the current virtual pin value, which will trigger the Write Event node.

Pete.

Thank you Pete!

Got it working, and I now better understand the flow of things…

Great,
Not sure if you’ve seen this topic…

It was written in the Legacy days, but very little has changed.

Pete.

I will check it out…

Hi PeteKnight, I follwoed your other tutorials ti transition from some extensive blynk legacy projects to Blank 2.0 + MQTT + Node Red.

May I know how you make sure that after a crash or re-start of the ESP you get the last values saved in the Blynk cloud to your variables on ESP? (communicated via MQTT of course).

On legacy app I was simply using SyncAll function on the ESP platform, now this is not possible anymore as I am not running any blynk code anymore on the ESP. Of course I could trigger this somehow via NodeRed, but the timing and instance of this sync is important and this should be controlled from hardware/ESP if I am not mistaken. Would appreciate your answer here.

I have seen this answer here, but the timing of the sync event is usually important. How does Node Red know when to trigger this sync event? I could of course periodicall call it, but this is not necessarily a clean implementation.

"Yes. The Write Event node will trigger whenever a BLYNK_WRITE() would trigger in the sketch. Writing to a virtual pin from a device won’t do that.

You can trigger a Sync node in Node-Red to cause the server to send the current virtual pin value, which will trigger the Write Event node.

Pete.
"

It depends on the scenario you are talking about.
Do you have an example that you can describe where you need your ESP to get the latest Blynk server value on startup?

As far as I’m concerned, here are really two different possible situations that need different approaches…

  1. ESP goes offline then back online again, and you want to sync the latest Blynk server value

  2. Node-Red goes offline then back online again and you want to sync the latest Blynk server value

In situation (1) you might have a command like an on/off status and you want to set a relay that tye ESP device is controlling to the correct status. In this case, the on/off message would have been sent from Node-Red to the ESP device via MQTT.
If the message was sent with the “Retain” flag set to true then that MQTT message value will be retained on your MQTT server.

image

When you reboot your ESP device it wil connect to the MQTT server and when it subscribes to the topic which relates to this on/off message it will automatically be sent the latest value, and your device will respond to that and set your relay to the correct state.

In Scenario (2) you’ll want to know what the current widget state that controls this relay is set to, as it could have changed while your Node-Red server was offline.
You can use the Sync/SyncAll node in the Blynk IoT contrib to fetch this from the Blynk server, and you can trigger that with an Inject node set to trigger at startup after x seconds.

image

If you use the SyncAll option (which I don’t recommend) then you have to be careful that your datastream is set-up to respond to this request, by checking the “Sync with latest server value every time device connects to the cloud" option in the Datastream Advanced settings for each virtual datastream you wish to sync.

Pete.

Hi PeteKnight.
The retain option is definetly addressing almost all cases I could think of, indeed.
I will start deploying and do some testing. Very accurate and great response. Thanks a lot!
Let’s see how long this implementation takes.

By the way, have you meanwhile come along any better option than using blynk? Such as Node Red with Dashboard on local machine + same Node Red on a cloud based VPS for example? I was thinking of bridging the values via Mosquitto or NodeRed from local Mosquitto MQTT to a cloud based MQTT and this way be able to use NodeRed Dashboard and avoid blynk. Just an idea…

No, that’s why I’m still here on the Blynk forum, advocating using MQTT as the transport method, Node-Red as the logic/rules engine and Blynk as the UI.

I started-off with MQTT and Node-Red, and dabbled with the Node-Red dashboard - and hated it. Searching for a better UI bought me to Blynk, and I’m still here over 6 years later.
I did initially try to mirror my Blynk dashboards into Node-Red dashboard, but it made my flows too complicated and I never used the Node-Red dashboard anyway.

Also, I don’t normally store any data on my Node-Red server. I use Blynk’s cloud server to store my historical data to be displayed in Superchart etc. Although I do have a SQL database that I store some specific data in, but most of the time I prefer to let Blynk handle that for me.

I don’t understand the architecture of a local plus VPS cloud based mirror. Why wouldn’t you just run one local Node-Red instance and make it accessible outside of your network.

Pete.

1 Like

Making Node Red accessible from outside my network—> no problem
Making NodeRed Dashboard accessible, full different story. No luck for me.

I am following your suggestion and actually do like it. If Blynk decides one day to deploy 3.0 and I need again to change all my projects, it will be a nightmare though. haha
Let’s see how I will progress. I have more than 20 relays and 20 sensors that all work together including timers etc. Let’s see.
Also I was heavily depending on webhooks and some thingspeak rest API functions. Let’s hope I will be able to replicate those without any issues, from what I saw so far webhooks are not as widely supported on 2.0 as on 1.0.
Do you have any clue how I cann access the content of my 1.0 apps? I cannot see anymore what is saved in the webhooks as all servers are shut down and the apps only load in offline mode…

Cheers

It’s probably 5 years since I dropped that way of working, but it does work.

You’d be surprised. If your logic and rules-engine is in Node-Red then changing to a different UI is actually very easy.

If you’re using webhooks in Blynk then you’re taking the wrong approach. You should be calling the webhook in Node-Red and processing the data there, then passing it to either Blynk or your device in the format that it’s expecting. The same with Thingspeak. There’s at least one Thingspeak contrib for Node-Red and you should be using that or a Node-Red webhook.

No, the servers are decommissioned, so the data is gone I’m afraid.

Pete.

Again, your answers are spot-on.
Fully agree, once my logic in implemented and all my virtual write and read functions from legacy 1.0 are converted to mqtt protocol, hence topic subscribe and post, I guess I will be way more flexible than I was before and get all other benefits such as Alexa integrations etc. (although I do not need them for now). This keeps me very excited though as this additional flexibility will pay off in the end I think.

Your answer in relation to webhooks, I fully agree. I actually already implemented part of the webhook nodered thingspeak nodes, you are fully right here.

Another question:
I also had used the bridge function with blynk legacy. What do you suggest here? As I was sending arrays of integers, I would like to replicate this as much as possible. Would you suggest to use:

A:
ESP NOW to communicate between ESP clients (ESP-B send data to ESP-A via ESP NOW) and local MQTT to communicate between Node Red on a RSP-PI as broker and ESP-A as client?

B:
Or alternatively ESP-A to ESP-B via MQTT broker via MQTT protocol? Can you actually send array of data? Double/floats etc?

Many questions but very relevant in my eyes…

Approach B, or a variation on it, is the way to go.

You can build a collection of data, either delimited or as JSON, but I wouldn’t bother.
You’ll probably find it easier to send each piece of data as a separate MQTT message to its own topic.

Once again, I’d really need to see an example to fully understand, but separate MQTT messages would be my preference.

Pete.