The logic of the config_dirty and config_received resources

Octave
1

Hi!

I am working with Sierra Wireless FX30S gateway and firmware 3.2.0.rc4.

I was delighted with the new functionality in firmware 3.2.0.rc4, which allows me to determine the moment when the blueprint changed. For this, the “cloudInterface/config_received/value” resource is used. I need this functionality so that when a new blueprint is applied to a gateway, a script will run on the gateway that will fill my non-configurable virtual JSON-type resources with the structure I specified. This, in turn, is necessary so that when the gateway is rebooted, the value of my non-configurable resources is not reset.
While testing this functionality, I found that with any change to the blueprint, the “cloudInterface/config_received/value” resource fires as expected, but it also fires when the gateway is rebooted, which is not desirable. When I reboot, I need to save the contents of my virtual resources, but because of the “cloudInterface/config_received/value” resource fires, I lose the contents, as I create the JSON structure of these resources anew.

The resource, “cloudInterface/config_dirty/value” is not described in the documentation, but, as follows from the name, it must fires when the gateway configuration is different from the blueprint. When testing, I found that the logic of its operation is reverse, it is triggered when the device configuration matches the blueprint. And its meaning is always equal to the false. Is this a working resource and how to interpret it correctly?

2

Hi Vitaly,

I will do a bit of testing on the behavior you describe. with the config_dirty. That value is as you would expect, the device configuration does NOT match the blueprint.

I agree with you that the cloudInterface/config_received/value” resource should not be triggered on reboot unless there is a true change to the blueprint that would be loaded on a reboot.

1 Like
3

Hi Vitaly,

I tested

  1. config_dirty. .
    True - when the device is out of sync with Octave configuration
    False - when the device is sync’ed with the Octave configuration

This works as designed

  1. cloudInterface/config_received/value
  • This trigger fired correctly when a blueprint was received and applied on the device.
  • The trigger did not fire on reboot when the device was on the “current” blueprint.
  • The trigger did fire on reboot when the blueprint was not “current” and a blueprint send from Octave was pending.

It seems this works as designed as well.

4

Hi David!

I checked the “cloudInterface/config_dirty/value” resource again and now it actually works.

And the resource “cloudInterface/config_received/value” continues to fire when the gateway is rebooted.
To demonstrate this, I’ve taken some screenshots.
The first screenshot shows the time when I triggered a forced reboot of the gateway.

изображение
изображение1655×532 44.1 KB

The second screenshot shows that the gateway configuration was initially clean, that is, matched the blueprint (time 07:59:40). Then I rebooted the gateway three times and the “cloudInterface/config_received/value” resource fires three times, which ran the script that wrote the “New Configuration” message. Then I changed the configuration of the gateway so that it did not match the blueprint, that is, it became dirty (time 08:12:02). And again I rebooted the gateway three times, and again the “cloudInterface/config_received/value” resource triggered three times.

изображение
изображение1648×792 65.4 KB