Muninn - Battery Wisdom

[rough token]

It's a queue - once it's full the oldest entry falls out the end so there's always a maximum of 16. If a full discharge happens within that range you'll see it.

But, if a charge period is observed, the app remembers it separately. The logic for the "last charge" number on the main screen shows this as I assume most watches last more than four days

[cloud cave]

Good to know. I have not charged my watch since using Muninn yet, so wasn’t sure.

An idea for the future - perhaps sample data could be kept but offloaded to the phone? Getting to see how battery life deteriorates over time, via a mobile stats page, could be very useful.

[rough token]

Yes, I have a to-do list item for doing something interesting with data on the phone and with that idea it's taking a firmer shape. Will be a big project so don't expect it extremely soon 😅

[cloud cave]

That sounds great.

For now, it would be nice if the sample data could be backed up. At least that way, once you add these planned features in the future, they’ll be a decent amount of historical data to view.

[slate mason]

@rough token Whenever you're ready to tackle the Pebble Time Round, I have one ready for testing.

[rough token]

Taking a look at continuously exporting samples to the phone for a longer-term look

[karmic holly]

Funny, I just read an article on Volvo and they give the references of Muninn. I had no clue, I'm not into mythology.

[rough token]

Aha, yes as with many new words once you learn it you start seeing it places

[grim tree]

is it not possible to disable the one day left notification?

[rough token]

Not currently - can add an option though if it's annoying

[grim tree]

it's certainly not something I'd live with but it's also not something I want - i prefer the OS's built in low battery indication which is programmed to trigger at about a day anyway

[rough token]

On PT2 I see that with at least two days remaining but I know they're probably not finished tuning it. I'l add an option for this to my todo list

[grim tree]

it's certainly not something I can't live with* oops

[grim tree]

The OS built in one is also built off a static assumption of how long the watch should last, not the dynamic algorithm in Muninn - so I definitely think there's value to the feature

[rough token]

An option sounds about right then 🙌

[cloud cave]

I was thinking about this today - about how Muninn will probably be better than the watch at predicting when the battery will next run out.

Last week I outlined an idea for a Battery Saver mode for Pebble: https://github.com/coredevices/PebbleOS/issues/663

I was thinking that it would be good if Battery Saver could be enabled automatically if there is less than a day’s charge remaining (rather than at a predefined %), but predicting precisely this when this will happen is hard - it depends on the model, watchface used, battery age, notification frequency - in short all the data that Muninn is capturing every 6 hours.

Perhaps Muninn could constantly maintain an estimate of when the battery will next run out, that can be read by other apps/faces on the watch?

[rough token]

That's a very good concept! A few of my watchfaces do have options to stop animations during night hours but a system preference API is a great way to go. I don't think Muninn can export data to other apps but the ideas could certainly be used by the system

[rough token]

Given the settings list is growing, now seems the right time to move them to a phone config page with Clay. Hopefully the 'custom components' part of Clay is easy enough for me to add things like the long-term graph or something else aside from the options list.

Hmm, Clay custom components are geared to custom inputs and come with lots of legwork from what I can see. Perhaps not the way to go after all given I want a phone page to show the data in the future...

[cloud cave]

@rough token How does Muninn calculate when the watch was last charged? Is that detected precisely from the moment it was unplugged, or is the calculation based off the next sample when the charge % was seen to have a big increase?

[rough token]

The second! As an app that doesn't even run in the background it can't get events when charging state changes. I experimented with supporting that if the app happened to be open at the time but it proved too complex

[cloud cave]

Yeah, I can see that would make it way more complicated. I guess watchfaces can see when charging starts/stops but not watchapps, unless they are open. It was a smart move to create a battery tracker that aimed for good enough rather than perfect - it clearly made it possible to be way more efficient than Battery+ was while still being accurate enough to be useful. A few hours difference is pretty irrelevant when the watch lasts several weeks on a single charge.

[rough token]

Thanks, some compromises had to be made for sure 🙂

[rough token]

In the direction of a paged navigation, this is the first concept - a foreshortened action bar hint and a down arrow. Could be something in it.

(Obviously some pixel-nudging needed)

[cloud cave]

Nice. What sort of things do you plan to display on the second page?

[rough token]

The transitions might be a challenge - it's already a huge layout so smooth paging between won't be an easy option. A PebbleOS-era nudge-and-cut might be viable.

I think the idea was:

MAIN  >  MENU
  V
GRAPH
  V
 LOG

or

MAIN  >  MENU
  V
GRAPH  > LOG

[cloud cave]

Will you still be able to navigate between the data points? (that previously was done with up and down on the graph and log)

[rough token]

That will need a solution if this is to go ahead, yes. Maybe for case 1 it could be a Select press to begin scrolling data points.

[verbal jacinth]

what if scrolling down from the main view brings you to the log (which you can just scroll through) and pressing select on the log brings you to the graph

[rough token]

Depends if you view the log as a drill-down in detail of the graph or vice versa

Maybe the log is redundant with the graph

[verbal jacinth]

eh i wouldnt say it's redundant

[cloud cave]

Have you considered this:

        <back|up>            SETTINGS

MAIN <back|select> GRAPH <back|select> LOG

So pages run left/right rather than up/down.

This way up/down could still be used on both graph and log to navigate through the data points.

The back button always takes you back to the MAIN screen and then another press on back exits the app. App could auto-return to MAIN if left on GRAPH or LOG.

Just an idea... (I think i suggested this above.)

One issue is you have to go through the GRAPH to get to the LOG when the GRAPH does not yet have enough data to display anything. GRAPH could perhaps be hidden until there is enough data to display it though that might confuse the user on where it is.

[rough token]

That's good, yeah. It's been a busy week or so, so apologies if I forgot you already suggested it. Definitely more workable with the graph's functionality than my vertical plan.

Going out now, watch this space!

[karmic holly]

Will you support the fabulous touch screen PT2 have?

[rough token]

I'd love to try it! When the SDK adds it, of course

[slate mason]

The top third of the screen could be reduced enough that scrolling wouldn't be necessary.

[rough token]

This is about navigating to different windows without using so much menu, not about fitting more content onto one window. But you're right, that would be the next possible step if I needed more space

[rough token]

Hard to capture a video of the emulator, so here's a PBW with a draft of the new navigation changes. Also includes more tweaks to the graph and log windows.

