Sensorgnome V2 feature wishlist

The Sensorgnome V2 software development started late 2021 with the goal to update the system to the latest standards and rebuild the web interface to allow enhancements and support mobile phone use. A lot has happened since but of course more is always possible! I’d like to try and use this thread to capture feature wishes as well as discussion of issues so I can focus my time on what hopefully will make the biggest impact. I will try to keep this first post up-to-date so someone new doesn’t have to read through all posts.

As of June 3rd 2024 the top items on the list are:

  • incorporate FUNcube restarts when devices drop out or sample rates drop (per FUNcube sample rate dropping and disconnecting - FIXED)
  • create a release candidate with this fix (and other accumulated improvements)
  • hopefully promote release candidate to “V2.0 release” soon thereafter
  • look at download ZIP filename and at preserving directory structure
  • show ICCID (from SIM info)

Beyond that, some of the items I have:

  • look into showing MAC address in UI
  • display signal strength of cell carriers (scan) – need to check ModemManager upgrade & capabilities
  • provide remote access to the web UI (TvE)
  • improve detection of malfunction / mis-configuration and notification of owner via SGhub (TvE)
  • report under-voltage alert in web UI / SGhub (Josh)
  • control over how long hot-spot remains active. e.g. option to set auto-off to 30 min, or never (Josh)
  • separate panes for CTT and Lotek tags, possibly even separating (or otherwise indicating) recognized tag IDs among the pulses (Josh)

Please feel free to reply to this post and chime in!

Thanks, Thorsten.

Here are a few others…

Cell-related

  • Display IMEI and/or ICCID
  • Timeline chart for cell related indicators, such as modem status, network connected to, etc. This may end up being really helpful to identify which network a particular location connects to most often or reliably

Tag databases

  • Loading multiple tag sqlite databases (currently the new one overwrites the old)
  • Assuming multiple tag databases are supported, break down total number of tags by file and display file names
  • Display the properties of the tags in the tag database(s) loaded

General

  • display most (or all) of the same plots and timeline charts from sg.net on the device web interface since this can be useful while actually at a site, especially if it’s a non-connected station. And vice versa.
  • one page display in the web UI by default (though maybe I’m in the minority with this wish!)
  • the underlying Debian seems to be UK keyboard layout by default. Can that be changed to US?
  • display MAC address on the web UI. It’s often requested by Universities and like when allowing it on their networks.
1 Like

Will be in the next image (>2024-148)

SGhub currently has some of this info (see bottom 4 lines), is this what you’re looking for?

Makes sense. The reason I’ve kept the tag database bare minimum is that the encoding is supposed to become public eliminating the need for it. I can look into the amount of effort required to be able to add multiple databases, remove them, and display all the tag info… It may be quite some work and you can join your own sqlite files as you desire as a work-around.

