Another smart home, in three parts. Part two, server software. + Bonus

    In the first part I talked about the iron part. Now it’s time to talk about software.

    So, in the beginning there was a word was a four-channel light switch, with different sensors connected to it. The physical interface is RS485. On top of the RS485, a simplified version of MODBUS ASCII is implemented. Only functions 03 and 06 are implemented, unlike the standard, addressing of byte registers starts from zero. In addition, support for broadcast packages has been added, the answer to which is not issued. They set the time, or all outputs are disabled. Through the adapter RS485 - RS232, the controller was connected to the COM port.

    In those days, smartphones, tablets, and browsers weren’t uniform, so the very first version of the control program was for a regular PC. Here is one:

    Option 1: PC + Windows


    Everything was written in Delphi, a lot of buttons, a lot of digits, everything works, but there is one thing but - why do I, when at home, turn on the light at home through a computer? Unclear. Therefore, the development of the network version began. And it turned out:

    Option 2: PC + Windows + Internet

    A small service was written that worked as a gateway between the Internet and the internal instrumentation network. The program has been modified to work on the network. Everything is fine, everything works, but there is one thing, but - why always carry a laptop or a USB flash drive with a program to turn on the light at home? Unclear. Therefore, further development continued. And it turned out:

    Option 3: PC + Windows + Internet + Mobile Phone


    In those old days, smartphones were very rare, browsers in mobile phones could not do anything, the maximum that could be counted on was J2ME. As an experiment, an ICQ client was added to the server side, one of the many other clients was also installed in the mobile phone. Everything worked, but every time I say “OK Google”writing on the telephone keypad “Home, turn on the light in the hallway, and show the condition of the other lamps and sensors” was not very comfortable. Therefore, the development of the J2ME application began, on the basic ideas of which one of the interfaces is now based. The bottom line was that there were several bookmarks or screens, each of which corresponded to one controller. Everything worked, everything was fine, but another thing appeared, but progress did not stand still, browsers from programs for displaying pages with pictures learned a lot more. And it’s too lazy to contain three branches in parallel - Win32, J2ME and Web. And smartphones with tablets briskly walked around the planet. Therefore, the development continued and resulted in the final today:

    Option 4: LAMP + Internet + Web

    In the client part, it was decided not to spray on different technologies, but to leave only one - HTML + JS. Fortunately, mobile and desktop browsers have learned to do a lot and most importantly - the same way.

    The ideology of the whole system was completely revised, if earlier the server part was just a gateway between the hardware and the application, now several additional tasks have appeared:

    • Clients (either a script in the router or a gateway) periodically send their address to the server, at which the server further works with them. Some kind of DynDNS
    • Once an hour, the server synchronizes the time on all controllers, since there are no real-time clocks in them, but only software
    • Once a minute, the server polls all the controllers and enters the responses into the database

    Also in the settings you can set the parameters, when changed, the server sent an email and logged the event. Having a base with accumulated values, you can build different graphs - for example, temperature, or voltage, or power consumption.

    All this worked at home at first in the Asus WL-500gP V2 router, with the firmware "from Oleg and enthusiasts" on which Lighttpd + PHP5 + MySQL were installed. A USB-RS232 adapter was connected to the router and ser2net was configured. The database stores settings and logs, the admin panel and services are written in PHP. Then the Ethernet-RS485 gateway was developed, and all this moved to one of the cloud hosting.


    Since there were a lot of pictures in the last part, I decided to talk about one of the projects in this part. At the same time, we consider the problems of scalability and the difference between wired and wireless interfaces, about which in the last part there was a lot of controversy. The project is important, but, unfortunately, with vague prospects. So, let's begin.

    Suppose there is a plot. It has several lighting zones, for example, entrance, path, parking for cars. Separately - a gate with an electric lock, and an entrance gate with an electric drive. There is a garage not to be exchanged for trifles - two floors, two lighting zones on each, and with separate heating. There is video surveillance and internet.

    On the ground floor are installed:


    Above is a lighting and heating controller on the 1st floor, an RCD and an automatic machine with an independent trip. The second row is a power protection controller with a relay on 100A, from below - a 12V power supply and a lighting controller on the site. At the very bottom is a two-channel receiver, which through the lighting controller allows you to turn on the entrance light and open the gate lock while on the street.

    On the second floor:


    Above is the electronics from a window air conditioner, it is by itself. The second row is the Ethernet-RS485 gateway, below is the lighting and heating controller of the second floor and power relays for convectors.

    Sensors for indoor temperature and coolant temperature (air from the convector in this case):


    In the attic - air conditioning, video recorders, routers, antennas, mode and more:


    All this worked safely for the winter, spring came, and after it the summer. And what’s the main thing in summer? Barbecue, gazebo and watering. A pit was dug, water fittings were bred in it:


    On the left - a filter, an inlet pressure sensor, a water flow sensor. In the center there is a leakage sensor, on the right there are two irrigation valves, a pressure reduction gearbox and a pressure sensor after the gearbox. Two controllers are installed - gazebo lighting and water supply. In the gazebo itself there are two zones - decorative lighting and the main light:


    In the box on top is the gazebo lighting controller, in the center there is a 24V power supply for valves and a water supply controller.

    It turned out something like this - the second floor of the garage and the gazebo:


    Between the pit and the rest of the controllers is about 15 meters, a wall of 30 cm aerated concrete and 10 cm of overlapping pit of reinforced screed. Wireless sensors and switches? No thanks. A 3x4 power cable and a 4x4,22 signal cable are stretched, connected to the power shield - and that’s all, there is light, there is watering, everything is controlled and shows the status of the sensors. As for me - no problems with scalability or the lack of wireless technology.

    That's all with the server-software part, in the next part I will describe the most interesting thing - the user interface.

    Also popular now: