General rule of thumb for me is, if LPL can’t open it in 30 seconds or less, I’m probably safe from most of the fuckwits that live in my area.
Just an Aussie tech guy - home automation, ESP gadgets, networking. Also love my camping and 4WDing.
Be a good motherfucker. Peace.
General rule of thumb for me is, if LPL can’t open it in 30 seconds or less, I’m probably safe from most of the fuckwits that live in my area.
I use an ESP32 board as a wifi-based proxy for the BT temp sensors on my barbecue. Works a treat! It’s doable in esphome, so easily plugs into HA.
Details here: https://esphome.io/components/sensor/inkbird_ibsth1_mini.html
I’ve been thinking about exactly the same problem.
We want to give our near-10yo daughter her first phone, but she’s not allowed to have it at school. She’s also getting to the point where she can be trusted at home for an hour or so before one of us gets home from work, so I also need a presence detection method that doesn’t use a mobile phone.
My best theoretical solutions are like those already suggested here: an ESP32 BT proxy detecting a homebrew BLE beacon in her school bag, or detect activity on her iPad/the TV. But neither of those are reliable for all scenarios - she obviously doesn’t take her school bag to her friend’s house, and doesn’t always use her iPad or the TV.
The only other thing I’m pondering is if I could setup facial recognition using our video doorbell. I use Frigate with a Coral TPU, so hoping there’s a project out there that could possibly do that.
Don’t be a dick, mate. Engage just a little bit of critical thinking before calling people names like that.
By law where I am, our kids aren’t allowed to have their phones at school. My daughter’s school’s policy, then, is that phones are left at the school office.
We want to give our soon-to-be 10yo daughter her first phone later this year (times with a planned family trip, so it can be her new camera as well). But if she takes it to school and has to leave it at the office, I can guarantee she’ll absolutely forget on more than one occasion to pick it up before coming home.
So, her phone will have to stay home. But we’re also getting to the point where she can be trusted to let herself in and wait for one of us to get home (like OP, maybe an hour or so). So a presence detection option can’t be based on whether the phone has moved into the geo zone in HA.
This is a legitimate question for modern parents. Denigrating OP without knowing or understanding all the facts certainly does shine a light on ignorance at play here. Just not OP’s ignorance.
Ah, got it. Thanks - this makes a lot of sense now. Looks like it’s so the HAOS Supervisor container can manage all the things that, in theory, I already handle myself with external tools.
Cheers!
Interesting about the backups bit. The functionality’s there in the UI to create backups, so kinda weird you can’t restore them. Like most docker containers, my HA config sits on a bind mount, and I just back that up nightly.
When you say add-ons, are there specific ones I’m missing out on? I have HACS, and frequently install all manner of integrations and front-end Lovelace add-ons.
Ah, gotcha. Thanks for that.
Sorry - not sure what you mean? I use HACS in my setup. Are there extra features in HACS when running HAOS?
Adjacent question: is there a compelling reason to run HAOS? I run my HA setup in docker on a Proxmox CT, using Portainer/Watchtower to manage, so genuinely wondering if there would be benefits I’m missing out on.
I edited my reply above. Could it be that both want to lock docker.sock
?
Are you able to share any additional details about your setup? How are you running HA?
Scratch that - I just realised that you mentioned the Supervisor container, so that kinda tells me how you’re running it. I suspect the problem is that both Portainer and the Supervisor container want to maintain a lock of some sort on docker.sock
.
But I run HA in its own container, so I don’t have any experience with the Supervisor container myself. I do run everything with Portainer though, and I’ve seen other things that wanted to use docker.sock
have problems with it.
Nice - finally a new release to get me off Stardew Valley for a while.
means you didn’t get the point or you know HA less than me
Your OP says “everytime I restart to apply the changes, all the switches, sensors and even the thermostat lose their values”. Later on, you’ve said that you configured all your switches and sensors to publish their states in MQTT. Hence why I’m saying you need to look at how and when HA is querying those states.
You’ve since clarified that the thermostat is a generic thermostat entity, where HA controls setpoint. Without having posted your config, I’m left to assume that HA turns your HVAC on/off based on a temp sensor state.
I’ve been running HA for many, many years, and am a network guy by trade. I’m only trying to help, but you’re now assuming I’m either not getting the point or know less than you.
No worries, mate. Best of luck. 👍
Jesus, you’re not exactly making it easy here mate. Feeding info piecemeal, to someone who’s spending time to try and help you, only frustrates both of us.
Re the sensors and switches, you said they’re all sending states via MQTT. Are they setting the retained flag? If not, that’s the problem. If so, run a packet capture to see what’s happening when HA restarts - maybe it’s not querying MQTT successfully straight away or something.
Re your thermostat, can you post your config? There’s a few threads on the HA community forums that are complaining of similar issues, with various causes/solutions discussed.
Ah, so your real issue is just the thermostat? Your OP made it sound like you were asking about all switches and sensors.
Is it just the setpoint that you’re losing and not getting back after restart? I’m assuming it’s getting the current temp back from the sensor just fine?
That doesn’t make sense. HA doesn’t “own” the setpoint - the physical thermostat does. All HA is doing is telling the thermostat what setpoint to use, as if you were standing in front of the thermostat yourself.
What thermostat are you using?
The retained flag simply tells the MQTT broker to keep the last message published for that topic, so it’s always available (rather than timing out and emptying the topic).
Like I said, you should probably do a packet capture to see what’s happening when HA queries states (either from devices or MQTT - it doesn’t matter).
How network-savy are you? I’m thinking you could run tcpdump on your HA server and capture network packets while restarting HA, then inspect in Wireshark.
Most devices don’t actually “send” their status to HA directly. It’ll (usually) be HA querying their status (the exception being devices that publish via intermediate services, like MQTT). Inspecting the network packets might reveal more about what’s going on.
When you restart HA, keep an eye on the Summary tab for the Proxmox guest. If you’re seeing CPU or memory spikes going into the red, you might need to assign more resources to the guest. Also take a look at swap and boot disk utilization - do they seem particularly high?
Also, over what period of time to the “go back to normal”? A few minutes, half an hour, more?
Cheers mate - no doubt I would’ve scratched my head for a bit when I do my weekly container updates tomorrow.