Web-based smart home with Perl XS
At some point, it became very lazy to tear off his fifth point in order to turn off the lights in the room before going to bed. And I decided to automate this business. As a result, a bicycle was invented for remote control of the power load - a software and hardware system with the following features:
* Ability to control the power load, powered by a voltage of 220V, from any place where there is access to the Internet, regardless of the territorial distance.
* Management of power load through the website
* Client-server architecture
* Access to the website of the system from mobile devices, including via cell phones with WAP support
* Using the widespread physical layer RS232 protocol for connecting the hardware component of the system with a computer.
* The hardware component is based on the microcontroller PIC micro. (PIC18F452 in dip-package).
Those. thanks to such a simple thing, it becomes possible to control _ any devices (albeit only at the “on-off” level), be it a kettle, an iron, a TV, a refrigerator, lights in a room, etc., with Internet access. You can manage with _lyublyu_ device that has Internet access and html / wap-browser - mobile phone, iPhone, iPad, laptop, computer, TV and other devices. I implemented my “smart home” in PHP (client), Perl (server), C (server, low-level functions library), assembler (mpasm, microcontroller firmware).
The system access options are as follows:
1) web site for stationary and mobile devices user with html support
2) wap-version of the site to provide access to the system from mobile devices that support WAP.
3) telnet access for console access to the system
')
And now - the general structure of the system:
Consider in detail the levels of implementation of the system:
1) The highest (client) level - is the entry point to the system for users. The website (see picture below) and its wap version, running under the CMSBuilder content management system (CMS) written in Perl, in conjunction with MySQL + Apache, accept user requests from both computer and mobile devices.
2) At the middle (server) level, there is a daemon, which is a multiprocess tcp server with pre-branching, also written in Perl. The interaction with the highest level is carried out using its own application protocol. A library of low-level functions written in C is intended for communication with the lowest physical level. The library is connected to the daemon via the perlxstut tool, which allows you to connect libraries written in C to the Perl applications. The C library used at this level implements work with the rs232 ports of the computer using the standard library termios.h.
3) The lowest (hardware) level (see the picture below, drawn in Proteus) is implemented on the PIC18F452 microcontroller, which is connected to the computer via the rs232 interface. The control of the connected load is carried out by switching the power lines with a voltage of 220V through a relay connected to the microcontroller through a transistor.
Here is how the device looks live (without rs232 cord and relay):
It works only under * nix. Archive with all necessary can be downloaded from here . To use, you need to build an APM (makefile attached), run prefork_pipe.pl (by default it will listen on port 8080 to receive load control commands via a socket). Understands the WRITE [value] and READ commands. (the value is written immediately to the 8-bit port, i.e. it is possible to control only all eight tracks simultaneously). The client part in the archive - in PHP. If you want to use the module from a site in PHP - connect apm.inc, an example of using in index.php. To implement interaction with devices that have a WAP-browser, the wap.php file is intended. In Web.pm, the Perl implementation of the system interaction protocol of the read / write command) on the server side. As you can see, nothing complicated. In reality, the client part is implemented as modules for a CMS written in Perl.
Perhaps someone will seem a serious disadvantage of the need to have a constantly turned on computer to control the equipment via the Internet. But no one bothers to use a miniature raspberry pi. Or adapt the router with Linux.
The second drawback you can see is the need for an rs232 port. But this problem is easily solved by purchasing a usb-rs232 adapter. Or you can buy a microcontroller with USB hardware peripherals. For example, for about 1500 rubles you can buy a ready-made kit, which includes a debug board with a pic18f14k50 microcontroller (built-in usb on board) and a PicKit2 in-circuit programmer / debugger:
- already unsoldered usb ports, com-port + prototyping field + one more such board, unsoldered. The package includes, among other things, a laboratory work with a library that implements the USB CDC class (what it is - see below) - i.e. quite often you can repair your smart home. <br
And do not be afraid of USB in terms of programming - nothing complicated here. The fact is that in general there are cases when it is necessary to climb into USB at a low level (write drivers, operate with end points from the MK side), etc. happen very rarely. For most needs, there are ready-made USB classes that allow you not to delve into the work of USB at a low level, not to write drivers, but to immediately solve the problem you need. In this case, such a class is CDC - from the microcontroller's side you use a ready-made library that implements this class, and operate with functions of working with a com-port. On the computer side, you see a virtual com port in the system. Thus, you continue to work with rs232, although the actual interaction is conducted via USB.
Speech recognition and synthesis
There is another way to implement interaction with the system, except to press the buttons of the cellular / computer and other device with access to the network — you can implement speech recognition to receive commands, and synthesis to get a response. For example, say "wife, turn off the iron" - the system for the keyword "wife" understands that the command will now follow. After receiving the command, a request to the microcontroller to control one (or all) channels from the relay, followed by a voice confirmation of execution (speech synthesis).
There are three ways of implementation:
1) Used to connect to the Internet and computer. The most popular solution is to use the API from Google - when recognizing speech, we record sound from a microphone into a file, recode it into flac, send it to Google, get a text response - parse it and give the command to the microcontroller. When speech synthesis text is sent to Google, we get a response with mp3-data, output to the speaker. You can read more here: habrahabr.ru/blogs/hardware/129936
2) Local speech recognition and synthesis, without the Internet, but again with a computer. For speech synthesis, the festival is often used ( Russian language pack for it ), for recognition - the Sphrinx voice engine with support for recognition of Russian speech
3) There are still solutions for embedded systems, without using an external computer for speech recognition and synthesis. An example of this is the HM2007 speech recognition chip (alas, already taken off the market). In short, we close her leg, set the code to which the team will be assigned, say the command, open the leg, and so on for each team. Then when we use it, if the microcircuit recognizes the command we are talking about, it sets the binary code corresponding to it at the output. For robotics - the most it. There is also a Microchip library for dsPIC30F - Microchip Speech Recognition Library. Minus - such single-chip solutions are bad friends with the Russian language. It is necessary to give commands in the English-language manner.
With the help of the solutions described above, it is quite realistic to modify the example from pic18f452 given in the article, implementing the commercial solution described on habrahabr.ru/blogs/startup/128656 (controlling the equipment through the IR channel with voice) —and if in an industrial version (home sapiens) if the load is not directly controlled (only via IR adapters), here we are able to directly interact with the load and save our hard-earned money. The only pity is that you do not create a solution that can say “Wife, fulfill marital debt” and get the desired result. So you have to remain a monk in the world. :)
PS Something has recently become lazy to go to the toilet. Here's how to automate this business ... :-)
* Ability to control the power load, powered by a voltage of 220V, from any place where there is access to the Internet, regardless of the territorial distance.
* Management of power load through the website
* Client-server architecture
* Access to the website of the system from mobile devices, including via cell phones with WAP support
* Using the widespread physical layer RS232 protocol for connecting the hardware component of the system with a computer.
* The hardware component is based on the microcontroller PIC micro. (PIC18F452 in dip-package).
Those. thanks to such a simple thing, it becomes possible to control _ any devices (albeit only at the “on-off” level), be it a kettle, an iron, a TV, a refrigerator, lights in a room, etc., with Internet access. You can manage with _lyublyu_ device that has Internet access and html / wap-browser - mobile phone, iPhone, iPad, laptop, computer, TV and other devices. I implemented my “smart home” in PHP (client), Perl (server), C (server, low-level functions library), assembler (mpasm, microcontroller firmware).
The system access options are as follows:
1) web site for stationary and mobile devices user with html support
2) wap-version of the site to provide access to the system from mobile devices that support WAP.
3) telnet access for console access to the system
')
And now - the general structure of the system:
Consider in detail the levels of implementation of the system:
1) The highest (client) level - is the entry point to the system for users. The website (see picture below) and its wap version, running under the CMSBuilder content management system (CMS) written in Perl, in conjunction with MySQL + Apache, accept user requests from both computer and mobile devices.
2) At the middle (server) level, there is a daemon, which is a multiprocess tcp server with pre-branching, also written in Perl. The interaction with the highest level is carried out using its own application protocol. A library of low-level functions written in C is intended for communication with the lowest physical level. The library is connected to the daemon via the perlxstut tool, which allows you to connect libraries written in C to the Perl applications. The C library used at this level implements work with the rs232 ports of the computer using the standard library termios.h.
3) The lowest (hardware) level (see the picture below, drawn in Proteus) is implemented on the PIC18F452 microcontroller, which is connected to the computer via the rs232 interface. The control of the connected load is carried out by switching the power lines with a voltage of 220V through a relay connected to the microcontroller through a transistor.
Here is how the device looks live (without rs232 cord and relay):
It works only under * nix. Archive with all necessary can be downloaded from here . To use, you need to build an APM (makefile attached), run prefork_pipe.pl (by default it will listen on port 8080 to receive load control commands via a socket). Understands the WRITE [value] and READ commands. (the value is written immediately to the 8-bit port, i.e. it is possible to control only all eight tracks simultaneously). The client part in the archive - in PHP. If you want to use the module from a site in PHP - connect apm.inc, an example of using in index.php. To implement interaction with devices that have a WAP-browser, the wap.php file is intended. In Web.pm, the Perl implementation of the system interaction protocol of the read / write command) on the server side. As you can see, nothing complicated. In reality, the client part is implemented as modules for a CMS written in Perl.
Perhaps someone will seem a serious disadvantage of the need to have a constantly turned on computer to control the equipment via the Internet. But no one bothers to use a miniature raspberry pi. Or adapt the router with Linux.
The second drawback you can see is the need for an rs232 port. But this problem is easily solved by purchasing a usb-rs232 adapter. Or you can buy a microcontroller with USB hardware peripherals. For example, for about 1500 rubles you can buy a ready-made kit, which includes a debug board with a pic18f14k50 microcontroller (built-in usb on board) and a PicKit2 in-circuit programmer / debugger:
- already unsoldered usb ports, com-port + prototyping field + one more such board, unsoldered. The package includes, among other things, a laboratory work with a library that implements the USB CDC class (what it is - see below) - i.e. quite often you can repair your smart home. <br
And do not be afraid of USB in terms of programming - nothing complicated here. The fact is that in general there are cases when it is necessary to climb into USB at a low level (write drivers, operate with end points from the MK side), etc. happen very rarely. For most needs, there are ready-made USB classes that allow you not to delve into the work of USB at a low level, not to write drivers, but to immediately solve the problem you need. In this case, such a class is CDC - from the microcontroller's side you use a ready-made library that implements this class, and operate with functions of working with a com-port. On the computer side, you see a virtual com port in the system. Thus, you continue to work with rs232, although the actual interaction is conducted via USB.
Speech recognition and synthesis
There is another way to implement interaction with the system, except to press the buttons of the cellular / computer and other device with access to the network — you can implement speech recognition to receive commands, and synthesis to get a response. For example, say "wife, turn off the iron" - the system for the keyword "wife" understands that the command will now follow. After receiving the command, a request to the microcontroller to control one (or all) channels from the relay, followed by a voice confirmation of execution (speech synthesis).
There are three ways of implementation:
1) Used to connect to the Internet and computer. The most popular solution is to use the API from Google - when recognizing speech, we record sound from a microphone into a file, recode it into flac, send it to Google, get a text response - parse it and give the command to the microcontroller. When speech synthesis text is sent to Google, we get a response with mp3-data, output to the speaker. You can read more here: habrahabr.ru/blogs/hardware/129936
2) Local speech recognition and synthesis, without the Internet, but again with a computer. For speech synthesis, the festival is often used ( Russian language pack for it ), for recognition - the Sphrinx voice engine with support for recognition of Russian speech
3) There are still solutions for embedded systems, without using an external computer for speech recognition and synthesis. An example of this is the HM2007 speech recognition chip (alas, already taken off the market). In short, we close her leg, set the code to which the team will be assigned, say the command, open the leg, and so on for each team. Then when we use it, if the microcircuit recognizes the command we are talking about, it sets the binary code corresponding to it at the output. For robotics - the most it. There is also a Microchip library for dsPIC30F - Microchip Speech Recognition Library. Minus - such single-chip solutions are bad friends with the Russian language. It is necessary to give commands in the English-language manner.
With the help of the solutions described above, it is quite realistic to modify the example from pic18f452 given in the article, implementing the commercial solution described on habrahabr.ru/blogs/startup/128656 (controlling the equipment through the IR channel with voice) —and if in an industrial version (home sapiens) if the load is not directly controlled (only via IR adapters), here we are able to directly interact with the load and save our hard-earned money. The only pity is that you do not create a solution that can say “Wife, fulfill marital debt” and get the desired result. So you have to remain a monk in the world. :)
PS Something has recently become lazy to go to the toilet. Here's how to automate this business ... :-)
Source: https://habr.com/ru/post/137726/
All Articles