The Project
The purpose of this project is to fill a void encountered by owners of recreational vehicles. These are medium to high priced travel trailers and camper buses that can be priced up to to 1 million dollars for a very high end diesel powered bus.
This project is intended to provide a low power, completely wireless home security type of system that can be installed within these RVs with minimal effort. Place and forget for the most part is the goal. The system will consist of the standard temperature, humidity, door/window opening, water leakage/intrusion, electric water valve shutoff and just about any other environmental sensor one wishes to integrate.
This will allow the owner to monitor their coach whether it’s in storage during the off season or if they are out and about but away from the vehicle for the day or a few days. Pets can be left with the knowledge that their environment will be constantly monitored.
All of this without the need to have a permanent electrical or WiFi connection. The wireless sensors will connect to an internal network whose gateway does have some power requirements that can be satisfied via small solar panel installation for in storage use or via the the standard in coach battery supply.
While WiFi is generally available within RV parks and some state and national parks it really is only reliable within a few yards of the hot spot which may just be the park office.
This project does not use WiFi or cellular for cloud user interface platform connectivity, but rather utilizes a low power wide area network technology called LoRaWAN.
The LoRaWAN technology does not have the bandwidth capability of WiFi but can have much farther reach thus is ideal for parks and large storage lots..
Current Project StateAt this time this project is incomplete. Due to LoRaWAN access constraints and the hardware complexity of this project the initial proof of concept is not yet been totally proven out.
What follows is details of the project that have been implemented but not totally documented in time to meet the #IoTForGood contest deadlines.
Proof of concept work has been completed for each phase of the three radio technologies in use.
Sensor BLE SoC controllers have been built to support temperature sensors, water leak sensors and water valve control sensors.
An interface on to the LoRaWAN network has been developed and partially tested but not fully vetted via a real live Helium network hotspot.
An example Thingsboard dashboard has been developed, sensor data can flow to and from this dashboard.
It is our intention to continue on with this initial proof of concept and update this document as the project progresses.
On with the ProjectThe overview which follows show the general flow of the system, Sensors communicating with their gateway via 2.4Ghz. The 2.4Ghz gateway with it's temporary 9600 Baud serial connection to a LoRaWAN gateway. The LoRaWAN gateway connects to the LoRaWAN Helium cloud service via it's 902-928 Mhz radios. The Helium cloud service connects to the target application server, Thingsboard in our case, via an MQTT internet connection.
This project utilizes three different radio frequency technologies for sensor to cloud communications in this initial proof of concept stage. We will start from the sensor point of view and work our way to the cloud.
2.4 Ghz - MySensors.org frameworkThe first radio technology in the chain for device to cloud communication utilizes a Nordic NRF51822 Bluetooth Low Energy and 2.4 GHz System on a Chip (BLE SoC) radio in a wireless mesh network developed by the good folks at MySensors.org. This meshing framework can utilize several different radios in conjunction with Arduino compatible processor boards to wirelessly connect sensors to a central gateway processor.
The gateway then can communicate onto the cloud via Ethernet, MQTT, or to a local server via a standard Serial interface protocol. From the MySensors.org gateway then there is support for a good many different home device controllers.
The radio SOC used in this project is available on several form factor breakout boards. These boards are readily available from many of the typical online hobbyist outlets.
The underlying support framework for this SOC has been ported by Nordic to both the Arduino IDE and VS Code IDE (running the Platformio plug-in) products making development targeting this board a breeze. Of course for the more adventurous low level bit banging is also supported.
From Nordic Semiconductor
“ The nRF51822 is a general purpose, ultra-low power SoC ideally suited for Bluetooth® Low Energy and 2.4 GHz proprietary wireless applications. It is built around the 32-bit ARM® Cortex™-M0 CPU with 256/128 KB flash and 32/16 KB RAM. The flexible 2.4 GHz radio supports Bluetooth Low Energy and 2.4 GHz proprietary protocols, such as Gazell.”
This framework along with the SoC will be used to control the various sensors within the RV. Temperature sensors, water leakage sensors and water valve controllers have already been developed using the SoC and MySensors framework.
Three custom controller development boards, each using the NRF51822 SoC to control one of the sensor sets has been created. Each board is power via a 3, 7V Li-I\ion battery. These boards communicate the sensor data to the MySensors gateway which is also utilizing the NRF51822 SoC.
As this project is using a cloud transport mechanism that is not currently supported by MySensors.org, LoRaWAN, we will be using the aforementioned gateway configured to use its serial port transport mechanism. This is a temporary bridge to take us from the MySensors meshing world on to the target LoRa network via an ST LoRaWAN developer board.
9600 Baud - Serial Interface ProtocolRather than hard wire the serial ports of our two disparate devices together we use a small HC-12 Serial interface radio module to act as our bridge between the MySensors.org mesh network and the upstream LoRaWAN network. All traffic to/from the sensors and the cloud will traverse this serial protocol bridge.
The beauty of this interface radio is that you hook it up just as you would a serial cable connecting to a terminal, no programming required if you use the default 9600 baud transfer rate. It truly is a plug and go radio.
This is intended to be a temporary bridge. Once we have ported the MySensors.org gateway to run on the LoRa gateway host device we can remove this Serial interface from the mix.
902-928 Mhz - The Helium NetworkThe third and final radio technology this project uses is a low-power wide area network whose protocols and radio technology were developed by the Semtech consortium, commonly referred to as Lora or more specifically LoRaWan. There are several different public/private products/techniques used to connect a LoRa enabled gateway to a corresponding LoRa network and on to a cloud application server.
For this project we will be using a fairly new offering called the Helium Network. This is a relatively newcomer to the arena of providing Lora accesses. It dubs itself as the “People's Network” because the hot spots that carry the network traffic from over the air and on to the internet infrastructure are owned not by a private network provider but by the general public. Anyone can purchase one or more hotspots and help build the network. The uniqueness that Helium offers is a financial partnership, sharing the proceeds that results from network usage fees.
In addition to the Helium network hotspot devices the Helium network supports a device user interface console. The console is a cloud software network management tool that allows for configuration and monitoring of data flow to/from your edge device and the final cloud app server. The Helium network does not offer any long term data caching or storage. Other than short term caching of the down-link data due to the peculiarities of the LoRaWAN technology the Helium network is a short term data passing network. Data transfer amounts, transfer rates, connection counts and status and short term data debugging can all be accomplished using the Helium console.
STMicroelectronics B-L072Z-LRWAN1 DiscoveryTo take us from 9600 Baud serial data to the LoRaWAN network we will use a development kit put together by ST, formerly known as STMicroelectronics. This kit is referred to as the ST B-L072Z-LRWAN1 Discovery development board.
The B-L072Z-LRWAN1 Discovery board is one of many/many development boards that ST produces to help developers understand and use their products. In addition they also supply a rather large amount of runtime and sample software that covers many aspects of their development board. ST also hosts many web casts and, times permitting, live events in cities near you.
The B-L072Z-LRWAN1 supports both the LoRaWAN and SigFox wireless technologies but for this project we will use only the LoRaWAN capabilities.
There are several LoRaWAN support runtime libraries available within the Arduino development world. Refer to the reference section for links to the framework we use in this project.
Thingsboard.ioThe final part of the project is to expose the sensor data to the RV owners. At the cloud side we will use an IOT device management platform developed by “Thingsboard”, at Thingsboard.io.
This is a very powerful tool that one can use to build a multi-level hierarchy of sensor management dashboards spanning sensor installations within floors, floors within buildings, buildings within cities, cities within companies. Access to dashboards controlling each level of the organization hierarchy can be limited or opened up as dictated by company policies or privacy concerns.
We will not be utilizing the full features of the Thingsboard platform for this project as this would make the project far far too large. We will however be utilizing a few of the widgets and the dashboards for exposing the current state of our RV sensors. We will also have controls on the dashboard for updating several user level settings that our sensors support. For instance we can remotely set over-and-under temperature levels such that if the current temperature falls outside of a given range the sensors controlling SoC can report an alarm back up to the cloud.
The user may decide to change those temperature ranges depending on the season. This system allows the RV owner to do so without having to go and visit the RV itself. He/she can make those adjustments via the Thingsboard dashboard.
The Thingsboard dashboard can be configured to report alarm messages to the owner via dashboard notifications, automatically created emails or for alarms that must be addressed immediately it can integrate with text messaging or phone call services.
We will be demonstrating the ability of the sensors to upload data to Thingsboard which will dynamically update the sensor indicator widgets as well as demonstrating the ability to download some of these user settings to the sensor controlling SoC.
This is an example of one of our Thingsboard dashboards showing our sensor "test" data. We have a temperature sensor that signaling out of range, leak sensors and a couple different versions of water tank sensors.
Unfortunately the NRF breakout boards we used came with pin header spacing of 2.0 mm rather than a more standard 2.54 mm thus to begin with we used a Waveshare BLE400 carrier board. Unfortunately this board does not contain a USB to UART converter chip which would make it easy to upload your custom application. Thus in order to program it we enlisted the help of an ST Discovery board and utilized its ST-Link SWD connected to the BLE400 SWD programming interface. This arrangement did integrate fairly seamlessly with the Platformio IDE plugin running inside Microsoft VS Code IDE we used for application development.
As the project progressed and the need arose for more sensor boards we embarked on yet another learning process and built up the design for a custom developer board that would also allow us to convert to a more standard 2.54 mm pitch for the header pins. The tool we used was KiCad EDA - A Cross Platform and Open Source Electronics Design Automation Suite. As this was our first attempt at board design it quickly became apparent that we will need more design iterations before we reach a final product.
This series of pictures show the developer boards used for this project.
As we do not yet have Helium network coverage in our immediate area we utilized fake testing interfaces when we needed to utilize the network. Once we had a working model we took a field trip to where we could get actual network connection to finalize that portion of the project testing.
We for daily development we needed to fill in the missing connectivity from the ST developer board to the Helium network and also from the Helium network to the target Thingsboard UI platform.
For testing the ST Discovery board to the LoRaWAN network interfaces we utilized the Hardshare remote device emulation tool. This allowed us to test the ST development board app that we have written using a "real time" live LoRaWAN connection. As we could not connect sensors to this "real" remote device we created "canned" sensor data that the device sent on to Thingsboard once the LoRaWAN connection was confirmed during the field testing.
For the Helium network to/from Thingsboard communications we used Mosquitto MQTT publish and subscribe command line applications to emulate the normal Helium console to Thingsboard MQTT interface. This also required canned data and scripts to be used so we could continue our Thingsboard device dashboard development.
While somewhat cumbersome it did allow us to continue our development efforts which culminated in several trips to the local field office for "real" network connectivity testing. In our case the local field office is a shady parking lot not too far from the nearest Helium hotspot.
While we were not quite able to complete the full project within the time constraints we were able upload and download a small amount of test data from the sensor SoC to their gateway SoC, from there via the Serial radio to the LoRaWAN gateway onto the LoRa network to the Thingsboard dashboard in the cloud. We were also able to demonstrate down-link data going from the cloud down to the SoC sensor controllers.
What remains to be completed is buttoning up and hardening the developer proto boards, eliminating the jumper wires seen in the photos. Finishing dashboard development as well as running some hardening testing of full round trip data transfers across this entire infrastructure.
it was none the less a very rewarding experience. Utilizing LoRaWAN as a cloud transport protocol has been something we have felt would be necessary given the remote nature of the intended target audience.
The IoTForGood contest gave us the necessary drive and incentive to see if we could successfully integrate into the LoRaWAN ecosystem. On that aspect I believe we were successful.
The CodeWe are not opposed to sharing the code created for this project however time constraints have prevented us from sanitizing the code to make it suitable for publishing at this time.
Hackster.io projects of interestMySensors Implementation:
- https://www.hackster.io/leroy2le/water-sensors-using-mysensors-framework-with-onem2m-platform-3097f6
- Their 10 more projects referencing MySensors.org
HARDSHARE implementation:
Platform.io VS Code plug-in
- There are 102 Hackster projects that list Platform.io as a keyword
Lora
- There are 281 Hackster projects that list LoRa as a keyword
B-L072Z-LRWAN1
- There are 23 projects referencing the B-L072Z-LRWAN1 development board
Other references:
The Helium Network: https://www.helium.com/
ST: https://www.st.com/content/st_com/en.html
Hardshare: https://www.hardshare.io/
Platformio: https://platform.io
Thingsboard: https://thingsboard.io/
Semtech: https://www.semtech.com/
Waveshare: https://www.waveshare.com/
KiCad: https://kicad-pcb.org/
MySensors: https://www.mysensors.org/
Nordic Semiconductors: https://www.nordicsemi.com/
VSCode: https://code.visualstudio.com/
Tlera Corp LoRaWAN runtime: https://github.com/topics/tlera-corp-boards
Comments