shelly-homekit
shelly-homekit copied to clipboard
mongoose-os-apps
adding manual WC calibration.
I added the ability to manually calibrate roller shutters (window closing). This should be used for roller shutters with end position detection, only (should be the case for any motor newer than 25 years). Therefore, a "Caution" hint is added as soon as manual calibration is activated. Two values can be set: (1) the move time. (2) For movements to limit positions a second (i.e., longer) movement time (to limit pos) can be added.
I think it’s not a good idea to depend on a external library just for an icon.
I think that the whole "Caution" is unnecessary since the calibration expects, that the motor safely finds its limit position, too. So no need for a Caution. From my point of view this can be removed without replacement :)
Any news on this? Awaiting this feature eagerly! Thanks for all the hard work!
Me too, I wait impatiently, because the automatic calibration only gives me 20% of the Shutter. This homekit firmware is awesome.
hi @rojer are there any news regarding the implementation? would be great!
@rojer thanks for your effort! Could you estimate, when it will be possible? I have the same problem that I cant use the shelly like I want to due to the fact that the consumption is 1.083 and stop after 1 sec instead of 28.
okay thank you. I haven't found a walkaround so far. Do you know if there would is one?
you could always use a custom build, i believe @juangamnik posted a link to firmware with this patch before.
@philmue1988 https://github.com/mongoose-os-apps/shelly-homekit/suites/2022082155/artifacts/40563570
@juangamnik entweder bin ich zu blöd... siehe Screenshot.
Hab's dann selber per Fork probiert, jedoch scheitert der Buildprocess.. könntest du mir deine Firmware irgendwie anders zukommen lassen? :)
.
@juangamnik entweder bin ich zu blöd... siehe Screenshot.
Hab's dann selber per Fork probiert, jedoch scheitert der Buildprocess.. könntest du mir deine Firmware irgendwie anders zukommen lassen? :)
Dear @raaaf. The artifacts are removed after some time. I couldn't rebuild the project as is either (although this is done in docker and should be repeatable...), but I synced with the upstream repository and did a rebuild and that completed. But be careful... I did not test the new build yet!
Here you can find the release: https://github.com/juangamnik/shelly-homekit/actions/runs/1403210981
@juangamnik cheers, mate. It works perfectly and finally I have the correct visual ui in Apple Home. Thanks for writing the necessary code and rebuilding it. I appreciate it.
Thank you very much for updating 🙏 I've only used the OTA method to install/update my shellys. How do I install this fork, dies it work OTA? I tried uploading the.zip from this fork/zipball/master but that doesn't work.
Thanks in advance.
thanks @juangamnik ! i uploaded the shelly 2.5 zip to my site, you can use this url for OTA: http://rojer.me/files/shelly/misc/shelly25-449.zip
Hello thanks for your firmware. I tested your Firmware to set the max. close position for my shutter. I have a catdoor in my window glass. My target is when I close the shutter with the physic button and the My home button on IPhone then is the max close position on ca.80% (perfect postion that can cat go out and in with a close shutter). With your firmware works for one time to close. But when I open the shutter, then is not full open and when I close agan, the position is not the same then before. I think the problem is, the close time and the open time is not the same. Can you make a option for buth? Or I can set this on a diffrent way?
Thank you for your efforts.
Tried the build but somehow it's not working for me. My Shutters need around 22s to close. And 23 to open. But even with 22000ms the shutters are not opening or closing correctly and in homekit it's always showing the opposite state. Weird.
Dear @raaaf. The artifacts are removed after some time. I couldn't rebuild the project as is either (although this is done in docker and should be repeatable...), but I synced with the upstream repository and did a rebuild and that completed. But be careful... I did not test the new build yet!
Here you can find the release: https://github.com/juangamnik/shelly-homekit/actions/runs/1403210981
Thanks so much @juangamnik!! I was stuck on Version 2.7.3 and the timeout Bug after 28 days was driving me nuts...
I have tested last version and I have the following problems:
1: I have an effective closing time of 33 seconds and an effective opening time of 27 seconds. I workaround by setting longest time and more, but after some up and down movements, the position is out of phase and cannot physically return completely closed or open.
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.
2: in the opening, in the webui it does not reach 100%, but at 99%, in the homekit it remains "I'm opening ..."
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 @Kerubin89 @vaenror your issue seems to be about differing open and closing times and not about manual calibration (caused by roller shutter switches, which do not directly put current into the shutter motor). The former was the initial issue and for that, this fork has a fix.
I believe your issues should be fixed in the automatic calibration first (introducing open and closing times, which is currently not available). Afterwards we can enhance the manual calibration to support this too. But this are two different issues, which should be handled separately. If we try to change multiple things at one time this can cause other issues (in Software Engineering small change sets are a way to handle complexity and build reliable software).
Hence, as far as I am concerned, we should merge this pull request for its original purpose as soon as @rojer says it is time and handle your problem in a separate issue. OK?
I'm trying to make it clear that it will be impossible to have a manual calibration with a single time because even if only slightly, there will always be a small difference between there and back. Imagine having a Ferrari on a highway that goes one way, to become a Fiat again. With the same time, Ferrari will go further so if you start from one point with the Ferrari and return with the Fiat using the same time you will never return to the starting point, multiply this fact more times and you will find yourself further and further away from the starting point. I hope I explained myself...
I'm trying to make it clear that it will be impossible to have a manual calibration with a single time because even if only slightly, there will always be a small difference between there and back. Imagine having a Ferrari on a highway that goes one way, to become a Fiat again. With the same time, Ferrari will go further so if you start from one point with the Ferrari and return with the Fiat using the same time you will never return to the starting point, multiply this fact more times and you will find yourself further and further away from the starting point. I hope I explained myself...
Sorry that I repeat myself: The automatic calibration does not have two times, too. This are two different issues. The issue that you describe are even a problem if you have no difference between open and close time, because motors do need time to start and stop. The calculation of ramp up and down-times is not exact. Therefore the position will change over time anyway. The automatic calibration deals with this via a separate "run to limit" variant if you do not set the shutters to a value between ]0..100[, but exactly to 0 or 100. Then it will stop as soon as no current is measured.
Since this is not possible in manual calibration (as there is no current to measure), we have the limit time. So if you go to exactly 0 or 100 it will go for the time from current position to the end position plus the limit time (to be sure to reach the end position and start from a clean state; it goes in a different state for that, so that the percentage is not part of the movement to end position for limit time, since this would lead to diverging positions again; the first version of my fix did this and did not work that well, because of that). This does mitigate the problem of diverging positions. So it "recalibrates" each time you move completely up or down. Some control software even does these recalibrations from time to time on its own (but not this firmware).
Did you try to use the Limit position parameter accordingly? For me it is Movement Time: 11000ms and Limit Time: 1000ms.
I hope I explained myself 😇
Of course, you have explained yourself perfectly. Perhaps the problem is because automatic calibration is usually performed almost always in the rolling shutters which by their nature, at least once a day, do the entire opening stroke and the entire closing stroke. So it is as if each time the percentages are recalibrated at each limit switch. However, if you stay in the middle without touching the limit switches, the problem arises ... As you say, it is a different request from the one for which the manual calibration was made, but in my opinion it is something to integrate as many will have this "problem" that in the automatic calibration we do not realize because we normally close the shutter all night and we reopen it all day. If I put the time limit (maybe it's another bug) it adds up to the movement time, not only to get to the limit switch but also in the intermediate positions. Example: I set a time limit of 1 second, I open to 50%, when it reaches 50% it continues for another second. This shouldn't happen, should that second only be used when I fully open or fully close to be able to "press" the limit switch contact?
Of course, you have explained yourself perfectly. Perhaps the problem is because automatic calibration is usually performed almost always in the rolling shutters which by their nature, at least once a day, do the entire opening stroke and the entire closing stroke. So it is as if each time the percentages are recalibrated at each limit switch. However, if you stay in the middle without touching the limit switches, the problem arises ... As you say, it is a different request from the one for which the manual calibration was made, but in my opinion it is something to integrate as many will have this "problem" that in the automatic calibration we do not realize because we normally close the shutter all night and we reopen it all day.
For the roller shutter it makes no difference. Why should you do full open/close runs less often in manual mode? It is all the same, if you set the limit time.
If I put the time limit (maybe it's another bug) it adds up to the movement time, not only to get to the limit switch but also in the intermediate positions. Example: I set a time limit of 1 second, I open to 50%, when it reaches 50% it continues for another second. This shouldn't happen, should that second only be used when I fully open or fully close to be able to "press" the limit switch contact?
Are you sure, that you use this release? This was fixed in this version as mentioned above
But I am not using the shelly in manual calibration for a roller shutter, but for the motorization of an elevator that I cannot connect directly to the motor, but via the control unit! For this reason I have these problems, because I don't often go to the limit switches and stay in the middle with the movements. I use the latest version @rojer shared yesterday.