Skip to content
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

Enhance new shutter modes and code cleanup. #9244

Merged
merged 10 commits into from
Sep 9, 2020

Conversation

stefanbode
Copy link
Contributor

Description:

#9098 fixed enhanced
#8901 fixed enhanced

Refactor the driver to support different kinds of requirements to operate relays/stepper/servos and open for future requests.
Pulsetime on relays now can be defined independently from the operation mode of the shutter. Only define pulsetime on the relay.
Added new "shuttermode" command to specify an operation mode. Default is 0 and will autodetect the mode as in the previous version as the best guess. The following modes are supported: SHT_UNDEF, SHT_TIME, SHT_TIME_UP_DOWN, SHT_TIME_GARAGE, SHT_COUNTER, SHT_PWM_VALUE, SHT_PWM_TIME,
New modes:

  • Garage mode (3). Operate Garage door only with one pulse on relay1 with automatic reverse
  • Servo value (5): Operates a servo where PWM value controls the position. Also supports fancy shuttermotordelay to smooth ramp up down servo like the stepper motor is already using.
  • Servo 360° will come in the future (6):

Related issue (if applicable): fixes #
#9098 fixed enhanced
#8901 fixed enhanced

Checklist:

  • [x ] The pull request is done against the latest dev branch
  • [ x] Only relevant files were touched
  • [x ] Only one feature/fix was added per PR.
  • [x ] The code change is tested and works on Tasmota core ESP8266 V.2.7.4.1
  • [ x] The code change is tested and works on core ESP32 V.1.12.2
  • [ x] I accept the CLA.

NOTE: The code change must pass CI tests. Your PR cannot be merged unless tests pass

@stefanbode stefanbode changed the title Patch 1 Enhance new shutter modes and code cleanup. Sep 5, 2020
@arendst
Copy link
Owner

arendst commented Sep 6, 2020

Stefan, is this stable? I plan to release v8.5 tomorrow but am reluctant to include this major change. pls advice.

@stefanbode
Copy link
Contributor Author

Hi arendst. Please do NOT integrate for the next stable release. I already did a lot of testing but you never know I I do not want to break something in a stable release. You can integrate it AFTER the release of 8.5. So I also have time to update the documentation. And also check for the stepper motors.

@stefanbode
Copy link
Contributor Author

I found an Issue in the Stepper driver. Please do not integrate now. Will post an update Tuesday

@ascillato2 ascillato2 marked this pull request as draft September 7, 2020 17:43
- fix restart bug on servo
- refactor smooth-ramp for stepper and servo. Now in RTC and much more stable
- increased internal resolution to better work with ramps
- testing, testing, testing....
@stefanbode
Copy link
Contributor Author

Now I'm pretty sure that not only the normal shutter still operates This was also OK before. Now also the smooth ramp on stepper and servos is in sync and tested hours and hours and hours... :-) Driver is now tested 100% and I would also be fine with 8.5. Depends on you. In many cases the stepper runs better than before.

@ascillato2 ascillato2 marked this pull request as ready for review September 8, 2020 23:52
- harmonized variable naming
- add more code comments to help others to understand
- SWITCH/PULSE now defined for each shutter.
@stefanbode
Copy link
Contributor Author

@arendst : Hi Theo, the servo operation PWM min and max are currently hardcoded. I see there is already a PWMrange defined in the standard. But this just seems to limit the max value. Is there already a way to limit the PWM value instead of 0..1023 to 90..500 without inventing additional variables?

@arendst arendst merged commit ff3d070 into arendst:development Sep 9, 2020
@arendst
Copy link
Owner

arendst commented Sep 9, 2020

Current PWMRange command only supports 255, 511 or 1023 (being 8, 9 and 10-bit) resolutions. These values make calculation PWM values very easy.

The bottom range is always 0.

Changing this to any value like higher low and different high values will at least for lights introduce issues. The chances of having an esp8266 control both lights and shutters are dim.

I think the best way forward and keep lights and shutter not intertwined you'll need to introduce a ShutterPwmRange command with both a low and high parameter like ShutterPwmRange 90,500. This way future additions won't interfere with your shutter code. Just take two uint16_t values from the settings.h list.

@pawol pawol mentioned this pull request Oct 4, 2020
15 tasks
@pawol
Copy link

pawol commented Oct 4, 2020

Please look at issue #9458
Tasmota 8.5.1 is affected by roller shutter timing bug

@stefanbode stefanbode deleted the patch-1 branch October 8, 2020 07:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants