Announcing the "ST_Anything" Arduino/ThingShield Project

I found a library that at least compiles here:

Todd,

Sorry about the missing DHT library. I should have included a link to it in my ReadMe. I’ll update it shortly.

Dan

Okay. I have it installed.

I don’t have all of these sensors, so I’m trying to play with the open/close to verify if it is working. Looking at the sketch, it says contact is pin 8. When I jumper pin 8 to ground, nothing happens.

I am using the Arduino Mega. Do I have to jumper any pins for it to work?

Thanks.

Sorry, I’m posting a lot.

One of the things I really want to do is have multiple contact sensors that could each trigger different “stuff” in Smartthings. I was able to get one contact sensor to trigger a light on/off. But, I cannot figure out how to make the thing shield look like more than one contact sensor in the Smart Things app.

You guys have done more with this than anyone. Have you thought about that and if it can be solved?

Thanks, again.

Dan,

Congrats, this is awesome. I was playing with it tonight and had most of my generic Arduino hardware working with it in short order. I’m looking forward to building a few of these projects and integrating them into my home.

David

1 Like

Todd,

I have updated the ReadMe at the GitHub to include the DHT library instructions, as well as the first post in this topic. Thank you for the feedback and for giving ST_Anything a test run!

As for the Contact Sensor question, I think you already figured out how to get one to work, but just in case…

Per the sketch…

#define PIN_SWITCH 8"
#define PIN_ALARM 9 “
#define PIN_CONTACT 11"

Pin 8 is a digital output for a relay, which is essential what a SmartThings Switch device is, like a SmartPower Outlet or a GE Z-Wave wall switch. Pin 9 is another digital output for another relay to turn on a siren. Of course, feel free to tweak the pins however you want…that’s the purpose of the library! Just don’t inadvertently assign the same pin to two different devices. I lost about 30 minutes trying to figure out that silly mistake during my copy and pasting of new sensors… :slight_smile:

Pin 11 in the sketch is a digital input, which is set to use “INPUT_PULLUP” per the constructor (see IS_Contact.h and IS_Contact.cpp for details of the C++ constructor arguments.) By connecting Pin 11 to ground, you should see the Contact Sensor change from Closed to Open in the Arduino IDE Serial Monitor window, as well as in the SmartThings App on your phone.

On the MEGA, make sure you follow the detailed directions in the full ReadMe from the ST_Anything GitHub. By default, I have configured the MEGA to use Hardware Serial communications on pins 14 and 15. Pin 14 needs to be jumpered to pin 2 while pin 15 needs to be jumpered to pin 3. Using the hardware UART on the MEGA really improves the performance and reliability based on our testing.

As for your question about multiple Contact Sensors, or actually multiples of any device type… Yes, this is possible, but requires some custom Attributes in the Groovy Device Type code, along with a SmartApp to link these custom attributes to a set of Virtual Contact Sensor Devices. I have successfully done this as part of my original GarageDoor Arduino application which can be found below.

I am planning on converting my GarageDoor controller over to the ST_Anything library shortly and will happily share that example with the community as well. It implements 4 x Contact Sensors (1 digital input each), 2 x GarageDoors (1 digital input & 1 digital ouput each), and 1 x Temperature sensor. All of these devices show up in the SmartThings App’s “Things” section as individual tiles, which can then be used within any existing SmartApps as if they were independent devices. I just need to find some time to work on it…

Continuing the discussion from Arduino SmartShield Garage Controller:

1 Like

David (@DavidCreed),

Thanks for the feedback. Glad to hear it is working for you as well. If you have any suggestions, I’d love to hear them. There is a surprising amount of code behind the scenes, but it is amazing how simple the Arduino sketch is now.

Dan

All,

As promised, I have rewritten my old Garage Door Arduino Application (now called ST_Anything_Doors) using my new ST_Anythings and SmartThings libraries. ST_Anything_Doors utilizes a DHT22 temperature/humidity sensor instead of the Dallas Semiconductor DS18B20 sensor. I have also added a Motion sensor to keep an eye on the interior of the garage.

ST_Anythings_Doors includes a new standard SmartThings Device Capability in the form of a “Door Control” device. I have written a new C++ class called IS_DoorControl for the Arduino to implement the Door Control capability which is typically used for a garage door. This class includes a digital input for a magnetic contact sensor as well as a self-timed relay output for “pressing the button” to open/close the garage door. Please read the comments in IS_DoorControl.h for specifics on how to use the constructor of this new class. The new ST_Anything_Doors.ino sketch should provide a nice example of how to use the new Door Control capability on an Arduino.

