Yesterday I found myself in IKEA and I thought I’d pop up to the Lighting department to pick up a couple of Bilresa dual buttons to play with. Eleventy billion laps later I found where they were hidden, but only when I got home did I realise I’d been fooled by the juxtaposition of the dual button and the scroll wheel on the shelves which had a lip almost as high as the boxes so all you could see is BILRESA and the very top of a picture on the front.
I installed them anyway and discovered a couple of things. One was that although the knob capability was in the profile in the standard driver, it isn’t supported in the mobile app yet. I hadn’t realised that. The other was that the switches on both the scroll wheel and to select the ‘groups’, as they describe it, were totally crap and you couldn’t reliably get pushed, held, double pressed, and triple pressed reported. In particular it often seemed to need a wake up push to report anything at all, let alone the right thing. The LED to indicate the selected group doesn’t seem to stay on, which seems to create unnecessary jeopardy, but then the switch only worked when it felt like it anyway. No idea what the scroll wheel did but I was kind of expecting it to feel a bit clicky as I turned it but not so.
Anyway today I returned the useless things which is a smooth enough process, except the Express return doesn’t have “doesn’t work” as a reason for return. I decided to have another go at finding the dual buttons (it was a matter of approaching the shelf from the other end).
I installed one of the dual buttons and them embarked on a marathon battle to create a couple of Rules with the CLI which, since it became version 2, is now very fond of coughing its guts up on the screen given the slightest encouragement. It eventually turned out that I had two issues:
I’d put an incorrect device ID in. The CLI always used to tell me that I’d done that so that wasn’t on my radar. I just got a 403 error and page upon page of error messages with no hint as to why.
I hadn’t used Matter buttons before and, having scrolled up to see both buttons in the app, hadn’t noticed there wasn’t a separate main component as there is in the Zigbee buttons. So the 422 error and page upon page of error messages was its way of saying I should have written main and not button1. Its not really an improvement on telling me.
A particularly bizarre thing is that when attempting to create a Rule with an invalid device ID, the first part of the response from the CLI is the usage instructions that you would get if you had written the command wrong.
Only then does it dump out a quite extraordinary amount of unsolicited HTTP header information, stack traces and I’ve no idea what, that shows that it has actually run the command just fine. Ironically, about the only thing it doesn’t include is the error message from the response body, which is the only thing it needs to show.
It turns out the CLI spews out the command usage guide and hundreds of lines of network related diagnostics for just about any API call that returns a 4xx code, and possibly others. I did have an example posted above but had failed to redact my CLI access token on one line.
So how do you suppose you invalidate a compromised CLI access token? Well if you think smartthings logout followed by logging in again should do the job then I agree with you. It doesn’t. When you authenticate again you get the same access token with the same expiry date.
If you wonder if you can cheat by changing the PC clock until after the expiry time, you can’t. You still have the same access token with the same expiry time but the CLI now has the wrong value for the expiry time so doesn’t refresh it for you when it does expire.
So how you are supposed to destroy the token if it is compromised is a mystery.
I just wanted to tag you on this (I already have a couple of issues open on Github). Not just because the CLI is now no longer giving the error response for 4xx errors (and possibly others) but is throwing out hundred of lines of crud instead as that is just making one of SmartThings’ best features look ridiculous, but more because of the access token handling.
The hundred of lines of crud exposes the CLI bearer token multiple times, something the CLI historically would never allow to happen. That increases the chances of the token being compromised by insufficiently redacted copies of the crud, which is rather dangerous to SmartThings accounts as that token is pretty powerful.
The obvious response to a compromised token is to delete or refresh it. So how should that be done for a CLI access token? I thought a smartthings logout would do it but although it wipes the credentials,json file, after reauthenticating the CLI has the same token with the same expiry date. Only once the expiry date had passed does the old token stop working and a new one get issued.
Am I missing some really obvious action to take, because this seems really bad?
Hi @orangebucket
Could you please share a screenshot or example of the CLI output via DM? This will help us pass it along to the team for further investigation. Thank you!