IoT provider notes. Engineering and economics of LoRaWAN in urban lighting

In the last episode...

Since a year ago I писал about the management of urban lighting in one of our cities. Everything was very simple there: according to the schedule, the power to the lamps was turned on and off through SHUNO (outdoor lighting control cabinet). There was a relay in SHUNO, at the command of which a chain of lanterns was turned on. Of the interesting, perhaps, only that this was done through LoRaWAN.

As you remember, initially we were built on the SI-12 modules (Fig. 1) from the Vega company. Even at the pilot stage, we immediately had problems.

IoT provider notes. Engineering and economics of LoRaWAN in urban lighting
Figure 1. - Module SI-12

  1. We depended on the LoRaWAN network. Serious interference on the air or a server crash and we have a problem with city lighting. Unlikely, but possible.
  2. SI-12 has only a pulse input. You can connect an electric meter to it and read current readings from it. But for a short period of time (5-10 minutes) it is impossible to track the jump in consumption that occurs after the lights are turned on. Below I will explain why this is important.
  3. The trouble is worse. The SI-12 modules hung stably. Approximately once every 20 runs. In conjunction with Vega, we tried to eliminate the cause. During the pilot, two new module firmwares and a new version of the server were released, where several serious problems were fixed. In the end, the modules stopped hanging. And yet we moved away from them.

And now...

At the moment, we have built a much more advanced project.

It is based on IS-Industry modules (Fig. 2). The hardware was developed by our outsourcer, the firmware was written by ourselves. This is a very smart module. Depending on the firmware that is loaded on it, it can control lighting or interrogate metering devices with a large set of parameters. For example, heat meters or three-phase electricity meters.
A few words about what has been implemented.

IoT provider notes. Engineering and economics of LoRaWAN in urban lighting
Figure 2. IS-Industry module

1. From now on, IS-Industry has its own memory. With the firmware for the light, so-called strategies are loaded remotely into this memory. In fact, this is a schedule for switching on and off SHUNO for a certain period. We are no longer dependent on the radio channel for switching on and off. Inside the module there is a schedule according to which it works out regardless of anything. Each working off is necessarily accompanied by a command to the server. The server needs to know that we have changed state.

2. The same module can interrogate the electric meter in SHUNO. Every hour, packets with consumption and a whole bunch of parameters that a metering device can issue come from it.
But that's not where the salt is. Two minutes after the state change, an extraordinary command is sent with instantaneous counter readings. From them, we can judge that the light is really on or off. Or something went wrong. The interface has two indicators. The switch shows the current state of the module. The light bulb is tied to the absence or presence of consumption. If these states contradict each other (the module is turned off, but the consumption is on and vice versa), then the line with SHUNO is highlighted in red and an accident is generated (Fig. 3). In autumn, such a system helped us find a jammed starter relay. In fact, the problem is not with us, our module worked correctly. But we work in the interests of the customer. Therefore, they should show him any accidents that may cause problems with lighting.

IoT provider notes. Engineering and economics of LoRaWAN in urban lighting
Figure 3. - Consumption contradicts the state of the relay. Because the line is highlighted in red

Graphs are built according to hourly readings.

The logic is the same as last time. We track the fact of inclusion by an increase in electricity consumption. We track the median consumption. Consumption below the median - part of the lanterns burned out, above - they steal electricity from the pole.

3. Regular packages with information about consumption and that the module is in order. They come at different times and do not create a crowd on the air.

4. As before, we can force turn SHUNO on or off at any time. It is necessary, for example, to search for a burned-out lantern in the chain by an emergency team.

Such improvements significantly increase fault tolerance.
This management model is now perhaps the most popular in Russia.

And yet ...

We went further.

The fact is that you can generally move away from SHUNO in the classical sense and control each lamp separately.

To do this, it is necessary that the flashlight supports the dimming protocol (0-10, DALI or some other) and has a Nemo-socket connector.

The Nemo-socket is a standard 7-pin connector (shown in Figure 4) that is often used in street lighting. Power and interface contacts are output from the flashlight to this connector.

IoT provider notes. Engineering and economics of LoRaWAN in urban lighting
Figure 4. Nemo-socket

0-10 is a well-known lighting control protocol. Not young anymore, but well established. Thanks to commands using this protocol, we can not only turn the lamp on and off, but also put it into dimming mode. Simply put, dim the light without turning it off completely. We can mute by a certain percentage value. 30 or 70 or 43.

It works like this. From above, our control module is installed in Nemo-socket. This module supports protocol 0-10. Commands come through LoRaWAN via the radio channel (Fig. 5).

IoT provider notes. Engineering and economics of LoRaWAN in urban lighting
Figure 5. Lantern with control module

