App gets command from Node-Red, device doesn't

mrkoch · June 2, 2020, 12:55pm

A command from Node-Red does not affect the hardware, but the app sees it.

If I tap the button in the app, Node-Red reports the value. The board reports the value.
If I send the value in Node-Red, the app changes. The board does nothing.
I have tried this with two different Node-Red servers. Am I doing something wrong?

I’m controlling a Wemos D1 Mini Pro with library version 0.6.1 over Wifi. I’m using Node-Red and the node-red-contrib-blynk-ws library version 1.0.3. My app is on iPhone 6s, version 2.26.4. Blynk cloud server.

Code (running on Wemos D1 Mini)
(I’m not using a slider, but I just started with boilerplate code from the example library for this example.)
[Opened issue on github: https://github.com/gablau/node-red-contrib-blynk-ws/issues/22]

/*************************************************************
  Download latest Blynk library here:
    https://github.com/blynkkk/blynk-library/releases/latest

  Blynk is a platform with iOS and Android apps to control
  Arduino, Raspberry Pi and the likes over the Internet.
  You can easily build graphic interfaces for all your
  projects by simply dragging and dropping widgets.

    Downloads, docs, tutorials: http://www.blynk.cc
    Sketch generator:           http://examples.blynk.cc
    Blynk community:            http://community.blynk.cc
    Follow us:                  http://www.fb.com/blynkapp
                                http://twitter.com/blynk_app

  Blynk library is licensed under MIT license
  This example code is in public domain.

 *************************************************************

  This sketch shows how to read values from Virtual Pins

  App project setup:
    Slider widget (0...100) on Virtual Pin V1
 *************************************************************/

/* Comment this out to disable prints and save space */
#define BLYNK_PRINT Serial


#include <ESP8266WiFi.h>
#include <BlynkSimpleEsp8266.h>

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

// Your WiFi credentials.
// Set password to "" for open networks.
char ssid[] = "...";
char pass[] = "...";

// This function will be called every time Slider Widget
// in Blynk app writes values to the Virtual Pin V1
BLYNK_WRITE(V1)
{
  Serial.println("Blynk Write V1");
  int pinValue = param.asInt(); // assigning incoming value from pin V1 to a variable
  Serial.println(String(pinValue));
  // process received value
}

void setup()
{
  Serial.println();
  Serial.println("I'm a machine!");
  // Debug console
  Serial.begin(9600);

  Blynk.begin(auth, ssid, pass);
  // You can also specify server:
  //Blynk.begin(auth, ssid, pass, "blynk-cloud.com", 80);
  //Blynk.begin(auth, ssid, pass, IPAddress(192,168,1,100), 8080);
  Serial.println("Setup finished.");
}

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

Node-Red

[
    {
        "id": "591c3a35.6ec74c",
        "type": "tab",
        "label": "Blynk Test",
        "disabled": false,
        "info": ""
    },
    {
        "id": "ec174547.a1436",
        "type": "inject",
        "z": "591c3a35.6ec74c",
        "name": "",
        "topic": "",
        "payload": "1",
        "payloadType": "str",
        "repeat": "",
        "crontab": "",
        "once": false,
        "onceDelay": 0.1,
        "x": 110,
        "y": 120,
        "wires": [
            [
                "9f176979.26d2c8"
            ]
        ]
    },
    {
        "id": "6f5f2860.a8041",
        "type": "inject",
        "z": "591c3a35.6ec74c",
        "name": "",
        "topic": "",
        "payload": "0",
        "payloadType": "str",
        "repeat": "",
        "crontab": "",
        "once": false,
        "onceDelay": 0.1,
        "x": 110,
        "y": 160,
        "wires": [
            [
                "9f176979.26d2c8"
            ]
        ]
    },
    {
        "id": "9f176979.26d2c8",
        "type": "blynk-ws-out-write",
        "z": "591c3a35.6ec74c",
        "name": "Sump Pump - Northeast - V1",
        "pin": "1",
        "pinmode": 0,
        "client": "18828803.811b1",
        "x": 360,
        "y": 160,
        "wires": []
    },
    {
        "id": "932d23a1.e5f3f",
        "type": "blynk-ws-in-write",
        "z": "591c3a35.6ec74c",
        "name": "",
        "pin": "1",
        "pin_all": 0,
        "client": "18828803.811b1",
        "x": 310,
        "y": 100,
        "wires": [
            [
                "393f84f9.480164"
            ]
        ]
    },
    {
        "id": "393f84f9.480164",
        "type": "debug",
        "z": "591c3a35.6ec74c",
        "name": "",
        "active": true,
        "tosidebar": true,
        "console": false,
        "tostatus": false,
        "complete": "false",
        "x": 480,
        "y": 100,
        "wires": []
    },
    {
        "id": "18828803.811b1",
        "type": "blynk-ws-client",
        "z": "",
        "name": "Sump Pump - Northeast",
        "path": "ws://blynk-cloud.com/websockets",
        "key": "M...t",
        "dbg_all": false,
        "dbg_read": false,
        "dbg_write": true,
        "dbg_notify": false,
        "dbg_mail": false,
        "dbg_prop": false,
        "dbg_sync": false,
        "dbg_bridge": false,
        "dbg_low": false,
        "dbg_pins": "",
        "multi_cmd": false,
        "proxy_type": "no",
        "proxy_url": "",
        "enabled": true
    }
]

PeteKnight · June 2, 2020, 5:33pm

Okay, the issue that you’re seeing is because you aren’t using the Bridge node.
If you replace your Write node with a Bridge node then it will work fine.

I think the reason is actually to do with the way that the Blynk server works, to prevent you getting into an endless loop.
A Blynk.virtualWrite(vPin,value) from C++ doesn’t trigger a BLYNK_WRITE(vPin) because if it did then you’d be endlessly responding to your own Blynk.virtualWrites.

The Blynk server can’t tell if the virtualWrite came from the hardware or from Node-Red, so it simply responds in the normal way, which is to change the status of the widget attached to the virtual pin, but doesn’t report the change back to the hardware, which would trigger the corresponding BLYNK_WRITE(vPin).

Using Bridge works, because the server sees this as coming from a different source device, so a BLYNK_WRITE(vPin) does need to be triggered on the destination device.

So, it’s not really a shortfall if @gab.lau’s library, it’s a design feature of the Blynk server.

Pete.

mrkoch · June 2, 2020, 7:39pm

Thank you. I understand that explanation. Of course the hardware doesn’t get a write back when it writes to the Blynk server.

The bride node does not work after I change the pin (or first set-up) until I toggle the “Bridge” log under the configuration node.

Otherwise it is good. Thank you.

PeteKnight · June 2, 2020, 7:53pm

Not sure I understand that, but if your’e happy then all is good.

Personally, I’d use the GitHub repository for reporting bugs that you’ve raised here and are confirmed to be genuine issues as opposed to user error. @gab.lau tends to be fairly busy beavering away on his projects, so you don’t tend to get speedy answers over there anyway.

Pete.

mrkoch · June 2, 2020, 7:55pm

Thanks again. You have no idea how much time I spent trying to figure out why it wasn’t working! I finally gave up until the older libraries became too much of a headache.

PeteKnight · June 2, 2020, 8:00pm

To be honest, my advice would be not to run Blynk code on the devices at all.
My Home Automation setup uses MQTT messaging between the devices and the Node-Red server, then the Blynk contrib to provide the interface to the app.
No need to go anywhere near the Bridge widget in that case

Pete.

mrkoch · June 2, 2020, 8:25pm

I’m certainly going that way. This particular device was appropriated from my sump pump project for Dad’s house. Unless I’ve overlooked something, being on a different internet at his house, it’s either Blynk or MQTT server / Node-Red / VPN to his house.

For my network, I’m learning to rely on MQTT and control Node-Red through Blynk, just as you say. My only doubt is for my boiler. If my Node Red/MQTT goes down, wouldn’t I be safer having duplicate access to the board with Blynk? For example, I lose temperature data in Blynk every time Node-Red restarts. Straight from the board, it only depends on internet. What would your experience advise?

PeteKnight · June 2, 2020, 8:51pm

Possibly, but it does get messy in that scenario.

That sounds like your’e not synchronising the values to the Blynk server when you restart Node-Red.

You should also look at retained messages in MQTT, and possibly consider a hardware watchdog on your mission-critical hardware that will reboot it if it locks-up.

A back-up Node-Red server is also something to consider.

Pete.

mrkoch · June 3, 2020, 1:49am

Thanks for the suggestions! I’ll have to think about a permanent NR backup server. Speaking of a watchdog timer, my boiler board reboots occasionally. Perhaps because I have a bug in the following code that has stumped me. Could you take a quick look at the line that says “Why?” Does anything jump out to you, other than being, erm, messy?

I suppose I should post the whole sketch in a new post?

void pub(void) {
// publishes data
long uptime_s = (uptime_ms / 1000);
char uptime_char[12];
//String uptime_string = "";
//uptime_string = String(uptime_s);
static bool oldDigIO[maxDigitalCount];
static float oldTemp[maxTempSensors+1];
bool newDigIO[maxDigitalCount];
static bool firstRun = true;
char temp[7];
static long uptime_s_last = uptime_s;

// send uptime every 15 s
if (uptime_s - uptime_s_last > 15) {
  ltoa(uptime_s, uptime_char, 10); 
  client.publish(will_topic, uptime_char, true);
  uptime_s_last = uptime_s;
}
  // the following block destroys the value in 'uptime_s' in the above block. Why?
  // get digital values
  for (int i = 0; i < maxDigitalCount; i++) {
    
    newDigIO[i] = readDIO(digitalAssgn[i]);
//    delay(10);
//  Serial.println("newDigIO: " + String(newDigIO[i]));
  } 

  newDigIO[5] = statAlarm; // overwrite with the programmatically defined alarm value
// abridged here for brevity
}

PeteKnight · June 3, 2020, 6:15am

I think so.

Pete.