Closed CReimer closed 3 years ago
@CReimer Thanks for testing the firmware! I shall test do some tests without neutral wire. It sounds like there may need to be some changes made to support a 'no-neutral' setup.
Hi @jamesturton Same setup for me and same result, using an old style 60W incandescent bulb + Shelly bypass, 50Hz, 240V (France) Let us know if you need any help with testing Thanks
Hi
I just wanted to report that I am seeing the same problem with LED 3 x GU10s. Using 240V in South Africa...
Very happy to test any updates for this.
Thanks!
I found your add-no-neutral branch and figured out how to compile it. I would call it "better". The LEDs stay on... kind of. But with really horrible slow flickering
Any news on this?
Any updates to this? Seems like the Dimmer 2 doesn't want to properly work without a neutral wire... Technically with loads above 10w you don't need the Shelly bypass.
My result without neutral wire is that once you turn the load on the device will restart. otherwise, if not touching the load the device itself does operate without neutral. e.g it will connect to wifi and everything else works.
I've spent quite a long time working with this now, testing many different types and brands of bulbs, but unfortunately I have not been able to get the dimmer 2 working reliably without the neutral wire. Some bulbs work nearly flawlessly and other flicker horribly no matter how hard I have tried to optimise the code.
Looking at the Shelly support group on Facebook not even Shelly themselves seem to be getting this device to work will all types of dimmable bulbs. And they have access to all the hardware schematics for how the device it supposed to be operated... :)
I can upload the latest version that I have been testing with, but as a warning, it might not work at all well with the type of bulbs you are using.
My result without neutral wire is that once you turn the load on the device will restart. otherwise, if not touching the load the device itself does operate without neutral. e.g it will connect to wifi and everything else works.
Maybe I can explain a little bit about why this happens - when dimming without a neutral wire, the bulb can never be 100% on, the dimmer must turn off the bulb so that it can get the power for it's self for a little bit of time before turning the bulb on again. If you are using Tasmota firmware with PowerOnState
set to 1, 3 or 4 and set the dimmer to 100% with the current released firmware the device is restarted 5 times very quickly, causing it to be factory reset and you will have to configure the device again. I'm not sure if the other firmwares (like ESPHome have anything similar).
Your new version works quite well for me. A little rough around the edges but pretty good so far.
And with rough around the edges I mean:
Another course of action could be to use the original STM32 firmware. I already prepared some hardware to figure out how Shelly changed the protocol starting with version 1.8.5. But no luck so far
Maybe I can explain a little bit about why this happens - when dimming without a neutral wire, the bulb can never be 100% on, the dimmer must turn off the bulb so that it can get the power for it's self for a little bit of time before turning the bulb on again. If you are using Tasmota firmware with
PowerOnState
set to 1, 3 or 4 and set the dimmer to 100% with the current released firmware the device is restarted 5 times very quickly, causing it to be factory reset and you will have to configure the device again. I'm not sure if the other firmwares (like ESPHome have anything similar).
I don't understand why this is the case. I believed the Shelly Bypass is in place to magically make this somehow possible. Shouldn't this only be a problem when the lamp is completely off?
But yes. After some tinkering with the official STM32 firmware I can say, that even there it's not possible (at least with tasmota) to dim to 100%. The sweet-spot seems to be below 70%
Interestingly I can not find any evidence that Shellys ESP firmware is aware of the no neutral setup. As far as I can tell Shellys ESP firmware keeps sending 1000 to the STM32 without problem. There could be something I'm missing as I can't listen in on the communication while mains power is connected. Only on my testbench powered via 3.3V
Something else confuses me about that. I use several Shelly 1L without Neutral wire with Tasmota. They work without any problem.
Why does a Shelly 1L work with its internal relay and a Shelly Dimmer at 100% does not?
Electronics 1L uses a relay. Once set 'on' it always conduct permanently. Dimmer use a Triac which automatically switchs off at zero crossing (=every 10ms) It is extremely difficult to reach 100% with a Triac. You need to triggers the gate right after the zero crossing. Both delay in ZC detection circuit and in sw add up. Even 100us late is already 1% "lost" and I believe it takes more than that.
Electronics 1L uses a relay. Once set 'on' it always conduct permanently. Dimmer use a Triac which automatically switchs off at zero crossing (=every 10ms) It is extremely difficult to reach 100% with a Triac. You need to triggers the gate right after the zero crossing. Both delay in ZC detection circuit and in sw add up. Even 100us late is already 1% "lost" and I believe it takes more than that.
@barbudor Unfortuntally neither the Shelly Dimmer 1 or 2 use a triac. Instead they use a regular MOSFET with no zero-crossing detection which the STM32 must syncronise switching with the line frequency. This is why it is so hard to get working without flickering.
I don't understand why this is the case. I believed the Shelly Bypass is in place to magically make this somehow possible. Shouldn't this only be a problem when the lamp is completely off? But yes. After some tinkering with the official STM32 firmware I can say, that even there it's not possible (at least with tasmota) to dim to 100%. The sweet-spot seems to be below 70% Interestingly I can not find any evidence that Shellys ESP firmware is aware of the no neutral setup. As far as I can tell Shellys ESP firmware keeps sending 1000 to the STM32 without problem. There could be something I'm missing as I can't listen in on the communication while mains power is connected. Only on my testbench powered via 3.3V
@CReimer My guess is that the Shelly STM32 firmware hides the fact that it never actually dims to 100% and remaps the 100% request value to something like 90% brightness.
Something else confuses me about that. I use several Shelly 1L without Neutral wire with Tasmota. They work without any problem. Why does a Shelly 1L work with its internal relay and a Shelly Dimmer at 100% does not?
I'm not sure how the hardware on the Shelly 1L looks but it must be wired differently. The power supply for the dimmer is wired in parallel to the load, so if the MOSFET is on 100% the potential accross the MOSFET will be too low to power the dimmer circuit. When the MOSFET is fully off the potential across the MOSFET will be the full 230V/120V so is easily enough to power the device, but the quiesent current will cause the load to be powered slightly, hence the need for the bypass add-on.
Hi all,
I have a new version to test, which (in my testing) has reduced the flickering when used in a no-neutral setup.
One thing to note is that it seems sometimes the leading edge property isn't sent correctly from Tasmota, so I can recomend sending ShdLeadingEdge 0
command after updating the firmware.
Please let me know your feedback!
James
@jamesturton It is working great! Have a look: https://github.com/esphome/feature-requests/issues/949#issuecomment-828654680 (with ESPHome insead of Tasmota)
Fixed with 36977bd. Will release a new version now.
My Shelly Dimmer 2 module is flashed with Tasmota 9.1.0.2 and the stm32 firmware version 51.5. Everything is connected without a neutral wire with a Shelly Bypass. As it is described in the manual.
With Shelly's stock firmware dimming works fine with and without neutral wire. With Tasmota dimming only works with neutral wire. Without it the LED bulb even flickers horribly at 100% and after a short time reboots Tasmota.
I suspect it's a problem with the stm32 firmware, which seems to be responsible for the dimming.