Osram Color Bulb Missing Hue, CT, Sat

[rmorriss]

https://drive.google.com/file/d/1KIB...ew?usp=sharing

Some logs with some comments in ****COMMENT***

Love to help test anything for you. Once I get the up/down values working, the last challenge would be to figure out how to make it work with UPB which has no dim level feedback. I was thinking I could make a counter. When FADE DOWN is seen, set the counter to 1, when FADE stop is seen, set the counter to zero. Loop the script while counter = 1, and stop when counter = 0. I think this would mimic the "hold and dim" actions of a switch. The problem I saw is the dim commands seem to queue but not get executed. You have to wait until it returns "Lights are updated" before it works again Whatever I do I think I would have to account for that unless it is a bug you can handle. Thanks Wim and Bill!!!

[w.vuyk]

rmorris,

I was checking the attachments you posted, but do not see the comment lines you mentioned. But I do see some weird errors in you log which I find strange.

I have checked the dim buttons here, and noticed that the saturation up and down buttons are missing! This could have been missing for several versions already.... So I have corrected this for the next version.

But testing the up and down stuff here, for hue, CT and dimming are working normal here? So I wonder why it is not yet working for you. It could be caused by the fact that the recessed lights are not yet known really for the plugin, although it seems to do well in the plugin.
I am here finishing the last stuff for the new beta, one of the new functions is that it can display the details on the properties page of the device.

Could you hold a bit until this new beta comes (should be tomorrow if I can finish it today)

Wim

[rmorriss]

Wim,

Of course - probably best for me to test all the functions in the new Beta. I betcha I attached the wrong log, I was tired

It's Ok, I can generate another one for you, I'll run some test cases and send it back. Wondering about the Decrease command and feedback with it. Am I right that the command doesn't queue and execute, but is discarded if I don't wait for the feedback? I saw some queuing messages, but like I said it behaved differently when I wait between presses. Almost like it is interested in queueing them up but doesn't like them for some reason. I'll check tomorrow this time to see if there is a new beta posted then I can install and run some tests. Thanks, Wim!

[w.vuyk]

rmorris,

I do not know what you see with queuing? Is this within HS3 or are you seeing this in the log of the plugin? If it is the plugin there is no need to worry. There is a timer that prevents flooding the gateways, but sending the up and down commands will never flood the queues.

I have played more with the up and down buttons here today and - aside from the missing up and down buttons for the saturation device - all are working. I tested with the Philips and ikea lights as I do not have OSRAM lights here.

But what I noticed is that if the saturation is low, you will hardly see the colors change when using the up or down button. When testing it would be good to set the saturation to max - 254. Then a hue change is seen immedately. Then you have to wait for the device to update - not each update is reported back from the gateway I noticed. So in a bad case when using deCONZ it can take 30 seconds to update (where the webhook 'should' have reported this instantly). During the update pressing the same button again has no effect. Will check later if I could update the device anyway, not waiting for the webhook or the polling function to update...

Does saturation work for you with the OSRAM lights? I have another user who cannot control the saturation of a bulb, coming from OSRAM. Am not sure if this standard for this bulb or because the bulb keeps becoming unreachable.....

While I was at it, I was getting annoyed as I was pressing the down buttons repeatedly, while the device already at it lowest values, so nothing happened then. So I have changed both up and down buttons to "cycle" upward or downwords. Once at the low or hig value, they will start again.


In the new beta, which is send just now to HST, the saturation devices will get their buttons again and the cycle functions are added, amongs other updates.


Thanks,

Wim

[rmorriss]

Hey Wim,

NOt sure if it posted yet as the version didn't change. I reinstalled it anyhow, and don't see a difference, so I think it's still in progress. Maybe they must approve it? Do you know what version # I should see? Did obvious things like refreshed the paged, and checked under incognito

[w.vuyk]

rmorris,

I send the update yesterday, but sometimes HST takes some time before they publish it. Let's hope for today...
The new version will be 2.01.9. You will find it on the manage plugins page in the beta section (near the bottom of the list) once it is available. You will then also see if the version differs from the one you are using.

Thanks,

Wim

[rmorriss]

Not yet! Will check tomorrow.

