Sometimes connectivity problems go away by power cycling a router. It’s a simple but inconvenient solution to a problem that shouldn’t exist, but that didn’t stop [Mike Diamond] from automating it for a few bucks in parts. The three-dollar router rebooter may be a simple device with only one job, but it’s well documented and worth a look.
The device is an ESP8266 board configured to try to reach Google periodically via the local wireless network. If Google cannot be reached, the board assumes a reboot is needed and disconnects the 12 V power supply from the router by using a relay. Then, after a delay, power is re-connected and all of one’s problems are over until the next time it happens. [Mike] used a relay module that has built-in screw terminals and a socket for the ESP8266-01, so it looks like the whole device can be put together without soldering a thing.
While the code for making this happen may sound trivial, [Mike] nevertheless delves into documenting it. It makes a great example of how to implement a simple event-driven finite state machine in a way that’s clear and concise. By structuring the code so that there is a finite number of specific states the device can be in (router power on, router power off, and testing connection) and by defining exactly how and when the device switches between those states, operation and troubleshooting becomes a much more manageable job. Another great example is this IoT Garage Door Opener project. If you’re programming devices that interface to physical things, these techniques are definitely good practice.
When working on a project that needs to send data from place to place the distances involved often dictate the method of sending. Are the two chunks of the system on one PCB? A “vanilla” communication protocol like i2c or SPI is probably fine unless there are more exotic requirements. Are the two components mechanically separated? Do they move around? Do they need to be far apart? Reconfigurable? A trendy answer might be to add Bluetooth Low Energy or WiFi to everything but that obviously comes with a set of costs and drawbacks. What about just using really long wires? [Pat] needed to connect six boards to a central node over distances of several feet and learned a few tricks in the process.
When connecting two nodes together via wires it seems like choosing a protocol and plugging everything in is all that’s required, right? [Pat]’s first set of learnings is about the problems that happen when you try that. It turns out that “long wire” is another way to spell “antenna”, and if you happen to be unlucky enough to catch a passing wave that particular property can fry pins on your micro.
Plus it turns out wires have resistance proportional to their length (who would have though!) so those sharp square clock signals turn into gently rolling hills. Even getting to the point where those rolling hills travel between the two devices requires driving drive the lines harder than the average micro can manage. The solution? A differential pair. Check out the post to learn about one way to do that.
It looks like [Pat] needed to add USB to this witches brew and ended up choosing a pretty strange part from FTDI, the Vinculum II. The VNC2 seemed like a great choice with a rich set of peripherals and two configurable USB Host/Peripheral controllers but it turned out to be a nightmare for development. [Pat]’s writeup of the related troubles is a fun and familiar read. The workaround for an incredible set of undocumented bad behaviors in the SPI peripheral was to add a thick layer of reliability related messaging on top of the physical communication layer. Check out the state machine for a taste, and the original post for a detailed description.
When [Steve Parker]’s girlfriend got a tea kettle that takes voice commands, he suddenly saw his fancy bean-to-cup coffee machine as a technological dinosaur. It may make good coffee, but getting the DeLonghi going is inconvenient, because it runs a self-cleaning cycle each time it’s turned on or off.
Thus began [Steve]’s adventure in trying to turn the thing on with Alexa via Particle Photon. Because of the way the machine is designed, simply adding a relay wouldn’t do—the machine would just turn off and back on, only to start the self-clean again. Once inside, he found it’s controlled by a PIC18LF2520. Further research indicated that it is powered by an off-line switcher that combines a power MOSFET with a power supply controller. [Steve] figured out that the buttons are read via square wave and interpreted by a multiplexer.
The project went into the weeds a bit when [Steve] tried to read the signals with a knock-off Saleae. As soon as he plugged it in, the control board fried because the DeLonghi evidently has no reference to Earth ground. While waiting for a replacement board to arrive, he tried replacing the mux and shift register chips, which actually fixed the board. Then it was more or less a matter of using the DeLonghi’s status LEDs to determine the machine’s state, and then to interface with the Photon and Alexa. Cycle past the break for a ristretto-sized demonstration.
[Steve] didn’t do all this to actually make coffee, just turn the machine on with a voice command. The Photon is totally capable of making coffee, though, as we saw with this closed-loop espresso machine.
Continue reading “Alexa And Particle Modernize Coffee Machine By One Iota”
To the uninitiated the words ‘State machine’ sound like something scarily big and complex. They aren’t (necessarily) and can be quite useful. In fact, state machines are no physical machines but a model of processes. They link the states a system can be in with allowed transitions. For example a media player when stopped can change to play or open another file. While playing, it can go to pause, stop, reverse, fast forward and so on. A state machine creates a map of all states and how they are connected. It is an abstract tool hat offers a graphical approach to organizing your code before actually programming.
In his video [Chris Guichet] uses a state machine to debounce a switch for a beginner friendly introduction of the concept. He then shows how to turn the hand drawn map to actual code, including a section on debugging state machines.
Continue reading “State Your Intentions More Clearly With State Machines”
The secret to domestic bliss often lies in attention to detail, an area in which we can all do a little better. But if paper notes and smartphone reminders are not enough to help you remember to knock jobs off your list, perhaps this IoT task reminder will give you the edge you need to keep the peace at home.
As [Andreas Spiess] points out, his best intentions of scheduling recurring tasks in Google Calendar were not enough to keep him on on top of his share of chores around the house. He found that the notifications popping up on his phone were far too easy to swipe away in favor of other distractions, so he set about building a real-world reminder. His solution uses a WeMOS D1 Mini in a bright blue 3D-printed box with from one to four LED switches on the front. Each box is linked to his Google Calendar, and when a task comes due, its light turns on. Sprinkled about the house near the task, like the laundry room or near the recycling, [Andreas] can’t help but see the reminder, which only goes out when he cancels it by pressing the task button. Simple but effective, and full of potential for other uses too.
Of course, the same thing could be accomplished with a Magic Mirror build, which we’ve seen a lot of over the years. But there’s something about the simplicity of these devices and their proximity to the task that makes sense — sort of like the Amazon Dash concept. We might build a few of these too.
Continue reading “IoT Chore Reminder For The Serially Forgetful”
From debug messages to the fundamental ‘hello world’, serial communication does it all over three little wires. Now imagine being able to cut the cord to your next microcontroller project and use your phone as a VT100 terminal. This was the premise of [Ondřej Hruška]’s Wireless Terminal Project where he took an ESP8266 and added an in-browser terminal emulator which can be accessed over WiFi. The final hardware uses an ESP-01 module mounted atop a breadboard adapter with a 3.3V LDO, protection circuitry for the pins and under-voltage disable.
The firmware is based on [SpriteTM]’s libesphttpd code which was modified to include the VT100 escape sequence parser. The parser, in turn, was coded as a state machine and compiled using Ragel which simplifies such projects greatly. When you access the tiny web server, the loaded webpage starts to communicate over web sockets to the ESP-01. Key-presses from the terminal are sent to the buffer and onto the parser and control logic. The characters are then passed to the hardware UART lines at 115200bps and if an escape sequence is detected, the corresponding action is executed instead.
[Ondřej Hruška] shares the code as well as a user manual in PDF for anyone who would like to try it out and help improve the project. With a little inspiration on learning about state machines, you could extend the project to your own use case as well.
Thanks for the tip [Marco Saarloos]
If you have ever thought that working out a Collatz sequence by hand was alright but lacked buttons and lights, the Collatz-o-matic by [mechatronicsguy] has you covered!
The device is a type of Tag system calculator. [mechatronicsguy] explains that a Tag system is a method of computing similar to a Turing machine; it consists of a read & write FIFO array (or tape or queue) of indeterminate length, and at every step the system reads the symbol at the “head”, deletes a fixed number of symbols from the “head”, and depending on what that first symbol was, appends one or more symbols to the “tail”. Then the process repeats with whatever new symbol is at the head.
The Collatz-o-Matic uses an RGB LED string to represent the queue, and is set up in the following way:
- Delete two symbols (tags) from the front of the queue.
- If the first symbol deleted was:
- A – then write BC to the rear of the queue
- B – then write A to the rear of the queue
- C – then write AAA to the rear of the queue
Numbers are as easily represented as any other symbol, and the Collatz conjecture is that no matter what integer you start with, the system (probably) always eventually reaches state 1. There is video of the device demonstrating exactly that embedded below. Continue reading “The Collatz-O-Matic: A State Machine With Style!”