Hi all,
just wanted to start a thread about my first app development job, to inform you I have made the heavy lift (hopefully!) for having most of the fundamental features in place to bring such a functionality to the Ubuntu Touch OS.
The link to my Gitlab repository page is: dataMonitor app, where it is saved the most up to date .click version 0.1.2 (in the folder /build/app).
The very latest commit is important because it is regarding fixing the bug about received bytes from the SIM connection not detected (wi-fi received data monitoring was working since the beginning).
I'd need some help to find out if it is working for you as it is working for me, but please bear in mind the app is UNCONFINED and runs a daemon on the background, so, you never know, better to install it, if you are willing to help, on a test device and not on a daily driver.

I also would like to use this thread to invite the UT community to share ideas and feature requests to improve this app and having it in a better shape to be eventually ready to be published in the OpenStore or integrated in the OS.
I was similarly involved and committed to help with the Linphone app developed by @CiberSheep and Brian and it was a great experience, very exciting and rewarding even if I didn't contribute very much at its development.
I started to work on this app because I felt a modern OS as UT cannot lack in this regard. Also, I read several times on this Forum and on Telegram about people asking for it or complaining for this lack; unfortunately, sometimes the reply to those people was that sure, the data usage monitoring app was missing in the UT OS but they could easily ask their SIM Provider to provide information as a workaround, which I felt a bit unhelpful and insufficient: I don't know your case but in my Country I cannot trust Providers, they are quite nifty so in my humble opinion it is very important to have the ability to monitor the received data on our own, to check on our Providers.

Thank you in advance.

Matteo

P.S. here below some screenshots of the app running on my phone.

@uri even though this is an old revived thread, only to let you know I'm right now working to provide an app bringing such a capability. I'm facing right now some troubles but I'm along the way to solve all those and maybe soon I'll come out with a concept app. Only for your information, the approach in my app is to exploit the API QNetworkConfigurationManager.

Matteo

Hi All,
just to revive this thread, I'd like to inform the Community that the dataMonitor app, object of the present thread, is still in heavy development by me but right now I'm committed in fixing some little glitches and bringing in UI improvements before to update it again on Gitlab to the last version. This version will be a big one, since it will also bring some gestures I worked on during this time I missed from the present thread.
I'd like to share with you some pics of the very latest build:

@rinigus I will try to help you out to package it if none of the most experienced UBports developers will show up....only, this is my last week at work and after I'll have plenty of time next week to dedicate at this scope. I'm not a great developer but I know a little how to package things with clickable even if I didn't manage yet to download and include third party packages in the clickable package, up to now.
Don't worry, somehow we will be your hands and your eyes, in order to have your great app set and working on this platform

@mariogrip All the best wishes to you and your family. The Community needs you in the best shape to move the project further and further but remember that life and family always come first.

I read your post and I felt your pain, which is mine too. I agree with you with the fact that many little bugs ( some of the bugs you reported don't seem to me very little BTW) could have been tackled before. However, we are a small community, and only a bunch of devs among all the community people are active in the development and we cannot expect miracles from them. For this reason, personally I'm struggling to find my way to help the development to improve, with the goal to start from the little bugs. I'm not a dev, I know some coding languages, but never developed for a phone OS. Like me, other people are trying to ride the same route with similar objectives. In the end, in my humble opinion, something is moving in the background, and maybe soon (that's my hope!) there will be self-taught devs who will be able to make this OS always better and better. For all the interested people, we have a discussion group on matrix named Bootcamp, where all the beginners are more than welcome

@Lakota I have BQ Aquaris E5. I installed also Gimp and it seems working good.

@Stefano I also once changed the baseband following the guide on this forum but I didn't notice such an improvement. To be honest I didn't test it so heavily so thank you Stefano to have made us aware of that, I'll certanly flash it back and pay more attention to the behavior. As a final comment, I'd say that if confirmed to be worth the upgrade, it would be great if the latest firmware would be included in the UT image.

@AppLee and @geekvine and @Giiba you need to build the binary first before to compile the clickable app.
So, once installed the dataMonitor folder into your local directory, you first need to run clickable build-libs to compile the file Actiondaemon.cpp. Only after that, you are ready to run clickable with your phone connected to your PC to compile the whole project.
Thank you for your interest BTW. Any feedback from you on the app behavior is highly appreciated

Matteo

