api

79 Articles

Does Getting Into Your Garage Really Need To Be Difficult?

November 9, 2023 by 78 Comments

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!

November 9, 2023 by 28 Comments

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

September 29, 2023 by 21 Comments

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

July 18, 2023 by 12 Comments

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

April 19, 2023 by 13 Comments

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

February 3, 2023 by 40 Comments

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.

Researching Factorio…For Science

October 19, 2022 by 15 Comments

Science has affirmatively answered a lot of questions that, looking back, could be seen as bizarre to have asked in the first place. Questions like “can this moldy cheese cure disease” or “can this rock perform math if we give it some electricity.”  Among the more recent of this list is the question of whether or not the video game Factorio, in which the player constructs an elaborate factory, can be used as the basis for other academic work. As [Kenneth Reid] discusses in this talk, it most certainly can.

If you haven’t played the game, it’s a sort of real-time strategy (RTS) game where the player gathers materials to construct a factory while defending it from enemies. On the surface it might seem similar to Age of Empires or Starcraft, but its complexity is taken to extremes not found in other RTS games. The complexity hides nuance, and [Kenneth] points out that it’s an excellent simulator to study real-world problems such as vehicle routing problems, decision making, artificial intelligence, bin packing problems, and production planning, among a whole slew of other interesting areas of potential research.

[Kenneth] and his partners on this project also developed some software tools with interacting with a Factorio game without having to actually play it directly. The game includes an API which the team used to develop tools so that other researchers can use it as a basis for simulations and studies. There was a research paper published as well for more in-depth reading on the topic. We shouldn’t be too surprised that a game can be used in incredibly productive ways like this, either. Here’s another example of a toy being used to train engineers working in industrial automation.

Continue reading “Researching Factorio…For Science” →