provide a way to silence "failed to read..." matron spam (in repl) #404
Comments
|
Ideally we'd fix the cause of these failures, so far not sure what's causing them though :( |
|
yeah. not great to just drop them on the floor. on the other hand, it's a bit noisy in the repl and could make folks think there's something up with the device. |
|
i'm fine to just mute these battery warnings for now and open a ticket to investigate. the code should also handle the fail more gracefully, ie, don't corrupt the previous read. |
|
Where does the repl get these logline from? Does it show all messages sent to |
|
@simonvanderveldt: i believe so. @ngwese can confirm? |
|
the repl prints whatever |
|
@ngwese : is there any way to know whether we're getting (or sending) EDIT: i'm sure this is a way; i guess i should rephrase and ask for your thoughts on how we might differentiate. looking at |
|
an interesting possible data point regarding the cause of the errors: i've only noticed the errors when my norns has been powered (specifically by my macbook). i don't think i've seen the errors when self-powered... |
|
@pq regarding separation of stderr from stdout in the repl- there’s only one stream sent over the websocket right now. |
seeing this correlation again. also fairly certain that the battery is fully charged when it occurs FWIW. |
|
Had this happen today whilst norns was running on mains power, no other connections. |
periodically, i see streams like this coming from matron.
norns/matron/src/hardware/battery.c
Line 62 in 484caad
is it adding any value? if not, it'd be great to have a way to filter this out.
assuming these messages should keep going to
stderr, it may be easiest (but not best?) to do this in maiden? (cc @ngwese)dunno.
The text was updated successfully, but these errors were encountered: