-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Shelly Dimmer 2 - PowerOnState does not work #10154
Comments
Flashed a second Shelly Dimmer 2 with devel 9.2.0.1 using Tasmotizer instead of mgos-to-tasmota used on the first unit. Flashed shelly-dimmer-stm32_v51.5.bin. Updated the first unit OTA from devel 9.1.0.2 to devel 9.2.0.1. PowerRetain does not work on either unit. |
It's a timing issue between tasmota and the mcu; at restart tasmota is quicker than the mcu telling it to set power to a known state. Workaround, just don't remove power from the dimmer. |
Ha! Power outages are somewhat unpredictable. Is there a chance this can be fixed in the future? |
I'm thinking about a possible work-around using a rule. Since the GUI has the correct state on power up, can that be used in a rule? Not sure on how to code this. |
You can use for example: Rule1 1
Rule1 on power1#boot do backlog var1 %value%;ruletimer1 5 endon on rules#timer=1 do power1 %var1% endon |
Thanks! It almost works. Here is what I have 14:06:45.884 CMD: rule1 When it powers up, the load is OFF when it should be ON. The GUI says it is ON. If I go to the console, and type Power1 ON, nothing happens, the load is still OFF. Maybe the rule needs to say: Thanks for your help! |
Please set weblog to 4 and then post the output of the console when your device starts? Thanks |
Hmmm... I changed the rule to: (Added backlog power1 off; power1 on) This works for the case when the load is ON when power is lost, but also turns the load on if it power was lost and the load was OFF. In other words, it always turns the load ON after a short delay on power up. Not good. Just saw your request for weblog 4, will do... Changed back to the original suggested rule. 00:00:00.049 CFG: Loaded from flash at F5, Count 95 |
Changed the rule to add a condition and shortened the timer; this seems to work. Rule1 on power1#boot=1 do ruletimer1 2 endon on rules#timer=1 do backlog power1 off; power1 on endon I originally was conflating the PowerRetain command with PowerOnState. I now have: I believe it it working correctly. The load goes ON if power was lost when it was ON, and stays OFF if the load was OFF when power was lost. Thanks for all your help! It will take some study for me to learn about using rules in Tasmota. |
Great to know that the workaround is working for you. |
@ascillato2 if you like you can assign this one to me. I will try to fix the sycronisation between the ESP and the STM at start up |
Just to clarify, the issue is that PowerOnState is not honored. The rule above works around the issue. I only mentioned PowerRetain because I initially thought it had something to do with the problem; it does not. Sorry for the confusion. |
Thanks. Very appreciated. |
@jamesturton |
PROBLEM DESCRIPTION
Shelly Dimmer 2 running devel 9.1.0.2 and the STM code Release v51.5. PowerRetain does not work.
REQUESTED INFORMATION
Make sure your have performed every step and checked the applicable boxes before submitting your issue. Thank you!
Backlog Template; Module; GPIO 255
:Backlog Rule1; Rule2; Rule3
:Status 0
:(Please use
weblog 4
for more debug information)TO REPRODUCE
Steps to reproduce the behavior:
Have the load ON. Remove the power from the dimmer. Restore the power to the dimmer. The load is OFF.
The GUI says the load is ON, but it is OFF. Toggling OFF/ON turns the load ON.
EXPECTED BEHAVIOUR
A clear and concise description of what you expected to happen.
With RetainPower 1, The load should be returned to the state it was in when the power was lost.
SCREENSHOTS
If applicable, add screenshots to help explain your problem.
ADDITIONAL CONTEXT
Add any other context about the problem here.
(Please, remember to close the issue when the problem has been addressed)
The text was updated successfully, but these errors were encountered: