Great, but I still have an issue with that sort of false advertising.
You’d notice if you had the same problem I had — they dropped off and would not recover until power-cycled. Seemed to be linked to the physical switch input changing, yet with exactly the same wiring setup I now have no downtime at all on ESPHome firmware.
Anyway, bit off topic, sorry.
It is not an esp, but I know nothing about the chipset they do say it has.
This is the closest I’ve come to a teardown image:
Regardless of the chipset you cant operate wifi on less than 1mA unless you put the device to sleep (and thus it is not “always connected”).
They say in their advertising that it is a new silabs low power chip. No chip number so hard to find a data sheet.
According to this it’s a silicon labs cortex m3.
The literature says the low power is from ‘integrated software-controlled sleep modes’. Sounds like this is why they drop off and not with esphome.
edit
Looks like rob the hook up did a review and wound up setting a rest sensor to poll the sensor.
Good find.
Mmm… My shelly plug s also have a similar issue. They won’t even turn off sometimes when pressing the physical button on the device.
Won’t that drain the battery really fast? From the linked text, it seems that The Hookup was working with the (wired) Shelly2 switch, not the Motion Sensor (I haven’t viewed the video, though, so there may be something I’ve missed)
Unfortunately connnecting IoT-devices to UniFi-gear seems indeed to be problematic in some cases, especially if UAP/USW firmware >= 5.x is installed and your IoT-devices are on a VLAN. This seems to happen because of that infamous DHCP-bug on Firmware v5 and up which Ubiquity has not been able to reliably fix until today. Check on their release forum about the issue.
As @tom_l already mentioned/suggested it a workaround could be to assign static ip-addresses to your Shelly Motion’s.
Did the beta firmware “fix” the issue for you?
If so, can you please explain how to install it?
Not completely but it’s a lot better.
Use this link but change by the IP address of the sensor you want to update:
http:///ota?url=repo.shelly.cloud/firmware/rc/SHMOS-01_build.gbl
Good luck
Thanks,
I now have 1.1.3-rc9 so I will see how that goes.
Yesterday I removed the DHCP reservations (in my Edgerouter 4) and left the devices on a static address but that did not help.
Ive seen on shelly forums that this issue can manifest if 2.5Ghz and 5Ghz are on the same SSID. splitting them out to separate SSIDs has fixed it for a lot of people, but this is not a great way to ‘fix’ what is clearly a firmware issue
It’s been a week now (with 1.1.3-rc9) and although they still go to sleep they do wake up when motion is detected or if I ping them.
I hope I haven’t jinxed them with this post though.
Morning @robfish. How do you get 1.1.3-rc9 on there? I can’t get higher than 1.1.2.
Edit: it updated this morning using the ota url above in this thread.
Yeah that’s the one Nick
Hey guys, just wanted to follow up on your success or not !? I have myself a shelly motion using coIoT, but it always goes unavaible. what I tried:
- Followed this guide:
- changed to 2,4GHZ Only
- I have a TPLink Omada managed Wifi Network, no problem with any other shelly
- Used latest RC Beta Firmware
- all my shelly run shelly firmware, nothing custom and all CoIoT and no problem so far.
- I have fixed IP now
- I have hardcoded coIoT IP of HA
- I have factory reset and newly added the shelly motion
what I notice is very high latency, when I ping 100 ms, but the statistics overall for wifi seem OK
after 2 hours it is unavailble, it does not report any motion, even if the light is red and the wb UI shows motion, just HA is not working
Any advise? Have you used mqtt? Any better?
cheers
Update to the 1.1.3-rc9 with the links above, mine has been stable since i did this 3 days ago
yes did that after 60 minutes it was not working anymore, could be because my shelly is in a different subnet than home-assistant. mqtt seems to be working now for 8 hours. so fingers crossed.