@peterbrown77.pb, you’re not the first person to ask for motor support. If you search this thread, you’ll see a discussion on the topic a few weeks/months ago.
As you’ve surmised, motion control can be fairly complicated. You’re exactly correct that the use of CW/CCW/HOME limit switches is required when using a motor without built-in feedback control. This is why Servo motors are supported and other motors currently are not.
If I were to add this type of motor control, I’d probably create a new Motor Parent Class, which stepper and dc motors would inherit from. The parent would include inputs for CW/CCW/HOME limit switches. Standard motion functions would also need to be included, like a homing routine, move continuous, move relative, etc...
Where I struggle with adding something this complicated is how to properly implement such a device within Hubitat. There are no standard capabilities that would be useful in creating a generic motion control device. Thus, the device would be a custom device, and standard apps would not be very useful.
I feel that a solution like this ends up be very custom and specific to the user’s project. Perhaps it does make more sense to write a custom sketch as you’re suggesting.
Thanks for that mate. Yeah I had mine really close to the board so if that or power is an issue then that could well be it. It's all good I have some in ceiling ones coming in soon that are individually powered so I might hook them up and see how I go.
For the actuator to move the distance I want with the threaded rod I'm using it would need to rotate about 30 times. These are operated far different than my Venetian window blinds.
I've used that for my servo motor blinds with 270 degree servos and it worked well, so thanks.
Oh ok. Interesting I hadn't stumbled a cross that. Best search harder next time.
As I'm only looking at the trigger source being 3 states maybe I'll ust implement that with two virtual switches to trigger http post to the esp8266 until this is added to hubduino. Seems way over my head at the moment.
@ogiewon I am using a BME280 on a Lolin Mini Pro but I only want the pressure readings. Is there a way to leave out the temp and humidity part so that the child devices are not even created? I tried to leave out the temperature1 and humidity1 but this just created an error when compiling. Would I need to customize the driver to do this? I'm still learning as I go.in Arduino land so thanks for any help.
The quickest way to accomplish this is to simply edit the PS_AdafruitBME280_TempHumidPress.cpp file, compile, and reload the sketch on your microcontroller.
Is there a suggested way to control the polling interval from the arduino side? I've got a couple esp32s setup with photoresistors and i'd like to update HE very fast/immediately when there's drastic changes, but for small changes, I'm fine with waiting a minute or so.
Do you mean for one of the analog sensors attached to the ESP32? No, once that is built into the constructor for the Hubduino device, that is the rate that the board will update Hubitat. What type of device are you thinking you would want to update more frequently than 30 seconds to a minute?
If you take a look at the top of the PS_Illuminance.h or cpp files, you will see how you can adjust the polling interval.
// Create an instance of this class in your sketch's global variable section
// For Example: st::PS_Illuminance sensor1(F("illuminance1"), 120, 0, PIN_ILLUMINANCE, 0, 1023, 0, 1000);
//
// st::PS_Illuminance() constructor requires the following arguments
// - String &name - REQUIRED - the name of the object - must match the Groovy ST_Anything DeviceType tile name
// - long interval - REQUIRED - the polling interval in seconds
// - long offset - REQUIRED - the polling interval offset in seconds - used to prevent all polling sensors from executing at the same time
// - byte pin - REQUIRED - the Arduino Pin to be used as a digital output
// - int s_l - OPTIONAL - first argument of Arduino map(s_l,s_h,m_l,m_h) function to scale the output
// - int s_h - OPTIONAL - second argument of Arduino map(s_l,s_h,m_l,m_h) function to scale the output
// - int m_l - OPTIONAL - third argument of Arduino map(s_l,s_h,m_l,m_h) function to scale the output
// - int m_h - OPTIONAL - fourth argument of Arduino map(s_l,s_h,m_l,m_h) function to scale the output
However, I would strongly recommend that you not send data any faster than ~every 30 seconds to the Hubitat Hub.
Now, if you're a C/C++ programmer, you could modify PS_Illuminance.cpp to only send data if it has change by a certain amount compared to the last value sent, to prevent spamming the hub with unnecessary updates. If you did this, then you could change the polling interval to something like every 1 second to check the photoresistor value, BUT be sure to make certain to not flood the Hubitat Hub with too frequent updates.
Right now, ambient light sensors that influence the dimmers in the same room. If my wife closes the curtains, I want the dimmers to respond immediately to the new level of light in the room. If it takes up to a minute, she's gonna (rightfully) roll her eyes at me when I explain how it works.
In general though, I want everything to be as responsive as possible. Delays and slow responses are what drove me from wink to hubitat.
Many lum sensors will have both an analog and digital output and a pot on top of the sensor to adjust the sensitivity of the digital output. The detection of the change to the digital output would be instant. Also, be careful when using a lum sensor in the same room that you are adjusting the lights. Since lum sensors don't care about the source of the light, as soon as the lights come on, the lums will go back up. So, if you have lights being turned on and also turned off by the lum sensor you can create a loop where the light in the room drops so the lights come on. Now the lights are so high that the lights turn off. And now it's dark enough where the lights come on. And so and so on and so on. If you stick to just turning the lights on, you can avoid such a loop.
Nothing specific. I just think it would make things more manageable on this topic, and easier for people to search and find answers. I can't stand megathreads. I used to run a few different forums, and whenever a megathread popped up, I usually found a way to create an actual section for it. They tend to do this over on the Vera forum, where there are sections for different 3rd party plugins and apps.
So I'm having no luck getting the Hubduino Parent Ethernet shield to auto add the child devices. I've followed all the steps listed on the tutorial and searched here for solutions and cant find anything else I could be doing wrong other than, using a clone uno and W5100 which I plan to soon replace with a Sainsmart Mega2560 and Arduino brand W5500. Also I am powering the Uno/shield right now via a USB cable from the router or laptop so maybe this could be another cause of the problem. I have set both static IP addresses for the Uno and Hubitat which I presume I did correctly since the Hubitat is working. Any advice would be appreciated!
Did you change the Hub’s port in the sketch to 39501 ?
That is the one big difference between ST and Hubitat.
If you’re using the latest HubDuino groovy drivers, I have greatly simplified the setup of the parent to only require the Arduino’s IP address and port it is listening on.
If these tips don’t help sort it out, please post your Arduino sketch as well as a screenshot of the HubDuino Parent Device’s settings.
You can also look in the live/past logs in your HE hub for clues.
