-Could you tell us your role at Shayp?

-I am Zineddine, the CTO of Shayp, I am responsible for the design, development and delivery of the overall Shayp solution. I tie together the hardware and software product roadmap with the business strategy.

-What is an Internet of Things (IoT) protocol?

-It’s a protocol that defines how a device sends data to a computer, the cloud, or another device. I have tested many in the very early development phase of Shayp and in my past job. Sigfox, LoRa, Zigbee, NB-IoT, BLE (Bluetooth Low Energy)…: the first Shayp prototype was an Arduino*, sending data by ZigBee* to a Raspberry Pi* that acted as a gateway*. There were a lot of possibilities that we investigated, but Zigbee seemed to have the best building penetration and lowest power in combination with a gateway.

-Which IoT protocol are you using now at Shayp and how does it work?

-Today we almost exclusively use Narrowband-IoT (NB-IoT). It is a GSM* protocol made for moving IoT devices that sends data directly to the network and forwards the data to Shayp. When we started, people were talking about it but it was not even available for testing.

-What technical criteria did you need to reach when you started, for what Shayp wanted to develop, and why?

-Our main goal was: easy installation. Working in places where you have no network and having an easy installation on a water meter without being invasive, it’s a challenge. Creating, like we are doing now, a sensor that works with 90% of the water meters. You can have water meters in classic basements where there’s no problem, the temperature is always the same, no humidity… You can believe the datasheet of the battery. But then you have places where the water meter is outside, it can be -20 degrees and at the end of the day +20, you can have the water meter under the water, underground… That’s also a challenge in electronics.

-What is the comparison between Sigfox, LoRa and NB-IoT?

-In the beginning, we had two big networks to choose from for what we wanted to use: Sigfox and LoRa. At that time we decided to go for Sigfox. The main advantage of Sigfox is that you are paying for a service so you don’t need to worry about managing antennas. LoRa, being also a good option to consider, wasn’t that developed in Belgium. It was also a business decision seeing that a mobile network provider called Proximus However was who handled LoRa in Belgium. The company deploying Sigfox in Belgium is actually their main business, so it was also something to take into account.

And now our main reason for using NB-IoT is that it is really Deep-Indoor. For our needs, it works much better than Sigfox. With NB-IoT you can send more data (up to 512bytes) in one message compared to Sigfox (maximum of 12 bytes) and in the end, based on our calculation and for our type of application, we think NB-IoT also uses less energy. With Sigfox, we were sending the same message three times to be sure that it will arrive somewhere, contrary to NB-IoT where we only need to send the message once.

Wireless connectivity

-How do you manage the data?

-The data is sent to our server by UDP* and then we save the data directly to our database.

-Which of these Internet of Things examples is more suitable for water meters?

-Most of the water meters are in basements or in places where wireless connectivity is very challenging, with NB-IoT we don’t have connectivity problems, even in more extreme conditions, so it is the most suitable for us for the moment. It makes deployment a lot more scalable and versatile.

-What are the categories of the IoT protocols?

-If I had to classify them, the first thing I would check is: does it need to be connected by battery or do I have to plug it in? In the first case it has to be low powered except if it can work for several hours, in the second one I don’t care about the energy because I can plug it in. Then I would check: what do I have to send? How many times per day? How big is my message? For example: if I know that I will have to send a big message, I would not use Sigfox because I have only 12 bytes. In third place, I would ask what is available where I am? For example, NB-IoT is not available in every country although it’s growing fast.

-What protocol would you advise for smart metering and why?

-NB-IoT, because it’s really Deep-Indoor. You don’t have to put antennas everywhere, you just have to select a good telecom provider and then they will take care of the antennas outside. If you are a water utility company, your main mission is to provide water, not to take care of wireless networks, base stations and bother with data loss or downtimes. Some water utilities make a cost analysis but they are underestimating the amount of problems that will occur. More often than not, we’ve observed that less than 20% of smart meters are no longer sending data.

Another added value is that you can have long battery life and also give more services to the customer. With other technology, you send a message once a day in the best case. But you can’t give a lot of insights with a message once a day or once a week. At Shayp at least, we are maximising value for the end-user. We’re seeing more water utilities realising that smart metering isn’t just about saving time and costs on their end.

With NB-IoT you can have high precise and high-resolution data, so the water company can give more services to the final customer. We believe that this is much more in the public’s interest than, for example, shutting off somebody’s water when they missed a payment of their bill.

-Is it cheaper to install your own antennas at the end?

-I didn’t do the math personally but I’m seeing way too much optimism. It’s always a question of make or buy for companies, and engineers tend to push to make because that’s what we all love doing. You need a wireless network specialist because you can’t install antennas wherever you want. I don’t understand why we should do that if the network infrastructure already exists, it implies extra pollution (producing more materials, transport…).

There are a lot of companies: Sigfox, LoRa, T-Mobile, Orange… Whose main purpose is to take care of these infrastructures, I would just work with them to be able to be more focused on my own business. Just negotiate a contract that is fair for both parties.

If you have an issue, you have to fix it and pay for it, so I don’t think it will be less expensive in the end. You need people to maintain that network and people are expensive.

-What are the advantages of wired VS wireless?

-If I had an endless amount of money, I would always go for high quality wired solutions. You have unlimited data, uncapped data rates and transmission frequencies making it truly a real live feed. And well, you don’t have to worry about battery consumption. But the clear disadvantage is the costs associated with wired solutions, sometimes even the technical feasibility. We reduced installation costs by over a factor of 20 compared to some wired solutions but really focused on maintaining the major benefits of wired solutions.

