Ohhh I haven’t seen that Zooz relay before, hopefully I can get it in Canada. Going to see about replacing the Shelleys I’ve got deployed then
Ohhh I haven’t seen that Zooz relay before, hopefully I can get it in Canada. Going to see about replacing the Shelleys I’ve got deployed then
The thermostat should be a passive device and is really just a relay on its own. It could be connected to the switch pins on a Shelly.
I don’t know of a compact zwave dry relay though - so this does mean 2.4ghz wifi.
If it’s like one I rented a few years ago, yes the thermostat just controls a fan, and the radiator is always hot or cold as it’s controlled by the building. I’d be inclined to use a Shelly or other dry relay with a virtual thermostat in home assistant now.
It comes down to what are the developers willing or able to support.
For smaller teams they usually don’t want the responsibility of maintaining the package for distros, and HA developers have chosen to not support that option themselves. In their case I see it - what’s the benefit or incentive to them to maintain packages and the associated support costs or headaches. Containers mean they get a known state and don’t have to try to support unknown environments.
Some interested people can maintain the packages for their chosen distro - for instance I see one for Gentoo but it’s only up to 2024.6. It’s the first that came up in a search but there are likely more too supported by the community.
In my case, I also think that using HAOS on a dedicated box has led to a more stable experience as it’s not competing for resources on my other hosts, and attaching devices to it is much simpler. I think encouraging a solid base for people means a better experience overall when to be honest it’s hard to get started with it to begin with for many people.
This. Basically few addons are ‘fire and forget’, almost all of them need some sort of configuration that’s listed in the Documentation tab, or in the add-ons repo. You’ll need to read up on it and look at the Configuration tab to set whatever you need to allow it to work.
If it’s logs, there’s a package called log2ram - it’s designed for small form factor systems to reduce writes to SD cards but does apply anywhere you want to log but not hit disk immediately. It syncs logs to disk on a regular basis so you don’t lose much if the system crashes.
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.
All that yes. The Wooting One (original that uses IR light) let you use buttons to simulate controller axes, change how hard you need to press to activate, and add second functions to keys. It was an interesting idea but I found the gaming part the original keyboard to be only usable in a limited set of games as it’s not as sensitive as a controller stick, and as a keyboard it wasn’t great either. Hopefully V1 problems, I know they had through another version of the IR keyboard, and then came out with the Hall effect keyboard. I like the idea but never could get used to it, and when the spacebar was loose I retired it after fixing it.
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.
Yes, the packet passes through routers at each stage and they direct the packet to the ‘closest’ path based on its destination, until the final router has the destination on its network. This can happen a few times (for something in your ISP network), or 10-30+ times for something further away.
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).
Try searching for your automation.entity_id - like in my case it’s something like automation.notify_washer_done (the original entity id of my automation, found via the developer - states tab). Then if I search using that in my YAML I’d see entity_id: automation.notify_washer_done, and add the context to see the full service call:
service: automation.turn_on
target:
entity_id: automation.notify_washer_done
data: {}
Assuming it’s an automation or script your should find it in the related .yaml file and can scroll up to see the actual automation or script source.
Turned off or Turned on is the disable or enable action. If it’s changed by something in HA it should show what the trigger was too (like a user or other automation).
Here’s an example - it shows the automations that enabled our disabled this automation, and their trigger.
To prevent the automation from being changed you can rename it, that should break anything automatic that’s changing it. You can also try to chase down what’s changing it from logs (once renamed you should start seeing errors in your HA log file), or by searching for the entity_id in your yaml configuration files.
I use an Emporia Vue device, it uses an ESP32 internally and you can find instructions on how to flash it with esphome code onto it. No cloud dependency, just wifi.
You can get various kits for one/two/three phase mains, and monitor up to 16 individual circuits via passive current clamps.
I have actionable notifications with notify.notify service working so I’m not sure there - something sounds off.
I don’t think there’s issues with long timeouts, but realize that they won’t persist through restarts of Home Assistant, and depending on your automation settings you can control the number of instances. To disconnect the action from the running automation I often add the event as another trigger to the automation and then add logic to handle the normal trigger and the notification trigger separately. No wait needed in the automation then, just fire the notification and another instance of the automation handles the action.
Phillips SonicCare for 20+ years. I think it’s helped me a lure with my dental care. Various models as the batteries wear out. The latest has Bluetooth that I never use but that doesn’t affect the cleaning part.