Volme. Truly smart automotive security device based on a really cool physical principle.

Or how we made a unique device for its niche without any experience in building hardware products.

This article is about how we created something that really works on the basis of a simple idea.

Also, I will tell you how the idea appeared, how do we see the general concept of the solution, how did we choose the physical principle and implementation technology, how did we develop and debug the data processing algorithm and the software (server and client) part and, of course, how did we put everything together and make it work 😉 At the end of the article, you will find a link to the repository with different code examples used in the project (examples for both: sensors/device control and a ready-to-use simple server-application code).

Hi! My name is Sasha and I am an engineer.

I finished my studies as a Radiophysicist, so my soul is more than inclined towards different kinds of hardware since I was a youngster. Actually, my first job was directly related to making hardware: I started my career as a technician at the company, which produces various electronic devices for electric transport. I was engaged in assembling some elements on the circuit board, preparing and assembling ready-made devices in a case, in general — I worked with my hands. After working for more than half a year I got a job at another company, but as a design engineer and participated directly in the development of the devices: I developed schematic diagrams, circuit boards layout, etc.

But God works in mysterious ways, so I got into programming, where I have been working for more than four years.

For the last two or so years, in a spare time, together with my co-founders I have been making a hardware startup — our Volme.

What is it? Volme is a modern and “easy-to-use” car alarm system that is designed to prevent car theft. Prevent is the keyword since the vast majority of car security systems only help (or not) to find an already stolen car. In addition to the actual protection, the system is designed to be as “user-friendly” as possible: installing and start using Volme will be as easy as start using a new teapot.

How does it work? The whole product consists of a device, a mobile app, and a cloud service. To start using Volme, you should download our app, pair your smartphone by scanning a QR code, and place Volme into your car. The final step before using our device will be the calibration process: it needs to become “ friends” with the different types of cars to be as accurate as possible (don’t worry, in reality, we’ll take care of everything that sounds scary).

What Volme has under the hood?

• Ultrasound sensors — to “scan” a car when you’re not around;
• Bluetooth — Volme is controlled via a cryptographically-secured Bluetooth channel;
• GPS/LTE — keeps in touch with the world;
• Camera — recognizes and captures intruders;
• Speaker — in the case of intrusion Volme plays a “special message” (audio you can record by yourself to wish everything you want to an intruder);
• Powerful LED — to scare and blind an intruder just in the face;
• Cloud Service — saves the content captured by the camera and other data related to your account.

How the idea was born? The idea for the project was born as a consequence of many factors. I had been using the car regularly for 6 years by 2018 (the year when the idea came to us). Therefore, I regularly used the standard alarm system, which was installed in the showroom when I bought my car. Anyone who drives a car probably knows how “great” such a default system works.

The default keys themselves work really well as a central lock to open/close a car, but the alarm system which they control — leaves much to be desired. Without taking into consideration the regular false alarms (for example in a thunderstorm, or from a loud passing car nearby) the standard alarms have a lot of flaws 😉 In my last year at university, I studied information security and one of my university friends was interested in car alarms. So, from time-to-time, he was sharing with me all sorts of videos on the subject.

That’s how I came to the YouTube channel — “Stolen.Net”. It shows various ways to steal cars, as well as ways to combat them. Frankly speaking, I was literally dumbfounded by the fact that the existing alarms are so unreliable: on average it takes less than 5 minutes to steal almost any car if you have a great desire and the right tools.

Because of my studies direction, I began to read more about the principles of various systems for car theft. It was a kind of hobby that lasted only a few months, but some information apparently stayed in my head. Well, on the basis of this knowledge, it was (and still is) obvious to me, that the vast majority of alarm systems are just central locks. In other words — protection from “honest people”.

Secondly, the idea of the project was prompted by the level of traffic and the number of cars in large cities: cars parked literally everywhere, and we, as car owners, have no idea what happens to our cars while we’re not around. When I dug a little deeper and take a look at the statistics, it turned out that one of the most “popular” places for stealing cars are parking lots of shopping malls even if they’re closed or guarded.

But, what’s the situation on market right now?

It became clear that the market lacked the right product. But what kind of a product — was the main question. So, we’ve started to analyze, search, and study the existing products in the niche, looking at how well they solve the problem and whether they solved it at all. If a product solves the problem well — we tried to understand its limitations, what and how we can improve, change, add, etc.

After analyzing the market, we were able to form a few theses about what’s wrong with the already existing smart alarm systems:

