Close

Log 6: Adding Control

A project log for SmartSoak

Maximize hot tub enjoyment, minimize cost

alexwhittemorealexwhittemore 09/10/2019 at 06:420 Comments

Ok ok so with a toe dipped into the waters of IoT, I decided that a full-blown IoT/industrial control platform was totally necessary, so why not bring out the big guns and use a Raspberry Pi with Node Red?

But first, a Chinese Amazon seller sent me this cheap temperature controller to play with, so I decided I would do that.

It worked well until it exploded!

Full story here: https://www.alexwhittemore.com/adventure-with-a-cheap-amazon-temperature-controller/

So on to the REAL system.

Obviously the system is going to need telemetry, so the main controller would have to have a wifi chipset. I thought about using the same ESP32 and building a controller around that, but I decided not to for a few reasons:

  1. Embedded software is tricky. If you get it wrong, it has a tendency to run out of memory and fail. Testing is a little difficult, since you can run into unhandled states that crash the system and don't output logs to figure out what happened. How many times have you written an Arduino sketch with improper handling of millis() that worked great for a few days then suddenly blew up?
  2. Embedded devices are slower to iterate. For the most part, I can't just log in remotely to look at state of operation and activity, and make changes in real-time as I please.
  3. Embedded devices leave everything up to YOU. Need an interface? Make and wire a board full of buttons, LEDs, and maybe an LCD. Then build the logic and/or graphics for that. Need new connectivity? Hope you have program memory space left!

In contrast, there are much easier options. For one, a Raspberry Pi seems like a great choice - an embedded linux box with connectivity up the wazoo that will work with whatever sensors and whatever application layer frameworks and languages you like. Control scheme not working? SSH in and have a look at the logs. Make some quick changes in Python and restart the service. Easy.

On top of that, I've seen Node-RED kicking around for a while now and I've always wanted a chance to kick the tires and see what it's all about. This seemed like a perfect opportunity. As it turns out, Node-RED is, in my opinion, nearly perfect for this kind of process control scenario. I can't say for sure that it IS, but it sure feels like it protects you from some of the logical and flow control gotchas of programming a controller in code. For instance, there are multiple tasks to keep track of - do you build a runloop architecture? Scheduler architecture? Use true multithreading? Run each thing in its own process and hope contention for the physical resources doesn't become a problem? Node-RED's visual and message flow-based design takes a lot of these decisions off the table from the get-go, and when you run into problems that are more difficult to solve with that kind of methodology, you CAN add in some custom code easily enough.

Discussions