Beiträge von condiosz

Thank you for the info, Alex. As usual, I'm sure a firmware update will fix this, later on, then

But I didn't know, so thank you for the info!

Hi,

Would there be a way to force a Shelly-Motion to re-connect to a WiFi network, after it disconnected?
All I know how to do is to re-initialise it (by using the pin hole), but I was wondering if there was a 'reboot' pin hole sequence,

without factory reset?

Thank you for your help.

Not end user replaceable. When dead, you should charge it

Yes it works. My whole house is set up like this. I have no conventional switches left in the whole house, and all switches can hence also be activated by the app.
Also, the wiring in the switches has been replaced by very thin wire, because almost no current is needed to go through the switches.
The TL also has a 4 wire version, I use that one, because then the I3 can read the status of the TL (open/closed).
It just requires a large cabinet and a lot of electrical wires. But then, that is the cheap part

I had this also. You just have to allow the device to init itself, and after a while, the normal web UI appears. Allow the device to start up, and all will be okay

1.9.6 doesn’t appear to be much better, as it didn't provide smooth and regular dimming between 0 and 100.

Dimming went up & down over the 0-100 range, but inconsistently (70% was much brighter than 80%, for example)(after trailing edge calibration).
I went back to 1.8.2, where everything was just right (for me). Calibration in my home doesn't work well.
I have Aiwode SMD-GU10-D lights in each room, about 7 lights per room. Every room has a dimmer.

Thank you so much, that information is really very interesting!
I did not know any of this.

Thanks again

It is somewhat unclear what leading and trailing edge exactly means, why it is unsafe to mix LED devices, and how we should decide which 'edge' to use (sorry .... )

Mine doesn't have a lux issue, but I agree I also would like to have the option to have '0' seconds, and have a signal every single time a motion event occurs.

Also, I was charging mine, and charging, and charging... 24 hours long. Manual said orange/reddish light would go off next to USB, but it never went off. After 24 hours, I finally decided to activate it anyway, and hey, battery was 100%. Another one, I activated first, then started charging, and said light did go out when battery was shown at 100% in the interface.
Small funny things

It is well in the limits, yes. That doesn't mean it will live a long life...

There are peak currents and so forth.

Anyway, at these levels sparks should not be a surprise and hence it is (in my humble opinion) much better to use heavier gear than that very tiny switch.

But if you like it... by all means. It's only my opinion.

I would never connect a heater of 2kW to a shelly.
You'll burn your relay up quickly.

In stead, use a contactor and let the contactor power the heater.

So, going through several threads I learned:
- RGBW2 now has 2 firmware updates. You must choose for either color or white.

- Firmware updates are sitting at

For Color:

http://repo.shelly.cloud/firmware/SHRGBW2-color.zip

For White:

http://repo.shelly.cloud/firmware/SHRGBW2-white.zip

Download these firmwares from the above links.
Then, when ready, use your own httpd server to allow local upgrade of the firmware:

curl --user name:password "http://x.x.x.x/ota?url=http://y.y.y.y/shellyfirmware/1.9.4/SHRGBW2-color.zip"

where

- x.x.x.x is the ip of your shelly,

- y.y.y.y is the ip of your httpd server,

- username and password for your shelly device, needed only when set in the device

And behold, the RGBW2 device is again detecting OTA shelly updates !
(see attachment)

This confirms to me OTA shelly.cloud firmware mechanism changed somewhere, during the lifetime of these devices. With this trick, you can hop back on the official OTA update wagon.

Thank you so much - again to Seven of Nine !

My issue is completely solved
(though you might want to consider putting the fw back up in the firmware archive? )

Hi, depends very much on what plugin you used in Hoobs to create the accessory.
Can you provide any information on what Hoobs plugin you are using?

Thank you

Hi,

I am experiencing some strange behaviour with (most of) my RBGW2 devices, in that they see no update available.
All are configured the same way. I even put internet DNS to 8.8.8.8 to make sure they have DNS.
All have internet access (as shown because NTP is correctly working).
As there is currently no alternative way to put the firmware on these devices (it seems this is a two step process),
would anyone also have experienced this, and maybe have a solution to allow upgrading them?

Thank you for reading this.

Hi, not all devices see the update being there. I have RGBW2 devices, and funnily some see an update and others not. However, I'd not want to mix subjects, and they all seem to work great, so it's not really a serious issue for me

Thank you so much for your help.

Shelly Type: ShellyVintage

Device Mode (if Shelly Type is Shelly 2.5): -

Firmware Version: 1.9.0

Router or AccessPoint: Ubiquiti Unifi UAP-AC-HD

Static IP or DHCP: Static

Hi,

all devices always have a valid internet configuration.
I can see, because they can NTP with time.euro.apple.com
Also, all other devices but the manually downgraded fw lamps can actively see updates.

(I actually wrote a little script that does mass-update all, because it was becoming impossible to update every shelly manually ) And they can and do update firmware.
This missing fw update information only appeared after downgrading.

I'm very pleased with the link & beta firmware offer.
As soon as it is released, I will for sure test it.

Thank you for this.

Hi,

Sure, I use a ubiquiti Unifi mesh network :

7x UAP-AC-HD fw v4.3.24.11355

1x US-24-500W fw 5.43.23.12533

managed by macOS controller fw 6.0.43.0

Band steering is not activated. Wifi health monitor is around 98%.

About downgrading, yes I tried, all the way down to 1.6, but this has no influence on the issue.

That said, lamps that were not upgraded function normally.
But lamps that were upgraded, do not change behaviour when downgrading fw.
So I'm thinking either a fw changed something on a programmable pic level,

or left some configuration behind.

It is actually funny that 'old fw lamps' that work very well do not find a sw update

"The current Firmware version of your Shelly device is 20191216-140157/??? No newer firmware available."

Other lamps that had fw upgrade (and of which behaviour I need to yet get convinced, waiting a few days to experience and confirm) also do not:
"The current Firmware version of your Shelly device is 20200309-103920/v1.6.0@43056d58 No newer firmware available."

I noticed lamps are only acting "weird" when always-on (aka on UPS, without physical power switch).

Other lamps act normally, but they have a physical switch before them (and get physically unpowered and powered).

Will report back how my two lamps are doing in a few days. As you may not, one of them was never firmware updated (because it was in a drawer for a long time, as a spare, and since one became unresponsive, it has now taken that lamp's place). I do not intend to update fw on that lamp soon

In annex the firmware level print shots.

Thank you for reading!

.

Hi,

So, today I after the lamp again was unresponsive, I wanted to see if the issue maybe was mechanical.

So, I cut open the lamp to see what's inside.

Below, you'll discover the inside of the vintage lamp.
I have been able to determine that the issue is *not* with physical connection issues with the lamp.

Even when completely stripped, the lamp continues to behave in the non-responsive way. The light goes on for a while (100%), then goes off. I get 3 links of reset sometimes, but no wifi signal.
I think it has to do with the firmware - or a flawed hardware design. But it's definitely not an electrical issue...

IMG_8559D.jpeg

IMG_8556D.jpegIMG_8554D.jpegIMG_8545D.jpegIMG_8542D.jpegIMG_8541D.jpegIMG_8540D.jpeg

Actually, my lamp still becomes unresponsive after a while...

Sorry...