Key points or what this article is about
We continue the series of articles about ShIoTiny - a visually programmable controller based on a chip ESP8266.
This article describes, using the example of a ventilation control project in a bathroom or other room with high humidity, how a program is built for ShIoTiny.
Previous articles in the series.
references
Introduction
There is no understanding without experience. This is the truth, tested by time and generations. Therefore, there is nothing better for learning practical skills than trying to do something on your own. And examples that show what can be done and what should not be tried will come in handy here. Other people's mistakes, of course, will not be able to prevent the occurrence of their own mistakes, but they can help reduce the number of the latter.
Questions and letters from readers of previous articles prompted me to make a small ventilation control example project to show how ShIoTiny nodes work.
The initial idea behind the controller ShIoTiny - pumping and watering station - far from suitable for everyone and will be interesting. Therefore, I took an understandable and useful ventilation control system as an example for everyone.
I will say that the idea of ββthe project is not mine, but and then adapted to ShIoTiny.
First understand what you want
The process of improvement is endless. And it is this property that has ruined many good ideas and projects. The developer, instead of releasing, if not ideal, but a working thing, continued to improve it. And he improved until competitors bypassed him, releasing, albeit not an ideal (and often frankly wretched), but working solution.
Therefore, it is very important to know where to put an end to the project. Or, in other words, we need to determine what we want to get at the end of the project from what we have at the beginning. In Russian, for a document that is compiled just to describe the path of creating something, there is a wonderful short and capacious word βplanβ, which for some reason mentally retarded translators and defective managers have recently begun to call βroad mapβ. Well, God be with them.
Our plan will be like this. Let's assume that there is a room in which the humidity can rise greatly from time to time. For example, such as a bathroom or kitchen. Humidity is an unpleasant thing and the way to deal with it is as old as the world: to ventilate the room. There are many ways to ventilate. But we will probably abandon exotic and old-fashioned ways like Negroes with fans and stop at an ordinary fan. Fans are cheaper, and it's easier to find them in our area.
In a word, we want to control the fan: turn it on and, accordingly, turn it off. More precisely, we want it to turn on and off when necessary.
It remains to determine: under what conditions the fan should turn on and under what conditions it should turn off.
Everything is obvious here: if the humidity is above a certain specified limit, the fan turns on and draws air; humidity returned to normal - the fan turns off.
An attentive reader will immediately catch his eye on the word "given". Given by whom? How given?
There are several ways to set the threshold humidity. We will look at two of them: the first - using variable resistance and the second - over the network using the MQTT protocol. Each of these methods has advantages and disadvantages, which will be discussed later.
For those who do not understand, I will explain that the βthreshold humidityβ is the level of humidity, above which the fan must be turned on.
The next question is whether to give the user the right to turn on the fan directly? That is, regardless of the level of humidity, at the touch of a button? We will foresee such an opportunity. After all, a fan may be needed not only at high humidity, but also to remove from the room, for example, an unpleasant smell, popularly referred to as βstinkβ.
So, we understood what we want and even a little how it will work. We list briefly all the functions of our ventilation control system:
- setting the threshold level of humidity (two options);
- humidity level measurement;
- automatic turning on of the fan;
- automatic fan shutdown;
- manual turning on of the fan (at the push of a button).
So the plan is clear. It is necessary to implement all of the above functions in our program. Based on this "plan" and we will act. First, let's draw a block diagram of the device.
Structural diagram of the device
Generally speaking, we will have two such schemes. The first one is for the variant in which the threshold humidity level is set by a variable resistance. The second scheme is for the option in which the threshold humidity level is set over the network via the MQTT protocol.
But since these circuits will differ by only one element - a variable resistor "setting the threshold humidity level", then we will draw only one block diagram. Of course, the block diagram according to GOST looks different. But we focus not on bison-engineers, but on the younger generation. Therefore visibility is more important.
So what do we see in the picture? Fan connected to relay Relay1 the controller ShIoTiny. I draw your attention to the fact that the fan is a contraption that lives under high voltage. Therefore, if someone will do this himself - be careful. That is, at a minimum, before sticking your fingers or measuring instruments into the circuit, de-energize at least the fan. And the second remark. If your fan is more powerful than 250Vt, then connect it directly to ShIoTiny not worth it - only through the starter.
Done with the fan. Now the button "manual inclusion" of the fan. It is connected to the input Input1. There is nothing more to explain here.
Temperature and humidity sensor DHT-11 (or DHT-22 or their equivalents). A special input on the controller is provided for its connection. ShIoTiny. As you can see in the figure, connecting such a sensor also does not present problems.
And finally, a variable resistance that sets the threshold level of humidity. More precisely, a divider consisting of variable and constant resistances. There are no problems with its connection, but I will explain that the built-in ADC on ESP8266 rated at 1 volt. Therefore, a voltage divider of about 5 times is needed.
And let me remind you once again that this divider is not needed if the threshold humidity level is set over the network using the MQTT protocol.
Let's start compiling the device operation algorithm in the ElDraw ShIoTiny editor. How to get there, to this editor, you can read in the articles earlier or in the instructions, a link to which is at the beginning of the article.
Option one, the simplest
Let's start simple: turning on the relay Relay1 by exceeding the threshold level of humidity for a given time.
As you can see, nothing complicated: only four nodes, not counting the comment nodes. DHT11 - this is actually a temperature and humidity sensor (can be changed to DHT22).
Constant CONST β threshold level of humidity, in percent.
A comparator is a node that compares two numbers and sets the output to 1 if the specified condition is met and 0 if the condition is not met.
In our case, this condition will be A>BWhere A is the humidity level measured by the sensor, and B - the threshold level of the same humidity.
As soon as the measured humidity level (A) will exceed the threshold humidity level (B), immediately at the output of the comparator A>B 1 will appear and the relay will turn on. Conversely, as soon as the humidity level returns to normal (i.e. A<=B), immediately at the output of the comparator A>B 0 will appear and the relay will turn off.
All clear? For those who donβt really read it again or look at the description of the operation of the nodes in the instructions.
Note that the data from the sensor DHT11 updated approximately once every 10 seconds. Therefore, the relay will not be able to turn on and off more often than once every 10 seconds.
Everything would be fine, but we would like to set the threshold level of humidity using a variable resistor. There is nothing easier!
Let's just replace the constant node with an ADC node. After all, we connected a voltage divider with a variable resistor to the ADC.
The voltage at the ADC input varies from 0 to 1V. But the humidity at the output of the sensor - varies from 0 to 100%. How do we compare them? Everything is simple. ADC node in ShIoTiny not only measures the voltage at the input, but also knows how to scale and move.
That is, the output of the ADC1 node (ADC) will have the value X, calculated by the formula
Where - voltage at the ADC input (from 0 to 1V); k - range (ADC range) and b-offset (ADC offset). Thus, if you set k = 100 ΠΈ b = 0, then when changing in the range from 0 to 1, value X at the output of the ADC node will vary in the range from 0 to 100. That is, numerically equal to the range of humidity changes from 0 to 100%.
Or, in a simple way, by rotating the variable resistance slider, you can set the threshold humidity level from 0 to 100. The only inconvenience is that there are no display devices. But in practice, if the variable resistance engine has 6 divisions 0%, 20%, 40%, 60%, 80%, 100%), then this is enough to set the threshold humidity level.
How do we set the odds k - range (ADC range) and b-offset (ADC offset)? Yes, itβs easier than a steamed turnip! Click the mouse pointer on the node ADC1 and then you will see the settings window. You can put everything you need in it. For our case, it will be such a window as in the figure.
So, we have the simplest working solution. Let's start improving it.
By the way, the simplest solution has one advantage - it does not need the Internet. It is completely autonomous.
Option two, connect the button
Everything works and everyone is happy. But bad luck, we can not turn on the ventilation forcibly. We have already agreed that the entrance Input1 we will have a button connected that will turn the fan on and off forcibly, ignoring the humidity sensor.
It's time to process this button in our schematic program.
The button click processing block is highlighted with an orange line. It is a counter of button presses, which is reset to zero when the value at its output exceeds one (green line, node output CT).
Everything works here as uncomplicated as before: the counter CT counts the presses of the button connected to the input Input1. That is, the value at the output of this counter increases by 1 with each press of the button.
As soon as this value becomes equal to two (that is, more than 1), immediately at the output of the comparator A>B 1 will appear. And this 1 will reset the counter CT to zero. This means the comparator, the lower one according to the diagram!
Thus, our button has two states - 0 and 1. If we needed more states (3 or 4 or even more) - it would be enough for us to change the constant CONST from one to another value.
So, we have two conditions for turning on the fan: exceeding the set humidity level and pressing the button once. If any of the conditions are met, the fan will turn on. And it will work until the button is pressed again. Π humidity level will not return to normal.
You can, of course, complicate the algorithm even more, but we will not do this - we will leave room for creativity to those who wish.
Option three, connect to the Internet
Everything that we have described is quite efficient. But what about ponies? After all, any pimply hipster cracker hacker will laugh at someone who turns the knob and presses the button, and does not control from a smartphone! Turning the handle is "not fashionable." But crawling with a finger on a smartphone, erasing this finger in the blood - here it is, the peak of desires of a hipster-hacker-cracker (I could never distinguish all of them - so if I made a mistake, I'm sorry).
But let's be indulgent to these individuals. There are real advantages to managing via the Internet. First, it is visibility. There are a lot of applications for all platforms that allow you to create a completely usable control panel for our Carlson controller with a couple of clicks. Secondly, it is the ability to remotely monitor the state of humidity in the room. And, thirdly, you can see not only what the fan is doing - spinning or not, but also what threshold level of humidity is set. And then - the fan turned on automatically or manually. In general, whatever you want.
Of course, for some fan a lot of honor - so much attention. But this is just an example.
So, to connect to the Internet, we will use the technology MQTT and the protocol of the same name.
To use this technology, we need MQTT Broker. This is such a special server that serves MQTT clientsEg ShIoTIny and your smartphone.
The essence of technology MQTT consists in the fact that any of the clients publishes arbitrary data on the MQTT broker (server) under a certain name (called topical in terminology MQTT). Other clients can subscribe to arbitrary data by name (topical) and receive newly published data. That is, all data exchange is based on the client-broker-client principle.
Π― I will not focus on the details. There are a lot of articles and tutorials on the Internet on how it works. MQTT and what are the programs for creating control panels. Just show us how to accept and publish data through ShIoTiny.
As a broker I used but the principle is the same everywhere.
So, we will assume that you have registered on MQTT broker. In general, the broker will give you (or require you to come up with) a username and password (for authorization), as well as a connection port. To plug ShIoTiny ΠΊ MQTT broker can be done in two ways - normal connection and TLS (SSL).
All these parameters in ShIoTiny entered on tab Networking, section MQTT Connection to server.
If your MQTT Broker does not require authorization - do not enter a login and password (leave these fields empty).
Parameter MQTT topic prefix requires a separate explanation.
The MQTT options prefix is ββa string added to the topic name (topical) when publishing and subscribing on an MQTT broker. to install MQTT prefix for your controller, you just need to enter it in the input field "MQTT topic prefix'('MQTT topic prefix"). The prefix always starts with a slash ("/")! If you do not enter a slash in the input field, it will be added automatically. Symbols cannot be used in the prefix "#" ΠΈ "+". There are no other restrictions.
For example, if you publish the parameter "status" (or subscribe to it) and your prefix is ββset to "/shiotiny/β, then this parameter will be published on the broker under the name β/shiotiny/status". If you have an empty prefix set, then all parameters on the broker will start with a slash ("/"): "status' will be published as '/statusΒ».
So, we assume that you have registered on MQTT broker and received login, password and port. Then you have written these parameters on the tab Networking, section MQTT Connection to server the controller ShIoTiny.
We assume that the prefix is ββset to "/room/Β».
Let's start by publishing the status of all key parameters: relay Realay1, manual on states, auto on states, and finally threshold and current humidity levels. Well, a bonus - the temperature in the room. How to do this, see the picture.
As you can see, the difference from the previous version is only the nodes "MQTT Publish". Given the prefix, the following parameters are published:
As you can see, we have the entire state of the system at a glance!
But we want not only to see, but also to manage. How to be? Very simple. We will opt out of setting the humidity threshold with ADC and a variable resistor and we will set this very threshold level of humidity according to MQTT directly from your smartphone!
We remove the ADC node from the circuit and include three new nodes there: flash store, FLASH restore ΠΈ MQTT describe.
Node function MQTT describe is obvious: it receives a parameter /room/trigHset (threshold humidity level) with MQTT broker. But what does it do with the data next? Just gives them to the node flash store, which in turn stores this data in non-volatile memory under the name trigH. After that, node FLASH restore reads data from non-volatile memory under the name trigH and what happens next we already know.
Why such difficulties? Why is it impossible to immediately give the received data to the input of the comparator?
As Comrade Sh. Holmes used to say - it's elementary! No one guarantees that after turning on your device, it will join MQTT broker. Humidity needs to be measured. And the fan must be turned on. But without information about the threshold level of humidity, this is impossible! Therefore, our device, when turned on, retrieves the previously stored threshold humidity level from non-volatile memory and uses it to make decisions. And when a connection is established with MQTT broker and someone will post a new value /room/trigHset, then that new value will be used.
Then you can come up with whatever you want. For example, in addition to humidity, also introduce temperature accounting. Or add "smart" lighting control (we still have two relays and two inputs left unused). All in your hands!
Conclusion
So we looked at several examples of the implementation of the simplest controller based on ShIoTiny. Maybe it will be useful to someone.
As always, suggestions, wishes, questions, typos, etc. β by mail: [email protected]
Source: habr.com