The headline is - main window: hold up stays the same, select goes to graph (with friendly message if there's not enough data), select again goes to log. Down from main window opens the menu.

[carmine terrace]

I was showing someone a thing on my watch, and then Muninn popped up. They asked what that grim message was about, and that made me realise that indeed it does not indicate at all in the one day remaining screen that it is about the battery of the watch, and not about your own life expectancy 😅

[rough token]

It is nonspecific. A lot of things happening out there 👀

[cloud cave]

This works fine for me. That said, I can’t say if it is intuitive for a new user, since I already knew how it would work ahead of time.

Perhaps when you tap ‘select’ on the chart, depending on the currently viewed data point, it should jump directly to the corresponding entry in the log? (And vice versa)

[rough token]

Not a bad idea!

Obviously nothing would happen if there's no data yet

After trying it for a few days all that bugs me is that going from an app's main page to a menu is very "Pebble-y" action users would be comfortable with, which is sort of where we were before. And the menu now is a bit empty with a separate menu for settings, but I do like that separation.

Maybe 'information' can be merged with the version item in settings and we can just have a settings menu by itself on the Down button.

[cloud cave]

An alternative is this:

from the main screen:

• tap select - go to menu. I would add a toggle awake/asleep option to the menu as well. This way the long press up on the main screen, which is arguably less intuitive for a user to figure out on their own, is a shortcut only. You can toggle awake/asleep via this menu OR via the long press of up on the main screen.

This would free up a button on the main screen so you could then have:

• up button - go to chart
• down button - go to log

This would you give you the “Select opens a menu” feature which might be more Pebble-y.

This layout works okay provided you don’t anticipate adding more screens in future.

Also with this layout, you wouldn’t be able to provide the nice link between each data point when switching from chart to log (and back), as I just suggested above.

[rough token]

I liked the solid action of waking and sleeping the bird but realistically it'll only happen once unless someone has a strong reason to not track their battery. Could even remove that and automatically schedule the first wakeup.

If the three button actions on the main screen are special actions instead of menus they would traditionally have icons but I'm out of icon space on Aplite and horizontal space in general to expand the button hint bar anyway.

I'll do some more thinking

[grim tree]

I'd like the ability to pause to still be available

It's a very rare case, but at times when I know I'll be running apps for long periods of time, I want to ensure that Muninn won't interrupt them

[cloud cave]

A nice thing about the long-press for this is that you are probably less likely to trigger it accidentally. That said, I struggle to think of a situation when you would actually want to disable Muninn, particularly once the phone backup is implemented. I agree that ability to disable it should not be removed, but perhaps it does not need to be so prominent? It could also be done via the settings menu. It is enabled automatically when you install it.

It occurs to me that perhaps you don’t need the awake/asleep banner at all. If it is I disabled, display the “Munin is Asleep” message over the entire Home Screen. When it is awake you simply remove the overlay. No need to state specifically that it is awake. If it is awake it just displays the available data. This would free up a lot of space at the top to rearrange things, perhaps giving you enough space to label the buttons, or display another data point. Just an idea…

[rough token]

Yes, I will keep the long-press. Rado has already demonstrated someone will need it and without the only option is to uninstall which erases the app's data.

Re: phone backup etc. - seems app config pages exist separately to the JS sandbox, so if the watch sends data it's unlikely there can be a phone-side visualisation. That said, it's possible the phone could perform some analysis on many charge cycles using the extended data and show the insights in the watchapp. Could still be useful.

I like the banner for the same reason I like the bird - the app's theme and sense of identity. But perhaps it can be merged with the white-on-black status below...

[rough token]

My desk experiment is on track to hit 24 days - after a full charge it was estimating 22 days so this is a good result.

[verbal sparrow]

Log graph is showing the Battery life of the PT2 getting better

[rough token]

Interesting. If it had enough space to show a whole charge cycle I wonder if it would actually plot something more like the battery's discharge curve

[verbal sparrow]

You could zoom out the x axis to show longer timeframe perhaps

[rough token]

It's all 16 values stored. Maybe it could store more, but implementing zoom might be nontrivial

I want to sync many more samples to the JS side and feed insights back to the watchapp

[cloud cave]

Why is it 16 samples max? Is there not enough space for the app to store more on the watch? Is that limit set for Aplite, and if so couldn’t the newer watches store more samples?

Instead of zooming, could you just page left, if you press up on the oldest sample on the chart? I.e. It switches to a second chart page with samples 17-32 displayed.

[rough token]

16 was more insightful than 8, the original number. I've not tested the limits. Four day's worth is probably enough to assess the average discharge rate really. The aim of the watchapp by itself isn't to look too far into the long term. I'd regard anything like that on the phone side as a secondary goal.

[rough token]

I've begun the data sync to phone feature. Seems when you switch watches the JS data isn't wiped - I guess Muninn should wipe it if the watch model changes or something.

It also allows potentially for data to flow the other way

[drifting terrace]

there's a pr for a per watch settings for clay, which is a really cool feature

[rough token]

It's just a JS object. It could even have a separate localstorage key per model or watch ID

Hesitant to ship it without any value added for the user

[void jungle]

how are you liking the CT2?

[rough token]

Since I missed out on a 2016 dev unit, it's great to finally have the huge display 🙌

[cloud cave]

I was still sad not to get my PT2 years after Pebble went belly up. It always felt like it would have been the first Pebble that finally ticked all the right boxes (no more massive bezel!). I’m so pleased that we will finally all get to experience a Pebble with that large screen, something I never imagined would ever happen until the relaunch. Does the screen feel significantly larger in every day use?

[cloud cave]

Simply being able to capture more data beyond the 16 samples is adding value, even if the data is not visible yet. Linking the data to the watch serial seems sensible.

[rough token]

It does! Especially when you put the time in to scale up one of your projects and things look smoother 👍

[trail veldt]

Hello Chris - I am alpha testing a PT2 and wondered if you know why Muninn is not doing its regular samples? I initially installed it and it took three, but then seems to have stopped. I've now reset the app and it is no longer taking any. Is there something I can try (maybe reinstall the app?) or is this because the PT2 firmware is still very much alpha and full of other issues. Thanks! Your app works beautifully on my P2D and it looks even better on the PT2 display!

[rough token]

Hi - sorry about that! So in the sample log it still says 'No samples yet', even after 12-18 hours have passed, and it says 'AWAKE' at the top of the main screen? Any chance you can connect to the SDK logs?

[trail veldt]

That's fine! And yes that was what I was seeing. I have now removed and re-added the app, so I will see if the 12pm sample is taken and go from there

If I have further issues I will look at trying to get the SDK logs - but as I say I don't want to bother you too much with it as it may be an issue with the PT2 firmware and not something to worry about (until .116 firmware, my watch was experiencing inexplicable freezes, animation freezing, backlight getting stuck on etc, so yeah!)

[trail veldt]

The plot thickens! Watch was on my wrist and in use the whole time.

Must just be something a bit wrong with the current device or firmware

[rough token]

Oh weird - I've only ever seen that directly after a reboot 🤯

[trail veldt]

Same!

Standby mode isn't selected either, btw - just in case it might have a similar effect (though I was moving around, watch on wrist, and other stuff happening)

it wouldn't be impacted by watchface triggering a vibration on the hour, and other reminders/notifications firing on the hour would it?

[grim tree]

Two wakeups can’t be scheduled at the same time, but Muninn will adjust it’s time if it conflicts with another wakeup

[rough token]

Indeed, if the :00 minute isn't available, it'll try each minute after up to :10 past

Only for apps that also use the Wakeup API - system notifications from phone apps etc aren't part of that

Stand by mode isn't a factor as far as I'm aware

[rough token]

This is especially strange if there was no reboot - definitely a cause to report a bug report in the core app if you see it again

[pallid solstice]

ah cool thats a bug. have you reported it?

[trail veldt]

okay - I can report it for sure!

I wasn't sure whether to report to the app developer first or via the core app

I'll do the latter now (y)

[rough token]

Always good to check with the app dev first but in this case it seems to be not a me-thing

But I've been surprised before!

[trail veldt]

done! thanks for your insight - I'll let you know what they say

[verbal sparrow]

Muninn is working fine on my PT2 (linked to an iPhone mini 12 using iOS 26), so definitely a bug somewhere with your unit/phone combo

[trail veldt]

Interesting thanks! It did start working okay on my Pt2 and took three samples but none since then

[rough token]

There is one case where a sample won't be recorded - a 'battery bump'. This is when something external changes (battery temperature, firmware 'settling' after charging) and a <10% increase is seen. In this case no log entry is added and Muninn simply waits another 6h and uses the change over that 12h as a sample. But it seems unlikely that case will happen repeatedly.

[karmic holly]

What numbers do you get with the current firmware state? ±20 days from full charge? Asked Chris in other channel but no answer.

[verbal sparrow]

Currently at 46% 11 days after last charging it. So approx 19 days. It’s improved a lot in the last few firmware updates

I did use 6% in one 6-hour window but I was testing a watchface and using the dev connection a lot that day!

[rough token]

I'm on track for about 18-20 days too

[trail veldt]

I'm doing something wrong (or mine is cursed, which seems likely!) but I'm on about 2-3 days max with my PT2. My P2D gets more like 11-15 days. Maybe I need to reign in some of my battery killer habits on both watches...

[rough token]

3 days seems uncharacteristically low indeed

[verbal sparrow]

What are your battery killing habits?? Sounds more like a bug or hardware fault

[trail veldt]

I guess I just have all notifications on, backlight on for 8 seconds, a watchface that updates with the weather every 15 minutes...

But maybe it is a bug! Hmm. I remember the last notes Eric sent talked about them working on improving the battery life but they haven't given any indication yet of what should be expected. I remember the P2D beta took us from battery life of days at a time to suddenly a fortnight or so.

At the moment I'm just glad I have a PT2 that no longer freezes after an hour or so!

[verbal sparrow]

Which watchface you using? I might try it

[rough token]

I'd have thought you'd need a huge number of notifications to drain in only a couple of days, but I'm no expert...

[trail veldt]

Multifunctional 7 Segment

[trail veldt]

Maybe I should report the battery life as a bug and see if they can inspect the logs...

[verbal sparrow]

Do you have seconds running on that face?

[trail veldt]

Set to shake and show for 5 seconds

[trail veldt]

I'll see if the battery life bug report gets any response and if not on Friday I might try a factory reset. Pretty sure it was factory reset in the run up to .117 being released but might be worth a go. It's charging now.

[verbal sparrow]

I’ve put multifunctional 7 segment on my watch, let’s see what it does to the battery life

[trail veldt]

May I ask what you were using or do you change frequently?

(I use m7s on my P2D which gets more like a fortnight of battery - but maybe it is limiting that watch as well...)

The other face I had been using on my PT2 was TimeStyle

[magic berry]

eight second backlight could make a difference

[trail veldt]

I've also just realised 8 seconds backlight plus backlight on notifications is probably not great and very wasteful. Turned it off and backlight down to 5 seconds.

[trail veldt]

@rough token hahaha sods law: I was coming up to 6am so I thought I'd film what happens on the screen and... muninn fired up and took a sample. So that's progress! I'm not sure what changed.

[trail veldt]

Super excited to see what the 12pm sample says!

(this is truly awful isn't it. I think I might factory reset now and start over.)

You guys were talking about 18-20 HOURS of battery life, not DAYS, right? 🤭😅

[grim tree]

silly question, but you are on whatever the current firmware for pt2 testers is, right?

[trail veldt]

.117 yeah. That's the first firmware I've had that allows this watch to run for more than an hour without freezing

(pretty sure I have a dud!)

I see there is a .119 release but .117 is the latest that they've pushed to alpha testers in the app

[trail veldt]

The bird knows

[grim tree]

love the graph

[trail veldt]

it's quite hard to do a factory reset as the watch tries to pick up all the previous settings, watch faces and apps from the phone app, hmm

but we'll see if this makes any difference!

[trail veldt]

Wellll muninn couldn't take its first sample at 6pm, and battery has lost almost 20 percent in about 7 hours lol. It's not looking good!

[rough token]

If you turn on the "vibrate on sample" setting you might see a message that is useful as you'll be alerted. If nothing happens on the hour at all then it's a larger issue

[trail veldt]

Thanks yeah I did have that on for my P2D and it worked well but have left it all as default this time. I'll turn that on to see if it helps diagnose the issue.

[subtle sequoia]

watch your back tomorrow

[trail veldt]

This morning's cryptic fail mode: "Muninn chose to wait some more"...?

[subtle sequoia]

he spared you

be grateful

[trail veldt]

😅

[rough token]

That message is when there wasn't the right conditions to record one of the result types (charged, no change, etc).

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

If you follow the logic after this line until the line displaying the message we can work out what happened - currently this should be when the battery neither discharged, didn't change, or didn't charge significantly - a "battery bump" where some condition caused it to rise only a few percent, like a really cold night which happened to me. Is that what might have happened to you?

[trail veldt]

Thanks Chris I will take a look. Initially though no, none of these seem to be the case. Watch was on my wrist, discharging, I don't think it went up... But I'll bear this in mind and see what happens at midday

Discharge rate is slowing since the initial drop. Currently at 68% since 1pm yesterday (now 9am).

I did also get a .121 firmware update pushed which I've installed a few hours ago. Maybe that will help.

[trail veldt]

yeah unfortunately it did not fire at 12, or show a 'missed' message

strange

but am 99% sure this is an issue with this specific device so no worries!

current DIY discharge map (just for giggles)

[rough token]

Hmm, mysterious. The window should show regardless of the result, with different messages because it's an if/else. I'll try and see if there are any paths I haven't covered but I'm also suspicious of the lack of wakeups on your device...

[trail veldt]

yeah - like I say I suspect there's something deeply cursed about this watch so I don't want you to worry too much about it - but it's all interesting nonetheless

i think my final recourse will be to work out how to truly factory reset it - which probably incolves resetting the app itself as well - otherwise old settings remain and sync acros

[verbal sparrow]

Just an update. Having run Multifunctional 7 segment for a couple of days, it’s had no impact on the rate of discharge. Still predicting 19 days

[trail veldt]

Thanks @verbal sparrow - all useful to know, just confirms this unit is almost certainly defective

have been sending logs and reports to Claudio via the app in case it helps them

[rough token]

Sounds like the most sensible course of action

[trail veldt]

Just a random anecdote: the "Muninn chose to wait" just fired at 0902... 🤷‍♂️

Meanwhile, my second discharge log after a full "battery calibration" charge is showing very similar behaviour to the first - with slight improvement

(am sending Claudio regular updates via the bug report in the app, of course)

[rough token]

The plot thickens

Great graph

[trail veldt]

Yeah - I have to own up and say it's being generated by Gemini I'm afraid. But it's working really well to just open the chat, say 9am 37 percent and then it plots a nice graph and tells me some stuff about discharge per hour (of course very roughly as I'm just doing it as and when, and while percentages are a bit coarse)

Useful though. Good sanity check. Especially the ghost lines.

[rough token]

It remembers across sessions?

[trail veldt]

Yep - I just have to go into the same chat thread. I've been surprised at the consistency so far.

[rough token]

Muninn hit 100 hearts! 🎉

[grim tree]

What I find most impressive is that people are discovering the heart button

I guess there's ~10000 p2ds out there, so 100 hearts isn't that much as a percentage of users

but considering the number of active members here and how hard the heart button is to discover it's impressive!

[magic berry]

coreapp locker, and native store preview, doesn't have a way to add a heart

from coreapp, you can only heart an app from the webview store

I wonder how that's affecting numbers

[rough token]

Ooh, that feels like a gap

I wonder where we request that

It shows a count (if it's not sideloaded) so maybe it'll eventually be a button

[trail veldt]

Eric shared their dashboard view with me which shows that - of course! - they have really good analytics of all the test units, including discharge data. But it's still been interesting!

And nice to get an update from the team generally which implies there will be a fix soon for battery and for motion related stuff. 🤞

[rough token]

Yes I saw that - hope it helps your case!

[rough token]

What are the many white traces above the red one that I assume is battery level over time?

[trail veldt]

I think they are all to do with battery from the labels but I'm not sure. There's a lot of them! (Unfortunately his screenshot hides a lot of the labels etc)

[cloud cave]

My P2D is suddenly eating battery. I am pretty sure this is caused by the latest release of “Pebble Mesh” which I think added more on-the-minute animation to the watchface. But just in case, it is something else, I wanted to share.

I turned animations off on the face last night and hopefully that is better - 9% in one day vs 2% without.

[karmic holly]

Interesting. I'm curious if one day the emulator will be so advanced that we will know exactly the consumption for a given model. If a C-64 emu exists today that is realtime cycle exact, I guess it's possible? That would be nice for app devs to tune code for best efficiency and test different scenarios like enabling seconds vs not and share that info.

[cloud cave]

Yet, another reason I would like to see a "Battery Saver Mode" added to PebbleOS. Automatically disabling animations every night would make a big difference to battery life, especially with watchfaces that have a lot of animation. You could have it turn on during 'Quiet Time'. Some watchfaces can do this already, but it would be far better as a system-wide setting. https://github.com/coredevices/PebbleOS/issues/663

[karmic holly]

Why not, like the sleep mode on my phone. But some telemetry like the HR would require an individual switch.

[trail veldt]

@verbal sparrow hey random question - when you tested Multifunctional 7 Segment, if you turn on any of the seconds functions, do they render correctly? I've just noticed in this watchface and another separate one that seconds only render every two seconds. I've logged a bug but was curious to know if you'd seen the same.

#mypt2iscursed

[verbal sparrow]

Yes they did render correctly. Admittedly to get the settings I side loaded a fixed version not the store version. Let me check the broken store version

[trail veldt]

Thanks. I've tried both the store version and the hacked one. And then also Weather Graph. Also tested scaled and not scaled. Same result across the board.

[trail veldt]

Beautiful. Thanks!

[pallid solstice]

this is only sdk

hardware already had 1% increments

and afaik muninn did use them

[karmic holly]

Oh ok, I should delete

Done

[rough token]

Something to do with the emulator?

[karmic holly]

Yes, I could not test one of my faces properly.

[rough token]

Ah, doesn't sound Muninn related indeed

[torpid thunder]

Hello @rough token! I’m loving Muninn on my Time Steel, thank you. Will it be coming to Time Round at all? Cheers!

[rough token]

Perhaps! It'll need a radical new layout though

[torpid thunder]

My old Time Round has had a new battery put in but it still only gets 2-3 days of life off a full charge, and I understand Battery+ is something of a drain on battery life - Muninn would be extremely useful on the Round!

In the meantime, is there some way of perhaps conveying info through the icon in the app drawer on the watch? Not this exactly, because this is awful and I made it on my phone in about two seconds, but just as an idea

[trail veldt]

Today's weird Muninn bug (which is almost certainly just #mycursedPT2 and not for you to worry about) - Muninn opens but when I press the bottom button to see if there's a graph of any data, it exits to the menu

[grim tree]

Munin has an app glance that tells you how many days are left

You probably don't see it because app glances are very broken, but it Tries

here's an example of it working

[torpid thunder]

Forgive me, in this context what is an App Glance please?

[grim tree]

an app glance is a bit of text that can appear underneath the app's name to show information without needing to open the app

[torpid thunder]

Oh so precisely what I was suggesting. How is it enabled? Thank you!

[grim tree]

Developers can set their app's glance via a C function, or it can be set via the timeline (although this isn't very useful without remote timeline support)

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

Here's how Muninn does it

I guess you might be asking how it's enabled as an end user - it's always enabled

The problem is that app glances came out right before Pebble Technology Corporation (2016) went bankrupt, and so they were left in a broken state - and they're broken to this day

they work sometimes, but not consistently

[torpid thunder]

End user, not a dev, yep. This is very helpful info, thank you! I can’t say I’ve ever noticed any info come up as an app glance but I’ll keep an eye out for it. I still have notifications enabled for 10% warning so I can just sort of not think about it until I that pops up, but it is nice to have something to check without going fully into the app

[rough token]

Thanks Rado for providing info - AFAIK the phone app has to properly implement collating the C and HTTP sourced app glances before sending the sum to the watch. Seems right now that nobody does this right but hopefully it's fixed soon. Honestly we could just get by with C-only...

[rough token]

Does this happen if you press down before the animation is finished on the main screen? I'm suspicious of it...

[grim tree]

the HTTP sourced app glances currently don't exist to my knowledge, since they relied on the remote timeline server and that's not a thing

but yeah, for Muninn all you need is the C ones

they just need to work

[trail veldt]

It seems to

[trail veldt]

Okay it happens before and after the animation is finished

[drifting terrace]

I'm happy to provide a build of bobby with not entirely functional appglances

for testing

[pallid solstice]

dude people are taking this seriously 😭

for context rado and I are friends 😭 😭

[rough token]

I didn't think you were serious 🙂

[pallid solstice]

no I meant the person reacting with 😬 to that image xd

[grim tree]

😭

[grim tree]

I like how Bobby is a pebbleOS stress test at this point

If anything breaks anywhere, it breaks Bobby

[torpid thunder]

I knew it was a joke. Hard to convey with emojis!

[pallid solstice]

lol

[torpid thunder]

lol indeed! lol indeed.

Have I got this right?

Cool, thanks. Would it make any sense to have “Date of next charge” beneath “Days remaining”? As they’re conveying two parts of the same information?

No objections to how it currently is; just an observation

😬

[rough token]

For me it just reads left to right - past to future event

But I totally get where you're coming from

[torpid thunder]

That makes sense! It was just a thought as I was looking at it all at once. Top down. Bird’s eye view.

[drifting terrace]

there's some things I would love to test on obelix and getafix!

since they have a more powerful hardware which let's us do some fun stuff

[rough token]

Seems work is definitely needed 😅

Can't just turn it on

pebble-scalable is doing some work though

[torpid thunder]

Sheesh kebab. I appreciate the attempt though!

[rough token]

I didn't do anything aside from add the PTR build

It's essentially just a larger display

[swift bramble]

is there any option to see battery health

[magic berry]

worth noting this is a coreapp thing. appglances worked much more consistently with legacy app, and there was a brief time with the native store where the app icons wouldn't show, but app glances would

the way that bobby's appglances were broken is that it would crash the system when it tried to set one, not that it wouldn't show up in the launcher

[torpid thunder]

I’d have the old app if it didn’t involve sideloading and refreshing with a computer once a week (I’m on iOS). Probably a very naive question - and probably not for this thread - but are Rebble not able to put the old app on the app stores?

[rough token]

Define health I suppose. The only information the API gives right now is charging or not, discharge level, and plugged in or not

[swift bramble]

Like battery capacity.

I think to calculate that it needs battery watt or volt idk

[rough token]

Doesn't sound possible currently, sorry 😞 but the FW is open now, so perhaps in the future

[swift bramble]

sure, no problem. appreciate your work.

[grim tree]

I remember them being inconsistent on legacy app as well

[slate mason]

The second menu example looks great. However, there may not be enough space in the second line for the text and battery.

[torpid thunder]

I don’t know how it looks on the new bigger screens but the “ - Battery Wisdom” part of the app name gets severely truncated on my Time Steel. I put it there because I didn’t want to do away with it completely in my first interaction! I’d be fine if it just said Muninn on top line and then app glances worked to show remaining battery life in text or with icon.

[grim tree]

appglances can't include icons, anyway

[torpid thunder]

I’m guessing as this is system app it behaves differently than developer accessible app glances?

[grim tree]

yup - the system apps have their own special things

(and, even if it could, i think a days incidator would be better than a battery indicator, since the settings app already has a battery one)

[torpid thunder]

It was literally just a couple minutes bodge sub-photoshop job on my iPhone to illustrate a suggestion for functionality I didn’t realise already (kinda) existed!

[rough token]

They can but when I try the SDK barfs

[grim tree]

oh they can?

neat

[rough token]

The name in the launcher is taken from the appstore listing, not the app bundle itself, bizarrely. It's in there for searchability reasons

[rough token]

Yeah, TINY_ICON etc but has to be from app resources

From memory

[torpid thunder]

Yeah, I’ve got a couple of other longer-titled watch apps which have similarly truncated names displaying in the launcher. When eventually I upgrade to PT2 and P2R maybe the larger screen real estate will render this point moot!

[rough token]

After some re-work to pave the way, I've begun sending some hopefully useful stats back to the watch using the total (up to 128 currently or about 32 days) history sync'd to the phone.

Bearing in mind the data is limited (time, charge level, charge/time diff, rate, result type), the useful insights are also limited, but I've come up with this starter list. What do people think, would it be useful? Any other ideas you think are possible given the limited data?

• Number of days' data stored
• Avg. discharge rate across ALL samples
• Avg. discharge rate in the last week
• Number of observed charges
• Mena time between charges

In the future, there might be a possibility of a graph of the last 32 days, if the JS side can send back just the graph points pre-plotted...

[trail veldt]

Battery is much improved with x.122 firmware so far. And the backlight motion issues are sorted. Muninn still doing that thing where I press down to see the graph and it goes back to the menu. But signs of improvement with this firmware update.

Still not 18 to 20 days but 4-5 days is an improvement on 1 day or so.

My Gemini graph is looking good too

[rough token]

Interesting, thanks for the update. Mine skipped three samples on Sunday, and I have no clue why. Seems back on track now though.

It also occurs to me the chart doesn't take into account the gaps. I should try and fix that.

[trail veldt]

Do you get any debug messages? "Failed to run because blah"? Guessing not from your message. Interesting! And have you only seen issues like that in the PT2? I run Muninn on my P2D but haven't paid close enough attention to see if that one "just works".

[rough token]

Not sure - will keep an eye out. I've also turned standby mode off in case that's somehow being too aggressive with wakeups

[trail veldt]

Ooh yeah I never normally enable standby mode - I did wonder if Muninn was failing to run because of something like that but it must be something else

[torpid thunder]

Is disabling standby mode advised for Muninn users then? I do have it enabled

[grim tree]

i haven't noticed any issues with it on - it shouldn't impact wakeups

[rough token]

I want to find out if it's a factor. Not sure yet

Mine's been solid with it on for weeks until the last couple of days. Or I haven't noticed, one of the two.

[trail veldt]

I should probably just Google this but is standby mode basically for when you take the watch off and leave it sat somewhere for hours it goes into low power mode?

I wear mine 24/7 so I've never turned on standby mode. But let me know if my understanding is incorrect!

[rough token]

Yes, it's supposed to turn things off/down on the watch (BT, CPU, etc) when it detects that it's completely stationary for something like 20m+

[fallow hedge]

I just opened the app on my PT and saw it said it missed a reading. I have stand by mode on

[rough token]

It'll say that when a wakeup ID was created and stored, but when the app starts it checks it with the FW and it's told it's invalid - or in the past. If the wakeup never happens then this happens. Otherwise it's impossible to detect a missed wakeup.

But another data point, thanks!

[grim tree]

it should be just Bluetooth?

[rough token]

That's extremely likely

My memory is hazy

[verbal sparrow]

I’m getting a new crash on Muninn after a factory reset on my PT2. When I select down to see the graph the watch quits to the bottom of the main menu.

You seeing that too? Or should I log a bug with Core?

[trail veldt]

Yeah I've had this for a while too.

[verbal sparrow]

I’ve reinstalled Muninn will see if that fixes it

[rough token]

I don't get it which is frustrating! Couldn't hurt I suppose. If it's not a fw issue they can just close it. 😕

[trail veldt]

Just for whoever is interested - .122 firmware is giving me much improved battery life. Still not what @rough token and @verbal sparrow are seeing but a definite improvement on this specific device.

[trail veldt]

Probably nothing, but interesting you say it dumps you to the bottom of the menu. Mine just kicks me back to the previous menu state - e.g. where Muninn sits and with it highlighted/selected.

[verbal sparrow]

I have it on a quick launch (long press down). If I launched it from the menu it crashed back to the Muninn item in the menu

[trail veldt]

Ahh got it. 👍

[rough token]

How many samples do you have, if you can tell? I wonder if there's a case where the graph drawing crashes or something...

[trail veldt]

Well I couldn't tell but I am guessing not many. I just wiped data within Muninn and now the graph page loads (e.g. pressing down now works and doesn't crash Muninn)