What can this module do?

He can turn the lamp on and off, dim it by a certain amount. He also knows how to track the consumption of the lamp. In the case of dimming, a drop in the consumed current is observed.

Now we track not just a chain of lanterns, we manage and track EVERY lantern. And, of course, for each of the lamps we can get a certain error.

In addition, you can significantly complicate the logic of strategies.

Eg. We tell lamp No. 5 that it should turn on at 18-00, at 3-00 dim by 50 percent to 4-50, then turn on again at one hundred percent and turn off at 9-20. All this is easily configured in our interface and is formed into a work strategy that is understandable for the lamp. This strategy is poured onto the lamp and it works according to it until other commands arrive.

As in the case of the module for SHUNO, we have no problems with the loss of radio communication. Even if something critical happens to it, the lighting will continue to work. In addition, there is no crowd on the air at the moment when you need to light, say, a hundred lamps. We can safely bypass them one by one by taking readings and adjusting strategies. In addition, at certain intervals, signal packets are configured that the device is alive and ready to communicate.
Unscheduled appeal will be only in the event of an accident. Fortunately, in this case we have such a luxury as constant food and we can afford class C.

An important question that I will raise again. Every time we present our system, they ask me - what about a photorelay? Can a photo relay be screwed in there?

Technically, there are no problems. But all the customers with whom we are now communicating categorically refuse to take information from photo sensors. They ask you to operate only with the schedule and astronomical formulas. Still, urban lighting is critical and important.

And now the most important thing. Economy.

Working with SHUNO via the radio module has clear advantages, relatively low cost. Increases the level of control over fixtures and simplifies maintenance. Everything is clear here and the economic benefits are obvious.

But with the management of each lamp, everything is more difficult.

There are several similar completed projects in Russia. Their integrators proudly report that dimming has been able to achieve energy savings and in this way pay for the project.

Our experience shows that not everything is so simple.

Below I give a table with the calculation of the payback from dimming in rubles per year and in months per lamp (Fig. 6).

IoT provider notes. Engineering and economics of LoRaWAN in urban lighting
Figure 6. Calculation of savings from dimming

It shows how many hours a day the lighting is on, averaged over the months. We consider that approximately 30 percent of this time the lamp shines at 50 percent of the power and another 30 percent at 30 percent of the power. The rest is at full capacity. Rounded up to tenths.
For the sake of simplicity, I consider that at 50 percent power, the fixture consumes half of what it consumes at 100 percent. This is also a little false, since there is a consumption of the driver, which is constant. Those. real savings will be less than in the table. But for ease of perception, so be it.

We will take the price per kilowatt of electricity at 5 rubles, the average price for legal entities.

In total, for a year on one lamp it is really possible to save from 313 rubles to 1409 rubles. As you can see, on low-power devices, the benefit is very tiny, with powerful illuminators it is more interesting.

What about costs?

The rise in price of each flashlight, when adding a LoRaWAN module to it, is about 5500 rubles. There, the module itself is about 3000, plus the cost of Nemo-Socket on the lamp is another 1500 rubles, plus installation and configuration work. I still do not take into account that for such lamps you have to pay a monthly fee to the owner of the network.

It turns out that the payback of the system is at best (with the most powerful lamp) a little less than four years. Payback. For a long time.

But even in this case, the subscription fee will nullify everything. And without it, the cost will still have to include the maintenance of the LoRaWAN network, which is also not cheap.

There is still a small savings in the work of emergency teams, which now plan their work much more optimally. But she won't save.

It turns out, all in vain?

No. Actually, the correct answer is this.

Managing each lamp is part of a smart city. The part that does not directly save, and for which you even have to pay a little extra. But in return we get an important thing. In such an architecture, we have a constant guaranteed power supply at each pole around the clock. Not only at night.

Almost every ISP has experienced this problem. We need to make wi-fi in the main square. Or video surveillance in the park. The administration gives the go-ahead and allocates support. But here's the problem - there are lighting poles and electricity there only at night. You have to be smart about something, pull additional power along the supports, put batteries and other strange things.

In the case of controlling each lantern, we can easily hang something else on a pole with a lantern and make it β€œsmart”.

And here again the question of economics and applicability. Somewhere in the outskirts of the city, SHUNO is enough for the eyes. In the center it makes sense to build something more complex and manageable.

The main thing is that these calculations should contain real numbers, and not dreams about the Internet of Things.

PS During this year, I had the opportunity to talk with many engineers involved in the lighting industry. And some proved to me that there is still an economy in the management of each lamp. I am open to discussion, my calculations are given. If you can prove otherwise, I will definitely write about it.

Source: habr.com

Add a comment