Resync button not based on virtual PIN

Need Help With My Project
1

Hello Blynkers!

I am finalizing my project based on an Arduino Mega+Ethernet board+ 16 relay board (yes, 5v external power source), but I stumbled upon some strange behavior.

the basic test platform is this:

  • create an app with one button switch ON-OFF, attached to a “normal” Pin, let’s say D24
  • create a simple program for aduino, containing Blynk.syncAll() in BLYNK_CONNECTED()
  • launch the blynk application
  • switch on the blynk button (the relay will activate)
  • switch off or reset the arduino board (the relay will deactivate)
  • switch on the arduino board (wait10 sec if you disconnect dc power)

the board re-sync at reconnect
but
SyncAll() won’t update the status of the button (while is perfectly functioning with buttons attached to virtual pin), and on the relay board the relay is OFF while the Blynk button is ON.

how can I resync this, in one way or on the other?

immagine
immagine899×1599 98.1 KB 

#define BLYNK_PRINT Serial


#include <SPI.h>
#include <Ethernet.h>
#include <BlynkSimpleEthernet.h>

// You should get Auth Token in the Blynk App.
// Go to the Project Settings (nut icon).
char auth[] = "x7wv1gNXpg_qPPjBYUOEUNQmCfs4IZfa";

#define W5100_CS  10
#define SDCARD_CS 4

void setup()
{
  // Debug console
  Serial.begin(9600);

  pinMode(SDCARD_CS, OUTPUT);
  digitalWrite(SDCARD_CS, HIGH); // Deselect the SD card

  Blynk.begin(auth, IPAddress(192,168,1,199), 8080);
 
}

BLYNK_CONNECTED() {
  Blynk.syncAll();
}

void loop()
{
  Blynk.run();
}

void(* resetFunc) (void) = 0;//declare reset function at address 0
void reset() {
  asm volatile ("jmp 0");
}

BLYNK_WRITE(V0) {// soft Reset
  if (param.asInt() == 1) {
    delay(3000);
    resetFunc(); //call reset
    delay(5000);
  }
}
2

You answered your own question :slight_smile: Use Virtual Pins and a bit of code instead of directly setting GPIO in the widget…

BLYNK_WRITE(V1) {   
 digitalWrite(24, param.asInt()); // Get vPin state and set GPIO to match
}
3

Thank you GTT for your answer, but…my question was on digital Pin…
I’ve excluded the use of virtual pin (I am well aware on how to use VPIN) because using currently 127 virtual Pin there are none left for an arduino mega.
if what you say is the final response, I am trying to understand the rational to allow a mapping with a “real” Pin on blynk app and then no control for it over a restart and resync of the board for any reason (already implemented for VPin).
No other way to resync a digital Pin with Blynk App?

4

lookin at server source seems to be no specific selection of virtual pin type in function syncSpecificPins for class HardwareSyncLogic… mmm… will look again…

5

And I answered it… why use sticks and stones when proper tools are available.

It was one of the first things in the overall Blynk program, basicly a “No Coding” way of doing very simple things.

I think virtual pins came shortly after and features progressed toward the better way of making more complex actions/reactions as people required them… and AFAIK the only way to have true bidirectional control over a single GPIO with a single widget.

But, if you insist on the “archaic” way, at least add in a proper pinMode() command for the GPIO, as (from my own experience) relying on Blynk’s direct pin manipulation and internal pinmode is flaky at best.

What???

6

Thank you GTT for your opinion. but I’m afraid wasn’t helpful, I’m sorry.
I understand your background, you are helping users not so skilled with blynk and VPIN, and thank you for this, but I am pushing the platform toward boundaries: my project is big (8200+ code lines) and complex (12 devices) and I need to understand if Blynk can deal with complex projects and anyway, I repeat, I run out of Virtual PIN, otherwise I would have never started using a direct digital Pin.

My question was simple, and your opinion I understand is straight and simple: NO, you cannot have a synced digital pin after a restart. That’s it.

Just clearly reporting this on Blynk documentation, on State syncing chapter, with a:

WARNING: State syncing doesn’t affect DIGITAL PIN value/state

or some FAQ, may save some time to test for malfunctions and to reply to developers like me who try to implement this usage of digital pin, directly allowed on Blynk App, and having a linear expectation of behavior compared to virtual pin.

… or … perhaps it’s just a Bug, looking at the documentation hereby reported:

Blynk.syncAll()

Requests all stored on the server latest values for all widgets. All analog/digital/virtual pin values and states will be set to the latest stored value. Every virtual pin will generate BLYNK_WRITE() event.

BLYNK_CONNECTED() {
    Blynk.syncAll();
}

reference to sync also digital pins is clearly reported, so is it a BUG?

I will signal this to Dmitriy, or somebody else in Blynk, if helpful.

Thank you GTT for your valuable time spent to give me an answer.

7

Why don’t you simply add a device to your app that has 255 virtual pins (such as the ESP8266) and use BLYNK_WRITE-DEFAULT in your sketch?

Having said that, I’ go down the MQTT and Node-Red route if I were building a project of his size, it makes life much simpler when working with multiple devices. The Blynk Websockets plug-in for Node-Red works like a dream.

Pete.

8

yes, change the master board from arduino mega to esp8266 family was my second choice, if the digital pin resync issue couldn’t be solved. Will also give a look to the plugin for node-red, but I think switching to 256 VPINS will solve my problem within Blynk platform.
thank you Pete

9

No, I didn’t say quite that :stuck_out_tongue: I DID say to try adding proper pinMode() commands, as that might? help.

However, as I quickly discovered after my first few days with Blynk, direct GPIO manipulation was clearly way too limited, compared to virtual pins and a bit of code, and thus simply not worth further consideration… And that was my “official” opinion :slight_smile:

Yep, many documentation and application adjustments would be nice… but then the devs have already long ago indicated that no further significant efforts are being committed to this non-commercial version… so we works with what we gots :frowning: