use shelly 2.5 roller shutter without calibration

[mattod0]

I'm trying to use the shelly 2.5 with a Velux KLF 050. The Velux KLF 050 is a remote for the Velux Solar roller shutter and provides inputs for the opening and closing.

when using the original firmware I can open and close the roller shutter by providing an opening/closing time of about 55 seconds.

Unfortunately it is not possible to use calibration because the KLF 050 won't consume any power unlike a roller shutter engine, so calibration will always fail.

With the homekit-firmware opening/closing is not possible - and i even cannot set the time taken for opening/closing.
and of course opening to 50% isn't possible too because of missing calibration.

without calibration the shelly cannot be used I understand.

Is it somehow possible to circumvent the calibration process and provide the needed data by setting some configuration manually like opening/closing time or calibration data?

[torto-85]

I have a similar problem. And would be happy about a solution for this.

[mattod0]

I changed the configuration to switch and enabled auto off.
so now I've got two accessories in the Home app for every shelly.
I can now open and close my roller shutter completely but will never see in what state the roller shutter is because both accessories will be off after closing or opening is finished.

so this is not a good solution but a least i can use full opening/closing in automations.

the original firmware allows to open, pause and close the roller shutter with my setup. maybe there is an option to not use the power consumption detection and use the provided simple open/close functions somehow?

[torto-85]

Hey,

I use the same configuration at the moment and that works okay. But what happens if someone (me :-) is pressing the two buttons the same time? Or press the UP-button while the shutter is still moving down. This could destroy the shutter.

I prefer if I could customize the movement time in shutter mode.

Cheers
Tom

[juangamnik]

I have a roller shutter which does not consume any power (on the motor inputs). So after calibration I have 1.09sec avg time (instead of 11.8sec what I measured with a stop watch). Could you (and would you) offer a „manual“ calibration, where a manually measured value(s) can be entered?

[juangamnik]

@rojer: if you give me a hint, where to do this, l would give my rusty C skills a chance... but at a first glance I do not find the right spot. The shelly.cpp in shelly2.5/ seems to be a configuration, only. In the main folder I did not find the code for roller-shutters...

...ok it is shelly_hap_window_covering.cpp where the roller-shutter code is situated and in index.html it is the component with id wc-config... correct? But still I am a bit lost 😞

[rojer]

if it does not consume any power, it won't work anyway... as power is used to determine limits of movement.

do i understand correctly that you have mechanism with two buttons that does its own movement and you want to control it with shelly 2.5? can you describe the setup in more detail?

[torto-85]

Hey @rojer,

I love your firmware... Thanks for your great work!!

Like juangamnik some people use a shutter which show no power consumption (in my case the shutters have their own physical switches and automatically stops in end positions controlled by the motor itself) or would like to use their shelly as master controller for two or more roller shutters.

Because calibration won‘t work in this case, It would be great to have at least two simple UP and DOWN buttons in homekit (maybe even without opening status). I know that this could be realized with „switch mode“ and „auto off“ but pressing both buttons the same time could destroy the shutter motor.

So I think it would be nice to add a function in „roller shutter modus“ where we can manually edit the movement time and have these two simple buttons where the UP button is deactivated while the shutter moves DOWN and vice versa. Like it‘s in the original shelly firmware.

What do you think?

Cheers
Tom

[juangamnik]

if it does not consume any power, it won't work anyway... as power is used to determine limits of movement.

in my case three motors are connected via a cutoff relais. So there is <1W consumption on the inputs. But each motor itself has an endpoint, so it shouldn’t be an issue to manually set the closing time and use the shutter in HomeKit... right?

[rojer]

the shutters have their own physical switches and automatically stops in end positions controlled by the motor itself

this is actually what our implementation expects. if you just connect the motor directly to shelly, without any external controller and buttons, this should work. is there any reason not to?

So I think it would be nice to add a function in „roller shutter modus“ where we can manually edit the movement time and have these two simple buttons where the UP button is deactivated while the shutter moves DOWN and vice versa. Like it‘s in the original shelly firmware.