Also included in the ST_Anything_Doors package are three groovy Device Types (ST_Anything_Doors (for the Arduino ThingShield), VirtualContactSensor (for 4 house doors), and VirtualDoorControl (for the 2 garage doors.) You will also find one SmartApp called ST_Anything_Doors_Multiplexer which takes care of mapping the 6 virtual devices into the 1 Arduino Device. This allows standard SmartApps to see each of the 4 contact sensor devices and 2 DoorControl devices as if they were 6 standalone devices.

These changes are all available at https://github.com/DanielOgorchock/ST_Anything. Please be sure to download all of release v1.1 and replace any copies of the v1.0 ST_Anything library as changes were needed to some of the standard files in order to support the new DoorControl device properly.

As always, please let me know if anyone has any questions or suggestions for improvements.

Dan

@Todd_Whitehead, @johnwest80, @DavidCreed

2 Likes

Dan,

In the multiplexer smart app, is there a way to set a sensor in preferences as optional? I’d like to make a more generic version that I can add and remove contact sensors in different times of the year, but the preference pane will not let me move on if all of the sensors are not assigned to something.

Thanks.

@ogiewon

Todd,

I am sure there is probably a much cleaner and more generic way to write the Multiplexer SmartApp. Unfortunately, I am much more of an Arduino C++ programmer than I am a Groovy guy. One simple method would be to run multiple instances of the Multiplexer app, each one mapping a single virtual device to the Arduino (but I am not sure how you’d handle the different custom attributes that the app has to subscribe to.) Or, you could just tweak the SmartApp’s groovy code based on your specific needs as they change.

To make it truly generic, you have to allow the user to select the virtual device tile, the Arduino, and the events it would subscribe to (in both directions) and the custom actions to call. I am not sure how to make that happen. Perhaps someone with a lot more groovy experience will chime in?

Thanks for taking a look. Hope it helps with your project!

Dan

@Todd_Whitehead

Dan,

I am only using this for contact sensors, so it doesn’t have to be THAT generic.

The work-around I am using right now is I just select the Arduino itself for the contact sensors that are not used. It has the potential to cause some error messages in the web interface log, but I almost never look at that.

I’ll go see if I can RTTFM and find the solution.

Thanks.
-Todd

@ogiewon

Okay, that wasn’t hard to figure out. You use required: false

preferences {
section("Connect these virtual contact sensor to the Arduino's sensors") {
		input "pin4", title: "Virtual Contact for Pin 4", "capability.contactSensor", required: false
        input "pin5", title: "Virtual Contact for Pin 5", "capability.contactSensor", required: false
        input "pin7", title: "Virtual Contact for Pin 7", "capability.contactSensor", required: false
        input "pin8", title: "Virtual Contact for Pin 8", "capability.contactSensor", required: false
        input "pin9", title: "Virtual Contact for Pin 9", "capability.contactSensor", required: false
        input "pin10", title: "Virtual Contact for Pin 10", "capability.contactSensor", required: false
        input "pin11", title: "Virtual Contact for Pin 11", "capability.contactSensor", required: false
        input "pin12", title: "Virtual Contact for Pin 12", "capability.contactSensor", required: false

	}
 
    section("Which Arduino board to control?") {
		input "arduino", "capability.contactSensor"
        //"device.ogiewonarduino" 
    }    
}

-Todd

2 Likes

Hi Dan (@ogiewon),

I am expanding my custom setup using your ST_Anything library. I started with the door sensors in my house and now I am adding moisture and temp humidity sensors. I have a problem and a question.

Problem: When I run the ST_Anything code, I get an error on the DHT call. I am using a DHT11 instead of a DHT22 (Does that matter?), but even if I point to a pin where the sensor isn’t present, I still get this error:
PS_TemperatureHumidity: DHT Unknown Error

Question: Can I have more than one Temp Humidity sensor? For the other “things”, the name in the declaration is the name we use in the device driver. But for temp humid, it seems to have hard-coded names. Is there a way to force some sort of suffix to the name so I can define more than one?

Thank you
Todd
@Todd_Whitehead

Todd (@Todd_Whitehead),

If you’re using a DHT11, simply change the call in the sketch to refer to a DHT11 instead of the DHT22. That should sort out that issue.

As for multiple Temp/Humid sensors, I can modify the PS_TemperatureHumidity class to allow you to pass in two optional string arguments which will be used when transferring data to the ST Cloud. This will allow you to have multiple temperature and humidity sensors, assuming you name the tiles in the Device Type code that same as the new names you pass into the new optional arguments.

The reason I used “temphumid” as the Arduino device name was to allow the polling interval to be sent from the Cloud to the Arduino when you press Configure (be sure to set the polling rates in the Preferences first). This is really optional, and does not currently persist after an Arduino reboot. I still want to use the Arduino EEPROM to persist those values.

I’ll make the code change shortly and update GitHub. I’ll let you know when it’s ready. Shouldn’t take long.

Todd (@Todd_Whitehead),

I have made the changes to PS_TemperatureHumidity.h and PS_TemperatureHumidity.cpp to allow you to optionally pick the names you want sent to the ST Cloud. Simply modify your sketch as follows:

Original:
st::PS_TemperatureHumidity sensor2(“temphumid”, 120, 10, PIN_TEMPERATUREHUMIDITY, st::PS_TemperatureHumidity::DHT22);

Additional DHT sensor:
st::PS_TemperatureHumidity sensor2(“temphumid2”, 120, 10, PIN_TEMPERATUREHUMIDITY, st::PS_TemperatureHumidity::DHT11, “temperature2”, “humidity2”);

The last two string arguments are new and are optional if you only have one Temp/Humidity sensor. The first argument must be unique as well…as requires some minor tweaks to the Device Type Groovy code if you want the Polling Rate for the additional Temp/Humid sensor to show up in “Preferences” and be sent to the Arduino in the “Configure()” routine.

If you need to Alarm off of the secondary Temp/Humid sensor, you’ll have to add support in a Multiplexer SmartApp and add a Virtual Temp/Humidity Device (you should be able to simply use a Virtual Contact Sensor Device Type as a prototype, and use the Tile definitions from the ST_Anything Device Type groovy code. Of course, you have to modify the capabilities section as well to replace “Contact Sensor” with “Temperature Sensor” and add “Humidity Sensor”…

New code is available on GitHub at https://github.com/DanielOgorchock/ST_Anything

Sounds like you’re having fun! Let me know if you have any questions.

Dan

1 Like

Dan (@ogiewon),
I’m having a blast! Thank you.

I think I added the extra sensors correctly, but the display output only shows the first one.

I have these lines for the temp humid sensors:

#define PIN_TEMPERATUREHUMIDITY1 16
#define PIN_TEMPERATUREHUMIDITY2 17
#define PIN_TEMPERATUREHUMIDITY3 18

st::PS_TemperatureHumidity sensor16("Pin16", 120, 10, PIN_TEMPERATUREHUMIDITY1, st::PS_TemperatureHumidity::DHT11, "Pin16t", "Pin16h");
st::PS_TemperatureHumidity sensor17("Pin17", 120, 10, PIN_TEMPERATUREHUMIDITY2, st::PS_TemperatureHumidity::DHT11, "Pin17t", "Pin17h");
st::PS_TemperatureHumidity sensor18("Pin18", 120, 10, PIN_TEMPERATUREHUMIDITY3, st::PS_TemperatureHumidity::DHT11, "Pin18t", "Pin18h");
  st::Everything::addSensor(&sensor16); 
  st::Everything::addSensor(&sensor17); 
  st::Everything::addSensor(&sensor18); 

But the serial output only shows the first set:

Everything: Sending: PinA8 dry
Everything: Sending: Pin16t 68
Everything: Sending: Pin16h 39
Everything: initDevices ended
Everything: Free RAM = 6133

The first set is populating in the ST “Thing”, but the other 2 sets are not showing values.

Did I miss something in customizing the labels?

THANKS!
@Todd_Whitehead

Todd (@Todd_Whitehead),

Not sure how many sensors you have now. You may need to increase the MAX number of sensors in Constants.h. The initial debug statements will display an error if you exceed the default maximum.

Dan

That did it!

Thanks!

Wow. Are all DHT11 sensors so crappy? I have the three sensors plugged into the same breadboard and the temperatures they report back are not very close to each other. There is a seven degree spread…

Everything: Sending: Pin16t 66
Everything: Sending: Pin16h 38
Everything: Sending: Pin17t 71
Everything: Sending: Pin17h 38
Everything: Sending: Pin18t 73
Everything: Sending: Pin18h 37

After the refresh, they got closer…

Everything: Sending: Pin17t 64
Everything: Sending: Pin17h 40
Everything: Sending: Pin18t 64
Everything: Sending: Pin18h 38
Everything: Sending: Pin16t 66
Everything: Sending: Pin16h 39

Glad to hear that solved it!