Muninn - Battery Wisdom

[rough token]

I've just published my newest app (although it didn't appear in #releases) - Muninn! Odin's bird of memory is taking a stab at observing and predicting your Pebble's battery life.

The approach here is to create a minimal and useful battery tracking application that does not impact battery life and can be tuned over time. It does this by leveraging the Wakeup API instead of the Background Worker.

You can get it here: https://apps.rebble.io/en_US/application/692b3821d7dcba000a809ba5 🌟
Source code: https://github.com/C-D-Lewis/pebble-dev/tree/master/watchapps/muninn

I'm reasonably confident it works well but I would humbly request some testers! Things that need more thorough testing than I was able:

• OG Pebbles that have had their batteries replaced
• OG Pebbles that have not had their batteries replaced and live only for a few days
• Multiple contiguous charge cycles
• Watch Left Dead In Drawer For Days scenario

Please report bugs here or in the repo and let me know if/how you get on!

[grim tree]

this looks awesome!

i wish there was a way for it to not require being manually opened after every reboot, but i assume the system doesn't provide a way to do that?

[rough token]

That's the main thing - the Wakeup API tells the user if an app had a schedueld wakeup while it was turned off, but does nothing to notify the app. Unless you frequently reboot it and charge it while on (usual case), I hope it won't be too much of a problem.

If you launch it after a missed wakeup, it tells you and immediately schedules a new wakeup to resume.

[grim tree]

my watch crashes occasionally, not to mention firmware updates are relatively frequent on core devices currently is my concern

[rough token]

Totally valid - I wonder if the newly open firmware can provide the app with a notification or some other resume option to the user...

But I'm not a fw engineer 🙁

[grim tree]

either way, it's a minor issue really - much better than the 10% battery hit of using battery+ (not to mention that battery+ is Quite Broken on core)

[grim tree]

it would make a lot of sense for wakeups to just... persist across reboots

if there's a wakeup scheduled at 1800 and my watch is rebooting between 1700 and 1701, there's no reason that wakeup can't still happen

[rough token]

Ah - it does, but if it goes off while powered off, the app doesn't get told. If you quickly reboot before the next wakeup, no issue

Yep

[grim tree]

ahhh okay, i assumed any reboot would mess it up from the description

if it only gets up if i happen to have the watch off exactly when the wakeup is scheduled, that's not such a big issue

does the logging work while disconnected? i assume so?

[rough token]

Ah yes I see how that could be confusing. I will try and clarify it.

[rough token]

Yes, there's no JS component at all

[grim tree]

awesome

also i love the bird

any app that has a mascot instantly gets +500 pts

[rough token]

Thanks - it helps with the passive monitoring metaphor but isn't the main focus. I'm also not an artist beyond tracing over a royalty-free raven image...

[tranquil mountain]

Huginn and Muninn

[rough token]

Indeed! Maybe Huginn as the 'thinker' would be better placed for an app about data processing.

[tranquil mountain]

I know and use the existing Huginn open source tool

[rough token]

Interesting, is it useful?

[tranquil mountain]

Basically self-hosted IFTTT with way more hackability

[main drift]

Just installed it to test it out! ill let you know how it goes

[sleek jay]

1. i'm pretty sure i didn't use 20+% battery in one day
2. that text layer needs to be a bit wider

also that ~ looks a bit ugly in that font, imho it should be centered vertically

[rough token]

Very interesting, thanks! This kind of thing is why that page exists in such detail. Indeed, that bit of text needs to accommodate two digits.

The reason for that estimate is the 2% change in battery charge (dC) over only two hours (dT) - extrapolated for that rate for a whole day it ends up being large. If future measurements are over full six-hour periods the weighted averaging should make this point less significant.

I guess perhaps you toggled Muninn asleep/awake at 21:59? I should try and handle that more gracefully. Thank you for testing!

Re: fonts - I used the defaults only. A bit lazy!

[rough token]

I allowed the first estimation period to be less than the full six hours so that value would begin for the user a bit quicker, but if this kind of possibility means a bad first reading then I should probably use full intervals only and they will wait a bit longer. It is passive afterall so not the end of the world...

[rough token]

I'll also update some of the wording to emphasize estimated daily rate that isn't over the last day to avoid confusion...

[grim tree]

estimated %/day?

estimated discharge rate per day?

(if you can fit it)

[rough token]

Yes, I'm thinking the same. Going for 'daily' and 'est % daily' for now. Hard to make the log more intelligible but the level of detail is vital for debugging remotely. I'll keep thinking about it.