The most complicated part regarding the installation of our solution is finding the water meter ensuring the client has access to the basement.

-How did Shayp address the challenges of wireless IoT?

-Our naivety helped. We said to ourselves: 10-year battery with maximum transmission frequency and never assumed it was impossible. We figured out clever ways to compress the data in the limited packets of data using algorithms and tried to find the right balance. In the beginning, with Sigfox, we had to use algorithms that produced more data with a smaller size, by compressing it. It may look easy but it’s not that easy actually.

-What are the advantages of long-range protocols VS short-range protocols and how do you choose between one or the other?

-Early on, we were inclined on using a sensor using a short-range protocol that would send to a gateway, which in turn would send to the cloud through WiFi or 3G. However, you’re already integrating an antenna into the sensor, so why not just send it immediately to the cloud instead? This reduces the bill of materials considerably.

I believe that if there is a gateway and there are only so many end sensors required for your application, it’s good to look into long-range protocols.

-What was the hardest part in reaching the objectives of low power, long data, wireless…?

-Hardware development is a pain, if you make a mistake, you’ll have to recall your devices. And believe me, every mistake or bug that you think can happen, will happen. If there is something on the market that already fits most of your technical criteria just go for it. At Shayp, we set ourselves high-level criteria but it did take close to 3 years to have a polished and commercialisable product.

-And what was the market’s need?

-After investigating monitoring solutions, especially for water meters, they were rather invasive and costly (some of them required ethernet cable, cabling, wiring…), and they weren’t battery-driven so they needed to be plugged into an outlet.

Moreover, any wired solution seemed completely unreliable, so either the data wouldn’t go through because of the walls (especially in commercial or multi-residential buildings). And water meters, especially when they come to wireless solutions, the level of difficulty increases because they are in the basement, under the street level or under metallic plates outside. That makes these solutions completely unreliable. So the challenge we took at Shayp was to provide scalable non-invasive and low-cost solutions. So we are able to equip water meters in buildings and to send data with a high data rate.

The technical challenge was to build something that was easy to deploy, completely battery-powered, and that had a life battery time that exceeded 10 years. That is due to that when building operators install something they don’t want to have to change it every year. Maybe they are managing tens of hundred buildings at a time. That means that you have to change ten hundred batteries every year, that’s not possible.

And the last aspect was that without plugging in, it equals sending enough data with a rather high resolution so that we could run out much more reliable leak detection algorithms.

-Why is it important to have such long battery life, why not recharge it?

-In our case, most of our customers take care of several buildings, changing their batteries or their devices every year would become very costly. That means that you have to send someone, take the device, charge it, send it back, connect it… So you lose time and money.

In the minds of building operators, the lifetime of the buildings is not just a matter of years, but a matter of decades. The investment that’s made is usually for at least ten years. That’s why the customers prefer it to be long-lasting so they can just forget about it for 10 years.

-Why do we need such high-resolution data? What was that for?

-There is no solution that parallels that level of data resolution combined with such long battery life. But it’s a requirement, as well as it can tell you really precisely if you have an issue, what’s the likely cause of the issue, how much it will cost and when, if it’s correctly fixed.

We’re capable of applying non-invasive load monitoring (NILM) to water consumption. This allows us to not only detect leakages but also consumption discrepancies such as a dysfunctional pump or water tank.


GLOSSARY


Arduino
→ Arduino is an open-source electronics platform based on easy-to-use hardware and software. Arduino boards are able to read inputs and turn them into outputs. You can tell your board what to do by sending a set of instructions to the microcontroller on the board.

ZigBee → Zigbee is a protocol used to link smart devices like lights, plugs, and smart locks to a home network. Zigbee is low-power and only pushes data on demand.

Raspberry Pi → The Raspberry Pi is a low cost, credit-card sized computer that plugs into a computer monitor or TV, and uses a standard keyboard and mouse. It is a capable little device that enables people of all ages to explore computing and to learn how to program.

Gateway → Gateway is a device within a communications network that allows you, through itself, to access another network. It works as a link between two networks with different protocols and architectures. Its main goal is to translate the information from the protocol in one network to the other.

GSM → The Global System for Mobile Communication is a standard that specifies how 2G operates. GSM represented a transition from analogue to digital telecommunications.

UDP → User Datagram Protocol is a communications protocol that facilitates the exchange of messages between computing devices in a network.


 

 

SOURCES

https://www.arduino.cc/

https://homey.app/en-us/wiki/what-is-zigbee/

https://www.raspberrypi.org/help/what-%20is-a-raspberry-pi/

https://infotecs.mx/blog/gateway.html

https://www.emnify.com/en/resources/gsm

https://www.sdxcentral.com/resources/glossary/user-datagram-protocol-udp/

https://www.linkedin.com/company/utechnology/?originalSubdomain=ca

https://www.pcmag.com/encyclopedia/term/3gpp

 

4 Thoughts on “We tested Wireless IoT Protocols for Buildings and Smart Meters, so you don’t have to.”

  • It is an obligation of gratitude to share information, continue the great work … I sincerely enjoy researching your website. great asset …

  • I am another customer of this site so here I saw various articles and posts posted by this site,I curious more energy for some of them trust you will give more information further.

    • Thank you so much for your feedback, we are glad to read it. We invite you to continue exploring our blog, we hope you find it interesting.

  • This is the first time I visit here. I found such a large number of engaging stuff in your blog, particularly its conversation. From the huge amounts of remarks on your articles, I surmise I am by all accounts not the only one having all the recreation here! Keep doing awesome. I have been important to compose something like this on my site and you have given me a thought.

Leave a Reply

Your email address will not be published. Required fields are marked *