So maybe it is some corruption or something in drawing the graph.

[verbal sparrow]

I couldn’t tell as it was trying to get to the graph when it crashed. I’m not sure it had succeeded in getting any samples after the factory reset though. Seems to have collected one at 6am after reinstalling

[trail veldt]

I wonder if some errors or corruption in data collection (e.g. constantly missing samples) leads to corrupted data and therefore a broken graph.

[rough token]

The samples will either be recorded or missed - corruption inside a single sample is unlikely. Tonight I will look over the graph code for anything that would be tripped up by a low number of samples or only large gaps or something like that. It feels like an edge case now.

[trail veldt]

I would say if this crash is only happening on PT2 alpha test units perhaps just don't worry about it. But if it's happening on other hardware or firmware then it might be worth a look.

[trail veldt]

@rough token sorry if I've asked before - what does it mean at 12pm when it says "Muninn chose to wait some more"

@rough token sorry, sorry, just searched and you already explained!

So yeah I think there's just something weird going on with how the alpha PT2s (or just my cursed one) are reporting battery. Muninn seems to always have a reason not to take a sample and it's probably because there's a weird glitch in the reporting or something.

[rough token]

According to my reading of the code, this case can only occur when the battery level has increased by a tiny amount - a temperature or settling-after-charge case we do indeed want to ignore and see this message for.

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

In all other cases I can see, result is set to a value that isn't STATUS_EMPTY and it should show 'taking a note'

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

The next step here would change that message to show something more debuggy - but you'd have to lose your sample history in order to switch from appstore build to a sideloaded one.

I'm also half-way through implementing the JS-side longer-term analysis feature, so cutting a new public release would be messy. I think the data is okay, it's just the UI to implement.

Aplite is out of memory again, so I may have to settle for a simple summary message or removing the feature for Aplite. But, given that those watches are likely going to have only a couple of days of battery life, it might not even make sense to offer it in the first place!

[grim tree]

i believe you can switch from an app store build to a sideloaded build without wiping app data

it's switching froms sideloaded to app store that forces you to wipe

[rough token]

Ah yes that is right

[rough token]

MVP of the sync feature (obv. fake silly data here)

[verbal sparrow]

Mmm, it’s crashing again trying to access the graphs again. Think it was just after the fourth sample. This evening (before that 4th) it was showing three samples but “not enough data” for a graph.

[rough token]

Thanks, that's intel. Would you be willing to try a side loaded version with a possible fix?

I found a couple of possible crash cases

[verbal sparrow]

Yep happy to try a sideload

[rough token]

I'll try and put one here soon - I have visitors now!

[rough token]

It's also hamstrung with this issue with the android app currently

[rough token]

That issue was resolved by a quick update by Steve in the alpha channel app. Since the change was also introduced there it's unlikely production will see it.

[rough token]

Have a go! Bear in mine to go back to the appstore version will require uninstalling and losing the app data. But in a couple of days you'll have it back anyway.

[drifting terrace]

I never used muninn so this is my chance

[verbal sparrow]

Interesting. Opening that sideload from the iOS app causes the iOS app to crash. Will log a bug with Core

[verbal sparrow]

Latest iOS TestFlight app is quite unstable!

[verbal sparrow]

Sadly, sideloaded version hit the same problem. Three samples, fine, but no graph, fourth sample appears to have been taken, but watchapp closes when trying to access the graph on down button

Historical stats says it’s synced 5 items, so it’s either crashing after the fourth or fifth sample

[rough token]

That's data - thanks! Shame it's not fixed yet. I can use that some evening soon to try and repro

[trail veldt]

I'll keep an eye after the next sample, currently on 3 synced items, no graph (but obviously graph page loads).

[verbal sparrow]

Ok, I have no idea what changed but it’s working this morning after 7 samples.

The TestFlight mobile app version did update to 1.0.10(6).

[rough token]

More data, thanks! I wait for 4 samples for the graph because otherwise it looks like just a disfigured line and there isn't much of a trend to show.

Reproduced on my PT 2 at 4 samples - but the emulator is fine. Probably some invalid memory access or something. Progress!

[rough token]

Ohhhhhh this is something else. The graph drawing logic has a variable x_gap which is the horizontal gap between plotted points. It uses this formula:

const int x_gap = GRAPH_W / count;

GRAPH_W is a constant, but when animating the graph, the animation scales the log length (count) from 0. So the first frame, it's a classic divide by 0 crash.

But why doesn't it happen regardless of log length?

Because of the animation easing algorigth and timing. When the log is longer, the 500ms the animation is scheduled to take is already past 0 for the first portion of the animation at that speed and easing curve. But when it's just 4, the first frame works out to an animated value of 0 🤯

This should be fixed, if you want to clear the app data and try again?

[verbal sparrow]

will do

[trail veldt]

Yep mine crashed after four samples again.

Trying the new one - this is without clearing the data

Shall I clear data to properly test?

[verbal sparrow]

Worked fine with 8 samples, will clear data and check what it does with 4

[rough token]

Yes, you'll need to clear and then get to 4 samples again. 3 and 5 are okay for aforementioned reasons

Thanks both!

[trail veldt]

Done! Thanks to you, Chris!

[karmic holly]

Hello Chris, I don't know if you have access or not but now that Eric praises Claude, have you tried throwing the code at Claude and ask if there is anything wrong? I'm not saying it will solve everything but sometimes it's only a single hint that will make you realize something you missed.

Now I know the source is there for everyone to contribute and KUDOS for that, but I don't have access to Claude, and I don't have all your knowledge to understand everything it would say I guess.

