VFD Pump Control via RS485 Modbus and Blynk

Hello, I live in a rural area and dependent on groundwater for my water supply and fire protection. Over the years I’ve had my well pump fail, pipes break, bladder tank lose pressure, and my booster pump to my house fail. Many times my 5,000 gallon fire tank drained and in some cases left us without water for days. Thanks to the creators of Blynk and years of trial and error by someone without any programming experience, I now monitor my tank level, discharge pressure, tank levels, suction pressure, and control my single phase 2 hp booster pump with an Arduino Mega, Esp8266-12F, flow meter, and 0-5vdc pressure transducers on the suction and discharge. With the exception of taxing the speed of the Mega with all the sensors, failure modes, and control features, this is working really well.

Now I’m changing up the game with something that may be beyond something that I, as a layman, can figure out on my own so I thought I’d solicit advice before I start my new adventure. I purchased a 3 phase motor and a VFD with RS485 communication. It also has analog inputs for 4-20mA and 0-10vdc sensors that will lend itself well to my discharge pressure transducer. However, there are a thousand programming/ monitoring features with this VFD that I would love to tap into remotely with Blynk and program with Arduino. Raising and lowering pressures remotely will be one of my goals along with adjusting pump speed to follow the pump’s best efficiency curve at different flow rates since irrigation is one of my largest electrical expenses. So to make a long story short, the help I need is the best methodology for communication between Blynk using the RS485 communication port and any resources that anyone knows about that I can read up on. I’m using the terminal monitor in Blynk right now for my existing setup so it seems like it would be useful but I don’t have the foggiest idea right now if that would be possible. I’ve also ordered one of these to interface with RS485.

I’ve also ordered a PWM to 0-10vdc converter if I decide to control everything from the Arduino but I would probably need to upgrade my Mega or add another one dedicated just for controlling the pump while the existing one only reads sensors.

Anyway, any help, suggestions, or advice is appreciated.


1 Like

I recently set-up a small solar system for garden lighting, with a solar charge controller that uses RS485 MODBUS communication.

The electrical side of wiring the RS432 to Serial interface was fairly simple, but the challenge comes from designing your software to read the serial data in a way that will work with Blynk.

I don’t actually run Blynk on my devices, I use MQTT messaging to send data to a Raspberry Pi, which then talks to Blynk, so I can get away with having a cluttered void loop. This is necessary because the code needs to be constantly listening for serial data.

My other challenge was making sense of the MODBUS protocol for my solar charge controller. There was plenty of documentation available, but it was written in Chinglish and there were numerous errors and omissions. I ended-up combining the data from three different versions of the documentation to finally work out what the various registers actually did, and how to access them.

Now it’s working, I’m very impressed with the functionality and reliability.

I think you should start by getting communication with the MODBUS device working correctly without Blynk, simply displaying the data in the serial monitor and using physical buttons to trigger writing commands to the MODBUS device.



Thanks Pete. It sounds like you have had a good experience for me to follow in your footsteps. A lot of my code right now uses the Arduino Mega for automation while Blynk is the monitoring system when there is an “event” whether it’s the code triggering an alarm, failure mode, or something as simple as the pump turning on or off. As such, I’ve tried to keep my void loop routine as clean as I know how by only calling on a subroutine (forgive my terminology if I’m not using the correct programming lingo) when the event occurs. For the bulk of the time the pump is off and nothing is happening. Now the sensors on the other hand are where I can relate with your use of the Raspberry Pi, since that part is where my loop gets messy and bogs things down. I’m constantly measuring suction and discharge pressure along with flow rate even with the pump off. I’m using Blynk Timer but my loop takes 3-8 seconds from beginning to end by using a millis command at the start and end of the loop. I have a lot of floating point math and can’t seem to master integer math without getting a lot of weird results. It would be nice to offload the messy parts to a raspberry pi, but thats another new platform I would need to learn. I’ve been looking at putting the Blynk Server on one anyway so maybe it’s time to take the dive. I have a Synology server that I’m using also that I tried to put it on, but my CPU is maxed out with packages running so the Ras Pi could be next on the horizon. I also looked at the Particle Photon to get a little more processing power and stay with the Arduino/C++ language.

