Arduino Shield Suggestions?


(Andrew Sterian) #1

Hey all,

To those of you that have used our Arduino Shield, do you have any suggestions for improving it?

Or do you have suggestions for other shield-type products or support for other platforms like Raspberry Pi or BeagleBone Black?


Announcing the "ST_Anything" Arduino/ThingShield Project
(Brian Steere) #2

Support for pi/black would be great.


(Ben Edwards) #3

(Steve B) #4

I would REALLY like a version that is in the same style/footprint as the Digi XBee. Then I could use my existing RF/XBee style Arduino/Pi shields.


(Geko) #5

Personally, I’d rather see a generic module with a single-row pin header in a smallest form-factor possible. This would allow building it into all kinds of gadgets, not tying it to Arduino Uno form factor. Who uses Uno anyway? Also dual 3V/5V power would be very much appreciated.


(Kmugh) #6

Is there any (documented) way to currently link Pi and ST via LAN/Wifi, and exchange commands between them?
(Sorry for the hijack)


How to (RPi + ST )?
(Dan) #7

@steriana - Andrew, I’d like to see some better documentation in general, especially for writing custom DeviceTypes for use with the Arduino. Even perhaps some updated examples of both Arduino/Groovy code would be very welcome. For example, the On/Off examples found in GitHub about two months ago were all out of date (i.e. not compliant with what appears to be some recent changes in the ST DeviceType Groovy Code requirements.) I spent a considerable amount of time trying to figure out why only certain parts of the examples would work. It turned out that the examples were lacking the “Definition” section of code. I did create a forked version at https://gist.github.com/ogiewon/517237129980469edca3 to hopefully help others. I just checked @urman 's GIST and it appears that he has updated his version as well. Thank you!

The one question I would really love for someone to help with is “how can I transfer multiple pieces of data from the Arduino in a single Zigbee update, and then parse those results for multiple device capabilities(attributes) in the DeviceType Handler?” For example, if I have an Arduino that is essentially a multisensor (Water, Temperature, Humidity, Siren, Contact Sensor, Motion, Light Level, etc…) and I send a single ST Zigbee update with the values for every one of these capabilities/attributes, how would I go about parsing the string in the DeviceType PARSE routine to update multiple attributes/values? I know how to handle a single attribute/value pair due to having plenty of those examples, but not sure how to return multiple RESULT(S) from the Parse function. It seems to take close to 1 second on the Arduino side to transfer data to the ST Cloud via the Thing Shield. Updating many attributes blocks the Arduino from scanning and processor its I/O. Ideally, I would like to reduce the amount of time the Arduino takes to update the ST cloud.

BTW - thanks for asking for the feedback! I am really enjoying the sense of community prevalent in the ST home automation world.


(John Rucker) #8

I would like to see you incorporate a Parallax Propeller processor right onto the board with the Ember ZigBee radio and publish a standard ZigBee HA library to communicate with the hub (No proprietary stuff like you do now). Make it a standalone device no Arduino or BeagleBone required. This would be a dream platform for developers! With the power of the 8 core propeller, 32 I/O pins, and ZigBee C library this thing would rock!! Oh and do it for $15 A guy can dream cant he!

Seriously this is very doable! Here is a post where an XBee (an XBee is simply a freescale processor and an Ember radio) is driven by a propeller and a standard ZigBee HA Library written in SPIN. There is even a custom SmartThings device type that talks to the propeller on the Parallax site!

I would love to get rid of the XBee and have the Propeller and Ember radio all in one small affordable package!!

Parallax is in Roclkin CA and they just released the Propeller to Open Source. I bet they would be happy to help you put this together!!


(Geko) #9

Everyone have their favorite ice cream flavor. Let a thousand flowers blossom rather than imposing one platform on everyone.


(John Rucker) #10

I agree and there are very good options available today to do just that. You can drive an Dig XBee with any processor that has a UART. They even have models that have a SPI interface. So right now today you can hook up a Arduino, Raspberry Pi or BeagleBone to an XBee and your off and running no need for any special hardware.


(Ben Edwards) #11

You can always start a new thread from another using this link in the right margin (on hover)


(Kmugh) #12

Just tried this, thanks for letting me know.


(David Creed) #13

Hi @steriana,

What I would love to see would be some very generic SmartDevice code and the matching Arduino sketches that would allow non-coders to utilize by removing the non-relevant code sections.

One cavaet, this could possibly already exist but I just haven’t found it yet! (If anyone can point me in the right direction, I would appreciate it)

Obviously this would limit the functionality, but would allow people to quickly learn and get their Arduino devices connected and working with SmartThings

For someone like me, once I can get my devices connected, I can use existing SmartApps to control actions.


(Florian Z) #14

FWIW, my personal requirements, which I have been trying to address with this project include:

  • Standalone (Arduino compatible, but doesn’t require separate Arduino board)

  • Small form factor

  • Low power consumption (Sensor running on batteries)

  • Low cost ($35 should include the MCU to make the shield/board permanently deployable)


(Joel T) #15

Agree - if you’re going to focus on Arduino, just put the ATmel right on the board. For an app with minimal I/O, I’m considering soldering a Pro Mini directly to the prototyping area on the existing ThingShield, but just doing them together on a single board would be cleaner. You could still consider Uno-style headers to support additional shields.

Also, is there a way to publish a vendor/device type information so that devices are discovered as something other than a ThingShield? I’m not sure how much I care right now, but it would be neat to start learning about end-to-end product development steps…


(Wallace McClure) #16

I’ve been also looking at a Spark Core.

I’m moving towards a couple of home information projects: One would be a weather station with internal and external environmental information, and the other would be on pool status (water level, temperature, chemistry, etc.) One of the reason I started with the Smartthings was the simple integration and open architecture. But I also want to integrate into external devices & sensors (such as the weather or water sensors).

Still sketching out what I want this to be. I have a Raspberry Pi on hand, and I’ve been looking at the Spark core as an option as well.


(Florian Z) #17

I have a few of those, and they are fantastic. They work great for SmartThings integration, especially with the free cloud access. Having said that, they are inefficient to run off of batteries for prolonged periods of time, so they aren’t a great choice for battery powered sensors. Spark IO has new hardware coming out soon, so maybe power consumption will be improved, as well.


(Mark B) #18

I would like more examples of different device types and adjusting how they appear on the dashboard. For example, if I am using an interrupt driven device, like a motion sensor mixed with a polled device, like a temperature sensor… how would the device type code look? I have a case where I am tapped into the sensors of my existing alarm system with access to all the motion and doors through a single Arduino (currently it is generating a web page with the status information), but would like to use the shield and device type code to place those on the dash board so I can trigger events off of that.


(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy) #19

I’ve asked for something similar to this a few times, and I think the Philips Hue (in Labs?) may be an indication of a starting point.

In my own words: A single physical-thing should be representable by any number of Thing-tiles, some are short-cuts to each other, some are different views/controls into the physical-thing’s data (e.g., a multi-sensor should allow for at least 4 (FOUR!) distinct tiles: open/close, activity, xyz, and temperature; and an Arduino Thing-Shield could demand “hundreds” of Tiles, as the Arduino could be a bridge to an entire set of physical-things [just like the Philips Hue ZigBee-WiFi Bridge is a link to up to 50 lightbulbs…]).

…CP.


(Jody) #20

Here is an arduino/thing shield device with polling and interrupt type tiles.