What if you attached a small (but powerful) magnet directly to the moving vane. Then, position an inexpensive magnetic door/window contact sensor nearby. As long as the value is toggling, you know the unit is running. If it gets stuck in one state or another for a period of time, you know it is off.
Personally, I’d probably use a clamp on CT - Current Transformer (like the Aeon HEM one) to monitor current draw. That is how I monitor my washer and dryer. You could even just buy a CT and wire it (find a good wiring diagram!) into an Analog input on a NodeMCU ESP8266 board (or similar) and simply monitor the voltage on the analog pin to determine if the device is on or off.
You could also place a temperature probe in the AC unit’s outlet air stream to determine if it is running or not. Maybe a second temperature probe not in the air-stream so you could compare the two values. If the difference is great enough, the unit is running.
I saw a reed switch online that was mounted on a Pinewood Derby car. The magnet was maybe 2 mm in diameter and maybe 2mm tall? Maybe 3. It appeared to be glued on to the inside wheel hub. Tiny. Not a lot of room on those wheels. Still had room on the car itself for a Mini, the other half of the switch, an accelerometer and some LEDs.
thanks I googled CT - seems like they are pretty reasonably priced. I don’t care about accuracy just need on/off so even cheap ones would work just fine.
Hi Dan,
Here is my issue - the sensor reports a wet value as 460, and the air-dry value as 860.
PS_Water library says "set a value, above which the sensor reports “wet” instead of “dry”
So the sensor wet value is twice smaller than a dry value.
Any suggestions?
Sorry, but I am not a programmer by any means! Played with Fortran 35 years ago.
Anyway, did you mean change “Everything::sendSmartString(getName() + (m_nSensorValue**<**m_nSensorLimit?F(” dry"):F(" wet")));"
to
Everything::sendSmartString(getName() + (m_nSensorValue>m_nSensorLimit?F(" dry"):F(" wet")));
I’ve already posted this in GitHub… not sure which communication channel you prefer. Please feel free to remove one of them
I’m using ESP8266 with more than one analog sensor. So I use multiplexing (something like this). This means that in order to poll value from A0, I have to set another pin to HIGH, then do analog read.
I’m wondering what should I do in this case with the ST_Anything library. Should I create a new device type? For example, PS_Custom_Water, with the edited getData code:
void PS_Custom_Water::getData()
{
digitalWrite(WATER_PIN, HIGH);
int m_nSensorValue = analogRead(m_nAnalogInputPin);
...
How would the link and automatic population of sensors on the SmartThings side be affected if I created a new sensor type. I’m not sure if there’s a better way… and I don’t think I really understand this:
//******************************************************************************************
//Declare each Device that is attached to the Arduino
// Notes: - For each device, there is typically a corresponding "tile" defined in your
// SmartThings Device Hanlder Groovy code, except when using new COMPOSITE Device Handler
// - For details on each device's constructor arguments below, please refer to the
// corresponding header (.h) and program (.cpp) files.
// - The name assigned to each device (1st argument below) must match the Groovy
// Device Handler names. (Note: "temphumid" below is the exception to this rule
// as the DHT sensors produce both "temperature" and "humidity". Data from that
// particular sensor is sent to the ST Hub in two separate updates, one for
// "temperature" and one for "humidity")
// - The new Composite Device Handler is comprised of a Parent DH and various Child
// DH's. The names used below MUST not be changed for the Automatic Creation of
// child devices to work properly. Simply increment the number by +1 for each duplicate
// device (e.g. contact1, contact2, contact3, etc...) You can rename the Child Devices
// to match your specific use case in the ST Phone Application.
//******************************************************************************************
On another note, would it be possible to specify what prefix we’d like to use for the individual sensors (“X” instead of “ST”, for example).
Personally, I would probably simply use an ESP32 as it has multiple analog input pins.
Yes, this seems like a very viable solution. Since you need to set additional pins, you will also need to pass those pin(s) into your custom object’s constructor and store them as private members of the class to be used later in your getData() function. (Or, you could just hard code the pin(s) in your custom class, assuming you are only going to 1 of each custom device type defined in your sketch.)
As long as you follow the naming convention outlined in the ReadMe, the Child Devices will be auto-created correctly. The name I am referring to is the first argument passed in to every constructor when defining the devices in your sketch’s setup() routine.
For example… in the below two lines, you’ll see these devices are given the name “water1” and “water2”. The first part of the name, “water” is used to determine what type of child device should be auto created on ST. The second part of the name, “1” or “2”, is used by the parent DTH to know which instance of the child device device needs to be updated. As long as you follow this naming standard, your child device will be created and updated correctly. So, you could created a completely unique custom device class that reads data from serial pins to determine wet/dry status - and the ST groovy side need never know nor care, as long as your class sends the same stings to the ST cloud that it knows how to handle already.
When you manually create the Parent Device in the ST IDE, you will give it a name/label. When you do this, you are setting the prefix for all of the children. Each child device can then be individually renamed from within its settings page in the ST Mobile Phone App to anything you want. This will then be the name that you’ll see in every other SmartApp.
Hope this helps to answer your questions. Good luck and have fun with your project. And remember, the ESP32 you may the simplest solution as it already has multiple analog pins.
Hi Dan,
I have a question for you…and it has to do with the callback function. I want to react locally to a contact sensor so that I don’t have to rely on ST cloud. I’m adding an automatic light to a closet. Now, I know how to do this completely within the Arduino without any connection to ST but I figured why not also allow control of the relay through ST if I want to leave the door open and turn off the light. So, I figured I could do this with the call back but I’m a little lost on where to start. Do you have an example I could reference? Thanks so much for all your amazing work. I find myself looking at everything going "you know, I could automate that too!
The intermittent false indication I was getting was from using an external pull up resistor (10K ohm). I never noticed the default use of the built in pull up. Even when I changed the argument to false I still was getting the false indication, however adding the optional numReqCounts argument to the constructor with a value of 100 eliminated all the false alarms. I have bench tested a setup with the internal pull up and no counts argument and it works. Guess I should have read the associated comments. I’ve taken my original apart and I will rebuild with more functionality (smoke and motion).
@vseven
Holy smokes, that was weird. Okay, I think I figured it out. Thanks for the help! I switched the RGB Switch tile attribute, and that helped get more stuff in the logs. Watching the serial monitor, it looked like no matter what I did, the rgbSwitch1 on command wasn’t making it to the device. Here’s the on function from the child device handler:
def on() {
sendEvent(name: "switch", value: "on")
def lastColor = device.latestValue("color")
//log.debug("On pressed. Sending last known color value of $lastColor or if null command to white.")
parent.childOn(device.deviceNetworkId)
if ( lastColor == Null ) { // For initial run
white()
} else {
//log.debug "on event lastColor: $lastColor"
adjustColor(lastColor)
}
}
And here’s a version that worked for me:
def on() {
sendEvent(name: "switch", value: "on")
def lastColor = device.latestValue("color")
log.debug("On pressed. Sending last known color value of $lastColor or if null command to white.")
// parent.childOn(device.deviceNetworkId)
if ( lastColor == Null ) { // For initial run
white()
} else {
//log.debug "on event lastColor: $lastColor"
adjustColor(lastColor)
}
sendEthernet("rgbSwitch1 on")
}
Silly me, I originally put the sendEthernet call right next to the parent.childOn call. However, if sendEthernet is not the VERY LAST THING in the on() function call, it doesn’t work. Even adding a log.debug after the last sendEthernet breaks things. I have no idea what’s going on, but it seems like things are working now.
Phew!
Edit: Looks like it’s not perfect. When the light is off and I set the level with the multi-attribute tile, it doesn’t work. The tile turns of, but the command never gets sent. Looking at the serial monitor again, it shows the adjustcolor command going to the device, but not the on command. Is there some restriction that says only one sendEthernet command can run per tile stat action or something? That doesn’t make any sense, but that’s what it seems like is happeneing.
The easiest way to start using the sketch’s callback() Routine is to simply uncomment the two Serial.print commands at the beginning of it. Then, fire up the Arduino IDE Serial Monitor window to watch exactly what is sent to ST. You can then add some logic to detect whatever events are important to you, and then take any actions desired.
I’ll look for an example and post here if I find a good one. If you can describe exactly what you’re trying to accomplish, I may be able to simply write a personalized example.
I recommend that you use at least 500 required counts to help prevent false events. You won’t notice the delay at all, as it is just 500 times through the loop() routine.
Here is an example that should help get you started…
One thing to be aware of… every 5 minutes ST_Anythings sends updates to ST even if nothing has changed. These updates will also result in the callback() function being called. You may need to add additional logic (i.e. local static variables) to your sketch to be able to detect a change in state of an input.
When you do a set level if the level is zero it sends the off command and if it’s anything above zero it sends the on command. I’m not sure if there is a limitation to how many times the send ethernet can run (sounds like there might be based on your testing) but if you’re already sending the level using that maybe the on-and-off aren’t being commanded afterword.