yes, i see clear demand for this. need to think how to implement it.

[torto-85]

this is actually what our implementation expects. if you just connect the motor directly to shelly, without any external controller and buttons, this should work. is there any reason not to?

Yes, but if I use the shelly as "master controller" for five roller shutters so calibration won't work.

yes, i see clear demand for this. need to think how to implement it.

Great @rojer, I'm looking forward to it!!

[juangamnik]

in my case three motors are connected via a cutoff relais. So there is <1W consumption on the inputs. But each motor itself has an endpoint, so it shouldn’t be an issue to manually set the closing time and use the shutter in HomeKit... right?

This is a situation where setting the closing time would help isn‘t it? As I said before I would add this myself in a fork and start a pull request if you would be so kind to give me starting help how this could be done (I do not understand how the components (html frontend/backend) interact and therefore how to add this)

[Storkn]

I have the same problem.
I use my shelly 2.5 for a roof window and the calibration detects 1.05 sec instead of the real 41 sec :-(
The Motor has a auto stop so it's ok for me to set the time manually

[juangamnik]

So I forked the project and added an input field for setting the movement time move_time_ms. It sets the corresponding value in the backend in cfg_. I know that the value is stored since it is displayed in the calibration text Calibration: movement time: 12 s, avg power: 0W. But still opening and closing stops after about a second...

[juangamnik]

The corresponding log output:

7355834451 mg_rpc.c:305            Shelly.SetState via WS_in 192.168.178.20:60749
7355845976 shelly_hap_window_c:350 WC 1: Tgt pos 100.00 -> 0.00 (RPC)
7355878132 mg_rpc.c:305            Shelly.GetInfo via WS_in 192.168.178.20:60749
7355904874 shelly_hap_window_c:330 WC 1: State: idle -> move (0 -> 20)
7356002105 shelly_output.cpp:56    Output 2: off -> on (move)
7356013229 shelly_hap_window_c:330 WC 1: State: move -> rampup (20 -> 22)
7356102026 shelly_hap_window_c:552 P = 0.00 -> 0.00
7356112653 shelly_hap_window_c:330 WC 1: State: rampup -> moving (22 -> 23)
7356204466 shelly_hap_window_c:339 WC 1: Cur pos 100.00 -> 99.33, P = 0.00
7356741143 mg_rpc.c:305            Shelly.GetInfo via WS_in 192.168.178.20:60749
7356802869 shelly_hap_window_c:602 Moving to 0, p 0.00
7357004438 shelly_hap_window_c:339 WC 1: Cur pos 93.44 -> 92.60, P = 0.00
7357202936 shelly_output.cpp:56    Output 2: on -> off (moving)
7357215218 shelly_hap_window_c:330 WC 1: State: moving -> stop (23 -> 24)
7357326327 mgos_sys_config.c:232   Loading conf2.json
7357350972 mgos_sys_config.c:232   Loading conf3.json
7357487461 mgos_sys_config.c:174   Saved to conf9.json
7357499643 shelly_hap_window_c:330 WC 1: State: stop -> stopping (24 -> 25)
7357542234 shelly_hap_window_c:330 WC 1: State: stopping -> idle (25 -> 0)

[juangamnik]

OK I found the issue. When I set the roller shutter to 1% it works. Going back to 99% works either. But opening or closing completely uses the current (at 0W) for knowing when to stop...

So I think I have now everything I need to finish this. I will start a pull request afterwards.

[Storkn]

Are there any updates or news? :-)

[juangamnik]

@Storkn: I am finished with my implementation. This evening I will cleanup the code and start a pull request. Then it is up to @rojer, whether he likes the feature/my implementation.

[juangamnik]

I started a pull request

[rojer]

it's not too bad, but please explain why we have two movement times? move_time_ms is already supposed to give time for full movement of the curtain.

[juangamnik]

@rojer come down from your high ross (as we germans say) 😉. It‘s not my language (C++) and I feel home in cloud native environments, native apps and SPAs/PWAs in my daily business....