As far as getting thing running without Blynk first, I agree. This will be a work in progress for a while. Blynk will still be used as a monitoring tool as I try to get the communication worked out between the Arduino and RS485 on the VFD. Half of my problems in the past have been not having “eyes and ears” on my water system when troubleshooting and Blynk has been instrumental to help figure out what’s going on when problems occur.


Okay, a few observations…

Having a process that takes up to 8 seconds to complete is probably pushing the boundaries with Blynk already. Blynk needs to be constantly communicating with the server, so that it knows if anything (such as a button press event) has changed in the app. It does this with Blynk.run and I think the standard timeout is 10 seconds. If the server hasn’t heard from the device in the past 10 seconds it will assume it’s MIA and show it as offline - missing, presumed dead.

The device then needs to re-connect to the server, which will happen automatically if you’ve written your code correctly, but it’s not very elegant. Adding. Blynk.run commands into your function (subroutine) that does the floating point maths is one way to keep the communication with the server going.

Personally, I’d recommend going for something a bit more mainstream than the Particle boards. I think (but I could be wrong) that they’re designed to work as a Wi-Fi mesh system and talk to the Particle server. A regular ESP8266 based device such as a NodeMCU or Wemos D1 Mini is what most people use, or an ESP32 device if you need lots of IO pins and are working with a lot of analogue inputs.
You might find this topic handy:

My approach is to use multiple Wemos D1 Mini devices that all talk to the central Pi device via MQTT. My home automation system currently has 17 separate devices, most of which have a single job to do - such as turning a light on or off, taking temperature readings, driving a touch screen etc.
All communication is via Wi-Fi, which means that you put the device where you want it and power it locally, rather than running a rats nest of wires back to a single controller (the Mega in your case).
A bit more light reading here if you’re interested in this concept:

I don’t run a local Blynk server, but if I did then I’d probably go for a Docker setup. My Pi acts as an MQTT and Node-Red server (Node-Red is a graphical programming tool that allows you to create rules-based workflow-type processes very easily. It also handles the communication with Blynk via a Node-Red plugin). I know very little about Raspberry Pi’s, and the whole server build was done via a script that installs everything, but I thing in future I’ll be moving towards a Docker based setup to simplify things even further.
There’s a great Docker explanation here:


I would say most of the time it’s 2-3 seconds, but there’s been times that I’ve seen 8. I “believe” there is a way to configure Blynk to lengthen the 10 second timeout (and I “believe” I’ve done this), but my memory prevents me from having 100% certainty on this point. Either way though, my code does include the reconnect commands that you mention. I also have the time that I lost connection and the time connection was re-established printed to the terminal monitor to give me an idea how long I was down. Since my code to operate the pump (and any failure modes like the pump running dry) doesn’t rely on Blynk, it really doesn’t impact my water supply. It just removes my ability to remotely monitor it.

As far as using NodeMCU/ESP8266, I use them quite a bit around the house. My pump controller uses an ESP-12E for communication. My problem though is they don’t have the processing speed to decrease the loop time. My understanding is that the Particle does. Downside is there aren’t any cheap Chinese knockoffs like those that exist for the Arduino/ESP platforms. I still think I can make some improvements with integer math or using parallel Arduino shields if I want to bifurcate the processing of sensors, controls, etc. Using your MQTT and RS485 setup is quite interesting. I will definitely review your links as I’m waiting for my parts to arrive on the slow boat from China. I think I will be in the design phase for some time figuring this out, but it’s a lot more fun doing this than working on a puzzle. I’m a Civil Engineer by trade, but getting into the process and automation has become an addiction.

