I have a test device with Dev Mode enabled running a soak test. The unit has been in this state for several weeks. Dev Mode has not been explicitly activated during this time. However, I have been using the inactivity timer to auto-disable Dev Mode when the device is inactive for one hour (3600s). My understanding was that the purpose of the inactivity timer was to help assure that Dev Mode was not left active for extended periods of time resulting in large unexpected bills. I am still being billed at the Dev Mode enabled rate. Is it necessary to explicitly set the Dev Mode enable resource to false (i.e. not rely on inactivity timer) in order to assure Dev Mode billing stopped?
Hi Dave,
What firmware and device did you observe this behavior?
I located your device. You should not have any charges due to Dev Mode messages once the device goes into Dev mode after the timer expires.
3.3.1. I just noticed availability of 3.4.0, but have not applied the update yet.
Perhaps slightly different topic, but I just saw new message threshold UI feature apparently released yesterday (04/27). Checking messages for 04/28, connector shows 21, but Usage page shows 49:
Can you help me understand the billable message count? The messages to the cloud stream are the ones tallied toward the billable threshold, right? Messages sent to external cloud platform are not counted (already counted when sent to cloud stream), right?
Thanks.
… also… you said you located my device. I explicitly disabled Dev Mode (via resource) after receiving the billing statement that prompted this question, so it is not currently in the state it was in when the issue occurred.
Initially, I had Dev Mode enabled with inactivity timer enabled and set to 3600 s . It was in this state for several weeks when the latest statement was received indicating Dev Mode billing. This prompted my question as to whether it was necessary to explicitly disable Dev Mode (as I have done with the device) or if it was adequate to initially enable Dev Mode but also enable the inactivity timer to disable Dev Mode upon expiry. Please let me know if my explanation is not clear.
Hi David,
I have not had time to test the new UI message overage warning feature but will do so tomorrow.
To answer your question:
Can you help me understand the billable message count? The messages to the cloud stream are the ones tallied toward the billable threshold, right? Messages sent to external cloud platform are not counted (already counted when sent to cloud stream), right?
Messages from the device to the Octave cloud are the only billable messages. Messages from the Octave cloud to external systems are not counted in the billing.
I am not fully understanding the billable message count being generated. The month rollover provides a clean point to demonstrate. I have disabled some events to de-clutter the messaging to investigate and understand the behavior better. I presently have only one event being sent to the cloud hourly. I expect 24 messages per day since I believe the data send is less than 20 Data points.
Details:
I have /util/cellular/signal/value read hourly (3600s).
An observation sends events to an edge action:
signalToAggregator
that writes the value to a VR:
vr://myDataToCloud
An observation on /virtual/myDataToCloud/value sends events to S&F buffer.
The S&F period is 3600s
The event appears to have 11 data points (I believe).
“elems”: {
“virtual”: {
“myDataToCloud”: {
“source”: “signal”,
“timestamp”: 1651446293.673159,
“value”: {
“bars”: 4,
“gsm”: {
“ber”: null
},
“lte”: {
“rsrp”: -93,
“rsrq”: -13,
“snr”: 3
},
“rat”: “lte”,
“rx_level”: -36,
“status”: “registered”,
“umts”: {
“ecio”: null,
“rscp”: null
The hourly poll period and hourly S&F period should result in a single event sent to the cloud stream ever hour. An Octave message consists of 20 data points. So, theoretically I am “wasting” 9 data points each hour. But somehow this configuration is generating twice the number of messages expected (48 msgs /day vs 24 msgs /day).
Can you help me understand the behavior?
Hi David,
I count 12 datapoints. Fyi, I have a Jira ticket open on the Dev Mode/ Inactivity timer.
I will look at this using my test devices.
{
“creationDate”: 1651586694814,
“elems”: {
“virtual”: {
“myDataToCloud”: {
"source": “signal”,
** “timestamp”: 1651586693.675298,**
“value”: {
"bars": 4,
“gsm”: {
"ber": null
},
“lte”: {
"rsrp": -91,
** “rsrq”: -13,**
** “snr”: 6**
},
"rat": “lte”,
** “rx_level”: -35,**
** “status”: “registered”,**
“umts”: {
"ecio": null,
** “rscp”: null**
}
}
}
}
},
“id”: “e6271368607cac34545a523af”,
“path”: “/dpinc/devices/dpinc_fs30s_01/mydatatocloud”
}
Hi David,
I will run this scenario on one of my test devices.
David, were you able to test these issues on your devices?
Hi David,
As a starting point, I did a soak test a well.
Dev Mode = off after 3600s
Logging = off
No Observations
As a result, I only had Dev Mode message usage during the 3600s period.
I am testing your S&F config now.
Hi David,
I ran tests using S&F yesterday. I compared the events in the stream to what is showing on the usage chart and today and I do see some anomalies in the usage chart as compared to what is in the stream .I am submitting a JIRA ticket to engineering for further analysis.
HI David,
I am also testing setting cloudInterface settings directly in the resource tree.
Hello David,
Could you test your S&F scenario with cloudInterface - store_forward - heartbeat_on_empty specifically set to “false” instead of empty? I ran your same test case on my device with this setting and the usage matched the count in the input stream exactly.
Hi DavidJ.
It does appear the explicitly setting heartbeat_on_empty to “false” results in message count per day dropping from ~48 to ~24 (as was expected for the test). Can you tell me what was causing the excess messaging?
Thx.
Hi David,
I am logging this as a bug, If you don’t explicitly set heartbeat_on_empty to false, it is on, which is not intuitive in the Octave UI or docs. The excess messages are heartbeat messages.
Hi DavidJ
Thanks for the update. I wonder if you could explain a bit further. I assumed after your recommendation to explicitly set heartbeat_on_empty to “false” resulted in reduction of messages that the issue was related to this setting. I was hoping to understand the behavior better, however.
My understanding was that the purpose of heartbeat_on_empty was to send a message to the cloud at the specified period if no other data had been sent (i.e., “on empty”).
The docs indicate that “…each communication of data sent to the cloud, updates the last known online status of the device in Octave. However, it can be useful to have the device perform this refresh even if there isn’t anything in the Store and Forward buffer.”
I dont understand why the heartbeat message was being sent in my case even assuming heartbeat_on_empty was interpreted to be “enabled”. Data was sent every hour (the S&F period), so there was always “data in the buffer” during each S&F period. I also don’t understand why the heartbeat consumed an entire message. The data in the buffer does not fill out an entire message, so there was room available in the existing message.
Lastly, I would like to understand the best way to troubleshoot issues like this in the future. For example, is there a way to capture all messages sent by the device ( including heartbeat, etc.) in order to debug unexpected / unexplained messages being sent?
Thanks for the assistance.
Hi DavidJ.
Did you have a chance to take a look at the follow-up questions?
Thanks.
Hi David,
we are looking into this. In your case, the Heartbeat should not have been sent as there was data in the S&F
Displaying heartbeats is something we are working on. For the time being it is not something that you can visualize in the UI
A.