SHOWCASING EMBEDDED AND MOBILE DEVELOPMENT SKILLS IN IOT PROTOTYPING
GlazeAlarm, Coderus - and an exciting IoT project
Large, glazed areas have always been easy targets for intruders – but GlazeAlarm – based alongside Coderus at the Innovation Martlesham tech cluster, is determined to change all that. Combining IoT wireless sensors with an end-to-end software development solution from Coderus, property owners can now take a proactive role in looking after their properties.
The idea: embed a sensor (The GlazeAlarm®) inside a double-glazed panel and each time it is disturbed (say, by an intruder touching the glass), Coderus’ embedded technology sends a message to the owners’ mobile device. Complemented by a security camera and a loud burglar alarm for example helps owners significantly increase the likelihood of a break-in, before it actually happens.
And it’s not just a deterrent for burglars: the system measures shock, temperature and humidity inside the unit, allowing owners to monitor events by exception and take preventative action over something that doesn’t look 'quite right'.
About the sensor
The IoT wireless sensor system is built into a double-glazed unit and interrelates with the user via their choice of mobile device. Its patent-pending technology provides a real-time version of events, providing valuable information wherever the user is based – at any time of day or night.
GlazeAlarm came to Coderus to provide an end-to-end software solution for a working prototype. The task was two-fold: to develop embedded software for the integrated sensor, and a companion mobile app that would liaise seamlessly with it.
As well as advising on intrusion and breakage, the app would also report on a variety of other useful factors, for example, if the temperature within the glazed area exceeded set limits. This project combined Coderus’ expertise in embedded and mobile tech development - a perfect showcase!
App: To suit a variety of users, the app needed to be optimised for use on smartphone, tablet and desktop across any device of the users’ choice. A simple user interface was key to allow users to remotely view and configure the system. The challenge was to develop an application that delivered a great user experience across multiple platforms while retaining platform specific features and benefits.
Controller: The first challenge was deciding which embedded platform to use. The client had invested in the Samsung OK6410 platform, and made some progress with it. However, due to its higher levels of support, we dropped this in favour of Raspberry Pi. This would provide the ideal platform for prototyping, allowing a proof of concept to be built at rapid speed. Should GlazeAlarm progress to commercial manufacturing in the future, then it would also provide some reusable elements for its progression to a fully secure, System on Chip circuit.
App: The mobile app discovers the controller systems via SSDP, using a REST API to communicate with the system, and to set/unset the alarm. To work across multiple mobile platforms, we chose Xamarin. This allowed us to create a large amount of shared reusable code with in-built logic, with platform-specific code specifying UI and interaction with the OS. MvvmCross was chosen to provide extra capability including databinding and dependency injection.
Controller: we split the development stages in two; C activities were handled by one developer and Node by another. Multiple services in each language were used to ensure a stable system. C was chosen for the lower level applications – providing flexible system access – and Node for the higher level, with a plan to move to the server for final project deployment. For the web framework, we chose Express for its high-quality maintenance levels and suitability for this project type.
The remaining technical specifications and corresponding benefits are as follows:
Mutexify: used for mutex locks – used to lock access to specific resources during the execution of a particular code block, providing version control.
Achingbrain’s SSDP Broadcaster for Node: used by the server to broadcast the presence of the controller.
CMocka: used for unit testing – and to verify whether changes would break any previous code before getting to the stage of testing a full build – ensuring early identification and fixes.
The app and controller were built simultaneously and the project delivered to an agile methodology to ensure that a POC was built in time and to the clients’ expectations.
The deliverables were split into sprints, each cumulating with client testing before moving to the next. The Morgan logging system– which displays information about HTTP requests sent/received by the API server – kept an accurate log of re quests to the alarm state, enabling issues to be quickly identified and rectified.
The prototype system was developed on-time allowing GlazeAlarm to demonstrate its system at Glasstec and to make valuable value propositions to both consumers and distributors.