In the last article, we talked about creating our team, but in this article we want to tell you exactly how we implemented our first project.
Description of the object
So our first object is a residential building with the following characteristics:
- 15 floors
- 135 apartments
- Impulse meters for cold water supply in each apartment
- Heat meters with M-bus for each apartment
- Electricity meters with RS-485 interface for each apartment
- Temperature sensor in every apartment
- One valve on the heating supply pipe to the apartment
First of all, we set ourselves the following tasks:
- Throw in a schematic diagram of automation
- Select equipment for heat meters and water meters
- Select equipment for recording temperature and controlling the supply of heat carrier to apartments
- Select equipment for taking readings from electricity meters and control of the load relay
- Make a project for a dispatching and automation system for an apartment building
- Write the first version of our back end and build a test bench
- Develop a design for two web applications (for the management company and the tenant)
- Write an application for the front, which will, in turn, pull data from the database
Schematic diagram of communication of field equipment of the object
While we did not know what equipment to use, we decided to draw a schematic diagram of the equipment communication.
The heat meter (Apator LQM) has 4 pulse inputs that can be configured for different needs, for example, as in our case, we set the first pulse input to m3, set the pulse weight as in our water meter, set the initial readings of the water meter, and so on a pair was created for each apartment - a heat meter / water meter. Receiving data from a heat meter, we simultaneously received readings from a cold water supply meter.
Electricity meters gave data via DLMS / COSEM (over RS485), we still did not know what it was, how to extract data from there, but one thing was clear that we had to learn how to work with the meter. From communication with the manufacturer of the metering device, he made us understand the protocol is closed - you will not receive it, but you can read it with an ordinary RS485 to COM or TCP / IP converter using their software.
To control the supply of the thermal medium and record the temperature, it was necessary to install a controller on the floor that would have a sufficient number of inputs and outputs to measure the temperature and control the valve in each apartment.
And most importantly, we gave preference to receiving data from field equipment via TCP / IP, we converted all serial interfaces to TCP / IP. In the basement of the house there was a router with a VPN turned up to our server where all the software was rolled out.
Schematic diagram of equipment communication
The diagram is ready, we begin the selection of equipment.
Heat meters
On the Internet, there is not much information about collecting data using the M-Bus protocol. Basically, these are companies that developed their own devices (M-BUS concentrator) that were connected to 250 units. metering devices and uploaded data to some kind of cloud with a terrible interface and without the possibility of building analytics and uploading data to billing services. The only thing that we found on the Ukrainian market was the Anybus interface and protocol converter, but we were not satisfied with its cost and delivery time. Well, Leha put forward the idea to buy an M-BUS / RS-485 interface converter and some kind of raspberry pi that will poll the meters via RS-485.
But the only lib and framework we found was OpenMUC, but at that moment we could not figure it out. Then they began to wool the European market and found it! The guys in Poland produced the device that we need, and the price is class, but how to bring it to Ukraine? We managed to do this through intermediaries.
And here is a miracle package, unpack it, connect it, turn on the scan of the counters and ... ... does not see it. Well, we tried it 5-7 times, decided that maybe the MBUS Gateway is working, but the counter is not. I run to my friends, ask them for a Sharky heat meter, connect it to the Gateway and ... ... interrogate it !!! We are glad to open champagne! Victory! Toast! But then the thought comes to us that there will be 135 Apator meters at the facility, which, by the way, are also made in Poland, but we didn't have a good conversation with them! We write to Poland to the Gateway plant, wait, write more and more, and so 4 days - silence. We don't give up (God, how sick we were in the head), I start surfing in FB, we find there Mateusz who works at the factory, we find his phone and are going to call. I grab Lech and say: “You were 3 years in a row in America at WT, now you will explain to the Poles that their Ukrainian friends have problems!”
He calls, begins to speak in English, but all that Mateusz squeezed out of himself: “Hi! Yes! ”, And what do you think Lech starts talking to him in Polish, in Polish !!! As a result, the issue was resolved in such a way that it was necessary on their support forum, to create a topic with a description of the problem and data for connecting to the device, and after 2 days, the guys from Poland taught their device to communicate with our Apator heat meter.
It is important to note that the Gateway wrote data from MBUS to Modbus registers, from where we took them. Also, the block could poll 60 devices, and not 250 units. we specifically went to this to increase the speed of receiving data from home and reliability.
Electricity meters
It was generally epic! I have been looking for solutions for obtaining data from electricity meters for a long time, the plant did not come to our aid, so I had to cope myself. Again Google saved us, on some forum I found a person who was very actively discussing the topic of counter dispatching like ours, and he had some experience in this direction. I wrote to him, he answered, the following became clear from the conversation: he did the reverse - engineering of the communication protocol with the software of the meter manufacturer. He just listened to the COM port and parsed the bare bytes - our man.
The result of wiretapping the
Gateway port he collected from ATMega-32, RS-485 / TTL and RJ-45 for arduino (I don't remember the exact specification anymore). That is, the gateway was a meter master and worked on the principle of the Polish block. We make 2 gateways, test on 5 counters, all class.
Self-made device for counters
We put 15 pieces on the object, 9 counters each, and the next morning 5 devices burn out. What's the matter, everything was fine at the stand, but the stand is a stand, realities are realities. It turns out that RS-485 / TTL was not galvanically isolated. We remove the blocks, buy the necessary RS-485 / TTL, solder, install and ... ... again they fly out. The problem was not solved with these units, however, we found a factory solution for RS-485 / Ethernet, and in two days we ourselves reversed the meter protocol. Everything worked out.
Heating medium supply control and temperature registration in apartments
We needed to find a controller suitable for the price, warranty and service. We started with Siemens, Wago, but due to the price and lack of an adequate service center (any such controller for repair must be sent abroad and wait 3 weeks, and provided that we had 15 of them this could play a bad joke), we continued to search and found controllers of Ukrainian production Raut, it was ideal for our needs - there are enough inputs / outputs, programming is much easier than in the same SoMachine Schneider, the price suited us, service from 3 to 5 days, delivery 1 to 2 weeks. And the quality is satisfactory, in 2 years we installed about 150 pieces and only 1 was sent for repair (pah-pah).
First stand
We used Pt1000 temperature sensors, yes analog, yes there is an error, especially with a long wire length, and we used to have 35 meters from the controller to the sensor, but compared to digital temperature sensors, it is easier to connect, more reliable, cheaper, and most importantly, when in The apartment was being repaired, 30% of the sensors usually have a snack, which, when using a digital sensor, leads to a short circuit in the line and often to a freeze of the field device.
We picked up the equipment, learned how to work with it, at the field level in the house everything should work and function, we assemble shields.
Shield assembly
We have started to write the first version of our back`end, launched in parallel to the design of the two interfaces (for the management company and the tenant), have started the installation on site.
Installation and commissioning
A separate word needs to be said about installation and commissioning. The object took:
- 15 controllers
- 6.5 km FTP cat 5e
- 2 km PVS
- 15 units Switch
- 30 units 24 V power supplies
There was a lot of work for the first object and the prototype, the wires had to be not only scattered under the ceiling, but also signed by each one (after all, each wire was for a certain apartment sensor, valve, water meter / heat meter), after installation, each wire was ringed and disconnected. I confused something and that's it - the wrong valve opened and closed for the apartment, the neighbors had someone else's testimony, and so on.
Each heat meter of the apartment must be synchronized with the readings of the water meter of the apartment and connected correctly. Each apartment has 3 serial numbers of the metering device, they also cannot be confused, or there will be a pipe in the accounting department.
Interface design
While the installation was in progress, and the writing of the first backup, our front'end team was preparing the first designs of two interfaces (for the management company and residents), about 4 options were proposed for each of the interfaces.
The difficulty was that these interfaces will not be just sites for sale, they should be light, simple and convenient, because if the tenant does not have a good impression and UX, for some reason (it is not clear how to control, where is the temperature, etc. ) then he will simply eat the management company and this will be a problem, since the customer will eat us.
The management company employs mainly engineers and they are generally not used to using something like that, give them SCADA, ASKUE and 1-C with heavy interfaces.
I think we managed to create the necessary designs and implement them in the future.
Resident's interface
Example page for UK
Super! Ahead still, awareness of problems:
- how to control the supply of the heat carrier is quite difficult, especially if you have one temperature sensor and one valve per 45 m2 apartment
- how to get people across our message and help them embrace technology
- how to make the system scalable, fast and simple
- it is necessary to monitor the consumption of resources and identify faulty impulse water meters and stuck valves, because there is no feedback
- calibration of temperature sensors
- overheating of the MBus gateway, and transferring the memory to read only
- we figured out the apartments, but the boiler rooms, TP, pumping stations. We want a real BMS!
But oddly enough then, without experience, we snapped these problems like nuts and went forward.
All good!