Asset Tracker custom configuration fields not saving?

I’ve previously set up a custom configuration schema for one of my devices via the API (PUT to /products/{{ product }}/config/{{ device_id }}) and have used those custom properties successfully - they save and sync down correctly.

However, after adding a few new fields yesterday, I’ve noticed that the new fields do not get saved on the backend/cloud when I set them in the console, but the old fields still work correctly. If I “Save” the settings (and see the success message at the bottom of the page) and then reload the page, they revert to showing the default/empty values.

If the device is online when I click “Save”, the device will receive both the old and new fields, but if I reload the console page only the old fields will have updated and the new fields are always empty/default.

Am I potentially doing something wrong with my custom schema that could cause this behavior?

I’ve also tried removing both old and new fields from my section of the custom schema, Saving the configuration section in the console (with no fields), then adding the old and new fields to the schema again; after doing that the old fields retained their previous values (and still can be updated/saved ok) and the new fields still do not get saved at all.

For what it’s worth, I think I set up the older fields a while ago based on the public API docs, before the custom configuration was officially announced at Spectra; not sure if that would make any difference?

Thanks!

Hi Scott,

I wanted to let you know Particle’s engineering and support teams saw your concern posted here and were hoping to dig in further. Would you be able to submit a support ticket at support.particle.io and provide any supplemental information (such as screenshots/videos, if possible), as well as the email to your Particle email account that you’re experiencing these issues on?

Thank you!

1 Like

Alright, I think I actually figured out what’s happening. Looks like half of it was a bug on my end, and the other half seems like confusing/wrong behavior in the Console.

The bug on my end was that I screwed up the config definition on my device firmware by only specifying a set_cb and not a get_cb for the new property. This meant that my device would successfully receive a configuration change if it was online at the time (invoking the set_cb as expected) but it was not able to cache that config to disk locally and restore it upon restarting. I think this also meant that acknowledgements of configuration changes (from device back to the cloud) didn’t include that field at all.

The behavior that I think is confusing, and made this tricker to debug, is that the web console seems to display the “current” (i.e. acknowledged) configuration and not the “pending” configuration. So if you save configuration when a device is offline, the change is being saved (to the “pending” config), but this isn’t visible at all since only “current” configuration is shown, so it looks like the change didn’t go through.

So what happens is that any properties that are not implemented (or incorrectly partially-implemented as in my case) on the device firmware will never appear to save changes on the console since those changes can never become “current” (whether or not the device is online at the time you save them).

There’s also somewhat dangerous behavior caused by displaying “current” rather than “pending”, since all form fields are saved when you save configuration, not just the fields you’ve modified. If you change a property (say, setting sleep “exe_min” to 123) and save while the device is offline, that will become “pending”. However, if you refresh the console page and then go change another setting on another page (say, motion “high_g”) and hit Save, it will actually clear the pending “exe_min”->123 change you saved earlier, even though you never opened the Motion page of settings or had a chance to see that it had been reverted.

There’s some other odd behavior I noticed, where it seemed like all configuration fields were getting reset to defaults after some series of interactions on the console, but I haven’t been able to reproduce it consistently.

Just following up to see if there were any plans to change the behavior of the console so that pending configuration is shown instead of just acknowledged? Thanks