Nest ePaper Signage

Project Status

All signs are installed and fully functional as of October 2020.

Project Overview

I wanted a display of calendar events on our wall, and started this project to accomplish this. In the end it resulted in a system of 4 types of ePaper signs around the house displaying various pieces of information.

System Requirements

• Off the shelf hardware available
  • I wanted to get the system completed and in use quickly, rather than having to iterate on a hardware design before I could even start on the software side.
• Wireless data transmission
  • I didn't want to have to run new cables around the house to drive data to the signs, and we don't have Ethernet or any other data running around the house currently.
• Able to run on battery power for 1 month or more at a time
  • Some of the signs are in places where running power to them would be a problem.
  • Even for the signs that are near power, things look nicer without extra wires, and using up outlets isn't ideal.

Hardware Evaluated

The battery requirement pretty much limited my options to ePaper, as LCD displays generally required being plugged in due to the power requirements over weeks or months. I looked at several ePaper-based options before settling on one.

• Generic Aliexpress ePaper Shelf Price Displays
  • Pros
    • Inexpensive
  • Cons
    • No open protocol or API in most cases, just software to push new prices out from an Excel spreadsheet or similar.
    • Tend to only be available in very small sizes
    • Air protocol tends to be something custom, not Zigbee or WiFi or anything
• Joan meeting room displays
  • Pros
    • 3 month battery life
    • Touchscreen device
    • WiFi communications
  • Cons
    • Display starts at $549 which is more than I was looking to spend on one display.
    • Monthly plan required to display custom content, which starts at $21 per month per display.
• Advantech ePaper Display Devices
  • Pros
    • Nice looking displays in a variety of sizes
    • Buttons on several of the displays
    • 802.15.4 communications
  • Cons
    • Larger sizes of display are "Coming Soon"
    • Protocol is proprietary and requires the Advantech hub device which starts at $720
• WaveShare NFC Displays
  • Pros
    • No battery required, powered by NFC from the device performing an update
  • Cons
    • Only updates when an NFC device is held up to the unit, can't update on-demand.
