Design


Hey there!

Just a short note before the introduction: when I first started writing this blog post, I was going into great detail about each screen in the application. Then, I realized that might be a bit dull for you to read. After all, there are tons of case studies out there that cover similar topics. They probably do a better job than I could hope to so I decided to change my focus. As a result, I present to you the challenges we faced during the project.

In the end, I didn’t even talk about the application much. Maybe I’ll have to write another post. 🤷‍♂️ Nevertheless, hope you enjoy reading this one!

![different smart sensors](https://strapi.suprabit.eu/uploads/Smart_Sensors_d1277e86e2.png)

<br/><br/>

## The rise of smart sensors

In the era of rapid digital transformation, the integration of smart sensors in buildings has revolutionized various industries. These sensors enable real-time monitoring of occupancy, energy consumption, air quality, and security. They optimise resource utilization, enhancing comfort, and improving overall building efficiency.

These intelligent devices provide valuable data insights and automate processes, leading to better efficiency and decision-making. However, the seamless deployment and management of smart sensors require a well-designed provisioning* app that technicians use to set them up.

**For those who are not familiar - in the context of smart sensors, provisioning refers to the process of configuring and setting up a sensor for its intended purpose and network connectivity. In most cases, sensors can be edited or reconfigured after they have been provisioned.*

<br/>

## Collaboration and synergy

The embedded team at Suprabit was already working on the firmware for the Smart sensor. During this time, our client, a Swiss-based smart building premier solutions provider, recognized a need for a user-friendly provisioning app. This app would help their technicians deploy and manage smart sensors easily. As a result, they asked us to design and develop a mobile app.

![best IOT team](https://strapi.suprabit.eu/uploads/best_IOT_Team_b0b9846ec6.png)


We embraced the challenge and took a unique approach to the development process. We designed and developed both the application and the firmware in the same team. This is, unfortunately, often not possible with IoT devices, since oftentimes different agencies work on firmware, application and design. But, the ability to approach the design and development of the app alongside the firmware team proved great. We had a thoughtful and iterative design process by keeping apps and firmware teams in sync.

<br/>

## Team effort

Since we were already working on multiple projects before, our tight-knit team had excellent synergy, aiding frequent collaboration and problem-solving.

This allowed us to address technical questions about hardware or firmware quickly and efficiently. Either by turning to a team member or through a short Discord call if we were working remotely. During the design and development process, we used a highly iterative approach. To ensure a great provisioning experience for users, we needed to adjust the firmware code to incorporate design and application improvements. We also had to adjust the application and design to accommodate firmware improvements.

By working together so closely and having instant feedback, we were able to make the best design choices. In the end, we created a high-quality, user-friendly provisioning app that met our client’s needs and exceeded their expectations.

> Through this synergy of different fields, we were able to create a provisioning process that neither application developers, firmware developers nor designers could come up with on their own.

<br/>

## Don't ignore UX

There's this thing that infuriates me about applications that are highly specialized and made for a specific audience. More often than not, they completely overlook the importance of user experience. It is usually assumed that they can simply refer to some kind of manual or figure out how the process is working by trial and error - it’s not like they can switch and use some other application.

From the get-go, we believed that applications should always be easy and enjoyable to use, regardless of the user or number of users. The app's entire process should be understandable from the moment it is first opened. In fact, we aimed to make the app so intuitive that the process would be understandable from the first time you open the app.

![Smart Sensor Mobile App Screens](https://strapi.suprabit.eu/uploads/Smart_Sensor_Mobile_App_Screens_656920a924.png)


<br/>

## The early stages

In the early stages, we focused on iterating rapidly, emphasizing user experience (UX) over polishing the user interface (UI). This approach allowed us to identify potential issues early and make necessary adjustments. This turned out great because there were numerous changes during this process. By not spending time on UI, we were able to move faster and more efficiently.

Our approach to the development process was highly iterative. We mock-tested bad designs early on, which allowed us to identify and rectify potential issues before spending too much time polishing the UI. This approach proved to be highly effective, and we moved faster and more efficiently toward a user-friendly application.

Throughout this period, all teams communicated constantly about the possibilities and limitations of sensor hardware and application. This was a crucial step, as it allowed all the teams to work as one big team and understand the possibilities ahead of us.

With the goal of ensuring simplicity and error-proofing, we designed the provisioning process to be as seamless as possible. Our foremost objective was to prevent technicians from accidentally locking the sensor with the wrong configuration.

Unfortunately (or luckily, regarding who you ask), we couldn’t just “copy” a UX/UI design for provisioning from Behance or Dribble because no one had done anything similar before.

<br/>

## My Precious: The LED ring

The first step in designing the provisioning process was to determine the hardware's possibilities and limitations.

The first obstacle we encountered is that sensors are typically set up in two steps by two people. First, they mount and power them on, and then they provision them.

The issue here was identifying the sensors in the app during the second step. With multiple unprovisioned sensors on the same floor, the technician needs to make precise identification of the sensor they plan to provision.

After consideration and brainstorming, we came to the conclusion that sensors should advertise their unique ID in the wild until provisioning is over. The app catches the ID and assigns a color to each sensor. The, LED ring on the sensor displays the assigned color to the technician in real-time.

![Different LED sensors](https://strapi.suprabit.eu/uploads/Smart_Sensor_Design_4bddc7ff14.gif)



This makes identifying the sensor easy, showing the technicians where the sensors are located on the ceiling. This ensures that the states in the app and in the real world are consistent.

This solution seems obvious now, but it was a crucial step in designing a user-friendly provisioning experience.

<br/>

## The Locking Puzzle: The provisioning process

### The problem

The next issue we stumbled upon was the locking of the sensors. Instead of sending their data through Wi-Fi or Ethernet (eliminating the need to set up cables or access points throughout the building), the sensors create a Bluetooth mesh network that transmits data to the gateway sensor that's connected to the internet.

Since sensors are provisioned into a Bluetooth mesh, the app can only communicate with them via Bluetooth during provisioning. Once the process is complete, they begin using Bluetooth to communicate with other sensors in the same mesh network. 
If there's an incorrect configuration, someone has to manually hard reset the sensors by pressing a device button. This is never ideal, especially when sensors are mounted on a high ceiling in a commercial space.

Through this process, a backbone of the design was created: a four-step provisioning process.

<br/>

### The process

Once a project (such as a single building) has been created, technicians can create networks for sensors to communicate on. These networks can be created per floor, or according to the client's requirements.

![Designing smart sensor provisioning process](https://strapi.suprabit.eu/uploads/Smart_Sensor_Provisioning_39bba5183d.png)



1. The first step to provisioning sensors is selecting the one you wish to provision. The application displays all unprovisioned sensors in the surrounding area. Each sensor has a unique color to aid the technician in selecting the correct sensor based on real-world data.

2. The following step prompts the technician to stand beneath the sensor. This step is crucial to ensure the strongest possible connection with the sensor.

3. After confirming their position, an animation will begin that is visible both in the app and on the real-world sensor. This step is essential to ensure the provisioning of the correct sensor. While this may seem unnecessary, we want to empower technicians to be certain in their actions and minimize any potential for errors.

4. In the final step, the user can add configuration for the selected sensor.

<br/>

## Designing with intent

For the provisioning process, we designed an icon for the smart sensor that changes color based on the color of real-world sensors. In the initial designs, we were just using simple colored circles to represent sensors. At first glance, this “illustration” may seem over-complicated. However, in initial tests, we noticed it allowed first-time users to make a stronger mental connection between the physical sensor and its representation in the application.

![Designing different smart sensors](https://strapi.suprabit.eu/uploads/Designing_different_smart_sensors_476b729dd7.gif)



Sometimes we want to abstract real-world elements to their bare minimum, simplifying them to basic shapes or symbols. However, the experience we had with the smart sensor icon reminds us of the importance of designing with intent. It highlights the significance of considering the users' cognitive processes and their ability to make connections between physical objects and their digital representations. By intentionally designing icons or visual elements that align with users' mental models and facilitate comprehension, we enhance user experiences and foster a deeper understanding of the system or product. This emphasizes the value of purposeful design decisions that prioritize user engagement over mere visual aesthetics.

<br/>

## Language is also design?!

Once one or multiple sensors have been configured, they must be provisioned into a Bluetooth mesh. In this step, we learned a valuable lesson about thoughtful design and language's impact on user interactions. The irreversible nature of provisioning sensors into the network posed unique challenges which made careful consideration essential.

We firmly believe that good design goes beyond just aesthetics; it extends to the words we choose to communicate with users. The terminology used can profoundly impact how users perceive and navigate an application. Hence, we dedicated time to ponder the best way to name each action during the provisioning process.

For those not familiar with the context, provisioning refers to configuring and setting up a sensor for its intended purpose and network connectivity. 

Unlike most cases, our sensors couldn't be edited or reconfigured once provisioned, which led us to avoid using the term "Provision" altogether. We were mindful not to introduce any connotations that word might have with technicians and cause confusion. Instead, we adopted "Configure" to signify the initial setup of sensors, and "Lock" for the actual process of provisioning them into the network.

To remove any confusion, we even went a step further and displayed the word "Lock" only on the popup window informing the user about the consequences of the action they were about to perform, and used a lock icon on the button.

<br/>

## Rethinking Symbolism

However, we soon realized that our approach had unintended consequences. The term "Lock" and its icon on the button created confusion among our initial test group. The symbolism of the lock did not represent a clear action. It didn't align with the actions technicians were accustomed to, and many of them forgot to press it. This left the provisioning incomplete. Despite explanations, they frequently missed the step, making it clear that the process wasn't intuitive enough.

Recognizing the need for a different approach, we decided to revamp the buttons. Instead of the lock icon, we introduced a clear "Finalize Provision" button. By incorporating a term familiar to technicians, the significance of finishing the provisioning process became more evident, and as a result, their memory lapses ceased to be an issue.

![Locking nodes process BLE Mesh](https://strapi.suprabit.eu/uploads/Locking_nodes_BLE_mesh_78f479c5ad.gif)



This experience taught us the immense importance of user-centric design. By understanding the specific context and needs of our users, we were able to craft a more intuitive and seamless provisioning process. It reinforced our belief that language and design must work harmoniously to create a truly user-friendly application. Through constant iteration and a willingness to learn from feedback, we successfully transformed a potentially confusing experience into a smooth and efficient one for our users.

<br/>

## Conclusion

In conclusion, the process of designing a smart sensor provisioning app not only taught us the significance of collaboration and user-centric design but also highlighted the profound impact of intentional language and iconography. By addressing challenges proactively and focusing on delivering a seamless and enjoyable experience, we successfully crafted a high-quality, user-friendly app that surpassed expectations. As technology continues to evolve, the lessons from this journey will undoubtedly serve as a strong foundation for future endeavors in designing innovative and user-centric applications.

SmartSensorMobile.gif

Step into the journey of developing a smart sensor provisioning app, as we shed light on the intricate design process, the critical role of user-centric design, and how collaboration led to an app that exceeded client expectations. A compelling case study for tech enthusiasts, app designers, and IoT professionals alike.

A Journey Through Designing a Smart Sensor Provisioning process: Bluetooth mesh

React

Development

At first, the transition seemed scary since the two fields appeared to be worlds apart. However, as I delved deeper, I realized that embedded and mobile development share more similarities than I initially thought. So, let's explore how these two fields intersect and the skills you can use to excel in both.

# Things in common:

## Hardware limitations

Embedded developers are accustomed to working in a resource-constrained environment where every byte of memory and every clock cycle counts. This not only helps in writing efficient and optimized code but also develops a valuable skill set that can be leveraged in mobile development. Similarly, mobile development also requires optimizing battery life and processing power, making the transition from embedded to mobile development easier.

## Debugging skills

Debugging skills are essential for any type of software development. While there are several debugging tools available, such as logic analyzers or JTAG, what separates the experts from the novices is their methodical and analytical way of thinking, combined with patience and focus. A great developer can navigate through the maze of code, identifying and resolving issues efficiently and effectively, regardless of the technology.

## Knowledge of hardware interfaces

As an embedded developer, understanding hardware components and configurations is necessary for dealing with real-time issues. Power optimization is a key objective, given that embedded devices often rely on battery power. Similarly, mobile developers need to understand hardware configuration to troubleshoot communication failures and connectivity issues. Also, battery-related issues can bring down mobile applications, and knowledge of power optimization is essential to help track and resolve battery-related issues, as it can be the difference between a successful or underperforming app. 

## Handling interrupts and callbacks

Handling interrupts is common in embedded development, where a single device can handle multiple events, such as timers, buttons, and sensors. Since every interrupt is important and any of them can happen at any time, it is essential to have strong knowledge and a deep understanding of how to handle them properly. In mobile development, user inputs are handled as interrupts. Therefore, experience in embedded development is useful in learning how to handle user events in the mobile app properly. 

Callbacks are another fundamental concept in embedded development, where they can be categorized as synchronous and asynchronous. Mastering callback handling enables developers to manage events more effectively. In mobile development, asynchronous programming is crucial since most of the user interrupts in the mobile app are event-based.

# Biggest differences:

## UI

The focus of embedded development is creating software that integrates with the system hardware. Usually, the user interface on the embedded device doesn't exist and the user can interact with the device through small screens or buttons. However, in mobile development, creating an intuitive and appealing user interface is a focused aspect of the development process. As mobile applications heavily rely on user interaction, designing a user-friendly interface is key to delivering an enjoyable user experience.

## Devices

Embedded development focuses on designing and creating software that runs on one specific device, usually having a resource-constrained environment. Most of the embedded devices are very different so the software can be used only on the device that it's made for. On the other hand, mobile development is focusing on creating software that can work on a range of devices with different hardware specifications. The user might have different devices with different screen sizes, resolutions, and processing power, so the software must be flexible enough to work on all of them. Mobile development requires more consideration of device compatibility, while embedded development can be more tailored to the specific device it's running on.

# Challenges I faced when learning mobile development

As an embedded developer, I started my career mainly using C and C++ programming languages. For mobile development, I used [JavaScript](https://www.javascript.com/) and [React Native](https://reactnative.dev/) which were unfamiliar territories. Learning a new language is always tricky at first, but as they say, practice makes perfect, and with every new task, I gained more experience and confidence in the language.

Another challenge was making an application that is working on both iOS and Android platforms. In the end, as an embedded developer, I was focused exclusively on hardware development, so there were a lot of interesting challenges with creating user interfaces. But hey, what's life without a little challenge, right? 

# Advice to embedded developers interested in learning mobile development

As always, start by focusing on the fundamentals of mobile development. Take a common framework like React Native and learn its syntax. Then, try your hand at developing a simple app like a memory game or notes app, where you can learn more about user interface and asynchronous programming. After that, give yourself a bigger challenge and make an app that uses multiple screens, databases or even a hardware integration like BLE. Remember, the best way to learn is through trial and error, so don't be afraid to make mistakes and learn from them.

In conclusion, don't let the differences between embedded and mobile development discourage you from exploring new horizons. Instead, see mobile development as an opportunity to expand your programming skills and add another layer of expertise to your repertoire. Many of the skills you've acquired as an embedded developer are transferable to mobile development, such as memory management, power optimization, and debugging techniques. Embrace this challenge and use your experience to your advantage. Good luck on your mobile development journey!

Learning JavaScript and React Native as an Embedded Developer

large_Embedded to Mobile.jpg

medium_Embedded to Mobile.jpg

small_Embedded to Mobile.jpg

thumbnail_Embedded to Mobile.jpg

Embedded to Mobile.jpg

Picture this: I'm an embedded developer who's used to working on exciting projects involving smart building management. But after some time, I decided to shake things up and venture into the world of mobile development. 

Embedded Developer's Guide To Transitioning To Mobile Development



<div style="width:70%; margin:auto;">
<h2> What are embedded systems? </h2>
Embedded systems are computer systems with a specific function within a larger system. This includes all computing systems, such as home appliances, digital watches, cameras, avionics, and medical devices, except for PCs and smartphones. When classifying embedded systems by their main computing component, two of the most common types are microcontroller (MCU) and a microprocessor (MPU/CPU) based systems. There are also DSP, FPGA and custom ASIC-based systems. 


Microcontroller-based embedded systems are typically programmed either without an operating system, known as "bare metal," or with a real-time operating system (RTOS). Microcontrollers are cost-effective, single-chip computers that include a CPU, memory, and input/output capabilities on a single integrated circuit (IC). However, their specifications are limited compared to standard PCs, with less than 1MB of RAM and less than 8MB of flash memory, and typically only one CPU core with a frequency of less than 500MHz. Many 32-bit microcontrollers today are based on ARM Cortex-M CPUs.

In contrast, microprocessor-based systems, which are based on more powerful CPUs such as ARM Cortex-A, run Linux and have specifications more similar to PCs or smartphones. These systems, known as single-board computers, feature RAM, eMMC (flash), and various peripheral chips on the board, rather than on a single IC.

![1.png](https://strapi.suprabit.eu/uploads/1_a622eb8f94.png)

While microcontroller-based systems are generally more affordable and energy-efficient than embedded Linux devices, they also have more limited computing capabilities and feature sets. This blog post will focus on the unique characteristics of microcontroller-based embedded systems. However, as part of the Internet of Things (IoT) ecosystem, modern embedded systems are expected to have a range of features such as wireless communication, internet connectivity, and advanced sensors and actuators, all while maintaining cost and power efficiency. Careful consideration of both hardware and software is crucial for the successful design and development of these devices.

<h3> Optimizing power consumption </h3>
When selecting components for a wireless embedded device, it is important to consider factors such as suitability for the intended application, software and community support, market availability and cost. The microcontroller, RF communication chip, and sensors/actuators are the main components to evaluate. Factors like deep sleep functionality, communication interfaces, security options, processing speed, and memory of the microcontroller should all be taken into account to ensure that the device's requirements are met in the most optimal way possible.

<h3>MCU</h3>
Low-power MCUs on the market can typically achieve current consumption below 1 μA in their sleep modes. Some of these include ST's STM32L0xx, Silicon Labs' C8051F98x, Microchip's SAM Lx and TI's MSP430.
In our recent project, we used STM32L051 MCU and in its Stop mode, we were able to achieve 1.3 μA with Low Power Timer and Watchdog running.



 ![Microchip.png](https://strapi.suprabit.eu/uploads/Microchip_a7739c6ed3.png)


<h3> RF communication chip </h3>
When choosing an RF communication chip, it's important to select an appropriate wireless communication protocol that takes into account factors such as power consumption, range, and throughput. Factors that will affect the power consumption of the device are protocol frequency (sub-GHz, 2.4 GHz, 5 GHz, etc.), data packet length, the number of messages being sent within a certain timeframe, and signal power. Operating frequency affects range, power consumption, and throughput. Lower frequencies (sub-GHz) have better range and lower power consumption, while higher frequencies have better throughput. It's essential to keep the number of messages sent within a certain timeframe as low as possible for battery-powered devices, usually 1-2 messages every 10+ minutes. Smaller data packet length increases the throughput and power efficiency of a protocol, as it takes less time to transmit information and keeps the RF transceiver in active mode. With greater power, the range is increased, but so is power consumption. Low-power RF chips on the market can typically achieve current consumption in the nA or few μA range in their sleep modes, making them a good choice for battery-powered devices. In our recent project, we used AX5243 sub-GHz RF chip at 868 MHz with a custom protocol. In its Powerdown mode, we were able to achieve 0.8 μA.

![2.png](https://strapi.suprabit.eu/uploads/2_d19cc36535.png)
When choosing sensors/actuators, their idle current consumption should also ideally be in nA or worst-case few μA range.

Besides hardware, software choices and optimizations can also greatly affect the power consumption of a device; choosing the appropriate sleep mode of the MCU and RF chip, minimizing time spent in running mode of the MCU and RF chip, using only the lowest-power MCU timer while the device is in idle mode, setting MCU peripherals in low-power mode, etc.



<h5>Here are some important takeaways from our recent project with STM32L051:</h5>
<div style="background-color: #1D3656; padding:10px; border-radius: 4px; width:70%; margin:auto;">

</div>

<div style="background-color: #1D3656; padding:10px; border-radius: 4px; width:70%; margin:auto;">
<ul style="font-size:16px;">
<li  style="color:#ffffff">setting all unused GPIOs as analog inputs has reduced average current consumption by a few μA</li>
<br/>
<li style="color:#ffffff">ADC needed to be powered off after each measurement, otherwise it would add ~35 μA to average current consumption in sleep mode </li>
<br/>
<li style="color:#ffffff">although Standby mode has the lowest current consumption, in this mode SRAM and register contents are lost and only certain GPIOs can wake up MCU, so we've used Stop mode</li>
<br/>
<li style="color:#ffffff">in Stop mode, LSI is the only oscillator that works (and only timers whose clock source is LSI can work</li>
<br/>
<li style="color:#ffffff">LSI is unprecise, but it can be calibrated using an internal MSI oscillator and more precise e.g. periodic interval measurements can be achieved</li>
</ul> 
</div>




Wireless embedded devices transmit data in periodic intervals and spend the rest of the time in sleep mode, which minimizes the amount of time the microcontroller and RF transceiver are running and consuming power. However, if the running time is too long, it can significantly impact the average power consumption and shorten the device's battery life. To optimize power consumption, it's important to keep the duration of running time to a minimum, whether due to a periodic interval or an interrupt.


<h5>Here are some methods that we've used to minimize the duration of running time: </h5>
<div style="background-color: #1D3656; padding:10px; border-radius: 4px; width:70%; margin:auto;">
<ul style="font-size:16px;">
<li  style="color:#ffffff">compiler optimizations</li>
<br/>
<li style="color:#ffffff"> removing printfs/serial outputs  </li>
<br/>
<li style="color:#ffffff">making sure there's no polling or register flag checking that keeps device in running mode</li>
<br/>
<li style="color:#ffffff">checking whether higher MCU frequency (with higher current consumption, but shorter processing time) is better for power consumption</li>
<br/>
<li style="color:#ffffff">using constants/hard coded values instead of calculations if possible</li>
</ul> 
</div>

It's important to select an RTOS mode that is optimized for low power consumption, especially as the number of features increases, as RTOS is often required in such cases.

Finally, tools that we've used to measure current consumption are Otii Arc and a multimeter (just to double-check Otii Arc measurements). Also, it's useful to have measurement ports on PCB for measuring the current consumption of certain components separately (MCU, RF transceiver, sensors).

![pic1.png](https://strapi.suprabit.eu/uploads/pic1_6e7794a3ee.png)


With whole PCB average current consumption being under 5 μA (idle mode consumption below 2.5 μA), these devices can ideally last on one e.g. CR2032 battery (~230 mAh) for more than 5 years.

<h2> Optimizing memory usage </h2>
As projects need to be profitable, prices of the components are very important. But with lower prices, MCUs usually also come with smaller amounts of RAM and Flash memory. For example, STM32L051 has 8 kB of RAM and 64 kB of Flash memory . As the complexity of the application increases and the feature set expands, optimizing memory usage becomes necessary for these microcontrollers.

<h5>Here are some methods of optimizing memory usage that we've used in our recent project: </h5>
<div style="background-color: #1D3656; padding:10px; border-radius: 4px; width:70%; margin:auto;">

</div>


<div style="background-color: #1D3656; padding:10px; border-radius: 4px; width:70%; margin:auto;">
<ul style="font-size:16px;">
<li  style="color:#ffffff">compiler flags</li>
<ul>

<li style="color:#ffffff; opacity: 70%;">we've used GCC's <span style="font-weight:bold">arm-none-eabi</span> toolchain: <span style="font-weight:bold">-ffunction-sections, -fdata-sections, -fno-exceptions, -fno-rtti, -Os, --specs=nano.specs</span> (for using nano version of newlib)</li>
</ul>
<br/>
<li style="color:#ffffff">check out functions with the highest memory usage and try to optimize them</li>
<ul>
<li style="color:#ffffff; opacity: 70%;">for <span style="font-weight:bold">arm-none-eabi</span> toolchain: <span style="font-weight:bold">arm-none-eabi-readelf -s elf_name.elf</span></li>
</ul>
<br/>
<li style="color:#ffffff"> disable unused RTOS features</li>
<br/>
<li style="color:#ffffff">remove unnecessary printfs</li>
<br/>
<li style="color:#ffffff">remove double and float arithmetic <span style="font-weight:bold">__aeabi_</span>functions if possible</li>
</ul> 
</div>



That wraps up this blog post on memory and power consumption optimization for microcontroller-based embedded systems. We hope it'll turn out to be helpful in your current and future embedded projects too!

</div>

large_IOT BLOG (2).png

medium_IOT BLOG (2).png

small_IOT BLOG (2).png

thumbnail_IOT BLOG (2).png

IOT BLOG (2).png

In this blog post, we'll explore various ways of optimizing power consumption and memory usage of wireless embedded devices with examples from one of our recent projects.

Optimizing power consumption and memory usage of wireless embedded devices

Blockchain


## Motivation
Modern Smart Building Management solutions are fairly complex, comprising of a number of software modules supporting a variety of, often proprietary, protocols. When you add in all the front and back-end devices, automation stations, sensors and gateways, it can all seem like a real pain in the neck. But there is a clear economic benefit as functional smart building solutions are able to optimize energy consumption, provide better living environments and better security for building occupants, bringing your business closer to achieving that net zero goal. However, there are new issues regarding data security popping up every day, due to complexity, Internet integration and, more often than usual, slow adaptation to the newest technology stack. Traditional solutions relied on private networks where security was not such a big deal, but now, as every smart building solution provider offers Internet connectivity, the security paradigm changed. That left most solutions vulnerable to inside and outside attacks as well as data breaches. On the other hand, with the advancement of the Internet, many new use cases emerged that have the potential to significantly improve the ROI of smart building management solutions and enable more building automation in favour of building occupants and investors.  

This presents an obvious need to introduce a new data infrastructure layer to your solutions that will guarantee data security and data availability within a smart building management market. 

## Lavsa
Lavsa is a decentralized storage solution for smart building management, developed using blockchain and IoT technology. Our solution is taking in a stream of data and then replicating that data to every node in a private blockchain network. The newly added data sets are hashed and the hash is published on permissionless public blockchains like Ethereum, Polygon etc. By using blockchain(s) as an additional layer of security, we are improving integrity, immutability and availability. This is a step up from the traditional database model because, in Lavsa, every piece of data is distributed across a number of nodes and additionally hashed on a public blockchain, making it virtually impossible to fake, change or delete the data. At the same time, smart contracts are used to improve data relevancy, white and black lists and support new use case scenarios.  




![blockchain.svg](https://strapi.suprabit.eu/uploads/blockchain_77fbf6c69c.svg)





## Lavsa Goals
- Put the building data security, integrity and availability at the forefront of the Smart Building and IoT initiatives
- Establish trust among stakeholders of the building automation projects
- Enable higher level of automation
- Support integration with third-party building automation and business solutions
- Enable new disruptive business models 
 

## Lavsa Use Cases

Lavsa puts the data produced by a variety of smart building devices at the forefront of the Smart Building economy enabling new disruptive business models like 
- Data monetization and data markets
- AI solutions based on relevant building data
- Regulatory compliance
- Support for ESG initiatives 
- M2M payments
- Building Automation Infrastructure As a Service

If you have any questions regarding Lavsa, or if you are interested in discussing various Smart Building use cases - feel free to [contact us](https://suprabit.eu/contact) and let's give it a thought together.



large_androfin-min.png

medium_androfin-min.png

small_androfin-min.png

thumbnail_androfin-min.png

androfin-min.png

Back in 2018., the blockchain hype started to gain traction outside of the crypto scene and a number of enthusiasts proposed using blockchain for different business use cases. We had a vision to provide every party with relevant and tamper-proof data delivered by smart building sensors and devices. That data has to be so good that somebody wants to pay for it. Once you bought it, you want to have it ready at your disposal for further processing. And you want to be sure of its integrity.

A Journey Through Designing a Smart Sensor Provisioning process: Bluetooth mesh

Embedded Developer's Guide To Transitioning To Mobile Development

Optimizing power consumption and memory usage of wireless embedded devices

Lavsa - a new kid on the Block