December 8, 2014 at 16:06Simple interface to smart home with nooLite
A few months ago, I installed a “smart house” at home based on the components of the Belarusian “Nootechnics”, which were written about many times over at Habré and Giktims . Strictly speaking, I did not consider it precisely as a smart home - but first of all as convenient: it began with the desire to get control of lamps from different places of the apartment without overhaul of wiring, and at the same time make sectional switching on for those lamps to which one pair of wires has now been passed .
If you look through publications on this topic, they basically come down to three things: “how I installed the first switch”, “how I write a super-sophisticated interface with plugins and my own scripting language” and “how I set up full automation so that I don’t see more switches at all ".
Alas, none of them gave me anything of practical value: besides the fact that the last two categories are usually in an eternal work-in-progress state, I don’t believe in meaningful automation of light in a city apartment (there’s nothing more to automate here), but I also do not want my own scripting language. I want a system that, once installed, would allow me and other people to conveniently control the light in the apartment, if possible without lifting the ass from the chair and without requiring any special knowledge. And not only turn on and off, but, for example, change the function of a particular button.
In general, I did it.
But first things first.
The reasons for choosing nooLite are quite typical: relatively inexpensive, simple, with a guarantee and generally support - if necessary - there should be no problems. The rather plain-looking design of the switches doesn’t scare me at all - it’s more important for me to be comfortable than beautiful, and here nooLite has a couple of advantages, which are described below. The unambiguous advantage of the relatively cheaper Chinese was the presence of wall switches on their own - I do not really imagine how to use a remote control again lost somewhere in the apartment instead of wall switches.
The main drawback - and present not only in nooLite - turned out to be that for any change in the functioning of the system it is necessary to climb up to the ceiling. For example, I wanted to change the function of the button on the switch - remove the chandelier, pick out the power unit from under the stretch ceiling, start it in the binding mode, change the function.
The second drawback is that the buttons on the switches quickly ran out, although nooLite has three on each. For example, a room. It has a table lamp, sconce, chandelier with two sections. These are already four buttons. Oops
Fortunately, nooLite has such beautiful, albeit very expensive, things like a USB receiver and a USB transmitter. When looking at this couple, a simple, but at the same time wise thought was not long in coming: after all, you can wrap up all the communication of circuit breakers with power units through a server, which will determine what exactly to do when receiving a signal from a button such and such. We want to change the function of this button - we climb onto the server and change it programmatically. We want to make some complicated logic for the button - we climb onto the server and write it. We want blackjack and women of easy virtue - well, you understand.
Here it should be noted that nooLite has its own device called “Ethernet Gateway”, but it can do a little more than nothing - show temperature from sensors (thanks, I have three weather stations) and turn power units on and off via the web.
Theoretically, the aforementioned systems with plugins and scripts solve this, but in practice they are overly sophisticated and without installation it is usually impossible to understand whether they will help, on the contrary, to do simple but desired things. In general, I sat down and did exactly what I needed myself. No claim to extensibility, customization, and so on.
It turned out something like this:
As a result, for example, the setting of a particular chandelier looks like this for me: the first press of a button - 2 of 5 lamps turn on; second press - the remaining 3 lamps turn on; third press - all lamps go out. Long press with all the lights off - all 5 are turned on at once; long press with 2 or 5 on - all lamps go out. That is, full control of a two-section chandelier with just one button of the remote control.
Disclaimer:
Theoretically, at the time of my purchase of the nooLite package, there were already unofficial drivers for it, which I hoped to use: when receiving a command, the receiver driver kicks the PHP script, and the driver kicks the transmitter driver in accordance with its internal logic.
These hopes did not last long - before the first personal acquaintance with the drivers: they turned out to be not so much drivers as a technological demonstration, which in principle nooLite can work under Linux. Inside, there was a lot of everything, from direct typos and errors (for example, an attempt to untie one channel of the receiver banged its entire configuration) to things like a wget called directly into the call code, which was supposed to kick the PHP script. It was possible to use them, but to love oneself for this is unlikely.
As a result, the Linux software package was rewritten (GitHub ) and got the following:
A skeleton is assembled from nooliterx and noolitepcd, in which it remains only to add logic that connects the output of the first with the input of the second. This logic is made in PHP ( GitHub ) - for two reasons: firstly, the ease of modernization on a living patient, and secondly, the ease of screwing the web interface. Although I don’t see the latter as the main means of controlling the light in the house (it’s usually easier to reach the switch than a smartphone), but it’s convenient to have it.
Finally, a smartphone application. It seemed ugly to me just to keep a link to the IP of the router where all this stuff lives (all the more so since IP can be an unstable thing), so I launched avahi-daemon on the router, screaming “they drive light here!” on the entire network, and on a smartphone riveted an application from WebView and Network Service Discovery ( GitHub), which according to these cries determines the desired IP and displays it. A separate compact web interface has been made for smartphones, of course, without beautiful pictures.
So which of the languages we have not yet counted? Oh yes, Javascript. On Javascript, the configuration of lamps and switches in the web-face has been made.
Everything can be done in it: add a switch (by the channel number of the receiver to which it is attached), hang lamps on it, determine what it can do with them. Everything is stored in the switch.xml file, which you can edit with your hands if you wish (and in the first version it was just about done, but somehow my appearance did not satisfy me).
In the next tab, you can register the existing bulbs (according to the channel numbers of the transmitter) and drag them according to the layout of your apartment, putting them in the right places (to remove the bulb from the apartment layout - pull it out of the picture). In addition to light bulbs, there is a device type “Other” - it differs only in the icon. Lamps are stored in lamps.xml.
Binding of power blocks and switches to the receiver and transmitter is done right there. Of course, it needs physical access to the blocks - but this binding is done once before installing a new block and never touches: it does not affect which switches the block can control.
Since all lamp control passes through the server, then theoretically - with the exception of the case when, due to interference, the command did not reach the lamp - he knows the current state of all controlled lamps in the apartment. It is stored in the SQLite-database lamps.db, when you first start the interface will prompt you to create it by filling it with zeros.
In case of communication failures - alas, nooLite is not safe from them, since it does not have feedback and confirmation of the reception of the command - it will be enough to flip the cycle with the switch button until the base and the real lamp are “synchronized” (in the simplest case, the “switching” command : 1) the lamp is on, the shutdown command has not reached it, the lamp remains on, it appears in the database as off; 2) the second press - the lamp received a command to turn on, continued to shine, while in the database it also appears as turned on).
To build under OpenWRT (a link to the finished package for AR71xx and OpenWRT 12.09 will be lower) you need the OpenWRT toolchain deployed somewhere on a large PC. In it, after standard preparation, you need to take the Makefile from here and put it in the package / noolite / folder inside the tool chain, and then make make package / noolite / compile . If today is your day, and GitHub is not banned by Roskomnadzor, then everything will gather and be in the bin / folder/ packages / as a ready-to-install package.
Of the third-party not-so-standard packages, libusb1 is needed for operation and libusb1-dev for assembly.
Install it on the router (opkg install <package>), then copy the noolite file to /etc/init.d/ of this router and make /etc/init.d/noolite enable - now the utilities will start when the router boots. In / etc / create the noolite.conf file and write to it:
The first is the command that the receiver daemon will call when it receives something; in this case, from the received one, it transfers the channel number and the command number (it is different for different types of buttons on the remote control and short or long press), but in principle it can transmit anything from the standard nooLite information in any order. The codes are in the documentation in the / doc of the project. The second is a timeout during which the program waits for something after a request to the receiver; does not play a fundamental role in society.
If you do not create a config or specify the -i option on the command line, then the nooliterx utility will output the data it receives to the console in a formatted format for human reading - this is convenient for debugging.
If you put the system under x86, then the assembly is ./configure && make && make install.
For the web-muzzle you need a web server with PHP support, for example, under OpenWRT (with all the necessary set) this is opkg install lighttpd lighttpd-mod-cgi php5 php5-cgi php5-mod-simplexml php5-mod-xml php5-mod-sqlite3 coreutils-timeout . If the router’s memory allows you to leave your native packages in place, it’s convenient to reconfigure the original web server to some type 8080 port, and hang the light control to the standard one: 80, in order to save LuCI and not interfere with cutlets with flies.
Then it remains to deploy the archive with the web interface in the right place, if you wish, open the admin / index.php file and change the username and password from admin / admin to something else (or turn off authorization altogether). Authorization is done at a very primitive level and only to the admin panel - so that your family and friends do not accidentally crash the light in the apartment by pressing a button.
Yes, if you still crash something - each time you save XML files, the old version is copied to a file with the .bak extension. So you can roll back the changes one step back, but only from the console - by renaming the file back.
When you first enter the web face, the system will offer you to create an empty database - do not refuse it. There are already XML files in it, they are for an example of what the finished configuration looks like - after looking, erase all the bulbs and switches from it and set your own. Do the same with the picture of the apartment plan.
The final touch is an Android app. In order for it to find where the lights are turned on here, put the avahi-daemon package on OpenWRT, go to / etc / avahi / services and create an http.service file of such content there (the application will find the IP of the router by the name of the service):
If Avahi then rests on startup and swears at the lack of DBus, then in /etc/avahi/avahi-daemon.conf you can add the line enable-dbus = no to the [server] section.
After months of using nooLite, I can’t, of course, not share my pain. First, of course, the lack of feedback: yes, it happens that the team left the switch and did not come anywhere. Infrequently, but it happens. Secondly, in addition to the lack of protection of the transmitted, the noolight is generally not very good at checking the integrity of the data: it happens that one team left and another came and the wrong lamp turned on. Quite rarely, but it happens. Finally, the switch sends several copies of the command to the air for confidence - and sometimes the receiver manages to accept them as two consecutive commands (to combat this, nooliterx has a restriction: the command is ignored if it arrived less than 300 ms after the previous one).
Unfortunately, I have not yet seen a system that satisfies me in price and aesthetics and is devoid of these shortcomings. Yes, the classic on Z-Wave is good, but the cost of Z-Wave's equipment for the entire apartment, even with a dollar of 35 rubles, was shaking.
From the pluses: it was found that the nondescriptness of the nooLite switches is redeemed by their functionality. You can do, for example, like this:
The remote control is inserted into the standard frame of the W59 Schneider Electric series of sockets (there is actually no socket under the remote, there is a wall right there), and instead of the native gray substrate, the remote control has a laminated print of its own, which indicates that which button turns off.
Advice:
If you look through publications on this topic, they basically come down to three things: “how I installed the first switch”, “how I write a super-sophisticated interface with plugins and my own scripting language” and “how I set up full automation so that I don’t see more switches at all ".
Alas, none of them gave me anything of practical value: besides the fact that the last two categories are usually in an eternal work-in-progress state, I don’t believe in meaningful automation of light in a city apartment (there’s nothing more to automate here), but I also do not want my own scripting language. I want a system that, once installed, would allow me and other people to conveniently control the light in the apartment, if possible without lifting the ass from the chair and without requiring any special knowledge. And not only turn on and off, but, for example, change the function of a particular button.
In general, I did it.
But first things first.
The reasons for choosing nooLite are quite typical: relatively inexpensive, simple, with a guarantee and generally support - if necessary - there should be no problems. The rather plain-looking design of the switches doesn’t scare me at all - it’s more important for me to be comfortable than beautiful, and here nooLite has a couple of advantages, which are described below. The unambiguous advantage of the relatively cheaper Chinese was the presence of wall switches on their own - I do not really imagine how to use a remote control again lost somewhere in the apartment instead of wall switches.
The main drawback - and present not only in nooLite - turned out to be that for any change in the functioning of the system it is necessary to climb up to the ceiling. For example, I wanted to change the function of the button on the switch - remove the chandelier, pick out the power unit from under the stretch ceiling, start it in the binding mode, change the function.
The second drawback is that the buttons on the switches quickly ran out, although nooLite has three on each. For example, a room. It has a table lamp, sconce, chandelier with two sections. These are already four buttons. Oops
Fortunately, nooLite has such beautiful, albeit very expensive, things like a USB receiver and a USB transmitter. When looking at this couple, a simple, but at the same time wise thought was not long in coming: after all, you can wrap up all the communication of circuit breakers with power units through a server, which will determine what exactly to do when receiving a signal from a button such and such. We want to change the function of this button - we climb onto the server and change it programmatically. We want to make some complicated logic for the button - we climb onto the server and write it. We want blackjack and women of easy virtue - well, you understand.
Here it should be noted that nooLite has its own device called “Ethernet Gateway”, but it can do a little more than nothing - show temperature from sensors (thanks, I have three weather stations) and turn power units on and off via the web.
Theoretically, the aforementioned systems with plugins and scripts solve this, but in practice they are overly sophisticated and without installation it is usually impossible to understand whether they will help, on the contrary, to do simple but desired things. In general, I sat down and did exactly what I needed myself. No claim to extensibility, customization, and so on.
It turned out something like this:
- Work on x86 under Linux and on routers with OpenWRT
- Work with standard nooLite receiver and transmitter
- Binding and decoupling of power blocks and switches via the web interface
- Possibility to hang as many lamps as you like on one switch
- Standard Features - Turning On, Off, and Switching Lamps
- Additional functions: sequential inclusion of several lamps by successive pressing of one button (convenient for multi-section chandeliers), switching on by chain (previous lamp goes out), managing a group of lamps (if all are off, turn on everything, if at least one is on, turn off all) lamps in the house at once
- Separate functions for short and long press of the switch button
- Configure all lamps, switches and the interaction between them from the web interface
- Display in the web interface of the current state of the lamps (see the picture at the beginning of the note)
- Android app
As a result, for example, the setting of a particular chandelier looks like this for me: the first press of a button - 2 of 5 lamps turn on; second press - the remaining 3 lamps turn on; third press - all lamps go out. Long press with all the lights off - all 5 are turned on at once; long press with 2 or 5 on - all lamps go out. That is, full control of a two-section chandelier with just one button of the remote control.
Disclaimer:
- I was not going to make this system supported, extensible, and so on - I have absolutely no reason for it. This is a self-contained system that solves a specific problem.
- I am not a programmer. Neither in C, nor in Javascript, nor in Java, nor in PHP (all four will be encountered later)
- The system did not do those things that I did not need (there are only the beginnings of working with dimmers, there is nothing about the schedule, there is nothing about the no-light sensors). Most likely, I will never do them, so if you need them, it will be faster to do it yourself
- All code is licensed under WTFPL
Theoretically, at the time of my purchase of the nooLite package, there were already unofficial drivers for it, which I hoped to use: when receiving a command, the receiver driver kicks the PHP script, and the driver kicks the transmitter driver in accordance with its internal logic.
These hopes did not last long - before the first personal acquaintance with the drivers: they turned out to be not so much drivers as a technological demonstration, which in principle nooLite can work under Linux. Inside, there was a lot of everything, from direct typos and errors (for example, an attempt to untie one channel of the receiver banged its entire configuration) to things like a wget called directly into the call code, which was supposed to kick the PHP script. It was possible to use them, but to love oneself for this is unlikely.
As a result, the Linux software package was rewritten (GitHub ) and got the following:
- Nooliterx receiver: the command to be executed is set in the configuration file or command line, there is a daemon mode, there is a UNIX socket through which this daemon listens to the remote control binding-decoupling commands
- Noolitepc transmitter: commands combed, bugs fixed
- Noolitepcd transmitter: if noolitepc is a console utility, then this is a daemon that accepts commands through a UNIX socket. This not only works faster, but also allows you to build an elementary queue of commands with automatic delay between them, since the nooLite transmitter chokes faster than once every 400 ms when it is pushed into it
- Nooliterxcfg transmitter configurator: console utility for binding-untying remotes. Actually no longer needed - this can be done via the web interface and nooliterx with its socket
A skeleton is assembled from nooliterx and noolitepcd, in which it remains only to add logic that connects the output of the first with the input of the second. This logic is made in PHP ( GitHub ) - for two reasons: firstly, the ease of modernization on a living patient, and secondly, the ease of screwing the web interface. Although I don’t see the latter as the main means of controlling the light in the house (it’s usually easier to reach the switch than a smartphone), but it’s convenient to have it.
Finally, a smartphone application. It seemed ugly to me just to keep a link to the IP of the router where all this stuff lives (all the more so since IP can be an unstable thing), so I launched avahi-daemon on the router, screaming “they drive light here!” on the entire network, and on a smartphone riveted an application from WebView and Network Service Discovery ( GitHub), which according to these cries determines the desired IP and displays it. A separate compact web interface has been made for smartphones, of course, without beautiful pictures.
So which of the languages we have not yet counted? Oh yes, Javascript. On Javascript, the configuration of lamps and switches in the web-face has been made.
Everything can be done in it: add a switch (by the channel number of the receiver to which it is attached), hang lamps on it, determine what it can do with them. Everything is stored in the switch.xml file, which you can edit with your hands if you wish (and in the first version it was just about done, but somehow my appearance did not satisfy me).
In the next tab, you can register the existing bulbs (according to the channel numbers of the transmitter) and drag them according to the layout of your apartment, putting them in the right places (to remove the bulb from the apartment layout - pull it out of the picture). In addition to light bulbs, there is a device type “Other” - it differs only in the icon. Lamps are stored in lamps.xml.
Binding of power blocks and switches to the receiver and transmitter is done right there. Of course, it needs physical access to the blocks - but this binding is done once before installing a new block and never touches: it does not affect which switches the block can control.
Since all lamp control passes through the server, then theoretically - with the exception of the case when, due to interference, the command did not reach the lamp - he knows the current state of all controlled lamps in the apartment. It is stored in the SQLite-database lamps.db, when you first start the interface will prompt you to create it by filling it with zeros.
In case of communication failures - alas, nooLite is not safe from them, since it does not have feedback and confirmation of the reception of the command - it will be enough to flip the cycle with the switch button until the base and the real lamp are “synchronized” (in the simplest case, the “switching” command : 1) the lamp is on, the shutdown command has not reached it, the lamp remains on, it appears in the database as off; 2) the second press - the lamp received a command to turn on, continued to shine, while in the database it also appears as turned on).
Installation
To build under OpenWRT (a link to the finished package for AR71xx and OpenWRT 12.09 will be lower) you need the OpenWRT toolchain deployed somewhere on a large PC. In it, after standard preparation, you need to take the Makefile from here and put it in the package / noolite / folder inside the tool chain, and then make make package / noolite / compile . If today is your day, and GitHub is not banned by Roskomnadzor, then everything will gather and be in the bin / folder
Of the third-party not-so-standard packages, libusb1 is needed for operation and libusb1-dev for assembly.
Install it on the router (opkg install <package>), then copy the noolite file to /etc/init.d/ of this router and make /etc/init.d/noolite enable - now the utilities will start when the router boots. In / etc / create the noolite.conf file and write to it:
command = wget -q -T 5 "http://localhost/lampcontrol.php?channel=%ch&command=%cm" -O /dev/null &
timeout = 250
The first is the command that the receiver daemon will call when it receives something; in this case, from the received one, it transfers the channel number and the command number (it is different for different types of buttons on the remote control and short or long press), but in principle it can transmit anything from the standard nooLite information in any order. The codes are in the documentation in the / doc of the project. The second is a timeout during which the program waits for something after a request to the receiver; does not play a fundamental role in society.
If you do not create a config or specify the -i option on the command line, then the nooliterx utility will output the data it receives to the console in a formatted format for human reading - this is convenient for debugging.
If you put the system under x86, then the assembly is ./configure && make && make install.
For the web-muzzle you need a web server with PHP support, for example, under OpenWRT (with all the necessary set) this is opkg install lighttpd lighttpd-mod-cgi php5 php5-cgi php5-mod-simplexml php5-mod-xml php5-mod-sqlite3 coreutils-timeout . If the router’s memory allows you to leave your native packages in place, it’s convenient to reconfigure the original web server to some type 8080 port, and hang the light control to the standard one: 80, in order to save LuCI and not interfere with cutlets with flies.
Then it remains to deploy the archive with the web interface in the right place, if you wish, open the admin / index.php file and change the username and password from admin / admin to something else (or turn off authorization altogether). Authorization is done at a very primitive level and only to the admin panel - so that your family and friends do not accidentally crash the light in the apartment by pressing a button.
Yes, if you still crash something - each time you save XML files, the old version is copied to a file with the .bak extension. So you can roll back the changes one step back, but only from the console - by renaming the file back.
When you first enter the web face, the system will offer you to create an empty database - do not refuse it. There are already XML files in it, they are for an example of what the finished configuration looks like - after looking, erase all the bulbs and switches from it and set your own. Do the same with the picture of the apartment plan.
The final touch is an Android app. In order for it to find where the lights are turned on here, put the avahi-daemon package on OpenWRT, go to / etc / avahi / services and create an http.service file of such content there (the application will find the IP of the router by the name of the service):
Homelight server _http._tcp 80 path=/ If Avahi then rests on startup and swears at the lack of DBus, then in /etc/avahi/avahi-daemon.conf you can add the line enable-dbus = no to the [server] section.
Lyrical digression about nooLite
After months of using nooLite, I can’t, of course, not share my pain. First, of course, the lack of feedback: yes, it happens that the team left the switch and did not come anywhere. Infrequently, but it happens. Secondly, in addition to the lack of protection of the transmitted, the noolight is generally not very good at checking the integrity of the data: it happens that one team left and another came and the wrong lamp turned on. Quite rarely, but it happens. Finally, the switch sends several copies of the command to the air for confidence - and sometimes the receiver manages to accept them as two consecutive commands (to combat this, nooliterx has a restriction: the command is ignored if it arrived less than 300 ms after the previous one).
Unfortunately, I have not yet seen a system that satisfies me in price and aesthetics and is devoid of these shortcomings. Yes, the classic on Z-Wave is good, but the cost of Z-Wave's equipment for the entire apartment, even with a dollar of 35 rubles, was shaking.
From the pluses: it was found that the nondescriptness of the nooLite switches is redeemed by their functionality. You can do, for example, like this:
The remote control is inserted into the standard frame of the W59 Schneider Electric series of sockets (there is actually no socket under the remote, there is a wall right there), and instead of the native gray substrate, the remote control has a laminated print of its own, which indicates that which button turns off.
Advice:
- The reliability of the operation of power units is highly dependent on the antennas. The antenna should ideally be flattened and directed perpendicular to the direction of the transmitter. Native antennas are made from soft wire, the easiest way is to provide them with sufficient rigidity by wearing a cocktail straw.
- Do not place the antennas closer than 5-10 cm from the CFL socles and LED lamps - their pulsed power supplies provide noticeable interference. A characteristic symptom is that the unit turns on from the first, and turns off from the fifth to tenth time.
- I exchanged the antennas on the USB receiver and transmitter for hard pins made of copper wire 165 mm long.
- The signal level of the USB transmitter is higher than that of wall-mounted remote controls, so wherever the wall-mounted remote control triggered two times a third, it can work stably with a USB transmitter.
- A router is a single point of light failure in your house (well, in addition to the dashboard on the stairs and the transformer in the next block). Buy two or three spare panels and tie the main power blocks directly to them so that you can turn on the required minimum of light without a router.