Thanks again Pete,

I’m not convinced that the Photon has more processing power than the ESP8266 or ESP32, but might be wrong.
But, if your ESP8266 isn’t doing the calculations quickly enough then I’d say that you have a problem with your code.

Do you want to give us a summary of what sort of things you’re calculating, and how often?
Soare is the code, as if it takes several seconds to execute then we probably aren’t going to pick through it in its entirety.
I’m just think8ng that there might be a better way to get the data that you want from your system, maybe by splitting-up the calculations, making some assumptions, or hard-coding some values.


Hi guys!
I mostly and only use Particle devices on my projects. I wanted to see if I can provide my opinion as well, if you guys do not mind.

Photons are wifi devices only (no mesh, mesh devices are the next gen) and yes, they connect to the Particle Cloud. That is one of the beautiful things about that device, since from that cloud you can control it, monitor it and flash it (and troubleshoot the issues it may have).

Since you mention you have a Rasp Pi in your architecture for your mqtt server, I think in the case of Particle, one can say that the Particle Cloud would replace that Pi.

I have no idea how they compare exactly, but I’m under the impression that the Photon may be faster than the ESP8266, but slower than the ESP32. Some info here.

@Phillip_Dauben, I encourage you to try a Particle Photon and see for yourself, I do not think it will let you down. I personally find them amazing.
For reference, I leave you with a link to all my Hackster projects, just in case you wanted to check what a Particle device can do.

One thing that I like about the Particle devices is that I can flash them, access their variables and trigger functions on the from anywhere as long as I have internet connection. I can troubleshoot my home projects even if I’m away on a business trip.

I think similar remote access to variables and functions in Arduino can be obtained with aREST.

Since I know nothing about the workflow on the ESPs, maybe you Pete can explain your worflow a bit if you would not mind? Do you need to be connected locally to them to access them, or troubleshoot them or flash them?

Thanks for the feedback Gustavo. Looking at processor speeds, the Photon was much faster than my Arduino Mega, but the thing that caught my eye was that it was 5V compatible. Most of the faster microcontollers on the market were 3.3v and not 5v tolerant. Yes, I can always level shift, but when all of my sensors were 5 volts, it becomes a pain and I always tend to fry something inadvertently. The ESP32 is also catching my eye due to the price tag, but debating about level shifting. Boils down to whether $15 more for a photon is worth the extra effort to redo everything. I will look at your Hackster Projects that you left a link to. I appreciate it.


I think it’s more a case of tolerating 5v, rather than being ‘compatible’.
The ESP8266/NodeMCU boards are also able to tolerate 5v logic levels in the GPIO pins. The only time I’ve ever needed to use a logic shiftier was with an RFID reader that needed 5v 2-way comms, and the 3.3v logic levels from the NodeMCU were insufficient for it.

I still think that ‘mainstream’ is a better option, unless you’re going to put the effort into figuring stuff out for yourself.


Hey, like Pete mentioned, I think the Photon is 5v tolerant, and only sometimes compatible.
From the docs:

[1] FT = 5.0V tolerant pins. All pins except A3 and DAC are 5V tolerant (when not in analog mode). If used as a 5V input the pull-up/pull-down resistor must be disabled.

Since the Photon uses the same Arduino compatible language you may not need to redo everything.
One thing for sure to have in mind is this: if you are using specific libraries, please check that they are ported to Particle already.

The Particle community here is very solid and helpful, only comparable perhaps to the Blynk community. I do not think you’ll be alone figuring things out.

Although less popular than Arduino itself, I’m pretty sure they will be a nice addition to your projects. The free cloud they come with makes a big impact on my workflow, for the better.

Thank you, guys!

I think the issue from my point of view is that there aren’t many people who use the particle boards (and cloud) who also use Blynk.
If someone asks a question of the Blynk community then users like myself will get as far as the word ‘Particle’ and back away.

