A wireless physical notification centre using a thermal 'receipt' printer and MQTT.
|SGT-88IV 80mm ESC/POS thermal printer||This is a Chinese Epson clone with added Bluetooth and WiFi capability, but any ESC/POS capable printer with an RS232 serial interface should do the trick.
58mm printers are more common, but an 80mm will give you more characters per line and thus significantly reduce your paper usage.
I've mirrored the latest drivers and documentation for the SGT-88IV.
|RS232 to TTL converter with male DB9 connector||RS232 is not directly suitable for connection to TTL serial. Not only is the mapping of voltage to binary value inverted, RS232 can swing up to +13V and down to -13V, which will quite happily kill a 5V (or lower) TTL device.
This board is based around a MAX3232 clone, which handles the signal inversion and voltage clamping. It also sets its logic level at its power supply voltage - feeding it 3.3V results in 3.3V logic, feeding it 5V results in 5V logic.
|Adafruit Feather HUZZAH with ESP8266 WiFi||The venerable ESP8266. In principle you could use any microcontroller with a UART and some form of host connectivity, or even a Raspberry Pi / Pi Zero. I decided on the ESP8266 because it's dirt-cheap and has a very mature ecosystem, and I decided to spend a little more to put it on the Adafruit Feather platform because of the additional flexibility it brings (power regulation, LiPo battery power and charging, µUSB power and serial bridging, trivial expansion with FeatherWings). If you don't need flexibility, you can probably get away with just using a breakout board if you really want to.||£19.00||pimoroni.com|
Hardware list notes
You may be wondering why we don't use the onboard wifi instead of a separate device. In fact, in the configuration software (but otherwise undocumented), there actually seems to be onboard MQTT support. So why talk serial to the printer? There are two reasons for this.
Firstly, the hardware is untrustworthy. When the printer arrived, I tried to configure it to connect to my home network. I use a relatively long passphrase for my WPA2 key, and some embedded systems struggle with it. This one, however, went into a reboot loop. The only way I managed to recover it was to connect to the serial port, reboot, then constantly send new wifi configuration parameters in hopes of hitting any small window before the firmware hung and the watchdog rebooted the printer. Luckily enough, I managed to hit one. I pinned the problem to the length of the key by testing shorter keys. However, by this point I was thoroughly drained of trust toward the onboard wifi module.
Secondly, it would leave me with no way of debugging between the network and the printer. With the ESP8266, I can configure debug output and investigate any issues. The printer offers no such channel (or logs of any kind).
As implemented on the Feather, the ESP8266 has its UART0 connected to the CP2104 USB to serial chip, which gives access to a command channel to the ESP8266. Fortunately, there is one more transmit-only UART on the ESP8266 (the TX pin of which is connected to the pin marked '2') which is what we'll use to control the printer - we don't need to handle data coming back from it anyway. Alternatively, we could use a pair of free GPIO pins and do serial emulation in software, but there's no reason to waste the cycles if the hardware has what we need already.