But anyway, I‘m happy to participate here. I am ready to add some documentation to the wiki with an explanation of the values and when to use the feature and when not (accompanied with a screenshot).

Regarding your question: In my first attempt I had one move_time_ms as well as an additional_time_for_limit_pos, which can then be a value between 0 and one or two secs. The current version is just not additive, but defines two complete timings. This makes the code easier and is more intuitive I think.

The idea behind this is two-fold. On the one hand many roller shutter controllers have recalibration runs which search for the end position after many relative shutter moves. This is generally done by giving the motor some extra time to really reach the end position (sure this expects a detection of end positions, but the auto calibration does this too, so I personally would remove the „Caution“...). Instead of doing such recalibration runs, I implemented it the way that it runs to the limit position always, in order to give the motor time to really reach the limit position.

On the other hand: my roller shutter is at „feeled“ 75% when I set it to 50%, because the shutter touches the lower end, then needs some more time until it is fully closed. With these two values I can „correct“ the relative positions, but still have a fully closed/opened shutter, when I do a full open/close.

By the way: nice solution how the mgos_config code is generated in mongoose os! Really like it. I did some research on the topic of generative approaches (textual/graphic DSLs) for a lot of different things and I had some touch points with firmware programming there two. I wrote a generator for a graphical programming language to native ANSI C for a security/enclave chip with a self-made ARC... was fun)

[juangamnik]

If I should add corresponding documentation, it would be nice if someone could give me the corresponding rights on the wiki.

[rojer]

come down from your high ross (as we germans say) wink. It‘s not my language (C++) and I feel home in cloud native environments, native apps and SPAs/PWAs in my daily business....

sorry, i didn't mean to offend. it was meant as a complement, actually :) the change needs some work in terms of code, but i also need to think about higher-level approach, need to be careful about what parameters are added and UI changes.

Regarding your question: In my first attempt I had one move_time_ms as well as an additional_time_for_limit_pos, which can then be a value between 0 and one or two secs.

what you are saying makes sense to me, and this concept of "extra movement time" may apply more generally. i wonder if we can improve accuracy by allowing user to set it, even when auto-calibrated. this may help with positioning accuracy.

[juangamnik]

I tried to stay as near as possible at your coding style and implement it at least invasive I could. If there is some improvement necessary on the code side please feel free to give me some hints (or if it’s easier to do it on your own, then please give me hint when you’re ready so that I can have a look at it). What I do not like completely is, that there are now many ifs with calibrated || man_cal or even worse !(calibrated || man_cal). This could be improved by using an enum with ordinal instead.

if I can be of any help, contact me. I use the updated version for some days now and it works great so far.

By the way: Do you have some kind of (unit or end2end; e.g. selenium) test set and an emulation of a device or the possibility to use it with a real (test device)? If not, I would open a new issue for that :). I would be eager to help in this direction, too.

[mattod0]

Hey guys, I started this thread and I must say: great news :-)
I am not a developer but I work with developers (as a product manager/owner) and I can feel how you are all in to this.

Just wanted to comment on the move_time_ms / additional_time_for_limit_pos.
I think this is only necessary if the roller shutter opens and closes fast so that the time for getting from 99% to 100% (end position/closing the sections to 100% darkness) is significantly high in relation to the whole movement time.

In my setup (Velux on the roof) the move_time_ms is like 52 seconds. So the additional_time_for_limit_pos of 2 seconds would be quite short in relation, and the 50% opening would be feeled 50% opening.

But anyway, if this is already done and not to complicated to understand for the user - why not :-)

As long as setting move_time_ms manually is possible and the roller shutter does not try to guess the end positions by measuring power consumption during movement I will be very happy :-)

[juangamnik]

@mattod0 at work I’m not programming that much anymore, too (architect, scrum master, team lead), but I really do like programming! For me the second time has two purposes: recalibrate & correct relative positions (because 50% more or less feels like 40% on a normal shutter). And for sure you can have 52s and 65s, for example.

