Add support for the new Transmitter ID and Sensor Code fields

[inventor96]

Is your feature request related to a problem? Please describe.

Nightscout has a new feature (currently in dev as of writing this) to include separate fields for Transmitter ID and Sensor Code.

Describe the solution you'd like

To enable better visibility and user experience, xDrip+ should pass these fields when the respective events occur.

Describe alternatives you've considered

As far as I know, the only alternative would be to manually edit the treatment in Nightscout after xDrip+ has sent it.

Additional context

See nightscout/cgm-remote-monitor#6780

[Navid200]

What would be the benefit of having the sensor code in Nightscout?
How about the transmitter ID?
You use a new transmitter once every 3 months, no? Isn't it easier to just enter the ID manually once every 3 months into Nightscout if for some reason it needs to be there?

[tolot27]

Some explanation can be found here: nightscout/cgm-remote-monitor#5442 (comment)

[inventor96]

What would be the benefit of having the sensor code in Nightscout?

The link from @tolot27 is definitely applicable. For a specific use case, I restart my G6 sensor sessions for as long as the readings are clean enough, which means I need to re-enter the sensor code. Right now, my current method is to keep the respective part of the sensor insertion kit for later reference. It would be helpful to have a consistent location to store the sensor code without having to worry about loosing a piece of paper.

How about the transmitter ID?
You use a new transmitter once every 3 months, no? Isn't it easier to just enter the ID manually once every 3 months into Nightscout if for some reason it needs to be there?

If the user is already required to enter the TX ID into xDrip+, any additional places they have to enter it are inherently inconvenient, especially when xDrip+ is already communicating with Nightscout and could send it there for them.

[Navid200]

Thanks for answering my questions.
So, it is a matter of convenience, not necessity. That's really what I wanted to confirm.

May I ask you to please have a look at this open issue?
#813

This guy's xDrip alarm wakes up his wife every night. And we have told him to put up with it. We have not made the modification to xDrip to address his issue.

Comparing that issue to this one, if we were a judge and had no personal preference, which one should we consider to be more critical? Do you see any reason this issue would be considered more critical than that?
If we don't allow someone to lower the volume on his phone when the xDrip alarm goes off, should we help someone keep a record of a 4-digit code, which is already printed on a piece of paper?

xDrip is a complicated code now because too much capability has been added to it.
This whole concept of having a repository and having it open source is sustainable if new developers join.
I can show you so many issues where the person who had opened it says I cannot figure out the code so I don't want to do it myself.
The more complicated we make the code, the less likely it is to get people to start contributing.

My suggestion is that we open an issue if we have identified a critical issue that is absolutely necessary. Otherwise, we find a way to use xDrip as is. That's just a suggestion.

[Navid200]

Just in case you haven't considered the option, you can see both the transmitter ID and the sensor code on the G5/G6 status page. You can take a snapshot. Every time, you place a new sensor, you can take another snapshot and replace the old one with it.

[Navid200]

You can also find your calibration code in the event logs. After you open the logs, if you search for "calibration code", you will see it.

[sjennison]

Thanks for answering my questions.
So, it is a matter of convenience, not necessity. That's really what I wanted to confirm.

May I ask you to please have a look at this open issue?
#813

This guy's xDrip alarm wakes up his wife every night. And we have told him to put up with it. We have not made the modification to xDrip to address his issue.

Comparing that issue to this one, if we were a judge and had no personal preference, which one should we consider to be more critical? Do you see any reason this issue would be considered more critical than that?
If we don't allow someone to lower the volume on his phone when the xDrip alarm goes off, should we help someone keep a record of a 4-digit code, which is already printed on a piece of paper?

xDrip is a complicated code now because too much capability has been added to it.
This whole concept of having a repository and having it open source is sustainable if new developers join.
I can show you so many issues where the person who had opened it says I cannot figure out the code so I don't want to do it myself.
The more complicated we make the code, the less likely it is to get people to start contributing.

My suggestion is that we open an issue if we have identified a critical issue that is absolutely necessary. Otherwise, we find a way to use xDrip as is. That's just a suggestion.

I'm going to sound pretty bad here, so I just want to preface by saying none of this is intended to come off as insulting.

This response does not fill me with confidence in the ability to maintain and enhance this app. Responding to a (legitimate) feature request with "look at this other legitimate feature request that we're ignoring", which is how I read this reply is.. not a good look.

I understand the question of added code/technical debt/added complexity, and it's a valid response to feature requests - to a point - although I see no reason this particular feature request would cause a noticeable increase in code complexity.

Is it the stance of the xdrip maintainers that new features will not be implemented into the app due to the added complexity? If so, is this stance published somewhere?

[Navid200]

how I read this reply is..

What you are reading is not the intended message.

There are limited number of developers. Therefore, all the requests, even if they are legitimate by all standards, cannot be implemented right away.
We are organizing the open issues and asking the user community to be reasonable.
We postpone requests that are not high priority.
That's all.

[Navid200]

I am closing this but have tagged it as postponed. So, we can talk about it later when we have more developers available to consider it.

[sjennison]

I am closing this but have tagged it as postponed. So, we can talk about it later when we have more developers available to consider it.

Shouldn't postponed issues remain open, so they can be discussed and potentially new developers (like myself, which is why I'm even here in this issue thread) can look at them and work on them?

My suggestion is that we open an issue if we have identified a critical issue that is absolutely necessary. Otherwise, we find a way to use xDrip as is. That's just a suggestion.

^ this seems to conflict with the idea of "closing" issues and marking them postponed. Should feature additions and non-critical bugs be opened as issues or not? General understanding of how Github works would indicate yes - are you suggesting people should not open issues for these and keep "using xDrip as is"? The whole point of creating issues is to make the software better - using it "as is" is something we can do already.

What you are reading is not the intended message.

Please explain what it is, then. Because I can't find a way to interpret it other than that.

[Navid200]

We are organizing and prioritizing issues.
We close the duplicate issues. We ask the community to use the support channels for asking questions instead of opening issues. And we close the issues that we postpone and we reopen them when the time comes.

We don't want the developers to have to do this, because it takes time. We don't have many developers. So, we are doing this to help them.

People have used these issues to ask questions like "I am buying a new phone; which phone do you suggest I buy"?!
We are closing all such issues and tell people to use the support channels for asking such questions.

There are real issues that are nice-to-have. And there are issues that are absolutely critical. We are prioritizing.

Don't think that after a feature has been developed, we are home free.
Look at this open pull request:
#584
This uploads the battery voltages to Nightscout. It would serve the community immensely. There is no real work-around. The voltages change twice a day. The only record available in xDrip only contains the values for today and yesterday. All the precious values are discarded. This was developed almost 3 years ago.
But, it hasn't been merged. It's not just adding a capability that we need. We need to make sure that it doesn't break anything else, and we need to make sure that we can maintain it.
The developers have to spend time reviewing these pull requests.
The more complicated xDrip becomes, the harder that could become also.

We're not suggesting that xDrip should not evolve. Absolutely not. We just want it to be managed and coordinated.

So, let's focus this conversation on this issue.
If you feel this issue (uploading the transmitter serial number and the sensor calibration code to Nightscout) is necessary, please explain why. You can explain why the work-arounds I have suggested are not useful.

But, if you prefer to continue talking about what we are doing, instead of the subject of this issue, perhaps @tolot27 and I may need to open an issue dedicated to that conversation.