OMG Bad Bug! (Hubaction plus create event)

General Discussion
,
1

I have spent many many hours trying to determine why the network connections of SmartThings sucked so badly. In a nutshell, the precise same code snippet worked in one method to send a socket message, and not in another method. And both worked six months ago.

I can’t believe how bad this is. It’s this:

If you createEvent() and return it, or sendEvent(), right after firing off a hubAction, the hubAction silently fails to send.

If you don’t do the event or you do it before the hubAction, it works.

I haven’t gone through to determine this in greater resolution. But it is definitely that particular sequence.

And you guys wonder why us community developers have lost the passion. Good grief!

@Aaron @slagle You guys seeing this?

2 Likes
2

How many such sequences may happen by chance in the wild?

1 Like
3

Tagging @ady624 @pstuart @adamclark_dev @N8XD

1 Like
4

Can you please add a log.trace “Here” between the HubAction and the sendEvent request, right before the sendEvent request, see if it shows in the logs? I have a feeling it won’t. And if it doesn’t, make sure you are not trying to save any unserializable objects to state (ie Event, Device, Location, etc.), or you may have an error in the HubAction, or its response.

5

@ady624 I think you misread what I wrote. The only difference in working and non-working code is moving the sendEvent() line. Which is self-contained. In all four relevant routines, moving that one line up by five solved the problem. Putting it back below restores the problem. At least with the firmware as it exists today.

sendEvent works either way, but if it comes before the hubAction, the hubAction doesn’t. The code after the sendEvent was indeed running; I was logging every step of the message preparation. The hubAction itself wasn’t reaching the device.

1 Like
6

@NWTony have you got a side by side code sample by any chance. Would love to have a play (and see if I can use to my own ends).

Thanks for the tag @JDRoberts

2 Likes
7

Just to be sure, this is a V2 hub?

8

This is a V2 hub. I have made a simple demo and recorded it to demonstrate. As you can see, this isn’t a hubAction problem. (I’m a bit tweaked by that suggestion. Sheesh!)

Video Demonstration of the bug

(You have to download it. This is a downsampled version, at 32MB or so; the original is 490MB. Feel the pain.)

3 Likes
9

Okay, I am impressed. Here I thought the ST Team cared. But I posted code, I posted a description, I wrote a side-by-side example, and I took a video of it and a week later the response has been… crickets.

Bueller?

10

@Aaron

Much better than Bueller.

11

I shared this internally, sorry for not responding. I get about 100+ @ messages a day, some fall through the cracks, but I read every single one. Please remember to use our developer support form if you want a more true support system.
http://docs.smartthings.com/en/latest/getting-started/getting-help.html

3 Likes
12

Thanks, Tim. I hadn’t seen that form before. But I don’t really want to have to ask for support. I want the platform to work reliably and transparently. (i.e. if something seems broken, it may be because the use case is different, but even then, let us know.)

13

@NWTony Took a look at your video, thanks for the description of the issue. I’m wondering, does your sendCommands(...) method create and return a HubAction?

In order for the HubAction to work, you have to return it from your command method (http://docs.smartthings.com/en/latest/cloud-and-lan-connected-device-types-developers-guide/building-lan-connected-device-types/building-the-device-type.html?highlight=Herein#overview). I believe that is the reason why the HubAction fails to send if you put a sendEvent(...) after the sendCommands(...).

2 Likes
14

@paulf That may be it. The hubAction commands were being executed (and hence were working) rather than being returned. This has been working as long as sendEvent happened before, not after.

Returning hubAction without executing it seems to also work, and allows the sendEvent to be placed arbitrarily.

15

Try replacing sendEvent(…) with “def something = sendEvent(..)”

This way you won’t implicitly return the sendEvent into the command list…

16

@paulf I would love to be able to see a timeline history of the documentation pages. These pages don’t resemble what I remember being there early last November.

17

All the documentation should be in github.

18

Thank you. I feel better seeing how much that area has changed.

1 Like