How to connect stepper motor or servo motor with node mcu or d1 mini to hubitat
Please step by step instruction
How to connect stepper motor or servo motor with node mcu or d1 mini to hubitat
Easiest way is to simply use my HubDuino project. The ReadMe includes step by step instructions for getting the basic system up and running. Example sketches are provided. HubDuino supports servo motors. It does not currently support stepper motors.
is it possible to use somehow stepper motor?
Sure - as long as you know how to write Arduino C++ code, you could easily add that capability to my project.
What are you trying to accomplish? That might help the community provide you with better ideas for how to achieve your goals with multiple options.
Most people are using inexpensive servo motors to automate blinds. Is there a reason a servo motor will not work?
In general, custom solutions for blinds and shades is going to require some programming experience.
Yes that's why i trying to find ready project.. (Copy /paste) lol
ok, trying set up everything together. just created driver with child-servo.groovy and APP in Hubitat
but how to find arduino SCETCH? (for esp8266 board)
As a starting point, you can try the following sketch in my GitHub repo (along with numerous other example sketches.)
In the main HubDuino thread, you’ll find quite a bit of recent discussion regarding a lot of changes that we made to the Servo motor class. You should also read the comments at the beginning of the EX_Servo.h or .cpp files.
//****************************************************************************************** // File: EX_Servo.h // Authors: Dan G Ogorchock // // Summary: EX_Servo is a class which implements the SmartThings/Hubitat "Switch Level" device capability. // It inherits from the st::Executor class. // // Create an instance of this class in your sketch's global variable section // For Example: st::EX_Servo executor1(F("servo1"), PIN_SERVO, 90, true, 1000, 0, 180, 2000, 544, 2400); // // st::EX_Servo() constructor requires the following arguments // - String &name - REQUIRED - the name of the object - must match the Groovy ST_Anything DeviceType tile name // - byte pin_pwm - REQUIRED - the Arduino Pin to be used as a pwm output // - int startingAngle - OPTIONAL - the value desired for the initial angle of the servo motor (0 to 180, defaults to 90) // - bool detachAfterMove - OPTIONAL - determines if servo motor is powered down after move (defaults to false) // - int servoDetachTime - OPTIONAL - determines how long after the servo is moved that the servo is powered down if detachAfterMove is true (defaults to 1000ms) // - int minLevelAngle - OPTIONAL - servo angle in degrees to map to level 0 (defaults to 0 degrees) // - int maxLevelAngle - OPTIONAL - servo angle in degrees to map to level 100 (defaults to 180 degrees) // - int servoRate - OPTIONAL - initial servo rate in ms/degree (defaults to 2000, used to ensure a gentle move during startup, afterwards comes from SmartThings/Hubitat with each move request) // - int minPulseWidth - OPTIONAL - minimum pulse width in milliseconds, defaults to 544 (see Arduino servo attach() function) // - int maxPulseWidth - OPTIONAL - maximum pulse width in milliseconds, defaults to 2400 (see Arduino servo attach() function) // // Change History: // // Date Who What // ---- --- ---- // 2018-06-23 Dan Ogorchock Original Creation // 2018-06-24 Dan Ogorchock Since ESP32 does not support SERVO library, exclude all code to prevent compiler error // 2018-08-19 Dan Ogorchock Added feature to optionally allow servo to be powered down after a move // 2019-02-02 Jeff Albers Added Parameters to map servo endpoints, actively control rate of servo motion via duration input to device driver, intializes to level instead of angle // 2019-02-09 Dan Ogorchock Adding Asynchronous Motion to eliminate blocking calls and to allow simultaneous motion across multiple servos // 2019-03-04 Dan Ogorchock Added optional min and max pulse width parameters to allow servo specific adjustments // // //******************************************************************************************
awesome... thanks...now hubitat can't see the new device...
thank you so much
Greetings to you.
For learning purpose of ST_Anything_Servos_ESP8266WiFi, could you please advise me which servo part I can buy? Any recommendation? Thanks in advance
I used an MG995 servo but I suspect that you could use almost any digital servo with three wires where there was a positive, ground and a single digital control line,
So I am no engineering expert, but I have read that the stepper motors may be a more stable system for the blind tilt mechanisms as they do not require a constant electrical load to maintain their position. There is also more likelyhood a servo may burn out over a shorter period of time for this reason. A stepper motor with decent torque may not require constant readjustment. This becomes more important when you also want to potentially create a system to raise and lower the blinds, but also utilize solar panels for primary power as opposed to replacing a battery or having primary AC power. I have a number of small windows that are approximately 20 feet up (lighting a loft area) with no available power feeds nearby (ceiling or otherwise). That is why I am interested in the previous questions regarding a stepper motor possibility. It would also allow your HubDuino even more control over fun automation such as launching robot sharks with lasers on their heads during an HSM intrusion alert . Ok maybe that is going to far... for now.
I don't have solar power working yet, but here's my version of how to build this yourself. Might be helpful for ideas.
I have worked with stepper motors at work for that past 31 years. They do, in fact, require a constant electrical current in order to maintain position. However, if they (or any motor, including servos) are properly geared to prevent 'backdrive', then power can be reduced/removed from them once they have reached their target position.
Not sure I completely agree with this. Servo motors do have built in position feedback, which allows them to maintain a specific position. I see this as an advantage over a stepper motor. However, I will concede that the buzzing of a servo motor can be very distracting, and will lead to reduced battery life. This is why my HubDuino library's EX_Servo device allows you to remove power after the servo has achieved its target position. As long as everything is mechanically designed to prevent backdrive, the blind's tilt will not change. So, you get very accurate position control due to the built-in position feedback, and can achieve good battery life with no buzzing.
I agree completely. Trying to raise or lower blinds with a 180 degree servo motor does not make sense. A stepper motor makes much more sense in this scenario.
Yes, adding support for stepper motors in HubDuino would be very useful. I really do wish someone would tackle this challenge and submit a Pull Request to have stepper motor support added. But, in order for me to accept such a PR, it would need to take into account all of the issues that stepper motors bring with them. For example, with no built-in position feedback, most stepper-based motion systems require three limit switches - Home, ClockWise, and CounterClockWise. The Home limit switch allows the system to determine the position of the motion system during a power on sequence. The CW and CCW limit switches prevent over-travel, which in turn prevents mechanical damage to the overall device being manipulated. Adding these limit switches would make using a stepper very complicated for simply automating a home window-blind. Thus, this is the reason that I have not spent any effort on adding stepper functionality to HubDuino. I cannot come up with a simple design that meets the needs of users, while maintaining a safe electro-mechanical design. I do not want users angry/upset claiming "HubDuino just broke my expensive window blind!" due to the fact that a stepper inherently has no way of knowing its position. It would require a user t go through a calibration process, and hope that the user never adjusts the blinds manually during a power outage.
As @jwetzel1492 has pointed out, there are plenty of examples where folks have purpose-built automated blind controllers using stepper motors. Hopefully one of those will meet your requirements and can be integrated with Hubitat.
I will also admit that I have zero personal motivation for automating window blinds or shades. Every window in my house has interior wood plantation shutters installed. These were here when we bought the house, and would be very difficult to automate. Thus, I have chosen to focus my energy elsewhere.
@ogiewon's point about limit switches for a stepper motor is a good one. I was fortunate in that I discovered that the torque necessary to break my blinds was far greater than my stepper was capable of putting out. If it hits the mechanical limit, it makes some noise as the stepper tries to go past and gives up, but nothing breaks.
So what I did in my driver is:
- ignore the counter-clockwise direction. It just goes from 0-100%, open to closed.
- When the NodeMCU powers on, it assumes it is in the open position. (it is easy to adjust them by hand, so I put them in the open position before I plug in the power.)
- if somehow there is a power loss while in the closed position, it's not a big deal. It'll think it's open, but the next time it tries to close, it'll hit the mechanical limits and not move, but now the internal state will be correct.
So I ended up not having to add limit switches.
(However, YMMV as far as the "it doesn't break my expensive blinds" thing goes.)
Followup: I did some stress testing on my blinds today. While the stepper isn't powerful enough to hurt the blinds, if you push the mechanical limits hard enough, it is absolutely possible to strip out the internal gears of the stepper. Fortunately, they are cheap and easy to replace.
Thanks for the great input! That is helpful in trying to figure out what to do and make sense of the debate around which route to go. Yes I have rooms with plantation shutters I have no intention of removing or automating either! Some things are just better left the old-fashioned way. I have a number of loft windows that are unreachable and 17 feet off the floor though, so those are my primary targets for blinds and remote control.