LoT thing - "smart" power strip and environment
Posted: Thu Apr 13, 2017 1:41 pm
This isn't the fanciest or most exotic thing, nor is it completely done, but it's a good base for stuff. This is a switched outlet power strip that also happens to monitor temperature and RH, since it kinda came along free. I had a well-used Ada ESP 8266 Feather Huzzah board, burned plenty of times that I used for development. At some point, it's the better part of valor to just put these into some project, before wearing out the flash...(yes, I know it's better these days, but). I like the USB support on this as a way to easily change the code in the field and kind of don't mind the extra cost, as I'm not product-izing this. If I were there are a couple things I'd do differently, but this one's just for me - and for you if you want to use this code and design.
One thing I would do differently if making this for public consumption is to use the wifi-manager library. This has the ESP 8266 default to being an access point if it can't find the hardcoded WAP in the connect parameters. It would be a great way for Joe Consumer to get it going on his LAN. It's also an attack vector if you think paranoid, as failure to connect makes it open to anyone to set up differently and spoof being you to the thing. Here, I just wanted it to work in one known spot, the shop, anyway, so I didn't mess with that yet. But it's out there if someone wants to do it - the link is to a Hackaday page describing the library.
The other thing I'd probably do differently is use 1 or two relays instead of a 4 relay board. If the whole point of wireless is fewer wires, having 4 switched power points co-located just means having a bunch of long power wires instead for most use-cases. Also, MPJA doesn't sell this cheap board anymore and only has the one or two holers. You may or may not want to put in the weather stuff, here an SHT-31 breakout, but I had it laying around and more data about the rooms in a remote building will help me decide whether to run fans or AC over there without having to hoof it over there to constantly check conditions. And now I have a way to turn these things on and off remotely. I will likely put the exhaust fan and the water collector booster pump on this, along with it's real use here - powering up and down the fusor data aq and cameras, again, remotely. Sometimes if things are really locked up, remote desktop won't get you a real robust reboot, and you might still want to turn things off for the night, and not have to hoof it over there to switch that power off and on just to do some dev work (which is always in progress with something like that).
I found a fairly nice "work box" the right size at Lowes. The main electronics fit easily in this, and lo and behold, there's even PCB retention/guide slots in this thing! However, when casting around for an AC adapter to run it all, well, even the small ones are on the large size. I pulled about the crummiest small one out of my junk box, and when I cut it open to just use the guts, I got a surprise on how they did this. It appears to be some kind of Royer oscillator running right off the line! The output (there is no feedback) is just half wave rectified off the secondary of the transformer (ferrite core) so to get any regulation at all - it's rated for either 120 or 240v - it must be doing something slightly tricky using core saturation for more than one thing.
There are just no parts there. The one diode marked zener is on the primary side of things. Here's a picture for your info. Whatever, the thing works for this just fine. On to the main show - it looks like this, when buttoned up it just looks like a sloppy hand made power strip: As far as the UI is concerned, it looks like this: And the relay control/status page looks like this: The relay status is shown both on the main page and on this page when you navigate here - the CGI checks the boxes for the active relays.
The code is more or less standard for here. This implements my LANDNS stuff, using the "good luck changing this" ESP machine name which is ESP_(last 3 bytes of MAC as hex).
This broadcasts the machine name and IP on the subnet on UDP port 53831, and shouldn't bother your LAN if you're not using my code to listen for this, or at least, it doesn't bother mine.
It emits a web page at TCP/IP port 80, nothing special there. I have it showing the last 24 hours of temperature and humidity as plots via SVG graphics, which kind of makes your browser do the work. As mentioned in the code, this could be done better and faster if someone used the polyline commands instead of line...line...line, but this works.
The CGI page, /controls, creates the checkboxes and fills them in with current state. An improvement might be to make this persistent across boots with eeprom. Then again, coming up or failing in the off state seems fairly safe. So...less work, safer, I'm not fixing what I don't see as broken.
So, this is a reasonable codebase for ESP-8266 "things" for my Lan of Things projects around here. Other "things" are often Raspberry Pies, but sometimes that's total overkill, and these are both cheaper in bucks and in power use.
And of course, the real purpose of this post is to share and also have offsite backup (someday I'll get serious about github, but till then..). Down the road a little (and things like this are why I made sure this would be easy to shove new code into) it might seem good to put another interface on this, say UDP at some other odd port (42042 comes to mind as the answer). Right now the only way to command this is via the web page or by pretending to submit to the existing page. It'd be easier to do programmatically, at least for me, to just have a port I could send messages to.
One thing I would do differently if making this for public consumption is to use the wifi-manager library. This has the ESP 8266 default to being an access point if it can't find the hardcoded WAP in the connect parameters. It would be a great way for Joe Consumer to get it going on his LAN. It's also an attack vector if you think paranoid, as failure to connect makes it open to anyone to set up differently and spoof being you to the thing. Here, I just wanted it to work in one known spot, the shop, anyway, so I didn't mess with that yet. But it's out there if someone wants to do it - the link is to a Hackaday page describing the library.
The other thing I'd probably do differently is use 1 or two relays instead of a 4 relay board. If the whole point of wireless is fewer wires, having 4 switched power points co-located just means having a bunch of long power wires instead for most use-cases. Also, MPJA doesn't sell this cheap board anymore and only has the one or two holers. You may or may not want to put in the weather stuff, here an SHT-31 breakout, but I had it laying around and more data about the rooms in a remote building will help me decide whether to run fans or AC over there without having to hoof it over there to constantly check conditions. And now I have a way to turn these things on and off remotely. I will likely put the exhaust fan and the water collector booster pump on this, along with it's real use here - powering up and down the fusor data aq and cameras, again, remotely. Sometimes if things are really locked up, remote desktop won't get you a real robust reboot, and you might still want to turn things off for the night, and not have to hoof it over there to switch that power off and on just to do some dev work (which is always in progress with something like that).
I found a fairly nice "work box" the right size at Lowes. The main electronics fit easily in this, and lo and behold, there's even PCB retention/guide slots in this thing! However, when casting around for an AC adapter to run it all, well, even the small ones are on the large size. I pulled about the crummiest small one out of my junk box, and when I cut it open to just use the guts, I got a surprise on how they did this. It appears to be some kind of Royer oscillator running right off the line! The output (there is no feedback) is just half wave rectified off the secondary of the transformer (ferrite core) so to get any regulation at all - it's rated for either 120 or 240v - it must be doing something slightly tricky using core saturation for more than one thing.
There are just no parts there. The one diode marked zener is on the primary side of things. Here's a picture for your info. Whatever, the thing works for this just fine. On to the main show - it looks like this, when buttoned up it just looks like a sloppy hand made power strip: As far as the UI is concerned, it looks like this: And the relay control/status page looks like this: The relay status is shown both on the main page and on this page when you navigate here - the CGI checks the boxes for the active relays.
The code is more or less standard for here. This implements my LANDNS stuff, using the "good luck changing this" ESP machine name which is ESP_(last 3 bytes of MAC as hex).
This broadcasts the machine name and IP on the subnet on UDP port 53831, and shouldn't bother your LAN if you're not using my code to listen for this, or at least, it doesn't bother mine.
It emits a web page at TCP/IP port 80, nothing special there. I have it showing the last 24 hours of temperature and humidity as plots via SVG graphics, which kind of makes your browser do the work. As mentioned in the code, this could be done better and faster if someone used the polyline commands instead of line...line...line, but this works.
The CGI page, /controls, creates the checkboxes and fills them in with current state. An improvement might be to make this persistent across boots with eeprom. Then again, coming up or failing in the off state seems fairly safe. So...less work, safer, I'm not fixing what I don't see as broken.
So, this is a reasonable codebase for ESP-8266 "things" for my Lan of Things projects around here. Other "things" are often Raspberry Pies, but sometimes that's total overkill, and these are both cheaper in bucks and in power use.
And of course, the real purpose of this post is to share and also have offsite backup (someday I'll get serious about github, but till then..). Down the road a little (and things like this are why I made sure this would be easy to shove new code into) it might seem good to put another interface on this, say UDP at some other odd port (42042 comes to mind as the answer). Right now the only way to command this is via the web page or by pretending to submit to the existing page. It'd be easier to do programmatically, at least for me, to just have a port I could send messages to.