I work around this with the uptime integration then conditions in automations that uptime must be over whatever time I want.
You could try using not_from in your state trigger but I’ve had limited success with that working recently. Something like this:
#…
- trigger: state
entity_id:
- event.inovelli_on_off_switch_config
not_from:
- unavailable
- unknown
#…
There’s your answer: you need an active PoE injector that follows 802.3af. None of the ones you pictured are the correct ones, they are passive not active and worst case can damage your device.
The difference is the active injector and the device communicate to determine how much power to provide, where the passive injectors just whack the device with their rated power. The device shouldn’t work without negotiation (per the spec).
Based on what I’ve seen with my use of ZRam I don’t think it reserves the total space, but instead consumes whatever is shown in the output of zramctl --output-all. If you’re swapping then yes it would take memory from the system (up to the 8G disk size), based on how compressible the swapped content is (like if you’re getting a 3x ratio it’s 8GB/3=2.6GB). That said - it will take memory from the disk cache if you’re swapping.
Realistically I think your issue is IO and there’s not much you can do with if your disk cache is being flushed. Switching to zswap might help as it should spill more into disk if you’re under memory pressure.
YouTube blocks it. There are extensions to allow it (like Vinegar) but by default it’s blocked. Brave might work around YouTube’s block in the same way.
You can try adding
continue_on_error: true
to the scene action so it doesn’t kill the entire automation. Note that if later parts depend on this action then they’ll fail in weird ways. The best thing is to fix the Zigbee network so the device doesn’t drop off but I know that’s not easy.
I’ve had to hard reset my controllers (both Zwave and Zigbee) a few times now, haven’t really found a cause but it’s usually been around times when updates were applied. It almost seemed to me like the device wasn’t released by the old container and that needed a hard disconnect to force it. IIRC logs just showed a generic can’t connect to device error but no sign of what had the device locked. First time I did some investigation, the few times it’s happened since then I just unplugged and reconnected the usb device, restarted the container and it worked after.
I haven’t had it happen for a while at least.
Check with your provider for SIP server, username and password, and if they have a suggested app (even if you don’t want to use it, it means they have some kind of support). It’s probably in their support pages somewhere.
I found this on the deConz pages - https://github-wiki-see.page/m/dresden-elektronik/deconz-rest-plugin/wiki/LQI-explained
Can you find it in the UI somewhere?
I don’t know deConz but ZHA shows RSSI on the device in home assistant, and you can see RSSI in the Zigbee2MQTT UI list of devices. I’d assume it’s something like that in deConz.
I’d say if the device is closer to the controller then I’d suspect the devices. Do you have any other devices yet or just the Aquara sensors? It’s possible they work better through a Zigbee router too so you can try connecting them via one.
How is the link strength for the devices? Do they still drop off if you leave them right by the controller? If you’re just getting started I’m guessing you don’t have a strong mesh yet with plugged in devices to provide routers to the network.
My experience is that some manufacturers are better at following the spec and devices work better or worse based on that.
Is the reverse proxy using an add on or did you roll your own? Reason I ask is proxing HA needs special treatment for websockets (wss:// or ws:// scheme). Add ons should do it themselves but I had to do it myself with Apache. I’m not sure if there’s special config needed for nginx too.
Did you set up the proxy as a trusted forwarder? That means setting use_x_forwarded_for and trusted_proxies in configuration.yaml?
Silly question but does it still work directly without the proxy (like http://homeassistant.local:8123/ )? Check the logs in system- logs and see if you can find anything relevant. AFAIK the proxy shouldn’t change how calendars get loaded.
I use an acurite 06002RM temperature and humidity sensor with a rtl 433 compatible receiver plugged into home assistant and an rtl2mqtt add on. It’s indoor/outdoor and has worked well for all sorts of weather. Combined with a sun shade and it’s a good solution I think, and completely local.
I think it’s not quite as well known or prevalent as other services (as say SSH) so likely doesn’t have anything automated attacking it yet. If you check something like http://shodan.io/ against your ip, I’d guess the service has been found.
Home Assistant likely won’t come under any kind of attack until there’s a very easy to exploit, unpatched zero-day vulnerability in the wild. Given how many people (myself included) who have HA exposed publicly it’s really a matter of time. The best mitigation is not exposing publicly if possible, and staying up to date.
In my case I don’t expose HA over 8123, I have a proxy on 443 where HA is not the default host name, meaning if you don’t use the right host HA doesn’t receive the traffic. As I’d expect that automated attackers wouldn’t what my host is it’s a reasonable layer in the security onion. I don’t expect anything would realistically protect from a targeted attack but I’m also not important enough to be targeted.
You don’t need cards to have full bandwidth, they only time it will matter is when you’re loading the models on the card. You need a motherboard with x16 slots but even x4 connections would be good enough. Running the model doesn’t need a lot of bandwidth. Remember you only load the model once then reuse it.
An x4 pcie gen 4 slot has ~7.8 GiB/s theoretical transfer rate (after overhead), a x16 has ~31.5GiB/s - so disk I/O is likely your limit even for a x4 slot.
We can’t ever stop this kind of stuff, but with something like fail2ban you can set it up to block on too many failures.
Really though - ensuring your system is kept up to date and uses strong passwords or use a SSH keys is the best defence. Blocking doesn’t prevent them from trying a few times. Moving SSH to a non standard port will stop most of the automated attacks but it won’t stop someone who is dedicated.
This sounds like you’ll need to do a balance operation. Try this first and see if it helps:
btrfs balance start -dusage=0 -musage=0 /
If not you can increase the number to 5 or 10. This operation reallocates chunks on the disk and ensures they’re filled - check https://btrfs.readthedocs.io/en/latest/Balance.html for details.
Check out this device. I have several and they work well. Zigbee temperature sensor in a cabled probe.
This. If you have any sort of set up - just do a backup and restore. All the configuration, automations, etc. will come across exactly as it was, including your subscription set up.
I’ve migrated from a Pi to a mini pc so it works between different platforms too - there I had to reinstall add ons but it was still generally an easy migration.