I’m working on a custom device type that pulls the wind speed down from Weather-underground with the getWeatherFeature() method. It then sends the wind speed value to a ZigBee device over the level cluster. The app is done and working here is the code:
I would like to reach out to the developer community for some best practice guidance. All input is welcome as I plan on using this app as a sample in an article I’m working on.
First off this Custom Device type is unique (to me anyway) since it gets data from a web service and then sends that data to a ZigBee device without the use of a Smart App. I do this on the poll cycle by calling the getWeatherFeature() method, parsing the wind data out and then sending it with a ZigBee level cluster command. As long as my poll method gets called everything seems to be running just fine. Is this best practice? Is the poll schedule something I can rely on or should I do this with a Smart App? I noticed in the weather underground sample custom device type it has; installed(), uninstalled(), and updated() methods. I thought those methods were only called when placed in a Smart App? To test, I put them in my custom device type and sure enough they get called?? Is this an undocumented feature of a custom device type? Do I need them??
I like the idea of self-containing the device, especially for ease of deployment. I’m really hoping for a future enhancement that lets us “package” devicetypes and parent/child smartapps for easier deployment. Creating SmartApps with child devices (especially multiple child device options is very cumbersome).
I think the installed(), uninstalled() and updated() methods are intended to be used when a device has preferences. I know we used updated() in the community GE Link code for the dimming preferences/parameters. Installed() and uninstalled() probably just don’t have meaningful uses in devices since there is no option to populate preferences on initial install and they don’t/can’t subscribe, so there isn’t much to uninstall().
(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)
This particular instance is fuzzy, because the “Weather Underground” is an unusual “Device”.
But, in general, it is definitely discouraged practice for Devices to interact directly without the use of a SmartApp… Tons of good reasons for this rule.
@tgauchat, @Sticks18 ,
Thanks for the input! Since I posted this earlier this morning I have gone back and created two device types and one SmartApp to do what I was trying to do with one Custom Device type. It looks a lot cleaner and I agree with your guidance!
So here is what I’m really doing. I created a virtual device and assigned this custom device type to get the weather information from the Weather Underground:
I then created this super simple not complete custom device type for my ZigBee device:
Finlay I created this Smart App that triggers on the wind data from my weather underground device type and sends it to the “setLevel()” method in my ZigBee device’s custom device type. The ZigBee device then sends a PWM signal to an attached analog meter moving the needle to represent the wind speed.
My goal is to add 3 more panel meters to my ZigBee device and send values for each of them to display. That is why I need support for multiple destination end points! Next week I’m going to pitch this to my editor for my next article in Nuts and Volts. I know it is very similar to the quirky dashboard but I’m not going to market it as a product. The goal with the article is to walk them through the process of grabbing data from a web services and sending it to their microcontrollers with SmartThings all based on ZigBee standards!
Hi John, I have a subscription to the Nuts and Volts and have read both of your articles with regard to Smartthings. I thought there was to be a second article about “CoopBoss” from last January, but in June you came out with the Analog Panel meter article. Both very good articles…
With your extensive knowledge of the Zigbee radio and its HA protocol, I would invite you to design an Arduino shield based on the same premise as the propeller design ( coopboss), i.e the ability to have both control and data at the mobile hand set.
Samsung in it’s great wisdom have discontinued their version of the Arduino Thing Shield, and I believe you and another Nuts and Volts article could design/build/sell the replacement shield, using the same radio as you used in your other two projects. The Xbee XBP24CZ7UIS-004. This radio is readily available from Digikey… Right up your alley … I’ll take 4 units.
Basic thoughts was a replacement shield, Arduino UNO form factor, but with a socketed Xbee radio, so that individuals who donot want the Arduino form factor could still use the Xbee radio in their Arduino project. This would still require the Smartthings Hub to work. Essentially we are replacing the Propeller CPU with an Arduino based CPU.
The original radio on the Arduino Thing Shield was a CEL chip, Model ZICM357SP2-1. The replacemet shield would use the Xbee XBP24CZ7UIS-004, and being socketable, the Xbee would be able to be programmed using the XCTU program to be able to connect to the Smartthings Hub.
I have no feeling as to the marketability ( I would expect several hundred pieces to be sold ), but I think this fits in with the components and Kits that Nuts and Volts sells.
Your knowledge, and experience would bring this to market very quickly.
I do not know the Samsung financial model for Smartthings, i.e how do they make money on a free cloud service?
Did they discontinue the Arduino Shield due to the desire not to support the DIY community? I would suspect they take a cut of any Smartthings sensor/plug/light that is sold, in order to maintain a free Cloud service.
Is a subscription model in the future? I do not know.
Where to start on this…
First Off I’m interested and would be happy to put something together. But, I don’t want to just recreate an old solution that is no longer available. They are not making them for some reason. If I had to guess it may be support but I would like to understand the real reason!! Maybe someone from SmartThings can chime in.
Second thought) Do we really need a custom circuit board? I spend zero time in the Arduino forums so I don’t know for sure but doesn’t someone have an xBee daughter board (sorry i think the term is shield) for the Arduino? If we can find a shield it may be a matter of creating a new custom device type handler. Let me do some quick searches be right back… Bingo! Can you guys make something like this work if it is able to communicate with SmartThings?
Totally spit-balling here. All input welcome!! From my understanding the old SmartThings Arduino shield did not use standard ZigBee clusters to communicate. It basically allowed people to swap data in strings back and forth between the Arduino and the SmartThings cloud. When I first looked at the SmartThings shield years ago that proprietary highly inefficient way of swapping data was a no go for me. That is when I started down the route of writing a ZigBee cluster driver for the Propeller that led to the development of the CoopBoss and my Nuts and Volts articles. Talking at the ZigBee cluster level requires you to run the xBee in API mode. I think that level of communications kills most Arduino projects. Most makers don’t want to get that deep into the weeds and you know what. I get that!! I think there has been some awesome things built with the old Arduino SmartThings shield! So what I think the Arduino group needs is not a custom board but a way to communicate with a SmartThings device type handler and an xBee in transparent mode (sending strings back and forth). This would make it look very similar to the existing solution. In fact from the Arduino’s point of view it wouldn’t know the difference once everything was setup correctly.
If I’m on tack with my above assumptions, we may be able to come up with a solution that is all software based!! Basically it would give you access to the board pictured here with an xBee ZB S2C chip installed in it (running in transparent mode).
Thoughts?? Am I on track?? Do I have anyone on the edge of their seat, leaning in. Tell me now! Tell me now!