(test data in screenshots, doesn't make total sense)

[grim tree]

I think "Est. %/day" would be clearer

[rough token]

I agree 👍

I'll release an update before I go out for the day

[pallid solstice]

started 2 hours ago but apparently nothing in the data log yet, is that normal?

[rough token]

Yep - it wakes every six hours and starts producing predictions after two meaningful samples.

00, 06, 12, 18 etc.

[rough token]

Also if it wakes and the battery hasn't changed at all it'll just wait another interval. I might add a summary log entry for that in case it confuses

[rough token]

I've set up a PT and P2D on my desk and will leave them alone to see if the predictions after a couple of intervals remain true when they're about to die🙏

[grim tree]

on my p2d so far

[rough token]

Seems sane! 👍

[tranquil mountain]

How many cycles are required before estimations are shown?

[valid peak]

Took me too long to figure out how to wake it up.

[tranquil mountain]

Nevermind, I see it's after 2 "meaningful" samples

[rough token]

Yes - two six hour intervals. Leaving it overnight from 12-6 seems the quickest period - when a person is asleep 👀

The reason it's two is so the averaging can do some work, in case the first and only sample is too high. Maybe it could be customizable...

[rough token]

That's fair - there's no common visual cue I've seen in the ecosystem for 'long press' than a notched button image like I used. Perhaps a menu entry would be easier? Or on by default? I thought it would also help tutorialise that it can also be disabled...

[grim tree]

on by default with a "disable" option in the menu would probably be clearer

[rough token]

Indeed, although I quite like the action. Maybe there's a compromise, if not I'll likely go that route anyway

[tranquil mountain]

Installed yesterday. Left it for a while. I seem to have no data logged.

Yes Muninn is awake

[rough token]

Has it been 12 hours?

[grim tree]

has the battery level changed in that time?

[rough token]

Oh, that is relevant! I might make 'no change' wakeups appear in the log if it's going to confuse.

[tranquil mountain]

It's been 12 hours for sure, maybe 2% battery loss since installing

[rough token]

Which watch model? Is there anything in the 'Data log' page from the app menu?

[tranquil mountain]

P2D, data log page is empty. "No estimates yet"

I can see the countdown...counting down to when the sample is supposed to happen. I have enabled the vibrate on sample option

[rough token]

Hmm, strange. Can you try using the 'Delete all data' option, waking Muninn, and then not sleeping it or resetting data for another 12 hours please?

In the meantime, some more pending changes to clarify wording and help the user know what to do / is happening

[tranquil mountain]

Sure. Just deleted the data and woke it up

[rough token]

Thanks! What time is it where you are?

[tranquil mountain]

14:49

It claims next sample time is in 2h

[rough token]

Are you able to get logs with the SDK?

I wonder if I gmtimed when I should have localtimed...

[rough token]

I just published a new version which replaces uses of gmtime (utc) to localtime (local timezone) - should correct the next sample timer time at least

[tranquil mountain]

Okay, it claims sample time in 32 minutes. I enabled vibrate. Will advise.

[tranquil mountain]

Er, now it says 46 minutes

[tranquil mountain]

Aha. Muninn just notified me

[rough token]

Mine didn't take any samples overnight 😞 seems perhaps I have a bug to find...

[rough token]

Probably somewhere I didn't consider the new status types although I tried quite hard...

[rough token]

Actually it might just be a little slow on the uptake - I can see mine is waiting for noon today. Not sure what happened at 6AM though.

[rough token]

I found the issue by reading the code - I changed how the app determines if any samples at all have been taken, but that value isn't set on the first ever sample - so it's in a loop forever of not recording samples. Will make a fix this lunchtime! 😅

[rough token]

Published the new version 1.4 - you should see it in the menu so you know it's updated (pull down in the Pebble mobile app Apps page and then launch to update it)

[verbal jacinth]

just installed this on my tintin :D, so far i like the ui

and ill let you know how well the tracking handles my wonky battery lol

[rough token]

Yes please - a wonky battery scenario will be valuable data

[tranquil mountain]

Seems to be working for me now

[rough token]

Awesome! 😅

[verbal jacinth]

a settings page that lets you see the logs from your phone would be cool

[rough token]

I have thought about copying the data log to the phone and vice versa so you can resume after uninstalling and reinstalling the watchapp. Could be a good feature!

[languid merlin]

Just want to say that this looks awesome at first glance. Thanks for the hard work!

[magic berry]

i have just installed and enabled Muninn on my snowy! let's see how this works

i'm curious what the math is doing to account for the possibility of receiving a 10% interval or a 1% interval

[verbal jacinth]

so, after letting muninn do its thing overnight, i went to check and it did track the battery but now it's asleep and if i try to wake it up i just get "Error: Failed to schedule wakeup"

[rough token]

Hmm, that either means the time it picked to wake was invalid or within the same minute as another wakeup which is unlikely given how little this API was used back in the day. Do you have any other apps that use it? Are you able to get logs with the Pebble SDK? The app logs it's internal state when it opens.

[rough token]

Me too - probably estimations near or on 10% rates, or if you get two changes near the ends of the day, perhaps an estimation that's higher than it should be. I'm very interested to find out!

I have a red PT sitting on my desk this week and when it dies I should have some recent data points

[verbal jacinth]

ohh i think it mightve conflicted with pebble in action maybe?

it's working now tho which is good

[rough token]

I'm glad! If another app (or the same app!) has a wakeup scheduled within 30s of the time I try and schedule it, it will fail. Can you link me to this other app?

[magic berry]

oh my little bird failed to schedule a wakeup

recurring wakeups feels like a fragile way to schedule things

[tranquil mountain]

Sounds like a problem due to the limitation of the wakeup API

In my mind, if more than 1 app or service is scheduled for a wakeup, the OS would queue them

[magic berry]

hm, i removed PebbleInAction, rebooted my watch, removed and re-added Muninn, and it still is unable to schedule a wakeup on my snowy

how can i help debug this?

[rough token]

I observed when changing the uuid that the wakeups are not released when an app is uninstalled - you'll have to wait for the next 6h interval your time (00, 06, 12, 18 etc) and try again.

I wasn't aware that wakeup was used even this much! Perhaps using the time Muninn is woken as the start and then count six hours from there, or alternatively add a random small number of minutes etc... need to think about it.

Thanks for the valuable testing!

I also found Pebble In Action and it looks cool!

[magic berry]

does it not count six hours from when it first starts? i assumed thatd be how it does it

if it's going for 12, 3, 6, 9 on the dot, then it makes sense the spot would be conflicted, haha

[rough token]

Nah, just a modulo on the hours of the clock. I guess I didn't think too hard about that part. I can make a fix tonight 🙂

[magic berry]

might not be a bad idea to, upon failing to set a wakeup, try again with a random offset of minutes

muninn is super cool, i love the theming and the visuals

[rough token]

That's another good option!

[rough token]

Open question - should it continue to wait for two full samples before showing an estimate, or after one but it could be an underestimation? I wonder if waiting for Muninn to wake three whole times before getting anything interesting is too long to wait:

Initial reading -> first estimate -> second estimate -> averaging can start.

[verbal jacinth]

i dont think thats right lmao

[rough token]

Hmm. What battery level does the system say in settings?

(although I have complete faith in battery_state_service_peek())

A peek at the top of the data log page might also be useful please

[verbal jacinth]

my bad i shouldve clarified that its not really an issue with the app its just that my battery reading is weird and will stay at 80% most of the time and then go down quickly

i was not joking when i said my battery was wonky lmao

[rough token]

No worries 🙂 Is it a very old battery?

I guess it can stay on at 0% and then suddenly die?

[verbal jacinth]

its usually good about shutting down at 0% and going to the clock-only mode thingy, the only issue is the whole staying at 80% thing

[verbal jacinth]

not necessarily old just smaller than its supposed to be and stolen off a like under $1 temu smartwatch we had lying around lmao

[rough token]

Ah right. Maybe it isn't compatible with the pre-set charge curves or something. I'm still interested in your testing of a full charge and discharge if you can

Can you post a phone of the top of the data log please? Curious what the most recent drop was

[rough token]

Well the maths don't lie 😕

I wonder what could be done although it feels like an uncommon case, given the sudden jumps in reading

[verbal jacinth]

yeah i dont really expect much to be done, mainly i just found the 127% funny

but also the UI should maybe be fixed to be able to handle 3 digit numbers

[rough token]

That's a valid point! I'll look into that although I'm not sure how frequent an occurrence >25% in 6 hours is. It definitely broke the UI though.

[rough token]

I struggled to find an icon that says 'next wakeup in X days or hours' - here are three candidates. I slightly prefer the calendar with pencil but there could be more obvious options I haven't considered.

[grim tree]

calendar with checkmark maybe?

or calenar with clock if you can fit it inot that few pixels

or maybe an arrow

[rough token]

Not sure what the checkmark would signify. Pencil means 'making a note' in my mind. I like the calendar with clock denoting a timed event though.

[grim tree]

checkmark would imply "the wakeup is scheduled"

pencil reads as an edit icon to me, which i guess it kind of is because the log of events will be edited in an hour, but that's kind of abstract

[rough token]

I hear you

I also considered a 'sunrise' icon although the 'wakeup' terminology isn't something the user is aware of

[grim tree]

i feel like the hard thing is that you need to imply "next"

and i'm not really sure how you do that with iconography

hey @magic berry how do you imply next with iconography

[rough token]

Maybe something like this

Too abstract maybe

Or just "T- Xh" 😆

[magic berry]

huh what

my first thought for "next occurrence" would be some variant on ⏩ or ➡️

[grim tree]

hrm

maybe arrow clock?

but that's... still kinda unclear, since what's actually being communicated is "data will be updated in x hours"

[magic berry]

of the ones here, i think calendar with clock is my favorite. alarm would imply to me that the watch is going to buzz or something, which is surprising and upsetting

maybe you could put a bar graph icon or something, to imply "data"

T-minus would be cute

i think that putting an amount of time next to the battery readout scans as "this is how long the battery will last"

[grim tree]

i feel like it's not unclear since there's a very clear "days left" right above it

[magic berry]

silly suggestion: a graph or an eyedropper for "next sample"

[magic berry]

yeah i hadn't looked at that part

xp

[rough token]

Thanks! Eyedropper is a new angle

Such as this MDI icon

I actually quite like it

[verbal jacinth]

hm yeah maybe

[rough token]

For "Sample" indication you can't get much closer. I don't think petridish is an option...

I'll make a new release shortly with fixes for wakeup clashes and include the new icon but I feel the UI is still mostly v1

[verbal jacinth]

yeah fair lol

[tranquil mountain]

lol the clock was way more obvious to me as when it would be collecting data

[rough token]

I guess interpretations are subjective. Maybe it should be a user configuration! 😂

[tiny yacht]

going with the bird theme, it could be a worm or something lol 🪱

I like the eyedropper or calendar with pencil

[magic berry]

i do wonder what useful information you could get from just two data points. personally i would rather wait

XKCD about extrapolation, and all

[verbal jacinth]

update it has gone down to 99% lol

[rough token]

It's better than just one data point 🤷‍♂️ If the user has to wait a whole day or more for three, four, etc then they may get turned off using it.

[rough token]

My PT I left all week tried to load the app when I used quick launch and complained it was disconnected. Guess it decided to unload it for some reason.

I installed the latest version about noon and at 6pm it made a reading that looks reasonable!

[magic berry]

i noticed muninn unloaded from my snowy overnight a couple times, too. luckily it seems to have still taken a reading

i wonder if apps will re-load themselves for wakeup events

[rough token]

My understanding is apps are unloaded if space is needed or the phone pairing changes. But my knowledge is probably old && incomplete...

In this case the watch was disconnected all week

I wonder if anyone apart from the emulator gets the app glances

[magic berry]

I saw app glances on my basalt!

seems to be classic pebble app vs core app that makes the difference

[drifting terrace]

how are you doing glances?

I guess I could have a look at the source code

[rough token]

Hmm, I thought it was purely C side, although the docs describe a web API I've never used.

Here: https://github.com/C-D-Lewis/pebble-dev/blob/master/watchapps/muninn/src/c/modules/glance.c

[magic berry]

i have a hunch there was some logic on the host app side for organizing appglance slices. when i switched to coreapp, i started having problems with app glance, even on super simple C apps like Today Is, and even on my Pebbles Time

[drifting terrace]

oh, huh

slices are sent back to the phone

reading the firmware source code is a cool exercise, but not how I wanna spend my evening tbh

[tranquil mountain]

lol I see the raven now blinks

[rough token]

Oh, I never knew that. Maybe so they can be consolidated with ones set by the web API

[rough token]

Yay, someone noticed! 😂

[drifting terrace]

it is a weird idea to some extent because it feels like some of the glances may be this watch only

[rough token]

It was a late stage thing, likely only a v1 before the company colapsed

[drifting terrace]

yeah

I mean, there are 3 entry points for glances specifically

which is way more than even pins

[rough token]

I like the idea but maybe it was overambitious as a starting iteration. Anyway, if it works, Muninn will provide a glanceable estimate 🐦‍⬛

[rough token]

I'd love a battery_state_service_get_uptime() or something in the FW. Then something like 'time since + time remaining' could be calculated

[magic berry]

so so cool. i love appglance

would be awesome to have that estimate placed in timeline as well, esp on watches that you might only remember to charge once a month

(say it with me, folks)

[magic berry]

https://github.com/pebble-dev/pebble-sdk-rfc/issues ‼️

[grim tree]

mister ant tenna's-

wait no

[tranquil mountain]

2% !

[rough token]

Impressive! My P2D gets that sometimes too. Also I should nudge that 18m text a bit to the left!

[rough token]

A timeline addition would be cool. I can't remember if pins can be adjusted? Would need to do so if the estimate changed

[grim tree]

it's definitely possible to delete one and make another

[rough token]

Done!
https://github.com/pebble-dev/pebble-sdk-rfc/issues/9

[rough token]

Something like this?

(thanks to coreapp's web request interception mechanism I could use code from examples)

(but with GENERIC_WARNING ⚠️ instead)

Can't use custom icon until the Python attr error for publishedMedia.timeline is resolved in the SDK.

[tranquil mountain]

Is uptime available to apps?

Would be nice to show the uptime somewhere

[rough token]

It's not, but I just created an SDK RFC issue for it

Although if partial discharges happen at arbitrary times since boot, I could not reliably show a total lifetime of the charge. I might be biting off more than I can chew actually...

[rough token]

I've updated my pebble-timeline-js package for flint and tested it works with coreapp's intercepting mechanism - others may find useful

Published the initial pin feature, we'll see how it goes!

[tranquil mountain]

Might as well also chop the name down to just "Muninn" since it gets cut off in the app list on the watch?

[rough token]

That's a strange one. The package.json uses one word, but the appstore name is the full one (discoverable!)

For some reason the launcher uses the appstore entry name

[hollow nacelle]

I am also working with this now and it's great

[rough token]

Maybe I should make a project thread for it although it's old and basic. But does the job.

[drifting terrace]

I was thinking about reviving a few timeline libraries

like the python and ruby ones, because it's just easier to use a library than doing all of that stuff manually

[rough token]

Sounds like a good idea!

I have pebble-timeline-js-node which was supposed to be for Node.js based servers pushing topic pins, like for News Headlines and Tube Status.

But it's not updated in any way yet

[drifting terrace]

yeah, the ruby gem that was there fails with ruby 3

I was meaning to update it

[verbal jacinth]

my battery stayed on 100% all day yesterday somehow so now i have this lmao

[verbal jacinth]

on related news i am getting a proper replacement battery soon which is nice

[rough token]

What does the data log look like?

Then we can work out how those figures were arrived at (or not!)

Bear in mind it uses more data points that just the last day

[verbal jacinth]

oh the data makes sense its just my battery being weird in a different way for some reason

but also now because it's started going down quickly the estimates have gone up and for now theyre actually at a point where they make some sense (battery lasts about 2 days, muninn says im using 38% battery in a day)

[rough token]

I'm glad! 🙂

I was thinking earlier you might be the only person to routinely get the timeline pin to remind to charge at noon the same day if you spend a lot of time on 0 days remaining

[verbal jacinth]

lmao yeah actually

[verbal sparrow]

Really liking this app. Using it on iOS with a P2HR and the old pebble app

Correctly been telling me that the watch has around 4 days of battery from a full charge

[rough token]

That's great! 🙌

Especially as it's a combination I don't have direct access to

[fiery tundra]

Hi, i have 1 question in mind. What is the thought behind choosing "crow" in your design? I'm so curious sorry 😅

[rough token]

Hey! I wanted a good name for the app instead of something boring like "battery tracker" and Googled mythical or legendary figures associated with watching or memory, and Odin's raven Muninn came up.

I think it helps with the idea the app is a passive one that just does its thing.

[fiery tundra]

Ahh okay.. i can sleep now thanks!😁🤗

[rough token]

Sleep well!

[opal vigil]

pretty dope app

[rough token]

I wrote a blog post since I reckon v1 is reasonably stable.

https://blog.chrislewis.me.uk/?post=2025-12-07-Muninn-Battery-Wisdom

[verbal jacinth]

i wonder who that's about /silly

[drifting terrace]

this update was made by @grim tree

[rough token]

You got me! To be fair it's probably a much more common case ten years on than I thought

[grim tree]

wait, what?

[drifting terrace]

did you not make this?

[grim tree]

nope

[drifting terrace]

oh no, my memory

[grim tree]

wait you're probably confusing it with the note i added to the dev site about how the battery life in the specs might not always apply

[drifting terrace]

oh

I am

[verbal jacinth]

yeah surely im not the only one with a wonky battery lol

[sleek jay]

the last 2 time periods seem to overlap (0 -> 6 and 0 -> 12)

my watch was on for most of the day, except for a firmware update around 18:00

also wow, c2d battery lasts so long 😮

[rough token]

Hmm, that is very strange. Especially as wakeups get a whole minute to themselves, so I'm hesitant to consider some kind of double wakeup.

Ohhh... I think if there's no change in battery level I ignore the wakeup and wait longer for the next. So while it looks confusing, the measurements were somewhat logical

But it needs some more thinking about for sure

Something like that

https://github.com/C-D-Lewis/pebble-dev/blob/master/watchapps/muninn/src/c/modules/wakeup.c#L96

[sleek jay]

does muninn save its predictions somewhere?

it'd be fun to some day have graphs like this x)
https://xkcd.com/2014/

xkcd: JWST Delays

Since delays should get less likely closer to the launch, most astronomers in 2018 believed the expansion of the schedule was slowing, but by early 2020 new measurements indicated that it was actually accelerating.

[rough token]

Only locally. I have an idea to export and import the log to the JS side in case you want to re-install it. Maybe there could be something like that there.

There is actually an inaccessible prototype graph window in the codebase, but beyond showing 8 values I couldn't think of any real value for the user.

It's also hard to track full charge cycles if the user doesn't regularly charge to 100%, and if it goes to 99 before the next sample time, Muninn might miss it. Needs more thought.

[rough token]

Seems localStorage is kept on the phone, at least in coreapp, but not the emulator if wipe is used (which makes sense) - this could be workable.

[rough token]

Said prototype graph with my watch's current data. Not sure how useful this is - ideas welcome!

[magic berry]

i'd like to see it! i like graphs

[verbal sparrow]

Suggestion: define the x-axis. Is it 18:00 each day over 8 days, or 4 hour intervals, or some other timescale?

Would love to see this in the app by the way.

Might also be interesting to plot predicated days remaining.

(Pretty sure my watch said 7 days remaining 2 day ago, then dropped to 4 days yesterday, then 3 days today: usually get 4-5 days from this P2HR)

[rough token]

Hmm okay, I'll persue it further. I'll need to handle the case the 8 points are over two days, but the point the trend line hits the bottom is like 20 days further out... could be small.

[rough token]

Thanks - it's currently two whole days, but agree it's currently a bit meaningless!

[rough token]

Sounds like it's converging to something. Ideally the rate will settle and so when the battery is charged it'll provide a reasonable estimate

[verbal sparrow]

Yep. Be interesting to see what it says on the next charge: 7 days straight off the charger sounded way too optimistic

[fiery tundra]

I hope your app is the #1 solution for monitoring pebble battery! Anw do you planning to give some color for colored screen pebble?

[rough token]

Thanks! I just hope it is accurate and more modern.

There's a flash of good old Jazzberry Jam on the button hint bar on color watches - aside from an unconventionally colored raven, where else would you expect colors?

[fiery tundra]

Raven should be black! Lol 🤣 i don't know.. maybe the stripes, or the separator, or font, or icons.. you tell me! 😁☺️

[rough token]

Interesting ideas! I'll have a think

[abstract totem]

Let me tell you, it's a great app. I use it on my pebble steel classic and it works great. 🔥

[rough token]

Good to know! What kind of numbers are you getting, and are they in line with your observations?

And have you replaced the PS battery?

[slate mason]

I just installed it on Pebble Steel (Aplite), Pebble Tiime (Basalt), and Pebble 2 Duo (Flint).

Here is my first observation of the UI. All of the UI:

The font size is usually too small.

• The Settings page uses such a small font, I can't read it without reading glasses.
• In the About page in the watch app, the font is nearly impossible to read without shining a bright light on it and using reading glasses.

Note: I don't need glasses to drive a car or do most things. The chosen font for each aspect of this product is usually smaller than it should be. A user would rather scroll than squint to read.

[fiery tundra]

Maybe have an option to make font bigger, standard, and small?

[grim tree]

The OS allows apps to conform to the font size selected in the settings

[sleek jay]

100% agree about about

but the settings font looks the same as system settings to me?

bug: the app doesn't support left-handed mode

the ui assumes buttons are on the right

[grim tree]

I don't think there's anything they can do about that

I don't believe they added an API for apps to tell when the screen is flipped

[rough token]

Yes, no new APIs yet. I also wonder even if there was what an app could do to flip everything, even text and images...

Maybe framebuffer but it doesn't work on the whole window IIRC

[rough token]

Valid feedback, thanks! Scrolling is Hard (the layers behave strangely) but I will try and find some solution. Maybe some of the pages of text can be removed because they're just a vague sort of tutorial...

[sleek jay]

I think paging would work better than scrolling. You have 3 paragraphs of about equal length, and each of them could be its own page

[rough token]

True. Although for each of those to fill a page would be a very large font. It would give me an opportunity to expand and explain a bit more though

[sleek jay]

it's okay to have some wasted space

[rough token]

Let's see what I come up with 🙌

[slate mason]

Generally speaking, you should limit the amount of text in the watch to what is absolutely necessary. Informational things can go in the phone app's Setting page. As for the Settings page, it's also a good idea to avoid a lot of words.

[rough token]

Good points! Although this is an unusual app so it's also important to explain and manage expectations accordingly. I'll look into a paging solution I think

[slate mason]

First of all, Chris, I want to say that I'm very grateful for this app to exist. My comments are founded on my desire for it to be easy to use and the most useful.

The watch app can use some re-distribution of screen space.

"AWAKE" and "ASLEEP" are already represented by icons. This text consumes a lot of space and provides no additional information, so should be removed.

The pretty border separating the top section from the lower three should be reduced to a single pixel width line.

"Muninn is" at the top should go. It provides no information.

The gray border along the right edge with black button indicators takes up too much screen space. It needs a re-design.

"Awaiting x estimate..." should be replaced by a single icon and the digit. The icon will be easy enough to understand. "Awaiting x estimate..." is impossible to read without shining a light on it and wearing reading glasses, so effectively communicates nothing.

The icon for "Days left" should communicate "Days left". Therefore, the text, "Days left", isn't necessary. Same goes for "Est. % / day". If those icons don't communicate clearly enough, then improve the icons. Unreadable, tiny text doesn't effectively communicate.

The "Days left" icon shows a clock face in it, which implies hours and minutes. Since you wish to communicate days, the clock face in the icon should be replaced by something that represents days.

All in all, I love this app. So, please take my suggestions as constructive.

[slate mason]

On Aplite (Classic and Steel), the bird icon is just one white pixel when selected.

For consistency with other icons in the list, consider drawing the bird as an outline instead of solid black. It will be easier to recognize too.

On all watches, "Muninn - Bat..." should be reduced to "Munnin".

[magic berry]

i guess the aplite launcher doesn't automatically invert... you should be able to address that by adding a white background on BW. it'll invert on diorite+, and will show a background on aplite

On all watches, "Muninn - Bat..." should be reduced to "Munnin".

watchapp name is actually a mobile app issue - when you get an app from the appstore, its name on the watch will match the full name from the rebble app store, not the short name from the watchapp package itself

this is something that should probably change

[slate mason]

Then, change the name in the App store to "Muninn".

[magic berry]

there are good reasons to have a long, descriptive name on the appstore for discoverability

we should be able to have both

[rough token]

Yep, I wanted 'battery' in there for discoverability, but not to call it something boring like 'battery monitor' etc. I think eventually it should use the package name.

@slate mason Thank you for the detailed feedback, I appreciate you taking the time! I'll see how many things I can address or at least compromise on. Re: icons - I'm no artist, so I'm working with the closest I can find in free icon sets. My first task when I find dev time is to remove all use of Gothic 14, it's just too small I guess. 18 or above only!

[slate mason]

You can include custom fonts, so don't feel constrained by the OS' built in fonts.

I just checked how my own watchface displays in the menu. I regret that it also gets abbreviated with an ellipsis (...). The watchface has been there for 10+ years, so it's too late to change it. My next watchface will be sure to have a shorter name.

On second thought, Chris is right about discoverability. So, keep "Battery" in the name.

However, "Monitor" would be a better word than "Wisdom", as it is descriptive.

[magic berry]

i like the wise raven 🙁

[fervent jungle]

I'm not sure you can have little icons that effectively convey complex concepts..

[hollow nacelle]

(ContentSize API: https://developer.rebble.io/guides/user-interfaces/content-size/)

[slate mason]

Unfortunately, it doesn't appear the UI allows for apps and watchfaces to have secondary information that gets displayed in tiny text below the name in the list.

[rough token]

Thanks, I'm aware of that. My problem with switching font sizes within one screen size is problems with exact positioning and line overflows come into play. I'll see what I can achieve without unless it's clear it's required.

[hollow nacelle]

Yeah it stinks. I have a bunch of fudge amounts to make things work and then sometimes it still doesn’t and I’m too scared to fix a cut off g

[magic berry]

my kingdom for pebble textlayers that work like figma text

"here's the origin and width, you may have X vertical lines, tyvm"

[rough token]

I'm half working a scaling library that will allow something like 'describe once, scale per-platform' but it's not very useful yet.

[fervent jungle]

In a perfect world, we would have visibility-maximising as well as design-maximising variants..

[slate mason]

The current screen size outliers are Pebble Round (Chalk) and Pebble Time 2 (Emery). I had to do careful custom editing to get my watchface to fit correctly on 144x168, 180x180 (round), and 200x228. Each of these has a different aspect ratio, so it's not a simple matter of scaling up and down.

Also, there currently isn't a large enough system font for my watchface text to increase to the point of looking the same on Emery. This is frustrating. I may have to start from scratch with a new font.

[rough token]

Chalk is... another beast entirely. One day I hope to add it to Muninn, but not for now.

[slate mason]

If you eliminate what's not absolutely necessary, and favor icons over text where applicable, I think you'll have less difficulty supporting Chalk.

[rough token]

Indeed! I suspect I'll do what I've done way in the past, which is to use distinct windows for chalk unless it's just a page of text or a menu, in which case let those components do their thing

[sleek jay]

I strongly disagree on AWAKE/ASLEEP. A picture of a raven does not effectively communicate the fact that the app is recording data.
I also don't believe there's a good way to pictorally distinguish "days left" from "days elapsed" or "hours left".

I think a much better solution is to also have all the information available on the phone

[fervent jungle]

It could also be put on a number of info pages to click through

(In addition to the summary page)

I like the current design..

But my eyesight is still 20/20

I also think this is not an app that has to work in stressful conditions..

It's a battery statistics thing...that is non-crucial, time-insensitive data

[rough token]

I have to go home now but will have a go at things this evening. I'd rather iterate to improve than redesign drastically. Appreciate all the chat! 🙂

[rough token]

Maybe eventually more detailed info on the phone settings page. For now a glance at the watchapp is the core value.

[sleek jay]

FWIW, mine is -6 (idk what it is in imperial units). On Flint I can use the app just fine without glasses or backlight. On Diorite I need either glasses or backlight to read the small text

Unrelated, I'm getting a lot of "Timer does not exist" errors from Muninn

[rough token]

That's something to do with the last blink of the bird's eye (I think). You can ignore it

[drifting terrace]

I wish chalk was a bit less annoying to develop for, if it wasn't bobby would be on it such a long time ago

[hollow nacelle]

I added to a wscript I have logic that pulls in a totally different .c file based on the platform so you don’t have to muddy any logic. Depending how different you want it to be. Then you don’t have to do inline checks to route between special screens.
I’m unsure if it’s smart enough to not include the original file if the platform-specific one is used, but I do imagine it must be otherwise there’d be a conflict between the two files

[rough token]

Sounds smart!

[slate mason]

My suggestion is to start with this.

The border between the top section and the lower sections can be a thermometer that graphically displays the amount of battery remaining. It would allow for more granular changes in battery life to display than the small, upright battery icon. It replaces the thick, pretty boarder that didn't provide information. On monochrome screens, it would be a dithered pattern. You'd have to be careful to keep the text percentage clearly readable with the dithered background. On color screens, the background can change colors to indicate overall battery remaining. Green for plenty of charge. Yellow/Orange for getting low. Red for less than a day's charge remaining.

The "Days left" icon and number can be combined into a calendar graphic showing the days remaining.

The "Est. % / day" section could be replaced by a calendar icon that shows a page turning to the next day along with the down arrow and percentage inside.

It's not obvious the bird represents the awake state. A pair of icons for awake vs asleep are needed. Perhaps icons for open vs closed eyes.

If icons can be used for "Awaiting x estimate" and "Passively monitoring", that would complete it.

This arrangement would easily fit neatly in the Chalk screen without having to special case for it.

Indicators for pressing the buttons still remains. Such indicators would have to account for left-handed (upside down) watch display.

[magic berry]

hmm... calendar with a number on it does not read to me as "this many days remaining," it reads as "it is the 10th of the month"

[slate mason]

Fair enough. The idea is to graphically illustrate in a simple form.

Another thing to consider is, the fewer words, the easier it is to translate to another language.

[slate mason]

Perhaps putting a right arrow to the right of the "10" in the calendar, like this would work?: 10 ->

10➡️

[verbal jacinth]

eh i dont really like this tbh

[rough token]

That's very detailed! I will take it all on board and continue to work on some iterative improvements, but don't expect anything quite so radical overnight.

I'll think more about icons but they are hard to find for such specialized cases. And I think translations may be quite a ways off for the moment 😅 I'll have some proper dev time this weekend.

If we go too hard in the iconography direction we'll struggle to fill the space and end up looking a little hieroglyphic

[verbal jacinth]

yeah

a UI that is purely icons is a lot less readable and a lot uglier

[grim tree]

I understand that the small text size is an issue, but I find the current UI very clear

The problem with using icons to represent things is that very few icons are truly universally understood. Obviously, text isn't universally understood either because not everyone will speak the same language, but at least you can look up the translation of text rather than trying to figure out "what does calendar down arrow 8% mean"

I also think there's an important balance to be struck between style and functionality - I think the graphical style of the app is unique and interesting, and it would honestly be a little disappointing if it were all stripped out in favour of a purely utilitarian layout

[rough token]

As I say, iterative improvements. I appreciate the feedback

[slate mason]

There would, and should, be information in the phone app with a diagram of the UI, and below having explanations of each part of the UI. Such information could also be in a Help page of the UI.

As for the down arrow in the "%" icon, that's all I could muster on short order. A down trending zigzag, like what is currently used, would be better.

[verbal jacinth]

heres the thing, the UI rn is self-explanatory

it doesnt need a help page

a dumbed down icon-only UI would just be worse

itd look worse and be less intuitively readable

[rough token]

I appreciate both perspectives - here's my proposal: when I have created the paging text component, the first launch message can be both more readable, and explain the app's concepts or iconography as required. From there, the user will be better equipped and it can be a self-contained introduction.

I will be sleeping before long, but in the meantime I've pushed some changes to GitHub that begin to include more responsive layouts and better text readability. More changes to look forward to! I even made my first call to the ContentSize API 🙂

[rough token]

Slow going, but having some good success on scaling fonts and layouts. This custom menu component uses the same size text for title and subtitle if the system text size setting is larger than 'medium' (the default)

[rough token]

Getting lucky with ScrollLayer too, which I previously had a too-small brain for apparently.

[magic berry]

oooohh

[rough token]

The only window left to work on is the main one, which is a lot more complex... I'll maybe tackle that tomorrow

[sleek jay]

how does it look on emery?

[hollow nacelle]

That scroll view header looks so cool!

[magic berry]

pretty good

[sleek jay]

the pixel density is higher on emery, right?

so all the fonts are physically smaller?

-# 1551% per day!?

[magic berry]

yes! best practice, IMO, is to bump up your font sizes by one step to compensate. you can see this happening in places like the launcher or notifications

[rough token]

That main window is the last one I've yet to improve - it will get better!

Also what's the data on that really high rate?

I also need to do something smart with icons...

[magic berry]

combination of water damage to the battery, and just plain early software, haha

[verbal jacinth]

pro tip: electronics dont tend to like water /silly,lh

[rough token]

Hmm, some not-very-6h-interval looking times there. I've seen a bit of the same. I wonder what's up.

[hollow nacelle]

As a counter. I’m getting some very 6 hour intervals on mine

0>6>12>18>0 like clockwork for me. Is it based on the wake-up API missing exact timing and your watches just have more things asking for wakeup? (Left field guess. Not well versed in Wakeup)

[sleek jay]

i wonder what happened yesterday between 18:00 and 18:42

[rough token]

Not sure. Only a little worried...

[rough token]

Wakeup reserves 30s before and after a requested wakeup time for that app. So it gets the whole minute. But that should be the limit...

[rough token]

Did you toggle 'awake/asleep'?

[sleek jay]

ohhhh

yes

i read totoro's comment about AWAKE and ASLEEP being redundant and i wanted to check it for myself

that explains it

[rough token]

So about that - I had logic which was 'if you toggle to AWAKE - note that time and battery level against the next wakeup' but that could be 1 minute and if it drops in that time, super high daily estimate

So I changed it to 'if > 3/4 of 6 hours left if you toggle to AWAKE - note and save', which may be still in the last release. But odd timings can occur and if you're expecting to still wait a day or two for readings doesn't add much value

So in the latest Git version, it's removed, toggling that doesn't record anything, and it just waits for wakeups on schedule.

Speaking of, I'm using struct tm and mktime to convert more accurate times in case as we saw above sometimes a few minutes before a full interval gets scheduled and extremely small intervals result. Maybe it'll be better, I'll test myself before I release again.

[rough token]

Update: After many hours wrangling, Muninn has had all windows scaled, which helped drive the design of my scaling library. Fonts are more aligned, and the images have been enlarged on Emery too. I want to track down this weird wakeup-five-mins-early on my PT2 I've been seeing before I make a release though.

[magic berry]

can you speak on how the font scaling library works?

[rough token]

Like this, but be warned it's not super sophisticated
https://github.com/C-D-Lewis/pebble-dev/tree/master/libraries/pebble-scalable#fonts

There is scope for custom sizes based on screen size but the issue is they have to be declared with the size in package.json 🙁

[hollow nacelle]

Hey that’s sort of what I ended up doing too. But yours is a library I can use as a black box instead and pretend it’s magic 😈

[rough token]

This re-work helped prove it out. It doesn't support Chalk (for the time being) because Chalk layouts are very likely to be very different to rect ones. Once I'm completely done for now I'll make a Project here and a forum thread.

[rough token]

"If woken up a few minutes early for some reason despite the promised wakeup time, sleep again until that time again" logic seems to help 🤷‍♂️

I submitted a bug report for it

[slate mason]

On legacy watches, I get "No Change" for alternating intervals, and intervals are no more granular than 10%. Is this due to the OS, or can intervals be made more granular, such as on the Pebble 2 Duo (Flint)?

Another issue: On Aplite, only 3 intervals are stored in the Data Log. I've had logging on for several days now.

[verbal sparrow]

Feature request - how long did the battery actually last, vs what was predicted: I find myself questioning the prediction, as I don't know whether the prediction turned out to be correct for previous charges

[slate mason]

The battery isn't dead yet.

On the legacy watches (Aplite, Basalt), the predictions haven't made much sense. I figured I'd give each at least a few days to collect enough data points to have a minumum of statistical significance.

[rough token]

Thanks! Overlapping intervals will be fixed in the next release - I didn't note a change if there wasn't any, but that resulted in multiple entries altough the end result was correct.

It's 10% on all platforms except the newest ones. The Emery emulator is from 2016 so still reports 10%. Expect less accurate predictions I think.

The short log... No idea. It should push small structs along an array of 8 length. Check it's actually waking up every 6 hours? The 'vibrate on sample' option will help you try and check that, but obviously I don't expect you to be up at 6AM unless you have to!

[rough token]

This is tricky... What is the logic if a full charge is done, then drained to say 40%, then charged to 65, then drained to 25, then charged to 80, etc. without going all the way to full on every charge instance?

Combined with the fact the prediction evolves constantly, not just made when discharging starts.

[verbal sparrow]

Yep, understood.

maybe a chart of actual battery level over time (like battery+ does) with a 2nd y-axis showing prediction days over time. So 2 lines, which should move together (ish)

[rough token]

That's an interesting idea. I'm wary of copying Battery+ too much, it still fills a niche.

I'd also need to store a lot more log entries.

[tiny yacht]

Would be cool if it notifies if the battery suddenly started draining way more (or way less) than usual. It could help detect if for example the new watchface you're using is consuming too much battery.

[rough token]

That's a good thought! It could show a window that didn't auto-dismiss in such a case when a sample was taken 👍

[sleek jay]

So you are loading all the fonts, even tho you could tell at compile-time which ones you actually need?

[rough token]

Yes - the app loads the fonts it thinks it needs, and the library is in charge of serving them up based on the size category the dev defines.

If a font is loaded but never used, the dev should not load it.

[sleek jay]

so you do it like this?

#ifndef PBL_PLATFORM_EMERY
s_gothic_14 = fonts_get_system_font(FONT_KEY_GOTHIC_14);
#endif
s_gothic_18 = fonts_get_system_font(FONT_KEY_GOTHIC_18);
s_gothic_24 = fonts_get_system_font(FONT_KEY_GOTHIC_24);
#ifdef PBL_PLATFORM_EMERY
s_gothic_28 = fonts_get_system_font(FONT_KEY_GOTHIC_28);
#endif
typedef enum {
  MFS_Small = 0,
  MFS_Medium,
  MFS_Large
} MyFontSizes;
scalable_set_fonts(MFS_Small, &s_gothic_14, &s_gothic_18);
scalable_set_fonts(MFS_Medium, &s_gothic_18, &s_gothic_24);
scalable_set_fonts(MFS_Large, &s_gothic_24, &s_gothic_28);

and without your library you'd do this:

#ifndef PBL_PLATFORM_EMERY
s_gothic_small = fonts_get_system_font(FONT_KEY_GOTHIC_14);
s_gothic_medium = fonts_get_system_font(FONT_KEY_GOTHIC_18);
s_gothic_large = fonts_get_system_font(FONT_KEY_GOTHIC_24);
#else
s_gothic_small = fonts_get_system_font(FONT_KEY_GOTHIC_18);
s_gothic_medium = fonts_get_system_font(FONT_KEY_GOTHIC_24);
s_gothic_large = fonts_get_system_font(FONT_KEY_GOTHIC_28);
#endif

[rough token]

Something like that. The main purpose is to abstract font IDs into generic sizes and providing font sizes appropriate to those sizes on each distinct screen size. You could do the latter if you had some way to make them global and refer to them in size-specific ways yourself.

I did develop it in a fluid way as I worked on Muninn's scaling, it's unlikely to be the most optimal approach 🙂

Hopefully now I can quickly apply it to News Headlines, Tube Status, and eventually the new Dashboard.

[rough token]

The new logic for scheduling is looking solid, we should have a shiny new release tomorrow evening 👍

[slate mason]

I have three Pebble watches, and rotate between them for wearing. Also, I never sleep with a watch on. It would annoy me.

[rough token]

Ah, no worries there, then.

[hollow nacelle]

Just a +1 on this idea because with many battery monitoring apps I struggle with “what do I do with this information?”. If this was instead more actively telling me something is changed compared to a baseline I think that’d be much more actionable.

(Probably more difficult for you to do, but I got excited when I read what Rizz said)

[rough token]

It's on the list 🙂

In other news, more scaling fun!

[hollow nacelle]

I’ve never seen Tube Status until right now because I never had a need to and I’m marveling over how nice it looks

[rough token]

New version is out!

[rough token]

What would we consider alertable? x2 increase? 1.5x? Thinking 10-20% on old watches and 4-8 on new ones...

For example, my P2D would be estimating 4% if I don't use it much, but 7% or 12% if I've lost some percent doing dev or testing.

[hollow nacelle]

I think something major because you won’t be getting good baselines especially now. People are fiddling with new watches so much that “normal” usage is installing and uninstalling faces and apps a lot

You could make it configurable if you wanted to be crazy. But I think if you see a 2x increase in drain you can consider that alertable

[rough token]

Yeah, if it's configurable the user can manage their own expectations

[hollow nacelle]

Ex. My usual was 7-8% a day. Then I hit 15-20 the next few days

[rough token]

I had half a thought to try and do something with 'actual percentage dropped today' but it could be interrupted by charging.

[hollow nacelle]

“Your battery drain is 5% higher than the previous 5 day average”?

It can be a non intrusive one time alert and then the higher drain starts to influence the new average

[magic berry]

my 2c: i don't want to think about all that! 😆 i would like the watch to figure out on its own what the baseline is and i would like some sensible default for when it starts alerting me

[hollow nacelle]

Until the average drain is higher than 10%?

[magic berry]

it could even be in terms of, like, "you'll have to charge a day early" instead of "drained x% faster than typical". make it actionable for me!

[hollow nacelle]

Yeah I agree I think the configuration would be odd. I think a P2D draining more than 10%/day is excessive drain. But being able to set a higher threshold could be useful for people doing development in ways that will hammer it higher than the 10%

I hope I’m also representing what Lavender is saying too

What if you set a default, not based on a baseline from the app data, based on the device and the general expectations of batteries at this point.

Then an action on alerting could just be to say that actually it’s expected like “this is fine” and it automatically bumps the threshold by X percent

Then I don’t have to configure a percentage. I can just say “no I’m happy with 10% a day” and internally you change mine to like 11 or 12

[magic berry]

"your battery drained by x% more than usual today!" [that's weird] [yeah I know I was hammering the Bluetooth installer] /joke

[hollow nacelle]

“This is normal”
“This is not normal”
“Ignore this for a week”

You could just base percentages off a little higher than the specs of the device
If the P2D is spec’d to last 14 days then say the average daily drain rate for a week should be 7-10%

[rough token]

Sounds... complicated, and some have replaced batteries, and some don't.

Being able to track drain for a whole day would greatly aid showing a prediction or power insights, but it could get interrupted by charging. Muninn just notices if the charge increased, but it's can't get direct battery service notifications.

[hollow nacelle]

Yeah that’s where someone would have to say “this is normal”

[hollow nacelle]

Oh I see. So if someone charges their battery but by the time Muninn checks it’s still lower than the previous scan, it’d be confused?

It’d look like you lose 1% for example but you actually just charged between scans?

[rough token]

Yeah... so like 50% at 12:00, then charged to 66, then drains to 45% at 18:00, it's technically a 5% drain, which would be x4 to 20% per day as a rate.

If a charge is a decent or full one it'll work best.

[hollow nacelle]

These things charge fast and drain slow. Do you think that’d really happening enough for most users?

Even in that example that means they drain 21% in 6 hours. If that is happening I’d imagine it’d cause the opposite sort of alert
“Hey your average drain is 20% in 6 hours and you just did 5%”

It feels like it’d be such an anomaly it’d be worth throwing away that data if the +/- delta is outside such a range unless it was reproduced more than once

[rough token]

Not really, charging should typically be for a decent amount of time

I thought about increasing the wakeup interval or making it configurable to increase resolution, but a) for a P2D it might not change for a few intervals and b) moves further away from the 'extremely low impact' goal.

[sleek jay]

it could be nice if it showed the expected date when i'll need to charge it

in addition to number of days

[rough token]

I'll see if I can fit something like that in where it makes sense.

[sleek jay]

oh, also since the down button is not used for anything, can we use it to open data log?

or maybe just move it to the top of the menu

i look at data log much more frequently than i change the settings

[rough token]

Good idea! The menu ordering hasn't been revised at all yet.

[verbal sparrow]

Should app glances be available on Flint or Emery, via the new Core mobile app? Can’t see the latest estimate in the menu on either my Duo or the alpha PT2.

(And yes I’m running two phones - old app and new app- and have a watch on each wrist).

[rough token]

Afaik it's not supported in coreapp yet

But I wish it was!

I've made a bug report in case

[late tangle]

Error that might related to Muninn but also maybe not?:

As far as I can tell, Muninn takes one of its samples at 00:00. Last night at that time, I got a vibration and a full screen message with "Not connected" (it seemed like an OS message, but I don't recall the circumstances when it appears. Definitely not for a simple BT disconnect or being out of range.) My watchface also switched to showing no connection to the phone. I checked Muninn and it had, in fact, missed that sample. I then checked the Core app and the watch wasn't reported as disconnected, so I had to tap on the "Disconnect" button to turn it into a "Connect" button. That was the end of the issue.

[rough token]

Weird! Sounds like something out of my control. If a wakeup doesn't happen the app can't know until it's launched again, at which point it'll notice and reschedule the next.

Keep an eye on it and learn more about the circumstances if you can please

[sleek jay]

we did a factory reset, paired it to a new phone, and reinstalled muninn, and now it says -1 days remaining and 0 samples

diorite

[rough token]

Try "reset all data" in the menu?

I mean -1 means no data for those slots, maybe the logic is broken somewhere... 😞

[sleek jay]

no, still -1

i think it might also do that on a fresh install

[grim tree]

I saw it working once!

It seems to work about as well as it did on the old app, which is to say barely

[rough token]

Worrying...

I just uninstalled and reinstalled and upon waking Muninn I see the same. A bug to fix!

And the best kind - reproducible

[rough token]

Ohh I think it's the animation - animated from 0 to the current value. It should not do that if the data is empty 🤦‍♂️

[sleek jay]

the animation is really cute btw

[rough token]

But at a cost apparently! 😅

[late tangle]

"If you go back to the past 1 day you'll have battery remaining"

[rough token]

We've all been there! 🤣

Once I get home from this after-work party I'll try and make a quick fix

[rough token]

Fix has been published, apologies

[tiny yacht]

can confirm it fixed it!

On another point, I switched to a PT for a few days, and today I came back to my 2D and suddenly has no data? Shouldn't it retain the estimation it had when I last used it?

[rough token]

The only thing that calls persist_delete is 'Clear all data' in the Muninn app menu.

So any other case must be something system related.

[sleek jay]

hmm, i think i had a similar issue with @mossy depot's diorite

I connected it to my phone to make sure it works, set up muninn on it, and switched back to my flint. After a few days of getting measurements, i left it on my desk. When i came back to it a few days later, muninn wasn't running and the log was empty

[rough token]

I wonder if there's some undocumented case where wakeups fail

And by 'wonder' I mean 'reeeaaallly hope not'

[sleek jay]

i wonder if it's something diorite-specific

[rough token]

Maybe. It might be hard to nail down but any evidence you can provide may help if there's a workaround from an app developer perspective. It might also be worth submitting a bug as the docs don't mention that simply not using a watch will interfere with scheduled wakeups.

[sleek jay]

it didn't just lose scheduled wakeups, it lost all data

[tiny yacht]

I left mine on and charging, it looks like it kept waking up on schedule. However, the estimate is blank

[sleek jay]

what about the data log?

is it blank as well?

[tiny yacht]

it does have data, from when it was charging

[sleek jay]

ah, i see

so it is different from what i had

[rough token]

Hmm. But if kept on wrist it's okay?

[tiny yacht]

I believe so. It was working fine before I switched watches

will report back once it wakes up again

[rough token]

Uh it looks like it's reporting charging up for very small decreases? I'm quite confused

[tiny yacht]

I mean, that whole time was charging. Unsure why the decreases happened.

Might have been it got randomly moved and disconnected from the charger, or my computer shut off or something (was connected to my PC's USB port)

[late tangle]

The app reports 0 days left after charging to 100%

Also the estimate suddenly jumped from 17% to 27% in some hours

It's on 1.8.0

[rough token]

Have a look at the data log - the estimated rate is an average of recorded values and evolves over time. It's possible a very recent value was a lot higher than the average.

If you can provide screenshots of the log it may help me make more useful responses

[rough token]

Hmm, maybe it should not record estimates if the battery is full and it's on charge...

[rough token]

Oh I think I know what this is - the value at the bottom is the live watch battery level, but the calculation uses the battery level at the time of the last wakeup. For now it should update to be better but I'll see what a fix looks like.

[rough token]

Made a fix for the days remaining calculation bug during my lunch break 🙌

[rough token]

I have a theory - the logic uses the 'pugged in or charge increased' condition to show "charged up", which is leading to confusing messaging... I'll clarify it

And if the charge controller allows small drops while on charge and full, this tracks

[magic berry]

off topic but that is a pretty watch

[late tangle]

Thanks!

[slate mason]

I'm doing the following experiment. I charged all three watches at the same time. I unplugged them at the same time when they were all fully charged. Then, I shot a photo of them during the same minute they were unplugged. Now, I'll see how accurate the Muninn predictions are for all three. I'll post results here as each watch runs out of battery charge.

I'll check the predictions at 24 hours after fully charged to give the software sufficient data points.

The watchface I'm using refreshes the screen every second. I'll update the software to refresh the screen once per minute; on the minute; once the experiment is complete.

[rough token]

Good luck! It might behave funny if it's off wrist for a long time but we'll see!

[slate mason]

What does wearing it change?

[tiny yacht]

I think Pebbles have a hard time keeping accurate time when they're not connected to a phone, so accuracy of Muninn might be bad because of that

[slate mason]

Mine don't even get a minute off when not connected for several days.

I also generally have some reason or another to connect each to the phone everyday.

Another thing. Just because I'm wearing one of my Pebbles doesn't necessarily mean I've reconnnected it to the phone.

[grim tree]

p2d is probably worse seeing as it has no RTC

[rough token]

I've heard that when being not on wrist or disconnected for a long time weird things happen, things which are probably out of the app developer's control

👻 !

But any extra evidence or experiences in this sort of use case may present some clues to something I might be able to do about it. Who knows!

[slate mason]

I just set mine to left-handed too. Perhaps eliminate the side bar in the UI to make it the same for both wrists.

[slate mason]

Here are the predictions after a day.

What I find interesting is that Aplite and Basalt both show 80% battery charge, but 2 and 11 days charge remaining, respectively.

What is distressing is that I just replaced the battery in the Aplite (Pebble Steel), and the Basalt, with color screen (Pebble Time), has the original battery.

[rough token]

Interesting to see, thank you! Let's see what the next few days will bring - any existing log data will continue to influence the predictions until newer entries course-correct, if the usage pattern changes.

Currently the most recent 4 log entries' estimates have a 2x weight on the overall estimation on the main page, which feels like a decent start. Maybe the most recent two should have more weight...

Perhaps the algo is too slow to change, but I'm also cautious of it varying wildly day to day. I'd incorporate real hours/days depletion, but it can get interrupted at any time with a period of charging of any amount...

[rough token]

Released a fix for this

[slate mason]

Should I start the test from scratch with the new release?

[slate mason]

Since there is a new version, and I wanted to release the new version of my watchface, I deleted all the data, installed the new version of "Dual Time Zone", updated to the 1.10 version of Muninn, and restarted the app. I'm charging all three watches back up to full to give Muninn a clean slate.

Observations:

1. Muninn's visible screen shows that it needs to take a couple of samples before showing estimates. Makes sense.
2. I tried pressing the center button to access the menu. This didn't work.
3. I tried pressing the back button. Then, the menu appeared. This wasn't obvious.

[rough token]

2 feels like a firmware issue. The app code is very simple - register button handler, push window. I'd submit a bug report to Core

[rough token]

The algo didn't change unless the release notes said it did, you're probably fine

[slate mason]

Starting afresh, here is Muninn showing 100% battery for each and Dual Time Zone showing the start time.

[languid merlin]

Im using 17% a day, how are you only using 3?!?

[grim tree]

If you're using that much battery, it's almost certainly down to your watch face - watchfaces that update every second and play lots of animations will consume more power than faces that do a simple update every minute

[languid merlin]

Ill swap out to a different face and if that imroves it, I also get a ton of notifications on my watch. Thanks

[grim tree]

notifications absolutely have an impact, but it shouldn't be that big

[languid merlin]

I usually use Simply Digital 3, one of the basic watch faces...

but Ill try another and see if it helps

[grim tree]

strange

I guess I should confirm - you're talking about a p2d right?

[languid merlin]

yup

[slate mason]

I updated the Dual Time Zone watchface in the photos above today to only update the screen once per minute or when settings are changed.

Before updating the code, I still got the advertised expected battery life from each watch.

It runs on all Pebble watches.

[sleek jay]

I don't like how the log now only shows 1 date per time inverval

My log looks like this:

• Dec 16, 6-12
• Dec 17 12-0
• Dec 17, 0-6
• Dec 17, 6-12
• Dec 17 12-18
• Dec 18, 18-0

I understand now that it shows the date of the latter sample, but it feels quite unintuitive that 12-0 counts towards the next day

One easy fix would be to write intervals as 12:00-17:59

Also my watched stopped taking samples yesterday for some reason, the last sample is from 18 Dec, 12:00. The next interval will be longer than a day, so it would be confusing if you just show the start date or just the end date

[grim tree]

the current version shows the days and percent per day counters with a leading 0 which i think looks really ugly

it also feels unintentional?

[rough token]

I thought a leading zero was better - like a gauge, which fits with the counting up animation, and also is a consistent width - otherwise with single digit value it feels like the icon and text is too far left and I thought people might not like that.

[rough token]

Seems weird. Did you take it off?

[rough token]

Hmm. Technically at 00:00 when the sample is taken it is the start of the day it shows? I'll try the :59 thing and see how easy it is

(dev time is limited these next few days, please bear with me!)

[sleek jay]

I don't remember 🙁

[sleek jay]

Yes, the sample is at the start of the day. But the list items are intervals, not samples. And the sample is entirely within the previous day

[rough token]

That wording managed to get through my brain faster than my coffee has so far, thanks 😅

[rough token]

I've seen spurious cases where a watch that wasn't always worn misbehaved with regards to this app but no single documented proof, but I'm forming a picture.

[sleek jay]

actually maybe it was the thing where os crashes and shows the qr code?

[rough token]

Yes, you'd need to open the app again to restart the wakup scheduling, sadly out of my control.

Is that PRF or just when there's no devices paired yet? I'm not sure.

[sleek jay]

can you schedule more than one wakeup?

so even if the watch is off during the first one, the second one will still run

[rough token]

That's a very interesting idea! Won't cover resets into PRF as all data is wiped during an intial firmware upgrade. I'll add it to the list. Appreciate it!

Someone on GitHub opened an Issue correctly pointing out that when the log is mostly full of 'no change' events (say, a healthy battery in a Pebble Time or OG), the estimate gets out of whack because it only counts periods of discharge - if you tick down a couple consistently with a P2D or PT2 the issue is hidden. I'll fix that soon too hopefully.

[grim tree]

I see - imo if you want it to look like a gauge, it needs to be a funkier font

Because right now it looks like generic text and doesn't pull off "gauge" to me

If you can get like, a 7 segment emulation font or something else wonky like that maybe (although it wouldn't fit with the aesthetic of the rest of the app)

(then again, the idea of a gauge doesn't really fit with the rest of the app anyway)

[rough token]

Maybe it could be configurable

Given I keep saying 'being charged at any time is hard' so much, how does this idea sound: If a sample shows the watch was charged, clear the log except that entry, and then go into the 'waiting for two meaningful samples' to start a-fresh?

The drawback is that old log data couldn't be used to immediately give estimates when taken off charge.

[grim tree]

2 samples takes a lot of time, I don't really love that idea

what's the issue with charging?

[rough token]

Min. 2 is so averaging is meaningful, but if you install and then forget for half a day you don't notice so much.

It keeps coming up. Mainly for new ideas like using actual real drop throughout the day and being being partially charged entirely between two samples.

I could increase from 6 hours to 3 but it would have a (marginal) higher impact, which I want to minimise. But we're thinking of user experience too (and rightly so)

[grim tree]

I feel like the edge case where you charge so little that it's still detected as a drop by the next sample is really rare

or am I not understanding?

[rough token]

I think you're absolutely right

And only over one interval so not a large potential impact even if it does happen

Given a 10% drop in six hours and then perhaps no 10% changes in a basalt for the rest of the day shows an instantaneous rate in the data log for that entry of 40%, perhaps it's not very valuable to show those intermediate rates there...

[late tangle]

I definitely feel the numbers are increasingly losing their meaning, maybe I'll dump them here and do a reset of the log

[rough token]

Your case - many entries with 'no change' or 'charged up' will get much more accurate when I publish the next version. It wasn't including those entrys' time periods in the overall calculations, but someone has helpfully pointed out to me that they should...
https://github.com/C-D-Lewis/pebble-dev/issues/3#issuecomment-3671297505

I would be very interest to know how it differs (hopefully improves!) once I'm able to do that tonight.

[slate mason]

My vote is for leading zeros.

It has been less than a day, but here is what I currently see:

• Only one of the three watches got enough samples to make a prediction, even though they all started simultaneously.

[rough token]

The app requires at least two discharging intervals - if the older watches that only report 10% changes didn't lose more than 10% then they'll be waiting longer for those
https://github.com/C-D-Lewis/pebble-dev/blob/master/watchapps/muninn/src/c/modules/util.c#L91

[slate mason]

Is it possible to update the firmware for the legacy watches to report smaller changes?

[grim tree]

It wouldn't be impossible once the open source firmware is built, but it might not be the best idea because the old watches don't have a battery gauge

So the percentage is likely to be a lot less reliable than on the new ones

(although those aren't 100% reliable either)

[slate mason]

Updating the old firmware would certainly improve how the Muninn icon appears in the menu. That itself isn't so important. I'd love to see the firmware for legacy watches to keep up as much as practical with the new firmware.

[slate mason]

So, the legacy watches need to drop down at least to 80% before making a prediction. This will likely take a couple of days altogether.

[rough token]

It would be great to get that update but it's a tricky business updating the old ones. FW 3 has mere bytes to spare, I remember.

[rough token]

Indeed, but you will get it, and it'll endure as long as you don't wipe the log and charge as normal

[magic berry]

yeah the legacy watches provide 10% increments because they are not necessarily precise about estimating their own charge level, AIUI

[slate mason]

I presume the OS estimates charge level by battery voltage. This is common, but not necessarily accurate.

[rough token]

(I snuck away from family but am sneaking back to them now!)

[hollow nacelle]

This doesn’t revoke timeline pins, am I correct? Say it puts “time to charge!” on my timeline, it won’t ever remove that even if I charged
(It didn’t, that’s why I’m asking to clarify if it’s right)

[rough token]

No, so far it just places one and moves it based on the most recent estimate when the app opens

If you open the app after charging and one sample then it'll be moved out appropriately

[hollow nacelle]

It won’t do that during wake up then, which makes sense because you want it to be very light

[rough token]

Not currently, no

It can actually complete the sample quick enough to not push any window and not get killed by the system but a quick 3s notice with optional vibration lets you know it's working

[hollow nacelle]

Yeah that’s cool! I think I’ve only ever seen if I’m using the watch in an app currently and it triggers. But seeing that timeline pin is huge and my first thought was that the “time to charge” pin alert felt like something native
It’s really really well done as a background monitoring app

[rough token]

If your phone isn't connected when you open the watchapp it'll not get updated but hopefully it'll be the case at least once before the estimated date arrives

[slate mason]

The iOS app doesn't automagically update to the latest version of Muninn (1.11) or my watchface (2.11).

[rough token]

If it's anything like the Android coreapp, pulling down to refresh the Apps page and then re-launching the watchapp should get the new version. But if not, I have no advice.

[slate mason]

I submitted a bug report on it yesterday. Shortly after, the watchface and app automagically updated. Who knows...

Here is today's data. Yesterday afternoon/evening, I updated the watchface and Muninn, but did not charge any of the batteries. So, Muninn 1.11 is working with several days of 1.10 data. I otherwise keep all three watches diconnected from the phone app to limit variables.

[grim tree]

lol the p2d's battery gauge is such a mess, I did a partial charge to like 60% and it's been steady climbing since

(this isn't criticism of muninn, just of the watch itself)

[grim tree]

that being said, feature request - the ability to pause muninn for a specific time, such as pausing it for a day etc.

this is entirely because muninn's samples will abort apps running on the watch, so I might want to disable it sometimes. but I worry that if I outright disable it, I'll probably forget to re-enable it until who knows when

that's, of course, if it's reasonably possible - idk if there's a limit on how far in the future you can schedule a wakeup

[hollow nacelle]

It’d be nice if the Wakeup API wouldn’t interrupt during user interaction. Like X seconds since the last button press

[grim tree]

It would also be nice if the wakeup API could relaunch the previously running app after it's done

that would make it not an issue for me

[slate mason]

My P2D got a doubling of days remaining at the same reported state of charge after 4 hours. Here are my results.

[rough token]

Looks like you're on to a winner with those numbers!

[rough token]

Sounds reasonable. I'll add it to my growing list!

[rough token]

There was a suggestion to schedule a few wakeups into the future to help if the watch happens to be off overnight or something like that but the logic involved with managing a queue of them scares me a little... Time for an abstraction!

[grim tree]

My idea is more so "when you pause for a day, remove all existing wakeups and schedule a new wakeup in a day"

but it also makes sense for there to be, like, a week pause, and can you even set a wakeup a week in advance?

[rough token]

Yes, they are two separate suggestions, one for durability of the schedule and another to avoid interruptions.

As far as I can tell there's no limit into the future although I've only tested hours ahead as that's all I've needed so far

[grim tree]

ah, okay

[slate mason]

My watches have been going for 4 days now. According to Muninn:

1. My Pebble Time (Basalt) is on track to last a week, even though the original battery in it is about 10 years old.
2. My Pebble Steel (Aplite), with new battery, is on track to go about 2 weeks on a charge. Although the replacement battery specs suggest this, I'm very skeptical of what AliExpress sellers claim.
3. My Pebble 2 Duo (Flint) won't need to be regarged again untill spring.

These numbers seem a bit optimistic. This ongoing test will see how accurate it really is.

[rough token]

Thanks for the update! Once the batteries are flat we'll know the full story.

As for the P2D... I mean if it's only losing 1% per day then the estimate seems okay. But nobody is expecting that in reality currently! Is it being worn or lying undisturbed on the desk? The latter would use a lot less power

[grim tree]

also probably disconnected from bluetooth

[rough token]

My record on my desk in 2015 was 24 days with a PTS and an extremely minimal setup - BT off, hourly watchface, and a custom firmware that disabled a few event services.

[rough token]

In order to support adding many more fields to each sample, and expand the number of samples beyond 8 in the log, I'll need to make the app wipe it's data for the next update. I tried for a couple of hours to make it work only once with four different structure shapes but I think for the future benefit it'll be worth it.

Would any here be willing to install a PBW to make sure a notification about this is shown?

[slate mason]

I got a very unexpected result on Flint this morning, so am uploading early.

Less than a day to go with 90% charge on Flint.

All three watches are resting on my desk in order to assure the fewest differences between them.

[grim tree]

hi, willing here

[slate mason]

Would the app wipe all the data, or just the oldest datum?

[rough token]

All data - clean slate. But in future this should not be required again

[rough token]

Strange! What's in the data log, please?

[rough token]

With existing app data, this should wipe it, show the 'welcome!' screen, then a notice about the wipe when 'back' is pressed, and only once.

[grim tree]

yup, can confirm

[slate mason]

Here's the Flint data log.

[grim tree]

Only criticism id have is that it wasn't woken up by default and that my settings were wiped too, which wasn't made very clear would happen

but those are both decently minor issues

[rough token]

Yeah, wiping just the log would be a small win

[grim tree]

Maybe change the text to read "data and settings reset"

[rough token]

Oh. Are all but one entry a 'no change'? I guess then Strange Things Involving Zero may be happening

[slate mason]

That's the entire Flint data log, in order.

I'm passing on loading the PBW in order to continue this test.

[rough token]

If that's an affirmative, I think I need to consider a case a watch is so long-lasting that the average of all discharging and no-change events is less than one.

[slate mason]

That's an affirmative.

[rough token]

Thanks! This is a valuable corner case

[slate mason]

I'll be tickled pink if my Flint actually goes for months on a charge, as Muninn appears to indicate.

[rough token]

One of the reasons I have to wipe the log data is adding a few new fields to the Sample struct - two of these are the estimated days remaining and daily rate. With this data and a suitable graphing or table view somewhere it will be possible to see how Muninn is performing in its predictions over time!

[slate mason]

Makes total sense. Do you consider my current data collection to be of less value than a restart?

[rough token]

A continuation after the next update will be valuable. The new logic for rate estimation is 'at least one', which will prevent Zero Based Weirdness, and is 'close enough' to your case, which is the best I've yet seen.

[slate mason]

Your reply is a little ambiguous.

[rough token]

Which part?

[rough token]

Stopping for this evening. New things so far:

• Minimum 1% daily rate
• Show alert if one day is left
• Add daily rate and day remaining to each sample to allow eventual analysis
• Increase log length to 16 (but most recent day carries 2x weight, as before)
• Accept a 'no change' in the first two samples, for a quicker activation on long-living watches

[slate mason]

"A continuation after the next update will be valuable."

So, what would you like me to do?

[rough token]

Keep testing and make sure that weird state when the majority of log entries were 'no change' is fixed

[slate mason]

I'm using Muninn 1.11.

[rough token]

When 1.12 is available, of course

[slate mason]

Here are the current results after 5 full days.

Musings:

1. Flint: 10% drop in 5 days would seem like I'd get around 50 days in total. So, 90 days remaining seems optimistic.
2. Basalt: 40% drop in 5 days would indicate 12.5 days total. So, 6 days remaining seems in line with the amount of battery charge depleted so far.
3. Aplite: 80% drop in 5 days would indicate 6.5 days in total, which is great for a 10 year old battery. So, 1 day remaining seems on target.

Tomorrow or Christmas, I expect to know how long the Basalt battery is lasting in my test bed.

[late tangle]

just when i thought the results were starting to resemble reality lol

but it'll be for the best

[slate mason]

That's similar to what I got on my Pebble Time after 3 days of testing.

[late tangle]

i agree with turning the channel into a flexing-10-year-old-batteries stream

[slate mason]

Well, it's not unusual for batteries that have been used and stored properly over their life to enjoy longer time in use.

[grim tree]

The stored part is such a big part, since Pebbles experience so few cycles

[fervent jungle]

It would be nice to have a setting for the sample interval.

So that folks can adjust the sampling to cover the whole drainage interval of their battery.

Given the limited number of samples

[rough token]

Re: 1 - that's integer math for you. At 1% avg per day 90/1=90 days. If it just ticked up to 2% then 90/2=45. Not sure what can be done right now but it's worthwhile knowing this could happen. I have a test case I can use to find a more intuitive solution.

[rough token]

That's on my list! I think choosing between 3 or 6 hours could be useful for some.

[verbal sparrow]

Weird thing this morning. I can see app glance estimate in the menu, but I’ve lost the app icon.

mmm, in fact I’ve lost all the icons for non system apps, so this isn’t a Muninn problem. I’ll log a bug on the mobile app

[rough token]

I think it had a moment of lucidity yesterday and then that's gone away again for now...

[fervent jungle]

12 and 24 hours also seems interesting to me

[fervent jungle]

I'm regularly loosing them on pts

[rough token]

I wonder how it would affect accuracy

When the next update with samples containing the estimations is done, the app should theoretically be able to rate its own accuracy

[rough token]

Freeing up some screen space for perhaps a charge date estimation row (or something configurable)

[rough token]

"Last charge time ago" and "next charge date" anyone? The former will only show a value if there has been at least one 'charged up' event. It will be remembered even if it falls out the end of the log.

[rough token]

But I think "last charge time ago" needs a more distinct icon. Maybe a plug + calendar.

[void jungle]

is the left plug indicator for how long ago it was charged?

[rough token]

It is, yes.

Well, the last time Muninn noticed the charge had gone up, not down. We can't receive plugged/unplugged events between wakeups

But on a days scale it's okay I think

[grim tree]

I like it!

Needs better icons, yeah

[grim tree]

I don't think you have the pixels for it, but plug and this would work imo

then plug + calender could be next charge

[slate mason]

Icons are tricky. Get them right, and they're intuitive. Get them not so right, and they're head scratchers.

[rough token]

I combined the plug with the 'previous' icon, same Material style as the icon set I've been drawing from. An improvement, at least, I think.

[rough token]

To avoid 'feature creep', I'll stop dev there for a few days to let the new things soak in and see if any issues come up. So far for the next version:

• Allow one 'no change' sample as part of the two initial required samples
• Increase log length to 16
• Show log usage in the log window header
• Show an alert when there is just one day remaining
• Daily rate will always be at least 1 in extreme cases
• Record the rate and days remaining estimations in each sample to allow overall accuracy calculation (future)
• Refine layout of main window to allow two new items: time since last charge observed, and date of next estimated charge.

If anyone wants a PBW early let me know, but be aware it'll wipe the app data this one time (shouldn't need to do it again in future)

[grim tree]

i'm willing to test!

[rough token]

Here you go! After a few days (holiday period!) we can compare notes.

[slate mason]

Here is today's daily dose of data. The Pebble Time has been warning me that it needs to be charged again today.

[rough token]

Thanks. The P2D continues to present the 1%/d problematic case. Though I am sure if it was on-wrist being used for apps and notifications etc. it would not be so low. But good news for Core if someone wants to make a desk clock out of it I suppose!

[slate mason]

Muninn Test Wrap-up So Far

Day 00   100% Est n/a    100% Est n/a    100% Est n/a
Day 01    90% Est n/a     90% Est n/a     96% Est 16d
Day 02    No Data
Day 03    80% Est 26d     60% Est 03d     92% Est 46d
Day 04    70% Est 11d     40% Est 02d     91% Est 91d
Day 05    60% Est 06d     20% Est 01d     90% Est 90d
Day 06    50% Est 05d     00% Est 00d     88% Est 88d```

Note: Basalt has 10 y/o battery. Aplite and Flint have new battery.

Change of measured battery state of charge (SOC) isn't linear over the discharge cycle, as it's measured in voltage most likely. To get a better approximation of days left, you can use a Li-ion battery discharge curve as a guide.

[rough token]

Seems in all three cases it takes a few samples to converge on a rate - this is probably expected and as data persists across charge cycles it'll remain locked in on that.

I only have percentage of battery from the OS, I don't think I can use a voltage curve or anything fancy like that.

@grim tree Seems there's a bug where the 'one day remaining' alert fires if there's insufficient data - this version should fix it.

[slate mason]

Most likely, the OS is getting % from the voltage, and assuming a linear discharge rate. That is, unless it takes this curve into account. Assuming it doesn't, you can use this curve to better predict days remaining. For example, the first day's change in SOC for all three was less than following days, which is consistent with voltage change in the curve.

It would be very useful to know what the OS uses to determine %. That way, you can better determine where on the curve a battery is.

For example 100% = voltage A, 90% = voltage B, etc.

[grim tree]

you can read the source code fwiw

It is voltage based on all pebble tech corp watches but it is adjusted for the discharge curve

[slate mason]

From 80% to 30%, the voltage changes very little. However, knowing how long it took to get from 100% to 80% will give a better idea of how long it will take to get to subsequent percentages.

[grim tree]

but it also assumes the battery is 3.8v so it’ll be wrong on a 3.7v battery

[slate mason]

So, it takes the above curve into account.

[slate mason]

My legacy Pebbles shipped with 3.7V batteries.

[grim tree]

oh, huh

maybe only some pebbles are 3.8v

[grim tree]

installed and running

feel free to ping me whenver you want and tell me what to tell you

[slate mason]

Many replacement batteries from AliExpress claim 3.8V. However, Li-ion batteries are nominally 3.7V.

[grim tree]

lithium ion is a broad term, and there's a lot of slightly different chemistries under it

so you can get lithium ion batteries with nominal voltages as low as 3.6 and as high as 3.85v

[slate mason]

The replacement battery I bought for my Pebble Steel is labeled 3.85V 250mAh. Since it is no larger than the original 3.7V 130 mAh battery, I'm skeptical of the label.

[grim tree]

oh yeah there's no way it's 250 mah

it might be 3.85v but it also might just not be

[slate mason]

I measured it with my multimeter, and it was over 4V. However, that's to be expected for a fully charged or near fully charged 3.7V battery.

[grim tree]

it does look like aplite pebbles did ship with 3.7v batteries while all others shipped with 3.8v batteries

[slate mason]

Ahhhhh.....

My Basalt watch went into needing a charge now mode as we were discussing. So, my final data point for this watch was within an hour of when it ran out of juice.

It's also less than 2 hours more than exactly 6 days from fully charged.

[slate mason]

Today's data. Merry Chris-tmas! 🎄 🎅

[rough token]

That PS really is a champ!

If nobody who has installed the PBW above has had any issues with data being recorded as before, I'll be thinking of making a release tonight so I can move on to some more new features like accuracy calculation and data export

[grim tree]

no issues that i can spot - is there anything in particular you'd like me to check out?

[rough token]

I don't think so!

[slate mason]

Here is the latest and last before upgrading to the new 1.12 build.

Bad News - Bug: After installing on Aplite (Pebble Steel), Muninn won't launch.

1. While connected to Pebble Steel, poke Muninn avatar in the "Apps" page of Pebble app.

2. Poke "Start App" button.

3. Wait for Muninn to load into watch.
   At this point, Muninn appears in watch menu, but hasn't launched.

4. Select Muninn in menu, then press middle/select button on watch.
   At this point, screen briefly goes blank. Then, watch menu reappears.

[rough token]

Hmm, installing the appstore version works for my PT2 and P2D. Have you tried deleting it using the Pebble phone app, and letting it get loaded onto the watch again?

My red Pebble Time (Basalt) upgrades from 1.11 to 1.12 okay too. Does it work for your Flint?

Here are two PBWs that can be switched between - opening 1.11, waking Muninn to set some data, then installing 1.12 should be the same upgrade path as the appstore

Unfrotunately I have to be out quite a bit of today, and rolling back to 1.11 with a 1.13 isn't a clean option is 1.12 data is already partially stored 🙁

Reports from working devices would be just as valuable (from anyone really), as well as SDK logs if possible from a non-working device.

Since checking for a storage key and looping through a range of keys if it exists to delete them is the very first thing the app does, maybe doing too much of that on Aplite is an issue.

These two builds reduce the total keys looped through when wiping to 51 (from 100), and check if a key exists before deleting it - please try them after setting up 1.11 first. I really hope this is the issue...

If it's only on Aplite then I'll rest a little easier, but not much, than if I broke it for everyone apart from me somehow.

[verbal sparrow]

1.12 from the App Store (installed via the old app on iOS) is working on my pebble steel.

(Well it installed fine). I’ll let you know if it captures logs properly

[sleek jay]

I woke up at 0:30 this night, and my watch (flint) was showing the Muninn welcome screen. Muninn was asleep and the log was empty.

No other apps lost their data

[rough token]

Yep, data schema changed one-time for the latest version, expected just this once

Last thing before my family screamed at me to get in the car::

[11:03:13] gbitmap_png.c:107> PNG decoding failed
[11:03:13] gbitmap_png.c:157> Failed to load PNG
[11:03:13] gbitmap_png.c:107> PNG decoding failed
[11:03:13] gbitmap_png.c:157> Failed to load PNG
[11:03:13] main_window.c:590> Heap free 1260

Seems it uses too many images for Aplite now 🙁 Needs a layout re-think.

My apologies go out to all the appstore users I cannot reach to reassure them...

[rough token]

@slate mason Please try this PBW - it runs on the Aplite emulator whereas 1.12 did not.

[rough token]

Tempted to publish it anyway since the emu crash is at least fixed.

[rough token]

Another user has said it fixes the crash, I'm happy with that for now 👍

[slate mason]

I was away from my computer. In order for the 1.15 build to load into my phone app, I had to delete Muninn, then add it back. It then launched in the Pebble Steel (Aplite) as expected.

[rough token]

Huzzah!

[rough token]

Tinkering with the graph concept - still needs a lot of work, but so far:

• Dots - each sample's charge level
• Circles - predicted charge level derived from the previous sample's estimated rate of discharge
• Line - contiguous discharge samples, useful for accuracy calculations
• Crosses - each sample's 'days remaining' value, which varies quite a bit while initial samples are taken, then seems to settle down. Not sure how useful this is
• R - Actual change in charge over the period over the estimated change using all the 'rate' values. Here the battery discharged 4% more than estimated.
• DR - 'Days remaining accuracy' - a made-up statistic comparing the oldest 'days remaining' estimate and the most recent, compared to actual time elapsed. Again, this varies a lot and I'm not sure how useful it is currently.

I'll keep working on it.

[rough token]

Unfortunately on my PT on my desk that is discharging slowly and at 10% increments the current graph logic is a lot less useful...

(the -1d there is 'not enough data', not -1 days underestimation)

[rough token]

It's evolving...

[slate mason]

"Drained 4% vs expected" is ambiguous. 4% more than expected?

[rough token]

Yeah, wording is non-final but I was thinking the same

But to be fair, if the user's habits change it can't be expected to predict that. Something that reflects a deviation from the recent trend would be more appropriate

[magic berry]

if you wanna get turbo nitpicky, s/expected/prediction

(apparently discord actually interprets that as a command if it's the first thing in your message! wow)

[verbal jacinth]

yep!

[rough token]

That's good, thanks

[rough token]

Also looking better on older watches too with those pesky 10% increments... The empty circles could perhaps interpolate between 10% levels but feels more advanced I think.

[void jungle]

just got muninn installed yesterday on my steel.. should I have the raven on the top left? also current status says awaiting discharges but there have been no samples ever taken

i charged it today also, if that helps

[magic berry]

it should take a sample every six hours, and it waits for three samples IIRC before giving an estimate

if it doesn't say "muninn is asleep" then you should be good!

[rough token]

This - initial reading, then at least two so averaging is actually useful. I toyed with allowing just one full sample but it could give a very innaccurate estimate

Sadly I'm up against Aplite (Pebble and Pebble Steel) memory limits so on that platform some of the non-essential images have gone. I'll try to bring the raven back though, if I have some spare memory or time.

(though there's enough memory for the image, PNG compression overhead and memory fragmentation seem to make it quite difficult)

[void jungle]

It's been on my watch over 12 hours but no samples yet

But that makes sense

[rough token]

They should appear soon. Check the data log in the app menu for details when they're available.

[void jungle]

got a few samples now, thanks!

[rough token]

Great! Keep me updated if you see anythign majorly weird and thanks for trying it

[rough token]

Woah, my PT2 battery must have gotten cold in the night and "charged" 2% 😕 so now the 'last charge' stat in Muninn is incorrect...

[verbal jacinth]

oof

[grim tree]

yeaaah, this happens a fair bit

[rough token]

To you personally with Muninn or with these batteries in a wider sense?

It was exceptionally cold last night

[grim tree]

i have experienced a similar thing with muninn many times

the battery gauge on these watches is just

not very good

as i remarked in another channel, if i partially charge my pebble to 55-60%, over the next 12-18hrs the gauge will climb to 75-80%

[rough token]

Ah, that's not good. This is the first time I've seen it at least via Muninn. So, we need a fix. My first thought is that if the rise is less than 10%, we postpone the next sample until the next scheduled time and treat it as a double period. Anything more and the user probably genuinely at least partially charged

[rough token]

Gah, I have a fix but Aplite just fell into the 'not enough memory' category again...

[verbal jacinth]

🔫 fix it /silly

[rough token]

I will try

[verbal jacinth]

the aplite gods appreciate it 🙏 /silly

[rough token]

New version is ready, but I'll wait until tomorow evening before releasing it, no sense rushing it in case I made a mistake somewhere...

Y'all will have to keep having bump batteries until then

[verbal sparrow]

Really liking the graph by the way

[rough token]

Thanks! I only noticed this most recent issue after seeing a small bump in the graph and wondering what the heck it was

[verbal jacinth]

muninn is top 1 most loved now with the new sorting :3c

[drifting terrace]

muninn really is the kind of app that I was hoping would be highlighted with these changes

[verbal jacinth]

true muninn is awesome

[grim tree]

i wonder if there's any way for me to switch to the app store version of muninn without losing all my data

[rough token]

Watch data is removed when you uninstall, which as you know is required to go to the appstore version. I had an experiment and seems localstorage in JS may persist but that feels more like an oversight than a feature 😕

And thanks for the kind words!

[drifting terrace]

that gives me an idea that clay could offer a way to export and import the config data easily for itself

I guess this isn't really that difficult to do with existing clay though

[rough token]

To and from a text file is probably possible yeah, although if I change the sample schema there'll be Difficulties. I feel like installing from PBW to Appstore is a small enough niche case for now, appreciative of the testers' patience of course...

[cloud cave]

I just discovered this app and it looks really great. I like that it is way less resource intensive than Battery+.

@rough token Should the app have an icon on the menu screen? I’m just seeing the generic app icon on my P2D.

[rough token]

Thank you! It should! I think after you launch it the first time it should show up. I'm using a PT2 but I can check my P2D if you think there's something amiss

[cloud cave]

I'm not seeing the app icon, but I'm realising that none of my installed apps have icons right now which seems odd. (The apps that it came with do. It may be that none of these apps have menu icons?) It has also been installed now for several hours and has not taken a sample yet. Is that normal?

i just restarted the Pebble to see if that would fix it, and got a "Muninn missed a sample, but will continue" message when i opened the app. Still no icon on the menu screen.

[magic berry]

muninn takes samples at each of 0:00, 06:00, 12:00, and 18:00

it's normal for it to take about a day before you start to see an estimate

[cloud cave]

I have launched it several times in the since installing it and the icon remains the generic one.

[magic berry]

do you have the native app store enabled in your core app settings?

there's a known bug where appglances are bugged with the web appstore, and app icons are bugged with the native store

[rough token]

Does anyone use the 'current battery' gauge much? It's using a whole image and the value is available in the system/watchfaces anyway. It could say something more useful at the bottom like "Next sample: X hours" or even something new.

[grim tree]

I think it really rounds out the ability of opening Muninn to give you a full example of your battery state

it would feel like an odd omission to me if it wasn't there

[rough token]

Part of me feels the same, yeah, strong argument

You can do the mental maths between that and the rate to rationalize the estimated days

[grim tree]

I wouldn't be opposed to the battery icon itself becoming static or something if that's neccesary to save on storage space, since every other icon is static anyway

[rough token]

The app loads only one anyway, but good idea

On Aplite it's used to save on the 'days remaining' icon too

I have just been reminded there are additional levers to try with image storage in the SDK so I will look at those too

Maybe the bird can come back

[rough token]

Hmm, those options aren't actually making a single byte of difference. Maybe I'm doing something wrong.

[fervent jungle]

I'm not sure I care when in particular samples are taken

[rough token]

New users will want to know when some progress will be made. Aside from that, the first 12-18 hours are still less intuitive than I'd like.

But once you're up to speed, yeah, it's a background detail

[fervent jungle]

I suspect a 'come back tomorrow for a first estimation' message would be more fitting than permanently taking up screen space

[rough token]

Indeed although in fewer words. The first launch message window should have more detail

[verbal jacinth]

i do 🙏

[cloud cave]

@rough token Is there a specific reason why the app takes readings at 00:00, 06:00, 12:00 and 18:00? could it not take the first reading the first time it is installed, at then take the next one 6 hour after that and so on? It was a little unclear when first installing why no reading had been taken yet. Can it not get started with the first reading immediately after being installed?

Also, taking a reading precisely on the hour seems like it could easily clash with an alarm for a meeting alert or an alarm, no? Would it not be better to take it 30 seconds before the hour or something when it is less likely to coincide with another alert?

[magic berry]

if the wake up collides, it tries again a minute out, for I believe up to 10 minutes

[cloud cave]

Having just discovered this app, I’ve spent most of today wondering what this eyedropper meant! As in, I could see it was an eyedropper but I couldn’t connect that to “sample”. I just had a thought that maybe a battery icon with a small camera icon on top of it might be a good way to convey ‘battery snapshot’. No idea if there are enough pixels to convey that, but it was an idea.

[late tangle]

i was meaning to search what it meant and forgot about it...

[tranquil mountain]

Ahh, this was discussed for a bit

[cloud cave]

Yes, I found the chat about it above - I had been wondering what it was.

[rough token]

Simplicity and reliability. It's simple and predictable to choose these times so the user can tell things are happening as expected, rather than needing to remember some arbitrary time if they want to see it working.

As for the initial reading, keeping the above in mind, if you installed at 17:00, dropped 2%, then at 18:00 the only estimate available would say the battery would be dead within a day probably. This way it can be easier to understand

[rough token]

It only clashes with other Wakeup API apps, of which there are relatively few, and as lavender said it will retry up to 10m out from the wakeup time.

[rough token]

There aren't many pixels available and I'm not an artist sadly... It was an alarm clock ("an alarm is going to go off??"), then a calendar ("it's showing me my next calendar appointment??"), then we settled on an eyedropper which is pretty much synonymous with chemical and color palette sample taking, so I'm happy with that for now.

Perhaps another page of tutorial is needed

[cloud cave]

Perhaps, during the initial sampling phase, when there is no data to display yet, beneath “Need x samples…”, you could replace the 4 middle boxes, with three lines of text for each of the required samples:

1. 07 Jan 06:00 ✔️ 87%
2. 07 Jan 12:00
3. 07 Jan 18:00

If there is space, perhaps a fourth line:

"Come back in x hrs..."

This would make it clearer what we are waiting for, and when it will be ready.

[rough token]

Not a bad suggestion. Would that solve the issue of what the dropper means?

After 12 hours that state goes away forever unless you re-install the app anyway

[cloud cave]

Perhaps. Now I know what it means, it makes sense, but if you are new to the app and you don't yet understand that it works by taking 4 samples at fixed times of day, the dropper might be a bit confusing. (It confused me but maybe I am just slow! 😂).

I don't recall if the sample times are mentioned in the opening tutorial but if they are, I clearly did not read it closely enough! I know that after 12-18 hours, this all becomes a non-issue, but at least for me, the first time I opened the app I couldn't understand why the first sample had not been taken yet. I thought maybe it was not working.

What pixel dimensions are available for the dropper icon? Perhaps I can try and create that 'battery snapshot' icon idea to see how it looks? I'm not sure if it would be better than the dropper, but I'm curious to try. I'm not much of a designer either, but strangely find it easier when working with constraints. Coupled with using the term 'snapshot' instead of 'sample', it might be a bit clearer, maybe.

[cloud cave]

As I mentioned in the Brutal watchface thread, I discovered this was because I was using the testflight version of the iOS Pebble app. I went back to the release version, and the menu icon is visible now.

[cloud cave]

By the way @rough token , I spent ages last night combing though the Pebble app store trying to find my favourite watchface from back in the day, and when I eventually found it, I discovered it was also by you: "Beam Up". I have always loved how elegant this watchface is, even if the animations come at the cost of battery life. Until receiving my P2D two week ago, I had not worn a Pebble since 2016, and I couldn't for the life of me remember what this watchface was called. It took a while to find it - it was about 25 pages in!

[rough token]

There's a fair bit of information in the appstore page description, and I'll add an information page to the app itself I think.

Thanks for the feedback and offer to help! The icons are 1bit B&W PNGs, 24x24 for classic platforms and 28x28 on Emery (PT2).

[cloud cave]

I also really liked Split Horizon too. Do you have any plans to update this one? (there seem to be three variants for minutes, seconds and plain.) It would be nice if there was a single app version, with an option to switch to plain over night to save battery. (Aside: PebbleOS needs an API for "Asleep Mode" so i single watch setting for the hours you are typically asleep (e.g. 11pm - 6am) can be accessed by all watchfaces to turn off animations during this time. This way individual watchfaces don't need to create this feature themselves. It would be a simple way to boost battery life.)

[rough token]

Ah, thanks. One of my earliest. It's been recently updated but not to add that configuration. I've added it to my TODO list.

As for system API requests - you can add an Issue here, I think that's the given way: https://github.com/pebble-dev/pebble-firmware/issues

[rough token]

I think the option to disable animations in the config effectively makes them all one watchface, or close enough.

[cloud cave]

Some attempts at small 'battery snapshot' icons. It's admittedly very tricky to keep it looking like both a battery and a camera at this size.

They are maybe a bit busy

Emery would be easier obviously.

[rough token]

Oh wow, those look great. You could convince me you were an artist of some kind. I do think they're a bit busy... What about just a battery outline and a simple magnifying glass? It could convey 'looking at the battery' connected with the time displayed, which I think is quite clear also.

I won't have much time for dev until after the weekend but can hopefully release a few minor things at some point.

[cloud cave]

Yeah, that might be better. I'll have a go later.

[fiery tundra]

I think i also need this. A page for manual instructions. I also a bit confused about eyedropper. But now it is clear.

Maybe adding icon definition in this page?

[rough token]

Not a bad idea 👍

[rough token]

My attempt at 'next look at battery' icon instead of the dropper

Filled variant

[grim tree]

looks good!

UX idea

the down button currently opens the data log

what if it instead opened the graph, and another down press opened the data log

in effect creating a 3 page system

[rough token]

ooh

[drifting terrace]

battery delta would also fit well

though I guess it is less clear what it means

[rough token]

How do you mean?

[drifting terrace]

as in a battery with a letter delta next to it

[rough token]

Ah, I see. I think that's a notch further removed from the notion of an event taking place that measures something. It would be a good alternative to the rate estimation icon although we run the risk of just becoming a whole screen filled with battery icons 😅

[cloud cave]

How about this:

• top-right button (tap): open settings
• top-right button (long press): toggle awake/asleep
  [This could also be done via the settings menu, so the long-press is like a shortcut saving you from needing to go to the setting menu to do it]
• middle-right button (tap): open chart
• bottom-right button (tap): open log

[rough token]

It is tempting to save the user clicks through menus but I'm cautious of applying too many disparate things to all the buttons. I think with Rado's idea to have a multi-faceted main screen, we won't need some of those taps for the log and graph.

In fact, I'm thinking the data log can be a direct drill-down of the graph but that has to be clear to the user, especially when there isn't enough samples yet.

[grim tree]

I think the data log could be a drill down of the graph screen, but I think it will be less confusing to not reassign the function of the middle button based on the currently active screen

[rough token]

No, I don't want to change and confuse existing users

[grim tree]

imo, the clearest UI is that pressing down takes you to graph, pressing down again takes you to log, pressing up at the top of the log takes you back to graph and pressing up on the graph takes you back to the main screen

pretty similar to how the timeline and health UIs work

[karmic holly]

Another suggestion could be a ⏳ mixed with a battery.

[magic berry]

a multiple-pages sorta layout for muninn makes sense to me

page one is the overview, and select opens the menu; page two is the graph, and select opens the log readout?

hmm

[rough token]

There's something in this for sure. I'll do some thinking and map it out

The current set of buttons + menus is the result of tacking on new features anyway

[cloud cave]

The only issue I see with this is that currently the graph uses the up and down buttons to switch between the data points, though perhaps with this layout, that functionality could move the middle button.

[grim tree]

oh i didn't even realize that was a feature

[rough token]

Hmm that is a good point. It'll interfere with that.

[slate mason]

I got my mitts on a Pebble Time Round (Chalk), so can test on it when it's supported.

[rough token]

It's on my list 👍

But will probably require a much reduced layout because we lose the corners

[slate mason]

I think you can rearrange items to keep everything there. I'd be happy to help you on it.

[rough token]

In the meantime, here's the new version I prepared a couple of days ago. Time will be limited this weekend for more dev, sadly.

[slate mason]

Unfortunately, the Pebble app requires me to delete, then add the app in order to get the latest version. Then, all historical data is gone.

[magic berry]

if you end up pursuing paged layout, you could approach chalk by splitting content across more pages

[rough token]

Yes unfortunately that's the case but in a day or so you'd at least have your estimations back. Maybe after the weekend I should pursue the export/import feature next...

[slate mason]

Well, the OS should automagically update apps and watchfaces, just as they did 10 years ago.

[cloud cave]

Mine just did. Pull to refresh on the ‘apps’ tab in the mobile app, and the app should update when you next launch it on the watch. My sample history was kept.

[grim tree]

yeah, updates work fine for me

[cloud cave]

You could do a left-right multi page implementation. From main screen, right goes to chart, right again goes to log. (Or straight to log if no chart available yet). For both these pages up/down works as it does now.

The problem with this approach is that to exit the app from the log you would have to press back 3 times, but you could help my making it so if you leave the app on the log or chart it automatically returns to the main screen after 20 secs or so.

[rough token]

Side loaded versions are treated distinctly to Appstore versions, like an override. Something for the mobile app team to look at one day

[cloud cave]

A few attempts

I tried to do a spark on the third one, but there are not many pixels to work with!

[tranquil mountain]

Hard to tell that's a battery behind it, almost looks like a Rook chess piece

[verbal jacinth]

yeah something like this is a little complex at this size methinks

[cloud cave]

In trying to make the magnifying glass a bit smaller, I'm discovering that the size Chris came up with above is probably about right. I thought it might look better if it was a bit bigger and more obviously a magnifying glass, but then it overshadows the battery. It's a fun challenge!

The one good thing is that there are several other icons on the screen with the same battery, so even if this one is a little hard to recognize, the association with the icons should help.

[rough token]

Interesting that you ended up similar to me, thanks for putting time in. I'm on the fence on having too many icons with batteries in on the same page though so even my own version might need changing.

[cloud cave]

It is an app for monitoring battery life, so it's probably okay to have few a battery icons! That said, I do get what you mean - it's also nice to have a bit of variety. Have you tried putting any of them in a mockup to see how they look alongside the other icons? I'd be interested to see whether it feels like there are too many batteries!

[rough token]

Alignment isn't perfect but something like this

[cloud cave]

I did have a look around online for inspiration and found this. If these icons weren't so tiny something like this might work, but unfortunately, this design is just too complex.

[rough token]

Maybe too battery-busy for me personally. Leaning a bit more towards the ol' dropper, plus the new information page explains what it is for those who don't know.

[cloud cave]

Fair enough. I was a fun challenge to explore some alternatives.

[cloud cave]

These screens really are tiny! When you open these mockups on a 4k display it really puts things in perspective. I guess the Time 2 and Round 2 will be a lot easier to work with, not just because of the bigger screens and pixel density, but because they presumably are not so resource-constrained?

I guess, inevitably we will reach a point pretty soon with PebbleOS where new features get added for the newer models that the old models just don't have the resources to support. For the last decade, this wasn't an issue because the firmware was basically frozen in time in 2016. It's frankly amazing that the early models, like the OG which shipped in 2013, still work great at least from a software point of view. Not many wearable devices are still usable after 13 years! My Apple Watch Series 5 from 2019 is borderline unusable at this point - watchOS is constantly freezing and activity tracking crashes half the time.

[rough token]

It was a treat to get FW 3.x back ported to Aplite but it is the odd one out resource wise. I think for Muninn the build reports <5k remaining and if there's less than 2k heap remaining at runtime the PNG decompression seems to fail. Basalt and onwards I think at least 40-60k remains available.

[fiery tundra]

Can you do that for the log graph too? What is dot mean, x mean, R/ DR mean or something else in the information page. So people can check it if they forgot..

[rough token]

Sure. Maybe in the new navigation layout there's an intuitive way of doing it. On first page launch would be a start.

[fiery tundra]

Thank youu.. that's surely help 🙏🏻🙏🏻

[verbal sparrow]

Got a funny screenshot earlier via the iOS app. No idea why it’s pink! But I assume the 9,500 days is because it had not reconnected after running out of battery, so the time was 1 Jan 1970?

[verbal jacinth]

LMAO

[rough token]

Oof. If it's not reconnected before that sample happened then that's likely it 😕

As for the pink - no idea!

[pallid solstice]

Fw bug, will be fixed in next version (the pink tint)

[verbal jacinth]

is it your fault JP

[pallid solstice]

It was actually my fault

[verbal jacinth]

damn

[drifting terrace]

can we get official tinting now?

[magic berry]

rgb backlight

[verbal jacinth]

make the backlight pink by default

[cloud cave]

How do you take a screenshot on your Pebble?

[rough token]

Either with the SDK or through the new phone app

[verbal sparrow]

I used the new phone app for that one. On iOS it’s quite new. and I’m using the beta/testflight version

[cloud cave]

Nice feature!

[late tangle]

As regards the "one day remaining" screen:
-Is it possible to make it dismiss itself over time?
-Could it use the same vibration pattern as the system selection? Does the vibration respect Quiet Time?
-If nothing else, could a clock be added to it so that it doesn't disturb the watch's main function?

I assume the screen might work the way it does by waking up the app because a notification can't be created

[rough token]

It could dismiss itself, but if it triggers at midnight you might not see it.

No, system doesn't expose many user preferences

Once you see it, you can just acknowledge and dismiss it and go back to the watchface - it doesn't need to be kept open

[late tangle]

Thanks, I was mostly checking if it could be made at least somewhat closer to other notifications. In any case, am I correct in thinking that the vibration will not trigger during QT?

[rough token]

It probably will since it's a vibration call from an app and not a notification

Might be able to detect QT but will need to check the docs when I have time

[magic berry]

https://developer.rebble.io/docs/c/User_Interface/Preferences/#quiet_time_is_active

sdk4 only, it's a stub on aplite

[rough token]

Ah so part of a solution

[cloud cave]

I see the log contains a max of 16 data points, which i am about to reach. Does the data get erased after that, or is it just that the log does not display it? Will the graph display the entire history of a complete charge-discharge cycle?