shelly-homekit
shelly-homekit copied to clipboard
mongoose-os-apps
use shelly 2.5 roller shutter without calibration
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?
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?
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
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?
@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 😞
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?
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
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?
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.
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!!
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)
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
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...
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)
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: 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.
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.
@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)
If I should add corresponding documentation, it would be nice if someone could give me the corresponding rights on the wiki.
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.
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.
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 :-)
@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.
@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
@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.
Hi Johannes, i have a question to your new codes. I have copies all codes into the original 2.7.3 files and replaced them into the zip file. then i uploaded them into the shelly. But nothing has changed. What didi i wrong? Or whar should i see?
@joha1971 the code has to be compiled and you should not copy two versions into each other. Either you wait for the version that contains the new feature or you build it yourself and deploy it (by checking out my fork and deploying it via OTA to the device).
Here you can find how to do this: https://github.com/mongoose-os-apps/shelly-homekit/wiki/Development