Thanks, that's also my experience, except that once you set a login password (as mentionned above), the whole device grinds to a halt (web interface).
Also, there's NO notification when the battery goes dangerously low, before the device stops working. Maybe it would be nice if there was an http action 'last thing I do before I die' 
I disagree, as the fix is not viable as per device purpose. It's supposed to work with the internal battery. One can't just start pulling cables everywhere 
Thank you so much for all your insights, they were very helpful to me.
Enjoy your Shelly devices and until we meet again: stay well!
Thanks again.
Thanks, yes, but still my browsers are complaining when they access a server inside my local network.
So, I was wondering if you would know a solution for that 
Thanks, though!
My experience has been quite good. Aside from the fact that I cannot reach the web page on the device, I must admit the devices work (trigger http API signals) well now. I only had a single outtage, and all it needed was to press the reset button a single click.
I don't know what that reset single push button does, but it seems to have 'bumped' the device to connect to the Wifi again and send http signals again.
One sidenote:
As a test I registered my Synology NAS.
So, now I have a valid certificate for FamilyDS.org
But when I connect with my browser to it, it just complains that the internal IP address is not the one linked to the certificate. You see, the certificate refers to my public IP address. My Synology server also has a local IP address.
Utterly useless for the average end consumer, if you ask me. Because I never connect to my NAS from it's public WAN address. I connect always and only via it's internal local IP address. I think this makes perfect sense (even without active internet, my home keeps working).
But no, I simply get an 'invalid certificate' response.
Maybe there is an easy solution to this.... would you know?
You're most welcome
I tried "Let's encrypt".
So, I do not own any DNS domain.
I don't want to pay for it, because I do not need it.
So, in this case, the computers that are physically not reacheable from the internet are deemed unsafe, simply because they have no DNS name that can resolve them "on the internet".
But I don't want to be "on the internet". I have a local DNS server that does the internal DNS serving.
And it seems for this case, "Let's encrypt" will not issue a certificate, and all web browsers are always complaining the https servers are 'unsafe'.
This feels to me like some scam where the world wants me to pay someone for having my own servers.
It's sad. And that is why I don't like security advice, when all it does is asking me to go public on the internet, take additonal risks, pay additional money - all things I never asked for...
One of the things why I love Shelly devices (and grown a profound dislike for cyber sec guys), is that like Tasmota, Raspberry Pie, etc. these vendors give us something we can work with to use and tweak as we (the general public) sees fit.
Sure, you could close up the eco-system and make it much more secure. Look at Apple. They have closed up their ecosystem, and allow only signed, verified apps in their store. But it also means that without a paying developer account, I can't even write an app myself and put it on my own phone...
Sure you have a point about all the technical points you are adressing above, and it is quite easy to ask these questions. However, I would also like if you could provide hints as how would you solve your points above, without making the user experience hell.
You see, for us to use https, we would have to buy certificates - official ones - which cost money, which are an additional hindrance to use (the general public) in using the software.
For myself, I only use these devices within my home network, and they never need to connect to the internet. I would like you to insert malware in a firmware downloaded from Shelly, please do it.
I don't see any real danger there.
Finally, I would like to point out many manufacturers use firmware without this 'signing' bit. Take Pioneer, Dreambox, for example.
So, when you can make it more safe and better, without impacting user experience, than please suggest ways to do it. It's too easy to stand on the side and just note how things could go bad.
For me, I'm already very happy when Shelly resolves the bugs in their firmware. Millions of devices sold, no issue to what you are referring too has been met so far.
Finally, maybe it's a little bit with target audience: for people to insert nasty things in software: it's gotta be worth it. Hence why Windows is such a wonderful target (why is the industry even still using Windows, the most dangerous and prone for attacks software, plagued by virusses and worms all the time. Why cling to such a bad OS?).
Maybe Shelly as a platform is simply not even worth writing bad firmware for?
In summary: for me it's a typical security guys overdoing it point that always comes back with security guys. Sure you need them, but you don't want to over do it either.
I think the primary goal would be to have happy customers that can use the gadgets for their intended use. And I think Shelly is well succeeding in that. When you know of ways making it better for the audience Shelly meant these things for, be my guest: come up with answers, not questions (what my boss always used to say )
Have a great day!
You're right. There is the official documentation, but then an engineer implemented (possibly an improvement) and the specs changed a little. Like all engineers, we hate creating/updating documents. We love coding So, it's a fact of life, I think, always discrepancies will exist
Well, I don't have any Cloud enabled devices. So, I manually upgraded my motion sensors.
Experience is not really excellent.
1. First, I had to manually reboot the Shelly Motions, so that they would see the update.
2. Updating took a considerable time, much longer than the usual Shelly devices.
3. After updating, I was unable to connect to the Shelly Motions, though they did work.
4. Reset a device is not straight forward anymore. Seems the device notices the reset button is pressed, but when you wait too long to connect to its own generated WiFi signal, it returns to the configured mode. In itself not a bad idea, but I didn't know about it.
5. Re-configuring the device is a snap, like it was before. Now I see time indicators next to the 'Action' URL entries. Apparently, one can program in that they only detect during a preset time interval. Like :
from 06:00 to 23:00
or something similar. Nice, but anyway, I left both to 00:00. I hope that is okay for them to always work.
6. After configuring, the device goes - without warning - into power saving mode. It's pingable, but the device only answers sometimes.
So, now I tried to connect to the device to access the web interface. >>impossible<<
Once the device is set up, the web interface loads a little bit (I tried 4 different browsers: Safari, Chrome, Brave and FireFox). But immediately (I suspect it goes to sleep) the loading is halted - for ever. I suspect the device after a small sleep does not remember I connected to it.
In short, after the device is set up, it works, but unable to get to the web interface anymore (the actions are done well, though).
Finally: I'll see if the device keeps sending its actions. I can't see the device status anymore, so I will rely on the actions to let me know it is okay. This is very similar to flood, door and other devices, that to save battery go to sleep. They become unreachable (unless the very short moment an action taakes place).
Let's hope for the best!
Yeah, it's a funny story with the Motion. Has been stable for 35 days, and then... no more wifi.
I reset it again (for the next 35 days?)
Oh, yes, that's way more clear.
Thank you!!!
Yes, I don't understand this Shelly Night mode on some devices either, even after reading the explanation from Shelly several times.
The name is very confusing, as it is certainly not just 'dusk2dawn'... (if it was, why force people to set the hours?)
I'd very much love to hear from people if they use this functionality, and if they do, maybe they can better explain than Shelly what it is and how it works...
After you do some research, you will find:
COLOR mode
curl --request GET 'http://192.168.33.1/settings/?mode=color'
and
WHITE mode
curl --request GET 'http://192.168.33.1/settings/?mode=white'
Isn't that last one a question to Philips?
I'm using Current version: 20210107-122133/1.9_GU10_RGBW@07531e29
and have not been experiencing issues since.
For information, Current version: 20210226-072307/v1.1.0@f31e1d2b
Static IP information set.
Hi, yes, I believe so too. But does your device have a static IP?
I set the IP configuration static, so the device should not be able to lose it...?
Hi,
Yes, I had a sensor not sending API http calls when it was actually blinking when triggered.
However, I then repeatedly started trying to connect to it over and over again, and after fineish like attempts, it finally responded. After that, the sensor started sending the signals again through http calls to my server.
So it seems accurate that the device is actually in some kind of passive 'sleep' mode, even though the led's on the device signal motion is triggered, it is not sending out the requested http url.
To be continued... (with follow-up update)
BTW, it is also true this did not occur with previous firmware version on the device.
I am not sure, however, how I can revert the device to a previous version of the firmware, as this site does not list the firmwares for the motion (I believe - at least, last time I looked).
Thank you for your assistance in this matter, and providing the path forward.
Hi, in my experience it takes longer than 24 hours for the problem to occur.
It seems to occur only after a week - maybe two.
In that sense it is not too alarming, if it weren't for the fact that because I cannot connect to it on WiFi, I use the pin to re-activate the device. But that then essentially resets the device to factory settings.
When and if it occurs again (I had it happening once on every device since I received them), I will try the 'connect test', where one claims after 5, 6 attempts to connect with the URL, the device actually starts responding again. I cannot tell if this works or not.
I'll provide my findings when possible.
Thanks!
