I am a huge fan of home automation. My last house was filled with so many hue lights, that we surpassed the limit of bulbs that could be joined to a single hue bridge (having to combine these bridges was my first dive into Home Assistant, I’ll have more on this setup in a later post). But I’m also a fan of technology that respects my freedoms and privacy – and unfortunately, pretty much all consumer home automation ecosystems rely on closed cloud services that package and sell your data to the highest bidder. Worse, appliances that pack in WiFi connectivity, like Samsung’s line of smart refrigerators, tend to lose support quickly, leaving consumers out of luck on features or exposed to security risks. Some features that would solve a few problems just weren’t in any of the offerings, either, so naturally I decided to roll my own.
Enter: The Kitchen Pi
Artfully integrated – just like it came from the factory!
The hardware I had sitting around from a planned, similar project, and is fairly straightforward. It consists of:
A Raspberry Pi 3
A cheap TFT touchscreen from eBay
An USB conference microphone
A Zebra label printer
It serves a few functions for the house in the Kitchen. The most popular feature is the label printer. At the press of a button, it’ll generate a sticker that helps organize the pantry, and makes it easy to tell when opened consumables and leftovers need to be thrown out.
The green and red buttons at the bottom turn the hue light groups for the immediate room on or off.
Voice recognition and control is courtesy of Snips, a private-by-design voice assistant platform that runs everything, from wake-word detection, speech recognition, and natural language processing, on-device: we can rest assured that our Kitchen conversations will never end up on the listening end of some mystery third-party contractors. The Snips model I have running allows color and brightness control for the lights, can add things to our shopping list in Home Assistant, and will print out a date label if requested.
The interface is a simple WxPython application (code on my Gitea). Conveniently, Snips publishes results from voice interactions on an MQTT topic, and Home Assistant also provides an MQTT interface, so a pair of Brokers bridge these topics together and the application hooks into both that way.
Some improvements I have for the near future:
Attaching a speaker – I was using desktop pop-up notifications for feedback from Snips, but the framebuffer driver for the TFT display really struggles at compositing, and the popup notifications will often corrupt the application display between redraws.
Get A larger screen driven over HDMI rather than GPIO (see above).
Add a Barcode scanner – I’ve been working to integrate an ERP-style system called Grocy, and a scanner near the fridge with a dead-simple interface would make sure it gets used.
Make a better interface to control the lights – screen real estate made this difficult on such a small screen, and groups can always be dimmed with a voice command, but a few taps are easier during a noisy party.
Raspberry Pi-driven meetup info board behind the NoVALabs front desk.
I’ve been working lately on making some TVs mounted around my local maker space more useful, displaying event information pulled from meetup. I opted to generate the displays with HTML, and wanted a no-frills thin client that would boot straight to a full screen web browser to display the info. This kind of setup would also be useful for a dedicated web-app on a kiosk with a touch screen.
Here’s how I did that on a Pi B+ and 3, but the following instructions should work with any Raspberry Pi:
Download and extract Raspbian Jessie Lite to an SD card. 2GB was plenty big for my application
Update the base packages and install our needed applications. Do not install unclutter if you want to see your cursor (e.g. for a kiosk with a physical mouse)
sudo apt-get update && sudo apt-get upgrade
sudo apt-get install --no-install-recommends xserver-xorg xinit
sudo apt-get install fvwm iceweasel unclutter
Set a static IP and hostname, if desired. Note that this process is different in Jessie than it has been in prior Debian distros.
Run sudo raspi-config and select:
Internationalisation Options > Change Timezone and set local timezone.
Select Advanced > Overscan > “No” to disable overscan.
Enable Wait for Network at Boot.
Set GPU memory split to 128 or higher, if desired. 128 works well for the Pi 3.
Out of the box, the Pi has some aggressive screen blanking settings, configured for both the console and X. Edit/etc/kbd/config and change the following lines: BLANK_TIME=0
POWERDOWN_TIME=0
Edit /etc/X11/xinit/xinitrc and append the following: xset s off
xset -dpms
xset s noblank
There are probably better ways to auto-start X using systemd, but nothing I tried work. Instead we’ll rely on rc.local compatibility, but to do so we need to change the X security model to allow a non-console user to start the server. Run sudo dpkg-reconfigure x11-common and select “Anybody”.
Issue startx to load fvwm, open an xterm window by right clicking on the desktop and following the menu, and run iceweasel -ProfileManager. Create a new profile called “Kiosk” and start that session. Install the R-kiosk plugin. This will force the browser full-screen, disable right-click, and disable the majority of browser controls and shortcuts.
mkdir -p ~/.config/autostart
Create new file ~/.config/autostart/iceweasel.sh with the following contents (be sure to replace <URL> with the URL you want the browser to load: # Set the date (novalabs has a very restrictive firewall, no NTP outbound.)
# Remove this line if NTP works for you
sudo date -s "$(wget -qSO- --max-redirect=0 google.com 2>&1 | grep Date: | cut -d' ' -f5-8)Z"
/sbin/ifconfig | grep inet > /tmp/ifconfig xmessage -file /tmp/ifconfig &
xmessage -center -timeout 30 "Loading display..." &
/usr/bin/iceweasel -P 'Kiosk' -no-remote <URL>
rm /tmp/ifconfig
Make the script executable: chmod u+x ~/.config/autostart/iceweasel.sh
Create ~/.fvwm/config and add these contents: DestroyFunc StatFunction
AddToFunc StartFunction
+ I Test (Init) Exec ~/.config/autostart/iceweasel.sh
Edit /etc/rc.local and put this line before exit 0: exec su -l pi -c startx
Reboot, and you should be greeted by your URL loaded full screen. If you want to check the IP of the Pi to control it over ssh, etc, connect a keyboard and Alt+Tab to see that message window. If you are using a mouse and keyboard on your kiosk, you will need to tweak the fvwm configuration to remove the extra desktops and further lock down the keyboard shortcuts.
A 440MHz fixed-frequency foxhunt transmitter I intended to use as a stationary fox. A Digistump drives a small 433 MHz transmitter module wrapped in yellow heatshrink. While any significant amount of metal is enough to capacitive load the transmitter out of oscillation, it does function decently indoors in convention spaces.
I’ve been wanting to put together my own foxhunt transmitter to use at conventions, and since I’d never etched a PCB before I decided to go for broke and make this controller board my first circuit board experience.
My general idea for form factor revolved around using a 1020 Pelican micro case ($12), with the means to strap the resulting device to a person’s arm to run around and be the fox. As a power source, I wanted something decently universal that could readily be recharged or swapped out, so I scoured Amazon for the highest capacity USB battery pack that would fit in the Pelican case. Unsurprisingly, I’ve been yet to have a foxhunt that even put a dent in this 11200mAh KMASHI battery ($16). After calculating dimensions, I figured out how much room I had left and used that as size for my PCB design.
I found a neat surface-mount module from Ebay that is a self-contained VHF or UHF transceiver intended to be used in walkie-talkie configurations. The DRA818V/U claims 0.5W and 1W output power levels, has an UART interface for control with 600 ohm audio in/out, and takes a single 5V supply to boot. All it really needs to make it work on the ham bands is a low pass filter, and it should in theory work with just about any microcontroller. I threw together a schematic in gEDA, basing my fox beacon around an Atmel ATMEGA328P, adding an hardware DTMF decoder and an AF connection from the radio to one of the micro’s GPIO’s to enable the possibility of remote control, as well as add flexibility for using this hardware in other configurations. The PCB art was drawn with gEDA’s PCB, which had a bit of a learning curve but after a week of fiddling around with it I managed to crank out my first bit of artwork.
As a foresight on my part, I hadn’t realized that the DRA818V module datasheet specifies 3.3V logic for the UART, but I was using a 5V microcontroller to keep the power supply simple. In trying to use up only parts I had on hand, I went with the cheapest level shifter I could think of – a simple resistor divider. I hooked the resistors up to a 5V Aruino and the initial result looked good.
I used the PCB toner transfer method with some inexpensive transfer paper from Ebay. It took me a few tries with this “easy release” paper to get the heat right with the iron while still being able to cleanly remove the paper under water, but I plan to retry this method with some more common photo paper or shiny magazine covers with smaller boards. To keep the front and back aligned, I created an envelope by printing the front and back on the same page, folding it over and aligning the two sides with a bright lamp. I actually ended up securing the top right corner of the board to the transfer paper with a bit of sellotape, which melted under the iron and left a triangle of copper protected from the etchant.
For etching, I used a 2:1 ratio of hydrochloric 32% acid (available at the hardware store as “Muriatic acid” with the pool chemicals) and 3% hydrogen peroxide. You can read more about this particular etching method from this great tutorial on instructables. The primary advantage over ferric chloride etchant that I saw is that cupric chloride can be reused indefinitely by adding acid and bubbling in oxygen from air instead of worrying about disposal.
Drilling out the PCB was the most difficult part of this venture. I’d actually managed to push most of a 1.4mm carbide bit into my thumb before I even started because the neat little case the bits came in was nearly impossible to open with any ease.
Assembly started out as a breeze; I decided to socket the micro in the event that the programming fuses accidentally get set incorrectly (which I’d managed to do with at least one ATMEGA328 when putting this together). But disaster struck when I double checked the pinout on the transceiver module.
Backwards! My worst PCB fear!
It turns out that I followed the pinout of the module from the datasheet without questioning whether these were the pins from the top or the bottom of the module. Assuming the top (in reference to the pads) I wrote the gEDA footprint file numbering the pins to match the same way they appeared in the datasheet.
To patch this blunder, I wound up sticking the module shielding-can side down and carefully soldering spare component leads to each pad. To date this had worked well for a while, but any shorts to the shielding can renders the fox useless at best and indeterminate at wost.
After testing the module with an external USB TTL adapter, I loaded up a simple sketch to configure the module, which to my dismay kept the module on the same frequency I had manually set. Poking at the UART lines with the scope revealed the horrible condition which my 2¢ level shifter had wrought upon the poor module.
It turns out that loading from the UART module plus 9600 bps speeds was just enough to make this “level shifter” scheme not work. The sloppy level transitions and over/undershoot made it impossible for the module to decode anything from the micro.
The best part is that the micro just sits there helplessly as the module returns nothing but +ERROR every time it tries to set the frequency. For now the fox will just have to forgo being frequency agile (although it could be changed manually with the external UART). Ah well, a proper level shifter will be incorporated in the KE4FOX SmartFox 2.0 =3
I’ve actually seen others just connect the module straight away to their 5V microcontrollers and have them work, but the datasheet is very explicit about 3.3V levels.
To wrap it all up, I drilled an hole for the bulkhead SMA antenna connector, and packed all the parts into the 1020 case. I really like how this turned out, despite the imperfections. The idea is definately there, just need to refine the implementation a bit. While etching my own board was neat, for the next iteration I plan to use a professional board house with plated through-holes. We’ll see how it turns out!
