Have you tried adjusting the 'servoDetachTime' parameter (see below)? Perhaps holding the power on for a little while longer would allow things to settle down before the code performs the servo detach command? Maybe even consider using a unique amount of time for each servo motor, to spread the 3 detach commands out a bit? Just a guess...
//******************************************************************************************
// 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)
I am not familiar with the ocelot. However, you may have two power sources fighting one another. By default, my example sketches enable the Arduino GPIO Input-PullUp feature which causes the Arduino to put either 5vdc or 3.3vdc on each contact sensor pin. This feature can be disabled in the sketch on a per contact sensor basis.
If the Ocelot using 5vdc? 3.3vdc? Something else? If you put a volt meter between the Ocelot input pin and Ocelot Gnd, what voltages do you see with the magnetic reed switch open and closed?
Hi Dan,
Yes, I have played around with the DetachTime from 500mS to 2000mS, and no difference. As I mentioned it happens in Group mode as well as when I move the servos individually, so a staggered DetachTime is moot then . . .
Wish I had more ideas. I don't actually use any servos, so no firsthand experience with how they behave long-term. Hopefully one of the other 'servo guys' will chime in with their advice.
I've tried to use the latest version to use A0 as a digital input but it doesn't seem to be working. I've tried using a manual pullup resistor to then trigger when the input is grounded. I've also tried wiring the other end of the input to 3.3v and triggering when it reads high but neither is flipping the digital input. Is there something special that I have to specify in the constructor when using A0 as a digital input? Any tips/ideas?
Hi Dan. I've just started working with HubDuino, and I'm loving it so far! You've made it every easy to set up devices and get them integrated with Hubitat
I have a question about the beSmart function that I see in most/all of the polling sensor classes, which allows for dynamically changing the polling interval from Hubitat. Has this actually been implemented in any Hubitat device handlers? I tried to find examples where it's used, but I couldn't seem to find any.
I tried adding an Input to my device handler, so that I could set the polling intervals for my multiple sensors from within Hubitat. It seems to work nicely (I added a sendData() call in the updated() function), but it seems to me that this value would get ignored each time the Arduino gets powered on. The sensors will get initialized again with whatever interval was entered in the sketch. Did you have any plans on dealing with this, like maybe storing the updated interval value into EEPROM or something?
You’ve hit the nail on the head! I’ve never fully implemented the adjustable polling interval from the driver. Using either EEPROM or a handshake between the Arduino and the Parent each time the Arduino starts are two ways I’ve thought about it. However, since you can set a relatively quick polling interval in the sketch without detriment, I have never finished that code. I’ve opted for simplicity. No current plans to implement that functionality.
Haha. Fair enough! I guess you've gone with the approach of setting fairly short default intervals in your sketches, and then adjusting upwards from Hubitat, if necessary? Kind of a "better safe than sorry" approach?
I kinda like the idea of being able to set these in Hubitat, so I might see if I can implement something that'll work. If I do manage to, and isn't horrible code, I might submit a pull request. I'm really not very experienced with Arduino code or C++, though, so we'll see... hehe
I only have one polling sensor, the current sensor for my dryer. When I'm not doing wash, I just turn off the board. That way, it's not bombarding the hub with unnecessary messages the majority of the time. I even have the power supply on a smart plug and use a button the board to trigger the shutdown. if you don't need to have measurements from you sensor 24/7, a solution like that could help.
In my case, it's not so much about reducing unnecessary traffic (although that's something to think about, too), but more about being able to easily adjust and experiment with different settings, especially in the setup phase of my project. I'm working on having 2 or 3 ultrasonic sensors measuring water tank levels. By the time the project is fully implemented, I imagine I'll be happy with a polling interval of every minute or even higher. But while I'm testing the sensors, the code, and the calculations, I've been changing the intervals around a fair bit. Instead of having to recompile and upload a modified sketch, I can quickly change a few settings in Hubitat.
Granted, I might never adjust them again once I've decided on the intervals, but it certainly comes in handy during the setup phase
I typically collect data from polling sensors about every 60 seconds (or longer depending on how quickly the thing I am monitoring can actually change.)
Using an ESP8266 you can also simply update the sketch over WiFi, to tweak the settings.
At the end of the day, I realize that being able to set the polling intervals in Hubitat is likely not going to be that much of a great feature, because once I've got things figured out, I'm not likely to change the intervals in the future. But it's just one of those things that sounds like a cool ability to have. And a big part of it is simply the thrill of the challenge
So, I wanted to share a use-case I don't think I've seen mentioned before. I was looking at using a Sonoff Basic in a spot I needed just a switch but I already had in that place a Hubduino board. So, I looked as adding a regular relay borad to my Hubduino board also. Then it occurred to me, the Sonoff runs an ESP board! Well, low and behold, there is enough flash memory to hold a huduino sketch as well!! You are a little limited with the number of GPIO pins you have access to but you get a board, case, relay and power supply all wrapped up in one neat little package. Saved me a lot of soldering!! Just wanted to share in case anyone else is in the same situation.
I got some of those devices a few years ago. When I had a look at the insides, the assembly quality bothered me so I relegated them to just doing sensors. I eventually consolidated those sensors to a couple of ESP boards because I lost what little trust I had in them when the screw terminals broke away on a couple.
You mention the limited number of GPIO pins. I only remember there being one. If there is a way to get access to more than one GPIO pin I might try to rescue one or two.
Well, there is GPIO 0 which is connected to the button, so you can use that as a Hubduino button. There's 14 which is exposed as a pin-hole. And there's 13 which is the on-board LED which could be removed and used as well. And of course 12 which is the Relay. But the primary reason I used this was that I need a which and a contact sensor in the same spot, to do a closet light, which you can do with Tasmota directly also but I wanted to be able to use the contact sensor for more than this light. So, Hubuino made a lot more sense.
Look like all news but I just realize I have more that 20 w5200 ethernet shield back went RadioShack went out of business and im buying more w5500 for no reason.
I try unsuccessfully a modification on SmartThingsEthernetW5500.h
//#include <Ethernet2.h> comment this out #include <EthernetV2_0.h> adding this and nothing I know im missing something the example on the EthernetV2_0 work out but not the ST_Anything_Multiples_EthernetW5500 any help will be appreciated.
thanks
Sorry, just to clarify my previous question... I've already successfully flashed a couple of Sonoff Minis with Tasmota (the customized version for Hubitat), so I'm familiar with getting a Sonoff to at least that stage.
Is uploading a sketch pretty much just like it is for an Arduino or ESP board? Wiring up the serial pins, connecting to a PC (with USB adapter), and then uploading from the Arduino IDE? Do you even need to get Tasmota on it, first?
