Taking A Public Transit Display From Project To Product

We’ve noticed an uptick in “project to product” stories lately, which seems like a fantastic trend to us. It means that hackers are turning out projects that really resonate with people, to the degree that taking the leap and scaling up from a one-off to a marketable product is worth the inherent risk. And luckily enough for the rest of us, we get to learn from their experiences.

The latest example of this comes to us from [Stefan Schüller], who from the sound of things only reluctantly undertook the conversion of his LED matrix public transit sign into an actual product. The original project had a lot going for it; it looked fantastic, it was technologically simple, and it provided a valuable service. But as a project, it made certain assumptions and concessions that would cause problems when in the hands of a customer. Chief among these was the physical protection of the fragile LEDs, which could easily shear off the display modules if bumped or dropped. There were also firmware issues, such as access to the backend API that serves the transit data; requiring each customer to sign up for and configure their own API key is a non-starter for a product.

In the article, [Stefan] enumerates a long list of problems that going from project to product raises, as well as how he addressed them. The API issue was solved by implementing his own service, which acts as a middleman between the official API and his customers. A nice plexiglass and sheet-metal frame serves to protect the display, too. Design changes were made as well, not only to provide better functionality but to make manufacturing easier. [Stefan] also relates a tale of woe with regard to getting the display’s app into the app stores, something that few of us have to deal with when we’re just fiddling around with something on the bench.

All in all, [Stefan] does a great job walking us through the trials and tribulations of bringing a product to market. There are similar lessons in this production run scale-up, too, but with an entirely different level of project complexity.

Does Getting Into Your Garage Really Need To Be Difficult?

Probably the last thing anyone wants when coming home from a long day at work or a trip is to be hassled at the last possible moment — gaining entrance to your house. But for some home automation enthusiasts, that’s just what happened when they suddenly learned that their own garage doors had betrayed them.

The story basically boils down to this: Chamberlain, a US company that commands 60% of the garage door market, recently decided to prevent “unauthorized usage” of their MyQ ecosystem through third-party apps. Once Chamberlain rolled out the change, users of Home Assistant and other unauthorized apps found themselves unable to open or close their doors with the apps they were accustomed to.

Those of us with custom smart home setups can relate to how frustrating it is when something disturbs the systems you’ve spent a lot of time tweaking and optimizing. It’s especially upsetting for users who both Chamberlain hardware specifically because it was supported by Home Assistant, only to have the company decide to drop support. This feels like false advertising, but we strongly suspect that buried in the EULA users must have agreed to at some point is a clause that essentially says, “We can do anything we want and tough noogies to you.” And if you read through the article linked above, you’ll get an idea why Chamberlain did this — they probably didn’t like the idea that users were avoiding their ad-spangled MyQ app for third-party interfaces, depriving them of ad revenue and the opportunity for up-selling.

We feel the frustration of these users, but rather than curse the darkness, perhaps this will light a candle of righteous rage that leads to a clever workaround. The Home Assistant blog article mentions a dongle called ratgdo, which should allow any door with plain old dry contacts to work via MQTT or ESPHome. It’s extra work that users shouldn’t have to put in, but maybe getting one over on The Man would be worth the effort.

Thanks to [KC] for the tip; please keep us posted on your workaround.

Programming 1949 Style!

What was it like to program an early digital computer? [Woven Memories] wanted to know and wants you to know, too. [Maurice Wilkes] and his team wrote a book about their EDSAC and the 18 instructions that it used. These days, you can even run an EDSAC program on a number of emulators.

It is hard to realize how things we take entirely for granted had to be invented by [Wilkes] and his colleagues. The book, “The Preparation of Programs for an Electronic Digital Computers” has, among other things, the first recorded use of a software library and the first API. Even the subroutine needed inventing by [Wilkes’] student [David Wheeler], which was known for a while as the “Wheeler Jump.”

Like many things in old computers, the Wheeler Jump required code to modify itself. Even indexing modes were often implemented by changing an address inside the program.

While we frown on techniques like this today, you have to start somewhere. We are big fans of EDSAC and [Dr. Wilkes] had a long and distinguished career long after EDSAC, too. The original plans for EINIAC led to EDSAC, EDVAC, and a slew of other early machines. You can see a video of the machine with an introduction by [Wilkes] below.

If you want to try your hand with the EDSAC, try your browser. There’s also a very nice Windows emulator that runs fine under WINE.

Continue reading “Programming 1949 Style!”

Building A Weather Display In Rust

We’ve seen a lot of weather displays over the years, and plenty of the more modern ones have been using some form of electronic paper. So what makes this particular build from [Harry Stern] different? The fact that the firmware running on the ESP32 microcontroller at its heart was developed in Rust.