I just updated the app on my Gitlab repository (link to this you can find in the first post). The most important feature for me is the introduction of the notifications, which are now triggered in case of exceeding data thresholds. The full change log is below:

-Version 0.1.6-

1. A new icon has been introduced with the present release (I'm not a great artist so this could be a temporary solution in case somebody else would come up with a better idea);

2. Added notifications in case of data thresholds exceeding. The code employs the C++ function 'popen' which apparently is the only one I discovered to work seamlessly without killing the daemon ('system' and 'QProcess' were the other two methods tried before);

3. Added summary at the Main.qml page for SIM and Wi-fi data;

4. Added the "info" section on the up right corner, close to "settings";

5. Merged early translation to spanish thanks to @Krakakanov (new additional strings to be translated have been added since then);

6. Added translation to italian thanks to...me;

7. Added gestures to interact with the graph:

   • Scroll down/up with two fingers to enlarge/narrow the 'MBytes' data range;

   • Press and hold with one finger to create a new data threshold object;

8. Added 'BottomEdge' section to store the list of the created data thresholds. In this section you can:

   • Drag the data threshold row towards right, to delete the data threshold;

   • Drag the data threshold row towards left, to mute the notification for the concerned threshold;

9. Added labels for 'Mbytes' and 'Days of Month';

10. Fixed 'Mbytes' data steps to be consistent between the Vertical and Horizontal view and to fill all the space at its disposal;

11. Fixed bug occurring when the date passed from one day to the day after, not calculating the received data in a correct way;

12. Added message on the middle of the page to inform about data unavailability when opening a graph with no data yet;

13. Added message on the middle of the 'BottomEdge' page to inform about thresholds unavailability when no data thresholds yet.

@ricardo65 from my repository page ---> here. If you are going to build the app yourself on your phone, don't forget to run first a clickable build-libs to compile the executable file, before to run clickable to build on your phone. Let me know ;). Regards.

Hi All,
I'm happy to announce that the version 0.1.7 is out. The main modifications are related to make the monitoring activity working also for the SIM connection due to a nasty bug @ricardo65 highlighted to me, which I hope I got rid of. Moreover, as advised before I modified the daemon files to be more simple and useful (but in future I'd eventually need to tinker those files again to bring somehow an automatic time step adjustment - Future Enhancement); who has got already the app installed needs first to delete the previous daemon files, from Settings page before having the new versions working; in addition, now the app shows many more options in the Settings page with the aim of putting in place the highest customization as possible for the app, in the very genuine Linux spirit.
For a better look at the modifications, see here below the log:

-Version 0.1.7-

1. Fixed bug which prevented the app to work for the SIM connection (feedback needed on this).

2. Daemon .conf files modified in a more useful and simple way. To get rid of the previous .conf versions, user to go to 'Settings', to push 'remove daemon', to exit from the app and open the app again to have the new .conf files copied at the .config/upstart location.

3. Added new settings in the 'Settings' page:

   1. Switch to enable colors by theme global selection or to be custom set; user can now set a custom color + opacity for the background, lines, font, buttons, graph grid and bars;
   2. Switch + button to enable the global theme selection by daylight (between Ambiance and SuruDark only), setting a threshold time;
   3. Slider to custom set the daemon time step for its idle activity, to better control the battery energy drain.

4. Minor bug fixes.

Thank you.

Matteo

@ricardo65 as promised, I made some inspections on my phone regarding the SIM data reception and storage.
I found the reason why the received data monitoring worked for me but not for you: if you see below the output of ifconfig -a, in my case the working SIM connection is the one named rmnet1 which is a Point-to-Point interface type. In your case you got instead a weird UNSPEC specification (see earlier output of yours for rmnet0 connection) which I didn't expect to occur and because of that a portion of fundamental code was skipped in your case. I already made a fix for that Thank you for noticing and for informing me about that issue by the way, working only on my phone could lead to flaws in the code sometimes.
Just please wait until I'll issue the 0.1.7 updated version, which I'm planning to do very soon and which will hopefully bring additional improvements (to the daemon and settings).

Kind regards,

Matteo

hablet@ubuntu-phablet:~$ ifconfig -a
ip6tnl0   Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          NOARP  MTU:1452  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:228 errors:0 dropped:0 overruns:0 frame:0
          TX packets:228 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:26852 (26.8 KB)  TX bytes:26852 (26.8 KB)

rmnet0    Link encap:Point-to-Point Protocol  
          POINTOPOINT NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

