redis pub/sub with websockets - part IV
Date: 2021-02-15
Author: Andrew
So the brainwave was put on hold for a day (see the previous post). When I did get back to the keyboard today it took all of 10 second to write the code and it worked first time! Hurrah!
Expanded it a little bit to use the GPIO libraries CPUTemperature() function. To do that I had to stop and think about how I was going to structure my services/messages.
As I see it there are a number of different ways to design the setup:
- I could go one service per piece of information i.e. one for the ram, one for the cpu temperature, one for the gps and so on. Each one would be its own channel and the listener would need to subscribe to them all. Then the message is passed onto the websocket and the client side code would interpret and update the UI. This keep things light on the UI side as I could write a function in a couple of lines of code that could handle any incoming message.
- The other end of the spectrum would be to have one service that does everything and publishes on only one channel. At some point you are going to need the listener or the client to parse the entire message and work out what needs to be updated.
Option One means a lot of fiddly services to manage and as I have learnt it is easy to disable a service during development only to forget to set it up again at a later date. The second option just feels wasteful of resources as there is a lot of redundant information being passed. Plus it's probably going to end up with multiple layers of nesting in the json which means more work parsing the message at listener or client.
The option I decide on is a middle ground. The information for the UI will be logically grouped into channels that means only one layer of json and a service for each wil be created. The breakdown is like this:
| Service | redis Channel | Notes |
| br-redis-pi-stats.service | pi-stats | Total ram, free ram, cpu temperature, disk space free |
| br-redis-bb_version.service | bb_version | Operating system, Robot version. This will only be triggered once on start as it won't change for the entire session. |
| br-redis-gps.service | gps | Latitude, longitude. |
| br-redis-m6050.service | m6050 | Angle x, y, z, Acceleration x, y, z. |
Each script will be writing to a log as well e.g. the br-redis-gps.service will write the entire NMEA string to a log file so if necessary I can recover any info that I need at a later date for analysis.
So a few things to clean up. Thinking I'll probably find more things to add along the way, especially when we start trying to control the robot speed and direction from the UI!