connmon connmon v3.0.10 [2025-Dec-21] - Internet Connection Monitoring Tool for AsusWRT Merlin

[Martinski]

v3.0.10 on RT-BE88U
[Branch: develop]
HELP [v3.0.10_25120912]

Thank you for providing the test/debug results.
Would you please run your test again using the latest 'develop' branch v3.0.10_25120920 version?
Once the test is completed, please post the contents of the debug logs, as before.

No worries on time. I am retired, just playing with tech while I still have something left of my mind.
Been looking for something to use as another datasource with Grafana and InfluxDB with connmon feeding it
fit the bill.

Besides this is more fun than my toilet I just finished fixing so it can flush properly again.

LOL!! Yeah, I get it. Playing with tech can certainly be more fun than fixing a toilet - or anything else in the house, for that matter...

@Martinski

While your down in the weeds on connmon InfluxDB code. I have a RFE on https configuration.
Right now you can pick your port for http access. But for https you can only use 443.
Maybe make http/https a configurable option.

Just to make sure I understood your request: you want a new menu option to specify/change the HTTP/HTTPS protocol for the current InfluxDB port number (even if it's 443), which then it's applied to send data to InfluxDB, correct?

If so, that's certainly doable. I'll do it tomorrow - I'm already too tired this evening, and I'm going to sleep early tonight since I have an early Engineering meeting tomorrow morning.

 

[scootertramp]

Thank you for providing the test/debug results.
Would you please run your test again using the latest 'develop' branch v3.0.10_25120920 version?
Once the test is completed, please post the contents of the debug logs, as before.


LOL!! Yeah, I get it. Playing with tech can certainly be more fun than fixing a toilet - or anything else in the house, for that matter...


Just to make sure I understood your request: you want a new menu option to specify/change the HTTP/HTTPS protocol for the current InfluxDB port number (even if it's 443), which then it's applied to send data to InfluxDB, correct?

If so, that's certainly doable. I'll do it tomorrow - I'm already too tired this evening, and I'm going to sleep early tonight since I have an early Engineering meeting tomorrow morning.

v3.0.10 on RT-BE88U
[Branch: develop]
HELP [v3.0.10_25120920]

Run Test:
Choose an option: cs

Data sent to InfluxDB successfully

agagne@rt-be88u:/tmp/mnt/rt-be88u/entware/home/bin# ls -ltr /tmp/var/tmp/
-rw-rw-rw-    1 agagne   root             0 Dec 10 07:05 temp_connmon_curl_OUT.LOG
-rw-rw-rw-    1 agagne   root           954 Dec 10 07:05 temp_connmon_curl_ERR.LOG

Martinski:

Just to make sure I understood your request: you want a new menu option to specify/change the HTTP/HTTPS protocol for the current InfluxDB port number (even if it's 443), which then it's applied to send data to InfluxDB, correct?

Yes, although port 443 is a special case that should be https. I have a number of internal resources that use SSL and none of them
use port 443 by default settings for https access.

 

[scootertramp]

v3.0.10 on RT-BE88U
[Branch: develop]
HELP [v3.0.10_25120920]

Run Test:
Choose an option: cs

Data sent to InfluxDB successfully

agagne@rt-be88u:/tmp/mnt/rt-be88u/entware/home/bin# ls -ltr /tmp/var/tmp/
-rw-rw-rw-    1 agagne   root             0 Dec 10 07:05 temp_connmon_curl_OUT.LOG
-rw-rw-rw-    1 agagne   root           954 Dec 10 07:05 temp_connmon_curl_ERR.LOG

Martinski:


Yes, although port 443 is a special case that should be https. I have a number of internal resources that use SSL and none of them
use port 443 by default settings for https access.

Nice Payload.

 

[scootertramp]

Just to be a PITA. Another RFE for a nice to have would be the IP your using for ping server.
OK I'm done with RFE's.

Thanks for all your efforts.

 

[Martinski]

v3.0.10 on RT-BE88U
[Branch: develop]
HELP [v3.0.10_25120920]

Run Test:
Choose an option: cs

Data sent to InfluxDB successfully

agagne@rt-be88u:/tmp/mnt/rt-be88u/entware/home/bin# ls -ltr /tmp/var/tmp/
-rw-rw-rw-    1 agagne   root             0 Dec 10 07:05 temp_connmon_curl_OUT.LOG
-rw-rw-rw-    1 agagne   root           954 Dec 10 07:05 temp_connmon_curl_ERR.LOG

Looking good now.
Thanks for your patience and willingness to run all these tests and provide feedback - I fully appreciate it.

Martinski:

Yes, although port 443 is a special case that should be https. I have a number of internal resources that use SSL and none of them
use port 443 by default settings for https access.

OK, understood.

Nice Payload.

Yeah, I thought it would be useful to have the router model as part of the data point "source."

Just to be a PITA. Another RFE for a nice to have would be the IP your using for ping server.
OK I'm done with RFE's.

No problem. I'll work on both of your requests. Give me an hour, two at most...

 

[Martinski]

Just to be a PITA. Another RFE for a nice to have would be the IP your using for ping server.
OK I'm done with RFE's.

Thanks for all your efforts.

OK, please try the latest 'develop' branch v3.0.10_25121020 version.

This latest development version now includes:
- Added "PingServer" field to each data point being sent to InfluxDB.
- Added "InfluxDB Protocol" parameter to WebUI page and CLI menus to specify whether to use HTTP or HTTPS.
- Reformatting and display improvements for some sub-menus.

If you run into any issues sending data to InfluxDB, please post the contents of the following files, as usual:

/tmp/var/tmp/temp_connmon_curl_ERR.LOG
/tmp/var/tmp/temp_connmon_curl_OUT.LOG

HTH

 

[scootertramp]

OK, please try the latest 'develop' branch v3.0.10_25121020 version.

This latest development version now includes:
- Added "PingServer" field to each data point being sent to InfluxDB.
- Added "InfluxDB Protocol" parameter to WebUI page and CLI menus to specify whether to use HTTP or HTTPS.
- Reformatting and display improvements for some sub-menus.

View attachment 69488

View attachment 69489

View attachment 69490

If you run into any issues sending data to InfluxDB, please post the contents of the following files, as usual:

/tmp/var/tmp/temp_connmon_curl_ERR.LOG
/tmp/var/tmp/temp_connmon_curl_OUT.LOG

HTH

v3.0.10 on RT-BE88U
[Branch: develop]
HELP [v3.0.10_25121020]

Works great.
Could you move ping server into the datapoint variable so it doesn't store ping data twice for each test.

It would then store a single record for each test.

 

[Martinski]

...
Could you move ping server into the datapoint variable so it doesn't store ping data twice for each test.
...
It would then store a single record for each test.

Hmmm... Normally, the way the data record fields are displayed would have to be a function of how the database is queried and/or how the extracted data is formatted for presentation purposes. From a database design and operation perspective, it would not only be very wasteful of storage space, but also very inefficient to store multiple times exactly the same set of timestamped data tags & fields for the same data record. Imagine if a user had 5 or 10 fields in the same data point??

I highly suspect your data visualization/presentation issue lies with how the data is being queried/extracted/presented, not that the same data point is stored multiple times in the database.

In any case, the change you requested in the code is trivial, so here's the latest 'develop' branch v3.0.10_25121108 version.

HTH

 

[scootertramp]

Hmmm... Normally, the way the data record fields are displayed would have to be a function of how the database is queried and/or how the extracted data is formatted for presentation purposes. From a database design and operation perspective, it would not only be very wasteful of storage space, but also very inefficient to store multiple times exactly the same set of timestamped data tags & fields for the same data record. Imagine if a user had 5 or 10 fields in the same data point??

I highly suspect your data visualization/presentation issue lies with how the data is being queried/extracted/presented, not that the same data point is stored multiple times in the database.

In any case, the change you requested in the code is trivial, so here's the latest 'develop' branch v3.0.10_25121108 version.

HTH

v3.0.10 on RT-BE88U
[Branch: develop]
HELP [v3.0.10_25121108]

Can I ask for one small change in how you added PingServer to dataPoint variable.
In it's present form it adds the ip address to the db quoted.

dataPoint="Jitter=${JITTER},LineQuality=${LINEQUAL},PingAvrg=${PING},PingServer=\"${PING_TARGET}\",Source=$SCRIPT_NAME"

 

[scootertramp]

Just ran a test from the router connmon webui to test https on port 8086 to the InfluxDB.
Everything was successful.

Thanks once again.

 

[Martinski]

v3.0.10 on RT-BE88U
[Branch: develop]
HELP [v3.0.10_25121108]

Can I ask for one small change in how you added PingServer to dataPoint variable.
In it's present form it adds the ip address to the db quoted.

dataPoint="Jitter=${JITTER},LineQuality=${LINEQUAL},PingAvrg=${PING},PingServer=\"${PING_TARGET}\",Source=$SCRIPT_NAME"

The PING_TARGET variable is double-quoted in the assignment statement because it can contain a blank space. For instance, say a user happens to set the ping server to "www.google.com" instead of "8.8.8.8" (the default); then the variable contents could be something like: "www.google.com (142.250.72.164)"

Try this yourself and check your results.

That's essentially the reason I had the variable as a "data field" instead of a "data tag" (using InfluxDB terminology) in the previous version.

P.S.
I'm currently on my lunch break, but I'm now really curious about how the InfluxDB database schema is organized and handled. I'll take a closer look this evening (curiosity already killed my cat!! ).

 

[scootertramp]

The PING_TARGET variable is double-quoted in the assignment statement because it can contain a blank space. For instance, say a user happens to set the ping server to "www.google.com" instead of "8.8.8.8" (the default); then the variable contents could be something like: "www.google.com (142.250.72.164)"

View attachment 69498

View attachment 69499

Try this yourself and check your results.

That's essentially the reason I had the variable as a "data field" instead of a "data tag" (using InfluxDB terminology) in the previous version.

P.S.
I'm currently on my lunch break, but I'm now really curious about how the InfluxDB database schema is organized and handled. I'll take a closer look this evening (curiosity already killed my cat!! ).

I guess quotes it is. Never would have occurred to me to put anything other then a ip address there.

Better off with a dog anyhow.

 

[Martinski]

@scootertramp,

Well, as mentioned earlier, I was very curious about how InfluxDB handles "data tags" vs "data fields" so I took a closer (but not an exhaustive) look this evening, and it turns out that a proper InfluxDB database for connmon ping test results should store the actual data as "fields" not "tags" because you can make proper database queries *and* perform numerical operations/comparisons with "field values" but not with "tag values." That's also part of the reason why "data fields" are required by InfluxDB, but "data tags" are only optional.

IOW, if ping test results are stored as "data fields," you could, for example, make a database query to extract data that is greater/lower than some specific threshold (i.e. "Ping Average values greater than 20 sec." or "Line Quality values lower than 90%."). These kinds of queries are not possible when stored as "data tags."

Here are some screenshots of the relevant info taken from the following docs:

InfluxDB glossary | InfluxDB OSS v1 Documentation

Terms related to InfluxDB OSS.

docs.influxdata.com

InfluxDB line protocol tutorial | InfluxDB OSS v1 Documentation

Tutorial for using InfluxDB line protocol.

docs.influxdata.com

Given the above info, I strongly believe I should modify the way connmon currently sends data points to InfluxDB, which means that you will have to modify your own database queries to properly extract and display the data fields (and tags).

I'll make the code changes tomorrow evening unless a valid, reasonable, and logical argument is presented against making the changes.

 

[scootertramp]

@scootertramp,

Well, as mentioned earlier, I was very curious about how InfluxDB handles "data tags" vs "data fields" so I took a closer (but not an exhaustive) look this evening, and it turns out that a proper InfluxDB database for connmon ping test results should store the actual data as "fields" not "tags" because you can make proper database queries *and* perform numerical operations/comparisons with "field values" but not with "tag values." That's also part of the reason why "data fields" are required by InfluxDB, but "data tags" are only optional.

IOW, if ping test results are stored as "data fields," you could, for example, make a database query to extract data that is greater/lower than some specific threshold (i.e. "Ping Average values greater than 20 sec." or "Line Quality values lower than 90%."). These kinds of queries are not possible when stored as "data tags."

Here are some screenshots of the relevant info taken from the following docs:

InfluxDB glossary | InfluxDB OSS v1 Documentation

Terms related to InfluxDB OSS.

docs.influxdata.com

InfluxDB line protocol tutorial | InfluxDB OSS v1 Documentation

Tutorial for using InfluxDB line protocol.

docs.influxdata.com

View attachment 69507

View attachment 69508

View attachment 69509

View attachment 69510

Given the above info, I strongly believe I should modify the way connmon currently sends data points to InfluxDB, which means that you will have to modify your own database queries to properly extract and display the data fields (and tags).

I'll make the code changes tomorrow evening unless a valid, reasonable, and logical argument is presented against making the changes.

You will get no argument from me on this.

 

[Martinski]

You will get no argument from me on this.

OK, I've made the changes to make sure actual ping test results are assigned to "data fields" instead of "data tags" per the InfluxDB documentation on their database schema structure.

Please try this latest 'develop' branch v3.0.10_25121222 version. As mentioned before, it's very likely that you will have to make some changes and adjustments in the way you query the InfluxDB database to display the data fields and associated tags in one single row as opposed to one row per field.

 

[scootertramp]

OK, I've made the changes to make sure actual ping test results are assigned to "data fields" instead of "data tags" per the InfluxDB documentation on their database schema structure.

Please try this latest 'develop' branch v3.0.10_25121222 version. As mentioned before, it's very likely that you will have to make some changes and adjustments in the way you query the InfluxDB database to display the data fields and associated tags in one single row as opposed to one row per field.

View attachment 69514

v3.0.10 on RT-BE88U
[Branch: develop]
HELP [v3.0.10_25121222]

Thanks much.
Looks like this new structure will work even though it shows strange in the InfluxDB WebUI.
I need to spent some time learning FLUX query.

From a simple API call it looks good. (select * from PingTest)

i@rp5-util03:~ $ ./pingtest-query
name,tags,time,Jitter,LineQuality,PingAvrg,PingServer,Router,Source
PingTest,,1765615665000000000,15,90,30,8.8.8.8,RT-BE88U,connmon

And from Grafana I can get what I was looking for. (After adding a second data point)

 

[scootertramp]

Enabled the export to look at this new datasource.
First pass at using the data.
Works the nuts.
Again, Thank you for your efforts.

 

[Martinski]

Enabled the export to look at this new datasource.
First pass at using the data.
Works the nuts.
Again, Thank you for your efforts.

View attachment 69530

Glad to see it working out for you in the end, and also, your project with InfluxDB and Grafana seems to be going well.

Thanks for sticking with me through all the trials and errors while trying to figure out what worked and what didn't. It was an interesting learning experience for both of us, IMO, and proved that we, old dogs, can still learn some new tricks… LOL!!!

I appreciate your collaboration, and best of luck with your project.

 

[Martinski]

FYI,

The latest 'develop' branch version v3.0.10_25121620 includes modifications to the CLI top Main Menu to separate some groups of options and settings into their own sub-menus. This is an attempt to make the top Main Menu shorter, more manageable, more user-friendly, and to improve the user experience. Feedback is welcome before the next production release is issued sometime over the coming weekend.

To switch from the currently installed production release to the latest 'develop' branch version, type the following command on an SSH terminal window:

/jffs/scripts/connmon develop

Sample screenshots:

 

[scootertramp]

FYI,

The latest 'develop' branch version v3.0.10_25121620 includes modifications to the CLI top Main Menu to separate some groups of options and settings into their own sub-menus. This is an attempt to make the top Main Menu shorter, more manageable, more user-friendly, and to improve the user experience. Feedback is welcome before the next production release is issued sometime over the coming weekend.

To switch from the currently installed production release to the latest 'develop' branch version, type the following command on an SSH terminal window:

/jffs/scripts/connmon develop

Sample screenshots:

View attachment 69598

View attachment 69599

View attachment 69600

View attachment 69601

Nice improvement.