How I saved my Raspberry IoT Edge host going into Denial-Of-Service (DoS) mode

Setup of IoT system

I was using a Raspberry-Pi #B (35$ ARM processor, RPi) for home autoamation running as edge router/server . I have a customized golang server that connects to my IoT sensors and updates to postgres DB (previously I used TICK stack , but I had Influxdb corruption issues, so I switched to postgres DB). All of these apps are hosted in docker-instances inside the RPi.  I still use Graphana as front-end GUI (after I added the postgres as datasource to Grapahana). 

Disk configuration to separate OS with applications

To safegaurd RPi going to Denial-Of-Service mode due to root disk-starvation, I have used extra USB-stick for customized-Apps, Postgress DB, Graphana and other docker instances. In this way, if any applications (including graphana, postgres, influx,  customized apps) fills-up disk , one can still access RPi as RPi's SD-Card  is still in good-shape (wrt to disk space).

Telegram-Bot integration

Recently I have added support for Telegram-Bot integration with my RPi , so that I can communicate to my RPi outside my home WiFI network. The integration went well and I can issue commands from Telegram app and handle in RPi (evetually I can reach my sensors). 

Telegram-Bot transient error cauing DoS situation

Everything went fine till I switched off my home WiFi network in home. The moment I switched off WiFi network, the third party Telegram-Bot framework started to fills up the USB-Disk (which is shared by docker instances, customized apps,etc) as my customized-app's stdout/stderr are routed to USB-disk (for debugging/post-mortem-analysis). Within 12 hours of night time, 8GB of data is filled up. If this fillup is continued, within another 12 hours all of my docker instances (postgres, graphana and my customized app will have DoS siatuation.

Solution

To mitigate the above DoS situation, I could route the stdout/stderr to /dev/null, but I will lose information in case of critical errors(apart from this error) from third-party-code-bases and any unhandled golang's stack-traces and panic outputs.

For handling all the above tricky situations, I have written small golang application named safeout that consumes stdout/stderr of any number of processes and redirects the output of each stdout/stderr into disk-files with checks on maximum size (with one backup file). 

I configured my customized application with above safeout . Now myApp (or any other app in docker instance ) starts redirecting  stdout/stderr to disk, they will not fill-up disk (as safeout will ensure maximum disk space limits are honored with one backup copy)

safeout Code is at Safeout

5$ TV Remote Control Using Smart Phone

I have following goals for controlling my Infrared Controlled Appliances:

• Towards the goal of the controlling my TV, Set-Top-Boxes,AC,etc, at lower cost less than 5$ (or even go less in case one has  more IR appliances or one has already a raspberry/chip in home for Home Automation/IoT works) per device. I am leaving the cost of central controller, whose cost would be around 9$.
• Design/Develop an Open Sourced system like LIRC project that controls the IR appliances using smartphone and WiFi(there by avoiding line of contact issues in IR based remote controls)
• Make any old TV(including CRT TV and LED TVs that are not smart TVs,etc) to be  controlled from any smart phone
• Also ensure that smartphone SHOULD not require  IR  based emitter (as smartphones with IR transmitter are little costlier)

To achieve these goals,  I have designed and tested initial version of my Centralized Home IR Appliances control system that can adapt and control different IR appliances at very cheap cost. The system has following features:

• It is cheap
• It Generic and one can add any number of IR devices
• All one has to for adding new IR appliance is to add the IR codes in form of property file
• Works with most of the smartphone (at present only android phones)
• Gives generic REST based interfaces to control these appliances (TODO)
• Gives generic RBAC control of these IR appliances (TODO)

For implementing initial working prototype, I chose:

• Common costs for all IR appliances in a Home
• 9$ Chip Computer as central control system where all Smart Phones sends commands . This device is common for all IR appliances in home (that are in same WiFi network). Though  I have chose 9$ chip-computer, once can use Raspberry-PI or any computer that run python.

2A Power supply for each IR transmitter 2$ (approximate)

• Per IR appliance costs for IR Transmission
• For each IR appliance, I have put one ESP8266 device to send IR commands (which costed me 2.82$). For each IR appliance , we need to this board (in case if both appliances are not in same IR visibility)
• I bought one IR Transmitter for 1.1$ (approximate) 
• Power supply for each IR transmitter 1.1$ (approximate)

At present the system control my TV and set-top-box. In future, I am going add more devices like my LG-Air-Conditioner

I have put code in 3 projects in Git-Hub:

• Java based SW application named TVRemote ( Android Application that controls my TV and my set-top-box)
• C++ Based embedded Firmware Infrared-Command-Sender for sending IR based commands from ESP8266 
• Python-Based Centralized Server for controlling all IR appliances running on 9$ Chip computer

Data mining by Python script to get data from 9$ Chip's battery health

I got finally my 9$ chip boards. Fortunately this boards comes with LiPo battery connector and charging IC (named axp209). One can query this chip's i2c subsystem by i2cget/ic2set commands to get the data about system's battery status like:

