DesignSpark Electrical Logolinkedin
Menu Search
Ask a Question
  • Home
  • Community
  • Competitions
  • *WINNING ENTRY* Cypress Design Challenge – Swarm Style Decentralised Greenhouse Control System

*WINNING ENTRY* Cypress Design Challenge – Swarm Style Decentralised Greenhouse Control System

The Greenhouse


I was very excited to hear about the release of Cypress Semiconductor’s latest series of development kits, implementing the latest flavour of Bluetooth also known as Bluetooth Mesh. Having experimented with Bluetooth for connected robotics and domestic IoT systems in the past, I was very keen to see the limits of the new mesh networking stack. I have some experience working with mesh networks that stem from my experimentation with automotive CANBUS, this helped me realise the potential of the Bluetooth Mesh standard to be used in a similarly high reliability, decentralised control system.

With this in mind, I wanted to experiment with its capability to implement a swarm style decentralised control system, where each node contributes a small amount to a larger controlling function. This design choice was derived from the idea behind of swarm robotics, where small robots perform simple tasks that form part of a larger collective operation. To realise this, I would focus my project around the CYBT-213043-MESH development kit and use the series of on-board sensors to develop a swarm of environmental monitoring nodes for use in a decentralised greenhouse automation system.CYBT-213043-MESH Development Kit

My aim was to use the Bluetooth Mesh stack to create a network format for each node to share and compare data on while using standard deviation to democratically determine the best operation of any irrigation and ventilation control equipment placed around the greenhouse. This would also give rise to the detection of any false positives generated by any one node and maintain the reliability of the greenhouse to ensure the health of its respective plants.

Decentralised Swarm Control System

Bill of Materials

  • CYBT-213043-MESH boards x4
  • CYW920819EVB-02 board x1
  • Soil moisture sensor modules x4
  • Humidity sensor modules x4
  • Irrigation kit, nozzles, 6mm hose and faucet adaptor x1
  • 24v mains adaptor x1
  • 24v solenoid valve with 6mm push fittings x4
  • Plastic planters x 4


  • Modus Toolbox and Bluetooth SDK 1.4
  • Putty Terminal
  • MeshController Android App
  • CySmart Android App


Development Log


The new features of the Bluetooth Mesh standard are predominantly centred around the application layer where the lower transport layers are still mostly dependent on Bluetooth Low Energy advisements. This is an effort by the Bluetooth Special Interest Group (SIG) to maintain backward compatibility with legacy Bluetooth standards. What I found unintuitive about this, however, was the decision to maintain the client-server network architecture and base the application layer around the use of a predefined series of specific functional models in contrast to a single general-purpose transceiver model much like in many other mesh style networks. As I based my stage-one application on this assumption, I found this to be a main point of contention throughout the project.

The primary objective of the build process then was to define or extend a Bluetooth model that would allow each node to send messages to the transport layer independently while monitoring the network for other broadcasting nodes and build a cache of historic data from each unique network address. This data could then be used to define an optimised set of operating parameters for the greenhouse’s irrigation and ventilation systems while mitigating the need for a central controller.

Bluetooth Mesh Vendor Specific Template

After several weeks experimenting with the GitHub demo code samples, I was able to use the vendor-specific snippet to derive a new model that could handle network events in slightly more detail than the model-specific message handlers. I was also able to define a transmission timer to periodically broadcast local sensor data to the network for the other nodes to read. By filtering the source addresses of any messages on the network, each node could theoretically build up a local cache of historic data to compare against its own and control the greenhouse based on the averages of each sensor type.

However, the limitations of this project were discovered when each node was required to define original messages periodically on the network using the Bluetooth Mesh client functions. To call these functions a reference to the network provisioning data was required, such as the application encryption key. Surprisingly, the WICED framework does not seem to provide a top-level reference to these arguments and currently only supports interaction with the Bluetooth stack through a series of vague functions and event callbacks.

Despite my queries on the Cypress forum and scrolling through the documentation, the only apparent way to gain access to these arguments on the top-level is to create the network locally, but given the fact I was using the Android app to provision several identical nodes on the same network, this did not seem possible either. This condition seemed to limit the potential for mesh networking topologies quite significantly and ultimately meant I was unable to continue with my intended project.

See GitHub repository for annotated code


I decided to utilise the remaining time to experiment with the CYW920819EVB-02 development board to see if I could continue on a tangent and learn more about the issues I had been having. My objective this time was to use the Bluetooth Low Energy stack to define a GATT service that could monitor and report on the operation of the greenhouse irrigation and ventilation systems while providing user-definable characteristics over a smartphone app.CYW920819EVB-02 Development Kit

Bluetooth Low Energy Monitoring and Control System

Bluetooth Low Energy Empty Template

To do this I used the empty Bluetooth app demo code to create a user-specific GATT profile. This was tricky at first as I needed to fix the errors in the demo code which did not inspire a lot of confidence, but having done this I was then able to easily use the Modus Toolbox configuration wizard to define my wireless services - one for reading live sensor values and the other for writing any target parameters.

Bluetooth Low Energy Empty Template Compilation Errors

The demo code did make it easy to define the required functions to initialise any advertisements and event handlers which made picking up these services using the CySmart Android App relatively straight-forward. However, while trying to update the characteristic values shown on the CySmart app I continuously encountered a “value out of bounds” GATT error from the Bluetooth stack and while trying to determine if the error was a user, WICED or Android error with the putty terminal traces, I eventually ran out of time before the submission deadline and was unable to continue.

See GitHub repository for annotated code


Having started this project in early July after some shipping delay, I have spent the last two months experimenting with the Cypress Semiconductor Bluetooth Mesh development kits, spending a majority of my free time trying to realise an engaging and thought-provoking application of this exciting new IoT technology. While it has been beneficial to learn all about the architecture of the new standard from the online resources and application notes provided by Cypress, the lack of progress I have made within their development environment has been disappointing, especially given my aspirations for the project documented in this article.

A large part of this slow progress has been due to the steep learning curve of the WICED framework which, despite its seemingly higher-level abstraction, appears messy and incomplete in places where perhaps it may still be in early stages of development. This was most notable when I failed to find the arguments required to call important network functions as well as having to amend the example code in one instance. The Modus Toolbox IDE could also use some amending as it was quite difficult to develop my code without a working debug or trace window that wasn’t third-party.

My lack of progress has been frustrating in places especially where it shares many similarities to my Leak-Killer Design Challenge project I completed a few years ago, which implemented a fully working control system, Bluetooth, Android app and CANBUS mesh network under a similar time-scale. Whereas despite my ambitions for this project, I wasn't even able to get past the software limitations to build any of the accompanying hardware.

Despite my frustrations, testing the limitations of the new Bluetooth stack and the Cypress Semiconductor development environment has been an informative exercise and I have developed my understanding of both the Bluetooth Mesh and Low Energy architectures. I still believe that Bluetooth Mesh has a strong potential to implement swarm style control systems and I will more than likely pick this up in a later robotics or domestic automation project.

I have also learned a great deal about the Cypress Semiconductor development hardware and their software environment and I would be open for further discussions with their design team to give feedback and hear their recommendations for any future projects.

Editor's Note

Congratulations Electric Josh on your entry to the Cypress Semiconductor Design Challenge, in partnership with DesignSpark. The judges have awarded you first place! Well done and thank you for taking part.

A keen electronic engineer with a passion for automotive systems and autonomous robotics. A progressive love of cars, engines and classic mechanics. Advocate for clean energy, transport and alternative fuels. Compulsive tea drinker. BrightSpark 2017. BEng MIET

22 Sep 2019, 11:07