I still don’t think you grasp the underlying principal here.
You are, in effect, breaking one of the golden rules of Blynk by having tow "devices (Node-Red and your hardware device) using the same auth token.
Your hardware device doesn’t echo-back Blynk.virtualWrites to itself, and the Blynk server can’t know that the commend that came in from Node-Red didn’t come from the device itself - they are using the same auth token and connection method, so it cant distinguish between the two.
Once again, I’m not sure that you understand what I’m doing. I also love the Blynk platform and use it as my primary UI. It’s just that my devices talk to, and recieve their commands from Node-Red, which then acts as the “middleman” between them and Blynk.
When I press a button or move a slider on the app, the devices receive those commands immediately, but those messages are relayed via Node-Red.
That may seem like a cumbersome way to do things, and that it’s just adding an extra layer of hardware and complexity, but in reality it has many advantages (which I’ve covered elsewhere, so wont repeat here).
Things to look out for when doing it your way…
Device on/offline status
When Node-Red established a connection to the Blynk server, that device appears as “Online” to the server, even if the physical hardware device is offline.
For Blynk to know that the device is offline, both the physical device and the Node-Red configuration node for that device need to be offline.
Blynk.Air
I did some testing with this minimalistic Blynk.Air code:
The issues that I experienced in post#2 of that topic were in fact caused by me having a connection set-up to the same auth token in Node-Red. This was a test device and I wasn’t actively using the device in Node-Red, but the configuration node for that device was still enabled.
If you want to do a Blynk.Air update to a device then y6pou’ll need to take its Node-Red clone offline first.
Pete.