I chose 2 different „full“ times (instead of one full time and one additive time), because perhaps someone wants the second time less than the first or something like this and then having negative times would be arkward. But I‘m completely fine with an additive time either.

[HomeKid0815]

@mattod0 at work I’m not programming that much anymore, too (architect, scrum master, team lead), but I really do like programming! For me the second time has two purposes: recalibrate & correct relative positions (because 50% more or less feels like 40% on a normal shutter). And for sure you can have 52s and 65s, for example.

I chose 2 different „full“ times (instead of one full time and one additive time), because perhaps someone wants the second time less than the first or something like this and then having negative times would be arkward. But I‘m completely fine with an additive time either.

Hi Johannes,
It’s really great work all of you are doing here!
I recently installed 9 shelly 2.5 roller shutters connected to Apple HomeKit. Everything worked well, but one makes trouble. It is the shelly that is connected to a motor which operates two shutters. My problem is that I cannot calibrate it under Shelly HomeKit Firmware. During calibration process the shutter goes up and down about ten times in a short range of about 15 cm. Final result is that it can only be operated in this range after calibration. Is there some kind of a workaround or so?
Many thanks and best wishes from Duisburg, Andre

[juangamnik]

@HomeKid0815 this is exactly the issue I had too. The issue is fixed and my attempt to a solution is in review.

This project is from @rojer and some more contributors. I just helped with this issue.

[lucaspinelli85]

to me it still does not work well, and I have not yet figured out where to download the latest .zip version to test

[rojer]

@juangamnik yes, signs have been positive. i still want to have a closer look and think how it fits into the picture. i promise to do it after 2.11 but before 2.12. can you rebase the change for now? there have been some UI changes.

@lucaspinelli85 i updated http://rojer.me/files/shelly/misc/shelly25-449.zip to reflect latest changes.

[lucaspinelli85]

Ok, now update and test it!

[lucaspinelli85]

@rojer have tested and I have the following problems:
1: I have an effective closing time of 33 seconds and an effective opening time of 27 seconds. how should i configure the setting? As after some up and down movements the position is out of phase and cannot physically return completely closed or open.
2: in the opening, in the webui it does not reach 100%, but at 99%, in the homekit it remains "I'm opening ..."

[juangamnik]

@lucaspinelli85 the automatic calibration does not work with different opening and closing times too AFAIK. And this was not the original intention of this issue here.

I personally think it should be handled in a different issue, after all.

[lucaspinelli85]

@gate546 , @Andi161 , @delicjous , @lieberjott they have the same problem too. A small time difference is enough to prevent the physical limit switch from returning to its position, and each time it will be more and more distant.
Forcing to increase the moving time and make the entire run in one direction and the other to return to the leader position.
In automatic mode you also go to see the current draw to determine
with more accuracy
arrival in position. Here it is not possible so it is almost mandatory to have two times, one for ascent and one for descent in order to be as precise as possible in the arrivals of the limit switches.
This is the my opinion...
What about 99% blocking instead of 100% arrival? I can not even create the automation that "when it is open ..." because it is never open if it remains at 99%.

[lucaspinelli85]

I have noticed a new problem.
3: if I move up and down through the homekit percentage bar, very often the shelly keeps both the up and down outputs active!
This is a serious problem because the connected ECU sends me haywire!
Shouldn't this happen, in any case, isn't there a safety (as in automatic mode) that only one of the two outputs must be active at a time?
(In some shutters, if the control unit receives up and down at the same time, it is a limit switch setting mode ... a mess would come out ...)

[lucaspinelli85]

@rojer I think it is still too early to approve the change in the official firmware, because many like me will encounter the same problems and you will be inundated with avalanches of requests for help!

[juangamnik]

I have noticed a new problem.
3: if I move up and down through the homekit percentage bar, very often the shelly keeps both the up and down outputs active!
This is a serious problem because the connected ECU sends me haywire!
Shouldn't this happen, in any case, isn't there a safety (as in automatic mode) that only one of the two outputs must be active at a time?
(In some shutters, if the control unit receives up and down at the same time, it is a limit switch setting mode ... a mess would come out ...)

