Switchmate Switch Covers

Feature Requests
21

Well, scanning is important for HASS purposes because if I set up a command-line switch in there I imagine I would use that for status in the UI. (i.e. if I turned it on physically HASS would still track the state.)

Unfortunately the only thing I know to do is just to try different values, which is a needle-in-a-haystack thing. So far the only two that don’t error are 0x01 (which always returns “off”) and 0x07 (same, but “on”.) But I guess it’s a start until I can figure out more direction or someone else finds an answer. :slight_smile:

22

I have done a ton of sniffing about with apps on my phone and such and I feel like it’s a WHOLE lot less complicated to read the status and turn the newer Switchmate on and off than the old ones.

I’m not sure it uses an auth key anymore, for one thing. Using a BT sniffer app on my phone, I found the device, and by writing a 1 or a 0 to a certain UUID address, it turns the light on or off. Then, a separate UUID’s value will update to reflect that 1 or 0, which it probably where the status bit comes from.

Problem is that I’m not sure how to translate this information into either something a) that script can interpret or b) something I can send via the BT transmitter on my Pi. :slight_smile:

23

Wow, I actually think I did it. Seems the newer Switchmates don’t care about auth keys so much near as I can tell, which is probably horribly insecure, but makes my life pretty easy. :slight_smile:

So here are the command lines:

To turn on: gatttool -b <MAC address> -t random --char-write-req --handle=0x0030 --value=01
To turn off: gatttool -b <MAC address> -t random --char-write-req --handle=0x0030 --value=00
To poll for status: gatttool -b <MAC address> -t random --char-read --handle=0x002b
If on, will return: Characteristic value/descriptor: 01 00 00 00
If off, will return: Characteristic value/descriptor: 00 00 00 00

That seems to be it. I am not totally sure how to parse out the two status statements in HASS to use as a value template, but it can’t be that hard, I wouldn’t think. Actually, wouldn’t this work?

command_state: "gatttool -b <MAC address> -t random --char-read --handle=0x002b"
value_template: '{{value == "Characteristic value/descriptor: 01 00 00 00" }}'

How would I pipe that command through grep to only return the 35th character (in this case, the “1”)?

(Or maybe I just use cut? cut -c 35?)

24

I am currently investigating the same python script for my switchmate (I have one of the older versions).

I was able to scan for it, but I have not been able to get an auth key from it at all.
Every time I run

sudo python3 switchmate.py e8:08:05:7b:03:cb auth

I get

Traceback (most recent call last):
File "switchmate.py", line 161, in <module>
device.writeCharacteristic(AUTH_NOTIFY_HANDLE, NOTIFY_VALUE, True)
File "/usr/local/lib/python3.5/dist-packages/bluepy/btle.py", line 459, in writeCharacteristic
return self._getResp('wr')
File "/usr/local/lib/python3.5/dist-packages/bluepy/btle.py", line 334, in _getResp
resp = self._waitResp(wantType + ['ntfy', 'ind'], timeout)
File "/usr/local/lib/python3.5/dist-packages/bluepy/btle.py", line 296, in _waitResp
raise BTLEException(BTLEException.COMM_ERROR, "Error from Bluetooth stack (%s)" % errcode)
bluepy.btle.BTLEException: Error from Bluetooth stack (comerr)

I have tried sending the switch signal with no auth key, I have tried both keys for SWITCHMATE_SERVICE
(23d1bcea5f782315deef121223150000 and abd0f555eb40e7b2ac49ddeb83d32ba2)

As well as different values for AUTH_NOTIFY_HANDLE and AUTH_HANDLE.

I get the above stacktrace almost every time, though very rarely I will get

File "switchmate.py", line 167, in <module>
device.waitForNotifications(1.0)
File "/usr/local/lib/python3.5/dist-packages/bluepy/btle.py", line 473, in waitForNotifications
resp = self._getResp(['ntfy','ind'], timeout)
File "/usr/local/lib/python3.5/dist-packages/bluepy/btle.py", line 334, in _getResp
resp = self._waitResp(wantType + ['ntfy', 'ind'], timeout)
File "/usr/local/lib/python3.5/dist-packages/bluepy/btle.py", line 290, in _waitResp
raise BTLEException(BTLEException.DISCONNECTED, "Device disconnected")
bluepy.btle.BTLEException: Device disconnected

or

Traceback (most recent call last):
File "switchmate.py", line 147, in <module>
device = Peripheral(arguments[1], ADDR_TYPE_RANDOM)
File "/usr/local/lib/python3.5/dist-packages/bluepy/btle.py", line 318, in __init__
self.connect(deviceAddr, addrType, iface)
File "/usr/local/lib/python3.5/dist-packages/bluepy/btle.py", line 367, in connect
"Failed to connect to peripheral %s, addr type: %s" % (addr, addrType))
bluepy.btle.BTLEException: Failed to connect to peripheral e8:08:05:7b:03:cb, addr type: random

