Managing Raspberry via websockets
The Raspberry Pi has gained immense popularity around the world. However, many of the amateur developers are faced with the problem of accessing the device from the Internet. As a rule, you have to conjure with DDNS or buy a static IP address. Both options involve setting up a router, which is not for everyone and is not always available. In addition - the opening of direct access to the device from the Internet carries certain security risks.
An extremely common way to solve this problem is to use an intermediate server through which the server and client connect to each other.
The scheme is extremely widely used in various remote access packages: VNCViewer, AmmyyAdmin, etc.
Option 1-DDNS
Option 2 - Static IP Address
Option 3 - using an intermediate server
This connection scheme can be implemented via the MQTT over Websockets protocol, but it was interesting for me to implement something much simpler, JSON-oriented, extensible, without protocol restrictions on the message size and with a more obvious security model.
The choice of protocol was obvious. WebSocket has long been supported by browsers and most platforms and programming languages.
The data bus model is trivial:
WebSocket Server supports an unlimited number of channels. Each channel can be either open or password protected. A channel exists only while it has at least one client connected. No data is fundamentally stored on the server. The password is set by the first client connecting to the channel. Clients without a password / with an incorrect password will not be allowed into the channel.
A channel is a container for messages. Messages are of three types: address messages (commands), which are intended for one or several recipients, response messages and broadcast messages that will be received by all clients connected to the channel.
Such a scheme allows the use of common hubs for many consumers relatively safely since There is no need for settings, user generation on the server (as in MQTT), generation of access keys, etc.
Messages are not saved anywhere, they are not logged and transmitted over the wss secure protocol.
Messages are typed JSON objects. Binary information is transmitted as a Base64 encoded string.
The project code is available on GitHub , and the current hub you can find here .
The project consists of a WebSocket server on .net, a web client application that connects to the server and a python application for raspberry pi.
A web application is far from the only possible way to interact with a websocket server. For example, you can easily write a cloud client that will “listen” to webcam events and save pictures to some kind of cloud storage.
The architecture allows you to connect an unlimited number of raspberry pi and clients per channel.
For example, if you want to build some kind of security / climate control / smart home system, you can put all raspberry on one channel and send commands to all or some instances at once.
Broadcast events "broadcast" will receive all network participants.
To be continued ...
An extremely common way to solve this problem is to use an intermediate server through which the server and client connect to each other.
The scheme is extremely widely used in various remote access packages: VNCViewer, AmmyyAdmin, etc.
Option 1-DDNS
Option 2 - Static IP Address
Option 3 - using an intermediate server
This connection scheme can be implemented via the MQTT over Websockets protocol, but it was interesting for me to implement something much simpler, JSON-oriented, extensible, without protocol restrictions on the message size and with a more obvious security model.
The choice of protocol was obvious. WebSocket has long been supported by browsers and most platforms and programming languages.
The data bus model is trivial:
WebSocket Server supports an unlimited number of channels. Each channel can be either open or password protected. A channel exists only while it has at least one client connected. No data is fundamentally stored on the server. The password is set by the first client connecting to the channel. Clients without a password / with an incorrect password will not be allowed into the channel.
A channel is a container for messages. Messages are of three types: address messages (commands), which are intended for one or several recipients, response messages and broadcast messages that will be received by all clients connected to the channel.
Such a scheme allows the use of common hubs for many consumers relatively safely since There is no need for settings, user generation on the server (as in MQTT), generation of access keys, etc.
Messages are not saved anywhere, they are not logged and transmitted over the wss secure protocol.
Messages are typed JSON objects. Binary information is transmitted as a Base64 encoded string.
The project code is available on GitHub , and the current hub you can find here .
The project consists of a WebSocket server on .net, a web client application that connects to the server and a python application for raspberry pi.
A web application is far from the only possible way to interact with a websocket server. For example, you can easily write a cloud client that will “listen” to webcam events and save pictures to some kind of cloud storage.
The architecture allows you to connect an unlimited number of raspberry pi and clients per channel.
For example, if you want to build some kind of security / climate control / smart home system, you can put all raspberry on one channel and send commands to all or some instances at once.
Broadcast events "broadcast" will receive all network participants.
A few words about the features of the application
- Remote access to the file system. You can watch, download and upload pictures, sound files and other files. It’s quite convenient not to carry your entire multi-terabyte archive of photos on your phone. Well, or if you need to look for something in the archives.
- PiCamera allows you to receive an image both on demand and in webcam mode. Along with receiving sound from a microphone, it can be used as a cheap security solution. Requires a connected pi camera.
- Send sound recordings to raspberry or receive recordings from a microphone. It can be used both for some security tasks, and for voice interaction with cats or children. Requires connection to a TV / speaker and microphone, respectively.
- Turn on / off / get the focus of the TV. CEC protocol allows you to control your TV via HDMI cable. You must install cec-client on raspberry.
- Display audio and text information on the TV. This feature includes turning on and receiving focus on the TV and displaying a text message, accompanied by a sound signal. It is convenient if you need to remotely force children to do homework.
- Remote image display. If you want to surprise your family and suddenly display a photo of your adventures on a family TV, then this function is just for that. Select any picture of your PC or phone and send to raspberry.
- Obtaining data on humidity, temperature. Raspberry sends out a Broadcast message with a specified periodicity. In addition to humidity and temperature, the message contains information about the temperature and processor load, disk and memory loading. Together, the remote I / O port control can be used as a remote control of the indoor climate. A temperature sensor DHT11 ($ 1) is required to measure temperature.
- Manage I / O Ports It allows both reading information from the selected GPIO ports and outputting a signal to them. You can get the status of switches, light bulbs, ring bells, and through the relay control some more serious devices.
- Remote start of commands allows to execute any shell commands on raspberry. For example, start viewing a photo album or movie. If such an opportunity seems unsafe for you, this function can be disabled.
To be continued ...