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.
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.
The phone or browser may be using DNS over HTTP (aka DoH), check if you can disable it for the wifi network. You may have to disable it on the phone or browser to get your desired behaviour - look up directions for your browser.
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.
Right now - easy, with the difficulty going up over time as the main Chromium codebase continues to change (and especially as it gets security updates). I think I’ve read that some variants (Brave?) have committed to supporting ManifestV2 for as long as possible, for instance with their own fork.
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.
From a Linux command line it would be the command called arp, you need to add a static arp entry. I don’t know how that works on sense, but on Linux it would be something like
arp -s IP MAC
Maybe there’s a module in opnsense to help. The way I’ve done this before is using a machine connected to the same network at my target to wake up by logging into that machine and issuing the wake command.
WoL packets are usually sent to the ip broadcast address for the network as they’re not ip based. I don’t know if this would ever work well across networks. Can you do send the wol packet from the opnsense router instead? Does it work then?
If you’re sending it to the IP of the server, it likely works soon after your turn the machine off because the ARP entry hasn’t timed out yet, but once it times out it won’t work anymore. The router doesn’t know how to get to the machine. You may be able to add a static arp mapping to get it to work long term.
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.
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.
You don’t say if you have any IoT networks yet, like zwave or zigbee, or if you’re looking for wifi. All have advantages / disadvantages, wifi is cheap and doesn’t use a separate dongle, zigbee devices tend to be cheaper, and a good variety available, Zwave is solid and doesn’t conflict with wifi or zigbee networks.
For the Hue bulbs you want a switch that lets you disconnect the relays from the physical switch. I don’t know what devices to suggest for EU, but my preference is to make the switches smart so they continue to do switch-like-things instead of having to retrain people.
This is a great case for templates. Templates are Home Assistant’s way of doing dynamic actions or data.
When: whatever triggers you need for the lights - can be multiple triggers or one trigger with every light/switch listed, with a For clause. The list is "OR"ed so do however you want. You could use a group but then all devices would be changed together - which doesn’t sound like is what you want.
And if: Whatever conditions you want, time, day of week, etc.
Then do: The action is where it gets interesting
add an action to execute “Generic turn off”, select any device (we’ll change that in a moment). The reason for the “Generic turn off” is that it works with devices in any domain (light or switch).
Then drop into the YAML view and chcange the entity_id value to this template: '{{ trigger.from_state.entity_id }}'
. The trigger is a variable that’s available inside the automation and can be used instead of specifying a static value somewhere. https://www.home-assistant.io/docs/automation/trigger/ for details on triggers.
Here’s the complete automation, you could create a new empty automation, then copy and paste this in place and just change the trigger and conditions as you want.
alias: Action - Turn off lights 15min after turned on during day
description: ""
trigger:
- platform: state
entity_id:
- switch.porch_light
for:
hours: 0
minutes: 15
seconds: 0
enabled: true
to: "on"
from: "off"
condition:
- condition: sun
after: sunrise
after_offset: "30"
- condition: time
after: "01:00:00"
before: "23:00:00"
weekday:
- sun
- mon
- tue
- wed
- thu
- fri
- sat
action:
- service: homeassistant.turn_off
metadata: {}
data: {}
target:
entity_id: "{{ trigger.from_state.entity_id }}"
mode: queued
max: 10
Make sure you’re not using any of the strapping pins for the interface with the AHT22 - take a look at https://esp32.com/viewtopic.php?t=5970 for a read. It basically means leaving GPIOs 12, 0, 2, 4, 15, 5 floating during boot or the esp will not boot correctly.
These pins control the boot process (like going to the boot loader instead of your code).
Yes. There’s no support (hopefully just yet) for multiple Home Assistant instances with the same account.
The only way I can think of is to disable the built-in updates, and set up time based shortcuts and have them do an if on wifi then trigger home assistant app sensor updates.
The way I’d structure it is a normal shortcut that you run from as many time-based shortcuts as you want to create (so you can reuse it easily). You can check the network name you’re connected to and only run if it matches your home network.
Create your own automation instead of using the blueprint. The blueprint doesn’t expose the location so it won’t work.
You might be able to look at the full yaml from the trace and copy it into a new automation (replace everything, then update the name). Once you’ve done that you should be able to use the visual editor and make whatever changes you need.
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