Get best of the week

~ SMAK ~ - programmable controllers for smart homesteads using the asyncio library on MicroPython


Preamble


The use of the Internet of things in rural areas is much wider than home automation, although this, of course, is a matter of terminology - what is meant by this. Nevertheless, I conceived the concept of Smart Homestead as a project of rational automation of processes occurring at objects located on the territory of my estate, and sometimes at a decent distance from where I am at one time or another, but at the same time I want to at least be sufficiently confident that what is happening at these objects will not go beyond the boundaries of what is permitted, that I can, if necessary, quickly get an idea of ​​the situation on the estate as a whole and at each controlled object in particular, as well as In your essay, to intervene in the processes are not rushing headlong, to the object that caused my concern,because at this moment I’m busy with something important, or simply banally cold and too lazy to leave the house.

At the same time, the implementation of this concept will allow me to deepen my understanding of the use of microcontrollers using the capabilities of MicroPython, which I just like with its illusion of lightness compared to C ++, in which I heroically carried out projects of varying complexity in past lives, as well as implement algorithms, up to which either did not reach hands, or they have not yet been embodied in libraries in high-level languages. This, in fact, determined my interest precisely in my own implementation, without resorting to widespread solutions ranging from well-known manufacturers of the same Xiaomy to specialized applications such as EspHome or frameworks. Although I do not exclude the possibility that, having run through a large and thorny circle of my own design, stuffed with bumps and corns, pretty plucked but certainly not defeated, I will exhale,I’ll spend my hard-earned money on beautifully packaged and designed devices of foreign and Russian production at a very market price and implement the experience gained in existing cloudy and not so monsters like MiHime, Domoticz, IFTT or something else.

Summarizing - I wanted to take pleasure in the invention of the bicycle, when for this there was, finally, time before the summer suffering, when it was no longer easy to do, but there was no time to think, while servicing my estate. I wrote this in order to understand for myself exactly what I want, but in order to give myself the right in advance not to respond to comments that may suggest existing and obviously more comprehensive solutions. Although algorithms for solving a particular problem related to the implementation of the plan are very welcome.


General approach


The processes occurring at the objects are controlled by programmable controllers, which are expedient to develop for solving local problems, combining them later in a hierarchy, if necessary, by forming wireless connections. Local tasks are solved where it is possible to provide a wired connection or short radio connections with sensors and actuators, using the simplest protocols for exchanging information. The spatial solution consists in the fact that the maximum decision-making burden falls on the controller that controls the leaves of the oriented graph in the form of sensors and devices, which, at the same time, has the ability to send summary information in packaged form to the node of this wireless graph that requested such information.On the Internet, on a phone or other device, it’s enough for me to see a blank screen, which means that everything is working as usual, but the ability to request details and, in an emergency, intervene in the actions of the final controller should belong to me as the Creator of this space. Security issues and protection from external influences are postponed until later.

The controller itself can already have more powerful communication channels and use more advanced protocols such as MQTT or ZigBee to organize a stable mesh network graph with subsequent access to the Internet.

Currently, the concept is limited by the logic of the programmable controller, taking into account the possibility of its inclusion in a swarm, or, in other words, in a group connected by wireless connections. The scope of the controller is an object subject to control and management, by no means a complete list of which I give below:

  • Greenhouse - temperature, lighting, soil and air humidity
  • Garden - watering, soil moisture
  • Incubator - temperature, humidity, tray rotation, sound
  • Bruder - temperature, humidity and lighting
  • Coop - temperature, lighting
  • Beehive - temperature, humidity, weight and sound (swarm)
  • – , ,
  • – ,
  • – ,
  • – ,
  • – ,
  • – ( ) (, )
  • –
  • —

To describe, research and solve the problem, a metalanguage has been developed that allows us to briefly describe the device drivers used as sources and consumers, delays associated with the processing of information, communication channels through which this information passes, schedules and timers for generating cyclic actions, variables, which contains information essential for the control and management of processes occurring at the facility.

In this part, the metalanguage allows you to read the description of the project in a readable form, which will be useful for generating documentation as well as a list of hardware devices and logic expressed in printed circuit boards on which or to which these hardware devices must be connected.

In the second part, the metalanguage presents the primitives by which the process is controlled and which are used in the initialization and subsequent analysis of the state of processes controlled by the controller. If there are sufficient resources for the microcontrollers used, this part can be implemented as an interpreter, the input of which is fed with text files describing the initialization of drivers, communication channels, variables and the script itself, which describes the logic of the controller and does not require changing the sewing if the scenario is clarified.