BUT! I have access to another one and just did a quick test and guess what, it has found an obvious error. A typo, yep! I just did a single file, which is data.c and on line 383 you wrote this: return last >= avg * EVEVATED_RATE_MULT; instead of ELEVATED, now you tell me the importance of this. 😉

There is a long list I don't want to post here, because I just don't want to throw it all at you and be like, there you go. I'm pretty sure you will prefer having a look at it yourself and you'll asks your own questions for what you feel and such. But I must admit as an old programmer in my early age, I still find this cool to look at code, I wish I would have continued to learn C when I was young.

Some other critical warnings to be verified are:

Out-of-bounds array access

• changes[] in test_data_generator: literal length must equal NUM_SAMPLES. If NUM_SAMPLES is larger, accessing changes[i] will read past the array and crash.

• data_get_sample(int index): no bounds check — callers passing invalid index can read/write out of range. Fix: validate indices (0 <= i < NUM_SAMPLES) and match changes array size to NUM_SAMPLES.

Division/modulo by zero

• WAKEUP_MOD_H used in ts_info->tm_hour % WAKEUP_MOD_H. If WAKEUP_MOD_H == 0 this crashes/div-by-zero.

Wrong units leading to overflow

expected_acc accumulates current->rate * current->time_diff. If rate and time_diff are large (and both int), multiplication can overflow signed int and wrap to negative values — subsequent logic could use negative timeframe or array indexes and crash. Fix: use int64_t for accumulators when multiplying potentially-large ints and check ranges.

[rough token]

Thanks for having a look, I will respond properly when I have some more time

But at a glance, I can say those examples are theoretically a problem, but the values involved will either never trigger them, or never be set to values that would cause a problem. The wakeup modulo hours one being set to 0 is nonsensical because it would be waking up every minute - defeating the purpose of the app somewhat.

I find with LLM code analysis the results need to be filtered with some context knowledge and common sense before being used to make changes.

(it also helps that I'm the only consumer of these functions so I'm in control of the inputs. If it was a library I'd be a lot more defensive in checking params etc, as you rightly suggest! 👍

[rough token]

Fixed the graph to show actual timestamps on the X axis, so gaps in data are visible and don't skew the slope.

[trail veldt]

Made it to four samples with a graph

[rough token]

Hooray!

[drifting terrace]

the pin to remind me to charge is very cool

[rough token]

Ah, you saw it?

[drifting terrace]

I did!

I'm using the old app though, idk if that matters

[rough token]

It shouldn't! It uses the new coreapp method and falls back to the web API

[hollow nacelle]

Curious, did you ever figure out a workable UI for round displays? Most notably where you position the side buttons that represent that you can press up/select/down? (Looking at Media in this threads turns up “no” but maybe you got somewhere privately)

[rough token]

I need to polish up this version for release once I know the long-term stats look at least sensible, then that's probably next on my list as gabbro emu isn't too far off

[rough token]

Those with the recent PBW - the logic for counting charge events is inverted from a refactor, I've fixed it ~but can't make a new PBW right now (busy lunchtimes!)~

Actually it was releasable 🤷‍♂️

[trail veldt]

Just installed this and after 7 samples it crashes on trying to open the graph

(or do I need to wipe data again?)

[rough token]

You shouldn't need to wipe data again, this just changed how charge events are counted

Crashing is annoying though

[verbal sparrow]

Sidelined version worked fine for 4 and 5 samples

[rough token]

Thanks! See if you also crash on the graph at 7. I'll try the emu again

Yep, 7 is another bad case 🤯

[verbal sparrow]

Think this is 7:

[rough token]

Well, I found a fix to my reproduction:

// Find total time and so the gap between intervals
int time_total = 0;
for (int i = 0; i < count - 1; i++) {
  const Sample *s = data_get_sample(i);
  time_total += s->time_diff;
}
if (time_total == 0) time_total = SECONDS_PER_DAY; // Avoid divide by zero, show something
const int x_gap = (GRAPH_W * SECONDS_PER_DAY) / time_total;

And it looks good

This has the fix, although Paul is likely over 7 points by now.

That one might have had a test flag enabled, hang on...

[trail veldt]

Yep - up to 8 now but graph loads again

[rough token]

Thanks for the help debugging!

[karmic holly]

Cool! That will be the very first app I will install when I get my PT2.

Curious if you tried showing the code to Claude, if you have access to it of course. Or if anyone else did.

[cloud cave]

Currently, if you are using the iOS TestFlight native App Store then it I not immediately apparent how to upgrade to the new release from the sideloaded version . If you click the link Chris shared above it will open the App Store web page for Muninn from where you can tap “Get” to upgrade.

Or click here: https://apps.rebble.io/en_US/application/692b3821d7dcba000a809ba5

[verbal sparrow]

You can also delete the sideloaded version, refresh the app locker and reopen the store version

[trail veldt]

That's what I did yeah.

Great job Chris!

[rough token]

I have not, but if I get stumped on a problem I may consider it.

[cloud cave]

Do you not lose your data if you do this? I'm sure I did that in the past and it lost it.

[verbal sparrow]

I didn’t lose data, but I did lose the settings, like for the timeline pins

[rough token]

Beginning work on the PTR layout - it might not actually be as hard as I anticipated

[verbal sparrow]

When Muninn nicely illustrates an issue with your watch 🙂

[rough token]

Any idea what changed?

[verbal sparrow]

Crashing every half hour or so apparently eats battery. Not been able to reliably replicate the bug annoyingly.

[rough token]

Muninn - Battery Wisdom

[rough token]

Something like this. A couple of minor things had to go.

I like how true to the original it is still.

[hollow nacelle]

That looks great already. The stuff you cut seems like the right cuts and I’m glad you made the right decision to keep big bird over AWAKE text (bigger bird, better app) since passively monitoring already covers that

The buttons on the right probably could be spread out a little more but that’d require making them longer probably to compensate for being more cut off. But I don’t have a PTR to know what it actually looks like.

Somehow it feels even more spacious than the rectangular design now

[karmic holly]

Does the diamons in black bar have an utility or it's a separator? Could save 2 pixels height, from 5 to 3.

[hollow nacelle]

Oh I see why! You didn’t just scale down, you brought some of the text up like “Days left” vs Days and “Est. % / day” vs “d”. Super nice that actually makes a good difference to have visually

[trail veldt]

PTR alpha test when? 🫠😅

[rough token]

Hopefully in the next day or so!

[rough token]

A splash of Norse style

[rough token]

Yes, that part is annoying and not finished 👀

[torpid thunder]

An insane thought: as actual battery indicator has now gone, could the diamonds indicate battery level somehow?

[rough token]

Ooh, that's out of the box thinking. It would need to be obvious somehow. Perhaps a thunderbolt from Odin?

[trail veldt]

I'm picturing the diamonds filling like hearts in Zelda when the screen loads, popping in from the left.

[rough token]

This is a thing that may work @trail veldt

I would try my old PTR but there's a screw that I cannot get out

[trail veldt]

Ahh I don't have the hardware I'm afraid!! Just a P2D and alpha PT2

[rough token]

Ah, my mistake.

I tried Gabbro with no other changes and it just crashes outright. Ominous!

[hollow nacelle]

v spooky. Wonder if this has anything to do with it. ScrollLayer with a width over 255 (Gabbro is 260) caused a crash (I don't think your first screen has a ScrollLayer though)
#1422454361371447316 message

[rough token]

The welcome message windows does have a ScrollLayer 👀

I see you may have already reported it? I wonder how many other parts of the fw/API assume certain max values like that...

[hollow nacelle]

Luckily the PR2's max resolution is over the max size of uint8 so it'll be fast to find things in the UI at least

[rough token]

I think I'll sit on it for now, then

[hollow nacelle]

Yeah I was able to work around it with how my UI looks but with some of yours I think you'll notice the missing 5 pixels

[rough token]

Hmm, gaps on the shadow hints I guess

[hollow nacelle]

Well it's only width and you can't see the extreme end of the shadow hints on Gabbro since it's rounded off. Height can be 260 (unless you have horizontal scrolling happening you mean)

if (bounds.size.w > 255)
{
  bounds.origin.x = bounds.size.w - 255;
  bounds.size.w = 255;
}

I just did this and left it for future-me to deal with. Shoves a 260 width view 5 pixels to the right so the action button doesn't have a gap against the edge

[torpid thunder]

My graphic design BA not completely going to waste!

[valid peak]

Anything you need tested on old PTR hardware? Looks good so far.

[rough token]

Maybe seeing if the calculations and the graph play nicely with the shorter battery life? See how it goes for a few days

[verbal sparrow]

This was my first pebble watch! Let’s see how long the battery lasts.

[rough token]

You can see there the bezel cuts a tiny amount over the display, which is shown as a shadow in the emulator but absent in my screenshot above

[rough token]

For some reason the drawing of the menu in the sample history window is only drawing the things on the right, although I've not touched that code recently 🤔

But it's fine in the emulator 🤯

[rough token]

False alarm, I missed a '9' digit...

[eternal socket]

Hi @rough token! I really like this app and I even have it set with quick launch on the up button on my Pebble Steel!

I have a question tho, is it normal for the app to lose all its data randomly? I don’t know if it’s because of the watch itself, maybe because of low memory? I can’t seem to identify the exact cause of this. For instance last night I plugged the watch to charge it, it reached 100% and then I opened Muninn to check the stats, and all data was gone, even the settings inside the app were back to default (battery pins, high drain alert, etc). And obviously the graph and samples were gone too. Is this a known issue? I’m on v1.21.0

[rough token]

Hi! I haven't heard of this or seen it myself, but back at Christmas time I heard of a few missing samples. Only thing that I know of that wipes data for an app is uninstalling it from the Pebble phone app, or re-pairing to another phone. Or a FW bug is also possible but not something I can look into or fix easily 😕

If you're using the new Core app and see it happen again, submit a bug report in the mobile app, you never know it might have something useful in

[eternal socket]

Sure! I’ll try this next time… the app hasn’t been deleted from the watch/phone, I’m trying to figure out what might be. Thanks for the reply!

[rough token]

It is a bit mysterious, sorry I don't have more 😕

[verbal sparrow]

Conclusion on the PTR test. Battery doesn’t last long enough on one charge to show a graph. 🙂

[rough token]

Oh dear

[valid peak]

Here's where I'm at. I spent some time using my Pebble Steel and charged my Round up after that. It'll definitely come in handy when the new Round units drop.

Discord bug, I guess. It kept displaying as the old screenshot unless I changed the file name or killed discord. It's showing the graph now, right?

[rough token]

I have a few more small refinements to make and an idea to use some of the space at the top of the main window, and then it should be ready for release

[valid peak]

Pulled this off the charger at 5:30 in the morning. Here's the results at 12:30 the following morning.

[rough token]

Hmm, it is not a very detailed curve indeed 👀

[rough token]

Some design additions - something of a day/night skyline at the top because the space is empty without the big AWAKE word, and finally extending the middle divider to the bottom, there's juuuussssttt enough space.

Should be able to release the next update very soon!

[verbal sparrow]

PTR update. When I don’t connect the watch to the core app, it lasts a lot longer!

Still gets notifications via iOS

Thought this battery was on it’s last legs, perhaps not.

[rough token]

Wow, that's quite a difference!

[karmic holly]

What is the little circle below the 2 of 12:00? Is it an out of graph value?

[grim tree]

it shows where muninn expected that sample to land

[karmic holly]

Dunno if this could eventually be a problem with even a lower value so I guess Chris will check this.

[rough token]

It's not a problem, it just looks unusual. The graph should probably not draw it if it's below the lower Y bound

Or not draw one at all for a charged sample

Does this fix it?

[eternal socket]

Hi! I find it funny that when I select Muninn on my pebble steel the crow’s eye is the only thing visible from the app icon! Hahah I don’t know if that would count as a bug, maybe a quality of life change for future updates?

[hollow nacelle]

Aplite is weird for menu icons. I can’t pretend I’m well versed in the why, but Timer+ had this issue and apparently doesn’t now after either

1. I made the icon white and black, no transparencies
2. I set the memoryFormat it 1Bit in the package json

I think 2 must have been the solution? Maybe it tries to palletize it even for Aplite unless you set it to 1Bit? Unsure. Either way it is Aplite specific

https://github.com/YclepticStudios/pebble-timer-plus/blob/master/package.json#L31-L37
this for reference for Chris in case it helps

[eternal socket]

Weird. For now I used a 1bit png on a watchface I’m working on and that worked fine, obviously no transparency. Or in this case maybe giving the crow a white outline? Haha

[hollow nacelle]

It has something to do with the inversion handling for menu layers. I can’t pretend to know the ins and outs of it. Someone more qualified than me on it was talking about something similar related to how Bobby handles bitmaps inside of the app, not Aplite or menu icons, but that’s where I derived this from

[rough token]

Indeed, an Aplite problem. I don't have one to hand and the emulator doesn't have the launcher menu. I can try another format and you could give it a try?

[eternal socket]

Sure! I’ll update the app and see the results!

Now it looks nice!!!

[hollow nacelle]

https://github.com/YclepticStudios/pebble-timer-plus/pull/16#issuecomment-3977214218

Timer+ is currently going through it as a note. They’re seeing that this won’t work because setting it to 1Bit does in fact make it 1Bit but for all platforms, including color. I had thought that it’d elevate the other platforms intrinsically but it doesn’t seem to

[rough token]

Hooray!

[rough token]

Is that for a color icon?

[hollow nacelle]

No, it's for an icon that has black, white, and transparency though. So if you wanted the eye of your crow to be white even when highlighted on color displays. Setting the icon as 1Bit will make it replace with blue (among other things)

If they wanted the white of their icon to invert to the highlight color (blue) on color displays, setting to 1Bit would be the solution but they want the white to be retained like other system app icons.

I posted a follow up comment that seems like the solution

Context back to App Dev. But if you are cool with the crow's eye inverting to blue, nothing extra to do here
#app-dev message

[hollow nacelle]

Unrelated to that, the new art at the top of Muninn is great. Will it appear on the Wakeup screens as well?

[rough token]

Oh I didn't notice the eye being transparent now. It's okay for now I guess 😂

[rough token]

Not a bad idea!

[hollow nacelle]

I think it’s a cool look for the crow to have its eye change color on highlight honestly

[rough token]

It's theme compatibility ✨

[eternal socket]

A couple observations on 1.22.0:

• I have set Muninn as the quick launch app when I press the up button in the watchface screen /homescreen. before in 1.21.00, I entered Muninn by long pressing the up button, then when exiting the app it went back to de watchface screen. But now in 1.22.00, when I exit Muninn (after opening it by long pressing the up button), it always go back to the app list! Doesn’t matter if I enter Muninn from the app list or the watchface screen, it always goes back to the app lists. It should work as before, to go back to the watchface if you launched the app from that screen, and go back to the app list if launched from there. To be context aware, putting it in other words 😅

I really like this app, so I’ll keep using it as my daily battery companion!

[rough token]

Hmm, strange. Does the behavior differ depending on if you use long or short press quick launch?

[eternal socket]

sorry, it was a false positive situation, now it works as expected! my PS has been acting strange lately! Lucky for me I have a PT coming in the mail soon to replace it!

[grim tree]

Muninn won't launch for me anymore on p2d

[magic berry]

have you gotten the firmware update to 4.9.127?

[grim tree]

that would do it

[rough token]

Oh I forgot about that 😬

Do I need to recompile on the earlier SDK for the time being and do another update?

[grim tree]

nah it's my fault for being out of date

dw

[rough token]

Well I meant for those who can't get that fw

[grim tree]

i think that for pebble tech corp devices users it'll still run fine?

i think the firmware requirement only applies to flint/emery/gabbro

[rough token]

Hmm okay. That's not so bad, thanks

[late tangle]

@rough token A suggestion for the "days remaining" counter: maybe it'd be more useful to have one decimal point for single-digit numbers of days remaining?

Currently, I have 21% drain (so basically very close to 5 days), but the days remaining counter sits at 04

This'd be particularly useful for Pebble Corp watches which I assume rarely if ever reach two digits, but it'd also be useful for newer ones when they're far from 100% charge anyways.

[rough token]

Maybe, although the math is integer math and gets a bit sensitive when the numbers get low. I'll see if there's a quick win I can implement.

[rough token]

Turns out this should be quite easy!

[late tangle]

famous last words

[hollow nacelle]

Is this good?

[late tangle]

the lithium mafia will get you

[rough token]

Wow

Can you get app logs if I give you a test build? And also find out how many items are synced

[drifting terrace]

is this the infamous c2d time reset?

no, that's a few too many years

[waxen lodge]

i'm noticing that Muninn crashes a lot on startup on my third day of using it, is that a known issue?

(i only just 3 days ago noticed that it supports the time round now!)

[rough token]

It shouldn't! Is that just on PTR?

[rough token]

Can you install this and send me all the logs please?

[waxen lodge]

PTR! here are the logs if that helps:

[21:31:52] animation.c:86> Animation 300000020 does not exist
[21:31:53] animation.c:86> Animation 300000020 does not exist
[21:31:54] main_window.c:524> Heap 40248
[21:31:54] main_window.c:551> wd 40028 B
[21:31:56] bitmaps.c:73> 0 bmp
[21:31:56] pkjs> Muninn:? Pebble JS Bridge initialized.
[21:31:56] pkjs> Muninn:97:25696 PebbleKit JS ready!
[21:31:58] pkjs> Muninn:97:26006 appmessage: {"PUSH_PIN":1,"DAYS_REMAINING":1,"DISCHARGE_RATE":63,"GET_SYNC_INFO":1}
[21:31:58] pkjs> Muninn:97:22640 Inserting pin: {"id":"muninn-prediction","time":"2026-03-05T03:00:00.828Z","layout":{"type":"genericPin","title":"Time to charge!","body":"Muninn predicts you will need to charge soon (Est. 63%/day)","tinyIcon":"system://images/GENERIC_WARNING"}}
[21:31:58] pkjs> Muninn:97:22811 Pin insert returned
[21:31:58] pkjs> Muninn:97:16557) {"key":"history-f9319594961ef8c3a16448c6b7f8bd17"}
[21:31:58] pkjs> Muninn:97:16845) loadHistory: 8 items in 7ms
[21:31:58] pkjs> Muninn:97:17691) WARN: Ignoring <1d diff (1 0 43315s)
[21:31:58] pkjs> Muninn:97:17853) {"chargeTimes":[1772550007,1772593322],"timeDiffs":[],"meanTimeS":null,"meanDays":null}
[21:31:58] pkjs> Muninn:97:18247 {"SYNC_TIMESTAMP":1772593322,"SYNC_COUNT":8,"STAT_TOTAL_DAYS":2,"STAT_ALL_TIME_RATE":41,"STAT_LAST_WEEK_RATE":-1,"STAT_NUM_CHARGES":2,"STAT_MTBC":null}
[21:31:58] comm.c:122> Sync: 1772593322 (8)
[21:31:58] ault_handling.c:97> App fault! {d008a08a-6e34-4cc4-98dc-bae02ce5e087} PC: 0x4ea LR: 0x809c859
Crashed, but no active project available to desym.

