So from the ST app, how did you select pure red? For me, using the color picker in the app gives very hit or miss results. I can have the picker all the way to the top left )of bottom color section) and it turns red… but not near a deep and pure red as when I use CoRE to set the color to “Red”.
I agree the color match in reality isn’t great. I have not tried to “optimize” that at all. I simply used the preset color dots at the bottom of the app UI (note that those continue “off screen” and I only saw orange and yellow at first… I had to swipe to get to the rest of the rainbow).
Chat support told me it is trivial to use the IDE to set hex values. I did not, however, ask how to do that.
Okay, I used those color dots as well and stumbled on the one off screen the 3rd or 4th time I messed with it. This thread did prompt me to go digging around the IDE for this device and I’ve not seen a place where I could enter or even see the current hex value. The only values I see are Level, Hue and Saturation and those don’t appear to be editable.
My 2 cents. I have several osram RGBW products and feel your pain on the colors. My issue was more using virtually any smart app that sets colors (they all seem to match Phillips hue products significantly better) which irks me more because I use the color picker less than setup colors via automation rules. The ONLY smart app that accurately sets osram colors for me is CoRE & it’s spot on. The only colors that I use the app manually to set is shades of white which I can’t stand the presets in any standard Osram DH, none of them match what I would call white so I use a custom DH that has 3 preset white temps that do just what I need (I modified the daylight down to 4K though). I’d recommend this DH over pretty much any other for that reason & a bunch of other presets it includes.
Sorry what’s DH stand for in this context ?
Device Handler or Device Type Handler. Think of it as analogous to a device driver on a PC. Read the corresponding section in the thread below. Using a different DH can significantly change the user experience in terms of expanded controls / shortcuts / more details of device state / etc
So I’ve tried to use CoRE to set “red” and I’m getting an error. Did you do anything special to make that work? I’ll dig and find the error in the Live Logging in a few minutes.
Also, I found that the default RGBW DH triggers a “setColor()” that seems to take a super redundant array of arguments (this declares a shade of red using three different methods!):
setColor([red:245, hex:#F5A623, blue:35, saturation:85.71428504959835, hue:10.39682573716995, green:166, alpha:1])
No, nothing special. I just select the Lightify strip in the Action step and then select “set color” and “red” as the actual Action. When does the error show up, as soon as you select Red? Does it error when you select another color in the huge list of colors CoRE has?
I created a piston that’s tied to a minimote button. The creation process worked fine. The minimote triggers the piston as expected. The “error” is a officially:
info DID NOT PARSE MESSAGE for description : catchall: 0104 0008 03 01 0000 00 54D1 00 00 0000 0B 01 0400
While that’s technically just an informational statement, at least according to what I see there, I consider it an error because the color setting is getting ignored. The piston:
- if minimote button pushed
- then 1) set color = RED 2) set level to 10%
perhaps I’m missing some setup stuff? The light comes on as I expect (meaning “set level to 10%” correctly implies “it needs to be on, if it wasn’t already”), but the color doesn’t change at all (which leads me to believe the set color command is the thing that could not be parsed).
I’m playing around with this a bunch right now and I’m beginning to think there are significantly different handling routines in the Flex based on the type of control one chooses. Color-TEMP based controls seem instant, accurate, and consistent whereas anything to do FULL-color is significantly delayed and sometimes fails.
In full-color control situations the Flex seems to respond to the on/off command relatively quickly but it delays the color controls (even if they are the first THEN clause in a piston). This is frustrating because I have 2 different pistons:
- Turn all lights in the room on and set them to 6500K and 100% (this is for standard daytime “give me all the lumens!!” usage)
- Turn on just the Flex at 10% and in some flavor of pure red (for nightvision reasons - I’m literally calling this “nightlight”). Unfortunately this mode come on at “whatever the last setting was” then takes 2 - 5 seconds to adjust the color. This is completely unreasonable because it ruins night vision if the last mode was “anything other than full red.” I’m going to play with the timing and see if I can get a consistent behavior that cleanly starts from red no matter what.
I’ll try and make time when I get home this evening to do some screen shots of how I set mine up and maybe even a video of the light when the piston is executed. I have my piston set to fade both level and color when my Mode changes (I use red at night for the same reason as you). When my Mode changes from “Evening” to “Night”, it fades from the teal color my wife likes to red over a couple of seconds. I do get some “stutter” when it changes over, but I think that is due to my fade time. I’ve yet to test removing that fade part to see if I get a crisp change in color and level.
On rare occasions (last night was one of them) the color will fail to change, but I don’t know if that is a Flex issue, a CoRE issue, a ST issue, or a WiFi/Ineternet issue. lol
Video or debug logs of what’s happening on your end would be really cool. Here’s my piston so far - note that what actually happens is the light turns on to 20% immediately with “whatever the color was” then transitions (coincidentally) to a teal color, then transitions to “whatever I set” (which is currently red, but I’ve tried a few other colors).
Mine is a bit more complicated than yours, so here is the piston dashboard view:
All of the “Turn On” actions are for just in case it was off for some reason.
I’ll work on some video of you.
Okay, here is a video of the above piston running. It starts with the Mode in “Dawn” and then I manually push it through Mode changes with a separate routine that use to trouble shoot pistons tied to Mode changes.
If you fallow the piston dashboard, the Dawn function is towards the bottom because I added it later on. It actually is at the start of video.
- This is awesome, thanks.
- I hate to ask, but can you test out my use case more and explain how you got things to work? My specific case is, “Flex was ANYCOLORBUTRED and then was turned off, then it being re-activated in RED and at a low %” <- I want to see that happen where the light comes on in RED with no need to activate-then-change. Make sense?
I’m not great at writing pistons yet, so could you upload a screen shot of your piston’s dashboard? That way I can build it the way you have it.
I’m confused because I thought “the pistons dashboard” is the thing I’ve already uploaded (my screenshot from a few posts ago)… is there a way to get to this data via desktop/web instead of through my iOS app? If so let me know where… that’s news to me!
I just realized that the CoRE Dashboard link in the iOS app just opens a Safari page, so when I use that URL in a desktop browser I can see things too. Here’s what I get there (looks like the same stuff from my previous screenshot, though):
Ah okay. I thought your “Flex was ANYCOLORBUTRED and” post was asking for a different type of piston.
I copied your piston (my trigger was a motion detector since I don’t have a Minimote) and this is a video of the results.
It does not actually turn off, seems to try and set a color, then you can see the 2 sec pause, and finally the level and color are set.
If you write longer pistons, that web view will become your best friend when you are trying to walk through your piston logic. lol