KE7FNS wrote:
Toshen used to be an active member of this forum. He updates his personal documentation pretty frequently whenever he feels the need to do so.
...
Where who announced what? And nothing changed, its the same as its always been.
I was referring to you saying he defined the expected behaviour in some documentation somewhere and was wondering if you had a link.
Most docs I read -- and I'd be happy to read "official docs" if they exist...
Essentially say that a static talk group set at the self help Brandmeister page is "always on" and a non static times out after some period of time.
KE7FNS wrote:
Its NOT a bug. Its doing exactly as it is meant to do. You have static groups listed in in the "Static TG" column. The one you are currently monitoring is IN THAT STATIC LIST, and it is NOT a dynamic talkgroup after 15 minutes.
Hmm ok. I can double check, but that was NOT the behavior in my screenshot. The talk group being actively received was not listed in EITHER box.
But now that I know the expected behaviour, I can see if it's reproducible. Thanks.
KE7FNS wrote:
The UI does not say its "not connected", its showing you that you have static TG's assigned and at least one of them is active.
The conversation being transmitted by my hotspot was not coming from a talkgroup listed as static or temporary in the UI.
To be clearer "not connected" == "didn't exist on the screen at all" in this discussion.
KE7FNS wrote:
If you don't want to monitor a talkgroup anymore all you have to do is properly disconnect by keying TG 4000. The same way it has always been.
Clearly. And I believe I mentioned in the first post that was how I stopped the transmissions. If I forgot, apologies.
There was no lack of control. The issue was a display only issue.
I'll go look at the original post but I suspect it wasn't taken literally as the behavior seen.
Anyway. Enough about that. I'll try to reproduce.
...
Meanwhile it does pose a UI/UX design question in my mind...
If a temporary talk group is going to switch over and move into the static box after 15 minutes anyway, what's gained by even having a box showing the user it's a temporary?
It's being treated like a static until you key TG 4000 and turn it off anyway. If the behaviour is as you've defined.
Just a thought. Seems odd.
Most websites I run into seem to indicate many folks think non-statics time out after 15 minutes of no local keying activity of the talkgroup.
As they say... Always read the documentation written by the source/author, but I haven't found any. I'm stuck with whatever Google finds.
I was under the assumption you were referring to Toshen as a developer and his GitHub or similar official documentation. So was asking for a link.
I believe what you're saying is it was just a post here sometime in the past by an enthusiast.
A quick google search finds a blog about pistar under his name also.
I was thinking he may have been a developer of one of the many modules pistar's PHP front end code is layered on top of.
...
Will see if I can get the node to reproduce the behaviour that doesn't match your description of the expected behavior.
Still, not a big deal. Just odd.
...
Oh... Forgot. Just tying up loose strings you brought up...
Didn't have time to mention it in the previous message as it was a separate tangent from the possible display bug...
You mentioned there's a few hotspots in my self service. Those are not in use and were me seeing how the two digit ending suffixes behave. I assumed self service included a way to delete them when finished with them. Just playing around to understand their behavior from behind a single public address while watching logs and a packet sniffer at the network edge.
I later saw that deleting them requires emailing somebody. Pfft. Not going to waste anybody's time with that noise.
We all have enough to do in support roles -- deleting records that should have a delete button on the web page would just be wasting someone's valuable free time. Ha.
I figured maybe I'll throw together another node to use the orphaned entries someday later anyway... Haven't gotten around to it yet, though.
Will see what I can do to reproduce this state where the node is transmitting a stream that isn't shown on the dashboard at all...
I'm pretty good at finding edge cases in state machines talking to operator displays... Too much wasted time in my youth doing it in a telecom lab... Haha. In this case, the bug isn't losing anybody any money, so it's a nothingburger. Just chasing it down for fun.
Pet the dogs. Hunt a bug. More fun than beating my head against the latest work related call flow design docs. Haha.
Cheers. And thanks.