• SyncSign ePaper Displays
  • Pros
    • Least expensive displays of any of the options, especially for smaller sizes ($35 for 2.9", $99 for 4.2", $299 for 7.5")
    • Hub is also inexpensive ($70) and uses Zigbee for hub to display communications
    • Open cloud API (and SDK to run code on the hub itself) to draw custom content on the displays
    • Battery life averaging 1 year with signs set to poll every 10 seconds and getting 7 updates a day pushed
    • 4.2" sign has 4 buttons on it
    • 2.9" and 7.5" displays are three-colour (black/white/red now and black/white/yellow coming soon)
    • Hub also supports connecting Zigbee sensors to monitor temperature, humidity, light, occupancy, etc.
  • Cons
    • Relatively unknown company, unsure if they'll be around long-term
    • No backlight or other lighting
    • Build quality feels cheap initially, though once mounted on the wall they feel a lot better

Hardware Selected

I selected the SyncSign system, primarily due to the open API and SDK as well as the price of all the components. My initial order was two 2.9" black/white/red displays, one 4.2" black/white display with buttons, and the hub which bridges WiFi or Ethernet to Zigbee to communicate with the displays. Later on once that system was in use and working well, I ordered another two 2.9" black/white/red displays to expand the system.

Project Details

Initially the project was just going to be a calendar that auto-updated to display upcoming events, but once I found the hardware system I wanted to use I thought of a few more uses I wanted to try out. In the end the first deployment was 3 signs, then a second deployment added a 4th type of sign (Dog Food) and a second "copy" of the Weather sign in a different area of the house, displaying the same content as the original one.

Signs

• Calendar - A 4.2" square sign that displays the events coming up on the current day, or the next day if it's later in the day.
• Alert - A 2.9" rectangular sign on the fridge that displays any alerts from the home automation system, or the current date if no alerts exist at present.
• Weather - A 2.9" rectangular sign that displays the current weather type, temperature, and humidity, and what weather is coming up in the near future.
• Dog Food - A 2.9" rectangular sign in the kitchen that displays which food and medication each dog needs next. This one was added in the second phase of the project.

Calendar

The Calendar sign is a 4.2" display with 4 buttons underneath, three of which are currently in use. The sign displays the current date at the top, and lists the events of the day (pulled from our Google calendars via their API) under that. At 8pm each day, the display switches to show the events for the next day, so that we can start planning the next morning out.

Alert

The Alert sign is a 2.9" display, stuck to our fridge with a magnet (which sticks through the plastic case to the CR2032 batteries inside the display). This sign displays any alerts currently active in our home automation system (which runs openHAB), which so far includes:

• HVAC alerts - filter change required, A/C or heating failure
• IT alerts - UPS problems, low toner or low paper level in the printer, unreachable servers or problems on servers
• Battery alerts - Low battery in our deadbolt, smart blinds, or the signs that make up this signage system

When no alerts are active, this sign displays the current date instead.

Weather

The Weather sign is a 2.9" display, with one copy upstairs where we spend a lot of our time, and one copy downstairs by the front door. This sign is split in half, the left half displaying the current weather and the right half displaying upcoming weather. Each half is mostly identical and has an icon for current weather, the current temperature, and the current humidity level. The weather icon changes to red if there is precipitation either currently or in the forecast (depending on which half of the display), and the temperature and humidity change to red if they are at more extreme levels where we would want to prepare for them. This display uses the Climacell API to get its weather information, which is free for the number of queries per day that this system ends up using.

Dog Food

The Dog Food sign is a 2.9" display which displays what food and medication each of our dogs needs to be given next. The information is stored in a YAML file, and the sign updates itself between each meal so that it's always displaying the information required when we're preparing their food. Medication is in red and food is in black, which helps remind us when medication is required.

Development Details

Each sign is driven by a separate program, all written in Ruby.

SyncSign Gem

The first step was to build a gem to talk to the SyncSign API, which would let me test out the hardware system as well as get something put together that would later be used to communicate with the signs. This went fairly smoothly, finding a few undocumented limitations here and there (some UI elements have to have dimensions or locations that are multiples of 8) but for the most part the SyncSign documentation is very good and gave me everything I needed to put this together. This is now available in RubyGems and the GitHub project is at [1].

Alert Sign

Initial Development

I ended up working on the Alert sign first once the gem was mostly completed, as it seemed the most straightforward. This sign pulls data from the openHAB API and displays it, and there weren't really any significant challenges in developing it.

Later Changes

Fairly quickly I realized that some alerts would be in place fairly long-term, for example Yellow Toner Low may be the case for quite awhile before actually needing replacing depending on how much printing we do with yellow. This would mean constantly displaying an alert on the display which would tend to lead to alert fatigue and not noticing the display anymore, defeating the purpose. I implemented a function to "acknowledge" alerts by putting them in a text file in the sign daemon's directory, which would then cause the sign to display the "System Normal" display, but with a note showing the number of acknowledged alerts in small type above that. This means that I can acknowledge the toner alert once I buy more toner, and not have to leave it on the display for months until the toner actually needs replacing.

We also discovered that my quick "put a suffix on a day" code didn't deal with 11, 12, and 13 correctly, but we like the quirkyness of it so we're leaving this in place and each month now has the 11st, 12nd, and 13rd in it.

Calendar Sign

Initial Development

The core functionality of this sign was straightforward, requiring the Google Calendar API to fetch events for a given day, then displaying them on the sign. The 4.2" displays have 4 buttons underneath however, which I wanted to make use of.

The SyncSign Hub is provided with an SDK, and by toggling the Developer Mode on you can run Python code on the hub itself. I put together a simple app to run on the hub that listened for button presses from this display and converted them to MQTT messages sent to the home automation system, which already ran an MQTT broker for use with other thing around the house. The daemon that drives the calendar sign is then able to move back one day, forward one day, or display as many events as will fit on the screen in a smaller typeface. After some time (a few minutes) of displaying this new screen, it automatically moves back to the "Today" view (or tomorrow, depending on the time of day).

Later Changes

The calendar display hasn't required any further changes at this point, really. I find I never use the Tomorrow or Yesterday buttons, but do use the More Events button to get an overview of the whole week on Sunday evening.

Weather Sign

Initial Development

This display is more graphical than the other ones we have in use, using icons to represent current and upcoming weather. The SyncSign displays have Erik Flowers' Weather Icons onboard, allowing display of these icons without having to push bitmaps over the Zigbee link every time. I wanted to use a 2.9" display for this one, which required putting some thought into how to best use the limited amount of space available. After playing with various options, I settled on a "split-screen" layout, with the left half of the display showing current weather, and the right half showing what's coming up next. The exact time of "next" depends on what weather is coming up, and the system tries to guess what we'll care about in the near future. If there's precipitation in the current day or the next day it picks and displays that weather, along with the time it's forecast to start, but if that's not the case then it displays a specific time in the future. Until 2pm it displays what the weather will be at 2pm, after 2pm it switches to displaying 8pm, and after 8pm it switches to noon the next day.

This display is a little different than the others in that it's not updated on a specific schedule, as weather changes in less predictable ways. Various factors cause the system to decide when to update it, based on whether it thinks we'll care about the difference between the stale displayed data and the current conditions. There's a balancing act here between updating too often which would run the battery down quicker, and not updating often enough which would end up displaying out of date information that's not useful. The daemon wakes up every 15 minutes and checks to see if any of the following is true: - Change from currently precipitating to not, or vice-versa - Change in time of the "next" weather by at least 2 hours if it's further away, or by at least 15 minutes if it's going to happen in the next 2 hours (so we get more frequent updates of when rain or snow will start) - Change in humidity or temperature by more than a specific amount - It's been more than 2 hour since the last display update If any of these are true, it pushes new weather to the display. If none of these are the case, it goes back to sleep for 15 more minutes. This system currently causes display updates about 10x/day on uneventful days and up to 20 on days with rapidly changing precipitation, which should be okay battery-wise. I haven't had to change any batteries yet since putting the system in place, so it remains to be seen how often they'll need changing.

Later Changes

The system required a lot of tweaking to get the refresh rate optimized, which meant adjusting all the various thresholds. I added tiny text under the current weather to show why the last update had happened, what time it happened, and how many times it had updated so far that day (e.g. "1505 9 H w" would mean the last update was at 1505, there have been 9 updates so far today, and the last update was because both the current humidity and future weather type changed significantly enough to force an update). This assisted in helping tweak the algorithm without needing to be checking logs every day.

Dog Food Sign

Initial Development

We have two dogs who are on various medications and amounts of food at various times of day, and it's sometimes hard to keep track of. I could print a page to put up near their food, but it would be out of date very quickly and still require looking up the correct time of day each time, which can be more error-prone than I'd like. We were ordering a second weather display anyways, so I added another 2.9" display to the order and made this sign.

This is probably the simplest of the signs as it requires no outside interaction, it simply displays the contents of a YAML file at the specified times of day. This file specifies what time to display the new screen, what it's called (Supper, Lunch, Snack, etc.), how much to feed (displayed in black) and what medication to give (displayed in red).

Later Changes

Shortly after putting up the sign, one of our dogs needed to switch to an every-other-day schedule for one medication. After thinking through how to handle this a bit (day of month mod 2 wouldn't work because on 31 day months you have two odd numbered days in a row, day of year has the same issue on Dec 31/Jan 1, etc.) I decided on using the Modified Julian Day number mod 2, which will continue toggling back and forth for the expected lifetime of this system. I added a field to the YAML file for options, and can now specify whether to display a certain medication only on even or odd MJDs. This functionality makes this sign even more useful, as keeping track of "every other day" medications can be difficult otherwise.

Project Outcome

The system as a whole has been much more useful than I had expected, and we've come to rely on it a lot. The ePaper type of display makes the units feel more like just displaying data right on the wall, and less like a display that's attracting your attention like LCDs tend to. The lack of backlight on them has not been a problem at all in practice, and further leads to them feeling like part of the environment more than something stuck on the wall.

Issues Encountered

Early on, the hub was crashing and rebooting every couple days. This resulted in a loud beep from the hub, as well as all signs disconnecting from the system and displaying their SyncSign Logo splash screens until the next update. I reported this issue to SyncSign and shortly afterwards a firmware update was available for the hub which fixed it, and I haven't seen any spontaneous reboots since then.

Future Plans

For the most part we're happy with the system as-is, but there are a few changes I still want to make.

Currently the calendar sign displays "[more events]" at the bottom if we have more than 6 events in a day, which I figured would only happen rarely. It turns out to not be as rare as I thought, so I plan to add a feature where the display will "scroll down" throughout the day if there are more events than fit on the screen. This will result in each event disappearing from the screen as it passes its end time, freeing up more space on the screen for future events.

The weather sign was designed in the fall, and as a result I completely forgot about wind chill and humidex as the temperatures have been mild. I'll need to figure out a way to put those on the screen soon, as wind chill at the very least is extremely important through the winter.

The dog food sign works great as-is, but having to edit a YAML file every time one of our pets is on a different medication or needs a different amount of food isn't ideal. I'll probably write a little web tool to change this in the future, so that I can update it from my phone more easily and not need to SSH into the server and edit a config file.