I am trying to write a value from node red to my device:
I see the value coming in on the web dashboard but not on the device.
(When I change the value on the web dashboard it is sent to the device)
Also the sync does not write anything to the device…
Am I misunderstanding the functionality or doing something wrong?
I assume that you have the same Auth token in your Node-Red connection as you are using on your device?
If so, this is standard behaviour for Blynk and is designed to prevent an endless loop of self triggers.
The Sync node should cause the current value held on the server to trigger a Write node in Node-Red that is connected to the same virtual pin.
I’m slightly surprised that the Sync node doesn’t cause the corresponding BLYNK_WRITE(V30) callback to trigger, but I’d need to test that one out for myself.
As you’ve probably gathered, I don’t run Blynk code on my devices, I use MQTT instead, which circumvents this issue and gives numerous other benefits.
Pete.
If so, this is standard behaviour for Blynk and is designed to prevent an endless loop of self triggers
that makes sense
I assume that you have the same Auth token in your Node-Red connection as you are using on your device?
Yes I do, I see the value (a button) on the web dashboard change when I write the value from node red, and when I click on the button then the device gets the value.
Do I need to trigger the Sync with a specific value? (I tried timestamp and just a simple 1)
Also tried “sync all pins” and that also did not trigger any updates.
Any input will trigger the Sync.
In just the same way that the Blynk.syncAll command has changed in Blynk IoT, only datastreams that have the “ Sync with latest server value every time device connects to the cloud” option enabled in the datastream advanced settings.
I’ll do some testing later today to see if I can get a BLYNK_WRITE(vPin) command to trigger.
Pete.
Okay, I’ve done some testing and you’re right, you can’t trigger a BLYNK_WRITE(vPin) event on the device using the Write node.
I think this was previously achieved using the Bride node in the Blynk contrib vor Legacy, but that method has been removed from Blynk now, so doesn’t appear in the IoT contrib.
But. there is a simple(ish) workaround that is very effective…
In the example above, I’ve set-up 6 Inject nodes that inject the numbers 1-6 on the msg.payload (but they could also be text if you wish), Node-Red isn’t fussy.
These then feed into a Change node, which simply sets the msg.pin value to “v1” like this:
There two more of these Change nodes below, for illustration. As you can see, you could set-up a flow like this with data coming in to multiple virtual pins on the same device, with very little extra work.
The next node is similar to the last one, it sets msg.token to the auth token for your device…
If I add a debug node set to show the complete message object after the set msg.token node like this:
the output when I press the Inject 1 node looks like this:
so the msg object now has three elements:
the payload, which was set to “1” by the Inject node
the “pin”, which was set to “v1” by the “set msg.pin to v1” node
the “token” which was set to the auth token by the “set msg.token” node
These three elements are then use as parameters in the HTTP request node to call the Blynk API…
That URL looks like this:
https://lon1.blynk.cloud/external/api/update?token={{{token}}}&pin={{{pin}}}&value={{{payload}}}
The triple curly (moustache) brackets tell Node-Red to replace this with the values that we’ve assigned to these msg elements earlier.
The lon1. part at the beginning of the url is the Blynk cloud server where my project lives, and is optional - but should be changed to match yours if you do include it.
The “Result” debug node is also set to show “complete msg object” and displays the status code returned by the Blynk server, which should be “200”
Hope this helps.
Pete.
pity, but shouldn’t this be updated? Makes no sense to only update the dashboard and not the device…?
Thx for looking into this at such extent, I can indeed use the http api (I already used it as previously my node red crashed on the blynk iot nodes 
)
But I expected the write node to have the same result and it is easier to use so tryuing that.
I guess the write node in the end also does a call to the http api? Or does this work differently?
No, as I explained earlier, it’s to stop the device from initiating an endless loop.
It does make sense though. Blynk sees the Node-Red connection and the device connection as the same thing. if you do a Blynk.virtualWrite(V1,value) from the device, it doesn’t trigger the BLYNK_WRITE(V1) callback on the device. This is exactly the same thing, and is part of the server-side functionality – not something that can be changed within Node-Red.
The Node-Red contrib for Blynk establishes a keep-alive connection to the Blynk server, so it’s totally different to the HTTP API.
To be honest, using the API in the way I’ve shown for writes is very similar to using the Write node, especially if you use the Link-Out and Link-In nodes in Node-Red and give these link connections sensible names. That would allow you to put my example flow on a separate page and feed writes to it from anywhere.
The thing you can’t do with the HTTP API is know when a virtual pin value has changed on the server, unless you constantly poll the server for each pin and check for changes.
The Blynk contrib solves that with the Write Event node, which is almost identical in it’s operation to the BLYNK_WRITE(vPin) callback in C++
But. if you’re going to use Node-Red in a serious way, you’re far better not running Blynk code on your devices and using MQTT instead.
thx pete.
Not sure about other use cases but for us the device holds “the truth” and the dashboard should always reflect that status so we will use the http api as that should work.
(honestly in my opinion writing in an IOT platform to a VP either from the app, dashboard or node red VP write node should always end up one way or the other in the device… )
We mean to use Node red for “side tasks” like communicating with 3rd parties (parsing data coming in and sending that to the device) and storing and getting metadata from our own db.
All sensor data will be going directly from the device to Blynk. So we wil keep on using it 
(also because I really like the platform, apart from these things we are figuring out it works like a charm!!)
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.
after reading your l;ast post you are completely correct. Apologies… I did misunderstand the way the node red “Blynk iot” components work.
So basically a node red blynk iot instance is seen by blink as a device, I completely misunderstood that.
Thx for keeping on explaining. Crystal clear now and knowing this now will prevent issues in future.
So this means I will only use http api within node red.
I get this, you probably have much more control on processing, combining data and executing results from your devices. I will read up on your posts…
thx again for your patience