1. they are NOT smart: a small number of products on the market that integrate with a smartphone, and technical implementation of the existing ones could be much better.
2. they are quite easy to hack.
3. they are almost impossible to install by ourselves: we couldn’t find good solutions which could be easily installed by a regular car owner without additional help or appropriate skills.
4. There are no middle-price products:
   Nowadays market has a huge price gap of different car security systems: there are relatively cheap ($50 — $200) “basic” security systems (regular “central locks”), which could be easily disabled, and “expensive” ($700 — $1500 + monthly subscription fee) systems, which include GPS-tracking, control breaking/extruding glass, remote disabling vehicle movement, etc.
   It’s clear that cheap systems practically don’t protect cars properly, and those that are more expensive give appreciable protection (they can also be hacked — enough to have the skills and equipment), but the cost, subscription fee, and the complexity of installation are discouraging middle-class car owners.

So we have a set of requirements for the system we’re going to develop: it should at least fix all of the above drawbacks of existing solutions, plus add various interesting features.

But first things first.

Working principle

The first question I asked myself as an engineer when we were thinking about a device concept was: “how to provide easy installation and at the same time a high level of protection?” We couldn’t go the way of placing various sensors all over the car, because that’s exactly what everyone else is doing and this is a radical departure from the principle of easy installation.

What should we do? How to control something without having controlling devices (sensors)?

After a long brainstorm, the solution finally came to us — we have to use ultrasound. The idea was to develop a system based on ultrasonic sensors that would make an ultrasonic “print” of a car. In a stable, closed state, this print has a certain value, but when the state is disturbed (someone opened a door or broke a window) it’s value changes, which will be the occasion for alerting a car owner.

Firstly, I wanted to discuss this measurement principle with a competent person, who could immediately point out the potential “weakness spots”. To be honest — it was very easy for me because such a person is my father: he’s a Ph.D. in physics so he knows a thing or two about the topic. My father confirmed the viability of the idea, and also immediately pointed out several potential problems (jumping ahead of myself, there were many more than “a few”).

The fact that the proposed principle works well didn’t surprise me. Nature, more specifically, evolution suggested this way a long time ago: bats orient in space using ultrasound. Their eyes are totally rudimental, so by generating ultrasound they estimate a distance to objects, thus constructing a portrait of the world around them.

Why ultrasound? Why not an infrared (PIR) sensor, or microwave sensor for example? The point is that ultrasound is a much more reliable way to detect motion/intrusion. With proper processing of the results (I’ll tell you about it in the following sections of this article), it excludes any false triggering, which cannot be said about the sensors mentioned above. The microwave sensor “sees” through solid (non-conductive) obstacles and, of course, can easily pass through the car interior trim and body metal. There are already a few products on the market that use a microwave sensor, and it works pretty damn bad in the context of false positives (occasionally triggered by rain, movement of twigs, or just people passing by)

As for PIR sensors, they can easily be fooled by wearing thermal underwear, thermal gloves, and a motorcycle helmet. Of course, such an outfit will look a bit strange, but it’ll help a thief to fool sensors and steal your car 🤷🏻‍♂️

POC

The principle is good, but it’s only a theory. It had to be tested in practice by assembling a simple proof of concept (POC). It didn’t take long to choose components for the POC, we decided to use a Raspberry Pi as a controller and the simplest HC-SR04 ultrasonic sensor.

Raspberry itself is a very flexible thing when it comes to prototyping, because it is a fully functional computer running Raspbian (a Linux distribution), and it was very convenient for me as a programmer to work in its native environment. As for the HC-SR04 — it’s probably the most popular ultrasonic sensor on the market and there’s a whole bunch of tutorials on how to connect it and a lot of ready-made code to control it as well.

First of all, I assembled a very simple model by mounting the sensor on a prototyping board with a simple two-resistor balancing cascade (there’s lots of information about how to do that in the public domain, so I’m not going to post it here too).

After picking up a proper piece of code to control the sensor and made sure that everything works, I immediately tested the theory in practice: I put the prototyping board with all components in the bathroom (I’ll explain later why) and ran the code that triggers the sensor (I was connected to Raspberry Pi via SSH, so I could run commands remotely).

Everything worked as expected: the logs in the SSH terminal clearly recorded the moment the bathroom door opened/closed.

Of course, this was expected: there are tons of videos on YouTube that demonstrate this principle on similar examples. Anyway, the realization of a working prototype is a good foundation for building something much more complex. Right?

