Setting changes missed when client stopped

Golioth Device Help
1

If I use golioth_client_stop() changes can’t be received since it’s offline. When I call golioth_client_start() any settings and states that changed when it was offline are not synchronized. Is there something I need to do in on_connect to force this synchronization?

Do the items below need to be re-called when the client is stopped and re-started?

   golioth_client_register_event_callback(client, on_client_event, NULL); // Register Golioth on_connect callback
   golioth_fw_update_init(client, _current_version); // Initialize DFU components
   app_rpc_register(client); // Initialize app RPC
   app_state_init(client); // Initialize app state
   app_settings_register(client);// Initialize app settings

If so, is there a way to force it offline vs stopping it? Would this be a good or bad idea? Would that fix this?

3

Hey @john.stuewe, on each connection, the device must initialize and register observations with the Cloud, which is usually done in the on_connect callback. This sprint we are working on improving the functionality by automatically re-establishing observations on re-connection.

4

Do I need to call fw_update and rpc_register as well? There isn’t a single example from Golioth where it disconnects and re-connects which is frustrating.

5

Yes, you need to call fw_update and rpc_register. All Services that register observations with the Cloud (OTA, LightDB State, Settings and RPC) must register them if they are to be used.

The reasoning behind this behavior is that a device should be able to wake up, send a sensor reading to LightDB Stream and go back to sleep, without the overhead of registering observations.

We are working on improving this functionality and on expanding our examples; every feedback is welcomed!

6

Got it. Thanks. I’ll keep my eye out for examples since I can’t seem to get it working properly.

7

My system reboots every 7th cycle when I register fw_update and doesn’t when I don’t register it. I"m testing SDK 0.12.1 and it seems to stay registered. Do I need to re-register anything with SDK 0.12.1?

8

Hey @john.stuewe, as you noticed, we released v0.12.1 of the SDK where we addressed the re-establishing observations after reconnect after internal discussions.

With the version v0.12.1 onwards, my comment from above isn’t valid and there is no need to reestablish observations on each connect.

You can use the start_golioth_client function from the Reference Design Template as a reference, where observations are set once in the application and are reestablished on each connect in the CoAP client as of this commit.

I understand this created confusion as we wanted to discuss internally what the best solution is.

To summarize, from Firmware SDK v0.12.1, observations are reestablished on each reconnect by default and there is no need to set them again in the on_connect callback. We are also working on deinitialization methods to allow users to cancel observations and release memory if they choose to.

9

Hey @john.stuewe, are you still experiencing this issue, or did the Golioth Firmware SDK release v0.12.2 solve it?

10

I’m fairly certain it did but I’ll need to confirm that next week.
If I connect and then disconnect quickly it definitely doesn’t though.
What is the method to determine when observations and FW update checks are completed so it’s safe to disconnect?

11

Hey @john.stuewe, the observations are re-established once the program enters the CoAP I/O loop in the CoAP client thread.

If you connect and quickly disconnect, then most likely, there won’t be enough time to re-establish observations, and it doesn’t matter since you want to disconnect the client anyway.

If you need to track changes in the firmware update process, you can create a callback:

/// Register listener for FW update state changes.
///
/// This is useful if your app needs to react or track changes
/// in the state of the FW update process (e.g. DOWNLOADING, DOWNLOADED, etc).
///
/// @param callback Function to be called when a state change happens
/// @param user_arg Arbitraty user argument, can be NULL
void golioth_fw_update_register_state_change_callback(
    golioth_fw_update_state_change_callback callback,
    void *user_arg);