Get data from one device and print to another?

Hi all,

Can I get some advice how to achieve this please.
I would like to share the same auth token (so I have only one project on my phone).

Existing - Garage weather station:
LCD screen
Indoor sensor
Outdoor sensor (V8 temp/V7 humidity)

Proposed - House weather station:
LCD screen
Indoor sensor
Outdoor V8/V7 readings cloned from ‘Garage outdoor sensor’

The app side is straight forward, it’s getting the V8 value to print to the House TFT screen that is troubling me. I tried this code but it did not work:

// This function will be called every time widget in Blynk app writes values to the Virtual Pin V8
  int TempOut = param.asInt(); // assigning incoming value from pin V1 to a variable
  tft.setTextColor(ILI9341_CYAN, ILI9341_BLACK);
  tft.setCursor(175, 110);

Any advice appreciated :slight_smile:

EDIT - using two Wemos D1 mini’s

You can have two (or more) auth tokens associated with the same project.

You didn’t mention what device(s) you’re using. I assume there’s a wi-fi device in both the garage and the house. I’d assign them each an auth token and use the Bridge widget.

1 Like

You can have multiple devices in a project. Auth codes are linked to devices, so you have multiple Auth codes per project, and just one project on your phone.

So, add another Auth code and use Bridge.

Or, come over to the dark side and use Node-Red and MQTT :smiley::smiley:


And if you search the forum (even topics within the last week or two), you’ll find that attempting to share an auth token across multiple devices can lead to headaches. This really wasn’t the way Blynk was intended to be used.

1 Like

@PeteKnight thank you! I did not realise that was possible until now. It seems Bridge is best to use then. Would it work with the above code do you think? (to print to a TFT screen).

PS - I have Node-Red on my list to do, I think my head would explode if I read too much about it currently :laughing:

I will take your word for it! I did see a post by Dimitry which said sharing auth tokens was acceptable and a feature of Blynk, however it was a few years old and experience of the forums is no doubt best. Thanks :smile:


Associating multiple devices / auth tokens with the same project is the foundation on which IoT is based.

I remember someone else doing the exact same thing … garage weather station + house weather station and wanting to cross-pollinate the data between local displays. If I remember correctly, the recommendation at the time was the Bridge widget. We also talked about integrating the local devices with the National Weather Service to get the outdoor readings.

1 Like

Thank you, now I’ve had a look it seems a good option.

Would my code in the first post be the correct one to use? (to read from 1st device pin V8 and print to 2nd device tft screen).

If I understand your scenario correctly …

// Device #1
WidgetBridge bridge(V1);  // or any other unused virtual pin for communication with Device #2
bridge.virtualWrite(V8, TempOut);  // write TempOut to V8 on Device #2
// Device #2
  int TempIn = param.asInt();  // TempIn from Device #1
  tft.setTextColor(ILI9341_CYAN, ILI9341_BLACK);
  tft.setCursor(175, 110);

Refer to,

1 Like

Thank you, yes that’s correct.

I obviously failed to realise that the 1st device will need bridge code writing to it! Luckily it’s OTA :slight_smile:


Yes, that’s the ugliness of the Bridge widget.

1 Like

Ugly? It is actually a very simple and elegant way of triggering any other (within account) device’s pin from another device’s code… no App intervention required, aside placement of widget… which is dead simple.

As well as sharing data, it basically gives any sending device’s code the ability to act like the other device’s App project.

Beauty is in the eye of the beholder. In my eye, any time you hardcode credentials (e.g., SSID, password, auth token) in firmware, it’s ugly. With the Bridge widget, the fact that you must hardcode the credentials of another device (or devices), is even more ugly.

1 Like

Too True :stuck_out_tongue:

But how else would any form of networking code function without some form of addressing and security?

From sensor device - “Hey, you, control device over in the corner, flip the pin on that other lock device over there… no, that one… no, to your the left… your other left!.. ah forget it, the crook already entered and left the building with the TV” :stuck_out_tongue:

Look at the MQTT Broker. @PeteKnight is a big MQTT fan. You certainly need “project-level authorization”.

In this use-case, the garage weather station would publish the outdoor temperature and humidity to the broker. The house weather station would subscribe to the outdoor temperature and humidity. The garage weather station doesn’t need to know the house weather station device-level credentials (and vice versa).

Let’s assume that @877 wants to add a weather station in each room of his house. The garage weather station doesn’t need to hardcode the credentials for another half dozen devices. The new house weather stations simply subscribe to the outdoor temperature and humidity. The garage weather station doesn’t change at all.

This is beautiful.

1 Like

Oh, I see what you mean… but I am referring to the traditional Blynk method of cross device link, not one of the hundreds of other ways of IoT. PS, I think it is MQTT :wink:

Compared to other options, I think the Blynk font options are ugly… but that is still the Blynk way of how they look.

It is now. :wink:

1 Like

Ya… it was MOOT point anyhow :rofl:

It sounds like the traditional Blynk method of cross device link is about to get a heck of a lot better,


I knew I’d get the blame somewhere along the line!

Thant’s what I’ve been saying for ages, but does anybody listen?

The thing us that I there still needs to be some form of ‘hard-coding’.
The device that’s publishing data still needs the IP Address/URL of the MQTT server, and some credentials to be able to log-in, plus it needs to be told which topic(s) to publish the data to.

There still needs to be this ‘introduction’ before a handshake can be established and information exchanged.

Having said that, it is much easier to change things within Node-Red than re-flashing code to a device, so provided you get the credentials, topics and required data correct then it’s easier to manipulate that in the way you want.

I’ve never had to use Bridge within C++ code (or even use the Bridge node in Node-Red) because it’s easy to pull data from, and push data to any Blynk device within a project - provided you know the auth code. The devices don’t need to be in the same project, or even in the same account. Provided I know the auth code and the URL to the Blynk server then I can pull/push data - similar to how it’s done with the RESTful API.

In my living room in Spain I have:

  • 4 lights each attachyed to a to its own Sonoff
  • 1 RGB LED strip
  • 1 temperature/humidity sensor attached to a D1 Mini
  • 1 Intrared transmitter attached to a D1 Mini
  • 1 433MHZ transmitter/reciever attached to a D1 Mini
  • 1 Nextion touch screen attached to a D1 Mini

There’s also:
A weather station (yet to be installed - but working)
4 zones of outside lights each controlled by a Sonoff
A gate release system attached to a D1 Mini
A power monitor attached to a Sonoff

These are all controlled by, or push data into the same Blynk app (okay, not all of the data actually goes to Blynk, but it’s there if I want it). That’s 16 devices (so far), all linked together using Node-Red. I can’t imagine the pain that I would gave had to go through to do that with Blynk Bridge.

And, if I decide that I’d like to push the RSSI figures, or free memory figures for a number of my devices to a Superchart widget; then provided that data is being published from my device via MQTT then it’s just a few clicks in Node-Red and quick change to the Blynk app to add the SuperChart. When I decide that I no longer want the data then it’s a few clicks to take it out again.

I’m the first to admit that MQTT and Node-Red isn’t the answer to everything, but I think that it’s a great solution for a simple to use smart home system and that once you get beyond two or three devices it’s much easier solution once you’ve got to grips with the basics.


1 Like

I suspect Blynk 2.0 is a near total overhaul