Having as second device defined in a project caused it not to trigger BLYNK_WRITE()

Solved
1

OK so I just spent about 6 hours figuring this out…

My first experiments were with a SparkFun thing dev. I got my app working fine.
Today my NodeMCU arrived and that is the one I want to run my Blynk project on.

So I went into my project and added a device.
Now I had two devices, SparkFun and NodeMCU.
Each had their own auth token and I ensured that my sketch always used the right token.

All the code that has any visible effect is triggered by changes to virtual pins.
I could not get anything in the version on NodeMCU to work, other than getting onto wifi.
No call to BLYNK_WRITE(V1) would happen when changed I widget the connected to V1.

I spent hours inspecting my code, switched back to the SparkFun - it worked still.
I changed the virtual pins, added widgets in again, etc.

Eventually I decided that having two devices defined may be the problem. Since that was the only thing that had changed.
Spent an hour trying to delete the first device. Searched the posts here and found a thread that was closed last November after it was stated that the first device cannot be deleted, and it was noted to be strange functionality.
So I went and deleted the second device, then modified the first device to no longer be SparkFun but now NodeMCU, got another auth token and updated that in the code and presto it all works…

So the reason I want to report this is an error is because it is not clear to the user that having two devices means that the second device simply wont run. I can’t tell if that is just a flat out bug, or if the design of multiple devices is for some other reason that what I thought it was (an alternate physical device that will run the same app). Either way it sucked up 6 hours of frustration.

Note: all the widgets in the app only use Virtual pins.
When attempting to use device #2 the app on Android would indicate the device connecting and disconnecting, as did the serial output.

Summary of the symptom: No BLYNK_WRITE() events were triggered at all when using the second device. First device continued to work fro the same app.

2

Sorry for your, frustration, but this is an incorrect statement :stuck_out_tongue:

When you have multiple devices in a single project, you can go into a widget and CHOSE which device it will link too. It will default to the primary (aka first) device.

35
351440×2880 184 KB
52
521440×2880 189 KB

Now, in these screenshots I have each button TARGETed to different devices, each with different GPIO, Digital or vPin.

48
481440×2880 238 KB
34
341440×2880 229 KB
45
451440×2880 231 KB

However, they could all just as easily point to V0, but that means each individual device’s V0… which could easily be a totally different function for each board.

There is also a Widget called the Device Selector… in which we could have forth button widget targeted to the Selector, and the selector set for SOME or ALL devices, which would mean that with one press I could trigger each separate device’s V0 function at the SAME time.

24
241440×2880 201 KB

33
331440×2880 318 KB
16
161440×2880 223 KB

Now before you comment about how the documentation doesn’t show this… well, you might be sorta correct. The info IS there, but as these functions all get added over time, then the documentation doesn’t easily indicate the overall relationship between multiple features.

This is where time and experimenting come into play… not just hours… but sometimes weeks or more :stuck_out_tongue: There is a lot to learn.

And asking questions AS you go… not first assuming there is a 'technical problem" just becasue you haven’t figured it out yet :wink:

1 Like
3

It is explained in the docs:
http://docs.blynk.cc/#blynk-main-operations-control-of-multiple-devices

http://docs.blynk.cc/#widgets-interface-device-selector

But, even when you know about how this functionality works, It’s easy to get caught-out buy not changing a widget from the default (first) device to the one that you’re working with in your code.
I’ve certainly wasted a lot of time trying to get a complex nested group of if/else statements working, thinking that the problem lay with the logic only to eventually discover that the widgets I was using were connected to the wrong device.

Pete.

1 Like
4

Thanks for excellent explanation of the reason why it works as it does. Describing how things work does not make something not-a-bug, or a design flaw.

What is missing is any logical reason why virtual pins should not default to the same pins for all devices - until they are set otherwise. Using virtual pins in an app is a generally good practice, as it removes all the issues of having to hard code device specific pins so that the app can run on different types of device. It seems much better to handle all that by conditional defines for physical pins in the sketch. The whole point of multiple devices is so that you don’t have to create a duplicate app, but that is nullified if one has to go and edit every widget.

With the additional information on how multiple devices work, I would now categorize the issue as an enhancement request to have Virtual pins default to the same value across all devices.
It is not that I did not check (and even reassign) pin assignments, I never noticed that the target should be changed too.

When one changes a device from one type to another, we get a nice warning that all the pin assignments will be lost. Good. When I did that before, I found that virtual pins are in fact, not lost, this is logical and also good. When adding a second device, there was no warning that device pins targets should be redefined in each widget, and furthermore, it is reasonable to expect virtual pins to behave in the same was as when one changes device type.

The success of software not only relies on things working as documented, but also being designed for ease of use and not making traps for users. I am well aware of how new functionality often eclipses these goals, and the evolutionary nature of the changes are seen by existing uses as incremental, but it also has to be viewed sometimes with ‘fresh eyes’.

I had to go through this countless times as a quality engineer in IBM over my career. It is a natural response for people who know of a workaround to declare that something is not an issue, or for development to point to documentation of the described functionality, instead of sitting back and asking “Is this a problem?”

If I get time I will play with it some more in a test app and potentially file an enhancement or issue report for virtual pin assignments to be copied into all devices when a new device is added.

Thanks again.

5

Actually, NO pin is set by default… virtual or otherwise. And this makes sense since there are so many options.

That is becasue Blynk supports direct pin manipulation with minimal code for the varying types of devices… and thus changing from one to another would clearly change pin layouts. Whereas Virtual Pins are universal, thus no need to “loose” them on device change… very logically designed :wink:

Another person seemingly unable to actually READ the labels in a thing that is actually fairly self explanatory :stuck_out_tongue:

Button Widget setup with one device… vs… Same widget with multiple devices

53
53800×1280 45.7 KB
12
12800×1280 52.5 KB

Well, that explains much… My recollection of IBM reps was they always seemed a bit yardstick “enhanced” :laughing: around “inferior” clones (that incidentally took the market share :wink: )

I think Blynk should hire you… you would have this whole messed up system fixed in a jiffy :+1: Maybe then I could get my auto scaling fonts back :innocent:

But seriously… I see and comment about design issues just as much as any other nitpicky person would… but you have been in this forum a whole 4 days and resisted every (OK, only some) attempts to assist and guide, with criticism and judgment of others, for daring to point out the facts of the system. Can you not just enjoy this system while learning it enough to constructively make suggestions?

6

I think you should probably create a new Blynk project, add two devices, then go through the process of selecting which device you wnat your widget to control, and which virtual pin you wnat to use.

Then, go back and read your comments and see if they make any sense.

It’s not about knowing how to work around a bug or design flaw, it’s about opening your eyes to the fact that you now have multiple devices and need to select one, before moving on to the next stage.

There is an argument for not populating a default DEVICE (as opposed to virtual pin as you’ve stated) when there are multiple devices in a project.
If you feel strongly enough then add it as an enhancement request here:
https://portal.productboard.com/blynk/tabs/2-all-your-ideas

If you’re an IBM fan (I know a couple of people who’ve worked for them as PM’s and certainly aren’t fans) then maybe take a look at MQTT and Node-Red with Blynk.

Pete.

7

Hi Pete,

no I am not an IBM fan at all. I left because their corporate greed is positively disgusting. Very little value left there, it is not the IBM that was IBM through to the 1980s.

yes, I am aware of MQTT and node-red origins… Node-Red looks incredible.

Dale

8

Yes, I use it for all my home automation stuff, alongside Blynk and Amazon Alexa, and I love it.

Pete.