KDTrey
(KD)
December 23, 2016, 7:52pm
1
Continuing the discussion from setColor() argument :
The shared link is access to my code.
tgauchat
(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)
December 23, 2016, 8:01pm
3
Hi KD,
We canât access source code directly from your IDE account.
You need to use a GitHub repository, please.
i.e., this link doesnât work unless we are logged in as you https://graph.api.smartthings.com/ide/app/editor/818991b7-1795-4426-abd5-d5f9a3210db4
KDTrey
(KD)
December 23, 2016, 8:09pm
4
My apologies. Iâm new to this and GitHub. See if this works
tgauchat
(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)
December 23, 2016, 8:16pm
5
What type (brand, model, Device Type Handler) are the âslaves
â?
If the âslavesâ do not implement setColor()
correctly, then your code could be 100% correct, but still not work.
KDTrey
(KD)
December 23, 2016, 8:21pm
6
tgauchat
(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)
December 23, 2016, 8:23pm
7
Iâm sorry⊠weâre going in circles. Letâs start fresh.
The SmartApp code you linked works fine, but doesnât do anything (it doesnât subscribe to any events).
So how it is that you are getting an error please?
1 Like
tgauchat
(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)
December 23, 2016, 8:25pm
8
The problem, as I said in the other Topic is not your SmartApp, it is your âVirtual Device Type Handlerâ.
See here: Your setColor()
method only takes ONE argument; the Capability specification says it must take TWO arguments:
KDTrey
(KD)
December 23, 2016, 8:40pm
9
oooh OK. Iâm getting the picture. So how would I go about handling this? Would it need to equal two strings, one pertaining to hex and one to saturation?
KDTrey
(KD)
December 23, 2016, 8:41pm
10
OK got ya. so for it to actually change the bulb, I would need to implement the sendEvent() method.
1 Like
tgauchat
(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)
December 23, 2016, 8:52pm
11
Something like that might work, but reallyâŠ
Study (read several times) the Capability colorControl section: http://docs.smartthings.com/en/latest/capabilities-reference.html#color-control
Then realize ⊠it is really a bit of an ambiguous mess⊠(not your fault⊠it just evolved inconsistently, IMHO. There have been a few discussions on thisâŠ
Tagging @Jim ; but encouraging color light developers to chime in.
Capability âColor Controlâ is defined in the Developer Documentation: One simple home system. A world of possibilities. | SmartThings
[image]
###This definition seems effed-up to me ⊠because:
Attributes hue & saturation and Commands setHue(number) & setSaturation(number) are completely redundant with the âhue:â and âsaturation:â keys available to the âcolor[]â Map.
Furthermore, map keys level and switch are obviously and painfully redundant with the distinct Capabilities (Attributes and Commands) of Switch Level and Switch.
This type of redundancy causes non-trivial risk of inconsistencies in DTH implementation and usage by SmartApps. WTF?
.
The âcolor[]â Map is described as âColor Optionsâ.
WhenevâŠ
For a âsyncâ SmartApp I think you can avoid using the setColor()
method, and, instead use the Hue and Saturation Attributes and Commands directly:
1 Like
KDTrey
(KD)
December 23, 2016, 10:08pm
13
Updated SmartApp. Hopefully this subscribes to events and makes changes
KDTrey
(KD)
December 23, 2016, 10:59pm
15
according to the simulator, no. It gave me this message:
grails.validation.ValidationException: Validation Error(s) occurred during save():
Field error in object âphysicalgraph.device.Deviceâ on field ânameâ: rejected value [null]; codes [physicalgraph.device.Device.name.nullable.error.physicalgraph.device.Device.name ,physicalgraph.device.Device.name.nullable.error.name ,physicalgraph.device.Device.name.nullable.error.java.lang.String,physicalgraph.device.Device.name.nullable.error,device.name.nullable.error.physicalgraph.device.Device.name ,device.name.nullable.error.name ,device.name.nullable.error.java.lang.String,device.name.nullable.error,physicalgraph.device.Device.name.nullable.physicalgraph.device.Device.name ,physicalgraph.device.Device.name.nullable.name ,physicalgraph.device.Device.name.nullable.java.lang.String,physicalgraph.device.Device.name.nullable,device.name.nullable.physicalgraph.device.Device.name ,device.name.nullable.name ,device.name.nullable.java.lang.String,device.name.nullable,nullable.physicalgraph.device.Device.name ,nullable.name ,nullable.java.lang.String,nullable]; arguments [name,class physicalgraph.device.Device]; default message [{0} cannot be null]
tgauchat
(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)
December 23, 2016, 11:46pm
16
I donât trust the simulator.
Why not create actual instance(s) of your Virtual Device and/or real color control Things; install the SmartApp into your SmartThings and test it using the SmartThings Mobile App while Live Logging is running on your PC?
KDTrey
(KD)
December 24, 2016, 8:37pm
17
Runs fine with no error but doesnât change the color of the bulb
Get Outlook for iOS
1 Like
tgauchat
(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)
December 24, 2016, 10:57pm
18
Well thatâs better!
Add a whole bunch of log.debug()
statements so you can trace what parts of the SmartApp and DTH are running, and the values of variables, etc., in Live Logging.