Simple interface to smart home with nooLite
Some months ago, I put in my home a “smart home” based on the components of the Belarusian “Nootechnics”, which were written many times over in Habré and Hiktaims. Strictly speaking, I didn’t see it as a smart home - and first of all as a convenient one: it began with the desire to get control of lamps from different places of the apartment without wiring overhaul, and at the same time make sectional switching on for those lamps to which one pair of wires is now connected .
If you look through the publications on this topic, they basically boil down to three things: “how I installed the first switch”, “how I write a super-rich interface with plug-ins and my own scripting language” and “how I set up full automation so that more switches cannot be seen ".
Alas, none of them gave me practically nothing of value: besides the fact that the last two categories are usually in an eternal state of work-in-progress, I don’t believe in meaningful automation of light in a city apartment (there’s really nothing more to automate) I also don't want my own scripting language. I want a system that, once installed, would allow both 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 enable and disable, but also, for example, change the function of a particular button.
')
In general, I did it.
But first things first.
The reasons for choosing exactly nooLite are quite typical: relatively inexpensive, simple, with a guarantee and, in general, support - if required - no problems should arise. The rather inconspicuous design of the switches does not frighten me at all - it is more important for me that they are comfortable than beautiful, and here nooLite showed a couple of advantages, which are discussed below. An unambiguous advantage with respect to even cheaper Chinese is the presence of wall switches in and of themselves - I do not really know how to use the lost key fob in the apartment instead of wall switches.
But the main drawback - and not only present at nooLite - turned out to be that for any change in the functioning of the system it is necessary to climb to the ceiling. For example, I wanted to change the function of the button on the switch - remove the chandelier, pick out the power block from under the stretch ceiling, start it in the snap mode, change the function.
The second drawback is that the buttons on the switches quickly run out, although nooLite has three of them on each. Here, for example, a room. In her desk lamp, sconces, 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 is simple, but at the same time, a wise thought did not keep itself waiting: after all, you can also wrap all the communication of switches with power units through a server, which will determine what to do when receiving a signal from a button. We want to change the function of this button - we climb to 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.
It should be noted here that nooLite has its own device called “Ethernet gateway”, but it can do a little more than nothing - show the temperature from the sensors (thanks, I have three weather stations) and turn the power units on and off via the web.
Theoretically, the above-mentioned systems with plug-ins and scripts solve this, but in practice they are excessively sophisticated and, without installation, it is usually impossible to understand whether they will help to do simple, but desirable things for me. In general, I sat down and did exactly what I needed. No claims on extensibility, customizability, and so on.
It turned out like this:
As a result, for example, setting a specific chandelier looks like this for me: the first click of a button - 2 lamps of 5 turn on; second press - the remaining 3 lamps turn on; third press - all the lights go out. Long press with all lamps turned off - all 5 are switched on at once; long press with 2 or 5 turned on - all the lights go out. That is, the full control of a two-piece chandelier with just one button on the console.
Disclaimer:
Theoretically, at the time of my purchase of the nooLite set, there already existed unofficial drivers for it, which I hoped to use: when receiving a command, the PHP script driver kicks, and the transmitter driver kicks, consistent 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 technological demonstrations that, in principle, nooLite under Linux can work. Inside there was a lot of things, from direct typos and errors (for example, an attempt to untie a receiver’s channel banged all its configuration) to things like the wget call that was supposed to be kicked in a PHP script that was hammered into it. It was possible to use them, but it is unlikely to love yourself for it.
As a result, a set of software for Linux was rewritten ( GitHub ) and got the following:
From nooliterx and noolitepcd, a skeleton is assembled into which it remains only to add logic connecting the output of the first with the input of the second. This logic is made in PHP ( GitHub ) - for two reasons: first, the ease of upgrading on a live patient, and second, the ease of screwing the web interface. Though 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 the smartphone), but it’s convenient to have it.
Finally, a smartphone application. It seemed to me ugly to just keep a link to the IP of the router where all this good lives (especially since IP can be a fickle thing), so I launched avahi-daemon on the router, screaming “they rule here!” On the entire network, and on a smartphone riveted the application from WebView and Network Service Discovery ( GitHub ), which by these screams determines the desired IP and shows it. For smartphones, a separate compact web interface is made, of course, without beautiful images.
So, which of the languages we have not yet considered? And yes, Javascript. The configuration of lamps and switches in the web is made on Javascript.
You can do everything in it: add a switch (according to 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, if desired, can be ruled by hands (and in the first version something like this was done, but somehow I didn’t look good with this).
In the next tab, you can register the existing light bulbs (according to the numbers of the transmitter channels) and drag them out according to the scheme of your apartment, putting them in the right places (to remove the light bulb from the apartment scheme - pull it out of the picture). In addition to light bulbs, there is the “Other” device type - it differs only in the icon. Lamps are stored in lamps.xml.
The binding of power units and switches to the receiver and transmitter is done right there. Of course, it requires physical access to the blocks - but this binding is done once before installing a new block and never starts moving again: it does not affect which switches the block can control.
Since all lamp control passes through the server, then theoretically - except for the case when, due to interference, the team did not reach the lamp - he knows the current state of all controlled lamps in the apartment. It is stored in SQLite-base lamps.db, when you first start the interface will offer you to create it, filling it with zeros.
In case of communication failures - nooLite from them, unfortunately, is not insured, since it does not have feedback and confirm acceptance of the command - it is enough to click 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 to work, it appears in the database as off; 2) second press - the lamp received a command to turn on, continued to shine, while in the base it also appears as turned on).
To build under OpenWRT (the link to the finished package for AR71xx and OpenWRT 12.09 will be lower), you need an OpenWRT toolchain deployed somewhere on a large PC. In it, after the standard preparation, you need to take the Makefile from here and put it in the package / noolite / folder inside the toolchain, then make make package / noolite / compile . If today is your day, and GitHub is not banned by Roskomnadzor, then everything will come together and be in the bin / <arch> / packages / folder as a ready-to-install package.
From third-party not-too-standard packages, libusb1 is needed for operation and libusb1-dev for building.
Install it on the router (opkg install <package>), then copy the noolite file to /etc/init.d/ of this router and do /etc/init.d/noolite enable - now the utilities will start when the router is loaded. In / etc / create the file noolite.conf and write to it:
The first is the command that the receiver daemon will call when it receives something; in this case, it transmits the channel number and the command number from the received one (it is different for different types of buttons on the remotes and short or long press), but in principle can transmit anything from the standard nooLite information in any order. Codes are in the documentation in / doc project. The second is the timeout during which the program waits for something after a request to the receiver; does not play an important role in society.
If you do not create a config or specify the -i parameter on the command line, then the nooliterx utility will output the data it received to the console in a format that is readable by a human being — this is convenient for debugging.
If you install the system under x86, then the assembly is ./configure && make && make install.
For a 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 memory of the router allows you to leave your native packages in place, it is convenient to reconfigure its original web server to some port such as 8080, and hang the light control to standard: 80 to save LuCI and not interfere with the 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 login and password from admin / admin to something else (or disable authorization altogether). Authorization is done at a very primitive level and only on the admin panel - so that your relatives and friends, by pressing the button, do not accidentally bang the lights in the apartment.
Yes, if after all you bang something - each time you save the XML files, the old version is copied to a file with the .bak extension. So you can roll back one step back changes, but now only from the console - by renaming the file back.
When you first enter the web-muzzle, the system will offer you to create an empty database - do not refuse it. There are already XML files in it, for example of how the ready configuration looks like - after looking, erase all the lights and switches from it and set your own. Do the same with the flat picture.
The final touch is the Android app. To make it find where the lights are on, put the avahi-daemon package on OpenWRT, go to / etc / avahi / services and create the http.service file of such content (the application will find the IP router by the service name):
If further Avahi rests on startup and swears at the absence 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 the painful ones. First, of course, the lack of feedback: yes, it happens that the team left the switch and did not go anywhere. Infrequently, but it happens. Secondly, in addition to the lack of protection of the transmitted one, noolite is not very good at checking the integrity of the data: it happens that one team left and another one came and the wrong lamp was turned on. Very rare, but it happens. Finally, for certainty, the switch sends several copies of the command to the air - and sometimes the receiver manages to accept them as two consecutive commands (to combat this, a restriction is introduced in nooliterx: the command is ignored if it arrived less than 300 ms after the previous one).
Unfortunately, I haven’t 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 equipment for the entire apartment, even with a dollar of 35 rubles, drove into a shiver.
From the pros: it was found that the inconspicuousness of the nooLite switches is redeemed by their functionality. You can do, for example, like this:
The remote control here is inserted into the standard frame of the W59 Schneider Electric series sockets (there is no actual socket under the remote control, there is a wall right there), and the remote control itself has a laminated own print inserted instead of the native gray substrate, which indicates which button turns off.
Tips:
If you look through the publications on this topic, they basically boil down to three things: “how I installed the first switch”, “how I write a super-rich interface with plug-ins and my own scripting language” and “how I set up full automation so that more switches cannot be seen ".
Alas, none of them gave me practically nothing of value: besides the fact that the last two categories are usually in an eternal state of work-in-progress, I don’t believe in meaningful automation of light in a city apartment (there’s really nothing more to automate) I also don't want my own scripting language. I want a system that, once installed, would allow both 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 enable and disable, but also, for example, change the function of a particular button.
')
In general, I did it.
But first things first.
The reasons for choosing exactly nooLite are quite typical: relatively inexpensive, simple, with a guarantee and, in general, support - if required - no problems should arise. The rather inconspicuous design of the switches does not frighten me at all - it is more important for me that they are comfortable than beautiful, and here nooLite showed a couple of advantages, which are discussed below. An unambiguous advantage with respect to even cheaper Chinese is the presence of wall switches in and of themselves - I do not really know how to use the lost key fob in the apartment instead of wall switches.
But the main drawback - and not only present at nooLite - turned out to be that for any change in the functioning of the system it is necessary to climb to the ceiling. For example, I wanted to change the function of the button on the switch - remove the chandelier, pick out the power block from under the stretch ceiling, start it in the snap mode, change the function.
The second drawback is that the buttons on the switches quickly run out, although nooLite has three of them on each. Here, for example, a room. In her desk lamp, sconces, 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 is simple, but at the same time, a wise thought did not keep itself waiting: after all, you can also wrap all the communication of switches with power units through a server, which will determine what to do when receiving a signal from a button. We want to change the function of this button - we climb to 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.
It should be noted here that nooLite has its own device called “Ethernet gateway”, but it can do a little more than nothing - show the temperature from the sensors (thanks, I have three weather stations) and turn the power units on and off via the web.
Theoretically, the above-mentioned systems with plug-ins and scripts solve this, but in practice they are excessively sophisticated and, without installation, it is usually impossible to understand whether they will help to do simple, but desirable things for me. In general, I sat down and did exactly what I needed. No claims on extensibility, customizability, and so on.
It turned out like this:
- Work on x86 under Linux and on routers with OpenWRT
- Work with a standard nooLite receiver and transmitter
- Binding-uncoupling power units and switches through the web interface
- The ability to hang on a single switch as many lamps
- Standard features - turning on, turning off and switching lamps
- Additional functions: sequential switching on of several lamps with consecutive pressing of one button (convenient for multi-section chandeliers), switching on by chain (the previous lamp goes out), controlling a group of lamps (if all are off - turn on all, if at least one is turned on - turn off all), turning off all lamps in the house at once
- Separate functions for short and long pressing of the switch button
- Configure all lamps, switches and 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 application
As a result, for example, setting a specific chandelier looks like this for me: the first click of a button - 2 lamps of 5 turn on; second press - the remaining 3 lamps turn on; third press - all the lights go out. Long press with all lamps turned off - all 5 are switched on at once; long press with 2 or 5 turned on - all the lights go out. That is, the full control of a two-piece chandelier with just one button on the console.
Disclaimer:
- I was not going to make this system supported, expandable, and so on - I absolutely do not need it. It 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 found later)
- The system did not make those things that I did not need (there are only the beginnings of working with dimmers, there is nothing about schedules, there is nothing about Noolight sensors). Most likely, I will never make 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 set, there already existed unofficial drivers for it, which I hoped to use: when receiving a command, the PHP script driver kicks, and the transmitter driver kicks, consistent 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 technological demonstrations that, in principle, nooLite under Linux can work. Inside there was a lot of things, from direct typos and errors (for example, an attempt to untie a receiver’s channel banged all its configuration) to things like the wget call that was supposed to be kicked in a PHP script that was hammered into it. It was possible to use them, but it is unlikely to love yourself for it.
As a result, a set of software for Linux was rewritten ( GitHub ) and got the following:
- Receiver nooliterx: the command being executed is set in the configuration file or the command line, there is a daemon mode, there is a UNIX socket through which the daemon listens to the remote-binding commands
- Transmitter noolitepc: combed commands, fixed bugs
- Transmitter noolitepcd: 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 command queue with an automatic delay between them, since the nooLite transmitter sticks into the commands faster than once every 400 ms
- Nooliterxcfg transmitter configurator: console utility for binding and unlinking of consoles. In fact, no longer needed - this can be done through the web interface and nooliterx with its socket
From nooliterx and noolitepcd, a skeleton is assembled into which it remains only to add logic connecting the output of the first with the input of the second. This logic is made in PHP ( GitHub ) - for two reasons: first, the ease of upgrading on a live patient, and second, the ease of screwing the web interface. Though 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 the smartphone), but it’s convenient to have it.
Finally, a smartphone application. It seemed to me ugly to just keep a link to the IP of the router where all this good lives (especially since IP can be a fickle thing), so I launched avahi-daemon on the router, screaming “they rule here!” On the entire network, and on a smartphone riveted the application from WebView and Network Service Discovery ( GitHub ), which by these screams determines the desired IP and shows it. For smartphones, a separate compact web interface is made, of course, without beautiful images.
So, which of the languages we have not yet considered? And yes, Javascript. The configuration of lamps and switches in the web is made on Javascript.
You can do everything in it: add a switch (according to 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, if desired, can be ruled by hands (and in the first version something like this was done, but somehow I didn’t look good with this).
In the next tab, you can register the existing light bulbs (according to the numbers of the transmitter channels) and drag them out according to the scheme of your apartment, putting them in the right places (to remove the light bulb from the apartment scheme - pull it out of the picture). In addition to light bulbs, there is the “Other” device type - it differs only in the icon. Lamps are stored in lamps.xml.
The binding of power units and switches to the receiver and transmitter is done right there. Of course, it requires physical access to the blocks - but this binding is done once before installing a new block and never starts moving again: it does not affect which switches the block can control.
Since all lamp control passes through the server, then theoretically - except for the case when, due to interference, the team did not reach the lamp - he knows the current state of all controlled lamps in the apartment. It is stored in SQLite-base lamps.db, when you first start the interface will offer you to create it, filling it with zeros.
In case of communication failures - nooLite from them, unfortunately, is not insured, since it does not have feedback and confirm acceptance of the command - it is enough to click 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 to work, it appears in the database as off; 2) second press - the lamp received a command to turn on, continued to shine, while in the base it also appears as turned on).
Installation
To build under OpenWRT (the link to the finished package for AR71xx and OpenWRT 12.09 will be lower), you need an OpenWRT toolchain deployed somewhere on a large PC. In it, after the standard preparation, you need to take the Makefile from here and put it in the package / noolite / folder inside the toolchain, then make make package / noolite / compile . If today is your day, and GitHub is not banned by Roskomnadzor, then everything will come together and be in the bin / <arch> / packages / folder as a ready-to-install package.
From third-party not-too-standard packages, libusb1 is needed for operation and libusb1-dev for building.
Install it on the router (opkg install <package>), then copy the noolite file to /etc/init.d/ of this router and do /etc/init.d/noolite enable - now the utilities will start when the router is loaded. In / etc / create the file noolite.conf 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, it transmits the channel number and the command number from the received one (it is different for different types of buttons on the remotes and short or long press), but in principle can transmit anything from the standard nooLite information in any order. Codes are in the documentation in / doc project. The second is the timeout during which the program waits for something after a request to the receiver; does not play an important role in society.
If you do not create a config or specify the -i parameter on the command line, then the nooliterx utility will output the data it received to the console in a format that is readable by a human being — this is convenient for debugging.
If you install the system under x86, then the assembly is ./configure && make && make install.
For a 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 memory of the router allows you to leave your native packages in place, it is convenient to reconfigure its original web server to some port such as 8080, and hang the light control to standard: 80 to save LuCI and not interfere with the 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 login and password from admin / admin to something else (or disable authorization altogether). Authorization is done at a very primitive level and only on the admin panel - so that your relatives and friends, by pressing the button, do not accidentally bang the lights in the apartment.
Yes, if after all you bang something - each time you save the XML files, the old version is copied to a file with the .bak extension. So you can roll back one step back changes, but now only from the console - by renaming the file back.
When you first enter the web-muzzle, the system will offer you to create an empty database - do not refuse it. There are already XML files in it, for example of how the ready configuration looks like - after looking, erase all the lights and switches from it and set your own. Do the same with the flat picture.
The final touch is the Android app. To make it find where the lights are on, put the avahi-daemon package on OpenWRT, go to / etc / avahi / services and create the http.service file of such content (the application will find the IP router by the service name):
<?xml version="1.0" standalone='no'?><!--*-nxml-*--> <!DOCTYPE service-group SYSTEM "avahi-service.dtd"> <service-group> <name replace-wildcards="yes">Homelight server</name> <service> <type>_http._tcp</type> <port>80</port> <txt-record>path=/</txt-record> </service> </service-group> If further Avahi rests on startup and swears at the absence 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 the painful ones. First, of course, the lack of feedback: yes, it happens that the team left the switch and did not go anywhere. Infrequently, but it happens. Secondly, in addition to the lack of protection of the transmitted one, noolite is not very good at checking the integrity of the data: it happens that one team left and another one came and the wrong lamp was turned on. Very rare, but it happens. Finally, for certainty, the switch sends several copies of the command to the air - and sometimes the receiver manages to accept them as two consecutive commands (to combat this, a restriction is introduced in nooliterx: the command is ignored if it arrived less than 300 ms after the previous one).
Unfortunately, I haven’t 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 equipment for the entire apartment, even with a dollar of 35 rubles, drove into a shiver.
From the pros: it was found that the inconspicuousness of the nooLite switches is redeemed by their functionality. You can do, for example, like this:
The remote control here is inserted into the standard frame of the W59 Schneider Electric series sockets (there is no actual socket under the remote control, there is a wall right there), and the remote control itself has a laminated own print inserted instead of the native gray substrate, which indicates which button turns off.
Tips:
- The reliability of the operation of power units strongly depends on the antennas. The antenna should ideally be flattened and directed perpendicular to the direction of the transmitter. Native antennas are made of soft wire, the easiest way is to provide them with sufficient rigidity by wearing a cocktail straw.
- Do not place antennas closer than 5-10 cm from CFL caps and LED lamps - their pulse power supplies give noticeable pickups. A characteristic symptom is that the block is turned on from the first, and turned off from the fifth to tenth time.
- I changed the antennas on the USB receiver and transmitter with hard pins of copper wire 165 mm long.
- The signal level at the USB transmitter is higher than that of the wall-mounted consoles, therefore, where it was triggered two times from the wall-mounted console, it can work steadily with a USB transmitter.
- The router is a single point of failure of light in your house (well, besides the dashboard on the stairs and the transformer in the next block). Buy two or three spare remotes and tie the main power blocks directly to them so that you can turn on the required minimum of light without a router.
Links
Source: https://habr.com/ru/post/364065/
All Articles