Bangle.js2 - Notification-strings in messages not displayed properly anymore about espruino HOT 5 CLOSED

Ok, thanks! Yes, I think this is related - Gadgetbridge took a few shortcuts to try and transfer data as efficiently as possible - one of those was sending characters in the unicode range directly rather than encoding them with \u.... I'll have to do a new build of Gadgetbridge that doesn't do that.

But I'm actually struggling to reproduce using the Gadgetbridge debug button and sentences containing ü and ö. Do you think you could include a section of the Gadgetbridge log where one of these messages is sent? Or even better just find some text you can put in the Gadgetbridge debug menu (and then press send) that reproduces this and then paste it in here?

Also, do you have Text as Bitmaps or Transliteration turned on in device settings in Gadgetbridge?

from espruino.

Thanks for the very quick response. Using the debug menu I could reproduce something similar, although not exactly the display as it comes from a GMail notification (ie only one strange char and no rubbish after the end of the notification). But maybe this can already be helpful.

"Text as Bitmaps" is turned on, "Transliteration" (if this is the english equivalent of "Sonderzeichen umschreiben") is turned off for all available languages. Should I try to change something there?

I also include the logfile I created for that result: gadgetbridge.log

The text I entered in the Message box was: Fön Kür Bär, which showed up the following way on the wrist:

Can I test or try something more?

from espruino.

Thanks! No need for Transliteration. This is really odd though.

If you connect with the Web IDE and when you're in the messages app and you paste in:

GB({t:"notify",id:1686681366,src:"Bangle.js Gadgetbridge",title:"",subject:"Fön Kür Bär",body:"Fön Kür Bär",sender:"Fön Kür Bär",tel:"Fön Kür Bär"})

Do you have any problems?

Or what about:

Bluetooth.inject([0x10,0x47,0x42,0x28,0x7b,0x74,0x3a,0x22,0x6e,0x6f,0x74,0x69,0x66,0x79,0x22,0x2c,0x69,0x64,0x3a,0x31,
0x36,0x38,0x36,0x36,0x38,0x31,0x33,0x36,0x36,0x2c,0x73,0x72,0x63,0x3a,0x22,0x42,0x61,0x6e,0x67,0x6c,
0x65,0x2e,0x6a,0x73,0x20,0x47,0x61,0x64,0x67,0x65,0x74,0x62,0x72,0x69,0x64,0x67,0x65,0x22,0x2c,0x74,
0x69,0x74,0x6c,0x65,0x3a,0x22,0x22,0x2c,0x73,0x75,0x62,0x6a,0x65,0x63,0x74,0x3a,0x22,0x46,0xf6,0x6e,
0x20,0x4b,0xfc,0x72,0x20,0x42,0xe4,0x72,0x22,0x2c,0x62,0x6f,0x64,0x79,0x3a,0x22,0x46,0xf6,0x6e,0x20,
0x4b,0xfc,0x72,0x20,0x42,0xe4,0x72,0x22,0x2c,0x73,0x65,0x6e,0x64,0x65,0x72,0x3a,0x22,0x46,0xf6,0x6e,
0x20,0x4b,0xfc,0x72,0x20,0x42,0xe4,0x72,0x22,0x2c,0x74,0x65,0x6c,0x3a,0x22,0x46,0xf6,0x6e,0x20,0x4b,
0xfc,0x72,0x20,0x42,0xe4,0x72,0x22,0x7d,0x29,0x0a])

That should send over the exact bytes that Gadgetbridge sent to your watch. Does it happen?

So... as far as I can tell this happens when the messages get saved to Storage (so it's a Bangle.js firmware issue). If you have a fast-load clock face (or you're on the messages app) then the messages are never saved and are actually ok.

from espruino.

Ok, I'm not very experienced with the WebIDE yet but thanks for the hint with having the Messages app open when a notification arrives (can also do via Debug-menu in App or sending a mail to myself), this has led to some interesting results. Following screenshots and descriptions of their cause and content:

This screen shows 3 messages. The topmost one was received while having the Messages app open, the middle one was received just before opening the Messages app and the bottom one is an older one from prior tests. This one has looked differently previously but seems to have been mangled over time.

This is the screen that shows up when I'm still inside the Messages app and a new mail with umlauts arrives at that moment.

Then I leave the app, go to the watchface, let the watch lock itself and turn the backlight off. After a minute I activate it again and open the messages app again and it looks like this:

With those results I somehow suspect that each time a new message is received, also the older ones get re-written and modified again, messing them up more and more over time. This would also support your suspicion @gfwilliams that it's not the notification itself but rather the process of storing/loading it to/from internal memory.

from espruino.

Thanks! Yes, that sounds very likely. It seems that the process of reading Unicode and then writing it back is causing problems.

I've finally fixed this, mainly with aa64b17 - but it turns out there were a whole series of issues:

• Gadgetbridge isn't sending UTF8, but some of those characters can be interpreted as UTF8
• When writing to JSON, the spec says we have to use unicode escapes even if the chars aren't unicode, so then when reading the JSON file the resulting strings are UTF8
• Finally wrapString (and join/split) didn't like Unicode strings very much. I'm sure there will be other issues as well.

But, finally, I think it's fixed, at least in this case!

There are more issues I think where we add UTF8 string together, but I'll fix those next week

from espruino.