I presented the basic idea behind SpiderBB in my post SpiderBB - Basic Idea. Starting from this, I will explain my system design. Subsequently, I identify all different components and will outline an implementation plan.
Requirements
Parents and babysitters can use SpiderBB to get a notification whenever suspicious movements or noises come out of the crib. After notification, the receiver needs to know the situation at the crib to decide what action to take. These observations lead to the basic requirements below.
- a motion and/or noise detection
- transport notifications to the parents
- provide a live overview of the situation
High-level system design
I made a high-level overview with Excalidraw online whiteboard to sketch hand-drawn-like diagrams. Due to the simplicity of Excalidraw, the results are clean.
SpiderBBs high level design
The image above shows the three main areas that need brainwork in SpiderBB. Let us start from the end-user (parents) and follow the information flow to capture all requirements.
Client
The world today does not have one platform to access information. That also holds for SpiderBB, and therefore multiple clients are necessary to satisfy all users.
First, SpiderBB will start with a static HTML page to archive a usable state very early. The ultimate target is to provide an application for most mobile and desktop operating systems. Currently, I think the JavaFX technology is worth a try. Thanks to Gluon, a high number of operating systems are possible with the same code base. Plus, it is an excellent time to revisit Java for UI after many years ;-)
Transportation
In the system design and the requirements, we see two types of information. First, the live image to deliver the situations overview in dark red. Secondly, the backend needs to deliver notifications to the client.
For the live stream, a simple live stream over HTTP will work. Later better-performing solution may be needed, but let us stay with the simple solutions at first.
To send notifications from a server to a client, the IETF developed WebSockets in RFC 6455. WebSockets are compatible with HTTP and therefore are hopefully possible without additional configuration.
Observation
Here the crib situation needs to be observed and based on movement/noises, notifications for parents are generated.
For the observation, a camera with attached motion detection should be sufficient. For motion detection, multiple ways are possible. For SpiderBB, we will stick with a configure-other-peoples-code approach.
A small service will multiplex the information to all clients and provide information to newly connected clients. The currently hyped programming language Go is designed for multi-core network services and provides a time-saving ecosystem. This service will be an excellent opportunity to get your hands dirty and try outgo.
Development Plan
Based on the previous thoughts, I made a simple project plan.
- select used hardware, see post SpiderBB - Hardware
- identify movements via camera, see post SpiderBB - Raspberry PI Motion Detection
- store observed situation and populate changes, see post SpiderBB - Go-State-Store
For each of the development steps, I’ll publish a summarizing post and add the links here. The sources and packages will be open for everyone and published via my GitHub profile.
Summary, and what’s next?
In this post, I’ve presented the basic requirements of SpiderBB. The resulting high-level system design provides an overview of the SpiderBB system. From the system design, I’ve concluded a basic development plan.
Next, I will follow the development plan and start with the decision about the hardware in post SpiderBB - Hardware.