The concept of having two cloud services, the Particle one and the Blynk one, on the same board at the same time isn’t likely to be without its problems, and I for one would be asking myself if any issue I encounter is down to the fact that I’m running this setup.
I’d guess that the Venn diagram of Blynk users using Particle cloud and Particle cloud users using Blynk will be relatively small, hence the ‘you’re going to have to figure this out without too many other people to hold your hand’ approach.

ESP8266s or ESP32s don’t give you everything that you’ve described Particle cloud as providing, but stuff like OTA updates and publishing debug data to either the serial monitor or to Blynk will make debugging straightforward.

As ever, it’s a case of you ‘pay your money and make your choice’, so people need to weight-up the pros and cons and maybe do a bit of experimentation before jumping one way or another.


I see better what you mean now.
Thank you for taking the time to clarifying that!

Please don’t back away too fast for the benefit of those community members in trouble. In my experience, I used Wemos D1s, Raspberry Pis and Particles with Blynk and Blynk-wise they do not make almost any difference in where the issues are and the troubleshooting required to figure things out.

At the risk of seeming being defensive on the Particle side, this you may never find:

Why? Because the Particle Cloud is native and as a beginner, you do not need to manage that connection. You don’t code that part, or see anything since it’s just integrated with the OS the device runs.
Yes, there are special cases where you need to manage that cloud connection (low power projects or cellular-connected ones) but I never had to do anything on that front so far.

I hope you accept this as another point of view in the discussion and don’t take any of this as an attack on your opinions, please.

One thing that I wanted to check with you, since I do not know the answer, is this:
Can one update the firmware on an ESP device from far? Or one has to be in the same wifi network?
That may help justify the extra $15 investment.

Thank you again,

1 Like

Is much easier if you’re connected to the same network. Standard OTA doesn’t work outside the network, so the solution is to use HTTP OTA. This downloads a new firmware file from a web server and installed it.
Much messier than the Particle cloud solution, and although I do use this in some circumstances I’ve now moved to simply having a mini PC that I can boot remotely (via Blynk of course) and use that to upload code to devices within the network. I just use TeamViewer to remotely control the Mini PC. Much more expensive than a $15 board, but this approach is also used to securely manage my RPI Node-Red server, check MQTT message data, and administer my CCTV system, so would be needed anyway.

Having said that, I don’t tend to do OTA updates from afar, unless it’s to fix a major big, as it’s often necessary to physically check that the device is operating its peripherals as you expected, which simply can’t be done the same way remotely.

You make a great case for buying into the Particle family, and there are some obvious benefits. Personally I don’t want to add another MCU type to my system, and I do have reservations about the suitability of these boards for absolute beginners, but they obviously have a place for some users.


1 Like

Do you want to give us a summary of what sort of things you’re calculating, and how often?
Soare is the code, as if it takes several seconds to execute then we probably aren’t going to pick through it in its entirety.

I have a 0-5V pressure transducers on the suction and discharge side and a hall flow meter on the discharge. I calculate the pressure and flow rates, but on the suction side, I also calculate the level in my tank based on the pressure reading which is a constant (2.31 feet per psi). I think I can clean things up a bit by doing the integer math first from the reading and then floating point math at the end.

As far as the Photon being 5v tolerant, I could have sworn I had read that it was compatible. If only tolerant and doesn’t give me the full 0-5v analog ranges, then I had one other idea of reading the sensors with my mega and sending the data via serial to something like the ESP32 (or Photon) to do the math . . . or build a series of voltage dividers to lower the voltage. 'Just haven’t had time lately to play with it any more, but with 2-3 second loop times, I haven’t been hard pressed since that hasn’t been much of a problem. Pump just turns on or off 2 seconds later or my sensors are delayed by that much. I did see 11 seconds yesterday. I’m really curious about how variable it can be. Even now as I type, I’m seeing around 2.5 seconds.