Yes I had exactly the same problem you describe across multiple ESPs/servos. Even across types of ESP boards, NodeMCU and D1 minis. In some locations I have 1 mcu controlling 2 servos on different GPIOs and 1 servo would exhibit this behavior and the other wouldn't.
My blinds required 270 degree servos for full range of motion, so the specified angle was different, but the issue still occurred occasionally.
I have been using this setup for several years and it would occur 1-3x/week and only upon opening. Moving from 0 to 90 degrees, never from 90 to 0
It did seem that the problem became worse using slower speeds. 4000ms
Not suggesting that you do what I did as Hubduino is a great project, but I have since switched them all to Tasmota and no longer have the issue. I can DM you the relevant post on Tasmota/servos if you want.
Good to know it may not be something I've done wrong! TBH I had not realised that Tasmota was set up for servos too. I guess I might move over to that - I do already use it for some other things.
The documentation I've found (HOWTO control servo motors · Discussion #10443 · arendst/Tasmota · GitHub) only shows it driving 2 servos, and I have 4 on one esp8266, but I ought to be able to work that out, it just looks like it may take a bit of getting my head round.
I don't suppose anyone out there has got the the bottom of this issue in HubDuino? TBH I would rather stick with that......
That's the example I followed, using a variation of the first wiring diagram (v5.1.2).
I did not use the MP1584/separate servo power.
I wired the servos (1 or 2 per ESP in my case) power and ground to the ESP USB 5V/GND pin and the servo signal line direct to a gpio.
The Tasmota web interface is a little wonky with 2 servos but it does work flawlessly with commands from Node-Red in my case. No odd movements in several months.
Ok, so I've got a button sketch running on an esp8266 and have established communication back and forth. What I'm trying to figure out now is how I can establish trigger behavior on the esp8266 based on data sent from the sendData function on Hubitat. I can see the data in the serial monitor, but so far I haven't been able to get anything to react from the message.
Typically, a Button sketch is designed to transmit data from the microcontroller to the HE hub. Receiving data from the Hub isn't going to be parsed into anything actionable, as the IS_Button device will simply ignore it.
It appears that it has been a few months since we last discussed any of this. Please update us on your goals for the project so we can assess the options available.
Is that clarifies quite a bit. This is a different project we're all I need to do is set up an ESP 8266 to trigger a solid state relay based on some kind of command from the hub. Maybe you have a recommendation on a different sketch to try? Perhaps for a slightly different application?
Sure. I would recommend starting with the ST_Anything_Multiples_ESP8266WiFi sketch, and simply remove all of the example devices except the EX_Switch device. This will result in a single "Switch" child device being created that can be used just like any other switch device in Hubitat.
Thanks, worked perfectly. This is going to be tremendously useful for integrating various micro controller effects into a DMX show I'm working on. I actually ended up wiring the outputs on the controller to a DY SV5W in independent triggering mode to begin playing audio out of a prop boombox.
As a bit of expansion on this concept, I'm wondering if there's an option for Hubitat to directly control via serial commands. Initial assumption is that I'd have to have my micro controller react based on a pin being set to HIGH or based on sent string data.
I seem to be having an issue communicating with a sound module connected to an ESP8266 via the RX/TX pins. I was wondering if somewhere in the libraries for the ESP8266 if the on board serial pins are being used for another purpose. I know part of this setup is simulating the Thingshield. If that's the case, resorting to softwareserial is probably a solution, though it does cut down on available pins.
So my issue seems to be more that the library I'm using with the connected DY SV5W doesn't work well with ESP8266 or ESP32 when not running off of the default hardware serial port, and SoftwareSerial doesn't seem to have a lot of support for ESP. I can just as easily set up the same sketch on a 32 instead of an 8266. Is there a way to set up the ST Anything sketch to run off of Serial1 or Serial2 on the ESP32 instead?
I believe there is a way to completely disable the ST_Anything debug serial.print functionality. It has been a while since I’ve bug through that code, so it may take a little while for me to post the solution.
I did manage a workaround by stacking a second wemos d1 mini on top and setting up a playback sketch triggered by switches set up by the 8266_Multiples sketch. It's not ideal, but it works. I'm glad these units stack so cleanly.
Okay, so it is coming back to me now... If you look at any of the ST_Anything example Arduino sketches, you should see a section of code that looks like
//*****************************************************************************
// Configure debug print output from each main class
// -Note: Set these to "false" if using Hardware Serial on pins 0 & 1
// to prevent communication conflicts with the ST Shield communications
//*****************************************************************************
st::Everything::debug=true;
st::Executor::debug=true;
st::Device::debug=true;
st::PollingSensor::debug=true;
st::InterruptSensor::debug=true;
Simply change all of the 'true' to 'false' as shown below
//*****************************************************************************
// Configure debug print output from each main class
// -Note: Set these to "false" if using Hardware Serial on pins 0 & 1
// to prevent communication conflicts with the ST Shield communications
//*****************************************************************************
st::Everything::debug=false;
st::Executor::debug=false;
st::Device::debug=false;
st::PollingSensor::debug=false;
st::InterruptSensor::debug=false;
Also, if you're not wanting the baudrate to be 115,200 on the primary hardware Serial port, please change the baudrate found in Constants.h as shown below. Note, there is a call to Serial.begin() in Everything::init(), which is called in the sketch's setup() routine. So, either make sure to match your specific device's baudrate by tweaking Constants.h... OR ...make sure whatever your code is doing to the Serial port happens AFTER Everything::init() is called.
//Serial debug console baud rate
static const unsigned long SERIAL_BAUDRATE=115200; //Uncomment If NOT using pins 0,1 for ST Shield communications (default)
//static const unsigned int SERIAL_BAUDRATE=2400; //Uncomment if using Pins 0,1 for ST Shield Communications
Perhaps my question does not belong in this thread, but you'll be the judge of that.
I just received a pack of WEMOS D1 Mini ESP8266 modules, and want to build a garage door controller.
I loaded the ST_Anything_GarageDoors_ESP8266WiFi.ino sketch, and it compiles just fine. However, when uploading, I keep getting this message: Failed uploading: uploading error: exit status 2
I tried hitting the RESET button when the Connecting... message appears, to no avail.
I would recommend following a generic online guide to learn the basics of using the Arduino IDE and how to properly configure it for your particular board. You may also need to manually activate the buttons in a specific sequence during the process of loading the sketch on the board.
Thanks for the quick response, highly appreciated.
I finally found out that I had used, one after another, 3 USB cables that were wired for power, but not for data. The 4th one worked.
Yet, I will definitely look into the WEMOS Setup document.
And, BTW, thanks a million for ST_Anything... The greatest invention since sliced bread... Saved me tens of hours of guesswork. Do you have plans for a LUA version?
I can appreciate why. Samsung have adopted a pretty lousy behavior in that venture. I will be able to migrate all my hubs to Hubitat as soon as I find a way to use my Globe Suite, Tuya and Smart Life connected devices with Hubitat. Can't wait .
Thanks for the fantastic driver and the ported examples, really helpful.
I'm ported one of your sample ESP32 sketches for an Adafruit Huzzah32 , and have a need to run a W5500 Ethernet shield with the ESP32 board for one application. The only wrinkle here is that most of the Arduino boards used for examples use Arduino pin10 for the chip select (sspin), but the Huzzah uses pin 33 for this function.
Buried down in the Ethernet class you can set the sspin via its init function, if called before begin function
static void init(uint8_t sspin = 10);
and the default matches the most common Arduino board sspin (10).
Do you see a clean way to pass the sppin pin down into the Ethernet class from up top or a place to manually call that init from the ST class at the sketch level before starting the driver?
I can DM you the relevant post on Tasmota/servos if you want.
.
