Yes., i know, there’s been done quite a lot regarding BT proxy lately. I do have three proxy nodes around my house (for my 13 xiaomi thermo(hygro sensors), but, no, this one is only esp8266 in a power outlet. So, one switch and one binary sensor (and a few sensors i always have, like wifi signal, IP, uptime…)
You are aware that they are the same? The esphome dashboard updates is the base for the esphome nodes version and they have the exact same release schedule because of that. That will be one major release per month plus bug fix releases.
So you should still get each and every update notification for the esphome add-on when turning off the esphome dashboard integration which is in charge to check your esphome nodes against the add-on version (and creating the notifications for each of your out of date node).
The esphome dashboard integration
Lucky you it’s not 2021.9 or prior…
still technically not a security bug you might be safer with a more recent version (like 2023.12.0 or later
Still as mentioned before you might also just loose API improvements on the way which would later could lead to weird things requiring debugging from your side.
Some people (including users in this forum) run stone old buggy Tasmota versions like 5 or 6 and are happy with it (because it switches the light ) - still it contains security vulnerabilities which could be exploited remotely.
The fine difference between a dumb and a smart switch is that the later is connected and while feature upgrades are not necessary you should at least install necessary security fixes.
Yeah, well… i’m usually more “wanna the latest and greatest” kinda guy, but esp nodes are an exception. HA, addons, hacs stuff… those i update regularly.
To be honest, most of my esp nodes do have pretty “decent” version, mostly because i’m constantly hacking, messing, improving… with HA and modules… always wanting something more, better…
Regarding “unauthorized OTA update”: hm… all my nodes are local. So, a hacker will have to break into my local network first in order to reach them. And if he/she does, then nodes will be last on the list to worry about…
Note that you should always take precautions with networking, even for devices within your network. If your wifi is using WEP2, which almost everyone is, your password can be obtained in about 12hrs using a RPI or laptop from outside your house. Useful if you’d like to share your neighbour’s wifi…
“WEP2”… do you mean WPA2? I don’t use wep2, i use wpa2. My router does support wpa3, but sadly many of wifi devices doesn’t.
But, ket’s say that someone would camp in front of my house with pi. It makes me wonder…why on earth would he/she wanna do that? I don’t have anything worthed to be stolen, hacked…
Is that a new method you are referring to?
I tried the common methods to test my network security (eg. hashcat against some packet captures) and threw some GPU at it as well but most nontrivial passwords (i.e. non-dictionary complex passwords) couldn’t be cracked within a reasonable time, I found.
I’m inclined to not believe the 12h on a Raspberry Pi figure. But if you happen to have any sources backing that up, that would be interesting to know.
Same here. That would be possible only if using an extremely weak password. Even with significant processing power, a WPA2 password of at least 12 characters and good entropy is not crackable in any feasible time.
The typical way to attack WPA2 is:
Spoof the MAC address of an authenticated device.
Send a deathentication frame to the AP as coming from that MAC. That’ll force the real device to re-authenticate.
Capture the handshale data.
Rinse and repeat to capture a bunch more handshakes.
Go home and brute force the key at your leisure.
Good luck if the target network has a good password.
WPA3 has management frame protection to prevent deathentication attacks and many other shenanigans, but it’s not as widely used yet.
Yes, sorry, it relies on people using guessable passwords that appear on one of the many online password lists and brute forced on a much more powerful computer at a later date.
WEP is luckily long gone and a WEP2 was never released for good reason
After it became clear that the overall WEP algorithm was deficient (and not just the IV and key sizes) and would require even more fixes, both the WEP2 name and original algorithm were dropped.
No, no one is WEP2 - really! It never was released!
Absolute oversized. A esp32 (typically with battery pack thrown into the bushes ) is enough to capture some handshakes (after some forced de-authing) which are then send later to the clouds to crack it
The 12hrs figure given is just imagination without any base or just totally made up. Depending on the pre shared key it can be somewhere from seconds (8 digit weak password from 4.8k most used WPA password list) to somewhere technically not crackable (within an acceptable time frame) complex passphrase
A recent ESPHome update to 5.2 broke OTA updates for my Athom presence sensors as the new update is too large. Error returned is:
ERROR Error binary size: Error: ESP does not have enough space
to store OTA file. Please try flashing a minimal firmware (remove everything
except ota)
Two folks mentioned this already at ESPHome’s Github page… links are at the bottom of my post.
Apparently the Athom Presense sensor may have 2MB flash but is only being detected as 1MB. Not sure if that’s true, but if so then changing the board type in the yaml config to a board supporting 2MB or 4MB may work. Or, could try installing a minimal firmware then the update would fit. But I decided not to bother with tweaking it.
I really don’t think these sensors need to update 2-3 times each month (so many ESPHome updates…) so I followed the steps above to disable the update notification. Thank you for the suggestion!
While I have the utmost respect for the ESPHome maintainers and their hard work, I believe there might be room for improvement in the current notification system. The current approach of sending numerous notifications to Home Assistant may not be the most effective or user-friendly solution.
The script/automation shared above does address this issue, but it also removes the update status from the ESPHome component interface, which could be valuable information to retain.
If I may humbly suggest, perhaps a more balanced approach would be to have a single notification in Home Assistant indicating that one or more devices require updates. This could be complemented by maintaining the detailed update status within the ESPHome component interface, allowing users to have a comprehensive overview when needed.
This is actually not the current approach. This was the old default. Starting with ESPHome 2024.6.0 update entities are disabled by default as (judging by this thread) many users have troubles disabling a entity themselves
) is enough to capture some handshakes (after some forced de-authing) which are then send later to the clouds to crack it 