The weather station itself is capable of operating for several months on its rechargeable NiMH battery bank. The Rust section of the project is in two parts, the first of which runs on a server which downloads the weather data and aggregates it into an image. The second part runs on the ESP32 using esp-idf which configures peripherals, turns on and connects to Wi-Fi, retrieves the image from the server, displays the image and then puts the display to sleep. By doing the heavy lifting on the server, the display should be able to run for longer than it would if everything was happening on the ESP32.

The project code is available from this GitHub page which should allow even Rust beginners to follow along, and the case file is also available for those with a 3D printer. [Harry] has a few upgrades planned for future releases as well, including a snap-fit case, a custom PCB, and improved voltage regulator for better battery life, and enhanced error handling for the weather API. And Rust isn’t the only interesting part of this project, either. As prices for e-paper displays continue to fall, more and more of them are found in projects like weather stations and even complete laptops which use these displays exclusively.

Reverse Engineering Reveals Hidden API In Abandonware Trail Camera

It sometimes seems like there are two kinds of cheap hardware devices: those dependent on proprietary software that is no longer available and those that are equally dependent but haven’t been abandoned just quite yet. But rest assured, abandonment is always on the table, and until then, you get to deal with poorly written apps that often suffer from a crippling lack of essential functionality.

Such was the case for the wireless game camera that [Chris Jones] scored on the cheap, but rather than suffering with the original software, he decided to reverse engineer the camera and turn it into something more useful. The eBay description was promising — Bluetooth LE! WiFi! — but the reality proved less so. To save the batteries, WiFi is off by default and can only be turned on by connecting to the camera via BLE using a janky and crash-prone Android app.

[Chris]’ first step in reverse engineering the camera was to snoop into the BLE by capturing the Bluetooth packets to a file and running them through Wireshark. This revealed a write command with the text “BT_KEY_ON” — very promising. After verifying that this command turned on the camera’s access point, [Chris] got to work capturing WiFi packets using PCAPDroid and analyzing the results, again with Wireshark. Using every function available in the OEM app eventually revealed the full API on the camera, which gives file system control, access to individual images, and even putting the camera into live video mode.

Continue reading “Reverse Engineering Reveals Hidden API In Abandonware Trail Camera”

Little Twitter Game Boy Won’t Work Now The API Is Dead

Twitter, like many social networks, used to feature a useful API. This let people do fun things like create toasters that could automatically post breaderly updates, or even load Twitter posts on machines that couldn’t handle full-fat websites. That API is now history, but [NEKOPLA] used it for a cute Game Boy-like Twitter device in its dying days earlier this year.

Swap out the TW BOY for a smartphone and this photo wouldn’t be nearly as good.

The “TW BOY”, as it is known, runs on a Raspberry Pi Zero 2 W, which includes a WiFi chip on board for easy internet connectivity. A Python script was charged with fetching Tweets for viewing using the now-dead Twitter API. Dithering was used to display color images on the 320×240 monochrome screen. Everything was wrapped up in a tidy 3D-printed housing to complete the look. The device uses two action buttons, and four directional buttons for navigation. It’s the layout popularized by the original Game Boy, and it looks super cute here, too.

The project was built as [NEKOPLA] has a penchant for single-use devices, due to their solitary focuses on doing one thing well. We can appreciate that ethos, and we love the final product, even if Twitter decreed it would no longer work. (Time to move on to Mastodon?) More images after the break.

Continue reading “Little Twitter Game Boy Won’t Work Now The API Is Dead”

End Of An Automation Era As Twitter Closes Its Doors To Free API Access

Over the last few months since Elon Musk bought Twitter there has been a lot of comment and reaction, but not much with relevance to Hackaday readers. Today though that has changed, with an announcement from the company that as of February 9th they will end their free API tier. It’s of relevance here because Twitter has become one of those glue items for connected projects and has appeared in many featured works on this site. A week’s notice of a service termination is exceptionally short, so expect to see a lot of the Twitter bots you follow disappearing.

Twitter bot owners have the option of paying to continue with Twitter, or rebuilding their service to use a Mastodon instance such as botsin.space. If the fediverse is new to you, then the web is not short of tutorials on how to do this.

We feel that Twitter will be a poorer place without some of the creative, funny, or interesting bots which have enriched our lives over the years, and we hope that the spam bots don’t remain by paying for API access. We can’t help feeling that this is a misguided step though, because when content is the hook to bring in the users who are the product, throwing out an entire category of content seems short-sighted. We’re not so sure about it as a move towards profitability either, because the payback from a successful social media company is never profit but influence. In short: social media companies don’t make money but the conversation itself, and that can sometimes be worth more than money if you can avoid making a mess of it.

If the bots from our field depart for Mastodon, we look forward to seeing whether the new platform offers any new possibilities. Meanwhile if your projects don’t Toot yet, find out how an ESP32 can do it.

Header: D J Shin, CC BY-SA 3.0.