Blynk write event and Node-Red

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:

Pete.