• Battery voltage
• Charging current
• Battery connected
• Battery charging
• etc

NTC provides a shell script that fetches above data. But running this script in daemon mode and collecting data from multiple chips (which are in network) would put  strain on CPU/battery resources of chip as this script executes almost 50 unix processes for getting 10 sensor values and it also might drain battery (when main power goes off AND monitoring scripts should not drain resources).

As I am going to monitor system using other python scripts as well, I started porting the axp209 script to python script using i2c-tools/py-smbus module. But this porting does not work in  python as smbus python-module does not provide forceful read/write of i2c-device addresses (for safe reasons). 

Similar options were provided in command line tools of  i2c-tools (like i2cget, i2cset, etc). So I have hacked  i2c-modules/py-smbus code and changed/added 3 lines to get similar forceful opening in smbus module of python.

Changed i2c-tools/py-smbus code is at github

Using the above  modified smbus module, I wrote python script that collects 9$ chip data in daemon mode. Source code is at github

This changed i2c-tools/py-smbus code can be used for raspberry pi as well (one has to change i2c-bus and device addresses accordingly)

Warning: Developer should be aware that forceful read/write of i2c devices can lead to dangerous consequences (if done unknowingly/inappropriately/etc). So developer is responsible for using this changed code :)

Launchpad can survive on 1000mAh LiPo battery for 1.5 years with Radio Link to RPi board

So after last few days of work on data serialization across Rpi & LaunchPad (MSP430G2553), I integrated the Serialization library that sends couple of 32-bit /16-bit integers from MCU to RPi via NRF24L01+ chip.

Initially MCU was raking around 230uA current . After some tweaking, it came down 130uA .

As final optimization (for this round of testing), I shutdown the NRF24L01+ chip till next time radio-packet-transmission. This step lead to MCU current consumption of 25uA . So in this period (approximate 12 seconds) MCU is in LPM3 sleep-state and radio is in shutdown-state. When MCU wakes-up, it activates NRF chip again & sends radio-packets, during this tx-period, it takes around 400uA for a breif period.


So taking on average current consumption of 50uA (including radio-packet-tx current bump), using battery life calculator for 1000mAh LiPO battery's life is around 14000hours (583 days). Not bad for a starter project :)

I have just documented the initial video for the same at youtube .


I will be submitting the code in github in coming days after stabilization and cleanups.
I will do same test for MSP430F5969 (FRAM board with Super capacitor on it).

Finally able to make Raspberry to talk to MSP430 via NRF24L01+

As a part of my future IoT projects, I was trying to create reusable libraries and utilities for Arduino, MSP430, PIC, Freescale and STM32 processors using Nordic NRF24L01+ wireless transceiver chip. Ultimate goal is to make cheap sensors (that cost less than 7 to10$ including sensors & batteries) that could be deployed in any IoT, HomeAutomation, etc projects. I was planning to use Raspberry (or any cheap Linux board or cheap Android sticks -- future goal)  as my central observer of these cheap nodes.

Here are some  major tasks that were necessary (apart from HW):

• Circuit diagrams that make connectivity
• FW for Linux box and MCUs
• A Data Serialization library for MCUs and Linux box

After lots of trials and tribulations (with limited amount free time after my office/home jobs), I was able to talk Raspberry with following devices (in initial setup scenarios):

• MSP430 LaunchPad with MSP430G2553
• MSP430FR5969 LaunchPad

Idea is to make Raspberry as to receive the radio packets from all sensors ( MSP430s, Arduinos, PICs,etc) and this Raspberry connected to network via LAN and WiFi.

As a next step for proper communication along these wide variety of MCUs with different endianness, I need to create small library in C/C++ for packing all types integers (uint8_t, int8_t, uint16_t, int16_t, uint32_t, int32_t ) and chars.  As I could not get this from web (with whatever search strings I gave), so I created  small library for doing this job. At present this works on Linux (so that Raspberry can understand what wireless nodes are sending), MSP430G2553 and MSP430FR5969. All UT was done for most generic corner cases, I shall be using this for my home IoT framework.

Once I finish more tests and my system, I will publish code at github:

• Raspberry to MSP430G2553 
• Raspberry to MSP430FR5969
• Generic C based Data-Serialization library for Linux/MCUs

I will also publish circuit diagrams for:

• Raspberry to NRF24L01+
• MSP430FR5969 to  NRF24L01+
• MSP430G2553 to  NRF24L01+

Home Access Control System

I was planning a Home Access Control System for lots of days. Finally got some time over past few months. Finally I finished version-2 of my Home Access Control System.

Current version uses Raspberry for controlling the Main Door lock. Client are: Smartphones and RFID keys.

At present, I have written Android client for controlling. But the system is capable to handle iOS/WinPhones.

I will add more photos and code in coming weeks. More info can be found at at this place