Sorry to say, but my code does not change anything on how the firmware keeps the output active. My changes are minimally invasive with just a few lines changed regarding time/position measurement. This issue will then exist in the normal firmware, too.

[juangamnik]

I have noticed a new problem.
3: if I move up and down through the homekit percentage bar, very often the shelly keeps both the up and down outputs active!
This is a serious problem because the connected ECU sends me haywire!
Shouldn't this happen, in any case, isn't there a safety (as in automatic mode) that only one of the two outputs must be active at a time?
(In some shutters, if the control unit receives up and down at the same time, it is a limit switch setting mode ... a mess would come out ...)

Please take a look at my explanation here (we should not discuss on two threads). I really think you misunderstand this.

[juangamnik]

@rojer I think it is still too early to approve the change in the official firmware, because many like me will encounter the same problems and you will be inundated with avalanches of requests for help!

@rojer / @lucaspinelli85: could you figure out the issue of Luca in the main code base? It is not related to the minor changes in my fork, right? Can we merge the changes to master now? The issue of Luca should (IMHO) be handled in another issue as a separate (perhaps foundational) problem with the firmware.

[robim385]

Hi all. I have 6 rollers with Shelly 25 and 5 are working fine without any issues. 6th probably has broken limit on motor when shutter is opening while closing limit on motor is working fine. Without opening limit, I am not able to do automatic calibration.

@juangamnik do you think I might be able to use your FW and set everything up by using manual calibration?

[ludalex]

Completely unrelated question to the topic, apologies but I can't find anywhere else to ask... for you who connected a KLF 050 to a roller/shutter switch type: does it work such as:

• short button press: window/blind completely closes/opens?
• button logn press: window/blind keeps moving and stops when you stop pressing?

[nicx]

@rojer any news when this (great!) feature will find its way to your firmware? :)

[nicx]

basically I would also like other users need different times for opening and closing (which is in the original firmware also depositable), but now I have first tried as it is.
it works in principle, but I also have the problem that when opening the shutter stops at 99% in the UI ("idle pos 99 -> 100"). That is, in the Home app, the shutter also stops on "opening...". the closing, however, works perfectly.

what can I do to solve the 99% problem?

[nicx]

any hint to solve the 99% problem?

[MrMarcel24]

Hi everyone :),

I am happy, that I found a solution to integrate my Shelly 2.5 roller shutter into my HomeKit environment (THANK YOU SO MUCH @rojer). I am glad, that it works now even without measuring the power consumption. But I also encounter the 99% problem, but lack the skills to solve the problem 😅. I hope, there will be a solution. Again: Thank you for your work!

[davebacsi30]

Hy!
Please help! I can't upload this firmware switch25-2.11.0-alpha1 .
Work it today?

Thank You!

[davebacsi30]

I have 5 shelly 2.5 roller shutter. 1 work great movement time 52sec. 4 don't work movement time 5-7 sec with automatic calibration.

[dev2ek]

First of all, I would like to thank you for this great project 😊👍👍👍😊

@rojer are there any thoughts from you as to when this great feature can be integrated into the current firmware?

I am using the current version from your link:

http://rojer.me/files/shelly/misc/shelly25-449.zip

Unfortunately this version still has the 99% problem ☹

Thank you very much for your work!

[nicx]

any news to the 99% problem with this special firmware?

[gmuth]

This feature should also help when power metering of the shelly 2.5 is broken (e.g. due to aged capacitors).
Whatever the result of the auto calibration is should be configurable in a manual way.

[nicx]

just a short update: I switched to ESPhome, with this on my shelly 2.5 everything works great :)

[lucassite120]

FYI: I moved to HAA Homekit firmware. It has a lot of roller shutter extra features, and it works with new Plus devices too with OTA flash:
https://www.youtube.com/watch?v=06YHkRkwJE4