A client of mine has a product in the form of a sensor that monitors the temperature of medical critical infrastructures, such as medicine refrigerators or organ transports. For the configuration, analysis and alerting of the sensor, he had licensed an app from another provider. The app was actually for another product, but the other software company changed the logo and then decided to call it a day. One day, however, the software company became impudent and demanded €50,000 licence fee per year for a product that was not even tailored to my client’s needs. So my client turned to me and asked me if I could develop an app that met his needs as soon as possible.
Join me on a six-week journey that included reverse engineering Chinese BLE specifications, massive performance improvements and responding to drastic changes in customer requirements.
规范 - What is 0xA9-0B-9A-05-03-A8-BB-08 ?!
In order for the app to communicate with the sensors, I needed to know which hex values I could send and receive. Fortunately, my client had contact with the manufacturers of the sensors in China. So he asked them for the BLE specifications. It took a while, but I got something…. In Chinese and far from complete. Using Bluetooth monitoring apps like NRF Connect, I could see that the devices themselves showed much more data than I had in my specification.
One of the main functions of the app is to notify the user remotely when the sensors are out of temperature range. In a way, the app serves as a base station. To do this, I needed the current temperature, which was not available in the specifications. Fortunately, after some observation of the data, I noticed that the last two bytes changed to “0xA9-0B-9A-05-03-A8-BB-08”. So I converted “BB-08” and found that this is my temperature. Yes! That’s it!
Building the app
I started with the Capacitor framework, which is a cross-platform framework that allows you to build apps for Android, iOS and the web. I had already used Capacitor for a couple of previous projects and was very satisfied with it. The app was to be developed for Android and iOS. The web version was not planned.
As always, I have developed the app in a very modular way, with separation of concerns. This makes it easier to maintain and expand the app. This saved me a lot of headaches in the later development phase, because my client now wanted the sensors to be able to be monitored by several devices at the same time. I had to change the module for BLE communication, but thanks to the modular design I was able to do that without having to change the rest of the app.
Interesting in terms of programming was the rather complex algorithm for alarm monitoring. Alarms can be triggered at different intervals and at a specific time. When an alarm is triggered, it calls a serverless function, which in turn notifies the user in the configured way (email, etc.). This process had to be very stable as the main use case of the product is in the medical field.
While developing the BLE core layer, I also noticed an unused feature of the current app’s stack. You could write the MTU size and speed up the temperature synchronisation process by 1000%. This was a very nice side effect.
Verdict
The app was developed in six weeks and is now in use by my client.