Init Network traffic

[sambarlick]

Hi Martin,

Thanks for adding this feature. This is exactly what i wanted!

A couple of questions,
Is it possible to write to that variable? - probably not, that's fine.

2nd question, is possible to set a specific time and date as a variable?

I am trying to create a flow or group of flows that rest, monthly, the monitored data or the monitoring, when my mobile carrier resets my data usage.

If you can't write to the init Network traffic variable then i can just could use store the usage at the time i want to "reset" my monitoring and use that as my reference.

The key then is can i trigger a flow on a certain date of the month without using a calender entry to trigger the flow?

Thanks Sam.

[Martin]

Hi,

To my knowledge there's no way to reset the reported values, except by rebooting the device. You could build a flow that remembers the values across device reboots and another flow to reset the values when the new billing period starts.

Here's a rough outline that might work. It's completely untested, I hope it's not completely wrong

Flow to accumulate the values over device reboots:
-trigger Shutdown
-action Init Variables Network Traffic
-action Script (add the values of the local variables to global variables), example for mobile received data:
global_mobile_received_bytes = global_mobile_received_bytes + mobile_received_bytes; (don't forget to initialize the global variable global_mobile_received_bytes to zero somewhere)

Maybe this flow needs to be changed for devices that have some kind of fast-boot mode, but I'm not sure about that.

You can access the current value in another flow by adding the global variable and the current reported value by action Init Variables Network Traffic.

You can assign the current reported value as a negative value to the global variable when you want to reset the billing period:
Flow to reset the billing period:
-trigger Calendar: Okt 1, 2014, Monthly (on day 1)
-action Init Variables Network Traffic (store in local variables)
global_mobile_received_bytes = -mobile_received_bytes;

Please note that some providers might not count some network traffic so I'm not sure how good this value will match the one used by your provider to create the bill.

Trigger calendar probably works, but you could also use a trigger Global Variable Date/Time and a variable set to the next billing period start. The page Script examples contains a few examples to work with dates.

Regards,
Martin

[sambarlick]

Thanks for your reply Martin!

Thanks for the suggestion about storing the init mobile traffic value, i didn't realise that it was lost on shutdown.

I was able to store the value in shutdown then transfer it back into my global veriable that i created for my current data usage.

I have also created a separate flow for the date that resets my variables, well i store the final value for that billing month and - it from the current value.

Thanks, Sam

[sambarlick]

Hi Martin,

I'm having trouble with the shutdown flow.

I created a flow that saves the current init value to a global but the variable is empty when i restart my phone.

Is the script too long?

I added a sound at the end of the flow to debug the flow, to check if the flow reaches the end.

[Martin]

Hi,

It could be possible that Automagic does not have enough time to execute the flow and save all variable values before Android kills Automagic. You also divide the data with quite a high value (1048576) to calculate the MBs. Since integer math is used, the value could possibly be rounded down to 0.
When you say that the value is empty after a restart, do you mean null or 0? Please try to remove the /1048576 and see if the value survives a reboot.

Regards,
Martin

[sambarlick]

I wondered if it was a time issue.

I will try removing the devision and see wbat happens.


Currently the value is initialised at zero and is zero after reboot, but im not sure if it isthe same original zero or a zero as a result if the flow.

[sambarlick]

Hi Martin,

I removed the division to MBs and left the values in Bytes. This solved it.

Thanks again Martin!