The SGhub (https://www.sensorgnome.net) has a full-blown time series database, which the Sensorgnome doesn’t have. I need to redo a lot of SGhub but even just storing all the data on the Sensorgnome would cause a lot of I/O.
It seems to me that looking ahead the best path is to make SG connectivity cheaper and easier, make SGs simpler, and concentrate data and smarts in SGhub. The stuff that needs to be in the SG is what’s necessary to ensure that it works at the moment of installation, and “ancillary” functionality to perform antenna/range/tag tests. I’m open to suggestions!

I believe you can set that when flashing using the raspi installer. I’ve left it at the OS default.

You can get the MAC info from SGhub from the “info” log. I took a quick look and it’s not a trivial addition to display it in the UI (I have to fetch&parse the data) but can probably do this in the future.

Thanks for the info.

SGhub currently has some of this info (see bottom 4 lines), is this what you’re looking for?

Yeah that carrier info is present; wonder where (or when) it was that I wasn’t seeing it!

Makes sense. The reason I’ve kept the tag database bare minimum is that the encoding is supposed to become public eliminating the need for it. I can look into the amount of effort required to be able to add multiple databases, remove them, and display all the tag info… It may be quite some work and you can join your own sqlite files as you desire as a work-around.

It’s not worth it if it’s not super simple

You can get the MAC info from SGhub from the “info” log. I took a quick look and it’s not a trivial addition to display it in the UI (I have to fetch&parse the data) but can probably do this in the future.

Great, I do see that in SGHub. I don’t see it in the web UI, though maybe I’m not looking in the right place.

1 Like

Comparing relative signal strength of available carriers, so that the most robust network can be selected for that SIM

1 Like

The MAC address is not displayed in the web UI.

I’ll have to correct my “and/or” to “and”. Doesn’t look like SixFab at least allows lookup by IMEI but only by ICCID. So having both would be ideal.

1 Like
  • Rapid Push for logs on by default.

Downloads via the UI

  • The “time of last download/upload” appears to reflect when the download was initiated, not when it was completed. At least this certainly happened for me once when my download was interrupted. Not sure if the completion of the download would be available to the browser, but in cases like my recent experience, it appears this would have resulted in missed files
  • When downloading, the file name is pre-populated as "foo.zip. When clicking “save” to the default download location the actual name is used, but if clicking “save as” to change the location, it will save as “foo.zip” without the identifying info.
  • Preserve folder structure that is present on the SD card, where files are grouped into folders for each day. Not a deal breaker but it’s consistent with the SD card and V1 SG and causes glaring outages to jump out
1 Like

Can you provide some background on why you want the rapid push enabled by default? It increases server load, server storage needs, as well as SG bandwidth consumption. If it’s off and you turn it on it essentially uploads all logs within an hour (bandwidth permitting), is that not sufficient?

I’m not sure I understand the “time of last download/upload” issue. It seems you are saying that you initiated a download but something failed in the browser so you couldn’t save the file and then the UI updated? That’s unfortunately quite possible as there is no real “download complete and file saved successfully” feedback from the browser. The UI has a button to retry the last download and then as fall-back a button to download all data. I’m not sure what else I can provide but am open to suggestions.

About the download file name, which OS/browser combo are you using so I can reproduce? I’ll see whether I can fix this, I remember struggling with some stuff around the file naming but not the details. I had not noticed the save-as issue…

I can look into the folder structure, I don’t know what it entails. The software creates the zip archive on the fly (it never hits the SDcard) and there were some limitations.

Can you provide some background on why you want the rapid push enabled by default? It increases server load, server storage needs, as well as SG bandwidth consumption. If it’s off and you turn it on it essentially uploads all logs within an hour (bandwidth permitting), is that not sufficient?

There have been a lot of issues with cell connectivity still and often a station will only briefly connect again before blinking out. Seems that sending the logs as quickly as possible makes sense so that diagnostic information is available. I didn’t think there was much data involved and that sending it in one shot vs spread over (how long?) made that much difference. But perhaps that’s not the case…

I’m not sure I understand the “time of last download/upload” issue. It seems you are saying that you initiated a download but something failed in the browser so you couldn’t save the file and then the UI updated? That’s unfortunately quite possible as there is no real “download complete and file saved successfully” feedback from the browser. The UI has a button to retry the last download and then as fall-back a button to download all data. I’m not sure what else I can provide but am open to suggestions.

That’s correct. I only realized this when a download very conspicuously failed but the “last downloaded” time was updated nonetheless. The risk with this is that data is missed, but there is no indication that that had happened. The safe bet may just be to select “download all” every time to ensure that everything is downloaded, but that can take a while and would be unnecessary in most cases…

One thing I really liked about the previous method of downloading via SFTP is that you could browse the folder structure and choose when to download from. What about an option to select the start date of the data to download? Via calendar picker or something. That way you could always ensure you are downloading data from the appropriate data, without downloading more than needed. And yes, having all of these on cell or otherwise connected would be great, but in reality that will be a while and there will always be some manual only stations…

About the download file name, which OS/browser combo are you using so I can reproduce? I’ll see whether I can fix this, I remember struggling with some stuff around the file naming but not the details. I had not noticed the save-as issue…

This is mostly on Vivaldi/ Win 10. However I just tried right now and though it’s displayed as “foo.zip”, it saved with the correct name with both methods.

image

FWIW I’ve been having a lot of issues downloading on various browsers. Often it just fails or there is a “server not found” message (while still connected). On various browsers and devices, but it’s all been quite intermittent so difficult to replicate. On my last trip, though, downloads went much better generally.

I can look into the folder structure, I don’t know what it entails. The software creates the zip archive on the fly (it never hits the SDcard) and there were some limitations.

It’s not worth spending time on if it’s not super simple! But maybe you can clarify since I’m not following Wouldn’t the files already be stored on the SD card with that folder structure