Journiv, first featured here at https://lemmy.ca/post/55005402 might be what you’re looking for as a self hosted solution

Ah right, I misread that chart as manufacturer not integration and didn’t really look at the details. That does seem odd that Tuya is that prevalent, they don’t seem that common on troubleshooting boards which I’d expect if they were used that much. I wonder how much self selection is happening here in the labs project and how much it will change when it’s opened to the community.

Does this Tuya include Zigbee devices? I don’t have any wifi based Tuya devices but it’s surprising how many generic cheap Zigbee sensors are Tuya.

Roughly 1/3 of my Zigbee devices are Tuya branded, if you buy from AliExpress it’s a strong possibility.

Ok so you’re using docker, the drive is a USB disk?

I think you need to:

• create a mount point folder
• mount the drive in fstab so it’s available on boot
• create a dedicated user for Jellyfin to run as
• make sure the new user has read/write access to the folders with media (this may mean changing ownership, adding to a new or existing group)
• set the docker container to run as the new user
• add the mount point as a volume inside the docker container
• add the folders with media in Jellyfin

More info needed. How are you running Jellyfin? How is the drive attached? What OS?

Not sure what you mean by this - Nabu Casa has a Zwave device already called ZWA-2 which is fully supported.

A strong mesh is a better way to go to me - ensuring you have a mesh of router devies between the coordinator and the end device has worked well to ensure that no matter where the device is it works. A better antenna may help but all it takes is a glitch like your 2.4 wifi moving to overlap with the Zigbee range and the device drops out.

I have a tubesb Zigbee device with an external antenna and I’m not sure I’ll benefit from the ZBT2 but the 2.4ghz band is very busy here. I’m tempted to try it and see if it makes any difference. I find my Zigbee network ‘slow’ - like sensor updates take 1-2 seconds before HA receives them.

Bcache can’t differentiate between data and metadata on the cache drive (it’s block level caching), so if something happens to a write-back cache device you lose data, and possibly the entire array. I wouldn’t use bcache (or zfs caching) without mirrored devices personally to ensure resiliency of the array. I don’t know if zfs is smarter - presumably is can be because it’s in control of the raw disks, I just didn’t want to deal with modules.

For your second scenario - yes you can use md under bcache with no issues. It becomes more to configure but once set up has been solid. I actually do md/raid1 - luks - bcache - btrfs layers for the SSD cache disks, where the data drives just use luks - bcache - btrfs. Keep in mind that with bcache if you lose a cache disk you can’t mount - and of course if you’re doing write-back caching then the array is also lost. With write-through caching you can force disconnect the cache disk and mount the disks.

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.

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
#…

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.