zigbee2mqtt-frontend
zigbee2mqtt-frontend copied to clipboard
Serve device icons locally
Is your feature request related to a problem? Please describe.
When my internet connection or the zigbee2mqtt.io server is down, Zigbee2MQTT frontend takes very long to load. See also https://github.com/Koenkk/zigbee2mqtt/issues/11908
Describe the solution you'd like
Serve device images locally.
Describe alternatives you've considered
-
Additional context
-
There are some folks running z2m on some ludicrously underpowered hardware and very space constrained. Adding all z2m images into the bundle would be death sentence for them.
I just committed some changes regarding image loading, it should solve frontend loading issues in case of offline usage Try to switch to the latest dev branch
https://www.zigbee2mqtt.io/advanced/more/switch-to-dev-branch.html#switch-to-the-dev-branch
We are speaking about 17MB:
$ du -sh koenkk/zigbee2mqtt.io/public/images/devices/
17M koenkk/zigbee2mqtt.io/public/images/devices/
IMHO, hardware that is killed by that amount of data is already dead. You can't even properly upgrade any base package with that low amount of space left.
I'm running zigbee2mqtt-frontend as part of the official zigbee2mqtt Docker image, so I'll have to wait until your changes are merged and released to see them.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Is still an issue and still not fixed.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
I would really appreciate this to be fixed. It would significantly increase privacy. There is no need to load resources from www.zigbee2mqtt.io (which resolves to ...github.io) on every move in the frontend, except for allowing github (=Microsoft) to track us. The reason I'm not using proprietary gateways / services etc. and supporting open source projects is that I don't want to be tracked.
Thank you.
Fully agree with previous comment. In addition for me full refresh of the the page is slow. With about 15 unique devices, while most of the images load in 50ms, some take 3-5s to load.
@nurikk I understand your point about users with underpowered hardware, but maybe it is possible to add a setting to the frontend config to allow users to override base URL for the images?
For example, I am serving frontend behind nginx reverse proxy and it would be very easy for me to serve images from the /images/devices/ location. This could also benefit folks with limited hardware, as they would also have an option to serve images locally but on some other host and not z2m.
I will serve the icons locally. I am full agree. That is privacy issue. That must be fixed, please Addon or an additional installation- & configuration-step.
https://github.com/nurikk/zigbee2mqtt-frontend/blob/a2e3dc31110b33aa5fe38e5e8ec7970aabf315bf/src/components/device-image/index.tsx#L19
What's stopping anyone from extending this function (that already exists!) to take an optional configuration parameter into account where you can specify a custom asset host? That can't be more annoying than fighting with the stale bot
I can only speak for myself: It's that it's more than extending that function.
- You need a way to properly configure that
- You need a way to fetch the images
- You need a way to properly distribute that
The latter will become a real pain. In the end it would lead to requiring two separate Docker images of zigbee2mqtt, one including zigbee2mqtt-frontend without images and one with images being contained. To serve @nurikk s requirement of having a small image for underpowered devices and an docker image containing the image files. Another option would be some downloading mechanism within zigbee2mqtt-frontend itself, but that would be another thing one would have to implement and would still not solve the problem for people who would want to run their zigbee2mqtt outbound firewalled.
Overall, for me, it just was not worth the effort of implementing all that + likely having some back and forth until the MR would be accpeted compared to just accepting my problem of bad frontend performance if internet is down which happens once in a year.
I don't see any fighting with a stale bot here since one year but I also will never befriend with stalebot (see https://drewdevault.com/2021/10/26/stalebot.html)
Take all this with a grain of salt as I'm quite new to this project, but
You need a way to properly configure that
There's already a way to configure the frontend via the frontend. You'd just need to extend its configuration schema with another string.
As a tip on how to approach something like that in an unknown codebase: First, find a source file that is related to what you're after, then do git blame and try to locate a commit that does something as close to what you want to do as possible.
As an example, here's a commit that added a different new config option: https://github.com/Koenkk/zigbee2mqtt/commit/1f642d86e87f91cdef32f8405a336bc26a9b8f1c
Really not that much to change. Just some schemas and test case.
As for the frontend side.. the form seems to be generated automatically from the payload from the backend? If so then that's no change at all. Translations, maybe?
You need a way to fetch the images
You mean git pull
? They're here:
https://github.com/Koenkk/zigbee2mqtt.io/tree/master/public/images/devices
You need a way to properly distribute that
See above. They're on GitHub. Same source where you also get the software from
Overall, for me, it just was not worth the effort of implementing all that compared to just accepting my problem of bad frontend performance if internet is down
I kinda suspect that the maintainers might feel the same way. It's probably just very low priority because it works fine and only causes mild unhappiness in probably less than 3% of installations.
So why this issue then? If you as the author don't even care about it then why have it in the first place?
I know the usual story is "Maybe some day someone will be looking to contribute something and then they will look at the list of feature requests" but that's frankly just not happening. It never has and it never will. There is no magic coding santa clause. Jesus also won't implement your feature requests, of that you can be sure.
This is just so very pointless and a waste of time for everyone involved. And it's everywhere in the issue trackers on GitHub. Especially worse when it comes to software close to consumer tech.
And that's likely why there's a stale bot active in the repo, because writing this reply took 40 minutes. Time a maintainer can better spend actually working on the software itself. Something that also is much more enjoyable than endless noise that leads nowhere.
Anyway, I threw in some pointers on how to approach this issue. I hope that can help reducing the scary-ness of tackling this task.
I also think that serving the icons locally is a good idea for privacy and stability reasons. The server serving the images seems to be down quite often.
zigbee2mqtt supports Base64 encoding them directly for Home Assistant. They don't even need to get downloaded en masse, when a url is found, instead snag it, encode it, and store the image that way maybe?
On Sat, Nov 11, 2023, 14:54 setfire2 @.***> wrote:
I also think that serving the icons locally is a good idea for privacy and stability reasons. The server serving the images seems to be down quite often.
— Reply to this email directly, view it on GitHub https://github.com/nurikk/zigbee2mqtt-frontend/issues/1477#issuecomment-1806903637, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHROWYMOGMAKTVRNMNJ2I3YD7JV3AVCNFSM5V6ZN632U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOBQGY4TAMZWGM3Q . You are receiving this because you are subscribed to this thread.Message ID: @.***>
zigbee2mqtt supports Base64 encoding them directly for Home Assistant. They don't even need to get downloaded en masse, when a url is found, instead snag it, encode it, and store the image that way maybe? …
This is a good point. Maybe someone can create a javascript code to automate this process?
Okay folks, I just implemented feature for you.
- Update to the latest dev
- Navigate to Settings -> Tools -> Click
Localise device images
This will download your device images and save them locally in devices.yaml
as base64 data uri.
Every time when you add new device, you have to run this procedure again in order to update image
How cool is this? Thank's man! I will try it as soon as this development makes it into the latest koenkk/zigbee2mqtt development Docker image.
@Koenkk ;-)
as soon as a new frontend release is made it will be in development dev docker image, awesome @nurikk !
Looking forward to being able to host the images locally, thanks for adding that.
the zigbee2mqtt.io site is down right now (like, extremely down, I can't even dig -t ns
the domain), so I would join the people suggesting that this just be the default.
I have been playing around in having a nginx as a server for the images. I can display the images in a browser, aka using the url http:/images.xyz.home/zigbee2mqtt/devices/BSD29.png However I put this url in the icon setting for the device, I do not get an error message nor the image being displayed! Infact no image is displayed, not even the zigbee logo. I have tried the internet url https://www.zigbee2mqtt.io/images/devices/BSD29.png of the image, this works, as the icon setting . Anyone else have this type of setup working?
I have been playing around in having a nginx as a server for the images. I can display the images in a browser, aka using the url http:/images.xyz.home/zigbee2mqtt/devices/BSD29.png However I put this url in the icon setting for the device, I do not get an error message nor the image being displayed! Infact no image is displayed, not even the zigbee logo. I have tried the internet url https://www.zigbee2mqtt.io/images/devices/BSD29.png of the image, this works, as the icon setting . Anyone else have this type of setup working?
FIXED: Found the issues, need TLS (https) and a CORS policy, generated certs, and updated nginx to support cors as well.