Most recent activity
-
realistically all you care about is maybe 40 bytes of data
In my case, I need, if efficiently packed before being sent to the watch, about 400 bytes, representing 48 hours of weather data.
I think in an ideal world, I would have a small program on the phone side (perhaps an embedded Espruino interpreter?) that handles the packing of that data, and then forwards the 400 bytes back to the watch. I think this is basically what "pebblekit for javascript" was designed for, though I don't think anything like that is implemented currently in gadgetbridge?
-
Thanks! Yeah, that's in my plans. Maybe swipe in different directions to see different data views? Though this won't be in my initial release, I want to get the basic functionality out first, what is seen in the screenshot.
I'm still working on some issues. Primarily related to high memory usage (to store the weather data in RAM as I only want to write when the clock exits to save on flash wear), and the large transfers for the OpenWeatherMap API sometimes cause issues.
The available free OpenWeatherMap APIs are a little problematic for the watch if you want a proper hourly forecast. See, either you use the "One Call 3.0" API which gives you everything in one go, which is rough on the memory-constrained watch, or you can use their free-tier "proffesional" API, which lets you limit the number of data points you receive, but only gives weather in 3 hour increments (compared to the 1 hour increments in the 3.0 api).
I think I can improve the memory situation somewhat, though it's still going to use quite a significant amount of memory (I doubt bangle.js 1 will be able to store the forecast).
-
I've seen both actually, though the memory_busy seems to come up if it has been idle for a while.
I read another post of yours explaining memory_busy:
MEMORY_BUSY happens when something is happening to the variable store >which keeps it busy (that usually means garbage collection) and a new variable >is requested from inside an interrupt.
In my code, each time the weather is updated, I have to create some fairly large objects: first parsing the JSON http response, then cherrypicking the interesting data from the JSON into my own structure. Could this be what is triggering the garbage collection? I probably need to switch to a more efficient way to store it, like you describe here: http://forum.espruino.com/comments/14667057/
For the FIFO_FULL, I already had "increased MTU" turned off. What branch is it on? I wonder if we could improve the transfer efficiency for APIs with JSON responses (what I imagine most people are using Bangle.http for) by either heatshrinking them and/or pre-decoding the JSON within GadgetBridge and transferring the equivalent of a Python pickle?
-
Did this patch make it in?
I'm seeing this error when receiving large http responses (16-20kB) from the openweathermap api through gadgetbridge.
-
I'm working on a YWeather remake for Bangle, using open weather map as the backend. Here's a picture showing where I'm at right now.
Right now I'm working on integrating "My Location" for the location source. I also still need to actually make the weather icon reflect the current state outside. I also haven't yet implemented the extra weather information you get on YWeather when you flick the wrist
The temperature and time/date reporting is working, and stores 48 hours of weather forecast so it can keep going for a while even if it loses connection.
-
I'm working on a weather watch face similar to YWeather for pebble, using open weather map as my backend. It's not ready yet but is coming along nicely.
Yeah, and it would certainly be more flexible. Imagine any sorts of tasks that would take a prohibitively large amount of ram or processing time if done on the watch. I think what we're describing here are what remote procedure calls are? Maybe we could leverage an existing RPC framework?
The reason I suggested embedding espruino was for the superficial benefit of having the same internal representation of data in both the phone and watch, though that small benefit is erased if we're serializing/deserializing the messages in a separate lib.