What’s after POC? POC 2.0!

Well, I made the sensor works, but it’s just the simplest realization of the concept.

The idea of the device we’re going to build is to detect any intrusion into a car: one sensor is obviously not enough here.

Plus, I had to write a simple server that, at the initial stage would save in the database all necessary data with timestamps: the registered intrusions, alerts, etc. This server needs to have a public IP so the device could send its requests via HTTP (actually, public IP isn’t necessary at the prototyping stage: you could bring the server up locally if the Raspberry and the machine connected to the same network).

I started the improvement of the existing prototype by connecting three more HC-SR04 to the Raspberry Pi and setting up the control script to works well with multiple sensors. To be honest, I’ve finished the script quickly, but all tests were still conducted in the SSH terminal logs because we hadn’t a proper server that could receive and process the alert signal.

Well, I started to write a server. As I’m a backend engineer and my main programming language is Java, there were no questions about the choice of technology for the server: it was decided to write a simple Spring Boot application to perform the most common CRUD operations.

It was easy to make for me, and in a week it was ready. It took a few days to put it into a Docker container and deploy it on AWS to get a public IP.

The result:

Testing

After the preparatory stages were completed, I began to test my prototype. The test was next: I placed the prototype in a closed room for a long time and started the system. In my case, a closed room was my bathroom. It suited perfectly (at least I thought so) because it helped me to simulate a real intrusion by opening a door.

Having my own server gave me the ability to send a REST request that checks if there is an alert in the database or not. I also installed a utility on both the Raspberry Pi and my smartphone called “Dataplicity”. It gives you full remote access to the Raspberry Pi via SSH, and directly from a smartphone you can enter different commands (exactly like you enter through a regular terminal). It’s very handy, and most importantly it’s free.

The first long test showed that the system doesn’t work correctly: in 8 hours of continuous working mode, it generated 7 fake alerts. My first thought was: “it’s necessary to debug the sensor control algorithm (script). For the quality debug I improved the logging on the side of the script, and transferred these logs as String fields of JSON object to the server, where the same string is written to the log file.

Component replacement

Improved logging helped identify several problem areas in the script, but even after fixing them, the prototype continued to catch fake alerts.

The solution came pretty quickly — we need to change sensors! HC-SR04 is good for prototyping and automating simple things but also this sensor is very cheap: the quality leaves much to be desired. We found out a bit later, its clock generator has a rather frequency variation. In addition, this sensor doesn’t resist the interference effect very well: this means that if the generated signals from two (or more) sensors overlap, it is very likely to affect the stability of their work.

I started searching for new sensors that would be better than the previous ones. After several days of looking, I decided to try — JSN SR04T 2.0.

Based on the datasheet attached — this sensor seems perfect: a wide viewing angle (up to 75 degrees), high stability of measurements, object detection at a distance up to 6 meters. This sensor was developed as an element of a Parktronic system and another huge plus — it doesn’t require an additional cascade of resistors, which greatly simplifies its use and saves space.

I’ve ordered 15 pieces because I wanted to build more prototypes for my cofounders to involve them in testing. Also it was clear that the Raspberry Pi 3B+ was too big and has a very high power consumption (270 mA/h): I needed a more compact version for future prototypes.

So I decided to build a device based on Raspberry Pi Zero W.

It’s a perfect controller for prototyping: same 40 GPIO pins as Pi 3B+, very compact (66 x 30,5 mm) with Wi-Fi + Bluetooth 4. 1 onboard and with decent power consumption: about 80 mA/h if you programmatically disable all unnecessary things like HDMI and signal LED.

I’ve built a prototype with new components, but I need a different control script for new sensors.

When I found a script code sample for JSN SR04T 2.0 I was able to easily integrate it into my existing infrastructure with minimal adaptation. Also, to ensure autonomy, I used a power bank as a power source.

After all changes, the prototype looked like this:

The test of the new prototype has begun. Time after time tests were successful: 5 tests in a row for 8 hours of continuous working didn’t generate fake alerts at all. Moreover: I was away from home for 4 days, and before leaving I ran the system for testing. As you can guess — no fake alerts in four days of continuous working.

We celebrated the victory — we finally made something to stabilize the “core” of our product.

Real-world tests

The next step was to test the system in real conditions — into a car.

