Control Device option not available for Automation

[alvelloso]

Hello friends,
I’m finishing the migration to the new Blynk and I’m stuck on how to migrate Bridges.
I understood Bridges could be implemented by Automation, but my devices seem not available to Automations, as shown by the picture bellow.

.

I read all the documentation but I think it’s not paired with the current web version.
Could you please let me know how could I make my devices available for Automation?
Best regards.

[PeteKnight]

Go to Templates > Automations and make your datastreams available to the automations.

Automations can’t fully replace Bridge though.

Pete.

[alvelloso]

Hellow Pete.

Thanks for your response.

As you can see by the picture above, I have allowed the datastreams available to automation, but automations are only working only for notifications. The button Control is disabled, and that is my problem. How could I enable it?

The automation has been allowed as seen by the picture bellow

I tried to allow Automations according to documentation and Maria’s Youtube videos, but the option is not anymore present in the datastream properties.

Best regards.

[Madhukesh]

@alvelloso

The button Control is disabled,

As you can see type of automation is “sensor”
You cannot have an option of switch for sensor.

[alvelloso]

Hello Madhukesh,
Thanks for your response, the button Control now works!
The data is being transferred from one device to another.
But there’s another problem: Only a fixed value could be tranferred. I need to implement a variable data transfer like the old Bridge widget.
Please see my Automation implementation bellow, so you can understant what I meant to do.

[John93]

@alvelloso

I need to implement a variable data transfer like the old Bridge widget.

That’s not possible.
the automation is just a trigger that will preform an action based on certain condition.
to send data between devices like the old blynk bridge widget, you can check this

Webhook widget

Okay, I’ve been doing some testing this afternoon. I’ve been using an ESP32 and the HTTPClient.h library. I’ve not tested with an ESP8266 and the ESP8266HTTPClient.h library, but I wouldn’t expect the results to be much different. I’ve managed to use the HTTPS API call with both the BlynkSimpleEsp32.h and BlynkSimpleEsp32_SSL.h libraries, however, the response times from the HTTPS API call are much longer than when using the HTTP API call. I guess this is what was causing @Blynk_Coeur’s -5 err…

[alvelloso]

Hi! Good to hear about the use of API.
I’ve tested MMQT in the past and it was another workaround.
Best regards !

[PeteKnight]

@alvelloso

I’ve tested MMQT in the past and it was another workaround

But a better workaround that using the API in my opinion, provided you use it with Node-Red and the Blynk plug-in, use a single Blynk device in Node-Red and don’t run any Blynk code on your devices.

Pete.

[Dmytro]

@alvelloso

But there’s another problem: Only a fixed value could be tranferred. I need to implement a variable data transfer like the old Bridge widget.

It’s not yet implemented. But it will be, eventually.

[alvelloso]

Hello Pete
How is it going?
Your code worked as a charm for ESP32. It’s really a better option than MQQT or EspNow.
Since I’m using ESP8266, I need to change the code a little bit for the use of the API call new sintax . The modification is:

#include <BlynkSimpleEsp8266.h> //Changed for ESP8266
#include <ESP8266HTTPClient.h> //Changed for ESP8266
#include <WiFiClient.h> //Added for new API syntax

//New API syntax call
WiFiClient client;
http.begin(client, server_path.c_str());

Thank you one more time.

[PeteKnight]

@alvelloso please edit your post, using the pencil icon at the bottom, and add triple backticks at the beginning and end of your code so that it displays correctly.
Triple backticks look like this:
```

Pete.

[PeteKnight]

There’s an ESP8266 version a few posts down from the ESP32 example…

Webhook widget

[EDIT 14th January 2022] Version 3.0.0 of the ESP8266 Core now requires that the http.begin command now includes the WiFi Client name as well as the server path. In the original sketch the start of the api_bridge function looked like this… void api_bridge(String token, int virtual_pin, float value_to_send) { HTTPClient http; String server_path = server_name + "update?token=" + token + "&pin=v" + String(virtual_pin) + "&value=" + float(value_to_send); // Your Domain name with URL path…

I’m still curious why you don’t find MQTT a good solution. It’s all I ever use for my Home Automation projects.

Pete.