Building an e-ink weather display for our home(kimmo.blog) |
Building an e-ink weather display for our home(kimmo.blog) |
> Left to its own devices, the Kindle will go to sleep after a while, and show its screensaver.
This can be disabled by entering `~ds` in the search bar of the kindle [0]
[0]: https://blog.the-ebook-reader.com/2017/12/31/heres-how-to-di...
Dropping this as a warning for people trying this out - your Kindle firmware should be < 5.13.X. You need to be very careful about auto-updates that'll undo a jailbreak so put it on aiplane mode until you jailbreak it.
After you do, I'd recommend you then install KUAL and then MobileRead Package Installer so that you can install the mod that prevents auto-updates and then you can install and control USBNetwork in a more user-friendly way.
Edit: It is actually loading a screenshot of a custom webpage he built.
I hope we're going to see such device come to life; my bet is some successful kickstarter followed by an amazon clone with alexa built-in :vomit-face:
+1 for a simple device that does one thing, and does it well.
https://www.helmet.fi/en-US/Libraries_and_services/Helsinki_...
I'd like link to Slint [https://github.com/slint-ui/slint] It has a live preview mode so you can iterate fast on the UI, and it is much more lightweight than HTML, so you could even run it bare metal on a Raspberry Pi Pico (RP2040)
Got any more details on that? Are we talking "takes half of the RP2040 flash just to initialize hello world" or something smaller ?
Amazing! I've never seen anything comparable in a U.S. library. What a wonderful resource. How do they maintain it?
You can book the machines/stations out for periods of time, using your library card/account.
You have to do a safety induction to be able to book the more dangerous tools.
They also sell materials, or you can BYO.
Taxes. I think one big benefit of the Finnish multi-party system is you have less political bickering and more actual doing. Perhaps it leads to more efficient use of tax revenue.
Either case, we have this library (and many more not as fancy).
Would really like to know power usage and how long between charges and more details about getting the pi to wake up once a day then sleep the rest of the time. Because if my maths right a Rpi zero running normally would drain the battery in less than full day.
Supporting EINK on mine could potentially help make it more visually compelling like yours, but I've done other EINK display projects in the past (see https://github.com/Mrjohns42/DoggieClock) and screen burn-in was definitely an issue.
I find this very surprising, I was aware that you can sometimes get ghosting-effects, but I did not think permanent burn-in was possible on EINK tech.
I think I might have seen that link here, either here or Reddit.
I tweaked a few things but it's basically the same code still. I slapped a 3500 mAh 18650 in it and it's been running now for a month and a half while still showing 89% battery remaining. If that pace holds up it'll be in the ballpark of a year of operation before it actually needs to be recharged.
Once an hour it wakes up, connects to WiFi, retrieves the information, updates the display, and then goes back to deep sleep. It's awesome, other than it being too small to comfortably read where I want to put it. Eventually I'll upgrade to a larger display, but I haven't seen any offered as reasonably priced standalone modules with a WiFi capable MCU attached out of the box like this one.
I built a MagicMirror-based Pi setup with a little 7” Lilliput screen and it works so much better, but it’s sad that over the past few decades we still haven’t solved this problem of a customizable smart home dashboard that actually works and yet does not require a CS degree to operate.
I mean I could definitely make one, but I don't really have time and I imagine most people don't either.
I might tinker with a kindle, but I have never owned one and searching online seems to hint at kindles being locked down.
Some notes on my approach: https://github.com/schwartzie/weather-joan
Temperature != Weather
It was a really fun build, I used a 5.3 inch black/white/red panel from aliexpress and a waveshare rp2040 to drive it, hooked up to a spare internal usb header. Circuitpython made life pretty easy for the firmware, though I am thinking of rewriting it in C. This is mostly because circuitpython seems to get 'stuck' in a weird state, the host PC won't recognise it, and I have to open the case and hit the reset button. Every boot.
What's missing really is a 3d printed frame.
I wish something hackable like this was commercially available (without surveillance/data harvesting.)
https://shop.m5stack.com/products/m5paper-esp32-development-...
You can start developing easily using their easy development tool called UIFlow, that's block based like Scratch ( https://flow.m5stack.com/ ), or go "advanced" and use MicroPython or Arduino, as it's core is an ESP32
Or you can repurpose an old Kindle: https://github.com/matopeto/kindle-weather-dashboard
My version[0] uses the 7.5 b/w ePaper that the author replaced, renders using LaTeX and addresses the bw font uglyness by rendering without anti aliasing in an okayish looking font. Looks good to me from a couple of meters away.
[0] https://irq0.org/hacks/epaper-calendar.html https://github.com/irq0/comporellon
I was shocked at the price of the e-ink display though. $200?! I could buy a whole Kindle for that price.
Here is the video that gave me the idea https://youtu.be/YawP9RjPcJA
This screen is 63$
Give an hourly (or 2 hour) 24.. or even 12 hour weather forecast, in 6-12-24 chunks. Allow natural scrolling to see hourly forecast for further than 12/24 hours.
Give a 7 day weather forecast. No need to connect with a wind direction sensor or anything fancy, just pull from the weather.com api or anything similar
It would also not show me ads or try to track me or crash. I would even be ok dedicating a full time iPad/other device to display this.
I made a 'skyfield' widget for home assistant that shows the current position of the sun, moon and some planets as well as the summer and winter solstice paths. I really think it would be awesome for an e-ink display in the home. I've been planning to kick off that project at some point. This is inspiring.
I ended up ordering a case from thingiverse because the case wave share sells doesn't fit the HAT model.
My goal is to not look at my phone in the morning, so having my todos on eink is nice. When I used paper I ended up with paper lists in 7 places.
Home assistant integrates with esphome which supports waveshare if you get the esp32 interface rather than the raspberry pi HAT.
And todoist integrates with home assistant.
Basically all via yaml.
[0]: https://hash.jordanscales.com/
[1]: https://inkplate.io/
Then, the battery could be a lot smaller and the device would be sleeping most of the time.
That's possible since e-ink only draws power when updating.
Once they're cheap-enough, the manufacturers will come.
They seem to be trying to limit full refreshes but they're very distracting when they happen, suggest keeping it out of eye line.
The idea first came to me in the era before BYOD was an okay thing. It was a huge struggle to put anything on the network, like a board saying how broken the builds are. And punching holes in walls or having dangling cables is always a problem, even at home, hence wireless.
eInk is pretty much the only candidate for a device that sleeps most of the time and wakes up momentarily to poll for data.
In the absence of any power control, the PiJuice page says the 13000mAh model powers a Pi Zero W for 60 hours at idle (18 hours at full load). Based on the lack of discussion on the post, this is probably what's going on, though recharging every 2.5 days is exceedingly annoying, so maybe not.
If you're doing a similar project, I really like the TPL5110 series of chips for power control. You basically connect it to your Li-ion battery, your project's voltage regulator's enable pin, and a GPIO pin. You set a time interval with resistors, and it draws 35nA while the power is "off". When the set time interval is reached, it enables the regulator, and your microcontroller boots. Do what you need to do, then set the GPIO pin. The TPL5110 then turns off the regulator and goes back to a very low state. With a 1200mAh battery, I can collect samples half-hourly and write them to a database over WiFi (with a RP2040 and ESP32) for several months without recharging. It all works very well, and would also work for the e-ink use case.
I will say that I've had random luck doing this with e-ink displays. Some freak out and generate artifacts or fade out when you disconnect power. Some don't. Often marked with the same part number. So I have no idea what's going on there. Also, be careful about what your microcontroller does when you have the battery connected to an analog input to measure the battery voltage; you can easily draw a ton of current while otherwise idle that way. Large resistors are your friend, though be aware that some say things like "you'll blow up the chip if any IO pin has a voltage on it larger than Vdd". I didn't see that in the RP2040 datasheet and it didn't blow up, but your mileage may vary.
One last note, when I've done projects like this in the past, I ended up just doing all the image manipulation on a server somewhere, and making the microcontroller just stream the bytes that the screen should display from the server. Then you never have to touch the microcontroller code, and you don't have to have a full Linux system on the client side (as this project did) with the associated power demands. $1 microcontroller > $35 Linux box. Though if you are a CircuitPython fan, this is ridiculously hard to implement because images get large fast and Python wants to read all the image data from the WiFi interface into RAM. Easier if you just write it in C.
You could try setting the pins to Z state (floating) before turning off to see if it makes a difference.
If you have access to an oscilloscope you can also analyze what is going on in fine details.
1. https://github.com/PiSupply/PiJuice/blob/master/Hardware/REA...
[1]: https://www.cityofsydney.nsw.gov.au/talks-courses-workshops/...
If they made a battery powered one I would buy it.
Unfortunately the fast color displays (we can buy) are not there yet. Only black & white (and grayscale) ones are fast enough to be used as somewhat generic screen you can interact with
I just did a project with one. You are right, the three (or more) colour screens do indeed have very slow update cycles, and they usually don't support partial refresh either (just updating part of the screen)
BUT there are some tricks you can do. You can start most of them in two-colour mode, which does support partial updates, and you can define and upload a custom set of waveforms that govern how the screen performs its refresh and update cycles. I wrote an email to the company I purchased from (good-display) and they were very responsive and sent me some waveforms to try. These allow a much faster update (~1s) at the cost of some slight greyness, which gets worse over time, needing a full refresh after a while.
The resulting code I wrote now does something like -
- start device (colour)
- draw background in colour (15 seconds)
- every minute, restart device (B/W) and draw 'active' areas (1 second)
- every 15 minutes redraw background (full screen update, 15s)
- every 24 hours run a screen refresh routine(1 minute plus)
(my screen refresh routine cycles each pixel through each of the colour transitions, black->white, black->red, white->red, and the reverse)
The full-color (7 or 8 colors to mix) take forever to update, but if you’re just displaying a photograph, update it at 2am and no one knows the difference.
Effectively I had to piece together some clues. There was the manual for the screen which gave the definition of the SPI protocol in use, and the commands you could send, what they did, screen startup sequence etc. They mentioned waveforms and modes a bit but it was frustratingly incomplete and it looked like there were gaps in the commands described. Then there was a youtube video of a guy showing how he'd implemented fast refresh on some other model of screen by uploading custom waveforms, who mentioned looking for waveforms in sample code and for chip specifications. This lead me to the original docs for the driver chip on my display (an ultrachip UC8179) which had the missing commands specified. Using these along with the waveform (LUT) definitions supplied by the vendor when I asked them for some, allowed me to make the fast mode.
I presume some commands were missed out of the vendor document as a lot of them were non-essential, and possibly could cause harm(?). Certainly the wrong waveforms could lead to poor performance or no performance. Also the chip spec document didn't give some of the higher level "Here is the startup sequence for your screen" flow chart niceties of the vendor doc.
(The waveforms are literally describing how the screen should apply voltages to transition a pixel from one colour to another. The default ones that the screen ships with are good for a 'full' refresh of the pixel, but you can get away with a lot fewer, faster voltage switches for B/W, at the cost of quality declining over time, which you reset with a periodic 'full' refresh)