Man Terry you should compare your posts from 2 years ago today, ST’s changed you…
1 Like
I’m sure they’ll want to have a lot of apps and supported devices when they go live so I personally think the developers will get them somewhat early.
Since everything runs locally, if the company folds after we get ours, I think we’d still be in a better situation then we are now with ST.
1 Like
As long as they keep the hardware open, they may use web interface to update etc. I just bought eero routers and they have no interface other than phone app and I think that makes settings from cloud. So if they go away so do my routers. Still one of the best tech purchases I have made in a while. They work amazingly well.
Did you watch the demo video of the Animus home heart working in founders home. I looks pretty good.
1 Like
One of their selling points is that it provides an API so I doubt they’d get rid of it.
I don’t remember seeing anything that mentioned remote monitoring and they mention several times how everything is stored locally. I could be wrong, but I have a feeling that the mobile app only works from your own wireless network.
Yes, I saw the video and it looked really good, but there could have always been someone off camera that was controlling them a different way.
THIS.
Don’t believe everything you see on TV. 
That would be pretty blatant fraud but it could be. I still have hope.
I think @tgauchat is turning me into more of a pessimist than I already was.
1 Like
No, you’re not doing it wrong. It’s a bug.
Still waiting to hear back on some questions, but I’m pretty sure it’s "<capability>.<command>" so in the example above, the setLevel command of the “switch level” capability.
Okay, FYI this works fine:
{ state “level”, action:“setLevel”}
And the device type supports the “Switch Level” command? Interesting.
No, the one I’m using it with supports just a switch capability, what I mean to say is that in all of my devices I don’t use capability.command, I just use command as long as the command is identified in the metadata.
However if the capability has the command as an intrinsic method then you don’t need to define the command in the metadata. (hope I didn’t confuse you).
However what I found confusing about that example in the documentation was it was “switch level.setLevel”. It looked like 2 separate commands to me, switch and level.setLevel, but you’re saying is that it’s switch level and setLevel, in which case as you mentioned calling setLevel directly should work (just the way calling on works directly for capability switch). Could it be a bug that setLevel isn’t defined/exported as an intrinsic command?
Also I noticed in the documentation:
setLevel(number, number)
Set the level to the given numbers
What’s the second number for?
Some devices support a delay. We’re in discussion what to do with this; at the definition level, the command does take two params. In practice however, the second is rarely implemented.
1 Like
Got it, possibly just enhance the documentation to show the purpose and it’s optional because the examples below like you said just uses one number with no reference to what the second number represents.
myswitch.setLevel(90) // also turns on the switch
Also, possibly a line on the difference between Switch and Switch Level (obvious to those to know but could be confusing to new devs)
At least when I tested this a few times a while back, it functioned as “setLevel( level, rate )” … i.e., the second parameter was used by some dimmer devices as the ramp-up / ramp-down speed. I believe no value used the default set in the device, 0 was instantaneous, and larger numbers were the some amount of time, not sure of the units.
A lot of dimmers don’t support this dynamically, so perhaps not consistently implemented. It worked for me on a Z-Wave outlet.
I proposed that the “default” value should be available as a Preference in the DTH.
4 Likes
This is how I’ve tried to implement it in any zigbee lighting device handlers I write. “setLevel( level, transitionTime )” where the transitionTime is in seconds usually. Typically, I’ll hardcode the default because DTH Preferences still don’t work all that well; or I’ll make it an optional parameter. Either way, it’s limited to SmartApp calls since DTH pass 0 or 1 parameter depending on the tile type. You could use a custom attribute and base the 2nd parameter on it using a slider or something to set.
1 Like
Its been 20 days where is the fffing fix for this already
@Lgkahn looks like it may take more time still 
In the meantime I will write a modified device type that has a button for each of the 4 or 5 color settings.
as a workaround
2 Likes
it is not the same bug as the slider bug… i modified first the osram driver
see here
and then the general zigbee driver for white color bulbs…
both work ok… ie no errors in the logs… but both DO NOT change the hue…
so the underylying white temp color control in zigbee is BROKEN…