Lucky Cat POV Display Ditches the Waving and Windmills Out of Control

If you’ve been in a Japanese restaurant, you’ve probably seen a maneki-neko, the lucky cat charm, where a cat welcomes you with a beckoning arm. It’s considered to bring good luck, but we’re not sure if [Martin Fitzpatrick] is pushing his luck with this Lucky Cat POV display. He hacked one of the figurines so the arm forms a persistence of vision (POV) display, where blinking LEDs on the paw create a dot-matrix style display.

Inside the hapless neko is a Wemos D1, motor driver, and a few other components that turn the cat into a working display. The five LEDs he attached to the paw are wide enough to display 5×7 characters. The tricky part in the mechanical design is getting signals from a stationary base to a spinning arm(ature). In this case it was easily solved with a 6-wire slip ring from Adafruit. [Martin] revs the lucky cat up using a brushed DC motor and a couple of gears.

The ESP8266 is running MicroPython — the combination should make this a snap to hook into any web service API you want to display your own messages. Right now the arm doesn’t have positional awareness so the message isn’t locked in a single position like it would be if a hall effect sensor was used. But [Martin] says there’s plenty of room left inside the cat and a future upgrade could include stashing the batteries inside for a cordless, all-in-one build. If he takes that on it’s a perfect time to add some type of shaft encoding as well.

Check the Lucky Cat showing off in the clip after the break.

Continue reading “Lucky Cat POV Display Ditches the Waving and Windmills Out of Control”

DIY Variacs get ESP8266 Upgrades

If you’be been hacking and making long enough, you’ve probably run into a situation where you realize that a previous project could be improved with the addition of technology that simply wasn’t available when you built it. Sometimes it means starting over from scratch, but occasionally you luck out and can shoehorn in some new gear without having to go back to the drawing board.

The two isolated variacs that [nop head] built were already impressive, but with the addition of the ESP8266 he was able to add some very slick additional features which really took them to the next level. He’s done an exceptional job detailing the new modifications, including providing all the source for anyone who might be walking down a similar path.

His variacs have digital energy meters right in the front panel which give voltage, amps, and a real-time calculation of watts. After reading an article by [Thomas Scherrer] about sniffing the SPI data out of one of these meters with an Arduino, [nop head] reasoned he could do the same thing with an ESP8266. The advantage being that he could then pull that data out over the network to graph or analyze however he wishes.

For his older variac, he decided to automate the device by adding a stepper and belt to turn the knob. The stepper is controlled by a Pololu stepper driver, which in turn get’s its marching orders from another ESP8266. He even came up with a simple web interface which allows you to monitor and control the variac from your smart device.

We don’t often see many variacs around these parts, and even fewer attempts at building custom ones. It’s one of those pieces of equipment you either can’t live without, or have never even heard of.

ESP Cookbook Goes Beyond Chips and DIPs

Are you putting ESP8266s in all your projects these days, whether they need one or not? We don’t blame you. These boards are cheap, tiny, oh and they have WiFi.

If you want to spend less time writing code and more time blinking RGB LEDs over Wi-Fi, then check out this ESP cookbook over on IO. [Turo Heikkinen] and team are writing a soup-to-nuts guide to these darlings of IoT. The cookbook leads off with pinouts and networking (of course) before moving into more intricate recipes involving popular sensors and displays.

This cookbook is funny, it’s helpful, and it’s really well-organized. We love that they used the details section to create a linked table of contents. The links all drive to a specific Instructions page where each group of code snippets and explanations can be found. It’s still a work in progress, so you might want to follow it for updates. We have a feeling they’re going to expand the dessert section next.

Love the ESP8266, but hate programming them in that wonky form factor? Here’s a handy programming jig you can build.

Simple Ethereum Vending Machines with NodeMCU

Recently, we covered how to use the Etherscan API to query data (a wallet balance) from the Ethereum blockchain with NodeMCU. It’s a very useful method for retrieving information from a blockchain on embedded systems where storage and memory are an issue.

It has some limitations though. Most notably, it’s polling the API at some interval to retrieve information whether it has changed or not. I would like to be able to receive data more efficiently than this, and quickly enough to make simple vending machines possible. While we’ve seen videos of Bitcoin-based Red Bull vending machines before, they required an NFC card to use.

If we could receive information about Ethereum transactions quickly and reliably enough, we could build a similar vending machine without requiring an NFC card as an intermediary. Simply send to an address via some method, and receive goods!

It turns out we can do exactly that with NodeMCU using WebSocket. Like HTTP, WebSocket is a communications protocol that uses TCP connections (typically over port 80), but it allows full-duplex communication. In other words, you can establish a connection to a server, and send/receive messages without needing to poll the server.

As in the previous example, we’ll use a NodeMCU running Lua. You may wish to refer to it for compile options and information about the screen, which will be the same in this case. Unlike the previous article, you will not need an API key from Etherscan to use this service (not yet, anyway). As usual, we’ll start off by connecting to WiFi:

