That’s the normal behaviour.
A Blynk.virtualWrite(vPin,value) command in a C++ sketch doesn’t trigger the corresponding BLYNK_WRITE(vPin) callback function to trigger, and it’s the same when using Node-Red.
In C++, if you wanted the BLYNK_WRITE(vPin) callback to trigger you’d need to use a Blynk.suncVirtual(vPin) command top get the server to send the latest value for the vPin, triggering the BLYNK_WRITE(vPin) callback, and it’s the same with Node-Red.
In Node-Red you could do this…
Which is the C++ version of
Blynk.write(V0,1);
Delay(100);
Blynk.syncVirtual(V0)
In C++ this will cause the server to send-back the value you’ve just written to V0, triggering BLYNK_WRITE(V0)
However, that’s approaching the problem in the wrong way in my opinion.
I don’t run any Blynk code on my devices. My device code connects to WiFi and to the MQTT server. It then subscribes to a series of MQTT topics, and publishes data to a number of other topics.
The subscriptions are a bit like BLYNK_WRITE(vPin) callbacks. They are triggered when data is written to those topics, and the value(s) written to those topics are extracted, in a similar way to using param.asInt(), and you then take the appropriate actions (such as turning on a relay) depending on what value was sent.
I guess that should be MQTT.fx ?
My preferred MQTT tool is MQTT Explorer…
it makes viewing and publishing test values to topics much easier than MQTT.fx
This is the sort of information that I publish via MQTT regarding each device…
The RSSI, Free RAM, and Uptime is update around every 5 seconds and the rest of the data is either published at boot time with the MQTT Retain flag set, or updated when it changes.
There’s more info my approach here…
Pete.