Please be aware that different RGB(W) bulbs uses different implementation of setcolor, so the capture and restore will be dth specific. I actually have to make some changes to the RM code, as the implementation worked on Phillips Hue, but not with my Aeon RGBW bulbs.
Well that sucks. And it all boils down to STâs lack of documentation and standardization. I think the DTHs should be modified to get to a common standard, rather than having all apps handle them differently. I have a Hue light, I donât have an Aeon light. I got OSRAM lights too. I havenât looked into the âsetColorâ implementation of those DTHs but I will.
Add an actionâŠ
Tapped on âControl RGB lightsâ
Tapped to select some RGB lights
Made selections, tapped Done
Back to selection page (it may be that thereâs several capabilities that share the same, like lights, switches and outlets - which explains this page). Tapped Done
Tapped âAdd a taskâ
Selected âTurn onâ and tapped Done
Continued to add tasksâŠ
4 Likes
These issues come with any multi protocol platform.
Osram and Hue are zigbee.
Aeon and Fibaro are zwave.
The lighting commands are standardized, but youâre looking at two different standardized protocols. They donât do things exactly the same way, and they donât offer exactly the same feature sets. (Loop and Breathe, for example.)
It does create UI challenges, but itâs understandable.
How is setColor different for the two different devices? I mean, what is different? My understanding is that âsetColorâ is a mix of âswitchâ, âsetHueâ, âsetSaturationâ and âsetLevelâ, because the color map contains those four parameters along with a hex color that may replace the hue/saturation/level combination.
If a device has extra commands, theyâll show in there automatically. For example, my Kitchen Ambient Light is a Hue Strip Light under the cabinet. Had I only picked that one, the list of tasks would be:
But if I select several devices, only commands COMMON to all are displayedâŠ
1 Like
The difference is when bulbs have the white capabilities. I have Osram and Aeon, so ultimately I changed the dth related to AEON to eliminate the setcolortemperature, and handle everything in the setcolor command. Also I made minor tweaking in RM (order of the restoring process).
So it can be done, but due to the diversity of implementations, it could be complicated to please the crowd.
1 Like
I guess weâll deal with these as we move forward. Please DO remind me after beta launch.
To an extreme, one could always just chain tasks to set each individual parameter at a time. The Capture will get all available attributes in each device. The restore will allow you to pick which attributes to restore - the trick will be to match the attribute being restored to the command that sets it.
Also, the Capture will use the variables system. It will ask for a variable name - if you donât provide one, it will automatically use a hidden variable, but it will still ride on the variable mechanism. If you DO provide a variable name, youâll then be able to use it anywhere else you want using the Restore command to get attributes out of it.
Get all the lights along a corridor to change to the same color as you walk down it 
@Squares can you please give more detail about what was wrong with setColorTemperature? What was happening?
Thank you
I have to admit, your implementation of the global variable is amazing.
3 Likes
When smart lighting first came out, it only worked with zigbee color bulbs like Hue, not with zwave color bulbs like Aeon or the Homeseer 200.
The following topic discusses those issues with Code examples:
Thank you, Iâll read that.
1 Like
Thatâs a normal PC app message, not specific to what youâre doing.
1 Like
Thanks Mike,
Following @Kriskitâs suggestion, after adding
def childUninstalled() {}
the debug message went away. The message was probably there with two real parent and child apps too, itâs just that Iâve never seen it or rather paid attention to that.
Any particular choice of words for capture/restore states?
- Store state / Restore state
- Save state / Restore state
- Capture state / Restore state
- Push state / Pop state
0 voters
Not convinced about the push/pop as that usually implies a FILO stack (first in last out), which is not the case, unless I implement that as a different function - may come in handy sometimes, when several changes happen to the attributes and theyâre all saved⊠memory becomes a big concern if POP is forgottenâŠ
Thanks so much for your hard work on this. Iâm super excited, especially about global variables. Canât wait for beta release! When itâs all said and done, I wouldnât mind chipping in for the cause. Iâm sure most people feel the same. Thanks again.
5 Likes
I donât know if I missed it, but will you be adding Speech and Audio capabilities with this release? I enjoy using this extensively in both RM and BigTalker. What I would like to see though if possible, is multiple responses to any given situation that can be chosen at random or even in sequence. I think this will add a little more variety with audio responses. Just something on my wish list.
3 Likes
Not true. But calling the uninstall method in the child from the parent during uninstalling can cause some funky stuff. Just let the platform do it for you.
2 Likes
@Jimxenus I am trying to make it be as agnostic to capabilities, attributes, and commands as possible. This means that I go with a list of known capabilities and known standard attributes and known standard commands. If youâre dealing with stock attributes, I already have them all defined (data type, range, options, etc.). If youâre dealing with a stock command, I already have that defined (parameters, each with data type, range, options). If the attribute is custom, then I should figure out an integration method to inquire the DTH about what data type, range and options itâs got. Until then, Iâll just assume value is a string. For commands, you get to enter whatever parameters you think the command has. An integration would be cool here too where I could inquire the DTH about what parameters to use. But getting back to your questions, all standard known attributes and commands are in, so they should work out of the box. I havenât written not one line of code to deal with a certain kind of command or attribute. I have them structured in a table, I go by what the table says. Trust me, Iâm an engineer LOOOOOL
2 Likes
So, if I understand correctly, the part that will still need some coding will be action whereby there may be the possibility of multiple responses?
Randomizing the action you mean? Yeah, thatâs not planned for, though I like the idea. I fiddled with it but then I figured in HA nothing should be random⊠You proved me wrong. 