seems like it's the same issue each time:

[21:35:11] animation.c:86> Animation 300000024 does not exist
[21:35:11] animation.c:86> Animation 300000024 does not exist
[21:35:11] main_window.c:524> Heap 40248
[21:35:11] main_window.c:551> wd 40028 B
[21:35:12] bitmaps.c:73> 0 bmp
[21:35:12] pkjs> Muninn:? Pebble JS Bridge initialized.
[21:35:12] pkjs> Muninn:97:25696 PebbleKit JS ready!
[21:35:12] pkjs> Muninn:97:26006 appmessage: {"PUSH_PIN":1,"DAYS_REMAINING":1,"DISCHARGE_RATE":63,"GET_SYNC_INFO":1}
[21:35:12] pkjs> Muninn:97:22640 Inserting pin: {"id":"muninn-prediction","time":"2026-03-05T03:00:00.906Z","layout":{"type":"genericPin","title":"Time to charge!","body":"Muninn predicts you will need to charge soon (Est. 63%/day)","tinyIcon":"system://images/GENERIC_WARNING"}}
[21:35:12] pkjs> Muninn:97:22811 Pin insert returned
[21:35:12] pkjs> Muninn:97:16557) {"key":"history-f9319594961ef8c3a16448c6b7f8bd17"}
[21:35:12] pkjs> Muninn:97:16845) loadHistory: 8 items in 7ms
[21:35:12] pkjs> Muninn:97:17691) WARN: Ignoring <1d diff (1 0 43315s)
[21:35:12] pkjs> Muninn:97:17853) {"chargeTimes":[1772550007,1772593322],"timeDiffs":[],"meanTimeS":null,"meanDays":null}
[21:35:12] pkjs> Muninn:97:18247 {"SYNC_TIMESTAMP":1772593322,"SYNC_COUNT":8,"STAT_TOTAL_DAYS":2,"STAT_ALL_TIME_RATE":41,"STAT_LAST_WEEK_RATE":-1,"STAT_NUM_CHARGES":2,"STAT_MTBC":null}
[21:35:13] comm.c:122> Sync: 1772593322 (8)
[21:35:13] ault_handling.c:97> App fault! {d008a08a-6e34-4cc4-98dc-bae02ce5e087} PC: 0x4ea LR: 0x809c859
Crashed, but no active project available to desym.

[rough token]

Nasty null! A clue.

[waxen lodge]

if it helps, this started happening after i charged the battery to 100%

and then muninn never started again

[rough token]

It's probably handling the null bad. Probably because no timeDiffs were available for that calculation. I might have time before this weekend when I'm busy.

[waxen lodge]

ah no rush! i'm guessing i can probably fix it temporarily by uninstalling and reinstalling

guess i'll find out

[karmic holly]

Ask Claude to have a look! 😁

[waxen lodge]

unless you'd rather i keep it like this to test it

[karmic holly]

Partial access to Haiku, for comm.c 159-165, he says:

Missing null pointer checks: If t->value is null, dereferencing it with t->value->int32 will cause a crash. You should verify that t->value is not null before accessing its fields.

[rough token]

The issue is that the value is null in the first place - otherwise it's not showing the valuable information. I can fix this by requiring a minimum of timeDiff values.

[karmic holly]

Also while at it, just curious if this is true in the context you use it...

[rough token]

True, although I don't do any more reads from it by name in that block before the return.

@waxen lodge try this one please

[waxen lodge]

ah! no crash!

[rough token]

Great. You should see a hyphen under 'avg charging interval' on the phone sync page

[waxen lodge]

looks like it

[rough token]

The reason was that after discarding charging gaps less than 1 day (think consecutive events that were charge-like) there was nothing to divide by for an average.

I wonder if it will also help @hollow nacelle issue, but I also needs logs from them probably

[waxen lodge]

ah makes sense! glad you could get the bug fixed!

[rough token]

Thanks for your help 🙂

[waxen lodge]

and thank you for fixing it so quickly! glad to already have my cool battery graph back! 🔋 📉

[rough token]

Does it look useful for PTR with a shorter battery life?

[waxen lodge]

tbh i haven't used it long enough to have a solid idea of how useful it is

but i'll let you know!

[late tangle]

Nice

[hollow nacelle]

Sorry just got off work. When I downloaded that above one I saw the hyphen as you said
When I downloaded your newest build I see this. Which is good but not as good as having 4 million days of life span

So newest build chopped off approximately 4 million days of battery time

[rough token]

Does it seem like a reasonable number?

[hollow nacelle]

14 days? Yeah that’s exactly what I expect

My data in this app has been absolutely spot on. That one thing was all I noticed ever as far as oddities

[rough token]

Ah, that's good to hear. Thanks for testing!

[hollow nacelle]

Most of why I haven’t reported anything is that the app has worked exactly as expected for me since I’ve installed it. Is that expected?

If it should be more broken at any time let me know and I’ll double check. It works well for me. My graph is always right

It’s hard to report “works right”

[rough token]

Yep - no news is good news 🙌

[hollow nacelle]

I will say that the prettier top banner has made me less mad about Muninn killing my apps when it wakes up, legitimately

[rough token]

Hard to find a way around that one I'm afraid 😔

[hollow nacelle]

No that's fine. Other than a background worker it's what wakeups do. I am non-jokingly happier now that the top banner has a prettier design. Tricking user's with design is good

I don't know the complexity of letting me decide if I want this to be a background worker vs a wakeup task. I don't know if it being a background worker is actually a battery detriment as long as you still treat the background work the same way as wakeups?

I think with a background worker you still have to wake the app up eventually to actually sync the data. All it'd do is let you grab the battery data silently but you can't push it to the phone or process it or anything until the app is woken up

[rough token]

IIRC the worker runs "all the time" and so the dev relinquishes their control over how much they draw power, essentially. I could implement the worker but it is a little against the original idea. But an option the user can conciously choose would give them the choice I guess.

[hollow nacelle]

I think what you're doing now is good enough anyway. More readings don't really seem to be needed in my personal experience with the data and I don't think the wake ups are that bad with how far apart they are spaced.

For dealing with stuff like PTRs and EOL batteries, is there some sort of assumption you can gather from the user or watch info that could adjust your calculations for that device?
The guess is that the P2D will last 14 days for example so you could have that as some sort of baseline. I wonder if you could ask the user how old their battery is in their device and that could influence some assumptions the app makes on when it should wake up, discharge rate, etc.

I don't know if that is useful, I've just been trying to follow the plight of PTR user battery life in here

[rough token]

Hm, maybe. The model info would help but batteries can be replaced and that's harder to detect. The app so far just uses pure math and observations - seems good enough for now. Maybe in the future something about battery health or age is available but not today.

[rough token]

Since the phone is syncing a lot more data now (up to 4 months currently, maybe more if it performs okay in the JS sandbox) it may be that that data could be used for more purposes - a better chart on a website, generating statistics for each model or by battery age etc if the sample size is large enough.

Could be insightful, although it would require the user being okay with their anonymized battery data being sent to an API that I would create. This can be a one-click opt-in action in the watchapp. Does this sound like a useful thing to pursue?

[grim tree]

I'd love that!

[gaunt rapids]

I imagine that would be extremely useful for devs if they could tie firmware versions and apps to battery drain

[rough token]

Interesting idea. That might have to be info volunteered by the user somehow, since it can't be read by apps

[magic berry]

watchapps can check firmware version

let me find out how

bobby includes firmware version in feedback reports

[drifting terrace]

that comes from the watch info I think

[magic berry]

https://developer.rebble.io/docs/c/Foundation/WatchInfo/#watch_info_get_firmware_version

[rough token]

