Get data from one device and print to another?

[wickedbeernut]

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.

[877]

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).

[wickedbeernut]

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
BLYNK_WRITE(V8)
{
  int TempIn = param.asInt();  // TempIn from Device #1
  tft.setTextColor(ILI9341_CYAN, ILI9341_BLACK);
  tft.setCursor(175, 110);
  tft.print(TempIn);
}

Refer to,

blynkkk/blynk-library/blob/master/examples/Widgets/Bridge/Bridge.ino

[877]

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

[wickedbeernut]

@877

I obviously failed to realise that the 1st device will need bridge code writing to it!

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

[Gunner]

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.

[wickedbeernut]

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.

[Gunner]

@wickedbeernut

Beauty is in the eye of the beholder

Too True

@wickedbeernut

the fact that you must hardcode the credentials of another device (or devices), is even more ugly.

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”

[wickedbeernut]

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.

[Gunner]

@wickedbeernut

Look at the MQQT Broker.

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

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

[wickedbeernut]

@Gunner

I think it is MQTT

It is now.

[Gunner]

Ya… it was MOOT point anyhow

[wickedbeernut]

@Gunner

the traditional Blynk method of cross device link

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

Global Virtual Pins (aka, Blynk Cloud Pins)

Problem Statement: share information across multiple, dynamically- or statically-provisioned devices. Note: With dynamically-provisioned devices, the Bridge widget isn’t feasible. Proposed Solution: Global Virtual Pins (GVPs). Let’s assume there are 16 GVPs, G0, G1, ... G15 The app / project would update a GVP and BLYNK_WRITE (or equivalent) would be invoked on each device associated with the app / project. Blynk.syncVirtual (or equivalent) would also be supported. Use-case #1: Two dyna…

[PeteKnight]

@wickedbeernut

Look at the MQQT Broker. @PeteKnight is a big MQQT fan

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

@wickedbeernut

This is beautiful.

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.

Pete.

[Gunner]

@wickedbeernut

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

I suspect Blynk 2.0 is a near total overhaul

[wickedbeernut]

@PeteKnight

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.

Topics, yes. MQTT server URL and credentials, no.

By “hardcode”, I mean codify in firmware.

I’d be OK with hardcoding the URL assuming your “product” will always leverage the same MQTT server. But you wouldn’t want to hardcode the credentials (typically an MQTT server authorization token). This is the exact example I gave here,

Global Virtual Pins (aka, Blynk Cloud Pins)

Problem Statement: share information across multiple, dynamically- or statically-provisioned devices. Note: With dynamically-provisioned devices, the Bridge widget isn’t feasible. Proposed Solution: Global Virtual Pins (GVPs). Let’s assume there are 16 GVPs, G0, G1, ... G15 The app / project would update a GVP and BLYNK_WRITE (or equivalent) would be invoked on each device associated with the app / project. Blynk.syncVirtual (or equivalent) would also be supported. Use-case #1: Two dyna…

I’m configuring the server authorization token (think of it as the MQTT server authorization token) and it’s being applied to all of the devices. If needed, you could configure the MQTT server URL in the same way.

Note: I’m assuming that we’re connected to Blynk (preferably through dynamic authorization token provisioning / Blynk.Inject) in order to configure the MQTT server.

Note: Currently, without the ability to apply configuration changes (through, say a Text Input widget) across dynamically-provisioned devices, I must manually cut-n-paste (configure) the server authorization token from device to device to device (i.e., click on a Device Tile, click on the “SETUP” tab specific to the device, cut-n-paste the server authorization token, return to the Device Tiles widget, click on the next Device Tile and so on).

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

Agreed. But the information needed to establish the introduction need not be hardcoded.

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.

But you’re hardcoding the Blynk device authorization tokens somewhere. I don’t want to know anything about Blynk device authorization tokens. That’s between the Blynk server and the device. Keep my firmware out of it.

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.

I wasn’t advocating the use of MQTT for this use-case. I was simply pointing out MQTT broker pub-sub as an example of a mechanism to exchange information between clients (devices) without the need to exchange device-level credentials. I shouldn’t have to introduce yet another cloud-based server in order to get this functionality. This functionality should be provided by Blynk. It sounds like we’re about to get something along these lines with the next major release (i.e., Cloud Pins).

I respect your opinion and your use of MQTT and Node-Red. It’s a good solution for your problem given the current state of Blynk.

I respect @Gunner’s opinion and his use of the Blynk widget. It’s a good (albeit ugly ) solution for his problem (and @877’s problem) given the current state of Blynk.

[PeteKnight]

I think you’ve managed to hijack @877’s thread and turn it from a general discussion about bridging and the use of MQTT versus Bly k Bridge into something that’s a much more detailed statement of requirements for your specific project.
I’m not saying that this isn’t a valid topic for discussion, and the problems you’ve encountered will certainly apply to other commercial situations, but I’m not sure that this is the bets place to have it.

I have no issues hard-coding MQTT server credentials for my domestic situation, and have no reason to implement OAuth 2.0 tokens. Implementing a fully automated OAuth 2.0 dynamic provisioning system, alongside an automated Blynk dynamic provisioning system is quite a big step forward in terms of required development.

Pete.

[wickedbeernut]

From all the “”, I think @877 enjoyed the discussion. Hopefully, it gave him some insight into how MQTT could be used to solve his use-case and some insight into related (planned) Blynk features.

[Gunner]

@PeteKnight

I’m not saying that this isn’t a valid topic for discussion, and the problems you’ve encountered will certainly apply to other commercial situations, but I’m not sure that this is the bets place to have it.

Pick a good title and move the relevant posts into a new topic, then we (AKA you two ) can debate the best way to do things while I troglodyte my way with Bridge

[877]

Thanks @PeteKnight being considerate as usual . Although the thread has gone a little off topic, I really don’t mind. I would like to learn more but your discussion is a little over my head.

On the plus side I think I have the bridge working