Using Onion Omega2 to create Linux and Wi-Fi devices

    Recently, I often face the challenge of making this or that DIY device with Wi-Fi. I considered different options for single-board computers and microcontrollers, on the basis of which it is better to do it, and as a result, Onion Omega2 became my favorite.



    Now I’ll tell you why I like her so much, and show with an example how to use it. As usual, this will be in the form of a traditional text article, and through video.


    Video




    Article


    Why Omega2


    To begin with, let's consider what tools are available on the market to easily add Wi-Fi to our DIY device. Especially if this device is part of a smart home.

    Very many are likely to say right away - Raspberry Pi. And yes, this is a full-fledged single-board computer, very powerful and with video output. And it is ideal for some complex tasks that require large computing power and the ability to connect a TV / monitor. For example, on its basis you can make a video player or game console, but for simple tasks like managing smart home devices it is too cumbersome and expensive. It's like shooting a gun at sparrows. Of course, there is also the Raspberry Pi Zero model, which is positioned as small and ultra-cheap, but so far they are still quite expensive to install in each switch and kettle.

    The other extreme - ESP8266. This is a very popular Wi-Fi microcontroller that costs less than two dollars. And this is really a very worthy solution, which will be enough for many tasks. But often the opposite is often too primitive, because it is necessary to write the firmware for it, Linux is no longer there, and separate libraries are used to work with peripherals and the network stack.

    I loved Onion Omega2is the golden mean. This is a single-board computer based on an MIPS processor with Linux, Wi-Fi, Ethernet, UART, PWM, I2C, SPI, USB, and of course GPIO. Initially, the manufacturer announced a price of $ 5, but with all the additional costs and shipping for the end user, such a thing so far costs somewhere around 9-10 dollars, it will probably become cheaper in the future. There is a slightly more expensive version with an SD card slot, but believe me, 16 megabytes of internal memory is enough for most everyday tasks. Another version for surface mounting has been announced, which is likely to be even cheaper, even smaller and have even more conclusions. But I already bought myself a whole box of regular omega, because at this price, you can safely stick Linux and Wi-Fi into each switch.

    As usual, many will ask me - why? Why am I suddenly not happy with the ultra-cheap ESP8266, and how did it happen that I suddenly stooped to something so high-level?

    Yes, it’s commonplace in the ease of use and maintenance. If we talk about a smart home, then this is not just controlling the iron via the Internet, it is a set of devices that work together on the same network and respond to each other's events. At the same time, programming is an integral part of using a smart home, because devices need to be periodically explained what is required in which case. And Linux in this regard greatly facilitates the task, it takes on the whole headache with multitasking and scheduled tasks, while Linux is a huge base of already familiar software. Here you have a full-fledged web server, and Perl, and PHP, and Ruby, and various network utilities, thanks to which you do not need to reinvent the wheel, and with which you can easily change the behavior of the device in real time, without recompilation.

    Disadvantages of Omega2


    I will not dissemble, Omega2 has enough shortcomings in comparison with classic wired solutions and microcontrollers.

    First of all, this is of course nutrition. This thing can consume up to 500 milliamps and it’s not too warm to bask. And if all my old smart home was powered by one power supply, then here we already need a separate unit for each device.

    Secondly, Linux does very poorly with real-time tasks. If you need to work with signals lasting in microseconds, you will have to write a kernel module, or even connect an additional microcontroller.

    Thirdly, Omega does not have an ADC, that is, there are no analog inputs, and this is very necessary when working with analog sensors. This problem is solved by connecting an external ADC or, again, by connecting a penny microcontroller, especially under Linux, there is software for their firmware, which completely eliminates the need to use a programmer.

    The fourth drawback is characteristic of all Wi-Fi devices, and not just Omega. This is a lack of decentralization. Using Wi-Fi implies that the whole system has one weak point - a Wi-Fi router, without it, devices lose contact with each other. But in fact, absolutely in any configuration there is such a weak link. I have here before, as I said, everything was powered by one power supply. And the whole smart house died when my uninterruptible power supply unit broke. And it should be noted that Omega2 constantly works as a Wi-Fi access point. Therefore, even with the complete absence of a router, you can always connect to a device, for example, from a phone. In addition, in any case, it is important to make devices with the expectation and work without a network.

    I don’t know what else to dig, but you can probably say about the boot time. Omega2 loads for a long time and gets in touch. This is absolutely unimportant for devices that work around the clock, but can be a problem for devices that plug into the outlet only occasionally.

    Use in practice


    I was ordered to make a device that should simply automatically open the entrance door when calling the intercom, while having the ability to configure remotely via the Internet. The fact is that the customer periodically rents his apartment through one site, while being in another city. And he needs so that on the day of check-in, a person can get into the porch, and there already take the key from a special box. Let's try to do this based on Omega2.

    The task for me is not entirely new. I already made an intercom with an answering machine , which can not only pick up the phone, but also respond with messages recorded on the SD card, plus write messages from those who came to the same SD card. In fact, you just need to simplify this scheme (you do not need an answering machine) and use Omega2 instead of ATMEGA64.

    The principle of operation of intercoms is very simple. When the handset hangs, its speaker is directly connected to the interphone network, respectively, the handset has a resistance of about 50 ohms. When the handset is picked up, its resistance rises somewhere to a kilo-ohm and changes slightly when we speak into the microphone, thus transmitting sound. And finally, when we press the door open button, the resistance of the tube grows even stronger.

    Accordingly, from the hardware point of view, we need:

    * The first is to determine the moment when someone calls the intercom. This is done easily, only at this moment voltage appears in the line. To determine the presence of voltage, you can use a transistor. As soon as at least a tiny current flows through its base, it will open and close one of the legs of the omega on the ground;
    * Second - after a while, pick up the phone, increasing the resistance of the device. To do this, you can use a trivial relay. It is bulky, they click, but very reliable. Resistance is better made adaptable, because for different manufacturers of intercoms this value may be slightly different;
    * Third - after some time, increase the resistance of the device even more, again, it can be done through a relay.

    Everything is quite simple. Do not forget to add such trifles as a button, a pair of LEDs to display the current mode, and a piezodynamic speaker to make sounds.

    It is worth noting that not all Omega2 pins can be used in GPIO mode.

    Its flash memory is connected via SPI, so these pins can only be used to connect SPI devices. If you hang anything else there, it is likely to prevent Omega2 from loading. In addition, pins 1, 12, and 45 should not be pulled either to ground or to power during device startup.

    As a result, I got such a board here:



    And such a device: We



    connect power to breathe life into it, and Omega immediately starts loading.

    Soon you will see a new Wi-Fi point called Onion + the last four digits of the MAC address. We are connected to it, the default password is “12345678”.

    Inside this interface, Omega has a default IP address of 192.168.3.1, connect to it via SSH, log in as root using the password “onioneer”, and first of all, configure the connection to the Wi-Fi point. For this, the “wifisetup” script is preinstalled there.

    If everything was done correctly, through ifconfig it will be possible to see the IP address that the router issued to Omega. Now you can disconnect from the access point of the omega itself and connect to it already at this IP address using a regular network, because now it is part of my home network.

    Log in again via SSH and check that Omega now has an Internet connection.



    The first step is to update the firmware using the oupgrade command. This is especially true in the light of recently discovered vulnerabilities in the Wi-Fi protocol.

    All software is installed from the repository using "opkg". The web server is already there, I will need more PHP:

    opkg update
    opkg install php7 php7-cgi php7-cli

    You need to remember to configure the web server in this case, in omega uhttpd is used:

    vi /etc/config/uhttpd

    Add to the main section:

    list interpreter ".php=/usr/bin/php-cgi"
    option index_page 'index.php'

    Yes, Omega2 firmware is based on OpenWRT firmware, so many tools are inherited from there. The configuration is edited and stored using the UCI - Unified Configuration Interface . This is something like a simple database, which is optimized to reduce the number of overwrites of flash-memory. For my purposes, I will use it myself.

    As for the management of peripherals and GPIO, it is quite easy to do directly from the command line. Omega already has several utilities pre-installed for this.

    First of all, it is worth paying attention to the fact that many outputs have several functions, the “omega2-ctrl” utility is used to switch between them.



    The direction of the output and the value of the output can be changed using the utilities “gpioctl” or the faster “fast-gpio”. You can also manage them through pseudo files on Linux, which is a more versatile and portable method.

    I decided to write the code directly on bash scripts, it is Linux after all. The task is quite simple: if a number of conditions are met, then we expect a call to the intercom and open the door after a specified period of time, respond to button presses in the manner specified in the settings, blink LEDs, make sounds if necessary ...

    It was then that I suddenly had a problem. To generate sound, I decided to use PWM. However, the software PWM that Omega utilities provide is highly unstable. Although it works at the core level, its timings float strongly, which is clearly noticeable by ear. Too noticeable, so you can’t leave it.

    However, Omega2 seems to have declared hardware PWM. It can be seen in the utility for switching the operation mode of the pins, it is in the documentation for the processor that is used in Omega, but there is no way to work with it. Apparently, the developers have not done them yet. Well, we will do it ourselves! The same processor documentation describes the registers for working with PWM.



    There are many of them, the local PWM is very flexible in configuration. Here you can even set arbitrary wave generation sequences.

    As a result, I wrote a native C program that works directly with these registers and generates a wave of a given frequency and duty cycle, using hardware PWM. I posted the source code for this utility on GitHub: github.com/ClusterM/omega2-pwm
    So use it if someone needs it. The sound eventually began to be produced without defects.

    It remains only to make a web interface so that the customer can easily configure and manage devices from any browser. Web technology is my weakness, here I am 20 years behind life, so there will be one more govnokod. As I said, I don’t bother and use PHP in conjunction with JavaScript. I don’t know how to do design, and I don’t need this one here, so I copied it impudently from the Luci interface from OpenWRT.



    Here is such a simple admin panel. Firstly, here you can watch and add intervals when our intercom will automatically open. On the same page, you can import the schedule from the “ical” file. Yes, I forgot to say right away that this was one of the requirements of the customer. The fact is that on the site where this person is renting an apartment, you can export the schedule or get it from the link. As a result, the customer will not even need to enter it with his hands in the device settings, it will be filled in from the site where he rents the apartment. Of course, you must not forget to configure the periodic execution of this script through cron.

    Even in the admin panel, you can change various settings - whether to make sounds, how quickly you need to open the door, how to respond to a button press, and of course change the password for the admin panel.

    On a separate tab, you can see the logs where all actions will be recorded. Of course, there is a tab with Wi-Fi settings. Here you can see which access points are nearby and connect to the selected one.



    It is understood that when you turn on the device for the first time, the customer will connect to the device, for example, from a smartphone, go to the admin panel and configure its connection to the router.

    I also made a tab in the admin panel where you can write an arbitrary script that will be executed when someone calls the intercom. The customer did not ask for this, and it is not particularly necessary for the average user, but this way you can perform any action at all when calling the intercom. For example, especially with the curl utility. So, for example, you can send push notifications to your phone. You can write your own program for the smartphone for this, but I prefer to use the pushover.net service (not advertising). For the customer, I already wrote a script template, he only had to substitute his keys, which you get on the service website. So he can almost instantly recognize if someone called the intercom.



    At this point, everything is ready. It remains only to print the case on a 3D printer.



    It looks somewhat cunning, but it performs its functionality perfectly.

    But the development did not end there. What happened was what I was most afraid of. I checked everything on my intercom, but it didn’t work at the customer’s intercom anymore. He is there from another company and apparently works a little differently. The problem was that the device thought that someone was ringing the intercom when this did not actually happen. At the same time, the customer lives far away, I could not come and see. However, I said that Linux greatly facilitates the maintenance of the device. The customer forwarded me the SSH port on the router, I connected remotely and figured out what was the matter. Just in the intercom line he had short-term interference, which can be easily filtered by finalizing the script. It is only necessary to respond if the signal in the line is present for some time. It’s great that it can be so easily corrected.

    Conclusion


    I hope that with this simple example I showed how convenient Omega2 is and how Linux makes the task easier when creating such devices. If you like the article, I will continue to talk about how I use Omega2, and I will try to do it in more detail. I still have many projects with her, both simpler and more complex.

    Also popular now: