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.
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.
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.
If you set the wait to 0, it will not wait at all and will proceed immediately (or stop the automation if continue is not set). It might be counter intuitive, in some systems a 0 wait means wait forever.
Set the wait to have a timeout and it will work.
Your wait needs to wait for a time, and decide if you want to proceed if you don’t get a response. Right now the wait for a trigger is expecting the event to be ready when it starts (before you’ve even seen the notification), and when it’s not the automation is stopping because continue on timeout is false. A wait for a trigger without a timeout doesn’t wait forever.
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.
I second the packet capture idea. Did you remove the virtual nic in the vm or just disconnect it? I’d you just disconnected it the packets were likely still directed to it as it’s the first network device.
I suspect you’re going to need to use a command line service to do a wol command as the integration doesn’t work let you pick a nic.
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.
Recorder integration: https://www.home-assistant.io/integrations/recorder/
The simplest way in configuration.yaml is something like:
recorder:
exclude:
entities:
- sensor.chatty1
- sensor.chatty2
For those devices that are very chatty you can specifically exclude them from being stored in the database. I then created template sensors that let me filter the results so I’m not spamming the database, only storing data I want. I do find the mm-wave sensors to be particularly bad, but I’ve also found Tuya-based air quality sensors to spam the logs too.
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.