Need help migrating my ESP8266 & ESP32 from legacy to 2.0

I have been using Blynk Legacy for four years with no problems. My mobile App had four gauges used for temperatures plus two super charts. One chart displays four temperatures over time and the other displays two weekly time values in bar chart format. Additionally, I have two LEDs and two value displays.
I have two ESP32 devices and one ESP8266. The 8266 has three Dallas DS18B20 temperature sensors and the ESP32 has one (four temps total). The other ESP32 sends two time values (one for heating and one for cooling time) to the value displays. The on/off heating values control the two LED indicators. This ESP32 also sends weekly time values to the bar graph.

So you can see I have three devices sending to one Blynk Legacy display. Each device has the same auth token and of course has different virtual variables for all values.

All of this has worked perfectly but since Legacy is going away I need to migrate. But I am unable to get even one temperature reading to send from a new ESP8266 board to the web dashboard. I heard someone say that if it asks for an auth token then it is connecting to the Legacy server. I have a new device with a different name than that of my Legacy system. I’m having trouble sending the WiFi credentials to the new ESP8266 because it insists on an auth token, which I do not have.

How should I proceed ?

Thanks
Mike

you can check the new Blynk documentation. It’s so useful
https://docs.blynk.io/en/blynk-1.0-and-2.0-comparison/migrate-from-1.0-to-2.0

That’s extremely bad practice, and isn’t how Legacy or IoT is meant to work.

In IoT you should either use Automations to send data from one device to another, or use the HTTP(S) API to emulate the Bridge functionality that was available in Legacy (and is what you should have used in Legacy).

Please have the Auth token discussion in JUST ONE PLACE. You’ve already raised this issue in two different paces, and I’ve shut one of them down and created a new topic for you from your other post. Please have that discussion in that topic, not here.

Pete.

Why is it bad practice to have three devices send to one dashboard? Blynk Cloud sees only one IP address with my 14 virtual variables. I have used that on Legacy for four years with no problems or errors and never saw anything negative about the practice until now.
I would have to rebuild all my systems almost from scratch to use Automations or HTTP(S) API , once I learn how to do that (which will take a while).
I am only a hobbyist, not a business and I just want to monitor temperatures and HVAC usage in my house so the $59 a year cost is getting a bit much. Legacy worked perfect for that- it was super easy to set up and never gave me any trouble (too bad it will be gone soon)
.
Is it possible to cancel my account for Blynk 2.0 and get a full refund if I asked for it ?
Thanks
Mike

I figured this out and got things working… I have one gauge and a super chart displaying temperature on my mobile device. Now I have to get the web dashboard working. No need to cancel subscription anymore.
Thanks
Mike

Well, IP address have nothing to do with this.
The whole concept of Blynk is that each device connects to Blynk with its own auth token. This allows the Blynk server to have an Always On connection with each device and to monitor that connection. The primary advantage of this in Legacy was that the user would be alerted if an individual device went offline. With your system, all three devices would need to go offline before the Blynk server was made aware of this, and could alert you.

In IoT, the other reason for individual auth tokens and device names is that it allows the Blynk.Air OTA system to be used.

In Legacy, there was no licencing cost attached to each device, so shared auth tokens wasn’t the Blynk staff were too worried about. They warned against it, because it’s not how the system was designed to be used, but that as all.
In Blynk IoT, licencing is based around devices and users, with limits set on each by the subscription plans. As far as I’m aware, Blynk don’t currently prevent or specifically look for another device connecting with the same auth token as one is already connected. But, think about how you would approach this if you were Blynk and you were looking to protect your revenue by preventing fraudulent use of multiple devices via auth token sharing. If it was me, I’d implement a system where if there was already an Always On connection with a specific auth token, and another connection was requested with the same auth token, I’d terminate the first connection and accept the second connection.

It may not work that way at the moment, but Blynk would be crazy not to implement this sort of checking in future.

So, my advice is to use Blynk as it is intended, and have unique auth tokens and device names for each device. This will create one tile for each device, and that may or may not suit your way of working. If it doesn’t then there are workarounds available.
I’d say that it’s better to do it that way than wake up one morning to find that only one of your devices is working, because Blynk have closed a loophole.

Just my opinion though!

Pete.

Thank you. That makes perfect sense and I will now comply with those requirements. My three devices will each have their own auth token and I guess I will have one template for those three devices?
I am slowly figuring all this stuff out.
Thanks for your help.
Mike

Maybe, it depends if they perform similar functions.
In most situations I think you’d have three templates and one device per template.

Pete.

Is it possible to show the data streams from more than one device on one dashboard ?
That’s what I’d like to do if possible.

With Legacy I was able to scroll the screen to see data from three devices. Was that only possible because I was using the extremely bad practice of the same auth on all devices?
Thanks
Mike

Yes. You can use automation to forward data between devices, just like the old blynk bridge widget, check the documentation for more details

No, but as @John93 has said the solution is to send data from “salve” devices to one “master” device, and display this data on the master dashboard. This way, you are amalgamating that data into one device and therefore one dashboard.

Pete.