Bandwith Consumptions when doing development through the tunnel

Hello , just wanted to know , does the flowfuse device agent consumes a lot of bandwith when doing development through the tunnel ? My data quota seems to get quickly depleted ever since I started to do development through flowfuse , it even reaches up to 1 GB per day for both data sent and receive, any thoughts ?

For your information , I did have other services which published telemetry data to the cloud which is telegraf but I doubt telegraf consumes a lot of bandwith , furthermore Im only sending every 10m so I doubt telegraf are the ones causing it . Any thoughts ? Thanks

Hi, welcome to the forum.

Do you have a lot of debug messages always passing through to your debug panel? Are there any large, frequent messages?

Do you have large context data that you frequently inspect?

How often do you open the tunnel? How often do you deploy & how large is your device flows file?

Not specifically related to the editor tunnel but still a use of your internet: do you have data being passed between the device and an external resource (project link nodes, http requests, MQTT?)

"Do you have a lot of debug messages always passing through to your debug panel? Are there any large, frequent messages?"

Yes I do , it is a large message and send every 100 seconds

"Do you have large context data that you frequently inspect?"

Yes I do , In fact every 5 seconds I update my global context persistent variable and every 5 seconds also I read from the global context persistent variable for further processing

"How often do you open the tunnel? How often do you deploy & how large is your device flows file?"

Quite often , I mean Im working on it from 8 - 5 , so during that time majority I use the tunnel , and my device flow.json file size are 133kb

"Not specifically related to the editor tunnel but still a use of your internet: do you have data being passed between the device and an external resource (project link nodes, http requests, MQTT?)"

Yes i do

  1. MQTT - I use it for subscribing the data I receive from chirpstack to nodered - but its from localhost to localhost

  2. Project Link Out - I publish telemetry data every 5 seconds where the data not so large I suppose , the message contents are this

{
"unsyncdata": 0,
"pgcount": 22785,
"gatestatus": "open",
"datasent": 614728940,
"datareceived": 223674677,
"mobilesignal": -55
}

Now my question is , does using

  1. debug node
  2. global context persistent variable

use internet ? I thought this just saved locally and not affecting the data usage ?

Every message that comes to your debug panel is passed through the tunnel.

For global/flow/node context, if you are passing this (via MQTT or project link or some other external system) then yes, that is traffic. If you are also often viewing or refreshing the context on the sidebar often then yes, that too will need to pass through the tunnel.

So if you deploy every 1 minute, for 8 hours per day, that is ~62MB/day. Over 20 working days, that is ~1.2GB

Couple that with all the debug messages and MQTT traffic, yes, I can see how you have been using your data.


Where, physically, is the device in relation to your browser where you edit flows?

For subscribing MQTT localhost data , it also use internet ? Really ?

The device just sits next to me when im working on it when im at the office , only on some days i wfh then I use it from my house which not so far away tbh , around 20 km from the gateway itself

so lets say if i turn off the dev mode , it should not used a lot of data correct ? since nothing are passed through the tunnel , only the device logs right ? and some data that being published to project link out node correct ?

Not localhost - I did specify "external"


Ok, so the tunnel does pass through the FF backend so while you are local to the device, traffic does still travel through the backend.
This is something we are aware of. Keep your eyes peeled.

In the meantime, where/when possible, disable debug nodes, don't leave the editor connected, try to avoid deploying changes too often, try to avoid refreshing large context view data too often.

1 Like

I see , okay then thanks for the suggestions steve , really appreciate it !

1 Like