As you call an idea, that’s how it will float, therefore Smart Manor is a Smart Homestead, the birthplace of an idea is Altai, however, Automation is also suitable, although it is a kind of tautology in this context to the definition of Smart and, of course, by means of which using a programmable Controller . Combining the uppercase letters and mixing the English and Russian words, it turned out - ~ SMAK ~ , but the Meta Language of the System Description, respectively, ~ MEAT ~ . This culinary concept came out - the application ~ SMAK ~ using ~ MEAT ~ . By the way, the primitive wireless protocol for the interaction of the controller and devices that are not endowed with their own protocols in advance, I called ~ JuJu ~ .

The hardware implementation is conceived using the capabilities of ESP8266 and Arduino with RF24 + or other, more modern, but no less cheap - for sensors and actuators - relays, valves, switches, etc., if they cannot be connected directly for any reason, the logic itself try to place the controller on ESP32, and if it fails, on STM32. The goal is to minimize iron costs. I admit the use of hardware implementation of a number of processes such as temperature controllers with hysteresis or air quality measuring instruments, but since I'm not an electronics engineer, developing a circuit using capacitors, resistances and transistors is painful for me and this determines a reasonable balance between hardware and software implementation, and also a desire for direct participation,or at least the contemplation of what is happening in the controller.

The software implementation is based on the syntax of the metalanguage ~ MEAT ~ , the asyncio library and related algorithms, the general logic ~ SMAK ~ described below. The task of controlling the processes occurring at the facility is aimed at maintaining certain operating conditions, as well as to restore these conditions in the event of deviations, moreover, with a stronger deviation, more energetic actions can be used, as well as a response to emergency situations.

In the future, the following terminology will be used in the text:

Sources (Source) - sensors, incoming communication channels
Consumers - executive devices, outgoing communication channels

The interaction of Sources and Consumers is described in the Scenario by analyzing the values ​​received from the sources; status of timers and consumers; values ​​of variables; schedules, on the basis of which control commands are issued to consumers.

The source register is used to store the latest data obtained as a result of a survey of sources, each of which can be interrogated with its own frequency. After updating the data of at least one of the sources, an analysis unit is launched to clarify the operating modes of consumers.

The consumer register is used to separate program and physical data in order to implement the mechanism of priority logic for script execution, which consists in the fact that in the process of analyzing the conditions described in the script, conflicting commands to the same device can be issued and the final command will be considered which was recorded last in the script. Thus, by forming a sequence of condition checks in the scenario of the operation of devices, their priority can be formed. Physically, the commands will be executed only after the end of the analysis unit.

Interrogation of sources and execution of commands by consumers takes place in asynchronous mode, that is, their drivers transfer control to the system planner in anticipation of the moment of inquiry or command, as well as in case of inertia of operation, during which the source or consumer is in a busy state and then subsequent requests are placed turn.

Depending on the type of device, the driver can use more than one information channel, for example, a DHT temperature and humidity sensor uses 2 channels to transmit temperature and humidity, and DS18B20 devices connected to a common bus to control the collector of the warm floor - even more, or an integrated servo drive, controlling several motors or valves at the same time.

Driver characteristics include a set of requests and commands specific to the device, the delay time for their execution, as well as the type of communication through which a signal is transmitted, which can be hardware (1Wire, I2C, SPI, UART, etc.) and wireless (WiFi, RF-radio, BT, etc.), which complements the methods for transmitting requests and commands. In addition, the driver provides self-diagnostic modes when it is loaded, actions when it is turned off, and diagnostics of unforeseen conditions during normal operation in asynchronous mode. The driver can run several asynchronous tasks, for example, if feedback on the status of the device is required.

From the analysis unit, you can access the registers of sources, consumers, timers and variables, system constants as well as the schedule. Ideally, the analysis unit is seen as an interpreter of a simple script description language, represented by a text file, but in the first versions, when writing a script in the firmware code, I will adhere to the basic primitives of this language to generate a more concise presentation of it. Currently, the script description language is used to simulate the operation of objects (incubator, brooder, chicken coop, apiary, greenhouse, garden, boiler room, hotel room), determine the required number of devices and their characteristics, which has already proved to be very useful.

Further in the plans is the publication of already accumulated and created:

  • ~ SMAK ~ - description of general functioning algorithms
  • ~ SMAK ~ - description of metalanguage ~ MEAT ~
  • ~ SMAK ~ - protocol description ~ JuJu ~
  • ~ SMAK ~ - description of requirements for creating device drivers in ~ SMAK ~
  • ~ SMAK ~ - application practice

Source: https://habr.com/ru/post/undefined/

More articles:


All Articles