I have a commercial IOT product that I want more control over. Sure, I can control it with the free Android app, but I want my home server to be able to control it, too. This means trying to understand how the app controls it over the network, and attempting to replicate that communication.
At this point, I have a few IOT things on my home network. The first were a couple of EcoPlugs Wifi outlets that I use to control my gutter heaters in the winter, and the next was a custom garage door controller. For the former, I’m basically controlling them by using a replay attack (I hope to make a post about this soon)…re-sending packets that I observed the EcoPlugs app sending. For the latter, I’m using a custom http interface. Since both of these contain an ESP8266, I’d like re-program them and unify them both to use the MQTT protocol.
Canonical recently dropped official support for Ubuntu 15.10 “Wily Werewolf”, so I decided to upgrade. I also don’t like being stuck on Long-Term-Support releases, so I did 2 upgrades in sequence: 15.10 “Wily Werewolf” to 16.04 “Xenial Xerus” to 16.10 “Yakkety Yak”. In the past, I’ve just done a clean install, but the trouble with that is having to re-do all my various customizations. This time I figured I’d just try an in-place upgrade. Of course, this meant that my customizations conflicted with packages changes. I’m still not sure which method is better.
Based off of this post on hackaday about a simple clock using a cheap stepper motor, I decided on a whim to buy some. I chose these on Amazon because they had the desirable combination of being cheap and prime-eligible.
Before they arrived, I did some reading and found that there were different verdicts on the gearing…
I had an idea for a cool project, but for it to work well, I needed some large 7-segment displays…like 3-4 inches tall. Unfortunately, the only ones I could find for sale on-line were absurdly expensive. I remembered seeing several folks make their own 7-segment displays, so that inspired me to try my hand at making my own.
I have a couple projects in mind where I want to use a seven-segment display (one of them where I want large digits), but I don’t want to dedicate too many pins to driving the display. Also, writing custom code to multiplex the digits seemed tedious.
I read about the MAX7219 chip, which lets you drive up to 8 digits over SPI, and it seemed to be just what I was looking for.
For those that don’t know, sslh is a TCP port multiplexer. This basically means that you can serve both https and ssh traffic from the same port. It’s most useful for circumventing corporate firewalls that block TCP port 22 (i.e. ssh), but allow TCP port 443 (i.e. https) by serving both on TCP port 443.
In the default configuration, however, all connections that go through sslh look to ssh or apache as if they came from localhost. This isn’t ideal if you want to run something like denyhosts or fail2ban to block malicious ssh login attempts.
sslh does have an option to do “transparent” proxying so ssh and apache think that the connections have come from the right place. In this post, I’ll describe how I set this up on my machine.
When developing my Valentine’s day puzzle box, I found myself really wanting to single-step through some code to figure out where things were going wrong. Fortunately, the STM32F3 Discovery board that I was using supports on-chip debugging. Unfortunately, it wasn’t already integrated into the template that I was using for the project.
***UPDATE*** I’m going to make some updates to the code, so I’ve modified all the github links below to point to a tagged version. For the latest-and-greatest code, look here.
After I saw this post on hackaday.com about ST Microelectronics giving away STM32F3 Discovery boards for free, I knew I had to have one, but I didn’t really have a specific project in mind for a while. Then, one day I remembered a reverse geocache box that was also featured on hackaday, and realized that I could do something similar. The F3 Discover board includes a 3-axis accelerometer & 3-axis gyroscope, so instead of using GPS, I would only have the box open when it was rotated through the correct sequence of orientations.
For those who don’t want to read the whole post below, the code is posted on my github repository. Also, those looking for photos should skip to the last half of the post.
Since I had ordered the free sample in late November, I figured that I’d have enough time to make this puzzle box as a Christmas gift for my wife. Unfortunately, it didn’t arrive until the day that we celebrated our early Christmas (before we travelled to see our families). Not quite enough time to throw it together… Fortunately, that just meant that I had more time to put something together by the next gift-giving opportunity…St. Valentine’s day.
I’ve been trying to get my STM32F3 Discovery board to register as a Virtual COM Port (i.e. RS232 serial over USB) when I plug it in via the “USB User” port. I had a false start trying to use the code for the F4 Discovery from here…Apparently, the USB hardware is too different between the 2 boards.
However, I did manage to get the example USB joystick/mouse code from the F3 Discovery firmware package from the ST website to run. It is pretty neat…tilt the board one way or another, and the cursor moves!