wifi.setmode(wifi.STATION)
wifi.setphymode(wifi.PHYMODE_B)
station_cfg={}
station_cfg.ssid="Your SSID"
station_cfg.pwd="Your Password"
station_cfg.save=true
wifi.sta.config(station_cfg)

Connecting to a server with WebSockets is easy, but since we’re not using HTTP, we’ll have to remove the https:// and replace that with ws://. (Note: not wss:// because we’ve not enabled encryption yet.)

ws:connect(‘ws://socket.etherscan.io/wshandler’)

Next, we need to report back when the connection is established as the trigger to run additional code. It will return an error code if the connection fails to be established. Handling these error codes in a sensible way is an excellent feature, but we’ll handle that later:

ws:on("connection", function(ws)
    print('got ws connection')
    end)

Now, we need to extend the above to subscribe to an Eth address, and add some new code to do something when a transaction occurs. Note that the API requires that you subscribe to an address within 60 seconds of connecting. It also states that you have to send a ping event to the server every 20 seconds to keep the connection alive, so we’ll need to set a recurring timer for that.

If you’re using ESPlorer, you can send the ping request manually by entering =ws:send('{"event": "ping"}') and pressing Send. This is a useful way to test the connection status.

The address I used seems to have frequent transactions so is reasonable for testing. Be advised though that sitting and waiting for a transaction to happen to test the code creates a slow development cycle so some patience is necessary here.

ws = websocket.createClient()
ws:on("connection", function(ws)
    print('got ws connection')
    ws:send('{"event": "txlist", "address": "0x2a65aca4d5fc5b5c859090a6c34d164135398226"}')
    end)

ws:on("receive", function(_, msg, opcode)
    print('got message:', msg, opcode)
    end)

You should see something like what follows below. The first message is a simple confirmation of connection, the second confirms your subscription to an address, and the third is what you get sent when a transaction occurs. You can subscribe to up to 30 addresses with a single connected device! Note that the data is all in JSON format, which is something we’ll take advantage of later.

got message: {"event":"welcome"} 1
got message: {"event":"subscribe-txlist", "status":"1", "message":"OK, 0x2a65aca4d5fc5b5c859090a6c34d164135398226"} 1
got message: {"event":"txlist","address":"0x2a65aca4d5fc5b5c859090a6c34d164135398226","result":[{"blockNumber":"5532531","timeStamp":"1525098009","hash":"0xe5ec497cb5b38811e8bf5db67a056a2bdd4aa9b68df5c8e8225cb300cbcfa413","nonce":"3363391","blockHash":"0xf446f77d92ed29c221e8451b8048113969ed305a7dd49177e10b422e8e2c4bda","transactionIndex":"172","from":"0x2a65aca4d5fc5b5c859090a6c34d164135398226","to":"0xec5fdfba35c01c6ad7a00085e70e8f30cd121597","value":"24418350000000000","gas":"50000","gasPrice":"4000000000","input":"0x","contractAddress":"","cumulativeGasUsed":"7896403","gasUsed":"21000","confirmations":"1"}]} 1

That’s quite a mess of transaction data, and unfortunately the datum of interest is in the ‘result’ field – which is nested JSON. In the last article, we converted simple JSON to a Lua table using the excellent sjson module. We’ll do the same here after verifying the message type is a transaction (txlist).

ws:on("receive", function(_, msg, opcode)
    print('got message:', msg, opcode)
    ok, ethdata = pcall(sjson.decode, msg)
    if ok then
        msgtype = (ethdata["event"])
        if msgtype == "txlist" then
...

The NodeMCU documentation specifically notes that nested JSON can cause out-of-memory errors. For that reason we use pcall (protected call) to contain any such errors when decoding our JSON message. Next, we extract the contents of the ‘value’ field, nested within the ‘result’ field:

if msgtype == "txlist" then
    wei = ethdata.result[1].value
    print (wei)
    eth = wei/1000000000000000000
    print (eth)
    end

It took me a few hours to figure out how to deal with nested tables, but in the end it was actually quite clean and easy — I was just being dense. Now, we need to add a basic provision to handle errors when the websocket is closed:

ws:on("close", function(_, status)
    print('connection closed', status)
    print('Reconnecting...')
    ws = nil -- required to Lua gc the websocket client
    tmr.alarm(0,4000,tmr.ALARM_SINGLE,transact) -- This reconnects after 4 seconds
end)

To wrap it all up, we encase the code in a couple of functions — first, one to establish a connection, subscribe to the right address, and notify when there is a transaction. Next we need one to display the amount of Eth transferred. Finally, we need a ‘ping’ function to call every 20 seconds or less to keep the connection alive. Overall this turned out to be more robust than expected and has yet to encounter an error. Check out the full code listing here. Note that I’ve also added a little code above to interface with a 128×32 OLED screen, the same one we used previously.

Now that it works, let’s consider im/practical applications. It’s a neat way to display Ethereum transactions in real-time, say if you do livestreaming and accept Eth donations and want them to trigger something fancy. Or, you could make a somewhat insecure vending machine. Clearly, getting a secure WebSocket up and running is the next order of business.

You could also set a timer where the length depends on the amount of Eth received. This would allow for things like public advertisements that go away for a while if someone pays a fee. (Please don’t do this!) Maybe a conference room for rent with the power controlled this way? Hackerspace membership payment? An electric bicycle that charges you for power used?

In any case, it’s not legal to use cryptocurrency as a form of payment in my country so I can’t implement any of the above examples at this time. If you’ve got a better application, please share it in the comments!

A Mobile Terminal for Guerrilla Communications

We use the Internet to do everything from filing our taxes to finding good pizza, but most critically it fulfills nearly all of our communication needs. Unfortunately, this reliance can be exploited by those pulling the strings; if your government is trying to do something shady, the first step is likely to be effecting how you can communicate with the outside world. The Internet is heavily censored and monitored in China, and in North Korea the entire country is effectively running on an intranet that’s cutoff from the wider Internet. The need for decentralized information services and communication is very real.

While it might not solve all the world’s communication problems, [::vtol::] writes in to tell us about a very interesting communication device he’s been working on that he calls “Hot Ninja”. Operating on the principle that users might be searching for accessible Wi-Fi networks in a situation where the Internet has been taken down, Hot Ninja allows the user to send simple messages through Wi-Fi SSIDs.

We’ve all seen creatively named Wi-Fi networks before, and the idea here is very much the same. Hot Ninja creates a Wi-Fi network with the user’s message as the SSID in hopes that somebody on a mobile device will see it. The SSID alone could be enough depending on the situation, but Hot Ninja is also able to serve up a basic web page to devices which actually connect. In the video after the break, [::vtol::] even demonstrates some rudimentary BBS-style functionality by presenting the client devices with a text field, the contents of which are saved to a log file.

In terms of hardware, Hot Ninja is made up of an Arduino Mega coupled to three ESP8266 boards, and a battery to keep it all running for up to eight hours so you can subvert a dictatorship while on the move. The user interface is provided by a small OLED screen and a keyboard made entirely of through-hole tactile switches, further reinforcing the trope that touch-typing will be a must have skill in the dystopian future. It might not be the most ergonomic device we’ve ever seen, but the fact it looks like something out of a Neal Stephenson novel more than makes up for it in our book.

This is not the first time we’ve seen Wi-Fi SSIDs used as a method of communication, thanks largely to how easy the ESP8266 makes it. For his part, [::vtol::] has previously experimented with using them to culturally enrich the masses.

Continue reading “A Mobile Terminal for Guerrilla Communications”

Accessing Blockchain on ESP8266 Using the NodeMCU Board

Blockchains claim to be public, distributed, effectively immutable ledgers. Unfortunately, they also tend to get a little bit huge – presently the Bitcoin blockchain is 194GB and Ethereum weighs in at 444GB. That poses quite an inconvenience for me, as I was looking at making some fun ‘Ethereum blockchain aware’ gadgets and that’s several orders of magnitude too much data to deal with on a microcontroller, not to mention the bandwidth cost if using 3G.

Having imagined a thin device that I could integrate into my mobile phone cover (or perhaps… a wallet?) dealing with the whole blockchain was clearly not a possibility. I could use a VPS or router to efficiently download the necessary data and respond to queries, but even that seemed like a lot of overhead, so I investigated available APIs.

As it turns out, several blockchain explorers offer APIs that do what I want. My efforts get an ESP8266 involved with the blockchain began with two of the available APIs: Ethplorer and Etherscan.

Continue reading “Accessing Blockchain on ESP8266 Using the NodeMCU Board”

Checking The Weather Without A Window

Making a weather display is great because it’s a simple project that shows off some skills and has an obvious daily use. So [ACROBOTIC Industries] decided to make an easy kit for the Hackaday Prize to make weather displays even more accessible.

Calling it the ESPecter, [ACROBOTIC Industries] wanted to make this a simple project for anyone, regardless of skill with a soldering iron or Arduino toolkit. So they decided to base the guts on common components that can be put together easily, specifically a Wemos Mini D1 with an OLED shield as a bright display. They also designed a cool tiltable 3D-printed enclosure for this small device so that you can orient it to your eye level.

ESPecter breadboarded prototype.

While they already have a breadboarded prototype, and a 3D printed case, some software work remains to make the project really shine. They plan to add nice features like a web interface to configure location and network information, alerts, additional locations, and historical weather data. They also want to create a weather library to display well on a low-resolution screen and add battery operation.

We look forward to seeing the final version later in the Hackaday Prize!

This isn’t the first weather project we’ve seen around here. Other variants include mirror weather displays, an ESP8266-based weather monitoring station, a very low-power weather station, and this roundup of weather displays which might give you some inspiration.