Bread Online is a Bread Maker for the Internet of Things

An engineering student at the University of Western Macedonia has just added another appliance to the ever-growing list of Internet enabled things. [Panagiotis] decided to modify an off-the-shelf bread maker to enable remote control via the Internet.

[Panagiotis] had to remove pretty much all of the original control circuitry for this device. The original controller was replaced with an Arduino Uno R3 and an Ethernet shield. The temperature sensor also needed to be replaced, since [Panagiotis] could not find any official documentation describing the specifications of the original. Luckily, the heating element and mixer motor were able to be re-used.

A few holes were drilled into the case to make room for the Ethernet connector as well as a USB connector. Two relays were used to allow the Arduino to switch the heating element and mixer motor on and off. The front panel of the bread maker came with a simple LCD screen and a few control buttons. Rather than let those go to waste, they were also wired into the Arduino.

The Arduino bread maker can be controlled via a web site that runs on a separate server. The website is coded with PHP and runs on Apache. It has a simple interface that allows the user to specify several settings including how much bread is being cooked as well as the desired darkness of the bread. The user can then schedule the bread maker to start. Bread Online also comes with an “offline” mode so that it can be used locally without the need for a computer or web browser. Be sure to check out the video demonstration below. Continue reading “Bread Online is a Bread Maker for the Internet of Things”

Propeller-Android communications using debug mode

Here’s a new way to connect an Android phone and a Propeller microcontroller. It’s called the PropBridge and uses a very simple circuit with a voltage regulator, a couple of transistors, and a few resistors. The trick to this method lies in creative use of software features that already exist on Android hardware, the Android Debug Bridge (ADB). The ADB was added with development in mind, but since it provides low-level control of certain parts of these devices it was just waiting to be incorporated into a hack.

The Propeller itself uses firmware to make Android think it is one of two different externally connected hardware devices. It can act like a PC running the ADB client or it can mimic a TCP connection. There’s still plenty of room on the uC to add your own firmware, and the majority of the I/O pins are unneeded for the basic connection. Check out the video after the break for a quick overview of the system.

If you need a little help with Android programming before you’re able to use this in your own projects, check out our Android development series.

Continue reading “Propeller-Android communications using debug mode”

Avoiding OS fingerprinting in Windows

[Irongeek] has been working on changing the OS fingerprint of his Windows box. Common network tools like Nmap, P0f, Ettercap, and NetworkMiner can determine what operating system is being run by the behavior of the TCP/IP stack. By changing this behavior, you can make your system appear to be another OS. [Irongeek] started writing his own tool by checking the source of Security Cloak to find out what registry keys needed to be changed. His OSfuscate tool lets you define your own .os fingerprint file. You can pretend to be any number of different systems from IRIX to Dreamcast. Unfortunately this only works for TCP/IP. Other methods, like Satori‘s DHCP based fingerprinting, still work and need to be bypassed by other means. Yes, this is just “security through obscurity”, but it is something fun to play with.

ATmega88 webserver

If you are an Atmel fan, you may enjoy this webserver built around the ATmega88. Since it has full TCP and HTTP support, communication can be done using a standard web browser on any system. We also noticed that the code uses AVR Libc and the processor can be replaced with an ATmega168, both used on the Arduino platform. Honestly, we think the most interesting part about this project is the firmware. The author has assumed that the webserver will only be sending one packet per request and the code is optimized for this setup. This leaves around 50% of the memory for the web application.

[via YourITronics]