As you may have noticed, Google is planning to discontinue the Nearby Notifications. This means that the 1.2.12 firmware which currently ships with button-activated mode change into URL-mode will be obsolete.
As our user base has grown we have received some great feedback, now would be a great time to address the ideas for next software version.
Should we bring the 2.X branch / GitHub master out of beta? So far I havenât heard anyone saying that theyâd gone back to RAWv1 or URL mode after starting to use the RAWv2 format.
On the other hand, a lot of users are perfectly happy with RAWv1 as it is, and update would probably break some existing applications.
Battery measurement: Current battery voltage is not a great predictor of remaining runtime, especially in cold temperatures. It seems that we could get better results by synchronizing the ADC to radio transmissions.
Button: Current process to enter bootloader by holding down button B while tapping R is a bit cumbersome. Maybe a long press on button âBâ could trigger a reset and start tag on bootloader?
Button: As the URL mode is no longer useful, what kind of action a short press should trigger? Switching between RAWv1 and RAWv2? Fast mode and long-life mode?
GATT: So far the GATT profile which ships with 2.2.2 has caused more confusion than new use-cases. GATT-connectible devices show up on bluetooth scans for headphones etc which some users find annoying. Thereâs also a security concern on allowing DFU updates without physical access. Have you used the GATT profile for something, or should we disable it by default?
NFC: Some kind of NFC event when the NFC field is weak can lead to a hangup in NFC driver and lead to increased current consumption. Weâre investigating how to fix this issue.
Please let us know your thoughts on these matters as well as anything else youâd like to see
Should we bring the 2.X branch / GitHub master out of beta? So far I havenât heard anyone saying that theyâd gone back to RAWv1 or URL mode after starting to use the RAWv2 format.
On the other hand, a lot of users are perfectly happy with RAWv1 as it is, and update would probably break some existing applications.
Iâd bring it out of beta and make the RAWv2 the new default, something will always break eventually so itâs not that big of a deal. A bigger issue/risk in my opinion is the âWindows XP syndromeâ where something old and obsolete stays the ânormâ for so long that developers start to assume it will always be like that and take shortcuts and/or hardcode stuff, rather than taking future updates and compatibility into account
Button: Current process to enter bootloader by holding down button B while tapping R is a bit cumbersome. Maybe a long press on button âBâ could trigger a reset and start tag on bootloader?
for this idea, long press of B should just reset the tag, and having B pressed while booting should enter the bootloader as it is now, that way people can still keep using the âold wayâ
Button: As the URL mode is no longer useful, what kind of action a short press should trigger? Switching between RAWv1 and RAWv2? Fast mode and long-life mode?
GATT: So far the GATT profile which ships with 2.2.2 has caused more confusion than new use-cases. GATT-connectible devices show up on bluetooth scans for headphones etc which some users find annoying. Thereâs also a security concern on allowing DFU updates without physical access. Have you used the GATT profile for something, or should we disable it by default?
In my opinion itâs better to disable it by default but have a convenient way to enable it if someone needs it. Having it enabled by default serves no purpose for users who donât need it or even know about it, and will just result in lesser security as well as worse battery life if the tag needs to be listening for connections
I would mostly support what Scrin said. Hell yeah, go ahead, break things⌠(;
About the usage of buttons: Would it be possible to have some sort of factory reset, maybe by pressing/holding buttons while powering up? The hardware of the tags is so versatile, there will probably never be one-size-fits-all sort of firmware, so it should be easy and inviting to experiment with different firmwares. On the other hand, flashing a firmware always feels a bit scary and risky, especially for beginner to medium level users, when updating ota, and without access to a devkit.
So having a reliable way to undo whatever can be done to a tag with ota updates would imho really help.
So ideally resetting would:
re-instantiate the default firmware (like a from a shadow firmware - i think we see this more and more on IoT devices these days)
or, if this not possible (e.g. because of size), at least erase the last otaâd firmware und put the tag in a mode where a new firmware can be reliably otaâd
erase all data and stuff (i still have tag around that âmagicallyâ acquired a name while playing with firmwares which it is not willing to forget ;))
Interesting ideas. Having an âactualâ factory reset would require âbundlingâ the âoriginal firmwareâ with the bootloader, which would increase its size, though as far as Iâve understood the firmware size is rarely an issue on ruuvitags so it could work I guess.
On the other hand a âfull eraseâ feature on the bootloader would be useful, if its possible. It has been observed numerous times in the past how leftover data from previous firmwares have caused odd issues with new firmwares, which have been often resolved by either fully erasing the tag with a devkit, or flashing a special âerasing firmwareâ first and then the intended firmware after that, which is probably not the best experience for inexperienced users
Regarding âchange / break thingsâ remember that this is not a web application, nor is it a phone/tablet app where once a change is made everyone getâs it. Users only get ânewâ code when they specifically install it. Unless they are adding to their fleet of tags and they already have old code.
Why not have the tag support BOTH RAWv1 (aka 03) AND RAWv2(aka 05) formats! Use button to cycle through formats. The version I am currently using supports several formats.
Having a complete factory reset would be somewhat tricky and it would reserve quite a bit of flash which would be a problem for the Espruino.
Bootloader itself remains as it was unless user explicitly overwrites it, and it can always be entered by holding down âBâ at boot. There are some corner cases which prevent the bootloader from operating properly, but those are generally not repeatable.
This specific case is probably caused by your receiver Bluetooth hardware, at least my Mac remembers last name it has seen on a tag even if I stop broadcasting it. Erasing all stored data, especially Eddystone settings would great though - right now there is no way to recover a forgotten Eddystone password on a tag as the settings are stored on location which does not get overwritten.