Add status to E-INK display

[gorski123]

@Lohrer and I were discussing the upcomming changes to the power board and one thing we thought about was how nice it would be for the E-INK display to report basic error messages if necessary. For example, if one of the power good signals for a supply was down, etc.

[Lohrer]

Another idea was to show the serial number, which verifies that the EEPROM has been programmed.

[gorski123]

Error states I think we should report. @Lohrer please chime in. 9VA power fail 12V fan power fail 5VA power fail AMP temps high PS temp high 24V supply out of range Power supply board comms fail LED board comms fail Preamp board comms fail

[Lohrer]

First, I'm not sure where all of this info is going to fit without needing a magnifying glass.

Second, going back to the roots of why we decided to keep the display at all, we needed a way to report information that is inaccessible until you access the AmpliPi over Ethernet. That meant knowing the URL to access and the password if trying to SSH. Everything else was dropped to save space on the new smaller display and to keep it simple.

If the display is being updated that means the Pi is working (+5VD is good, a service USB isn't plugged in, etc). If the Pi is working then we can report any status we want in the web UI/log. So from that perspective, the things we should for sure show on the display are related to "why can't I access the web UI/log". Also the support tunnel if that's running separately, I'm not sure how that works though.

So the status I'd recommend showing on the display is which pieces of AmpliPi are up and running:

• Network status
  • This is already shown as No Network/No IP or similar, just adding here for completeness.
• Webapp/API service
  • It would be great to have an indication that the systemd service for the webapp/api is down so we know if it's worth even trying to access the webapp.
• Support Tunnel?
  • I'm not sure how this got implemented, but if there's anything stopping the support tunnel from being created it would be nice to know. If something is going wrong the support tunnel is how we're going to get info if the user can't give it to us themselves.
• Hardware self-test status, aggregating a total of up to 103 individual statuses assuming I haven't missed something here.
  • The "check-engine light", this won't tell you what's wrong but it will tell you that you should go find more info.
  • This is the stuff you're talking about Jason, but since we don't have many pixels to show everything it's in aggregate.
  • Things that can cause the self-test to fail (pretty much what you said Jason):
    • Preamp board comms fail (all units, up to 6)
      • I believe that I2C internal comms failures still cause lockups, so this includes LED/Power board comms fails.
      • If we do end up reporting internal bus comms failures as apposed to just the controller bus failures, that is a maximum of 6 * 7 = 42 devices to report the status of.
    • Power bad (for all units, up to 6)
      • 24V out-of-range (TBD what that range is), up to 2 rails
      • 12V fan power bad
      • 5VD bad
      • 5VA bad
      • 9VA bad
    • Temps bad
      • Pi temp over/under temp
      • Amps over/under temp, 2 sensors, up to 6 units
      • PSUs over/under temp, up to 2 sensors, up to 6 units.

As for the original reason I chimed in on this issue, it sounds like Ryan has a different idea of when to show the serial numbers as I did, and at least for my original purposes I'm not even sure we need to show them if we have the "check engine light". I just wanted to avoid units being shipped with unprogrammed EEPROMs.

[gorski123]

First, I'm not sure where all of this info is going to fit without needing a magnifying glass.

Plan is to use error codes for each error state (E01, E02, etc)

Second, going back to the roots of why we decided to keep the display at all, we needed a way to report information that is inaccessible until you access the AmpliPi over Ethernet. That meant knowing the URL to access and the password if trying to SSH. Everything else was dropped to save space on the new smaller display and to keep it simple.

I think its very useful to have errors on the screen and and think with error codes we can do this.

If the display is being updated that means the Pi is working (+5VD is good, a service USB isn't plugged in, etc). If the Pi is working then we can report any status we want in the web UI/log. So from that perspective, the things we should for sure show on the display are related to "why can't I access the web UI/log". Also the support tunnel if that's running separately, I'm not sure how that works though. It would be really nice to perhaps show tunnel open, tunnel active on the status? If this is a big lift it is not necessary

So the status I'd recommend showing on the display is which pieces of AmpliPi are up and running:

* Network status
  
  * This is already shown as No Network/No IP or similar, just adding here for completeness.

* Webapp/API service
  
  * It would be great to have an indication that the systemd service for the webapp/api is down so we know if it's worth even trying to access the webapp.

* Support Tunnel?
  
  * I'm not sure how this got implemented, but if there's anything stopping the support tunnel from being created it would be nice to know. If something is going wrong the support tunnel is how we're going to get info if the user can't give it to us themselves.

* Hardware self-test status, aggregating a total of up to 103 individual statuses assuming I haven't missed something here.
  
  * The "check-engine light", this won't tell you what's wrong but it will tell you that you should go find more info.
  * This is the stuff you're talking about Jason, but since we don't have many pixels to show everything it's in aggregate.
  * Things that can cause the self-test to fail (pretty much what you said Jason):
    
    * Preamp board comms fail (all units, up to 6)

take away from this @mjustian is you will need a way to show which preamp is inaccessable in the error code, It may just be an index number in the error code. For example index 0 is the preamp in the main unit, index 1 is the preamp in the next expander. Or perhaps we show something on the display like total number of zones.

      * I believe that I2C internal comms failures still cause lockups, so this includes LED/Power board comms fails.
      * If we do end up reporting internal bus comms failures as apposed to just the controller bus failures, that is a maximum of 6 * 7 = 42 devices to report the status of.
    * Power bad (for all units, up to 6)
      
      * 24V out-of-range (TBD what that range is), up to 2 rails
      * 12V fan power bad
      * 5VD bad
      * 5VA bad
      * 9VA bad
    * Temps bad
      
      * Pi temp over/under temp
      * Amps over/under temp, 2 sensors, up to 6 units
      * PSUs over/under temp, up to 2 sensors, up to 6 units.

As for the original reason I chimed in on this issue, it sounds like Ryan has a different idea of when to show the serial numbers as I did, and at least for my original purposes I'm not even sure we need to show them if we have the "check engine light". I just wanted to avoid units being shipped with unprogrammed EEPROMs.

[rtertiaer]

I think this issue has two components - the framework for actuating and displaying monitoring statuses, and the bulk of the statuses we check for. I think most of that first part is addressed in #719 , but we will fast follow that PR with many of the actual monitors mentioned above to use @mjustian 's very spiffy framework.