I’m taking the liberty of sharing my non-developer opinion…
Being able to get a signal level chart from the history would be great. Indeed, I have a few devices that tend to lose connection regularly, but I can’t find the reason, and this could help me investigate.
Similarly, I would like to receive a message if my device loses connection for too long…
So, front-end or back-end? Uh… Yes! ![]()
It’s not the same because now:
-
It’s not if(signal = 1) then such icon, it’s if(signal = 1 or signal = 44 or signal < -33 or signal > 12) to manage each brand/implementation. The distinction by brand is now managed in the front end, whereas in v4 we always handled this in the code of each service on the backend.
-
It needs to be done in all places:
-
In messages, if we code a question: is my bulb XX accessible? The answer will depend on each brand, so we will need to make if statements by brand in the message code. This example might not be something we want to do, but for example when you turn a bulb on/off and it doesn’t work, we might want to respond with something more advanced like « The bulb has had a weak signal since yesterday ». To make this calculation, we will need to call the formula in the message code as well.
-
In scenes, either we must also do the conversion to be consistent with the UI, or we ask the user to remember and do their own research on what level of LQI/RSSI means what. Which is not consistent with the UI anyway because the user will not be able to see the current value on the dashboard (or they will see a bar). Why not also display a scale of 0 to 5 in the scenes? (with a UI specific to this feature)
-
@VonOx I see that you tagged me in a PR (Signal quality feature by VonOx · Pull Request #1315 · GladysAssistant/Gladys · GitHub)
So what’s the conclusion? ![]()
Bah I made a generic feature for the signal (without unit)
@pierre-gilles I have a related question
Lucide offers a Preact package. lucide/packages/lucide-preact at main · lucide-icons/lucide · GitHub
On the Gladys side, should we stay with a web font or is the switch possible?
The switch is possible, after testing, I didn’t go into the details of the package:
- How is each icon loaded? The advantage of a webfont is that you load everything at once at the beginning, it doesn’t make hundreds of small requests (especially when you need to display the scene creation view, where you need to display all the icons)
- How does it affect the bundle size?
- How does this kind of package react on a view where you display a lot of icons? (Like a scene creation screen) Displaying 200 characters is easy, displaying 200 Preact components is heavy
Does Lucide not offer a webfont?
It’s coming, it was more of a technical question since I don’t have experience with these topics.
I don’t know if it’s worth testing because it’s a lot of work. How to analyze performance just the browser console?
Two ways:
- Indeed, the console is your friend, you can check in the « Network » tab what’s really happening when you load an icon (is there an initial load or does it make a GET per icon?)
- Otherwise, you can build the front end locally by generating a bundle analysis with the command:
npm run build-with-stats
This will generate a stats.json file that you can visualize with a tool like https://www.npmjs.com/package/webpack-bundle-analyzer
Installable like this:
npm i -g webpack-bundle-analyzer
And then:
webpack-bundle-analyzer stats.json
This will display in your browser something like this:
It’s very simple and practical ![]()
Is anyone working on this?
The « signal » feature is coming soon! But we still have nothing to display.
Not me! My two current focuses:
- Fixing all feedback on the graphic display + as soon as everyone is satisfied, communication on the feature
- Then, Alexa integration
We need to be patient.
FeatherIcon is no longer maintained and clearly abandoned, a community fork exists with a current focus on addressing Feather issues/requests.
Feather does not have signal icons
.
In progress on the lucid side Add `signal*` icons by ericfennis · Pull Request #428 · lucide-icons/lucide · GitHub
The fork does not yet offer a webfont, but it’s coming
https://github.com/lucide-icons/lucide/pull/401
I will keep you informed here:
- First, the migration from Feather → Lucid
- Then, implementation of the feature
For integrating the lucide library, we can work on it together, there are over 400 icon references on the front end.
I quickly tried it this morning.
@VonOx Why not just add the signal icons for this view instead of changing the entire lib? It seems a bit disproportionate to do all this work just to display a few poor network icons ![]()
Why not download the network SVGs?
Lucide looks nice, but well, no webfont is a bit blocking…
As mentioned earlier, the webfont is coming. Feather was nice but very, very limited in icon diversity, and I’m not the only one with this opinion (let’s not forget that on the other side, we have MDI with thousands of icons).
If you don’t want to change the library (that’s the impression you give), say so right away, it will save time.
In short, the reason, there are plenty of messages on the forum.
No worries about changing the icon set ![]()
Lucide actually looks great, it keeps the simplicity of Feather but with a few more icons, I wouldn’t mind switching to Lucide at all. Of course, it needs to be tested, but in principle, and in terms of design, I don’t see any drawbacks.
After all, since the topic was about signal-strength, and since we don’t know Lucide’s timeline regarding the webfont, I was just proposing an alternative in case we still want to display the signal-strength
To perform the migration, there won’t be much to do (as long as the icon keys haven’t changed since Feather, otherwise a migration will be needed), we have a repo with the theme, which I forked this summer because tabler had some blocking bugs regarding Gladys:
Hello here,
I understood that integrating the new icon collection was not a small task.
But I have another question, I understood that the value of this feature should have been between 0 and 5.
Wouldn’t it be more judicious to use the min/max attributes on the feature to determine the power and the ratio (x/5)?
Because I think we will very quickly forget this constraint during the development of the services.
Whereas on the front end, we could calculate the ratio between min and max.
And for the scenes on the other hand… I have not looked into the matter ![]()
Yes, because there are 5 or 6 icons that represent the graphical state
That seems like a good idea
Why not just integrate these icons (In on mode, we put the 5 svg in Gladys, and we import them in the components?)
Except that we had said that it was the back that did the calculation, right?
What you are assuming is that it is always a linear scale, I am not sure that is always the case.
( By linear scale, I mean that if the value goes from 0 to 100, then 0 = 0 bar, 20 = 1 bar, 60 = 3 bars, …, 100 = 5 bars )
Why not just integrate these icons (In on mode, we put the 5 svg in Gladys, and we import them into the components?)
Yes, or even with CSS.
There, what you assume is that it’s always a linear scale, I’m not sure that’s always the case.
Indeed, that’s what I assume.
I only know the distance with Bluetooth (rssi) and the lqi of z2m.
But I haven’t conducted a more in-depth study.
When talking about icon sets, I never realized that Tabler (our theme) had their own icon set, and it’s clean!
What do you think?
