So, it's time to tell and show how this is all managed. As I said in the second part, after several iterations, everything stopped at HTML + JS. I did not plan to write a separate application for Android, but life, as usual, made some adjustments.
Links to the first two parts:

The user interface is presented in two options. The first is when parameters and commands are grouped with reference to individual controllers, and the second, when parameters and commands are grouped by task. Historically, the first appeared interface with grouping by controllers, so let's start with it.
')
User Interface # 1

From left to right: lighting controller, floor heating, electricity, water supply and irrigation.
Let us examine in detail, for example, a lighting and heating controller.

- 1, 5 - Controller switching tabs. From above five fixed, from below - four are displayed, the others can be flipped by green arrows.
- 2 - Information about the location and description of the controller, the date and time of the last update and address.
- 3 - Directly control interface. Status, control buttons, light and temperature timers, and everything else.
- 4 - Service information. Transmitted, accepted, timeouts.
Management is carried out either by simple pressing or through pop-up menus.

From left to right - the light control menu in the lighting controller, the timer settings menu in it, the irrigation timer settings menu in the water supply controller, and the voltage limit settings menu in the power supply controller.
In this type of interface there is one big plus - and it is also a big minus. Here all the settings, parameters and control elements of the controller are collected, but because of this, the interface itself has become too overloaded. Why do I constantly see voltage or current thresholds? Or heater control method and temperature hysteresis?
Therefore, the development of the second version of the user interface began.
User Interface # 2

In this embodiment, a principle similar to the OOP is implemented - there is an object, it has properties and functions. For example, a lamp - it has brightness and can be turned on and off. There are several? Well, let's make some objects of the same type.
There is a certain set of tabs, widgets of objects are located on each tab. There is no tab binding to the controllers, on the tabs you can place objects associated with different controllers, unlike the first interface option. When you click on the widget, a menu appears with control buttons. There are no multi-level nested menus either, only the simplest commands - enable, disable, stop, start, change in steps.

From left to right - the heater control menu, the irrigation control menu, the power management menu, the light control menu.
Of particular interest is the last tab. It presents a log of events, and a pair of independent graphs.

I already mentioned in the second part that you can set up email alerts for any changes to any parameters. Once a minute, the server polls the controllers, and if something changes because of the specified conditions, an email is sent. In this tab just shows a few recent events. On the graphs on the right, you can also display a variety of values from the controllers. In this example, the weather station and power controller.
At the top left - the status of the router and gateway.
In this form, it works now. But since this is a hobby, it is not appropriate to sit with folded arms. A third user interface was developed. The simplest and most lightweight.
Option number 2 ½

Everything is very austere here, there is no background, one page - one widget. A set of widgets is taken from the configuration of the second option, scrolling right-left with arrows, when clicked, the same menu appears with the same commands.
What was it done for? We are simply not particularly spoiled by high-speed Internet, and pulling megabyte images over GPRS is very depressing. But the main reason is slightly different. In what? In the appearance of Android Wear and wearable electronics.

or so

The two-and-a-half option was taken as a basis; it just went well with the small clock screen.
What about music?
MPD is responsible for it.

And with video surveillance?


With video surveillance in general is not bad, but in particular - not very. There is a widget on which you can display a picture from the cameras, but there are two but - the picture should be just a picture, not a video stream, and the second one - it is updated together with all the widgets once every 10 seconds. I have two video recorders, with a wonderful Chinese name and Russian roots - Dahua. They perform their main function quite well, but why it was impossible to add the ability to return a static image via HTTP - I do not know. Therefore, it now works with crutches and blue electrical tape.
Summing up
From the interesting - the experience of developing for Android Wear. It turned out - there is the same android, as in smartphones. There are some nuances with data exchange between smart and watches, for example - in firmware 5.0.2 the standard network availability check - on the clock stubbornly showed that the network is available, and after updating to 5.1 - the same code began to show network unavailability, although it was in this firmware has been added support for Wi-Fi.
Well, there is one question for Google - why it was impossible to make a wrapper for transparent work with sockets on the clock via a smartphone? We have to write an additional layer, and so - there would be identical code for both the clock and the smart.
As a conclusion - at this point in time, the main areas have settled down, there is a minor refinement of something else. In the spring, a meteorological station was developed that could measure temperature, humidity, pressure, wind speed and direction, and I will try to tell about it later. There are a couple of ideas in the plans for new controllers, whether it will work or not - life will show.