[rmorriss]

Hi Wim!

Things I noticed..

Saturation works.. I didn't play with the up down, just looking at the Slider, becuase I started noticing some other weirdness. I think this below will explain it. It seems, it wants more data per request then you are sending

I connected the to API to see what was going on in POSTMAN

Just some notes:

Saturation always remains at 0, x/y is what changes

{
"etag": "e233a1e754578e5022e67f9fbf92139e",
"hascolor": true,
"manufacturername": "OSRAM",
"modelid": "LIGHTIFY RT RGBW",
"name": "Office 04",
"state": {
"alert": "none",
"bri": 122,
"colormode": "hs",
"effect": "none",
"hue": 0,
"on": true,
"reachable": true,
"sat": 0,
"xy": [
0.312704,
0.328988
]
},



Once I started sending the REST commands via POSTMAN, Life was OK.. It actually worked. What I noticed is that the state values never change, doesn't matter where the control comes from, the plugin, or POSTMAN. So it look like DECONZ has some bug with state.. Carry on...

I see you are logging the result and it says success:

Your result

[{"success":{"/lights/25/state/on":true}},{"success":{"/lights/25/state/hue":34457}}]

This is sheer madness, because the light doesn't actually change!!

Then I figured it out. Mine was working great. Yours wasn't. How is this possible when you get state success??? How is this possible when we are probably reading the same API document?? What is wrong? Just for kicks I decided to clean up a bit. I was sending this out of laziness cutting and pasted from the docs:

{
"on": true,
"bri": 180,
"hue": 43680,
"sat": 255,
"transitiontime": 10
}

Decided, ok, remove the stuff I don't care about.

Started sending:

{
"on": true,
"hue": 43680
}

Got the same lovely "Success" messages as you, but alias, I replicated the problem in the Plugin! No light changes!

It seems it doesn't like being without "sat" for a "hue" command. I had some fun with transitiontime too that really makes it cool .

[{"success":{"/lights/25/state/on":true}},{"success":{"/lights/25/state/hue":10000}},{"success":{"/lights/25/state/sat":254}}]

This result worked every time.

So it seems you must send the current sat setting along with the hue, or it just says "Success" and does nothing. It tells you success. But it must have a different definition of success than you or I..

So ultimately, for me (an I assume others) I'm interested in controlling groups. So, naturally I tried the same thing:

http://192.168.1.14/api/988112a4e198...roups/4/action

{
"on": true,
"bri": 254,
"hue": 10000,
"sat": 255,
"transitiontime": 10
}

Works great!

This however, does not.

{
"on": true,
"bri": 254,
"hue": 10000,
"transitiontime": 10
}

I tried them all. "sat" is the problem. It's required. I've also attached my log from this exercise as well..

On to the Up/Down.. They work great. Where I get confused is the slider feedback doesn't work. IMHO I will just kill the slider, don't want it anyway.

It would be nice of you could ask for /state/ and have it be right. It doesn't seem to be right. Well not right away anyhow. You see I went back to check it and there it is, up to date!! But it takes MINUTES.. So it's useless in my opinion. It seems you have to track your own state. This maybe why your slider controls/feedback don't seem to work either, because the only thing that can be relied on it seems is the state from the call itself.

I opened this on Git, see if they say something: https://github.com/dresden-elektroni...gin/issues/387

Log: https://drive.google.com/file/d/1I5a...ew?usp=sharing

[w.vuyk]

rmorris,

Thanks for the digging you did! It really helps me to understand what is going on. These issues are a challenge when you do not have the same bulbs
Adding the sat value to the command will be done with the next beta version. It is not needed so far of any other brand, so it is specific to only OSRAM. Officially (following Philips guidelines) it will cost some performance, but I think this should be good to go...

I see you are getting an error on the webhook return call, where the REST API returns xy values instead of the HUE values. It looks like the OSRAM is not really supporting the hus/sat values really, similar as the IKEA bulbs, that only work with the xy values? Will try to find out on the github.

On the error, I will send you a PM for an extended trace for the webhook error.
Once we solve this, the plugin will at least immediatly update the devices to the set value.

Thanks!

Wim