Difference between revisions of "Nest ePaper Signage"
m (SarahEmm moved page Household ePaper Signage to Nest ePaper Signage without leaving a redirect) |
|||
Line 55: | Line 55: | ||
** Cons | ** Cons | ||
*** Relatively unknown company, unsure if they'll be around long-term | *** 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 | *** Build quality feels cheap initially, though once mounted on the wall they feel a lot better | ||
Line 97: | Line 98: | ||
=== Later Changes === | === 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 | + | 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. | 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. | ||
Line 103: | Line 104: | ||
== Calendar Sign == | == Calendar Sign == | ||
=== Initial Development === | === 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. | ||
+ | |||
+ | == 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. | ||
= Images = | = Images = |
Revision as of 16:55, 24 October 2020
Contents
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
- Pros
- 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.
- Pros
- 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
- Pros
- 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.
- Pros
- 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
- Pros
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. 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.
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.
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.
Images
- Sign-Dogfood.jpg
Dog Food Sign
- Sign-Calendar.jpg
Calendar Sign
- Sign-Weather.jpg
Weather Sign
- Sign-Alert-Normal.jpg
Alert Sign - Normal condition
- Sign-Alert-Abnormal.jpg
Alert Sign - Abnormal condition