The weird part though, is that the switch will toggle itself about 30-45 seconds after the stacktrace for Error from bluetooth stack (commerr) is thrown…

I know you said you have one of the newer models that doesn’t seem to need authentication, but do you have any insight that might help support older models as well?

Edit: I have dug into btle.py:298 to see what is happening when the error occurred. I printed out the responses and I saw that the old switchmate responded with stat twice, first with a state of tryconn, then conn, and then a response of err with a code comerr. After the stacktrace a response with state of disc (disconnected) comes back.
I’m not sure why there is a communication error, the devices are right next to each other, and clearly data is going back and forth.
Stacktrace with response printed:

btstackerr
btstackerr899×307 12.1 KB

25

I’m afraid I don’t really…I kinda lucked into the progress I made on the new ones, in that the only real lead I had was jimmysprinkles up there pointing out that the errors probably came from the script poking around at the wrong addresses.

I think the current problem stems from the addressing changing with the most recent firmware updates to the old Switchmates and that those changes need to be tracked down and applied to the Python script. It could probably be sniffed at with the same app I used (LightBlue Explorer on iOS) but if the whole auth system is still in place I’m not sure what to do with whatever data was extracted from that.

(Interestingly, in noodling with it now, I’m learning that sometimes just the act of writing is enough to toggle it, and that it doesn’t matter if that write is a 1 or a 0. I may need to experiment and figure out why that is, and I may have to figure out how to write a conditional to my script for “if you’re trying to turn it on and it’s already on, leave it be” since I know I can reliably read whether it is on or off.)

26

Just for fun, I tried using this tool on my older switchmate… and it worked.
However, it took almost exactly 45 seconds each time for the switch to move, and the status command always returns the same thing regardless of the switch state. It’s usable at least!

The nice thing though is that writing a 1 to the switch does not toggle it if the state is already at 1, and vice versa for 0.

27

Yeah, I didn’t catch that part about toggling no matter what when I first discovered all of this, so I may have to investigate a little and see if I can’t figure out why that is, as I don’t think it happens 100% of the time. I may be writing to the wrong address or another bit might need to be flipped or something. (I’m pretty sure one of the other writable bits is “the switch is now upside down” but I don’t know where that would enter into toggle mode, other than 0 being up and 1 down maybe, but that isn’t the behavior either.)

As it is, I’m an amateur here and have lucked into most of this so it would be useful to have someone more savvy and I in these things helping out. It would be really handy to know how to listen in on BT commands coming out of the iPhone app (maybe using my iPad?) and try to correlate that to the addresses I see in LightBlue.

28

So here’s what I have figured out so far:

First, the UUID of all of these services follow the format of <a22b????-ebdd-49ac-b2e7-40eb55f5d0ab>, with ???? ranging from 0010 to 0230. blescan -d provides these addresses as well as the handle addresses that gatttool needs. So here are the ones I have figured out so far:

0010 = Battery level. appears to be 100%. Will know more as my batteries die. :slight_smile:
001f (a22b0010) = system clock of some sort
002e (a22b0080) = “Reverse” inverted bit: 00 for normal orientation, 01 for inverted. Will toggle switch to match the current on/off state with respect to orientation.
002b (a22b0070, read/notify only) = status bit: 00 for off, 01 for on
0030 (a22b0090) = toggle bit: just write to it to toggle state, doesn’t matter what.
0029 (assb0060) = toggle / reset?: when read, value is always 00, but when 01 is written to it, switch toggles and BT connection to device is immediately dropped
0021 (a22b0020) = state of Timer 1. This is a 12-character hex address and encodes the time / day settings from the app.
0023 (a22b0030) = state of Timer 2. Same as above.
0032 (a22b00d0) = state of Motion Detection timer. Same as above.

The one thing I can’t find from the app is the Welcome Home settings; which makes sense, since it’s based on location detection of the phone so why not save that info in the app and trigger as necessary. I am sure that the timer stuff could get hashed out with enough poking at it and changing settings and seeing how the value changes.

Makes me wonder what 0025 (a22b0040) is for, since it’s a 12-character writable field but doesn’t seem to have a corresponding setting.

So that means my command-line switch is imperfect, since both on “on” and “off” commands will toggle the switch. I need to figure out a template that will decide whether to actually send a toggle based on the current state of the switch, which I am sure is doable, I just need to find out how to do it. Right now I use these two commands to track state:

command_state: "gatttool -b C0:12:DF:CB:B3:23 -t random --char-read --handle=0x002b | cut -c 35"
value_template: '{{value == "1"}}'
29

