I have a fairly advanced project using two ESP32 and three ESP8266 devices sending JSON messages at one second intervals to each other through an MQTT broker. The MQTT link seems to block the Blynk.notify() function used on one of the devices. I suspect the notify() function doesn’t have time to complete before the MQTT grabs the link time. This doesn’t particularly concern me because I can add another device to handle Blynk communication and pass messages to it over a serial link. However, I would like to try an alternative method of sending the notification by sending it via HTTP. It may not work for the same reason but its worth a try.
I’ve been experimenting to find the exact syntax used to send a notification but without success. Using a web browser to try different formats, I can send and reveive virtual pin “Vxx?value=” commands by connecting to blynk-cloud.com and using ‘get’ and ‘update’ with no problem at all but trying to send a notification is eluding me. The docs say use ‘notify’ but not how the message should be formatted to send it. I have tried various JSON formats and just simple text, the server doesn’t object to the syntax but my mobile phone doesn’t jingle or show anything.
Can anyone give an example of what the command line should look like to mimic a real blynk.notify() command?
Notifications don’t work if you compiled your sketch using one of the Blynk 1.0.0-Beta.x libraries, could that the cause for your rogue device?
The notify API call requires the message to be in the body, and I’ve not found a simple way to do that via a simple browser call - but I’ve only tinkered with it a little.
Your real solution is not to run any Blynk code on your devices at all, and install Node-Red on a device on your network and use the Blynk plugin for Node-Red as a bridge between Blynk and MQTT.
This is how I use Blynk and it’s far simpler, more flexible and more robust than any other way of combining Blynk and MQTT.
The Notify node for Blynk in Node-Red simply passes the MQTT payload to Blynk and this arrives as the notification a fraction of a second later.
This is my Node-Red flow for sending me an notification when someone presses my doorbell…
The doorbell sends an MQTT message on the “UK/Doorbell_Alerter/Doorbell_Pressed” topic and the current time is appended to this and passed to the Notify node, which sends the notification. The limit node ensures that I don’t get more than one notification every 5 seconds if someone gets a bit overenthusiastic with the button.
Thanks Pete.
I’m not using the beta libraries but quite a lot of the code relies on being synchronised to an MQTT time code so I suspect whichever method is used will disrupt the messages. It’s a project for industrial control with distributed controllers, including one mobile PV powered one although all in range of the MQTT broker. I has around 3,000 lines of code so I think I’ll take the cowardly but practical route of adding an additional ESP8266 to the network and dedicating it to sending and receiving Blynk messages. I need to keep tabs on what it is doing and make remote adjustments from time to time from 400 miles away so Blynk is an ideal platform to use.
I’ll try ‘Wiresharking’ Blynk.notify data when I get time, I’m curious how it works. If I get anywhere I’ll report it here.
You should really give some thought to going down the Node-Red route, because in many ways its better for making changes that using Blynk.
I run a Raspberry Pi that’s my Blynk, Node-Red and MQTT (Mosquitto) sever and run ZeroTier on it. ZeroTier is great because it gives me secure remote access to the Pi without the need for any port forwarding or fancy software. I use it to control my system in Spain, from home in London, and it’s very fast, just like I was controlling a Pi on the same network.
ZeroTier also allows me to set-up an MQTT Explorer session to view all of the MQTT traffic on my remote session, and post MQTT messages if I want to.
I can make changes to most of the logic on the remote session my changing my Node-Red workflows, which is very handy.
I’m not sure that will help.
You need to include the message in the body of the API call, as per the documentation…
Thanks for the info Pete.
I tried the Node-Red approach and it did work - to a point. For most of the Blynk controls and reports it works fine, although the ‘flow’ chart is quite complicated. I got stuck with one problem and couldn’t find an obvious solution without introducing delays, maybe you have an idea. The problem concerns a bank of six (may soon have to be increased) ‘LED’ indicators each accessed as virtual pins. It is possible that the combination of on and off may change simultaneously. The state of each is held within a JSON formatted MQTT message sent by a remote module. Changing one at a time is no problem but if more than one changes at the same time it sometimes exceeds the messaging limit and Blynk misses some of the commands or even floods and disconnects. Do you know of any way to express the changes so more than one virtual pin changes state simultaneously. I’m trying not to use the ‘delay’ node in Node-Red if possible.
In a previous project I ended up using a HTTP interface and selecting one of a group of images to be inserted into a web page. Each image being a picture of the whole bank of LEDs illuminated or not.
With the Blynk cloud servers, trying to send more than 10 updates per second is likely to run into issues. If you run a local server then you can increase the limit considerably.
Adding-in a small delay via the delay node may help, but are you only sending updates if a value changes? if not then an RBE node for each pin may be the solution.
