It seems that many of you use Bridge widget, which we removed from Blynk 2.0. Our initial idea is that Automations would fulfill all the needs for cross-device actions.
Help us understand most common usage of deprecated Bridge so that we can understand what can be done. Also, include your feedback on what was not great about it.
Just a quick note: There is a 99.9% chance we will not return Bridge, but rather find a more elegant and user-friendly solution.
I donāt personally use Bridge, because all of my devices communicate with Node-Red, where all the logic processing is done, and Node-Red then communicates with Blynk.
However, having seen list of Blynk related questions in the past, think a typical scenario is one where you have a temperature sensor connected to one device, a thermostat with a display connected to another, and a relay controlling a heating/cooling device connected to a third device.
The temperature sensor just pushes data in one direction to the thermostat, which is the āmasterā device.
The relay device needs to be commanded by the thermostat, but may a.so need to send-back information about itās current status.
The thermostat sits in the middle and takes the data from the temperature sensor, uses information inputted by the user directly (maybe using a physical screen and physical buttons) but also synchronises with app widgets, and pushes temperature and status information out to the app.
The thermostat also commands the relay to turn on or off, and the relay maybe sends back confirmation data about the relay status. The relay device might also have a current sensor attached, to provide feedback about power consumption.
I think the biggest issues/problems that people have with Bridge is that the Sketch Builder example is confusing. It only provides the sketch for one of the devices, and although experienced users can usually work out what needs to be done on the second device from the hints given in the sketch, newcomers find it more difficult.
Once they get into scenarios where data needs to be sent on multiple pins, bi-directional bridging is needed, or bridges between multiple devices are needed then it gets quite difficult to comprehend.
Iām quite a visual person, so for me a diagram explaining how the data flows between various devices would help to make the process make sense, and thatās something thatās lacking at the moment.
I was thinking about writing a guide to this before beta testing began, but I dropped the idea when it became clear that Bridge wonāt be used in Blynk 2.0
Pete.
this is exactly my scenario that you described
I have 2 external temperature sensors, 1 fuel tank level sensor, 1 thermostat with nextion display and 1 boiler management .
Yes I also right now have a remote temp sensor with another unit running Nextion displaying on my temporary system. On my full out system the door alarms, temp sensors and the light switches will all bridge back to the nextion
maybe we have to migrate Bridge to esp-now 
Node-Red is a better solution, assuming that Blynk put together a working websockets interface, or integrate MQTT into Blynk in a workable way.
The advantage of using Node-Red is that you an have a local Node-Red and MQTT server, which means that it will work locally if the Blynk cloud isnāt reachable. If youāre using Nextion controllers then you still have a simple way to issue commands to your āslaveā devices, or you can use the Node-Red to inject commands that would normally come from app.
Pete.
Good idea Pete but I am a noob with nodered 
Iām sure the bridge integration to blynk plateforme is easy.
Jump in both feet. There have been some very helpful people on the NR forum.
I agree, but the forum can be a bit daunting to begin with, simply because there are so many people doing so many different things with Node-Red. Most of the questions are very specific to what these individuals are trying to achieve, and may eb about specific nodes or contribs (plug-in contributions that add extra nodes).
If youāre going to start then installing Node-Red and Mosquitto locally and reading through some of the Node-Red related topics on here is probably the best way to get started.
Pete.
My 2 cents worth I loved the bridge widget very easy to use. I know there is an AP work around bit honestly the bridge widget worked well. Automations is not an option far to complicated
Hi, unfortunately I canāt migrate some of my projects to the new blynk due to the lack of bridge communication, which is really important to me on the new platform.The very useful thing about bridge is that I was able to send data from different hardware devices such as arduino nano ed nodemcu.
Example 1:
Through arduino nano + esp01 I read a tank, this virtual value is sent via ābridgeā to a Nodemcu connected to an lcd1602 display, where the parameters are read simultaneously on both the blynk app and the lcd.
Example 2:
Reading and control system of 2 tanks with 2 arduino nano + esp01 in communication bridge and 1 relay.
In this project there are 2 cisterns about 400 meters apart, one is the main one and the other of rainwater, both of which read the cisterns by sending their values āāto the app.
When the main tank is equal to or below 30% and the rainfall is greater than 30%, a pump is turned on that sends water to the main tank, when the rainfall value is equal to or below 10% the motor is not activated or if activated it switches off automatically.
a presence check also takes place, i.e. if one of the 2 boards cannot be reached via the bridge, they both restart after 30 seconds, resetting the relays to the off state to prevent the relay from remaining on.
I hope bridge will be reintroduced soon because it is currently a big limitation ā¦
Thank you.
Bridge problem has been solved
Not sure that it will work with the Arduino + ESP-01 setup though.
Pete.
Due to Arduino nano ?
Due to the way the BlynkSimpleShieldEsp8266.h library works.
Pete.
A little late to this party but I use the bridge extensively. Sometimes it is used to send ambient temperatures from one ESP to another that controls a remote HVAC unit. I also use a local server which has a Blynk client, an FTP server, a VPN tunnel and a local WiFi access point. Configuration files are stored on the server for all clients and since Blynk does not support email attachments, nightly reports are generated by the ESPs and uploaded to the server. There is a bridge connection to a socket on the Blynk client on the server and it accepts preformatted system commands from the clients to send reports and local configuration files as email attachments. Works very well and is extremely reliable for executing server commands based on ESP client events.