SwannOne Key Fob Support (updated 2019 DTH in post #51)

Thanks chipr! Good luck with the testing Rudip!

Yesterday night I was finally able to run some testes but unfortunately the issue is NOT fixed yet.

I’ve started from scratch and was able to get and verify the “device fingerprint” (minor updates here) and it’s basically the same as the Securifi Key Fob. I’ve also managed to create a Refresh function and add buttons to manually call the Refresh and the Configura functions. Everything worked fine but after a couple of hours the device lost connectivity with the ST Hub again.

It would be nice to have the device “Technical Manual” (I’ve tried but could not find it) to see what the device is expecting from the inicial configuration (enrollment) and make sure we are sending the correct information.

Well, I’ll have to go back to the “books” and also try to validate other ZigBee devices to see if I can come up with some new ideas to test :frowning:

Wow! Rudip. You’re getting some good testing in! Good work! I also looked for some technical manuals, and could not find anything!
I will keep researching over the weekend.

The same issue/behavior is being reported for another ZigBee device that is also a remote (buttons) controller, the Philips Hue Dimmer, and there is no solution reported so far.
Just FYI: I could not do much testing this weekend and I’m still reading about ZigBee devices and related issues like the above.

Thats a great find RudiP! I read through the whole thread about the Phillips Hue Dimmer.

It does appear to be suffering from the same problems that we are experiencing with our keyfobs.

There is a wider audience on that thread also, which hopefully will produce many ideas about the issues that we are facing and hopefully a workaround fix!

@Sticks18 or @JohnR, you were both very helpful and knowledgeable about zibgee device handlers while helping with the Securifi keyfob. Would you happen to have any ideas why the SwannOne zigbee device loses connection with the SmartThings hub after several hours/day?

Here is the device code many of us are using:
https://github.com/RudiP/SmartThings/blob/master/devicetypes/RudiP/Swann-One-Key-Fob.src/Swann-One-Key-Fob.groovy

I am curious if we need to tell the fob to check in every so often with the hub.

The device type looks pretty clean and straight forward nothing jumps out at me.

When you say looses connection what does that mean exactly? How do you get the connection back? Do you have to reset the FOB back to factory and rejoin SmartThings to get it back? Or do you just have to move it closer to the hub? Will it stay connected if it stays close to the hub? Wonder if it is a range problem? Did it work okay for awhile and just now start to have problems?

You may want to click on the logging tab in your IDE and let it run in background to see if you can get any messages.

I agree with @JohnR that the code looks fine. I’m surprised it’s having trouble maintaining the connection considering the hub enrolls the device as an IAS zone device. It might be interesting to see the logs to confirm it is enrolling properly and see if they give any clue as what’s happening. I’d recommend adding a log statement at the very beginning of parse() so we see all the messages coming through to help.

We’re having a similar issue with the Hue Dimmer Switch. After some amount of time the remote stops communicating with the hub. I thought about trying to send periodic messages, but I was worried about battery life. I suspect the issue lies deeper in the zigbee firmware/implementation than we can affect with device code.

1 Like

Thank you for taking the time to look at it. I have compared this device to others on the community and GitHub as well and nothing jumps out at me either. I am just wondering if we have to configure it to check in with the hub at a certain internal or something - pardon my ignorance of zigbee devices. I know with my ThingShield zigbee device as an example I get pings on a given interval.

Regarding losing connection, several of us on this thread are experiencing the same issue. We pair the device and all is good but then after X hours, it no longer works and the unpairing light on the fob blinks meanwhile on the SmartThings side the device is still setup, etc. We then have to reset the device and pair it again and then eventually the same situation will happen.

My fob was sitting very near my hub when I paired it and I left it there and came back and it was unpaired. So I don’t believe it is a range issue. These fobs are meant for the SwannOne home automation system so who knows maybe they are setup to NOT work with other systems.

I was just curious if there are any other configurations we can set on the fob itself during config to maybe make it work. There isn’t a whole lot of documentation on those commands so I have been struggling to troubleshoot this. Thanks again for your help!

@tpmanley mentioned this regarding the securifi fob. Wonder if it’s somehow related to this

When I tested your device handler I noticed the sensor rejoins the network on basically every button press. I wanted to hold off on further testing until some lower level changes I’m making to the ZigBee join support is released to make sure it would still work correctly.

1 Like

Thanks I believe it is definitely related because I see the rejoin as well. This is strange to me because the Iris Key Fob doesn’t behave this way but I am no expert on these devices either.

In my case the device works fine and if I leave it sitting for X hours it just stops sending commands to the ST Hub, the pairing light starts blinking on the device every minute or so.
I left the device close to the Hub for testing and makes no difference. On the ST Hub side I can manually send a Refresh or Configure to the device, the Hub logs the COMMANDS but I can’t see any response from the device.
To rejoin I just start the search on the ST Hub (“Connect new device…”) and hit the back button to wake up the device (no need to reset to Factory) and it will rejoin as the same device.

I’ll try to add the Debug Logs to the parse() command as recommended by @Sticks18, but this issue looks very similar to the issue with the Hue Dimmer Switch.

Thanks @kevintierney. The code that we are using is based on your device type code but the Securifi fob is not presenting this issue and id does not look like you had to implement anything to resolve/fix the behavior reported by @tpmanley, am I correct?

So far, I haven’t. Approval of my device is pending these system changes. Don’t know if I’ll need to make any changes yet

Scott, do you have a ZigBee sniffer you can fire up and see what is going on? I don’t have any of these devices and my free sniffer software has expired anyway.

I could never get the sniffed traffic decrypted, so it was of limited use. I think I tried Ubiqua trial, but that was short-lived.

Total speculation but:
It might be something with how ST joins to zigbee remotes since it seems they all try to join constantly. Maybe ST doesn’t identify the hub as an end device at all, so the outClusters of these remotes think they’re unpaired. Some remotes like the Lutron and Securifi will work anyway, but others think there’s a problem.

1 Like

I have noticed when a device sends a device announce packet it triggers the hub’s ID process and the hub says its joining the network. Normally battery powered devices don’t send a device announce every time they are activated. I wonder if something is causing the fob to be orphaned and it sends a device announce when it finds a new parent or reconnects to the old one. I have seen other devices that have extend sleep cycles get orphaned by ZigBee routers. My gut tells me it has something to do with that parent child poll timeout. But I’m just guessing without a trace to look at.

1 Like

Unsure if this helps… Forgot I saved these logs from this past weekend.
Here is the fingerprint:
rawDescription desc: 01 0104 0401 00 05 0000 0003 0001 0500 0000 02 0003 0501

Below is the log during the enroll process and me pushing different buttons:
975bea70-1699-4de3-a762-459b9f6b8396 2:13:44 PM: debug SmartShield(clusterId: 0x0501, command: 0x00, data: [0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00], destinationEndpoint: 0x01, direction: 0x00, isClusterSpecific: true, isManufacturerSpecific: false, manufacturerId: 0x0000, messageType: 0x00, number: null, options: 0x0100, profileId: 0x0104, senderShortId: 0x8a97, sourceEndpoint: 0x01, text: null)
975bea70-1699-4de3-a762-459b9f6b8396 2:13:44 PM: debug [raw:0104 0501 01 01 0100 00 8A97 01 00 0000 00 00 00000000000000000000, profileId:0104, clusterId:0501, clusterInt:1281, sourceEndpoint:01, destinationEndpoint:01, options:0100, messageType:00, dni:8A97, isClusterSpecific:true, isManufacturerSpecific:false, manufacturerId:0000, command:00, direction:00, data:[00, 00, 00, 00, 00, 00, 00, 00, 00, 00]]
975bea70-1699-4de3-a762-459b9f6b8396 2:13:44 PM: debug Parsing 'catchall: 0104 0501 01 01 0100 00 8A97 01 00 0000 00 00 00000000000000000000’
975bea70-1699-4de3-a762-459b9f6b8396 2:13:42 PM: debug Parse returned Swann One Key Fob button 2 was pushed
975bea70-1699-4de3-a762-459b9f6b8396 2:13:42 PM: debug Away button Pushed
975bea70-1699-4de3-a762-459b9f6b8396 2:13:42 PM: debug SmartShield(clusterId: 0x0501, command: 0x00, data: [0x03, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00], destinationEndpoint: 0x01, direction: 0x00, isClusterSpecific: true, isManufacturerSpecific: false, manufacturerId: 0x0000, messageType: 0x00, number: null, options: 0x0100, profileId: 0x0104, senderShortId: 0x8a97, sourceEndpoint: 0x01, text: null)
975bea70-1699-4de3-a762-459b9f6b8396 2:13:42 PM: debug [raw:0104 0501 01 01 0100 00 8A97 01 00 0000 00 00 03000000000000000000, profileId:0104, clusterId:0501, clusterInt:1281, sourceEndpoint:01, destinationEndpoint:01, options:0100, messageType:00, dni:8A97, isClusterSpecific:true, isManufacturerSpecific:false, manufacturerId:0000, command:00, direction:00, data:[03, 00, 00, 00, 00, 00, 00, 00, 00, 00]]
975bea70-1699-4de3-a762-459b9f6b8396 2:13:42 PM: debug Parsing 'catchall: 0104 0501 01 01 0100 00 8A97 01 00 0000 00 00 03000000000000000000’
975bea70-1699-4de3-a762-459b9f6b8396 2:13:40 PM: debug Parse returned Swann One Key Fob button 3 was pushed
975bea70-1699-4de3-a762-459b9f6b8396 2:13:40 PM: debug Night button Pushed
975bea70-1699-4de3-a762-459b9f6b8396 2:13:40 PM: debug SmartShield(clusterId: 0x0501, command: 0x00, data: [0x02, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00], destinationEndpoint: 0x01, direction: 0x00, isClusterSpecific: true, isManufacturerSpecific: false, manufacturerId: 0x0000, messageType: 0x00, number: null, options: 0x0100, profileId: 0x0104, senderShortId: 0x8a97, sourceEndpoint: 0x01, text: null)
975bea70-1699-4de3-a762-459b9f6b8396 2:13:40 PM: debug [raw:0104 0501 01 01 0100 00 8A97 01 00 0000 00 00 02000000000000000000, profileId:0104, clusterId:0501, clusterInt:1281, sourceEndpoint:01, destinationEndpoint:01, options:0100, messageType:00, dni:8A97, isClusterSpecific:true, isManufacturerSpecific:false, manufacturerId:0000, command:00, direction:00, data:[02, 00, 00, 00, 00, 00, 00, 00, 00, 00]]
975bea70-1699-4de3-a762-459b9f6b8396 2:13:40 PM: debug Parsing 'catchall: 0104 0501 01 01 0100 00 8A97 01 00 0000 00 00 02000000000000000000’
975bea70-1699-4de3-a762-459b9f6b8396 2:13:10 PM: debug Parse returned Swann One Key Fob button 1 was pushed
975bea70-1699-4de3-a762-459b9f6b8396 2:13:10 PM: debug Home button Pushed
975bea70-1699-4de3-a762-459b9f6b8396 2:13:10 PM: debug SmartShield(clusterId: 0x0500, command: 0x0b, data: [0x00, 0x00], destinationEndpoint: 0x01, direction: 0x01, isClusterSpecific: false, isManufacturerSpecific: false, manufacturerId: 0x0000, messageType: 0x00, number: null, options: 0x0140, profileId: 0x0104, senderShortId: 0x8a97, sourceEndpoint: 0x01, text: null)
975bea70-1699-4de3-a762-459b9f6b8396 2:13:10 PM: debug [raw:0104 0500 01 01 0140 00 8A97 00 00 0000 0B 01 0000, profileId:0104, clusterId:0500, clusterInt:1280, sourceEndpoint:01, destinationEndpoint:01, options:0140, messageType:00, dni:8A97, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:0B, direction:01, data:[00, 00]]
975bea70-1699-4de3-a762-459b9f6b8396 2:13:10 PM: debug Parsing 'catchall: 0104 0500 01 01 0140 00 8A97 00 00 0000 0B 01 0000’
975bea70-1699-4de3-a762-459b9f6b8396 2:13:10 PM: debug Parse returned Swann One Key Fob button 1 was pushed
975bea70-1699-4de3-a762-459b9f6b8396 2:13:10 PM: debug Home button Pushed
975bea70-1699-4de3-a762-459b9f6b8396 2:13:10 PM: debug SmartShield(clusterId: 0x0501, command: 0x00, data: [0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00], destinationEndpoint: 0x01, direction: 0x00, isClusterSpecific: true, isManufacturerSpecific: false, manufacturerId: 0x0000, messageType: 0x00, number: null, options: 0x0100, profileId: 0x0104, senderShortId: 0x8a97, sourceEndpoint: 0x01, text: null)
975bea70-1699-4de3-a762-459b9f6b8396 2:13:10 PM: debug [raw:0104 0501 01 01 0100 00 8A97 01 00 0000 00 00 00000000000000000000, profileId:0104, clusterId:0501, clusterInt:1281, sourceEndpoint:01, destinationEndpoint:01, options:0100, messageType:00, dni:8A97, isClusterSpecific:true, isManufacturerSpecific:false, manufacturerId:0000, command:00, direction:00, data:[00, 00, 00, 00, 00, 00, 00, 00, 00, 00]]
975bea70-1699-4de3-a762-459b9f6b8396 2:13:10 PM: debug Parsing 'catchall: 0104 0501 01 01 0100 00 8A97 01 00 0000 00 00 00000000000000000000’
975bea70-1699-4de3-a762-459b9f6b8396 2:13:08 PM: debug enroll response: [raw 0x500 {01 23 00 00 00}, delay 200, send 0x8A97 01 1]
975bea70-1699-4de3-a762-459b9f6b8396 2:13:08 PM: debug Sending enroll response
975bea70-1699-4de3-a762-459b9f6b8396 2:13:08 PM: debug [:]
975bea70-1699-4de3-a762-459b9f6b8396 2:13:08 PM: debug Parsing 'enroll request endpoint 0x01 : data 0x0015’
975bea70-1699-4de3-a762-459b9f6b8396 2:12:41 PM: debug parse description: updated
975bea70-1699-4de3-a762-459b9f6b8396 2:12:41 PM: debug [:]
975bea70-1699-4de3-a762-459b9f6b8396 2:12:41 PM: debug Parsing 'updated’
975bea70-1699-4de3-a762-459b9f6b8396 2:12:41 PM: debug Config Called

That’s what we would expect to see, so nothing interesting there. I have an idea.

Can someone add this bit of code to a refresh() command? Then after pairing the device and confirming ST sees the button presses, try pressing refresh and posting the response here.

“st rattr 0x${device.deviceNetworkId} ${endpointId} 3 1”

Scott, this device type doesn’t have a refresh function in it. Can it be placed in config or elsewhere?

This attribute should get updated during the join process, so I don’t want to include it with Configure and there aren’t any other functions. Refresh is easily added though.

At the top with the other capabilities:
capability "Refresh"

Somewhere in the body:
def refresh() { "st rattr 0x${device.deviceNetworkId} ${endpointId} 3 1" }

If you need a tile to call the function, you can add this to the tiles section:
standardTile("refresh", "device.switch", inactiveLabel: false, decoration: "flat") {
state "default", label:"", action:"refresh.refresh", icon:"st.secondary.refresh"
}

And then modify the details line to:

details (["button","refresh"])