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”).
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:
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.
I updated to 1.1.3-rc9 and noticed an improvement but not 100% reliability.
Tonight I noticed that my devices were showing an update available so now I am trying
1.1.3-rc16
Fingers crossed here too
What are you guys seeing in HA when the device isn’t available? Does the state turn to unavailable?
Yes it does.
They could be “woken” but pinging them or sometimes by activating them but in HA I had to then restart before they were available again.
Mine with rc16 are still ok after 2 days.
(Fingers still crossed though)