Hey @NhonChu,
My apologies for letting this sit. The lifetime is 630720000. What do you mean by the URL of the AirVantage system? Something like https://eu.airvantage.net/monitor/systems/systemDetails?uid=<sysuid>?
Hi @nick,
Yes, that’s correct for the URL of AirVantage.
Are you still having issues with “registration expired” or sending commands ?
@NhonChu, our biggest pain point right now is sending commands. We do however still see registration expired from time to time, which requires our users to physically reboot the device on their boat.
Hello @coastalbrandon
What SIM card is used ? What is your country ?
I have systems who work fine in USA with SIM card from Sierra.
I have tested in Germany and Austria too without any issue about registration expired.
It’s a WP8548 but for US I move now to WP7603 due to 3G cover in this area.
I test now WP7607 for EMEA without any issue with LTE 4G.
Francis.
Hey @Francis.duhaut,
We’re in British Columbia, Canada and testing with Sierra Wireless SIM cards. This could be related to the 3G issues you mentioned in the USA (since we’re so close). We’ve managed to code around almost all of the modes of failure, but the one that typically requires a reboot to fix occurs when cm radio shows the following output: https://gist.github.com/nvandoorn/40aa270d528174345524c88dc6c3cf2b
I’ve also been very cautious about what routines I call from the modemService since it’s not strictly multi app safe and is already used by the dataConnectionService.
Hey @NhonChu,
I’m a little confused, wouldn’t you still need authentication/privileges to see the system in AirVantage?
Our primary pains are still related to commands. We’ve managed to code around almost all of the modes of failure related to sending data, but please see my post above regarding a very hard failure mode.
In terms of commands, I’m almost certain it’s related to NAT timeouts on our cell network. The commands are received quickly whenever the hardware has a fresh session or sends a heartbeat.
I see some trouble with 3G connection in US. I have added a push dummy data every 5mn to solve it. 2mn was too short I think due to NAT time out ?
Operator is AT&T.
Now it’s ok. But I will move quickly to LTE in US.
Hey Francis, could you clarify about the dummy data and different times? We push real data quite frequently (sometimes every 1 to 2 minutes), so this could be a problem for a us.
I just push a dummy integer every 5mn (pushData not pushRecord).
This solve my problem.
I have a lot of data session ended / started.
Hi @nick,
You’re right, there is auth issue to see your system anyway. You provided the answer on the lifetime which was 630720000, that is 20 years. So it is not likely to see registration expired.
What is the heartbeat interval ?
If your use case needs to receive commands asap, could you try to a push a single data every 20s, this will keep the NAT alive. This test will help to confirm whether your issue is related to NAT.
Thanks
Thanks @NhonChu. I’ll give this a go. Does the le_avdata_Push routine really differ that much from le_avdata_PushRecord? We invoke this routine quite frequently to push time series data. I recall seeing it use the same push mechanism under the hood but I may be incorrect, so I will try this either way.
Heartbeat is set for 15 minutes.
Hi @nick,
le_avdata_Push or le_avdata_PushRecord can be used to do the NAT test.
It is more straightforward to use le_avdata_Push to push a single data point, for instance:
- call le_avdata_CreateResource(VARIABLE_MYSPEED, LE_AVDATA_ACCESS_VARIABLE) once in COMPONENT_INIT
- then call the following to push data (once every 20s for your test):
le_avdata_SetInit(VARIABLE_MYSPEED, mySpeed);
result = le_avdata_Push(VARIABLE_MYSPEED, SinglePushHandler, NULL);
It is not ideal to push data every 20s, but this test helps to identify/confirm your issue.
Hey @NhonChu,
Thanks for the suggestion, I’ll give this a try.
This is a somewhat unrelated question, but still important to make this work effectively. I opened a new thread to discuss efficiently sending JSON style payloads over the le_avdata interface. If you have any input it would be much appreciated.
Cheers!
Hey all,
After decent amount of experimenting, I’m still having trouble with sending commands/settings to the device reliably and on time.
So far I’ve tried:
-
Pushing fake asset data (I used an epoch time) using
le_avdata_Pusheverynseconds wheren ∈ { 20, 60, 120, 240 }as suggested by @NhonChu and @Francis.duhaut. This did not seem to make a difference unfortunately. This result did not really surprise me since we were already callingle_avdata_PushRecordevery 5 minutes andle_avdata_Pushandle_avdata_PushRecordboth make calls tolwm2mcore_Pushunder the hood. -
Adjusted the heartbeat. I could be mistaken here, but it seems that
le_avc_SetPollingTimerand “heartbeat” in the AirVantage web app seem to refer to the same thing? Regardless, we’ve seen best performance at 15 minutes. Times in the range of[1, 10]resulted inavcServicefrequently missing watchdog kicks.
- Close and re-open the AVC session frequently using
le_avc_StartSessionandle_avc_StopSession. This seems to work well as it forces a “full registration” along with ~136 data points. As discussed above by @asyal and @Prush, a “registration update” is preferable as it does not include as many data points.
Analyzing all of this leaves me with a few questions:
- Registration update events appear to be the heartbeat, is this true?
- What information is contained in a registration update? I’m assuming AirVantage requires information from the registration update to send commands, settings, and updates to the target. We usually see these operations leave the “pending” state as the device publishes a registration update.
- How can we debug this and get an idea of what is going on behind the scenes? We frequently see operations in AirVantage sit in the pending state for 8+ hours while time series data continues to be published. The target has no logs indicating anything is wrong, so it does not leave much in the way of debugging. I considered setting up my own CoAP/LWM2M environment but this seems like a huge effort.
- Does AirVantage and
avcServicediffer from the LWM2M or CoAP spec in any significant way? - Could any of this be related to the required
avcCompatapp (used on the WP85 to adapt AVC1 to AVC2)?
Hello @nick
For 3. I have same issue. A strange thing because per moment the command is successfully done on the target…
After investigation I have a lot of issue in case of poor or Fair level reception.
I use now new antenna taoglas FXUB066 (more bigger) and for the moment it seems good.But the command per moment still in pending mode and my device push data and the heartbeat work…
I use WP7603-1 in US and WP7607-1 in EMEA. Legato 18.05.1.
But of course I can’t explained issue with AV connection.
I just add a reboot if no AV connection since 01h. This is include in my avcController .
It’s dirty but work.
I’m’in holly day. I will spoke with Sierra end of August. You can find Robert Jacolin in the Legato forum. rjacolin it’s my contact for AV.
I think too all is not clear with AV.
Francis.
- Registration update is the heartbeat. As to what is in the registration update, we can refer to the LwM2M Spec.
From the LwM2M Spec.
When registering, the LWM2M Client performs the “Register” operation and provides
the properties the LWM2M Server requires to contact the LWM2M Client (e.g., End Point Name); maintain the registration and session (e.g., Lifetime, Queue Mode) between the LWM2M Client and LWM2M Server as well as knowledge of the Objects the LWM2M Client supports and existing Object Instances in the LWM2M Client. The registration is soft state, with a lifetime indicated by the Lifetime Resource of that LWM2M Server Object Instance. The LWM2M Client periodically performs an update of its registration information to the registered LWM2M Server(s) by performing the “Update” operation. If the lifetime of a registration expires without receiving an update from the LWM2M Client, the LWM2M Server removes
the registration. Finally, when shutting down or discontinuing use of a LWM2M Server, the LWM2M Client performs a “De-register” operation
2/3. Refer to the Queue mode operation in LwM2M spec. As per spec I believe the server should forward the requests in queue when it receives any notification or registration update. We have to look our server implementation to see why requests are not forwarded after a push notification is received.
-
avcService is not very different from LwM2M (CoAP over UDP)
-
No
Update on the following:
We frequently see operations in AirVantage sit in the pending state for 8+ hours while time series data
Our Server team confirmed that they would forward the pending requests (jobs) to the device after receiving the push notification. We couldn’t reproduce this issue at our side. Is this something you are seeing consistently?
Thanks for the information @prush. I suspect this is an issue with the registration updates not arriving when expected or perhaps an incorrect lifetime in the update.
Hello all,
Some updates:
I spoke with @Prush about his testing on this issue. I’ve asked him to try with a WP85 instead of WP76. I think this is important since it factors in different modem firmware as well as the avcCompat app on the WP85.
In terms of reproducing the problem:
- Let the device connect, start a session, and start pushing time series data (a push every
nminutes wheren ∈ [1, 5] - Issue a command. If the command lands right away, wait another 5 minutes or so.
- Repeat until you see the commands sit in the “pending” state for an extended period of time
The screenshots below show one of our units that’s pushing time series data, but fails to receive the operation.
