Proposed - House weather station:
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
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.
@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
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
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.
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.
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”
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.
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
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.