I started off the year by working on updating some Arduino libraries to make the LiteMon Node (LN) firmware a little better. I discussed this in a previous post, but I quickly dug myself into a whole. I realized last week that I had spent so much time messing around with the updated libraries that I had made no progress on the functional parts of the project! Wowza! I hadn’t eaten my fail-early cereal! It’s time to move on to things that are more important right now.
I need to dig back into the lean development books for a better term than ‘Feature Reach’, but I’ve been using this to describe the process of pushing down the critical path toward an MVP. Last month I was definitely in a feature swamp, in which I was working on things, but not thinking about how they strategically moved the project forward.
This month, I’m being more critical about what is the smallest system I can get running. The changes I described in the previous post were quality of life, not core functionality. So I’m now being more ruthless in deprioritizing them. Only system-critical features for now. So I’ve moved to the system handling notifications. The L.N. is only responsible for uploading data to the cloud and a separate server will take care of polling the cloud data and checking whether the node is reporting correctly and if the reported data is within the appropriate limits. This component is what I want to prove next.
LiteMon Notification Sender
The LiteMon Notification Sender (L.N.S.) is the script responsible for querying influx and sending notifications to the user. It has three primary functionalities are:
- Ability to query InfluxDB for current data.
- Ability to look up client details from an SQLite database.
- Ability to send notifications through Twilio.
The basic flow of the L.N.S. is:
- Query the client database for all the active users that need their homes to be checked.
- Poll InfluxDB for the latest data for this list of installs.
- Check each data point with the limits stored in the client database.
- For all the installs that are found to be outside of the limits, gather a list of notifications details
- Send out notifications to all the users whose installs need attention.
- Generate a run log and write to the disc.
- Send a summary of the checks to me! (On a daily basis!)
The above tasks will be run at a set interval to meet the reporting promised to the user. I would suspect a run interval of 15 minutes would be suitable to spot most failures. An advantage of putting this responsibility into a server is that it can be adjusted without impacting the reporting interval of the L.N.s themselves. The interval at which the L.N.s report to the cloud will be set in the field while the units are being installed. At first, I thought this would require a third piece of software, a configuration tool that runs on my laptop. This is the approach I have used in the past, but I had forgotten that I’m dealing with a much bigger chip in the ESP32. It can run its own config tool. The only need on the PC is YAT (Yet Another Terminal).
The L.N.S. is going to be a python tool. The libraries are well flushed out and I’ve been wanting to keep practicing with Python. I slapped together independent tests for InfluxDB queries and Twilio SMS pushes in Python. Both are relatively painless. The SQLite3 database is so quick to get started with. The critical learning for me is learning best practices for laying out these databases. I suspect that a full SQL install is in the future, but I really appreciate the serverless approach to help me learn by tinkering and breaking things.
Twilio is so easy!
Nice! Look how simple this code is and it gets me a text message on my phone! So easy!
1 # Download the helper library from https://www.twilio.com/docs/python/install
2 import os
3 from twilio.rest import Client
4
5
6 # Find your Account SID and Auth Token at twilio.com/console
7 # and set the environment variables. See http://twil.io/secure
8 account_sid = 'SECRET'
9 auth_token = 'SECRET'
10 client = Client(account_sid, auth_token)
11
12 message = client.messages \
13 .create(
14 body="Hello from Litemon",
15 from_='+SECRET',
16 to='SECRET'
17 )
18
19 print(message.sid)Balancing Features
This is another great time to talk about how much development is needed for the MVP. I hinted at the start that I had already done down a rabbit hole on the command handler. Using ideas from Lean development is a good starting point. Dealing with software that is a little bit slower to config is fine for now. I know there will be a need for support around the L.N.S. to improve how quickly a fresh deployment takes and how easy the system is to maintain and monitor. The list of tasks I made higher up is the bare minimum operations of the L.N.S., but I will need some tools to add, remove, and update clients. So how far should I go in building these supports? Well right now, I’m thinking lean again, and these support tasks are not critical. I can get away with hardcoding stuff until I can identify other problems with the approach. BUT…it’s nice to think of a future where the database is on a remote server and I’m using a C# based website to interact with the database and to get a dashboard of the current installs. That’s a later task, if the product works, that’s what will be in the dev backlog. WAY down the line.
The Basic Functionality
All that being said, I took a few days to concentrate on just getting the depth of the basic functionality. Yes, things like addresses, client names, and thresholds are hard coded. But it works. I can at least get a feel for how the project could advance, and maybe even get it into the hands of someone to test.
The test setup currently consists of an ESP32 running the node firmware on my desk with a single thermistor attached. A raspberry pi 3 sitting right next to it is taking care of polling Influx and sending out text messages. I can take this chance to start thinking about the business side of things while also making a big old backlog of tasks that will fill out the features. But for now, it’s working….ish!
