ThingShield fails to receive message

I have a ThingShield attached to an Arduino Mega. I’m using the ST_Anything library. The switch is set to D2/D3. Pins 2/14 and 3/15 are jumpered.

The device type includes the following:

def open25()
{
zigbee.smartShield(text: “OPEN25”).format()

  log.debug "Sent to device: OPEN25"

}

Logging shows that it “fires” appropriately.

The sketch includes:

SmartThings smartthing(HW_SERIAL3, messageCallout); //constructor for hardware serial port with ST_Anything Library
.
.
void messageCallout(String message)
{
smartthing.shieldSetLED(0, 1, 0); // shield led is green

if (message.length()>0) //avoids processing ping from hub
{
smartthing.shieldSetLED(0, 0, 9); // shield led is blue

  smartthing.send(message);
  if (message.equals("OPEN25")) 
  {
              Serial.println("open25");
  	Serial.println("Interleave coil steps forward");

  		myMotor->step(25, FORWARD, INTERLEAVE);
  	smartthing.send("Opened 25%");
  }
  if (message.equals("CLOSE25")) {
  	Serial.println("close25");
  	Serial.println("Interleave coil steps backward");
  	myMotor->step(25, BACKWARD, INTERLEAVE);
  	smartthing.send("Closed 25%");
  }

}
smartthing.shieldSetLED(0, 0, 0); // shield led is off
}

The shield receives a ping every so often. I’m using the LED to visually signal what’s going on. I can get it to send a message back to the cloud, but other than a ping, it NEVER receives a message from the cloud (i.e. the OPEN25 message).

Any ideas?

1 Like

Have you tested with the official SmartThings’s library? It’s not as good, but at least you might get “official” support.

It has a debug flag for some tracing, but needs more.

But I experienced this same problem at the Internet of Things World Event hackathon a few weeks ago. Shield worked fine at home, but not at the conference. Didn’t have time to find a solution… But interested.

1 Like

No, I have not. I will give that a try.

I did find something odd though. If I send “on” or “off”, the shield receives it - it just doesn’t receive anything else (just those two specific messages).

The library has to parse out the headers on the ZigBee packets to extract the “message”. I have my suspicions that this code isn’t handling certain odd situations properly.

By starting with the official library, we can be on the same page. I can add more debug tracing as we go along, perhaps.

I’ve been meaning to work on some Tutorials for the shield, so this is helpful.

try

def open25()  {
log.debug "Sent to device: OPEN25"
zigbee.smartShield(text: "OPEN25").format()
}
2 Likes

@urman
When I originally tried your fix, I put the log.debug first, but I left a line after zigbee.smartShield. I didn’t notice it, but then I figured out I didn’t really try what you had suggested. Once I did, well problem solved.

I really appreciate the fix, and this comment has nothing to do with your suggestion (I truly appreciate it), but rather towards ST. Should it work this way? Shouldn’t either way work? Why does a statement after the smartShield function cause it to be ignored?

EDIT: To clarify the limitation: You can have other code, just not log.debug or sendEvent (or anything that generates a message to the cloud).

Thank you very much.

Really??

This is either an undocumented synchronization limitation (or whatever it would be called…) or a bug.

Really!!!

I can make it work or fail at will.

Also, I think I have found a few other “limitations”, but I’m still trying to narrow the pattern down.

This will be a very valuable contribution to the Community, once the details are deterministic.

I wonder if there’s some buffer overlap or ? There are a lot of mysteries surrounding the SmartThings “zigbee.*” Class and what is processed in the Hub vs. Cloud.

@rappleg would know. If I remember correctly it’s not a bug. It’s something to do with basic code execution. I’m just a pretty face. @rappleg is the brains.

i know this topic is old, but i cannot find any other topics on this. does anybody know what the root cause for this is? or is there something that has changed so it is possible to logically call sendEvent AFTER the command has actually been send to the shield?

It’s just a limitation. The second message to the cloud kills them both.

I re-ordered things and I repackaged a few messages. No issues.

@bago is there any documentation about this? or anything in the community about why this limitation exists?

1 Like

Nope. When I had the issue I came here and started the thread. This is it. I don’t know why. I asked the same question. Sorry.

Can you work around it? I was able to and have not had any issue.

yeah, I worked around it. but without somebody at smartthings acknowledging and writing it down, I just have no idea where this might pop up again. not a big deal, just a platform nuance I suppose.

1 Like

That’s how saw it too.