Blynk write event and Node-Red

I have a project with were I send my solar panel battery voltage to Virtual Pin Labeled Value, in Blynk, that works as expected. I would like to display that value with UI Node-Red gauge. I am using a blynk-ws-in- write event. The write event connects to the virtual pin but no data on the gauge. I am successful using a button in Blynk and displaying the output to a gauge. I have searched and read many related post and topics but no success. Maybe I am going about this the wrong way. Any help or direction on the subject would be appreciated.


This thing can be solved in two ways:

  1. via bridge: you have to use two different “auth token” one for the device and one for node-red.
    To use the “in-write” node in node-red you have to send a “virtualWrite” command via the “bridge” from the device, so the command goes directly to node-red and not to the blynk server see this doc

  2. via polling: you can use an “Inject” node with “repeat” option that every few seconds make a “syncVirtual” command, which automatically sends a “virtualWrite” to be read with a “in-write” node.

I’m pretty sure the write command is not really coming to node-red !!!
To see if the command actually arrives at node-red, open a log console and use the options in the node configuration

Let me know if you can solve it!


Thanks for information, I was able to solve it with a flow similiar to one posted by Pete Knight using a http request node to get the data from virtual pin and json to parse the data. Not sure if the json node is the correct one to use for parsing but it does work.
Thanks again

1 Like

Hi @PWK, glad you have a solution that works for you, and that I was able to help in some way (although I can’t remember suggesting this approach!).

Another solution would be to send your battery voltage directly to Node-Red as an MQTT message. With my projects, I don’t actually run any Blynk code on my ESP devices, just Wi-Fi and MQTT code - plus whatever is needed to work with the sensors, relays etc that are connected to them. If I want to see the data in Blynk then I send it to the Blynk server from Node-Red.
Any Blynk commands from the app go to Node-Red then are sent to the appropriate device as an MQTT message.


Hi PeteKnight,

Your solution sounds more logical but not sure how to run mqtt code along with my other code on my ESP devices. I do have mosquitto mqtt running on my RPI and Tasmota flashed mqtt Sonoff devices. I will have to research that method, thanks for the information I should have some time … because it will be minus 50F tonight with the wind chill factor.



This comment was very helpful for me solving a Blynk, Node-Red, ESP8266 problem. Could you elaborate on “auth token” for Node-Red? I understand about the “auth token” for hardware, which is generated by Blynk. I see no mechanism that would generate an “auth token” for Node-Red.

Hi arcs_n_sparks,
it is very simple, you can generate a token for any hardware it will be fine also for Node-Red.
For Blynk Node-red is a symple hardware, I usually use “Raspberry PI” or even “Wemos”, based on what you use in the blynk app you’ll have more or less pins available, but you don’t care because usually with node-red you use only the virtual pins.


Ah, I see. So you are generating more virtual pins in case you run out of virtual pins on an existing hardware target. Clever. Thanks!

I’m not sure that’s exactly what @gab.lau was explaining.
This question relates to an issue you raised in this topic:

so I’ll comment on both elements of the question on one go…

Here’s my fairly naive view of how it works - anyone with better knowledge please feel free to chip-in with corrections…

In this example, device 1 uses auth code 1234.
The device (or Node-Red) writes a new value to pin V1 for this device.
A change in the value of V1 via the app would normally trigger a BLYNK_WRITE(V1) event in the code running on device V1, but if this was allowed to happen when the device itself updates V1 it could cause a problem.
The code running on device 1 would have to go and process the BLYNK_WRITE(V1) event, and if you’ve written your code badly and called a Blynk.virtualWrite(V1) as a result the of the event being triggered, this could cause an infinite loop to be initiated, like this…

V1 changes -->
  BLYNK_WRITE(V1) triggered -->
    Code on device 1 does a Blynk.virtualWrite(V1) -->
     V1 changes -->
       BLYNK_WRITE(V1) triggered -->
[repeats for infinity.....]

So, I think that the way the Blynk server handles this is to say… “Okay, Device 1 just updated virtual pin 1 - it already knows about this, so we don’t need to fire BLYNK_WRITE(V1) to tell it about this change”

This means that in your case, discussed in the other topic, the switch widget in the app changes, but BLYNK_WRITE(V1) doesn’t fire in your code.

The way around this is to get a different device to update pin V1 of device 1.
If that different device (device 2), with a different auth code (lets say that is 5678), updates the the pin via Bridge, the Blynk server will think “oh-oh - somebody else just updated the value of V1 for device 1, we’d better let device 1 know”, so it fires BLYNK_WRITE(V1)

What the example in Node-Red is doing is to in-effect create a dummy device 2 that uses auth code 5678 and use this (via bridge) to update pin V1 on device 1.

That dummy device isn’t really used for anything else in your example (although it could be), it’s just a means of having a different device update a virtual pin on device V1, so that BLYNK_WRITE(V1) fires in your code.

Having read this through several times I’m not sure it’s explained in the best possible way, but hopefully you’ll get the general picture :wink:

As I’ve said, this is my speculation about how the whole process works, based on my observations, and may not be in the least bit accurate!
I really hope I’m right though, as I’d love to think that the server says things like “oh-oh - somebody else just updated the value of V1…” to itself :grinning::grinning: