Man, I wish this had been a thing ~8 months ago when I was building these for my stuff.

…mine are awful, and these look awesome, so maybe it’s time to re-do that.

I’m on year 5 with 6 of them and they’re all fine.

RTSP stream to frigate, and then frigate does the magic AI and recording shit.

They’re also not allowed outside the LAN and don’t seem to care about not being all internet connect-y, though YMMV on newer models.

I can’t think of a single case of being annoyed with them other than the mounting pressure is a little wonky and a sufficiently fat corvid can land on them and change the angle on one of the ones in the backyard but I’m not sure I’d blame the camera manufacturer because of a fat crow.

Yeah, I’m just using some cheap NFC stickers from Ali Express.

The thing is that I don’t use the dashboard: not every action has a dashboard entry and even if there is one, the amount of time it takes to load the app, open the correct dashboard tab, and then click a button is like, 10x the time of ‘tap your phone on the NFC tag, and thing happens’.

On Android anyway: iOS requires you endlessly tap ‘Yes, yes I’m sure I meant to do that it’s fine just do it already’ for NFC triggered actions, and on Android, it just goes ‘boink’ and does it.

TLDR: it’s super faster than hitting a button on the dashboard.

Both!

The native automation is perfectly cromulent for what I want, usually, but there’s a couple of cases where the integrations either don’t exist or don’t return meaningful data.

FOR EXAMPLE, the video playback in the living room thing. Sure, the roku integration says “something is playing” but it’s shockingly wrong and unreliable. What happens is it falls into ‘idle’ status between videos, or if you’re fast forwarding sometimes and thus the automation was not doing exactly what I wanted.

The Jellyfin API, though, can look at the living room tv user and is spot on as to what is going on with play/pause/stopped statuses, so I have node red yank that data direct from the API and it works great.

I’ve gone way too far down the automation path.

All manner of temperature, humidity, occupancy, motion, and air quality sensors make all sorts of things do appropriate responses.

For example, I’ve got a mmwave motion/occupancy sensor in the bathroom, and if there’s no motion/occupancy and the humidity is more than 5% higher than the hallway sensor, then turn on the exhaust fan until it’s not.

Or, if the air particulate count in the kitchen is too high, turn on the exhaust fan until it’s not.

Or, if the living room is occupied, and the tv is on and playing media, turn the overhead lights off and turn the RGB accent light on very dimly. And if the media is paused or stopped, increase the brightness of the RGB lighting so you can see where you’re walking, and if it stays paused or stopped for more than 10 minutes, turn the main lights back to whatever state they were in before media playback started.

No dashboards though, since the goal is essentially that you don’t have to think about what is going on, because it should Just Work™ and never be something you have to deal with.

…though, really, I’d say we’re at like 80% successful with that.

For manual interactions I’ve got a bunch of NFC tags in various places that will trigger the appropriate automation in the case that you either want to do it by hand or it fails to do the needful, plus the app is configured to allow manual control of any device and to trigger specific automations.

Yep, it’s fully supported in HA/ESP32 and is suuuuuper easy to deploy and configure and the HA devs even documented how: https://www.home-assistant.io/voice_control/thirteen-usd-voice-remote/

Unless there’s something wonky with your virsh configuration, no.

This is a shitty explanation and if anyone would like to explain it better feel free, but the bridge interface acts as sorta like a network switch that can forward packets as well as be used for an interface, if configured.

What that means is, essentially, your VMs will be attaching their ethernet devices to a “switch” that then routes the packets out to the local LAN as if it were, well, a nic plugged into a switch.

virsh shouldn’t assign an in-use MAC, as it generates a random one (and I have no idea what you’d have to do to make them not do that) so everything should… just work.

No, because the bridge interface becomes the primary interface as far as Linux is concerned.

You’d just use dhcp to assign an IP to br0 instead of the physical ethernet device, though for a server a static IP is probably a better choice (so that it doesn’t bounce around on your local network making it harder to access)

My nas isn’t running fedora and thus isn’t using whatever fedora uses for network definitions, but is netplan under ubuntu.

I mean, probably the same thing, but it was shockingly trivial to configure:

network:
  ethernets:
    enp0s31f6:
      dhcp4: no
      dhcp6: no
  version: 2
  bridges:
    br0:
      interfaces: [enp0s31f6]
      addresses: [x.x.x.x/24]
      gateway4: x.x.x.x
      nameservers:
        addresses: [x.x.x.x, 8.8.8.8]
      parameters:
        stp: true
        forward-delay: 0
      dhcp4: no
      dhcp6: no

Disabled addresses on the physical interface, added the bridge section and told it which interface(s) to bridge - in this case it’d be the real interface and whatever gets added later by qemu/kvm, and then defined the IP address info.

the virsh network xml file was also straightforward, just make a xml file similar to:

<network>
  <name>host-bridge</name>
  <forward mode='bridge'/>
  <bridge name='br0'/>
</network>

and then it’s just

virsh net-define your.xml.file.here
virsh net-start the-name-you-used-in-the-xml
virsh net-autostart the-name-you-used-in-the-xml
virsh net-list --all

Should show up in the net list, and be selectable by name when making a VM

That’s a configuration problem you’ve made somewhere: you shouldn’t be assigning an IP to the bridge and it’s constituent interfaces.

You should take a look at your network config, and run (I’m assuming) dhcp only for br0.

Once you define the bridge network in virsh, and use that to make your VMs, kvm/qemu will assign unique MAC addresses to the VMs, so all you really need to sort out is getting your host OS to only assign an IP for the bridge.

Edit: also checked and yeah, eno2 and br0 and virbr0 are all different MAC addresses; did you maybe pick an option that forces them to inherit a MAC or something?

If all you need is for it to go ‘I turned on the light’, they’re fine. I wouldn’t expect to use them for anything more detailed or music-oriented.

I’ve accomplished this with the Atom Echo and they work… fine?

The speaker is essentially inaudible, but the mic works well enough for me to just yell at HomeAssistant to do things.

And hey, can’t beat the size/price/power footprint and the deployment with ESPHome takes like, 30 seconds.

Oh sorry; my goal here was for individual metering. I’ve got an Enphase solar system, so the Envoy is already doing whole-house monitoring.

I’d like to be able to identify and ultimately be able to lower my load to stay under what the solar panels are generating, but that needs data I mostly don’t have, and specific equipment to actually turn things on and off.

Yeah the plan was for the in wall relays. I’m in the US and if I read the specs properly they’ll do 16a at 120v, which is also where my breakers would trip anyways so probably shouldn’t matter.