I recently started building a Messenger Bot. This is a series describing how I approached it and what I learned.
Why build a bot?
I had a specific problem to solve: was my rooftop solar power system working?
Wait, what does a bot have to do with power production? That sounds like a ridiculous question today. 10 years from now it won’t. Bots are going to be the future of how we interact with products and services.
In addition to solving a real problem, I chose to go down this path for several reasons:
- I wanted to understand this trend around bots: how you build them, what you could have them do
- I haven’t coded anything in years, and wanted to see what I could still accomplish
- Get my hands dirty on a bunch of new technologies like Heroku and Git (okay, these are not so new but very new to me)
Problem
My rooftop solar power system sometimes trips the circuit breaker. But there were no quick ways to be notified of a problem. The only way was by looking at my power bill. My surprise-almost-three-hundred-dollar-bill!
I had stopped looking at these bills several years ago because we are a net producer of power. I never have a bill to pay and in fact over produce by several hundred dollars a year (separate topic on how I could monetize that power). This all changed last year when our system stopped producing power for several months. This all could have been avoided.
What I need in a solution
Notifications above everything else are a must have. Alerts and monitoring. Push is way more valuable than pull in my case.
The sooner I get notified of a problem, the faster I can fix it. The faster I’m producing power again. So I need a notification channel beyond the monthly reports that the system (now finally) e-mails me.
A very secondary use case is reporting. This is a nice to have. There is a mobile app for my solar system but it’s awful. Something that summarizes reports and doesn’t ask me to log in each time would be much nicer than PG&E’s system too.
Next post I’ll talk about why I chose messenger over alternatives.