Oh neat. Might be a bit of work to specify fw version per sample, which I imagine would be necessary

[rough token]

I've made a decent start on the API - DynamoDB tables, Lambda handler, API Gateway routes and a custom domain. Always quite fun to plug a few AWS services together 🙌

https://github.com/C-D-Lewis/pebble-dev/tree/master/watchapps/muninn/backend

[rough token]

Upload works, but it's only useful if there's value to be had - focus will soon be on what the web page could offer with multiple months' of data and across devices.

I'd feel good if my PTS was "lasting longer than 80% of PTS watches"

[rough token]

URLs are hard to display though

[limber temple]

Maybe a QR code as option? No documentatio for it yet but it's there: https://github.com/coredevices/PebbleOS/blob/main/src%2Ffw%2Fapplib%2Fui%2Fqr_code.c

[drifting terrace]

that's not exposed in the sdk, is it?

also would only work with watches newer than c2d

[rough token]

If you read carefully, and get your 6-digit code which is exchanged from your watch token right, you'll be okay

[limber temple]

True 😵‍💫 , it's under "changes to the firmware" https://developer.repebble.com/sdk/changelogs/4.9.127/

[magic berry]

what i really want in pebblekit is a way to open a URl in the phone's browser

there are so many places it'd be helpful. watchapps, timeline pins,

[rough token]

It would be useful. IIRC Android notif actions used to allow launching activities but not anymore

and not through PebbleKit directly without companion

I could also spring $20 for another Route53 domain that is shorter like muninn.app

[hollow nacelle]

I'm a big QR code from the watch fan for stuff like this. Though muninn.app/s0jr5t isn't bad. I'd certainly always put the third n of muninn in the wrong spot each time

[rough token]

Do you still see the crazy avg charge interval number?

QR would be great ofc, just point at the wrist

[hollow nacelle]

No ever since that update you did it's the "correct" number

[rough token]

Sweet

I could bake in a QR to https://muninn.chrislewis.me.uk and show the code below for manual entry

If anyone wants to submit their data, bearing in mine the web page doesn't exist yet!

But when it does, I can use it to test

[hollow nacelle]

If performance is the concern, you can hardcode all the structural elements of the QR code which just adds complexity on preparing data to render. You could optimize away most of the byte array computation since the domain is always the same and just XOR the last 5 characters but that surely isn't that impactful with your URL length. You have to draw the entire thing every time anyway which, from my experience, is the worst part for the Pebble (not bad for a QR of your size)

[hollow nacelle]

Just downloaded this one

[rough token]

That's a great insight, although only non-Aplite platforms have the sync feature, so I'd have no issue showing them a PNG for the main domain.

I'll have something basic put together in the next few days, but for now, I will sleep 😴

[magic berry]

https://tenor.com/view/genki-dama-spirit-bomb-goku-gif-12526925

[rough token]

Some progress - no web page yet though

[valid peak]

So, would this be long-term test results in a browser for a given watch?

[rough token]

Yes - the phone is storing up to 4 months of samples and giving opaque stats on that, but this will allow viewing all the details and a chart of it all which isn't possible on the watch

[rough token]

Aside from a nice chart of the entire sample history, there's a not a lot of new things the web UI could do. Therefore I propose to remove the stats window from the watchapp and upload directly from the settings menu, receiving the QR code.

Reasons:

• Long-term stats on the watch feels quite opaque without being able to see the visuals
• Given the watch's main predictions only use the local watch data, not the extended history, this might lead to confusion.
• Simplifies navigating many menus
• It can free code-space!

Given the web UI can show more interesting things in general if the population of users grows (leaderboard!?) it will also mean people actually use it 👀

[grim tree]

I wish to share one of the graphs of all time

featuring a gap of slightly over a week

[rough token]

Glad that's working haha

[rough token]

I wonder what your whole sample history will look like in the webapp - I started with the chart with chart.js, now adding in all the other stats

(Note I am not a designer)

[rough token]

Initial web UI version is live, use this PBW to upload your data and see the full graph. I think some re-work on the watchapp is needed to integrate it fully, but not far to go.

https://muninn.chrislewis.me.uk/

Example, my watch's exhanged code is C74FAA

[grim tree]

how is the exchange code generated?

also that's a nice site

also also, idea for another stat - based off the all-time avg rate and the last week rate, you could generate all-time average battery life and last week battery life in days?

[rough token]

Thanks! The JS side sends the watch token to an API, and a six character code is generated, checked for uniqueness, and returned.

Not bad ideas. I guess "average charge interval" is another name for "all time average battery life"? I'm assuming people only charge when they're about to run out, but a more frequent charger will change that data point to be more frequent.

Does "last week battery life" mean anything if it always lasts more than a week? I know that's probably not a thing for PTR for instance. Unless I'm misunderstanding!

You can see that my battery life has gotten a lot better in the last week - probably a fw update. Also it's not a black&gray PT2, but a black&red. Probably because it's a test unit.

[magic berry]

tiny pinch of feedback --- I did not expect the code to be case sensitive, haha

[waxen lodge]

neat! next up, gamification and global leaderboards

[magic berry]

nooooooo

i dunno, i feel like if you gamified it, people would start doing silly stuff just for the biggest number, and then you wouldn't be able to usefully make inferences about real battery life in the wild

i suppose people do that anyway, and core's got internal analytics on all their devices anyway

[waxen lodge]

haha yeah i can imagine it would immediately go horribly wrong

[grim tree]

My idea for the battery averages is to be able to see how long a full charge would last on average for all time, and for your current usage

The idea is literally 100 / percent per day = days of battery life

the average charge interval is a good stat, but as you said it's skewed by the user's charging habits

[hollow nacelle]

case sensitive codes?!?

[rough token]

I just need to toUpperCase() the input value, will do that soon 👀

[hollow nacelle]

Saving me from having to press shift a single time on my code 🙏

[rough token]

Does the chart on the webapp work for you?

[hollow nacelle]

It does! I presume the data is right! I’ve lost a lot of legacy data from watch resets and stuff but for my new data it’s good

[rough token]

Great. I guess it's the only way to reveal any gaps or problems with the extended history on the phone since it's the only visualization

[hollow nacelle]

I’m pretty happy with uploading the data somewhere to keep track just because I do unpair, reset, switch apps (?!) personally sometimes and I get sad about losing data like Muninn’s. But I just think it’s fun to look at the data

[magic berry]

say, do you have a phone-side config page for muninn

I bet you could have the config gear open the all-time webapp automatically, and then feed it the code via pkjs

[rough token]

I don't know if I can use Clay with PKTS 😕

But I'm game to have a go

[drifting terrace]

can't wait for clay ts

[hollow nacelle]

I use Clay with PKTS in Kagi News but it's just a Rollup configuration to be sure it shoves the file into the built directory that PKTS does as well so it can be used at runtime

