Digital pin widget

[Gunner]

Even works with API…

http://10.10.3.13:8080/5fb55413762b400cbb979111b630b9af/update/V128?value=hia

[Aziz]

Device selector reduces repeated widgets.

[wickedbeernut]

My bad. I was looking at BLYNK_WRITE(pin) where pin <= 127. I don’t see a restriction with Blynk.virtualWrite. It seems to pass whatever value you specify. If the server accepts values greater than 127, you should be good.

    template <typename... Args>
    void virtualWrite(int pin, Args... values) {
        char mem[BLYNK_MAX_SENDBYTES];
        BlynkParam cmd(mem, 0, sizeof(mem));
        cmd.add("vw");
        cmd.add(pin);
        cmd.add_multi(values...);
        static_cast<Proto*>(this)->sendCmd(BLYNK_CMD_HARDWARE, 0, cmd.getBuffer(), cmd.getLength()-1);
    }

[Blynk_Coeur]

[wickedbeernut]

What are you trying to do? Receive a value on the device from the server using the BLYNK_WRITE macro (which involves one and only one parameter … pin)? Or send a value from the device to the server?

[Blynk_Coeur]

to write a value to label widget on v128

[wickedbeernut]

Blynk.virtualWrite(128, "nok");

Right?

[Blynk_Coeur]

ooopss, I’m tired

[wickedbeernut]

It works with iOS.

[Blynk_Coeur]

yes and it works well with android now !
thank you so much !
tomorow I will use 128 pins more
maybe we need 512 ?

[wickedbeernut]

It just won’t work in the other direction. For example, you can assign a Text Input widget to V128, but don’t expect BLYNK_WRITE(128) to be invoked. And don’t specify a Refresh Interval of anything other than PUSH. BLYNK_READ(128) won’t work either.

How are you using 128 virtual pins? Are you associating groups of pins with devices? Are all of the virtual pins tied to widgets?

[Blynk_Coeur]

All the virtual pins tied to widgets .
I use two devices and bridge widgets.

[wickedbeernut]

I wonder if there’s a reason they haven’t extended BLYNK_READ and BLYNK_WRITE? It seems odd that you can assign pins 128 - 255 to widgets in the Blynk app, but BLYNK_READ and BLYNK_WRITE don’t accept pins 128 - 255. Maybe I’m looking at the wrong library. I’m looking at the master branch,

blynkkk/blynk-library

We could always extend BLYNK_READ and BLYNK_WRITE ourselves, but then we need to maintain the local copy.

[Blynk_Coeur]

Yes I dono too.
I have to swap some Vpins below 127 to 128 and above.
So I’ll save vpins for blynk_read

[wickedbeernut]

I confirmed that V128 assigned to a Text Input widget is invoked on the device. It invokes GetWriteHandler, however, there’s no BlynkWidgetWrite128 widget write handler. Consequently, GetWriteHandler returns NULL and the thread dies. But the infrastructure is certainly there to support it.

WidgetWriteHandler GetWriteHandler(uint8_t pin)
{
    if (pin >= BLYNK_COUNT_OF(BlynkWriteHandlerVector))
        return NULL;
#ifdef BLYNK_HAS_PROGMEM
    return (WidgetWriteHandler)pgm_read_word(&BlynkWriteHandlerVector[pin]);
#else
    return BlynkWriteHandlerVector[pin];
#endif
}

[Blynk_Coeur]

Yeah I think so too.

[Gunner]

@wickedbeernut

but BLYNK_READ and BLYNK_WRITE don’t accept pins 128 - 255.

You use this “From App to Device” function method for any pin over 127… Single function for all, but with switch case logic to distinguish individual pins as needed.

Using > 127 Virtual Pins in sketch

The BLYNK_WRITE_DEFAULT() function handle virtual write for all pins > 127, this is a small example to manage pins 181 and 190: BLYNK_WRITE_DEFAULT() { int pin = request.pin; // Which pin has trigger write int value = param.asInt(); // Use param as usual. //only for debug Serial.print("virtual write pin: "); Serial.print(pin); Serial.print(" value: "); Serial.println(value); //handle pins actions switch(pin){ case 181: //your custom code for pin 181 Se…

[wickedbeernut]

That’ll certainly work. Is that the plan? They don’t intend to extend the BLYNK_WRITE macro?

[wickedbeernut]

And BLYNK_READ_DEFAULT(). I’ll be darn. @Blynk_Coeur, you don’t need to reassign any of your pins.

[Gunner]

@wickedbeernut

They don’t intend to extend the BLYNK_WRITE macro?

As referenced in that topic, it would apparently just increase the memory usage of the library for the minority of need… so probably not, at least with this current version of Blynk. Who knows what 2.0 will look like.