The last part of our contribution series (Part 1, Part 2, Part 3, Part 4, Part 5) Should show how to equip the TDMM with a Command Processor with a little programming, which can take over the control of the TDMM and is easy to expand. We also get to know the Library Eeprom.H, with which we can permanently store the settings of the device.

I have integrated a few examples of simple "virtual measuring devices" for you, which, for example, react to the crossing of a limit. A message can be made by voice output, or via the serial port. A message about MQTT is also possible, so that an action can be triggered. For example, a charger can be switched off before the battery is overloaded. This gives us functions of how they can be found in professional measuring devices.

The Command Processor and Eeprom .h can be used in many other projects. It is probably worth studying a little more.

This is how the Command processor works

We see the new library in a sketch . The Github page provides further useful information. There are several blocks whose arrangement should be observed:

Right before void setup () is the command table. "Definitely wired" is the help function, which with a "?“ or "h“Is called. The so -called.  "Handler"   void handler(Char* Param)

For the Help statement, stands below the table, directly void setup ().

All commands are entered in the command line of the serial monitor. Please make sure that the end of the line is formed by "new line". This is important because otherwise communication will not work.

All traders stand for their own commands before the table.
Let's take a look at your own command: 

 { "Lu",  handler,    "U",   "Tension limit BSP: LU 15 | Switch off lu 9999", 1 },

With the "?" Or "H" command you get the complete command table with the functional descriptions via the serial port. You can also use the TDMM via the serial port from a Rasperry Pi, another microcontroller, or via the serial interface of a PC / laptop. This enables integration into complex measurement programs such as LabView.

Command overview as PDF

Practical use

It may be best if you look at the> 500 lines of the complete sketch on a second screen and get an overview of the command handler. I like it if I have clearly delimited functions that can be tested separately and not again - e.g. after 12 months - request the incorporation into the whole project again if I want to improve or change something. That is why I use a lot of global variables.

WiFi, MQTTEN separately can be switched off/ switched off separately

The functions for the WLAN connection and MQTT can now be switched on and off. What should that be good for? Imagine you have learned to appreciate the TDMM and don't want to miss it anymore.

Then you may want to use it out of the house or in a place that has no connection to your WLAN and MQTT server. They switch it on - it is looking for and searches and searches for the WiFi. You cannot use the device because it is looking for the WiFi in an endless loop.

Sure: You can limit the process so that it only searches for 10 times for the WLAN and then switches off WLAN and MQTT. You are welcome to implement it like this. Here I recorded two separate commands for this, so that the TDMM is available to me shortly after switching on.

I made MQTT "switchable" separately because I plan an implementation without MQTT for applications in which the TDMM delivers a small website.

CA command: Calibrate electricity measurement

The electricity measurement has been busy in the past. The sensitivity of the measurement procedure compared to disturbing magnetic fields can make it appear functional to calibrate the current measurement from time to time.

In my measurement programs I always do this at the beginning. To do this, please connect the two sockets for electricity measurement, so that no electricity is certainly flowing. Then enter "ca". The comparison process can be observed via the serial monitor.

I noticed that the comparison after a warm -up period of approx. 30 minutes is always worth it. For me, the zero comparison "is concreted".

Save values ​​permanently

The library belongs to the basic stock and does not need to be imported. My personal experience in using the D1 Mini V3 is that the Library the Board Manager Generic ESP8266 modules needs. It may be that other board managers for the D1 Mini V3 also work perfectly. With this you can be sure that it works. I placed badly with other board managers.

The knowledge cost me hours. You always look for the mistake in your own code or in thinking. But it wasn't like that this time.

All values ​​that you want to put in the EEPROM put them in a data object with the name eepromvars. The reason for this is convenience.

EEPROM.H uses a memory area of ​​the D1 Mini V3, from which I can use the instruction Eeprom.Begin(128) narrow 128 Byte reserved. If you look at function descriptions and examples for this library, you will see that byte you secure the data for bytes. So you should know exactly which variable how many bytes occupies. From this you calculate the next free space and save the following variable there. This can also be called "memory organization on foot" - and it is actually tedious.

You can also go the following way:

•   According to estimate the memory requirement, reserve the necessary bytes.

•   Pack all data in a single data object

•   Save this object starting at storage space 0

•   If necessary, get the property back at the storage space 0.

In fact, despite the extensive sketch and the many libraries, we have a lot of memory. Therefore, this procedure is easy. You can even “pack” data objects - but this is also not necessary in our case.

The data object EEPROMVARS

Our data object takes the float-Variables Lu, Li, LP and mi on. They are limits for tension, electricity and performance. "Mi" is the new variable "measuring interval". This adapts the measuring interval to the actual need. In some cases you may let it run a little slower, sometimes much faster. This allows you to optimally set up the time sequence of the measurements.

struct{           // eeprom-variable

  float lu;

  float Li;

  float LP;

  float mi;

  intimately Concount;

  intimately Wificount;

  Bool Luswitch;

  Bool Liswitch;

  Bool LPSWitch;

}eepromvars;

Then they follow int-Variable "Concount" and "Wificount". "Concount" determines how many attempts at MQTT should be made,  "Wificount" provides the requirement for the number of WiFi connection attempts.

The three following boolVariables tell the system which limits are set.

To address the variables, the name of the object is used together with the variable name, e.g.   eepromvars.luswitch = true;    

If you want and enjoy it, you can save even more variables in the EEPROMVARS object. How about the WIFI and MQTT credentials? Or the settings for further measuring functions?

Download complete sketch

Conclusion

You have got to know a small measuring device that has now proven itself in practice and serves well in practice.  It can be supplemented quite easily by new functions, or also by external sensors, e.g. for the temperature. So you can implement the load test for a power supply with just a few additional components.

I am particularly happy about the practical suitability that could be achieved. The device can no longer think away from my daily work, also in the repair café, or in electronics development.

As always, I am grateful for all questions, ideas, suggestions etc.!

Have fun replica
Your Michael Klein