Hi,
My FX30 runs on battery (256 Wh) and in order to get the desired month of battery life (more would be nice) I rely on ULPM to sleep in between measurements.
However, while my data is sent to the cloud when writing them to “cl://” the synchronization with the cloud is not complete. For instance, if I change an edge action or alter the value of a resource in the web interface, it will never get written to the device - the spinner at the device just keeps spinning.
Is there any way of postponing the ULPM shutdown until all data have been exchanged with the cloud? I have failed to find any resource indicating the state of the cloud synchronization process. It would be nice if the shutdown resource had a “lazy” shutdown feature that would not shut down until housekeeping was completed.
Overall I am really impressed with Octave but things have gotten quite complex due to a lot of implications of the battery powered operation.
Hi @jj1 ,
Can you please clarify the observation that you are getting?
It means did you try to synchronize in ULPM?
In my practice, Octave provides real time for synchronization. It means it is automatically synchronized when there are any changes from the Octave page you can check the synchronized state as below
My device wakes up to sample a few sensors, transmits the data to the cloud and then goes to ULPM sleep. My hope was that synchronizing edge actions etc. would be able to take place during the awake periods but this is not the case. Since setting the ULPM to true puts the device to sleep no matter if the device is synchronized with the cloud (edge action etc) or not I need to find a way of postponing putting the device to ULPM sleep. To do that it would be very handy to know whether or not the synchronization was complete.
I have now tried a different approach which uses a cloud action to put the device in ULPM sleep. As I have had tremendous problems with ULPM “boot loops” where I cannot disable ULPM before the device goes to ULPM again, the cloud action solution also provides a nice way of solving this issue. Now I just need to verify that edge actions etc are properly synchronized when using this way of managing ULPM.
`
function (event) {
var deviceName = event.path.split("/")[3];
// Your code here…
var result = {};
var cmdPath = “/everfuel/devices/” + deviceName + “/:command”;
Hi,
OK, thanks, I guess I was not the only one needing this.
Can you provide a list of bugfixes and changes to firmware 3.2.0? I see quite a bit of strange behavior with firmware 3.1.0 and it would be interesting to see if some of that has been resolved.
Can I sign up for a prerelease?
This may not be complete for the production release.
Changes from 3.1.0
Important notice for FX30 devices
Once upgraded to 3.2.0, a FX30 must not be downgraded to an earlier version. It will cause the device to fail to communicate.
After firmware install, one additional reboot of the device can occur.
SSH Remote Login : authentication configuration may reset after firmware install. If this is the case, a new login authentication menu will display. Please test your SSH keys and/or passwords in a separate terminal before logging off from all terminals to ensure you don’t lose access to your target device.
Startup resource /cloudInterface/config_received/value is now triggered once all the configured services have processed their configuration and created the resources accordingly.
USP can run simultaneously on both UARTs.
Connectivity watchdog can now be disabled with zero value.
ORP allows to access to other application resources.
UARTs can be used up to 921600bps.
Bug Fixes and Improvements
Fixed ULPM boot reason that was sometimes not set after wake up.
Fixed an issue where Observations path updates were not taken into account.
Number of bars display is aligned with industry standards.
Fixed an issue with dynamically created Virtual Resources that were pushing twice the same value at init.
Fixed a potential crash in Action Runner when flooded by Edge Actions executions.
Fixed an issue in ORP where the data frame was broken when the waiting time is over 5 seconds.
Fixed an issue in timers where the repeat setting was not kept.
Fixed an issue in Virtual Resources that prevented the use of arrays in JSON kind resources.
Fixed an issue where Cloud Interface was crashing when the Edge Action code size was too big.
Fixed an issue where Cloud Interface was crashing when more than 32 Edge Actions were loaded.
Fixed an issue in ORP where inbound timestamps with decimal points were rejected.
Fixed an issue that made CANopen application restart when a configuration is applied.
Known Issues
If the level of store and forward exceeds 7 MB: 2 MB above the 5 MB max threshold, the events in the store and forward will be lost.
In some rare occasions the system clock is not properly set at boot.
Hi,
It would be really interesting to try the prerelease, thanks. I have noted that downgrading is not possible. When is the production version due for release?