To do this, it’s necessary to put our prototype into at least some case. For the first try it was decided to choose a parallelepiped shape with beveled corners: this form-factor should theoretically allows to control only the opening areas of doors and windows, but at the beginning this will be more than enough.

But I didn’t have a 3D printer arround, so I decided to make the case from “shit and bricks”, or rather from a carton 😄

So here it is:

Immediately after installing the prototype in a car and running the system, I faced an unpleasant surprise. Our ultrasonic sensors seemed to gone crazy: one of them was giving random readings, and the other was constantly showing a timeout. As you probably guessed, I wasn’t able to do the main task — test an open/closed door detection. It was obvious that something went wrong.

A more detailed study of the real-time logs didn’t help me to shed a light on what’s going on: I still didn’t understand what could be the reason for such behavior. One of my first thoughts was that the sensors were out of order. Sure I thought unlikely (because there were two at once), but still possible. I quickly replaced them with new ones and ran the test in the car a few more times again. The result was still the same 🤯

The Algorithm

Since replacing sensors with new ones didn’t solve the problem, I started brainstorming.

As it usually happens, the right answer is right in front of your nose — you just need to be able to see it. I thought for a long time about my problem, and suddenly asked myself: “why everything was working well in the bathroom?!”, so, I put the prototype (already in the case) in the bathroom and ran the system again.

In the bathroom, the system worked perfectly, just like in previous times. This made me clear that it’s not the sensors’ problem, but in the algorithm that processes their readings.

I told my father about this situation, and he suggested a way to solve my problem: we need to make the sensors “smart”. It means to rewrite my current algorithm using principles of Machine Learning.

The main reason for this weird system’s behavior was that the shape of a car interior is incorrect and materials don’t reflect ultrasound good. These two factors fundamentally change behavior of sensors compared to their working in the bathroom. The fact is that the bathroom has flat and solid walls — this creates just ideal conditions for clear and high quality reflection of ultrasound.

In simple language, the basic idea of refining the algorithm was to “train” sensors to “recognize” the object they are in (I mean your car). To do this, it’s necessary to collect and record the indicators of the sensors over a period of time. The resulting data array will be considered as a “quiescent state” (I prefer to call this — “ultrasonic signature”).

But, as all we know — easier said than done. Many questions had to be answered: “how long does it take to build the right ultrasonic signature?”, “how to handle situations when a sensor returns timeout”, “how to deal with situations when a sound wave generated by the sensor is reflected in the cabin many times and the sensor registers a gigantic value?”. These are just basic questions, in fact, there were tons of different nuances.

After 4 months of development and regular tests, the stable algorithm was finally completed.

We were celebrating for real! The “core” of our product finally worked the way we wanted it at the beginning of the project.

The Algorithm

Since replacing sensors with new ones didn’t solve the problem, I started brainstorming.

As it usually happens, the right answer is right in front of your nose — you just need to be able to see it. I thought for a long time about my problem, and suddenly asked myself: “why everything was working well in the bathroom?!”, so, I put the prototype (already in the case) in the bathroom and ran the system again.

In the bathroom, the system worked perfectly, just like in previous times. This made me clear that it’s not the sensors’ problem, but in the algorithm that processes their readings.

I told my father about this situation, and he suggested a way to solve my problem: we need to make the sensors “smart”. It means to rewrite my current algorithm using principles of Machine Learning.

The main reason for this weird system’s behavior was that the shape of a car interior is incorrect and materials don’t reflect ultrasound good. These two factors fundamentally change behavior of sensors compared to their working in the bathroom. The fact is that the bathroom has flat and solid walls — this creates just ideal conditions for clear and high quality reflection of ultrasound.

In simple language, the basic idea of refining the algorithm was to “train” sensors to “recognize” the object they are in (I mean your car). To do this, it’s necessary to collect and record the indicators of the sensors over a period of time. The resulting data array will be considered as a “quiescent state” (I prefer to call this — “ultrasonic signature”).

But, as all we know — easier said than done. Many questions had to be answered: “how long does it take to build the right ultrasonic signature?”, “how to handle situations when a sensor returns timeout”, “how to deal with situations when a sound wave generated by the sensor is reflected in the cabin many times and the sensor registers a gigantic value?”. These are just basic questions, in fact, there were tons of different nuances.

After 4 months of development and regular tests, the stable algorithm was finally completed.

We were celebrating for real! The “core” of our product finally worked the way we wanted it at the beginning of the project.

Complete prototype