...
input: "src/ts-config/config.ts",
output: {
  file: "src/ts-build/config.js",
  format: "cjs",
  compact: true,
...

And you just end up with

• ts-build
  • config.js
  • index.js

And your wscript (hopefully) picks up both. Them my npm build just runs rollup after pkts finishes npx pkts build && rollup -c rollup.config.mjs

I quite honestly just used rollup because I know how to make it produce the JS file in the way I want and for no other reason than that

[hollow nacelle]

Though I think the implication from Lavender was to mark your app as configurable, but when configuration is open, feed the URL for the graph to the page and open that instead of config. (Right?). Not necessarily use Clay for config

[rough token]

Ohhh I see. I forgot it could be any URL. Worth a try!

Slight UX wrinkle - the button is permanently labeled (Settings) in the Pebble mobile app. I could explain it in the appstore description but I've seen people rarely read it all

[gaunt rapids]

Have a blurb in the muninn app where the qr code is displayed?

Maybe a startup message so people know their battery data is being uploaded to some strangers database? 😁

[rough token]

It's a voluntary upload from the settings menu. If the upload is successful, the QR is shown. If not, nothing happens. I should have been upfront about that here

[gaunt rapids]

Ah neat, that's a good system

[rough token]

Indeed, sorry if there was confusion. Uploading data without an explicit action from the user was at the forefront of my mind.

Hence the settings action.

What it looks like from the bottom of the stats menu. I still plan to merge it to the main menu soon.

Language could probably be improved although space is limited

[gaunt rapids]

I'm glad it was explicitly stated but I trust you to do good work 👌

[rough token]

Thanks! The source is always available too
https://github.com/C-D-Lewis/pebble-dev/tree/master/watchapps/muninn

[karmic holly]

Maybe Confirm to upload could be Confirm to share data. Now one knows something is shared?

[rough token]

I like that

[rough token]

New PBW if somebody can test - made a lot of improvements and turns out that using it as the config page URL works really well ✨ I also re-organized the menu.

[verbal sparrow]

Loving the graph!

Shame my PT2’s battery life has not been great recently (I’ve logged bugs).

Not sure it totally agrees with the watch though

[rough token]

The web view is showing stats for the entire sample history. The estimation on the watch main window is from the last four days

[verbal sparrow]

Proves it’s got worse recently then

[rough token]

I have a hunch the couple of times my PT2 battery starts diving it seems better after a reboot. Try that?

[verbal sparrow]

I factory reset it yesterday. Seems to have slightly improved things, but not much.

[rough token]

Need to put a line on that main window that actually says it's the last four days (up to) if I can find space

[gaunt rapids]

I turn my watch off every night. When I turn it on in the morning, I get a message saying Muninn missed a wake event. Is this going to affect the accuracy of the readings and if so, maybe include an option to change the sampling times?

[rough token]

Yes, it has to be able to wake to take a sample. This is how I avoid using the background worker which runs much more frequently/all the time. Sounds like you'll only be getting samples at 12:00 and 18:00 then? It could still work fine if usage is steady. I'd actually be interested in knowing how that goes for a while?

[trail veldt]

Useful to know! I had taken a week and a half off from PT2 and been using my P2D which has been lovely. Going to switch back to PT2 today and had been hoping for some battery improvements but doesn't sound like it!

[rough token]

Mine has improved a bit since about a week ago I think

[trail veldt]

I'll give it a go! I think mine has always had battery life issues and other hardware problems. Looking forward to the final version, whenever they show up.

[rough token]

Oops, seems I didn't save the upload code on a per-watch basis - will fix that...

[trail veldt]

Ohhh boy. Fully charged 1h40m ago and already at 77% ummmm...

[rough token]

Yikes 🙁

[trail veldt]

😂😂😂

[rough token]

I don't know how much Muninn can help you as it is 😬

[trail veldt]

I'm not sure there will be a six hour gap either side of this entire charge!!

[gaunt rapids]

Yeah sure, Ill let you know

[trail veldt]

😅

[rough token]

It must have accelerated from some older rate in order to be deemed much faster 👀

"Muninn simply can't believe this!!"

[grim tree]

seeing this screenshot - it might be cool if it looked a little something like this (but yknow, with the text centetered and such)

(i did this quick mockup in KDE's default paint program which it turns out has no text tool so I had to make do with the text already in the image lmao)

...it does have a text tool i just couldn't find it

what sort of fuckin' text icon is this KDE

[hollow nacelle]

Have Muninn generate a QR code to link to a new battery when it’s looking real bad
“Muninn can’t help you anymore”

[rough token]

Hmm, looks nice, although the text area would look pretty empty, moreso than now

[rough token]

Haha. No QR anymore since using the config mechanism

[grim tree]

yeah- my idea is to center the text to make it a bit less empty

[rough token]

Oh yes, I didn't read properly. I can give it a try 🙂

[rough token]

This version is pretty final - can't seem to find any issues with it. Will test it myself for a few days and then probably it's release time 🙌

[fast warren]

Wish I knew how to copy URLs from Android CoreApp lol

[eternal socket]

when is this releasing? 😮

[rough token]

I have a few issues to fix (not being able to copy from the Pebble app config page is one I probably can't) and hopefully in the next couple of days 🤞

[rough token]

(If you want to be bleeding edge, this is pretty much what will be released)

I added a new small feature where if Muninn is launched and there is no 'last charge time' recorded yet, and battery is >90%, it will inform and assume it can be 'now'. This way you don't have to wait a full charge cycle if nearly full to begin seeing that.

[rough token]

No point procrastinating - if there are any issues, please shout!

[rough token]

PBW for those who want to keep their data and not uninstall for the appstore

[gaunt rapids]

Awesome, this looks great!

I did notice I can't copy the share link on the settings page

And long pressing it only opens it again

[rough token]

Yeeeaaahhh. Nothing I can do about that for now, but it shows the URL including your code, if someone really wants to share though.

[gaunt rapids]

True

Ah yeah you mention that like 4 messages up lol

https://muninn.chrislewis.me.uk?id=BF04A9
Here's my graph while turning the watch off every night

[rough token]

I thought about removing it, but weighing the neat access via the Pebble app settings vs the QR that forces the user to get their phone and scan the QR for a full web browser, at least it's there as an idea.

[gaunt rapids]

It's good to have in there. Can you put it in a text field instead? Fucky but selecting would be possible

[rough token]

In order to copy with a long-press? Worth a try!

Try it now?

[gaunt rapids]

Ayyy

That's great

https://muninn.chrislewis.me.uk?id=BF04A9

Nice and easy

[grim tree]

@rough token "use the upload option in the watchapp to start seeing data here"

it would be nice if it told you where that option is

[rough token]

It's in the second menu. I hope they would encounter it eventually 🤞

[grim tree]

oh yeah also, does it autoupdate or does it only upload when i manually upload it? @rough token

i probably shouldn't ping you about that but

[fast warren]

https://muninn.chrislewis.me.uk?id=9F6812
Pretty nifty

[rough token]

No worries! I was asleep. It's an explicit action, for now, so the user knows it's a process they can do if they are interested

[grim tree]

I would be quite interested in an auto upload mode that either uploads after every sample or once a day or something

[rough token]

I hear ya - maybe the menu item can be a toggle

Maybe not every sample - despite adding new features I still want to keep the wakeup process extremely lean

[grim tree]

still though, awesome feature - and I wanna toss you a general thanks for making this app too

it very much satiates the data tracking desires

[grim tree]

yeah I can understand that - I think once a day on the midnight wakeup would be a pretty good compromise

That way you can get relatively real time data on the website still

[rough token]

You're welcome! It's been a very fun project. And yes, once a day seems like a good idea - maybe in the daytime in case stand-by mode is enabled and the phone is disconnected.

[trail veldt]

I know this one is more for the Core devs but the latest firmware seems to be miles better for battery life so far. Never seen numbers like this on my unit.

[rough token]

That's more in line with my PT2 (when I'm not using it for dev)

[trail veldt]

😅

[karmic holly]

If you are looking for another cool project many will want, let me know. I like how you care for small details and always polishing.

[trail veldt]

As the spidery chaos data gets nudged off to the left, the new graph since the latest firmware is looking sweeeeet so far.

[rough token]

Sure, feel free to DM and run it past me

[rough token]

Looks like those empty circles are lining up gradually

[karmic holly]

I think I already shared that idea here somewhere... I wasn't there in the previous Pebble era but 6 months ago I read about the relaunch when latest Pixel watch was announced, and what I found amazing about Pebble is the numerous watchfaces available and the fact it is somewhat easy for anyone to create their own or app, there are new ones every weeks. We get to choose from already a lot and I want to be able to do like a playlist of favorite songs, but for watchfaces.

It would be handy to get an app to add all our favorites with options to automatically change watchface in use for another one in the list, based on time, like every 24h or every 3h or user define, a change occurs. With the option to scan the list linearly or go random. That's it.

I would do it myself but don't have the knowledge, nor skills. This one needs to be made from someone who knows the Pebble ecosystem well. Since Muninn seems complete for now. maybe you're looking for a new challenge? 😁

[rough token]

Interesting - sounds like something a companion app can do. There is an API that can remotely start a watchapp if it's installed.

[verbal sparrow]

Sadly my PT2 is still suffering from 5 day battery life. Tried multiple different firmwares and staying either connected or disconnected from the mobile app.

Latest firmware has it back down at 18% per day so marginally better than 25%, but nowhere near where it was. I’m wondering if this is a phone thing rather than a watch thing. Suppose I could swap phones for a while to test that out

[rough token]

Ah that's a shame 🙁

Phone thing could be a theory. Until the last week or so when a new FW update was released to me, I could maybe swear rebooting both made it slow down for a while, but could have been coincidence.

[verbal sparrow]

Spare phone is back on iOS 18. Could be an interesting comparison

[valid peak]

Am I understanding it right that I need 8 samples to use the web UI? I had to delete and reinstall from the store because I was stuck on an old version for some reason, and I've been running around the watch app trying to find the opt-in.

[rough token]

That's right - the place is in the Phone Sync page, which itself waits for 4 samples. This is so that you actually have the bare minimum of insights available to look at 🙂

[trail veldt]

Is it possible to prune off old erratic data or should I just wait for it to time out eventually as this new regime continues?

[rough token]

The only option is to reset all data and you probably don't want that 😅

[trail veldt]

My beautiful graph! No no, I'll wait! 🥹

[rough token]

Looks like about 18 hours to go

[valid peak]

There, finally. Looks like there was some old data kicking around somewhere. I guarantee it doesn't last anywhere near 33 days. 😉

https://muninn.chrislewis.me.uk?id=2D502D

[rough token]

Interesting. There's a gap between the 3rd and the 14th. You said you had to reinstall at some point?

And between February and March

The watch pushes whatever samples it has that are newer than the most recent the phone has. There's no logic yet to handle large gaps. Maybe there should be but right now I'm not sure what that would look like.

[late tangle]

as a PT owner im jealous of that smoother curve tbh

[rough token]

I think that's due to the 10% increments reported by the FW

[late tangle]

yeah thats what i meant lol

[karmic holly]

Tell the truth, you wanted to brag about this!

More seriously, how many of those were made?

[rough token]

More than the PTR gold

[valid peak]

Regarding the gaps in the data, I was using another watch at the time. Trying to keep a rotation going to give their batteries regular exercise.

[drifting terrace]

yeah, those aren't that uncommon

I have two for some reason

one of them is a kickstarter one too

[rough token]

Hmm. I wonder if a break more than a couple of days should be truncated or something. Or wipe if the watch token changes and use whatever is then synced from the new watch (up to 4 days of samples)

Because otherwise the extended stats are very Not Accurate.

[waxen lodge]

yeah the PTS gold was moderately popular i think

the PTR polished gold is the super rare one

[trail veldt]

Just while we're at it Chris, the implementation of the web based stats interface is really nice! I love that it persists and I can update from the watch app. Really neat stuff. Works in that semi automagic "stuff just works in the background' way that the best pebble apps do.

Also dat CURVE! 🥹 Sorry to go on but this test unit has been cursed since day one and is now working as it should have been all along. It's exciting.

[rough token]

Thanks! It was fun to work on and I'm hoping soon I might be able to present some statistics from all the participating watches - best fw, model, etc.

[trail veldt]

Can I be a bit simple and ask what is meant by the "Trend" bit at the bottom of the graph? I've always wondered.

[verbal sparrow]

It means you’re getting 66% less battery drain than it expects. Makes more sense with less volatile numbers. Here’s mine. Lost 6% in last sample vs the expected 4% (16% per day) so 2% more than expected.

How my watch lost 6% while I was asleep with no notifications is slightly baffling

[trail veldt]

Ahhh thanks @verbal sparrow - my numbers have been all over the shop which is why I haven't understood them or spotted a pattern. That makes sense.

[rough token]

Yes, that. Thanks Astosia for explaining, I was getting ready for work

It works by summing all the actual drops and comparing them to a sum of all the predicted rates at each sample

[trail veldt]

No apology necessary, I'm very grateful for how active you are in this channel!

I might reset my data on the next full charge because I'm hoping the weird erratic battery drain is behind us but you never know!

[rough token]

Looks like I had Odin's attention on my walk this lunchtime 👀

[rough token]

I began on adding buttons to allow CSV export and downloading the chart as an image, but it appears that they don't work in the coreapp config webview, sadly

I wonder if it's possible to detect this environment and warn the user

[weary ravine]

If there isn't a proper way what you could do is add a parameter to the "settings" url then check if it exists using javascript, something like: https://muninn.chrislewis.me.uk?id=${id}&isapp

[rough token]

That's not a bad idea!

[late tangle]

Is the line in the "%" character just how the font works?

I almost thought I had some issue with my screen

[rough token]

The curve joining the top 'o' to the '/'? It's a font ligature I think

Well not quite, just how that character is designed

[hollow nacelle]

This sent me down a rabbit hole of discovery on how the % symbol came to be and I feel like I learned a lot that I’m going to tell someone who does not care about later

[rough token]

@grim tree I've added a setting to enable automatically uploading a history update once a day. Will refine it and then it'll be in the next update. Might be a while on that, got some life stuff going on atm

[grim tree]

thank youuuuuu!!! 💚

take your time, thank you so much for continuing to make this app better!

[rough token]

I also have graph image and data CSV export ready too for any data nerds out there

[grim tree]

https://muninn.chrislewis.me.uk/?id=4FC7DC hm, my data got wiped?

i should have more than 24 samples

[rough token]

I see 24 too

How many are you expecting?

[grim tree]

well, more than that?

i thought it was supposed to store more than fit on the watch

[rough token]

Yes, I had about ~100 before I reset for dev purposes. The max is 480 which is arbitrary.

Have you switched watches with the same phone?

[grim tree]

nope

[rough token]

Well the watch stores up to 16 so that was unlikely unless it happened a couple of days ago and got to 24.

The JS side uploads the whole list each time so it must be what is stored on the phone. There aren't any mechanisms to truncate it and it's stored on a per-watch-token basis.

[grim tree]

oh huh

[grim tree]

my guess is my local storage just got wiped somehow

but idk how

[rough token]

Obviously it is a thing I fear and do not understand when this sort of thing happens.

[grim tree]

is there some possiblity to have the web storage append to existing data instead of overriding it

[rough token]

Maybe. I'm aware there may be gaps which do funky things to the calculations that are not time-based.

It's possible if someone gets to the full 480 funky things may happen anyway, I haven't gotten that far yet.

[grim tree]

i'll keep an eye on the measurements and tell you if i see data missing again

[rough token]

That would be helpful, thanks

I guess the JS side could fetch the web side but it's a simplified version because the web side doesn't need all the fields. I don't want it to get that complicated.

[grim tree]

nah i don't want the JS side to fetch the web side

i'd just like the web side to be able to a long-term log if possible

[rough token]

I hear you, I've made a note.

The scope has expanded but I like to think the non-watch bits are opt-in enough so that you can just use the watchapp as-is and it's still simple enough.

[rough token]

I also did some work on aggregations based on all users' data to see what we can learn across many watches. The current dataset is 76 which may hopefully increase over time. I think it might be best to ignore those with only 1 contributor...

These are updated once a day by the Lambda function based on an EventBridge cron trigger

[rough token]

I'm aware the color SKU is probably not a defining characteristic for battery life...

[karmic holly]

So cool. Yep merging color is a good idea. Is that visible to all? I mean link is public? I would prefer by platform to be in steady alphabetic order.

[verbal sparrow]

Colour sku isn’t even representative of reality for the alpha PT2 units. My blue & silver thinks it’s black & grey in the app

Something has fixed the battery drain issue for me though. 🙂

[gaunt rapids]

It would be cool to ask the user if/when the battery was replaced. The one in my time steel should be ~8 months old

[grim tree]

@rough token just saw the auto upload option, thanks!

[rough token]

That feature isn't live yet, it needs refinement. Good shout on alphabetical order

[rough token]

Indeed although hard to capture that response and data

[fallow hedge]

Muninn has been missing readings a lot and didn't realize when I last charged my watch so my stats were all whack for a day or so then suddenly decided it had been charged even though it was charged days before and now are whack in a different way lol

In other news my battery had been draining faster than when I first took it out of storage for a bit there and now I seem to be getting better battery life again lol idk what happened

[rough token]

Which watch model is it? Can you share screenshots of the charts and web stats if applicable?

The charging detection is simply a sample that has a significantly higher charge level than the one before it, nothing more. Sadly this is as close as we can get with wakeups

[fallow hedge]

Pebble Time.

[rough token]

I've heard rumors of persistent storage being cleared mysteriously but it's nothing I can control as an app developer. If you think it's unexpected, I'd advise raising a bug report in the Pebble app

[fallow hedge]

It didn't seem to be doing it when I first started using it but maybe cuz I was checking it more frequently than I am now

[rough token]

Can you share a screenshot of the charts please?

[fallow hedge]

Sorry I didn't have my watch on me earlier, it was charging

[rough token]

Yep, there's a gap alright 😂

[grim tree]

@rough token so, here's something I wanna discuss

There's a little minor annoyance when using Muninn and Bobby - Muninn schedules a wakeup right at the even hour slots

And if Bobby tries to also schedule something in them, it fails

Now that could be fixed by having Bobby do the same "if the wakeup is occupied go a minute ahead" logic that Mininn does, but I wonder if it might not be a lot easier and better to just make muninn wake up at :02 or something

[rough token]

Hmm. This possibility was always there. I can probably ship an update faster but it would look weird to show an arbitrary number of minutes past the hour.

Ideally all wakeup using apps have this possibility and the return code to the schedule function is clear when a wakeup is not available so trying again is the next expected step.

[rough token]

Maybe another setting could be a compromise, the user can cycle up to 5m as a value

[trail veldt]

Ruh roh!

[rough token]

Try a watch reboot

[gaunt rapids]

Could just round down. Take the reading at 12:02 and call it 12:00

[rough token]

Not a bad suggestion but you'd still either be wondering why it didn't wake up at 12, or being bemused why it did wake up at 12:02.

[gaunt rapids]

True

[rough token]

The global stats feature is now live, and your own battery life and rate estimates now show where you place against the average for your watch model too

Although I'm suspicious of the battery life average for PTS - 27 days sounds insane. But it's using the same logic.

Oh I just realized a pretty major flaw in how I group the models... But I'm about to head out to a wedding reception so I will hide this for now and work on it later...

[valid peak]

Probably outliers from my watch, sorry. 😅

[fallow hedge]

Yea like 5 days gap and then it was saying it's been on for like 17 days or something for like a day or 2. All the stats were way skewed lol

[rough token]

Maybe a wakeup was missed and the chain was broken

[snow lava]

Comparison links are evil lmao

[waxen lodge]

hey i'm the one chalk person haha

[rough token]

I did wonder! 🤔

[rough token]

Now I see two 👀

Stats looking a bit better now I fixed the groupings

i.e: P2 and P2D not considered the same...

I might also separate out P2HR because the sensors would make a difference

[rough token]

I've unhidden this feature since it looks a lot more coherent now 👍

[late tangle]

https://muninn.chrislewis.me.uk?id=AE1C4C

How come the rate is 10% when I've always seen it oscillate between 15% at best and 25% at worst?

[rough token]

The "Avg. Discharge Rate" on that page, do you mean?

If so, that figure is an average of all the 'rate' calculations for all samples every recorded that were discharging. On the watch, the rate shown on the main page is only the last four days max, more sensitive to the values in the last 24h. So that can change more dramatically I think.

[late tangle]

I see

I'm still surprised given that it would imply a 10 day battery life, which has not been my experience.

Even the "last week" rate in the website says 9% too

[rough token]

Looking at the graph, zooming on the last week, it does seem to drop 10% every four or so samples which is a day. Perhaps there is some math not adding up somewhere. I'll try and find some time to dig deeper soon into this case.

But on the surface, if the average is 10% per day, the simple math is 100%/10%=10 days. Integer math doesn't leave much more accuracy on the table. Probably something can be done about that too.

What figure would you put on actual days battery life from experience, if not 10 days?

[hollow nacelle]

(Unrelated. I’d like to sync more regularly without having to do so ad-hoc by pressing the button. Can the web page just have a button to force the phone to sync its data when it’s loaded in the settings page?)

(Realistically I’d accept it just auto uploading the data for you every X time it wakes up but I know that can be complicated with making sure the user knows what they’re consenting to exactly)

[late tangle]

The ~20% reported rate seems to match my experience, though I don't really let it go to 0%. But ~5 days does seem to match my experience, not double of that.

[snow lava]

micropebble + Pebble time, I just get this when I try to go to the settings page

[valid peak]

I think you need eight samples before you can upload anything for the page to display.

[snow lava]

Oh I see

[rough token]

Yep, and use the upload option in the Phone Sync menu once you do

[rough token]

There's a new Settings window row for auto upload once a day 👍

I wonder if waiting for the API request before opening the web page is feasible without the showConfiguration callback being killed or ignored...

[hollow nacelle]

Does showConfiguration have to send out a GET or is it freeform? The same route could take a PUT and return the resource on completion so you aren’t held up by a separate request externally. You’d have a side effect on show configuration but I wonder how far past you already are on the intention of configuration anyway.

[rough token]

You just tell the Pebble app which URL to open. I wouldn't be surprised if you have to do it immediately or get killed. I'll experiment

[hollow nacelle]

Oh yeah duh it’s a webview. Whoops

[karmic holly]

How IDs are generated to be unique? From the MAC address?

[magic berry]

probably this: https://developer.rebble.io/docs/pebblekit-js/Pebble/#getWatchToken

[rough token]

And then this
https://github.com/C-D-Lewis/pebble-dev/blob/master/watchapps/muninn/backend/lambda/src/handlers.ts#L37

[rough token]

I found a discrepancy in how the JS side average rate calculation is done, so I've added some function tests for that side of things and implemented a better way. Should be able to test it soon

[rough token]

@late tangle Hopefully this might make your drain rate figure a little better. For instance, my experience has been about 18-19 days, and my figure is now a lot closer (was 25)
https://muninn.chrislewis.me.uk/?id=C74FAA

Also we just crossed 100+ users with uploaded data - hopefully as they adopt this new version the global stats will increase in accuracy accordingly 🙏

[verbal sparrow]

new best ever segment for a watch on my wrist. 0% between 6am and noon today

Admittedly I was working sitting at a desk for most of that time with notifications mostly muted, but nice to know my new watchface isn’t eating battery

[late tangle]

https://muninn.chrislewis.me.uk?id=AE1C4C

I feel it's more accurate to my experience now

[torpid thunder]

Hello! Bit of a weird one - Muninn seemingly uninstalled itself overnight on both my old PTR and PTS. I’ve reinstalled now but have lost all my data.

[rough token]

I've seen 0% but usually overnight. Nice!

[rough token]

Sadly that will erase the app data. I wonder why the reinstall happened 😕

[torpid thunder]

It actually happened twice. First time yesterday afternoon. App had disappeared from the watch but was showing on the legacy phone app app list, but as a blank icon

So while it was still showing there as a blank icon, it was ALSO in the App Store with “Add” button available, as if I’d never installed it. So I installed it from there. Went straight back to position I’d had it.

When I woke up this morning it had uninstalled itself completely this time. Reinstalled it from app store again - this time it went to bottom of app list in legacy app, and I had to move it back to correct position

Weird!

[grim tree]

I get 0% fairly often when I partially charge the battery, which confuses the battery gauge

[deft vessel]

Idk why my muninn shows different stats between the watch and the web 🧐 https://muninn.chrislewis.me.uk?id=5B0F92

[rough token]

There's probably a C-based rounding discrepancy vs the JS code

The watch also has only access to last 4 days where as the stats on the config page are from all time and last 7 days

[rough token]

But the stats shown in the 'Sync to Phone' page in the watchapp should at least match those in the web settings page

[late tangle]

Actually, I think it might not be uploading automatically at 12 as configured

Given that the last sample in the app was on 31/3 in my case

[rough token]

Did you enable the new setting in the watchapp?

[late tangle]

Yes

[rough token]

Was the phone connected at 12:00?

[late tangle]

The phone should have internet access at all times

At least today I'm fairly sure both my watch and my phone were on me at all times

[rough token]

The watchapp signals the phone to upload the data. So if the watch wasn't connected just at that minute then it wouldn't work.

There's also a possibility that if the web request is in flight and the wakeup period ends (~3s) then the JS side is killed, but I have no docs or evidence to confirm or deny this. I'd treat is as 'best effort'.

I'll keep an eye on mine at 12:00 tomorrow as a sanity test but the logic is pretty clear:
https://github.com/C-D-Lewis/pebble-dev/blob/master/watchapps/muninn/src/c/modules/wakeup.c#L79

[late tangle]

I see, I guess I'll give it a few more days too

By the way, if I switch phones while still using the Core app with the same Rebble and Core credentials, would muninn keep the data?

[rough token]

That said, the next release I hope to publish tonight has a few key improvements:

• Use higher fidelity numbers to be able to represent partial discharge rates - meaning a rate change from 4 to 5 won't mean a swing in 5 whole days of estimated time remaining
• Attempt to update the web data when the config page is opened

[rough token]

No, it's all local on the watch and phone itself.

[late tangle]

I see

While I don't mind a reset

Wouldn't this create a problem for the global stats in the long run?

Given that same watch+different phone would create a duplicate

I'd say it's reasonable to believe phones might get switched out more than the watches

[rough token]

Each watch/phone just uploads whatever it has stored each time, to keep things simple. As long as the watch doesn't behave incredibly differently after the reset, its new contribution should be pretty similar in the grand scheme of things. Something to keep an eye on though...

[rough token]

My history was updated at 12 as expected

https://muninn.chrislewis.me.uk/?id=C74FAA

[trail veldt]

Not Muninn related, sorry, and don't have my PT2 with me but on my P2D I've noticed maybe since the latest firmware that watchfaces that show step count are displaying huge and incorrect numbers. Step count in Health is correct. Have logged a bug report.

[grim tree]

@rough token just saw - my data has once again been deleted

even more oddly, there are more than 8 samples on the actual watch

[rough token]

The number of samples in that menu is sent from the JS side before any new ones are sent from the watch. So it should be higher if you restart the watchapp.

Sounds like the phone data was the one lost. The only part of the app that does that is the "Delete All Data" option which I assume you didn't use. Did you switch watches or phones?

[grim tree]

Nope, watches or phones have not been switched

And yup, phone samples have now gone up to 17 (16 old ones on watch + one new one)

however, I was at above 50 before

[rough token]

Hmm. Well since there's no other functionality to clear data in Muninn, maybe it's bug report time.

I'm not aware of any routine expected scenario that clears phone data except uninstall and perhaps changing watch/device combination.

[grim tree]

Bug report to core? They'll probably be like "when does it happen" and I'll go "idk" and they'll be unable to help me

[rough token]

Hmm. There could be some event or error in the logs that would be included that might be a clue. I don't know what they log. But unfortunately it's likely some event or condition outside my control 😞

But if I'm wrong I'll be very happy to be able to fix it

[grim tree]

Could I ask you for a pretty big favour? Is there any chance you could cook me up a build that remembers the last synced items to the phone on the watch, then displays a popup with vibration if it goes down, so I can catch when the data gets wiped?

I totally understand if not of course

[rough token]

That should be pretty easy! Would in about 4 hours be okay?

I have travelling to do

[grim tree]

totally, thank you so much!

[rough token]

Thank you for helping out!

[rough token]

Give this a try:

t = dict_find(iter, MESSAGE_KEY_SYNC_COUNT);
const int sync_count = (int)t->value->int32;
APP_LOG(APP_LOG_LEVEL_INFO, "Sync: %d (%d)", last_ts, sync_count);

// Test compare with last seen value
const int temp_key = 5000;
if (persist_exists(temp_key)) {
  int last_count = persist_read_int(temp_key);
  // some value was saved
  if (sync_count > 0 && sync_count < last_count) {
    message_window_push("Phone count is less than watch count!", true, false);
  }
}
persist_write_int(temp_key, sync_count);

[grim tree]

it has been installed - an interesting note is that installing it seems to have wiped the phone data while the watch data is untouched (it now says 16 samples again)

[rough token]

Hmm

Keep an eye on it.

If there's a phone app change to wipe data if a sideload is installed, I haven't heard of it

[grim tree]

this build does appear to get stuck on "Muninn is taking a note" at least the first time, but I guess that's okay and will just give me a reminder to check on it and see if it misbehaves

[rough token]

I disabled the auto-dismiss, since it would show the new alert but the fact it woke to take a note would dismiss it perhaps before you noticed.

[grim tree]

ahh, okay!

yeah that works

[rough token]

Sorry, I should have mentioned

[magic berry]

i think this is lignite's error 420 as well

the data clearing thing

https://support.lignite.io/hc/en-gb/articles/44752963221908-Error-420-persistent-storage-lost

[rough token]

It's possible. No clue on the cause though.

[rough token]

Hmm, I guess after a certain size of gap the app should discard data...

Vs February here

[valid peak]

Hoo, that's a big gap.

[rough token]

It was dead on my desk for the whole of March...

[rough token]

In other news, dosed up on caffeine and mini eggs to write another detailed (read: waffling) blog post on the Muninn web platform journey
https://blog.chrislewis.me.uk/?post=2026-04-06-Muninn-Web-Statistics

[cloud cave]

Has anyone with a P2D ever got close to the promised 30 day battery? Mine always seems to be around half that. I don’t know whether there are further optimisations planned to improve this. Does anyone know?

(Even 15 days is still great, but it is significantly less than what was promised. It also makes me worry that the PR2 may end up being a lot less than its promised 2 week battery life which is more of an issue.)

[rough token]

I got over 21 when I was using my P2D before switching to PT2, and they have claimed to make perf fixes since then. I'm sure it's still being worked on.

[fast warren]

Mine still gets 20-25 day estimates

[trail veldt]

My P2D is hitting about 14 days yeah. I won't talk about my PT2 as I know my specific test unit has always had sub par battery

[hollow nacelle]

What’s up with 39 Pebble Time Steels averaging 19 days of battery life. What do I not know.

Are you throwing away significant outliers from that data table? (Not that it’s important that you are!).
Did everyone just replace their batteries and they’re all really good now?

[rough token]

I'm wondering that too. Before the recent update to tweak accuracy it was like 25 so something is gradually correcting. I'm not throwing away anything although I should probably do something intelligent before doing calculations. Something for a v2 after the contest is over (I'm cooking up another new watchface)

[cloud cave]

I have been away in Switzerland skiing and then in France for the last 10 days. I fly home tomorrow and charged my Pebble before leaving and I still have 2.5 days remaining. I didn't even bother to bring the charging dongle as I could see I would't need it (Thanks Muninn!). This is why I love Pebble again after years of Apple Watches that frequently did not last the day, particularly as they aged. You just don't have to think battery anymore.

[trail veldt]

Hah, same here @cloud cave - @rough token has created an app that meant I was able to charge my P2D before a ten day trip away and see that the predicted next charge slot was comfortably after I am due home so I didn't even bring the charger. A few days to go and the prediction has stayed rock solid with only minor variations.

[cloud cave]

Yeah, @rough token, Muninn has evolved into an indispensable tool on Pebble. Thanks for building it. I'm also loving the stats on the phone too.

[rough token]

Ah those are great stories! Thanks for sharing and glad it's helping 😁

[late tangle]

@rough token it seems my Muninn ID didn't change, though the web data did get reset. not a big deal usability-wise, the watch kept the latest data as expected. I'm not sure if this means there's a duplicate now or not for the global stats

[rough token]

Yes, the ID is unique per watch token which never changes. Therefore no duplicates. There is a mysterious source of phone data deletion but I have no other info or remediation to offer right now 😕

[karmic holly]

Does Eric have said anything about Muninn yet? He must find interesting the massive battery data you can get for each platform.

[rough token]

Not to my knowledge, but I probably wouldn't recommend it until I have some more detailed quality measures on the data collection, such as outliers as was mentioned earlier.

Plus I'm pretty sure the telemetry they already have is better

[karmic holly]

❔

The watches phone home?

[rough token]

I assume if this is enabled