Do you know this situation: you are listening to a playlist from Spotify on your stereo but just can’t figure out who is singing that song? Since you are sitting comfortably on your couch (too far away from your stereo) you think how this problem could be solved with some clever engineering. You quickly draw up a mental design in your head: a ESP8266 based device connects over the net to Spotify. Then every few seconds it downloads information about the currently played song. Maybe some cover art too and display it on a color display! It can’t be THAT hard, right? This post explains the challenges I faced when implementing the ESP8266 Spotify remote and how I solved them.
This is a sequel to the previous post “Weather Underground no longer providing free API keys.” We would like to fill you in on what has happened since and how we rode that storm.
Disaster struck in the evening of Thursday May 16th in the form of a private message from David “G6EJD” Bird to me. David, a passionate amateur radio & weather station operator and electronics engineer, is active on GitHub as G6EJD and has been contributing a lot to the ThingPulse open-source projects. The email started with:
I thought I’d give you advanced information, although you may already know, that Weather Underground are no-longer issuing a free Developers Licence and so new customers can no-longer download weather data.
The implications became clear in an instant – and they were far reaching.
Continue reading Welcome OpenWeatherMap, bye bye Wunderground
The open-source software that ThingPulse provides for its devices relies on weather data pulled from Weather Underground. The standard setup process involves creating a Wunderground API key (documented in our guides). The usage was free for up to 500 requests per day or 10 requests per minute.
In the evening of May 15th The Weather Company, a subsidiary of IBM, announced that it will no longer provide free weather API keys. There was no prior announcement and the change became effective immediately. It is unclear for how long existing keys will still be valid. As not even the tens of thousand of weather station owners who deliver their data to Wunderground for free will get a key to read their data back the uproar in the community is big.
For our customers this means that unless they already obtained a key from Wunderground they cannot use the ready-made software for the ThingPulse kits. We are very sorry, and furious, about this development but our hands are tied. The promise to our customers is that we will be working hard and not rest until we can offer an adequate alternative integration.
We started working on a new service integration on May 19th. Stay tuned.
Read the sequel here: Welcome OpenWeatherMap, bye bye Wunderground
In the last few years all big IT companies have discovered the Internet-of-Things field in one way or the other. Apple and Google have offerings for home automation, Google, Amazon and Microsoft offer services to connect IoT devices to the cloud. For one of our projects we wanted to take a look at Microsofts Azure IoT Hub solution. Microsoft offers comprehensive libraries to connect the ESP8266 to the Azure cloud. But what about the ESP32? In this post we’ll describe how to create a shared access token for the Azure cloud. We’ll further cover how to use this token to send a minimalistic request with the ESP32 to the Azure IoT hub.
In light of our recent power-consumption related posts 1 & 2 it seemed logical to ask ourselves about max deep sleep for ESP8266. Yet, it took a comment from a curious reader to set things in motion. I replied
…the maximum value for a 32-bit unsigned integer is 4294967295 or 0xffffffff. Hence, the max deep sleep interval appears to be ~71 minutes.
You can’t argue with that first statement but the second is a bit in the air without clear evidence. My co-founder Dani quite rightly then asked “are you sure, didn’t they change that recently?” (“they” being Espressif and/or the Arduino devs).
So then, what is the current max deep sleep for ESP8266 i.e. the maximum duration the ESP8266 can sleep deeply – and still wake up afterwards.
In the last post I showed you how you can use cheap hardware to get a reasonable good power consumption test rig. In this post we are going to use this tool to improve the runtime of the ESPaper significantly. The short trial and error cycle possible with this tool will let us validate several ideas for improvement in only very little time. Continue reading 5 Hacks to Prolong your ESPaper’s Battery Run-Time
In this post I’m going to show you how you can monitor the power consumption of your battery driven (ESP8266/ ESP32) device. Measuring the power consumption over a full activity/ sleep cycle is the precondition to optimize your code for a longer battery runtime. Only with a reliable tool you can decide which code changes lead to less consumption. In a later post we’ll look at some tweaks we can apply to the code to get a few more days out of the battery. Continue reading ESP8266: Monitoring Power Consumption