Strit

joined 3 years ago
MODERATOR OF

CPU usage on the server is about 5-10% (it does loads of other things too), so home assistant is not using much.

Maybe about 18 repeaters all over the house.

[–] Strit@lemmy.linuxuserspace.show 1 points 2 days ago (2 children)

Thanks. All the plugs and bulbs are routers, so I have about 20 routers in the network, so that shouldn't be an issue.

I've repaired an item or two multiple times the last couple of days.

[–] Strit@lemmy.linuxuserspace.show 2 points 2 days ago (5 children)

I could be close to the limit, I have about 46 devices on the ConBee2. But it is a new problem, I would have thought this would be happening as soon as I started nearing the limit, not months after it.

[–] Strit@lemmy.linuxuserspace.show 1 points 2 days ago (2 children)

I have not added anything new in the last couple of months.

22
ZHA started randomly dropping devices (lemmy.linuxuserspace.show)
submitted 2 days ago* (last edited 2 days ago) by Strit@lemmy.linuxuserspace.show to c/homeassistant@lemmy.world
 

For years I have had my zigbee network functional with a ConBee2 zigbee coordinator in my home assistant box.

But this week, devices started to randomly drop off the zigbee network. I could re-pair them and get them in again. But yesterday, it suddenly dropped 24 devices... Sensors, buttons and lightbulbs seem to be the most common ones.

I've restarted the ZHA integration, restarted the docker container, even downgraded to 2026.8.3. Still the same.

I checked the Home-Assistant github repo issues and there are lots of issues regarding zigbee and dropped devices in the last 2-3 weeks.

Does anyone have any suggestions as to why this happened all of the sudden?

The zigbee network has been stable for years before this.

EDIT: At this time I have re-paired all the devices and will see if they start dropping off again.

This reminds me of the Docker issue they fixed in Omarchy recently. Basically you could get root through the docker socket, because the default user groups included the docker group.

[–] Strit@lemmy.linuxuserspace.show 1 points 1 month ago (3 children)

Almost true.

It is pretty picky, as it expects a certain folder structure to get all the info correct when importing. But it is fairly easy to go in and manually "fetch" the correct metadata from one of the metadata providers (Amazon, Google Books, Open Library etc). It's a chore if you have big library with many different structures, but doable if you don't want to rename all folders.

[–] Strit@lemmy.linuxuserspace.show 3 points 1 month ago (1 children)

And you can check the shasum of the binary to see if it actually matches that provided by the developers of the application.

A malicious PKGBUILD, which is what is being talked about, you would see that it downloads a binary that does not come from the developers and so you should not install that.

If the attack happens on the developers repo, not even Linux repository packages would be safe at that point (eg, the xz heist).

[–] Strit@lemmy.linuxuserspace.show 2 points 1 month ago (3 children)

Rarely, but I check the PKGBUILD to see if the binary is what I expect it to be.

[–] Strit@lemmy.linuxuserspace.show 4 points 1 month ago (5 children)

But if you read the PKGBUILD, you would see that it downloads and runs a black-box binary and should therefore not install it. It's a little harder with PPAs I think. The build files are not so easily found.

 

This seems newsworthy.

The 2 lead project members have left the project for different reasons.

They state that the project will continue as it has always done, since it has a council (which I didn't know), so we shouldn't worry.

There was an argument regarding AI policies in the projects between some of the core contributors, which I think has influenced some of this decision.

 

There is currently a malicious attack going towards the AUR, in the form of a botnet impersonating git users/maintainers to take over packages and adding a malicious payload.

Arch team is aware and working hard to reset/delete the affected commits and packages.

 

Not properly released on kernel.org yet, but 7.0 has been tagged on the kernel git repository.

 

Four years since the launch of the Raspberry Pi 4, the Raspberry Pi 5 has arrived with a performance boost and house silicon that adds support for PCIe 2.0.

 

FOSDEM is a conference where thousands of open source developers meet and learn.

Location is as always in Bruxelles, Belgium, Europe, Earth.

Any of you going this year?

12
submitted 3 years ago* (last edited 3 years ago) by Strit@lemmy.linuxuserspace.show to c/kde@lemmy.kde.social
 

Hi all.

Happy KDE Plasma user for a long time and I generally love the desktop experience. But I do have one small issue.

At work, I have 2x 4K displays. connected through a Dock. But in Plasma it's only able to give me around 1080p resolution on both of them. In contrast, the display manager SDDM and TTY displays 4k on each fine.

So am I missing a trick to get the max resolution in Plasma? My install is Arch Linux, kernel 6.4.12, Plasma 5.27, Wayland session.

I did install the displaylink AUR package, as I thought it might be the dock limiting the video output, but it isn't as TTY and SDDM seems to display it correctly.

Happy to hear any thoughts and any ideas. :)

EDIT: The screens turn on and work fine with 4K resolutions in a Plasma X11 session.

 

tværpostet fra: https://lemmy.dbzer0.com/post/3076577

I posted the other day that you can clean up your object storage from CSAM using my AI-based tool. Many people expressed the wish to use it on their local file storage-based pict-rs. So I've just extended its functionality to allow exactly that.

The new lemmy_safety_local_storage.py will go through your pict-rs volume in the filesystem and scan each image for CSAM, and delete it. The requirements are

  • A linux account with read-write access to the volume files
  • A private key authentication for that account

As my main instance is using object storage, my testing is limited to my dev instance, and there it all looks OK to me. But do run it with --dry_run if you're worried. You can delete lemmy_safety.db and rerun to enforce the delete after (method to utilize the --dry_run results coming soon)

PS: if you were using the object storage cleanup, that script has been renamed to lemmy_safety_object_storage.py

view more: next ›