Solar Tracker device type zigbee development questions

Devices & Integrations Community Created Device Types
#1

Hi Everyone!
I’ve created a digital solar tracking controller that has xbee functionality built into it for serial command/response capability (think telnet), so it would seem that creating a SmartThings device type/handler should be a straight forward process, but I’m quickly getting confused, so maybe someone can clarify the development process for my scenario (I’ve been writing firmware for years in C so this high level Groovy stuff is pretty mind blowing).
Hardware wise my device is basically equivalent to an Arduino with an Zbee shield. My Xbee doesn’t have the special firmware of the SmartThings Arduino Shield so I guess I’m going to have to implement all the handshaking for joining the hub unless there’s some library for that I haven’t caught on to.

The phase 1 goal: There’s all sorts of tracking data and sensor values that could be shared, not to mention configuration values, but that can all wait. For now the goal is to be able to issue a command to start tracking, and stop tracking (park), Additionally the solar tracker has a wind sensor input which triggers a suspension of tracking and puts the array in safe park position. The tracker posts these wind events which need to become triggers like a motion detector event for a SmartApp to send a text or whatever.

First issue: What is my thing like that I can start from?
So solar tracker can be thought of as ON when tracking, and OFF when parked, but there’s this extra high wind mode and a maintenance (cleaning) mode as well. Should i start with a basic switch or is there something better?

Second issue: Zigbee Clusters
So my controller just uses a Xbee module as a wireless serial modem, and doesn’t even access api mode, just a few AT commands. Am I right that the Zigbee cluster library specifications are specifically targeted towards devices utilizing the other zigbee (non-serial) i/o pins for hardware control? And since I’m just using the serial interface most of that doesn’t matter?
With something like the refresh method for example, I need to ask my firmware what the mode is, not the zigbee module’s firmware, so why would I ever want to follow the zigbee device type example with a call like: zigbee.readAttribute(0x0B04, 0x050B)
That won’t send the serial data to my micro unless I’m missing something here.
And if I don’t follow the example, then what’s a good example for my situation?

Thanks for any pointers

2 Likes
#2

The main advantage to starting with an existing SmartThings Capability (see List), is that then there is a good chance existing SmartApps will be compatible with your DT (Device Type). This is not always desirable if it can cause confusion (e.g., Does it make sense to control your tracker from “Smart Lighting” or other on/off centric SmartApps … maybe?). This also makes your “concept” desirable as users can plug and play other hardware with the same “Capability” from a different vendor. But note: there are also a lot of, as yet, undocumented Capabilities, and one might just happen to fit your case more closely.

Ad hoc Attributes and Commands can be added to any DTH (in addition to the claimed Capability or Capabilities), but there is no standard for these at all. If your device is truly unique, then not trying to masquerade as something you’re not is likely a good thing.

1 Like
#3

Mark, to get connected to the SmartThings ZigBee network your xBee is going to need to be one of Digi’s xBee ZB S2C modules preferably the SMT version. To get data up to the SmartThings cloud you will need to write a custom device type in the SmartThings IDE to send data back in forth. From your device you have a couple of options; one, is you can send simple text strings back and forth (that is what the SmartThings shield does) or two, you can communicate over standard ZigBee clusters. If you go the standard ZigBee cluster route there is a better chance your device will work with other non SmartThings hubs. Here is an article I wrote on connecting an xBee to SmartThings in the January Nuts&Volts. You may also want to take a look at this post on mapping your ZigBee network with Digi’s XCTU. It will explain the security settings you will need to configure on your xBee ZB.

To properly implement ZigBee clusters on your device with an xBee ZB radio you will need to talk with it in API mode. That is going to require a fair amount of code and processor power. Not sure what processor your using but I use the Parallax multi core Propeller and I have published my SPIN xBee API driver in this post.

The ZigBee public cluster library is a list of commands and attributes to facilitate the communications of devices in a standard efficient manner. Think of it as an application layer that spells out how your device should send and receive common commands like on / off, level, temperature, color, etc. If your device sends unique data not covered in a standard cluster pick a cluster close and extend it with vendor specific commands and attributes. Take a look at the documentation for the CoopBoss you can see how I extended several standard clusters to expose my unique commands and data. So I would argue with your above statement and say ZigBee clusters are very well suited for your type of data.

Oh by the way check out Solar-Current.com we make a wind protection kit for wattsun solar trackers.

2 Likes
#4

Thanks for the feedback. From the research I’ve done you are The Man, when it comes to this stuff John!

After Terry’s comment I was thinking that my tracker is basically just an appliance, a coffee pot would probably be a fairly close analogy, but now I see that John’s CoopBoss is the best reference project available and not that un-analogous.

