So actually when programmable is off, Gadgetbridge isn't ever able to set the time! So from that point of view a time event would be a big improvement, and does at least allow us to send extra data in a more obvious format than a flat array.
Having said that, if we can actually send enough data to the Bangle to get it to always update the timezone correctly (rather that once) I feel that is a real improvement.
setTimeZone getting disabled is a pain, but it needs to be done to make widdst work with Gadgetbridge (at the moment). However maybe a better option is to make setTimeZone disable setDST when called, and to then put setTimeZone = function(){} into widdst - having the same effect, but being reasonably easy to undo
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
Yes, the service sounds like a good idea - then it's pretty easy to 'opt in' as you say (at least if you're using Gadgetbridge).
One reason for sending the time event, which I didn't elaborate on, is that when the Bangle is in
programmable:false
mode it doesn't accept commands on the REPL, only theGB({...})
formatted lines: https://github.com/espruino/BangleApps/blob/master/apps/boot/bootupdate.js#L46-L55So actually when programmable is off, Gadgetbridge isn't ever able to set the time! So from that point of view a time event would be a big improvement, and does at least allow us to send extra data in a more obvious format than a flat array.
Having said that, if we can actually send enough data to the Bangle to get it to always update the timezone correctly (rather that once) I feel that is a real improvement.
setTimeZone
getting disabled is a pain, but it needs to be done to make widdst work with Gadgetbridge (at the moment). However maybe a better option is to makesetTimeZone
disablesetDST
when called, and to then putsetTimeZone = function(){}
intowiddst
- having the same effect, but being reasonably easy to undo