rmnet1    Link encap:Point-to-Point Protocol  
          inet addr:10.48.87.3  P-t-P:0.0.0.0  Mask:255.255.255.0
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:9304 errors:0 dropped:0 overruns:0 frame:0
          TX packets:5186 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:10736783 (10.7 MB)  TX bytes:452452 (452.4 KB)

rmnet2    Link encap:Point-to-Point Protocol  
          POINTOPOINT NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

rmnet3    Link encap:Point-to-Point Protocol  
          POINTOPOINT NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

rmnet4    Link encap:Point-to-Point Protocol  
          POINTOPOINT NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

rmnet5    Link encap:Point-to-Point Protocol  
          POINTOPOINT NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

rmnet6    Link encap:Point-to-Point Protocol  
          POINTOPOINT NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

rmnet7    Link encap:Point-to-Point Protocol  
          POINTOPOINT NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

sit0      Link encap:IPv6-in-IPv4  
          NOARP  MTU:1480  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

wlan0     Link encap:Ethernet  HWaddr 38:bc:1a:1c:ee:bd  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

@ricardo65 Ricardo thank you for your feedback but please keep always the most up to date version since I don't remember the issues I got with the previous versions, so I want to be sure it is not going to break your phone. In the next days I'll try to find some free time to check the data monitoring with my SIM (hopefully this weekend).

Matteo

@ricardo65 apparently you also have a ril_0 gsm connection, so how strange, it should work. In the next days I'll make some verification with my SIM in to see if something changed during the time I worked exclusively on the wi-fi connection. For now, thank you Ricardo, you have been so helpful so far

@Lakotaubp great! Thank you...much better now ;P

@ricardo65 please next time use either an external service to paste such long reports, for instance Pastebin Ubuntu is what we usually prefer to employ, or you could embed your report between code tags (the symbol </> you can find above the text field during message composition). This because it's easier for anyone to read and following these simple rules we avoid too much noise in the present thread.
To come to your output, it seems similar to my Pro5 output....but I don't see any ril_0/ril_1 gsm connections....are you sure you have your SIM card inserted and proved working? Please show me also the output of: nmcli device status both when the SIM is inside and after you pulled it out, if possible. Thank you.

@ricardo65 Ricardo, thank you for providing the log. What I noticed is that regardless of the connection type (SIM or Wifi) you got that strange error related to Error: no such table: chartYdata Unable to execute statement. This sometimes happened to me also, but a reboot fixed that without additional troubles. Did you try to reboot?
Also, I need to ask you to type the following command in the terminal, after your SIM connection is fully working: ifconfig -a and report the log here.
Please follow the discussion about this issue reported in my dataMonitor Gitlab page ---->Issue #1
to understand what's going on with your phone and why you don't have apparently SIM data reception.

@ricardo65 Hi Ricardo. Do you mind to move your issue to the official thread related to dataMonitor app? The thread I'm talking about is here. I would like to avoid too much fragmentation, therefore one place for reporting issues related to the app is better.
Also, I'd need to see the log: to make it simple, please open the LogViewer app and look for mattdaemon log and eventually copy and paste in Pastebin the log after having the SIM connected and proved working and after receiving some data (i.e. surfing on the internet, looking at a video on YouTube....). Thank you.

@AppLee and @Giiba since you are trying to build the app from source, it's worth to inform you I made slight modifications to the two .conf files used for the daemon functionality. Those will be included in the next ver. 0.1.7. The reason is that I'm tring to find the most functional code for the daemon. Just to briefly explain, the mattdaemon-service is only meant to get triggered once at the purpose of switching the first boot code path to the after-boot code path the Actiondaemon binary shall follow. I recommend you to change locally the two .conf files according to the below reported new files. If you already built the app before, then you need to go first to settings and to push the "remove daemon" button; after that, you need to exit from the app and you can rebuild it (this time you only need to build the qml part, since the C++ library remained unchanged) and in the end to reboot the phone. You can find the two .conf file in the dataMonitor/daemon folder.

EDIT: sorry, I needed to remove the previous attached .conf files for the daemon activity, since I find out there is still some improvements to give to those. I will report back as soon as possible, when I'll find the most convenient way to express those. In the meantime, the 0.1.6 version is working for me to test the app.
A recommendation: test this app only on a secondary device, not on a daily driver, since it is still experimental (even if widely tested by me) and in case of any undesirable occurrence you will not lose any data and you can safely recover from scratch. Thank you.