First the 350 page HA User Guide, then the 832+page Cluster Library Guide make for a lot of reading material while I try and hunt down places my data belongs! I’ve only about 12,000 lines of code and a little over 60 commands and many more parameters to wade through with my own firmware running on an ATMega2560. Not previously familiar with the Propeller board, I saw a 5Mhz clock speed and figured the 16MHz atmega could do the job, although it’s not capable of async operations like the Propeller. Now I also see it actually runs at 60MHz and is also 32bit vs 8. I’ve taken a glance at the Spin Xbee API driver John created and wondered if an “arduino” port wasn’t possible. I’m shocked no one in the Arduino community has done what John has for the Propeller with the HA API. Does that mean an 8bit 16MHz micro can’t do the job?

Just noticed the header on John’s API and had a good laugh. I wondered who he worked with. Our projects are amazingly different and similar at the same time.

So to use a mountain climbing metaphor, I have some doubts before setting off to scale this mountain of Z HA. John has shown the path, but of course I was hoping to take a slightly different route up the Atmel side. The alternative for me to Z HA, and my original plan, would be to create my own zigbee hub that runs a web server to provide a control interface: a process which seems oddly less technical (because the only protocol I really have to match is http), and then I could just use http methods in my smart app.
So the trade off points seem to boil down to make my own hub, or learn the Zigbee HA way. Unfortunately the heavily constrained option is probably the best.

1 Like
#5

The ZigBee documentation can sure be overwhelming and seems cryptic at first glance, I get that believe me! Keep in mind if you want to build your solution to only work with SmartThings and your not concerned with interfacing to other vendors you don’t have to use ZigBee clusters. You can just use the ZigBee transport and send text strings back and forth between your device and the SmartThings custom device type. That is what the SmartThings shield for the Arduino is all about. On the other hand if you go the WiFi route then you are going to need some type of cloud based service to allow people to access your device. Sounds simple but if this is going to be a commercial product your headed down the road of creating custom Android and iPhone apps, and maybe even a web based solution.

The propeller actually runs at 80Mhz (5Mhz times 16) and has eight 32bit cogs (cores) for $7. How about this. What do you think about adding the propeller and an xBee to your existing project? Keep all the code and firmware you have now but stick a propeller in there to front end the ZigBee communications.

I love these type of projects and if you build on-top of SmartThings I’m happy to help as best I can and time allows.

1 Like
#6

Thanks for the advice John. Choices, choices! I learned about the XIG the other day (a wheel I don’t need to re-invent!) which sounds like an almost out of the box solution of sorts, but that path only goes so far…

Today I got a couple xbee pro smd units per your advice and soldered up headers. Studied my pcb layout last night looking for room for the Propeller and some eeprom, and it looks like I can make that work.I’m waiting on a P8X32A quickstart board so I can play with John’s code.

Making a tracker smart enough to park itself in high winds and tell you it’s ok and didn’t get destroyed is just step 1 towards a smart heliostat (a concept so far off the beaten path that the spell checker doesn’t even recognize the word!). My theory about heliostats is that they’ve needed a so-called “killer app” in order to become mainstream. Almost nobody besides a utility wants one that just points at one spot all day

Here’s my big picture vision (putting it out here in the PD now!) for where I really want to get:
…you walk in a room, it senses your presence and the need to increase the light level, Since the sun is shining outside and there is an available heliostat that can target a window for your room, the lights remain off, but sufficient sunlight now comes through your north facing window (which can also be used for heating). A load of laundry is started and there is a demand for more hot water, which according to your preferences has a higher priority than the room lighting, so the lights in the room come on as the heliostat moves to the water heater joining another heliostat also on the same target…
The heliostats would all be capable of serving a variety of targets for various other functions such as heating H20, or combined heat/power w/CPV, solar oven, water purifier, dehydrator, even heat driven refrigeration cycle or Stirling engine. I could start evangelizing here, but I really feel like the technology for this vision is just sitting on the shelf waiting to be used to make smart dynamic allocation of radiant solar energy both possible and practical for domestic use.
I’ve got the code for a mutli-target heliostat tracker that will work with just about any DIY alt-azi or equatorial mount using actuators or slewing motors. Properly integrating for SmartThings can make a nice part of my Aquarian dream come true in a way that a cloud based web interface probably can’t.

I don’t know who is going to develop the heliostat target appliances, but at least the ST Hub creates the open infrastructure, and all the motion/presence/temp/illumination sensors that already exist provide baseline functionality and proof-of-concept that I hope will attract early adopters.

1 Like
#7

Love the idea of a heliostat there is an object on the Parallax web site that calculates the location of the sun based on your Lat, Lon, date, and time of day. All the calculations are done on the propeller. Now that you have one on the way you may want to play around with it. My son is a mechanical engineer and for his senior project he made the frame for a self folding solar array. I used the above object on a propeller to aim it at the sun once it was towed to the site and deployed.

Your heliostat sounds like a great project!!

© 2020 SmartThings, Inc. All Rights Reserved.