Comments (5)
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.
from amplipi.
Another idea was to show the serial number, which verifies that the EEPROM has been programmed.
from amplipi.
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
from amplipi.
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.
- Preamp board comms fail (all units, up to 6)
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.
from amplipi.
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.
from amplipi.
Related Issues (20)
- Robust TRY_BOOT script
- Stop storing state next to software
- Make a hosted API for release management
- Set system timezone from frontend
- Song names have "'" around commas in ui HOT 2
- Spotify streams with spaces in the names do not create HOT 1
- Version-checking in both the updater and main app report incorrect latest HOT 1
- runvlc/vlc streams sometimes don't stop running
- "Add Stream" button misaligned on Firefox HOT 2
- Move software install to someplace other than /home HOT 1
- Paused/Stopped internet radio steam plays after announcement ends
- Button color HOT 3
- FM Radio only outputs to left speaker HOT 5
- Make the display service work when the API is authenticated HOT 2
- Build manual on every release using GitHub Actions or similar
- Move "Always connect to this amplipi" option to the initial connection modal on mobile HOT 2
- Change button layout for manual connection modal on mobile HOT 1
- Add toggle option to source autoselection HOT 3
- Links in settings about should all open in a new tab
- Logs link in about->settings stays blue after being clicked once and becomes barely visible.
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from amplipi.