At the end of summer 2019 we came to a certain stage of our project, when we definitely can and should to try to demonstrate Volme at conferences and exhibitions. It’s always a good idea to collect feedback and find angel investment on the early stage of your product.

Of course, if you go to a conference with a carton box — it will be the best joke there. In addition, we hadn’t a mobile application (there was no communication between Volme and a smartphone) and the server was built hastily.

After a lengthy discussion with my co-founders, we’ve decided to finish all components of the system to attend conferences at their best. We delayed the development of Volme even more, but we wanted to do it as well as it is possible.

My friend and former colleague had mastered React Native and agreed to help with the development of our application, while I was busy tweaking the server.

Another friend and co-founder was involved in mobile app design and branding in general.

We decided to rewrite the server to microservices based on Spring Cloud and Netflix Zull API Gateway as well.

The microservice architecture allows a qualitative division of functionality into different modules on a logical basis, which gives a greater degree of freedom in subsequent scaling and refactoring.

The security for the server is worth mentioning separately: we used a JWT based on the SHA-512 algorithm. There was a whole bunch of problems with setting up good security, as well as with migration to Spring 2.0. To implement push notifications we used Firebase: in my opinion, it’s probably the most convenient solution available on the market at the moment.

Honestly, there is enough information about writing our server for one more article, so, I won’t focus on this here. It is worth adding that finalizing the server took more than three months, because we used technologies which we hadn’t use before on real projects and just did a couple of tutorials on them (such as Spring Cloud, JWT, Zull, Firebase), therefore, design, development and fine-tuning took so much time.

In a word — the server is really cool: using modern technologies, wrapped in Docker and deployed on AWS.

After we printed the case, our prototype was good enough for presenting:

Anti-theft protection

Anyway, the main task for Volme was and still is to protect your car from theft. I’ve already said before that solutions on the market are quite easy to hack. One of the most popular and easiest ways of hacking is “code grabbing”.

I won’t talk about it in detail, but in short: when the owner opens the car with the key alarm, an intruder who is nearby (within 30–50 meters) reads the signal with a special tool (code-grabber) and records it. When the owner isn’t around, an intruder opens the car with the code-grabber as easily as the owner with his keys alarm.

This method of hacking is possible because of poor technical implementation of default car alarms: in particular because of the protocols they use for communication and the primitiveness of the default system themselves.

What does Volme offer?

The thieves have perfectly studied the systems I described above and found ways to hack them. Unfortunately, default systems can’t react in any way (e.g. to update the software and add a few features to better protect themselves).

Volme is truly smart, because both your smartphone and our device itself have a multifunctional operating system, support a variety of communication protocols (HTTP, Bluetooth, etc.), and don’t have a problem to count hash functions.
This is where cryptography, which I mentioned at the beginning, helps us. Cryptography gives us the surest way to verify that a certain message was sent by a certain user. Again, I won’t focus on a cryptography question, but in short, a user can generate a pair of keys: a private key and a public key.

It is clear from the names that the private key must remain secret, and the public key can be distributed to anyone who wants to receive messages from the user who generated the keys.When sending messages over the network, the user signs messages with a special cipher (token), which is generated by “hash function” using his private key.
After signing and sending a message, the addressee on the other side, using his public key, can verify that the message was sent by that user with almost 100% probability.

This is a very simplified explanation, but it helps to catch the idea in general terms.

There are many implementations of hash functions, but the most reliable is SHA-512. It is almost impossible to crack (it would take millions of years for the most powerful computer today to crack it).

“Signed” messages fit perfectly into the concept of security systems and solve the problem of code grabbing very effectively.

Volme uses Bluetooth to open/close your car, and code-grabbers work on completely different frequencies, so there are no ready-made code-grabbers on the market, which could forge control signals for Volme. But even when such robbers will appear, it won’t help to steal cars, because token validity time (key, which signed the message) is very short. If a thief somehow intercepts the message, then 10 seconds after generation it will become invalid. He won’t be able to generate a new message that would pass the device’s validity check either since he doesn’t have a private key. A very simple and elegant solution to this problem 😉

MVP

Of course, the prototype is only the beginning of a long journey. In order to move the project forward (go to crowdfunding, and look for investment) you need at least an MVP.

The main requirement for an MVP — it should be almost the same as a product that will be on store shelves.
And yes, the form factor that we’ve chosen for our prototype isn’t suitable to be the basis for the final version of Volme’s design: it’s too large, not safe (sharp corners), not functional (only 2 sensors and so narrow viewing angle) and even a little ugly (but it’s not exactly).

