I do this with my desktop - I work from home so it’s really nice to have my PC ready by the time I get down to it. There’s a workday integration too, set your typical schedule and it’ll be true when it’s a workday - with a motion sensor as the trigger as my start time varies if I have meetings In the morning.

This is one of the first things I set up with HA for fun but the convenience is really nice.

Yes, based on my migration from a Raspberry Pi to a mini x86 pc. A full backup contains a complete snapshot of that moment and all your configuration, history, and all add-ons and their data. I think HACS came across too, though I can easily be misremembering.

The restore looked like it tried to do everything but my large database add on (PostgreSQL) gave it grief so I ended up restoring components separately. The backups did work overall though, and after a few reboots everything worked.

The add-on store that’s managed and updated via the supervisor. It does the same thing as your setup, but integrates into HA nicer (automatic connectivity to HA for the containers, when they need it). If you’re happy with how your setup works then there’s no compelling reason to switch.

Iirc that’s where they start ERs yes - it’s easier to see, vote, and comment on them there compared to GitHub. It’s also the source for the month of WTF where it seemed like a lot of the easier ERs get addressed.

Not according to the integration documentation: https://www.home-assistant.io/integrations/recorder/

The recorder integration only supports: domains, entities, events, and entity globs right now. I think that’s a good idea though, should check or create an enhancement request!

First thing - exclude recording of the devices. My method was to use a glob so I name devices/entity IDs specifically and they don’t get recorded (in my case I used f_ as in “filtered” so devices become like “F Source Presence”), but you can add specific entities or use your own glob. In configuration.yaml I have this:

recorder:
  exclude:
    entities:
      - sensor.excluded_entity_1
    # AND/OR this (then of course rename entities as needed)
    entity_globs:
      # exclude all sensor entities that start with f_
      - sensor.f_*

Then I created templates for my presence sensors, that just copy the state so I get history (yaml here, but can do through UI now too in the Helpers section, the import part is the template in the state key below):

template:
  - binary_sensor:
      - name: Real presence
        unique_id: my_presence
        state: >-
          {{ states('binary_sensor.f_source_presence}}
        availability: >-
          {{
            not (
              states('binary_sensor.f_source_presence') == 'unknown' or
              states('binary_sensor.f_source_presence') == 'unavailable'
            )
          }}
        device_class: presence

You could also use a statistics sensor to get a moving average for numeric values and get history from them too (and reduce the noise by reducing the precision and having a larger time window). This is also available through the UI - Helpers.

I’m curious too. As I understand it (and based on my observations after playing with it), it doesn’t change how often they send data to the controller, but instead changes how often the controller passes the data on. It doesn’t help the network, just the MQTT/Home Assistant side, but it can mean they flood the database less, if they’re tracking a value (like temperature). If they’re following a state (open or close) then I find they would miss the important messages and just not work well.

In my case I’ve found a few Tuya devices that seem like they have bad firmware and flood the zigbee network - human presence sensors and co/voc/climate sensors. I experimented with denouncing them, but I still ended up retiring most of those devices as they degraded my network performance and other devices couldn’t communicate very well. If it actually prevented the devices from flooding the network it would make a lot more sense to use.

I still have database filters to not record the main entities (for the mmWave presence sensors that I’m still using) and instead use a template on them to record their state as I found my database grew in size very quickly otherwise.

I’m using project boxes from Amazon, like these: https://a.co/d/4R4Dtv5 before I had a 3d printer to make something bespoke. Some of the boxes have the ESP board glued down, some it’s loose. It works well enough and doesn’t look too bad. I still use them now as it’s easier to throw everything into a box instead of designing something specific to the project.

Then to link the entities together into a device you need to mimic the auto discovery, or you just have two split entities.

I suppose you could create a template entity with the battery as an attribute to see it in the details view, but you still need the entities with the raw data. I’d be more inclined to create the device with auto discovery, seems like a cleaner way to go.

Zigbee2mqtt should do device auto discovery by default (it did for me and I didn’t have to do anything). Maybe you’ve turned something off? The alternative I can think of is to manually create and maintain device auto discovery records like https://stevessmarthomeguide.com/adding-an-mqtt-device-to-home-assistant/ shows (for example).

Maybe look at something like a template trigger that checks the last_updated property of the state object? If it’s older than n hours ago it’s triggered?

Why not set up an automation for when it disconnects (goes into unavailable or unknown state probably) and send a notification? That’s relying on the actual problem (Nest goes offline) rather than a side effect of the problem (notification that the integration is broken).

Try executing just /config/backup.sh - the config directory is mapped into the HA container under /config, not under /root.

Zigbee is a mesh network so it’s a bit different. Zigbee devices can be an end device, or a router device (in addition to whatever it actually does likes controlling a plug). Routers contribute to your zigbee mesh, and devices connect through the mesh. This means you need more router devices to have a strong mesh. I use a few plugs where my network is weak, but otherwise have found that devices are stable. I can’t see on the zigbee2mqtt site if they’re a router or end device, but most powered devices are routers. ZHA and Zigbee2mqtt both tell you the device type if you go digging.

If they’re zigbee devices I don’t think they can be flashed with esphome. They’re not normal esp devices and that would likely disable the zigbee networking.

There is an add on available to help offload backups via SFTP too.

Also check HACS, I’ve seen some weather related integrations there that might work instead.

I don’t use that integration, have you looked at configuration options to see if hourly can be turned on?

If there’s no obvious options it’s likely not supported natively. You could create a restful sensor to retrieve it, just be mindful of api limits.