Search results for:

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.

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.

I'm sure this has been brought up before, but are there any plans to allow the banglejs to use gadgetbridge to request the location? Or has this feature already been implemented? A quick search on these forums turned up no discussions, perhaps they were done elsewhere.

I want to be able to get the location for a weather app without using the onboard GPS, as it doesn't work well indoors and seems needlessly power hungry when we're already connected to a phone. If I'm downloading weather data from the internet with Bangle.http, then the phone defacto also has location services turned on, which we could use.

I considered using a geoip service, but all the free ones I've found (that actually work) either have very low API limits, or require HTTP, which isn't enabled in gadgetbridge.

I think I found the answer to one of my questions. The modules directory is for modules developed by people who've published to the BangleApps repo.

So the next logical question is, how does the app loader know that it needs to load a module? Is there some code that scans for "require" calls, I'm guess? I don't see it get defined explicitly...

I see a really nifty-looking module in the BangleApps repo called ClockFace.js (https://github.com/espruino/BangleApps/blob/master/modules/ClockFace.js) that says it can take care of a lot of clockface boilerplate. When I try to require it though, it says it can't find the module.

How do I go about including this? Should I upload the file to my watch, or is it included in the firmware already somehow like Layout.js (which happens to be along side it in that repo...)? Is this a staging area for modules that are going to be added in a future firmware release, or am I becoming very confused?

And a related question, how can I list the built-in modules that are available to be required? For example, I don't see Layout.js listed in the files loaded on my watch, yet I can require it.