It was obvious that we have to rethink this subject from a scratch, but how exactly — was the main question. We didn’t have a person on our team with industrial design skills, so we decided to outsource this work.
By that time, my co-founder, who’s responsible for the design, had already noticed one industrial designer: his work looked very high quality and even won the Red Dot Award. In general, the decision to work with him was made quickly. We got on the phone, discussed the details, and set to work.

Product design raised a lot of questions: from the choice of how to mount elements inside (and the device itself in general) to the materials of the housing and connectors — everything must be thoughtful. For example, at the prototype stage, we didn’t think much about power consumption. No, of course, we thought, but somehow in passing.

From the beginning, we wanted to make Volme completely wireless to make the installation process as comfortable as possible. The idea was to supply with the device two removable batteries (like a power bank): while one works, the second charges. According to preliminary calculations, one 10000 mA/h battery should be enough for about 9 days of uninterrupted work of the device.
But, as I said above, we had to rethink a lot of questions. The approach with removable batteries was not convenient: it increases the weight of Volme, its size, complicates the production of the device body itself, and the usability of this approach — why users constantly need to rearrange the batteries?

Well, after brainstorming with my team we’ve decided to power Volme from a diagnostic connector — OBD2. The solution is a compromise because almost every car has this connector (almost, because OBD2 has been widely used since the ’90s) and it’s very easy to connect everything to it without additional help.
Also, issues of power consumption and device’s size again began to concern ultrasonic sensors. I chose great sensors, but as soon as we started trying to fit them compactly into the case, we faced a lot of problems. Their power consumption is quite high (35 mA/h), which doesn’t help the autonomy of our system at all.

Then I remembered that when I was looking for a new sensor to replace HC-SR04, I came across a very good one, which I kept in bookmarks, but rejected because it was too expensive. This is the MB1000 LV-MaxSonar-EZ0 sensor.
I checked its specifications once again and convinced that it suits Volme perfectly: viewing angle — 40 degrees, high-quality (precision) element base, and power consumption 🥁 — 2 mA/h. But its serious disadvantage its price — $14 for one sensor. Well, we’ve discussed a problem again and decided to buy and test new sensors. As expected, the sensors showed excellent performance and we decided to make Volme’s design based on new sensors. Along with new sensors, a question of a GPS/GPRS module was raised.

Initially, we didn’t plan to make the possibility of a live-stream video in case of triggering Volme, so I chose a simple SIM808 module for communication with the outside world. But when I was making the specification of our elements for the industrial designer I caught myself thinking that we have a GPS/GPRS module, and we’re going to stream video with it. Obviously, we wouldn’t be able to do that.
I urgently began searching for a new module that would meet the new requirements for 100%. After a few days of researching I’ve found a worthy candidate — SIM7000G-PCI-E LTE(NB-IoT)/GPS module.

Only for $15 we get:

• LTE
• NB-IoT support
• GNSS(GPS + GLONASS + BeiDou)

Our industrial designer is very skilled and gave us a lot of advice. This kind of cooperation with him helped us look at many things in a new way in general. I transferred our element base to 3D, keeping original sizes to easier grouping elements together in a new case.

As a result, in preparation for the MVP, we dealt with all problems that were postponed, revised the element base, and solved a lot of new issues.

After all the hard work 🥁

This is a great device (design) we’ve got at the end (even though it’s just the beginning) of our journey. Thanks to everyone who read my story to the end — I hope you found it interesting. That’s not all we encountered along the way, but I have tried to collect what’s really worth looking at.
Please, feel free to visit our project’s website to learn more about it: https://volme.rocks

In conclusion, I want to say: try to implement any of your ideas — the process itself is incredibly interesting! Share your thoughts, write comments, ask questions and if you liked Volme share my article with your friends, maybe they will like it too! 😉

One last thing: as I promised, here is a link to a repository with some sample code: https://gitlab.com/codys-man/useful-iot-stuff. In the repository you’ll find a ready-made server which can receive alert messages and save them, some scripts to control ultrasound sensors and GPS/GPRS module, and a skript to enable Bluetooth communication between the Raspberry PI and a smartphone.

In case of any questions/suggestions please, contact me:

• Telegram: @codysman
• E-mail: ivanchenkoalexsandr@gmail.com

Again, many thanks to everyone!

Cheers,

Sasha