I can’t say if it ‘guarantees’ the order, but I can say that during my testing I have never observed handleCommand() being called out of order.
In the meantime I observed another more difficult issue, (which would cause problems both with my solution, and with a rules based solution). The problem is as follows..
Light starts off at (say) brightness == 1%
User sends a complex command e.g. set brightness to 100% over 20 seconds
Binding sends complex command to bridge
Bridge IMMEDIATELY sends SSE event with (target) brightness == 100%
After about ~15 seconds bridge sends another SSE event with (actual) brightness == about 70%
Binding informs OH with brightness == 70%
OH core sends unsolicited handleCommand() with brightness == 70%
This causes the binding to send brightness == 70% to the bridge
Which STOPS the planned transition to brightness == 100%
The problem is with the OH core step 7. above; and I don’t know how to fix it. Note: the problem does not arise with transitions less than about 15 seconds, since steps 5, 6, 7, etc. do not occur.
Exactly. That is why, if you send a command (without precessor) it will be executed immediately. Whereas if you send a command that had been preceded by a delay command, it will be executed with the respective delay.
If you use (say) the Hue app to send a channel command, and that same channel is being displayed in Main UI, then OH will accept the new value, the Main UI will update, and OH will send a handleCommand() to the thing.
If you use (say) the Hue app to send a channel command, and that same channel is NOT being displayed in Main UI, then OH will accept the new value, and OH will NOT send a handleCommand() to the thing.
Ok. In the latest build, I implemented it BOTH ways.
Send a DecimalType(transitionDuration) to the dynamics channel, and then within ten seconds send (say) a PercentType(100) to the brightness channel, or ..
From within a rule send dynamicCommand(String channelId, Command command, DecimalType durationMSec)
Yes I did. However one of the advantages of API v2 is that dynamics do not only apply to lights, but also to scenes and rooms and zones. So the old name is not completely appropriate. It is probably a trade off between making it easier for existing users, versus making it easier for new users.
3dcdda92-3d88-4ef0-80b1-3530bb110ebe -> updateState() 'light-level' updated to '11853' - light-levels are reported by a factor of 100 I guess?
Something still isn’t right with scenes. Restarted openhab, and suddenly two my room/zones do no longer have a scene channel - which they had before restart
See the following from the Hue API v2 documentation:
Light level in 10000*log10(lux) +1 measured by sensor. Logarithmic scale used because the human eye adjusts to light levels and small changes at low lux levels are more noticeable than at high lux levels. This allows use of linear scale configuration sliders.
EDIT: notwithstanding the comment about linear scales, I could imagine that OH users might prefer if this channel would reverse the above mentioned transformation formula and present the actual light level in Lux. => WDYT?
EDIT 2: i.e. rather than the channel being a Number (:Dimensionless), it should perhaps be Number:Illuminance ??
EDIT 3: to answer my own question, I think the answer should be ‘yes’..
@seime I made yet another attempt to fix the scene initialization timing, and also the units of measure of the light level and dynamics channels. Jars in the usual place..
Im having an issue with the brightness of a hue ambiance candle bulb.
If I use “openhab:send 1” to the bulb, the bulb goes dark and is 0% in the hue app.
If I use “openhab:send 2”, the bulb goes on and is 2% in the hue app.
All numbers from 2-100 are correctly set and are shown with the same number in the hue app.
If I set 1% in the hue app, openhab is update to 0% for this bulb.
I see the same for a “Hue Fugato color spot”:
Change Brightness in hue app for the spot to 1% → event.log →
Item ‘xx:color’ changed from 264.005,35.2200,18.11 to 264.005,35.2200,0
I’m using the lates version from your pull-request (commit from yesterday).
All lights when they are on have a maximum and minimum lumen output. If you command below the minimum, it is interpreted as off. Apparently the minimun for your particular light is between 1% and 2%..
When I add a smart button and want to configure the channel I have the following problem:
It says it is missing a profile and I cannot click on any of the shown one. Changing the type to Number doesn’t make a difference either.
I checked the code
if ((this.channel ? this.channel : this.selectedChannel).kind === 'TRIGGER') {
debugger
if (!this.compatibleProfileTypes.length) {
this.$f7.dialog.alert('There is no profile available for the selected item')
return
}
if (!this.currentProfileType || !this.compatibleProfileTypes.includes(this.currentProfileType)) {
this.$f7.dialog.alert('Please configure a valid profile')
return
}
}
and it reveals that this.compatibleProfileTypes is indeed empty.
I checked Philips Hue - Bindings | openHAB but this even doesn’t mention to add a particular profile. Do you know what the issue is?
