My network is made of unifi switches, AP’s and a router with an isolated vLAN for IoT and a main vLAN for everything else. The IoT vLAN has no internet access and can only access Home Assistant on main vLAN.
This is working well for my esphome devices as they can still get updates from Home Assistant.
I am about to migrate all of my switches from Zwave to Shelly. What is the recommendation to still keep firmware updates?
Put Shelly devices in the main vLAN?
Put Shelly devices in the IoT vLAN and create a rule for firmware updates?
Since you went to all the work of creating an IoT vlan, why put IoT things anywhere else? You can create a “Shelly” network group, and create a firewall rule that gives the Shellys access to the Internet. For tighter control, you could only enable that Shelly rule when you want to update the firmware.
I’m pretty new at this, so please tell me if I missed something or misunderstood your situation.
Yeah, you’ll need a 3.3V FTDI module like this one and some jumper leads. You can find tutorials online: just make sure you don’t power the Shelly from mains whilst flashing!
I converted my two Shelly 1 units as they were having connection problems on the OEM firmware, and they’ve been perfect ever since.
Good luck, and do report back on success as that sounds less fiddly. I used a similar route for my UP111 Gosund smart plugs, and that worked (with a bit of persuasion!).
Why people suggest flashing with 3rd party first, without a reason?
It’s not a solution.
Not all shelly devices are supported by esphome nor tasmota.
Considering shellies are to be used without cloud, those might work in sealed vlan. However I see no reason to not give them access to internet for fw updates and time server.
But even without that, you can arrange some local address to provide firmware files and ntp
It was a solution to the connectivity problem I couldn’t solve with OEM firmware, and now I only have one system (ESPHome) to manage, and don’t need to worry about internet access, or looking up firmware updates. I don’t have to care that I have two Shellys and two Gosunds — I have four ESPHome devices that I can manage centrally.
Given that OP already has an ESPHome infrastructure, it seems a logical option to suggest converting these incoming devices to match the infrastructure already in place.
Allowing devices free rein to update themselves is asking for problems. Not just from a bad firmware, but the firmware being modified by attackers and them being used on the devices themselves. (anyone remember Asus)
Sorry but no, firmware should be updated if only really needed to fix an issue, even then update with care. then block access to the internet for those devices. so they cant be used if firmware is compromised
@Troon the update to Tasmota with the OTA patch worked flawlessly. The sample code for ESPhome is out of date and / or wrong but the reference code works if you follow this process:
No Shelly device is updating automatically without owner consent. It’s not the HA Supervisor
Shelly devices inform owner about update available. Update itself must be explicitly called by the owner.
Then it might be the rootcasue. I have no experience with CoAT protocol but new Shelly FW allows to set some details around that.
I’m using MQTT and experiencing no delays. TBH I found MQTT most stable and reliable way of integrating Shelly out of all available.
I used MQTT on the shellies in the past. But I like the cloud fallback option in case HA for some reason goes down while I am on holidays. This way I can still control my sprinklers for example.
No. Don’t have any ESPHome device.
I should add “…Shelly with oem firmware”. I didn’t since I thought it’s obvious I’m talking about OEM fw.
BTW IMO MQTT is better choice over ESPhome just because of decoupling. ESPHome docs list this as disadvantage (One less single point of failure), but IMO it’s just opposite architectural wise. Custom protocol, used to connect two custom components gives less options to debug issues or to maintain the system. And is more error prone. You are dependent tightly to either ESPhome or HA integration without ability to see what is happening between them.
Using well established (thus reliable) technology between components is great advantage (for cost of some delay which in home automation scenarios is negligible anyway)
For the same reason I use zigbee2mqtt instead of ZHA.
So… no. I’m not going to try 3rd party FW unless forced to do so, ie by serious problems with oem FW.
I was just winding you up based on your prior response to me
I completely agree with your “decoupling” principle, by the way, and I have a Shelly 1PM on OEM firmware (because it behaves, and has been fairly physically inaccessible since before I knew ESPHome on Shelly was a thing) but using manually-configured MQTT to interface with HA for exactly those reasons.
I use the ESPHome API for my other devices only because it is easy to set up and has been absolutely flawless in my experience — if it showed any signs of instability I’d move them all across to MQTT for the reasons you state.
