As an aside, if you do prefer to use the Powershell and the environment variable isn’t already set, it seems you can do:
$Env:SMARTTHINGS_DEBUG = 'true'
1 Like
Sorry, for now, you can create a Personal Access Token (with all the scopes to make sure you can use all the commands) and use the --token flag:
.\smartthings devices --token=xxx-xxxx-xxxxx
Note: Remember to save that token securely because it won’t be shown again
1 Like
By creating a Personal Access Token and using the --token flag i could perform all the previous commands. Strange situation. Thanks for all the help
Thank you for sharing your results.
This is because the default authentication is done through an OAuth integration to get the Access Token dynamically.
The PAT has a long expiration time and it’s used as a manual authorization because the value is static.
1 Like
Hi, @Joao_Santos.
The team has been analyzing your issue and noticed this is something specific to your account. Therefore, they need to check your account data and make some tests, to do so, we need your help to authorize this access, please follow these instructions:
- Go to the SmartThings Web (my.smartthings.com)
- Log in to your Samsung Account
- Select Menu (⋮) and choose Settings
- Toggle on Account Data Access
- Select the time period and confirm - In this step, please select “Until turned off”, once the team finishes, we’ll let you know so you can disable it again.
Its toggle on.
By the way, I have a strange problem, when I try to create local automations for the lamps that involve several parameters, they don’t work well.
For example, I want the lights in the room to turn on at 50% at 2200K at 10pm, but when I change the brightness and color in the same automation, only one of them changes and it is normally the color temperature. Is this a known bug or is it just my account?
1 Like
Is the device being controlled by a driver released by ST or someone in the Community?
In the logcat, you should see the commands received in the device when the routine is triggered.
It will help you check if all the commands are received but not handled correctly or if it’s missing.
Its an IKEA bulb so has a driver released by ST (not yet migrated to edge driver as seen below), but the result is the same as other bulbs with edge drivers.
This problem occurs with every bulb i have, whether they have edge drivers or the old drivers. I tried with time, motion sensors, buttons, the result is always the same. If i change one parameters it works every time, but if i try the change more at once it only changes the color temp most of the time.
@nayelyz @Joao_Santos
It also happens to me with an edge driver, but I don’t have access to the cli to analyze it
@Mariano_Colmenarejo
By coincidence I discovered this problem when i was trying your Zigbee Light Multifunction Mc driver on a LIDL RGBW strip, then i tried it with a bulb that has a driver released by ST, just to be sure, but the result was the same.
Could you provide more info once you have the opportunity, please? I’d need the capabilities involved to make tests on my side as well.
@Joao_Santos, the team made an internal change for you, so, please help us check if the command works without using the PAT so the default authorization comes in, please?
1 Like
The problem is exactly what @Joao_Santos describe.
If you put more than one actions, one level and another one of color temperature, only one is executed, normally color temperature.
I have an Ikea bulb that is activated by a motion sensor.
Normally I have it turn on at 60% brightness and turn off 5 minutes later.
That combination has always worked for me.
I added the option to set the colour temperature to 2591K to my routine.
The light turned on at 26% brightness, set the colour temperature to 2591K, then 30% brightness and never turned off.
I removed the colour temperature option, and it’s back to working normally again.
Mmmmm this is interesting, thank you for sharing your observations. We’ll make some tests on our side as well.
I have noticed this too couple nights ago, but didn’t report as there were a lot of ongoing bigger issues on platform. But this is correct, if you have level and white temperature change, in reality only temperature changes, level stays the same.
Bigger issue that history is showing changes of both level and temperature, however not the temperature set in automation.
It should be 4500K@100% or 3100K@40%
Every time temperature readjust to different value, and if I remember correctly we used to have Temperature rounding calculation issue couple months ago.
If I move slider, for temperature to minimum level 2700K, it readjust to 2703K, then if I slide it again to 2700K it stays there. Same with preset points, if I select first preset 3080K, it readjust to 3077K, and by selecting same preset agen, it stays on 3080K
This issue was resolved with a change to the colorTemperature defaults
It was working fine, the solution was:
- When the command is received in the driver, the value in °k required by the user is saved with set field.
- Conversion to Mireds is performed and sent to the device
- The device replies with the attribute value set in Mireds
The Handler of the color temperature attribute:
- Converts the value received in Mireds to °k
- retrieves the value required by the user and saved with set field.
- Compare the conversion value to °k with the saved one
- If it is within the difference generated by the conversion error, it emits the value saved with set field, which is what the user requested.
- If the value saved with set fied is null or exceeds the conversion error, then it emit the value received from the device converted to °k.
I do not know what they have been able to change so that does not work now and I can’t analyze it until August.
UPDATE:
Local execution may now be so extremely fast that when the device answers and the hub is still writing the value to memory with set field 
I’ve not worked with bulbs, but I see IKEA mentioned a lot above and I’ve read in various places, for various platforms and going back years, that they don’t like doing things like level and temperature at the same time. Typical solutions seem to involve introducing small delays between the commands so they don’t interfere, or deferring processing so the commands can be combined in some way. Is that something historical or just irrelevant?
I don’t know since when this problem exists, I never had an automation of this type.
The only thing I did was tell them that it happened to me too, with lidl bulbs.
If someone contributes some log of the execution of the automation, it can be analyzed.
In the Zigbee light multifunction Mc driver there is the circadian function and progressive on and off with optional color temperature.
In both cases, level and color temperature commands are sent sequentially and it always worked well and continues to work well, I tried it this morning.
If the small delay between commands that the driver can introduce in the calculations is enough for it to work well?, I don’t know!
I have the CLI installed.
After work today i can alter my motion sensor routine and generate some logs.
2 Likes