Search results for:

sadly, nope.
I tried cleaning with alcohol and using a hot air rework station to try to re-solder the microcontroller; but the problem persists...

in the next few days I'll try the hot air again, I'll dare a little more with the heat, until it holds up.

I cleaned the whole board but nothing, same problem.
doing some calculations and tests I found that a 150 ohm resistor between the button pin and 3.3v solves the problem (it means that the pin is "short" to gnd with around 400 ohm); the problem is that it consumes about 6/7 mAh... too much...
I'll try cleaning the board again and maybe reflowing the chip with a hot air gun...

-

-

always 0.09V
with pinMode(BTN, 'output'); it jumps to 2.7V
pinMode(BTN, 'input_pullup'); -> 0V
pinMode(BTN, 'input_pulldown'); -> 0.09V

the pads on the PCB look a big dull (although that could just be lighting)

from another angle/light it is actually clean. I'll try to clean it anyway.

How old is the watch?

1 year

being pulled up to 3.3v via an internal pullup

this is the strange thing, reading the value between GND and the button pin with a tester I detect a voltage of only 0.09V (no it's not a typo)

There is a vanishingly small chance that the unpopulated component you found could be an optional pullup resistor

I look at this here: https://www.espruino.com/Bangle.js2+Technical, it seems that the component is also missing.
and in any case given the proximity it should be a component of the compass.

you can effectively disable the button

yes, I've already tried, it works but I'm trying to understand if I can get it to work again without using the "tap" trick

does the board look corroded in any way?
nope, I'm attaching an image even if my smartphone sucks a bit...
I also disassembled the rear part and there are no signs of humidity or corrosion.

the last time it worked, I used it in a cold environment but considering that it was always worn and under the jacket, I don't think it ever went below 10°C.

I only noticed one thing, in the part "circled" in red, there seems to be 2 soldering points but there is no component.
is it missing or is it correct like this?

Sorry if I reopen an "old" post, but I have the exact same problem:
clock in bootloop because it detects the pressure of the BTN1.
since the button "seemed" stuck, I already opened the watch; only that even if you physically remove the button, the board detects it as pressed.
I then tested the button with a tester and it works fine.
what could I do?

do you want to be able to handle/display messages without them even being stored on the device? Do you still want to be able to store some messages? Or do you not want to store any?

The more I think about this, the more I feel like we could have one messages library that all apps can interact with to add/remove messages. But we make sure that library can be implemented by any app that wants to (eg like sched or textinput)

that's exactly what I meant, move all the logic ( saving messages, managing music... ) to an app/library/... and move the GUI to a separate app (perhaps with an app type like for example "clock" )
to make everything more compatible I thought of using events, so as to be able to manage each app independently, but I see that we don't really like that idea.

I believe this "library" should provide the basic methods which can then be used and configured by the user / by whoever will program the GUI.

for example I find it "wrong" that the pushMessage automatically saves the messages that arrive; I believe that the two things ( message management / message saving ) are 2 separate things and the library should give the possibility to use the two functions separately.

( PERSONAL OPINION: I find that the management of saves, views, etc via "handled"/"noMessageApp" is confusing and in the long run difficult to manage, maintain and document correctly; but I repeat it is a PERSONAL OPINION )

By having the event, we potentially end up in a situation where we have multiple apps storing the same message in different ways. And then if you delete the message on one app, it's not deleted in the other one.

however it could also be that different apps need to store different types of messages and therefore not centralize everything in a single list... mine are just hypotheses

For example right now we have require("textinput") - but textinput can be provided by any different keyboard app. Or require("sched") - we have a default scheduler, but any app can implement a new one. It's simple, it's fast, and efficient. I don't really see the issue with doing this for messages too.

this methodology for me has a "problem" (I'm not saying it's serious but more "annoying")
when you install the Android/IOS app, the messages app is also installed from the dependencies; at this point the user can also install the app he wants to view the messages which will overwrite the "messages" file by inserting his own code so that by calling require("messages") the custom app is called.
now in the custom "messages" file it is necessary to reimplement all the pushMessage,clearAll, getMessages, status, buzz, stopBuzz functions going to create a duplication of the code.
having overwritten the original "messages" you can't even recall the functionality of the other file.
(premise: I'm not sure about this point, I haven't done any tests) if the original "messages" app is updated, does it overwrite the "messages" file and therefore the custom app should be re-installed?
and even if you uninstall the "message" app, when the "Android/IOS" app is updated, for the dependencies the "message" app is also reinstalled (overwriting the files)?

in theory, these problems could be solved (at least partially) by providing a specific type of app for displaying messages. (I saw that the "notify" type exists but from what I understand it's an "old" method for handling notifications, right? )

TL;DR;

• create a library with the common features -> yes, perhaps providing more functions but which allow greater customization
  
  

a way to split off the GUI parts to different apps/files

• it is already done automatically with the creation of the library
  
• the methodology of overwriting the "message" file (or any other file) -> I think it needs an improvement to work smoothly (I'm talking more about user experience)
  
  
  

PS: with @rigrig 's suggestion i implemented a message app which i'll ask for a PR.
I overwrote the require function to make everything work; I don't like it, but it would seem to work.
PPS:

although nobody is yet to make a PR to actually just improve the standard message app :(

I think the problem is that everyone would like an ad-hoc app, and honestly I wouldn't want to touch the GUI/functionality of a program when others like it, I prefer to implement my own version.
But if there are shared choices and you need a helping hand, work permitting, I'm here :)

hello, i have the same problem with iconlaunch and rebble.
rebble I know it's a mess and should be fixed as suggested by @Ganblejs but,

@Gordon

The fast loading won't work if the clock doesn't have widgets

does this mean that the fastload ( Bangle.showClock() ) will never work with full screen clocks?
and if so, how does the launcher know which load to use to avoid problems?

sorry in advance if I misunderstood

since at the moment there is another PR who is modifying the app message ( https://github.com/espruino/BangleApps/pull/1498 ) and who is implementing some sort of events; I would say that it is useful to understand how to proceed (so as to avoid writing unnecessarily code )

It feels rather hacky, but it works

yes it works, but I don't really like the approach... I think that keeping these methodologies leads to some apps struggling to communicate with others in the end.

At this point I would override the "require" function so as not to directly load the "message" library (and its pushMessage )

Obviously it's a draft but there are some issues I can see...

yes yes, I know there are some problems, before continuing I wanted to know if the methodology could be good.

It would solve the 'handled' issue

that's more or less the solution I was thinking of (and which is currently implemented as a workaround in the "message")

I'd be inclined to push call through the same message event too

at the beginning I had implemented only one event; logically it seemed clearer to me to divide it ( message, call, music, other... ).
It actually consumes slightly more ram; I might go back to the "old" method. (only the "message" event for all )

So why are we doing this?

certainly a more "open" program uses more resources but I think it's more convenient, in a modular environment like this, to manage the various apps as separate things.
write, hardcoded, that an app calls another app ( require("message").pushMessage directly from the android/IOS app )
it means creating a bond that goes against the logic of apps.

the point is to try to understand if we want to implement a logic where multiple apps can manage various types of messages, or if the "notifications" world must be closed (it is true that everyone can implement their app as they see fit, but this means code fragmentation and poor management/updates).

I think so:
android/IOS raise an event -> any app can handle it
(the "official" message app is capable of event handling).

Does it save memory?
not directly, it depends on the implementations:
currently my version of message is lighter than the official one because it doesn't store messages in mass memory and has a "cleaner" UI with fewer settings.

if, on the other hand, we don't want to give the possibility of managing notifications to multiple apps, it would be convenient to be able to change the app that is called by the Android/IOS app

give the possibility to write the name of the app to be called in the "android.settings.json" file (by default it would be "message") and then replace the occurrences with:

require(settings.appName).pushMessage(event);

so that if one wants to implement his own app he could do something like this:
in the settings of the app create a button like "set me as message manager" which calls

require("android.lib.js").setAppName("my_custom_app.js")
//( or IOS )

all apps should work as usual and you would have the possibility to manage messages with any app (if desired, the custom app could still call the require("message").pushMessage(...) )

let's say this solution is a hybrid.

it shouldn't add any boot code, just an additional variable in the "android.settings.json" file (which is already read during boot so it doesn't slow down / take up more space)

splitting out the GUI

it was an idea, but perhaps much more complex to apply and which made everything even more restrictive in some respects.

PR: https://github.com/espruino/BangleApps/pull/2274

Thanks to all for the immediate response!

metadata.json is documented in the BangleApps README

@rigrig that's where it was! I seemed to have seen it months ago but I could no longer find the reference!

Hi, sorry for the question, I see in the last pull requests that functions such as Bangle.load and Bangle.showClock have been implemented.
The problem is that I can't find any documentation about it; i used to look in the espruino docs ( https://www.espruino.com/Reference#software ) but it seems to be out of date.
Among other things some time ago I was looking for the documentation on the file "metadata.json" and I could not find anything.
Am I wrong where to look or the documentation is out of date?

a premise:
the message is long and I helped myself with google translate for some pieces, I hope there are no blunders!

I was thinking more of an app that manages the receiption of the message, (saves in the storage, sets the additional parameters to the msg, etc.) and another that ONLY implements the show functions
(showMessage, showMusic, showMap) which obviously are recalled if necessary by the first.

Actually these days I was thinking about it, especially the optimization speech and two ideas came to mind that could be used (at least partially):
1)

to manage everything in events, it is not necessary to move all the code during the boot phase, but only the "pushMessage" function which at this point could be cleaned of all those references to the actions to be done (load message, turn on the screen, etc.) leave only the code that "understands" the type of message and launches the appropriate event.

The message app, (or who will intercept the event) will not necessarily have to load everything in the boot, but something similar will suffice

Bangle.on ("message", msg => {
eval (require ("Storage"). read ("myMessage.app.js")) (msg);
}
(I don't know what the performances could be; I should do some tests.)

so in the boot area only a few references will remain and each app will manage the events independently.
(obviously the message app will also register for events like all other apps)

we would only have to think about a question of "priority" and handling of the event, but I think that is the least of the problems.

the advantage of this methodology is that multiple apps could register and handle the same event (for example an app that tracks a specific notification, along with the standard messsage app)

2)
if instead we want to keep the performances to the maximum, then we could:
leave the Android / IOS app as it is
structure the message app in a similar way:

• message.core.js (containing all the message app logic, getMessages, buzz,...)
  
• message.GUI.message.js (containing only the showMessage function)
  
• message.GUI.map.js (containing only the showMusic function)
  
• message.GUI.music.js (containing only the showMap function)
  
  

When loading the app from the appstore, we can merge all these files to create a single file that works exactly like the actual message app.

we could therefore think of a way to "choose" the GUI part that you want to install (such as customizing the app from the AppStore, or a separate app that does the same procedure during installation).

I know it's a bit of an overkill but it should allow you to logically divide the "graphics" from the "code" without practically affecting performance (the message app would work exactly as it does now)
I doubt however that this method could be a bit "tight" in some applications

Phone -> android/ios -> message library -> (custom app || message app)

I believe this can be a good solution.

absolutely nothing stops you from forking the app loader and providing your own messages app implementation (or even a separate app that overrides some functionality).

you are right; this is the solution i am currently using.
the problem is that in order to have different graphics, a lot of code is duplicated between the apps, making it very difficult to maintain them. (I currently have a modified version of android and message, "updated" a few months ago).
I think it can be an interesting thing to divide the logic from the graphics in order to further customize the device.

another solution (a little less event-driver, I don't know if you like it) is to divide the graphics from the logic into 2 separate files (or something similar) in the message app; the graphics file could be a standard name (message.GUI.js) and so if everyone wants to customize the graphics, they could "just" write their own app, which overwrites that file.

sorry, english is not my mother tongue and i may have missed something.
Currently I have seen that the emit of the "message" event is done by the "messages" library and if no app "manages" the event, the library itself calls the display of the message through its own code.
so something like this:
GB -> Android -> Message -> custom app

Couldn't you implant the message event emit directly from the Android app?
It would then be enough to modify the Message app by implementing listening to the event (Bangle.on ("message", ...).
and have something like this:
GB -> Android -> (Message || custom app)
In this way the management part of the event is disconnected from the graphic part;
it is up to the installed "message" app (custom or not) to bind to the event and manage it and not to the android app to call the program "statically"

hello, I get involved in the discussion.
a while ago I was trying to do the same thing and make it "legacy".
in the end I decided to modify the android app and message to make everything work the way I like it (like the pebble notifications) and I never published it.
With the latest updates I have seen interesting things and I wanted to try to rewrite the message app so that it works with the new version of the android app and the new features.
If you want, @Sir_Indy we can work with it (it counts that the graphic part, unless modified, is already partially functional)

attached an example of notification (with long texts, the text can be scrolled by tapping at the top or bottom of the screen)
To exit the notification just click the physical button

Thank you for the link!
if I am not mistaken then it is gadgetbridge that does not have internet permissions and from here https://github.com/espruino/BangleApps/wiki/Bangle.js-2-Status
I saw that the version with internet enabled should be on the way (January 2022).

Couldn't find any other info, so the internet-enabled version I guess hasn't been released yet ...

is there a way to make GET / POST requests from bangle.js to web services and get the result on the smartwatch?

I searched a bit through the documentation and the gadgetbridge code but couldn't find anything about it.
I only found a post in which it is said that there is the intention to create a dedicated app and implement this functionality.

if anyone is interested I could try to implement a library on bangle.js and the necessary code on gadgetbridege ...