I bought a Switchmate for my fireplace switch and a Wink 2 hub but it won’t pair. Then I see that Wink is killing support as of Feb 28th. I emailed Switchmate and here’s their reply:

Thanks for reaching out. We are just as excited for our re-compatibility with Wink, but unfortunately we are still waiting on Wink to push out their new update to make this compatibility occur. This has taken much longer than Wink advised us (integration was scheduled to occur July 2017). Due to the duration of this delay, I am currently unable to provide you with a reasonable estimate on when compatibility will be re-established. However, I can assure you that our software development team is working closely with Wink to speed this process up for you. I sincerely apologize for any inconvenience this caused you, if you have further questions please let me know!

When I asked a few more questions and pointed out how Wink intends to kill support, they said they didn’t know anything else. I asked about an API for projects like Home Assistant and they said they had no interest. So I guess this product is pretty much Dead! Has anyone had any success as of late or should I just bring back to the store for a refund?

30

Just checking in to see if any more progress has been made with regard to the current-model Switchmates. I think the most recent firmware update (2.9.11) broke the ability to write the toggle bit that I’ve described above; when I try to do it now I get an “Attribute can’t be written” error despite blescan reporting that that address is still read-write.

I was considering installing an ESP8266 in mine (as explained in this video) but according to the comments the battery life is really bad. If it even lasted two weeks instead of five days I could live with that.

31

I don’t know what future Switchmate has to be honest. I upgraded to a Wink2 hub specifically for the Switchmate then found out they don’t even support the new version. I contacted both companies and it seems they both are on a different page. Switchmate says they are waiting for Wink to update their firmware with the changes and Wink says they are discontinuing support at the end of the month because Switchmate refuses to correct the issues Wink addressed. When I sent the email from Wink to Switchmate they were surprised and then later replied from second level support that they were removing all Wink advertising from their packaging. I also asked about an open API for open projects like HA and they said they were not interested. Considering everything it looks like Switchmate as a company just doesn’t care to integrate with anyone! I don’t see how they intend to survive as a company just relying on a app for use of their product and siloing themselves but it is what it is. Maybe one day they would change but in the meantime I’m not wasting anymore time with these guys.

32

Maybe, but the great thing about this community is that a product isn’t dead until WE decide it is. So I may not buy more of them (honestly I don’t NEED more than the one I have), but I still have one and need it to work with HASS so I’m still gonna grind at it. :slight_smile: And I know I am not the only one.

1 Like
33

I agree and hope it gets supported too. My point is the company seems to be pretty difficult to work with. They make changes and don’t really care that it breaks integrations. Try sending them an email too, the more they get support tickets asking for these features the more likely we are to get long lasting support.

34

Well, yeah, at the same time, though, addressing it directly via BTLE is not a supported scenario, so I don’t really get to complain that they broke it with a firmware update when it still works with their app and was supremely insecure to begin with. :slight_smile:

Agreed that they don’t play very well with others though; they have teased direct Alexa support for some time as well, and point fingers at Amazon every time someone asks why it hasn’t happened yet. Looks like a trend.

That said, they literally make the only device that is feasible for me to control my kitchen lights with (I live in an apartment or else there would have been a WeMo switch in there months ago) so I have little choice but to pound on it.

35

@clemon79
I use one on a low voltage fireplace switch which is also the only option If I want to control the fireplace. So I’m in the same boat as you. Yeah, I think they keep blaming everyone but themselves and so I’m not too hopeful it will be a long term product I want to use.

Have you thought of using Hue lightbulbs instead of a switch?

36

That would certainly make the most sense since I’ve transitioned to Hue for my living room lights. Problem is that my kitchen lights are five BR30 cans. If you can find me BR30 Hue-compatible bulbs for less than $10 per I’m all ears. :slight_smile:

37

Yeah, that’s one thing I hate about Hue is the price. Especially if you have multiple bulbs. It ain’t cheap

38

Good news, everyone! I applied 2.9.15 tonight (what the hell, right? Wasn’t working for me before, and in fact there was a new issue where the thing was freezing up and wouldn’t even work with the physical button unless I pulled the battery and reset it), and everything works again, the toggle bit can once again be written to and I can talk to it directy over BTLE. So I’m back in business!

1 Like
39

I noticed that you were able to control a HomeBrite bulb through Home Assistant. Could you tell me how you did it? I have 2 bulbs I would like to control and I’m not a good programmer. Thanks.

40

Well, ultimately I threw them over my shoulder and jumped on one of the Philips Hue starter set sales because the HomeBrite bulbs are garbage quality, an incredible pain in the butt to work with, and Feit Electric support (even for warranty replacements) is utterly horrible, but if you really want to tussle with it you can look in this thread for more information. I’m pretty sure I found an article someplace explaining how the CSRMesh implementation came about but I can’t remember where right now.