Thanks, Dan! I may ultimately take the Pico plunge as you suggest, but I'm willing to play around for a while first to see what I'm able to come up with. To leave unused GPIO on a NodeMCU that's already exactly where I need it is a little more than I can walk away from this early 
If you have two GPIO pins free, then you could simply use two momentary pushbuttons to create a 2-button Button Controller device that supports pushed, held and released events.
This would allow you to every easily control a light, with
-
Button 1
- Pushed = On
- Held = StartDimming Up
- Released = Stop Dimming
-
Button 2
- Pushed = Off
- Held = StartDimming Down
- Released = Stop Dimming
I have a few 2-button Picos that I use to control nightstand lamps with smart bulbs in them. I have a wall-mounted pico, that integrates seamelessly alongside my other Caseta switches/dimmers. I also have a pico remote on each nightstand, to make it easy to control all of the lights in the bedroom, and even be able to turn off the bathroom lights.
Yeah, that's a great alternative too... will experiment/mull over! Thanks!
I would like to set up two pulse counters on an esp32. Currently I am able to determine in the sketch how often a pulse counter reports to the hub. Is there a way to set the time differential between when each pulse counter reports to the hub.
For example if I want both pulse counters to report to the hub once every two minutes and I also want one of the pulse counters to report 5 seconds after the first one reports, is this possible?
You can use the polling offset parameter, as described in the comment section at the top of the PS_PulseCounter.cpp file. Set one device’s offset to 0 and the other to 5.
Hi,
Quick question, can I use DHCP for my sensor, if I use my dhcp server to give the sensor a "static" ip?
Gives some flexibility to no need to reflash the sensor if I need to change the ip adress.
Yes you can use DHCP. In each of the example sketches, you will find a static IP declaration for the 'SmartThings..." communication object, as well as a commented out DHCP line. Simply comment out the static IP line and uncomment the DHCP line. Rebuild the sketch and upload it to the microcontroller.
1 Like
DHCP reservations totally work. the key thing is to have one IP address for the device that the hub can point to and connect
So I've had some success with my encoder-based dimmer! I should maybe have clarified at the outset that my intent was not really to replicate a traditional in-wall dimmer, but functionality where if I turn a lot clockwise, the associated bulb gets a lot brighter (regardless of where it started) and if I turn a little ccw, it gets a little dimmer... so for this reason I'm not concerned with the absolute location of the dimmer at any given time.
Here's a recap, starting with the hub and moving backward, which I think will be slightly more intuitive(?) :
-
Rule Machine has the ability to adjust a dimmer by an amount (vs setting to a level) which is a great start for what I wanted. It doesn't seem to support a value taken from an attribute directly, but you can use a variable. This became rule 2 of 2.
-
Rule Machine can set a variable to the value of an attribute, so this became rule 1 of 2: when the attribute holding the "amount of change" gets updated, copy that value into the variable referenced in Rule 2.
-
Then, to stuff the encoder delta measurement into an attribute with minimal effort... (There may be some obvious option here I neglected!?) I noticed in the capability list that "signal strength" has two number attributes, but only RSSI is used in the DH, leaving LQI as a tempting random-place-to-store-stuff. I lightly modified the parent ethernet handler to be able to parse for LQI updates as well as RSSI updates... so the LQI attribute of the NodeMCU became the attribute monitored by rule 1 and ref'd via variable in rule 2. (Obviously very off-spec, so if anyone wants to use LQI for something down the line, this is an issue...)
-
Modified the Button interrupt sensor to look for encoder changes and, at still-being-tuned intervals, fire off the amount of change to the hub via an LQI attribute update. Overall latency is not bad and seems largely driven by the sketch parameters (how long to wait before deciding motion on the encoder should be sent as an update) vs any RM processing. I'm delighted.
1 Like
can I use DHCP for my sensor, if I use my dhcp server to give the sensor a "static" ip?
This is called a "Static Lease" (at least in my router) and is generally the "easy" way to configure any device with a static IP on the LAN. As you noted, it allows you to flash firmware, reinstall OSs, etc. without having to change the LAN configuration of the device. It's a good idea to keep a running list of your devices, MAC addresses, and static IPs someplace, just in case you ever lose the router settings.
Any advice what does it mean when servo is adjusting itself suddenly. One of my blinds works normally but sometimes I can hear tiny servo movement and then it might turn blinds almost closed and back to default. Is that a sign of power problem or something else?
Most users typically allow the servo to lose power after each move, to prevent the servo motor from trying to maintain an exact position. This is an optional feature you can set when the EX_Servo device is declared in your sketch's setup() routine.
You can see all of the options in the comment section at the top of each device's .h or .cpp file.
Pay attention to the 'detachAfterMove' and 'servoDetachTime' parameters.
//******************************************************************************************
// 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)
Ok I see. What causes then certain servo to do that occationally? I mean from 10 blinds only one is doing this and it happens once a day. It would make sense that every blind would work same way as they are identical all the way.
On more question. Earlier I asked why do I have two child servos under parent device and you answered that sketch supports two servos. Does that mean that connecting another servo to one of the pins in board would allow me to control two servos with one board?
I really have no idea.
Yes, you can control multiple servos from a single microcontroller... You just need to be somewhat cautious of which GPIO pins you choose to use, as some pins are troublesome on a restart of the board.
If is fairly straightforward to see hoe each servo is declared in the ST_Anything_Servos_ESP8266WiFi.ino sketch.
Here are the code snippets that declare the two servo devices in the sketch.
//Executors
static st::EX_Servo executor1(F("servo1"), PIN_SERVO_1, 90); //last argument is the starting angle for the servo (0-180)
static st::EX_Servo executor2(F("servo2"), PIN_SERVO_2, 90); //last argument is the starting angle for the servo (0-180)
//*****************************************************************************
//Add each executor to the "Everything" Class
//*****************************************************************************
st::Everything::addExecutor(&executor1);
st::Everything::addExecutor(&executor2);
1 Like
Thanks again. I still need to check wiring for that particular board because something weird is going on. It feels like it could be because of bad wifi connection or bad wiring. Something similar happens when usb connector is taken off and put back on.
Hi, another quick question, using the ST_Anything_Multiples_ESP8266WiFi example,
I got a switch child device which turn the onboard LED on&off.
I also got a child device called alarm1, havent been able to figure what it does?
Edit: I realize its for controlling a strobe or siren, and now I also found it in the sketch.
Sorry, sloppy reading again...
1 Like
I have a small wood shop setup in my garage that consists of a table saw, power miter saw and a router table. It’s a pretty basic affair that currently uses a large shop vac for dust collection which will eventually be replaced by a real dust collector. I’m thinking about using ESP8266 NodeMCUs for power tool current detection to turn on the dust collector. More often than not I forget to turn on the vac before making a cut and end up with more airborne dust and mess than necessary.
I’m thinking of making three short extension cords using SJ cable--each with a plug on one end and a 4 inch square outlet box on the other. Half of the box would contain a duplex outlet for the power tool and NodeMCU power supply; the other the NodeMCU with current detection to determine when the power tool is powered on. I’ll need a divider in the box to physically isolate the ESP8266 and it’s low voltage power from the line voltage but that’s another matter.
The end goal is to have the NodeMCU detect the current from the power tool and tell HE to power on a Z-Wave wall outlet that turns on the dust collector and leaves it running for 30 seconds after the power tool is turned off to ensure maximum dust extraction.
So after that long winded intro; any thoughts on how to the best way to handle current detection? I don’t really need much precision here—these tools draw a fair amount of current and a current transformer seems like overkill. Any thoughts?
I have the same problem sometimes...
This would do it but seems costly...
0.5 A Current Switch
Might be cheaper options somewhere.
Button controller in your pocket might be a good compromise.
EDIT: Better yet... one of these...
Zooz ZEN15 power switch
Yeah, kinda pricy. I'm thinking of using a 20A Range ACS712 Current Sensor Module Detector but I'm not sure how much it's going to like an inductive load with a fairly high in-rush current when the tool starts up.
I suspect I'll have the same brain fart issue with the button controller I'm currently having with manually turning on the shop vac--I'm part way through the cut when I think oh s#@%--I forgot to turn on the shop vac again.
What about the ZEN15... made that edit just as you were typing your last message, it seems.
