YahueV2 (Yet another Hue app, using Hue API v2)

[Sankotronic 2,370]

Hi Jan,

 

before I left home I tested buttons for effects, but wasn't working either with light turned off or turned on.

 

[jgab 2,644]

On 5/23/2026 at 6:52 PM, Sankotronic said:

Hi Jan,

 

before I left home I tested buttons for effects, but wasn't working either with light turned off or turned on.

 

I believe I have fixed it in the latest version...

[ChristianSogaard 71]

Hi, Jan

Thank you for the great work on Yahue

I am using Yahue on Fibaro HC3 together with Logic Group Matrix keypads/controllers, where centralSceneEvent events are mapped to Hue actions.
Im still no programmer so if i analysed something wrong, please live with my wrong assumsions. 

 

Basic actions work very well, for example:

turnOn  
turnOff  
toggle  
setValue

However, dimming from physical wall buttons is harder to make stable.

 

Current challenge

From what I can see, Yahue’s startLevelIncrease and startLevelDecrease start a fade/ramp towards 100% or 0%.

That makes sense for Fibaro’s standard level-change interface, but for external button controllers it would be very useful to have more controlled dimming options.

 

Suggested improvements

1. Step dimming API

A method for small brightness steps would be very useful, for example:

fibaro.call(deviceId, "stepValue", 5)  
fibaro.call(deviceId, "stepValue", -5)

or:

fibaro.call(deviceId, "dimStep", "up", 5)  
fibaro.call(deviceId, "dimStep", "down", 5)

This would allow external controllers to repeat small steps while a button is held down, instead of starting a long ramp to 100% or 0%.

2. More robust stopLevelChange behavior

For physical button controllers, it is important that:

fibaro.call(deviceId, "stopLevelChange")

always stops an active level change immediately and reliably.

3. Configurable dimming parameters

It would be useful to have configurable variables per Yahue child, such as:

dimdelay = 3000  
dimstep = 5  
diminterval = 300

This would make it easier to tune Yahue for physical wall buttons.

4. Exposed capabilities

It would also help if Yahue child devices exposed their capabilities in a predictable way, for example:

supportsDimming = true  
supportsScenes = true  
supportsColor = true  
supportsTemperature = true

This would make it easier for other QuickApps to detect what actions are supported by a given Yahue child device.

5. Scene stepping support

A built-in next/previous scene action would also be useful:

fibaro.call(deviceId, "nextScene")  
fibaro.call(deviceId, "prevScene")

 

Summary

Yahue already works very well for Hue integration on HC3.

The main thing that would improve compatibility with external wall controllers and Matrix keypads is a small “button-controller friendly” API, especially around step dimming and reliable stopping of level changes.

[jgab 2,644]

Not released yet, but work in progress + questions

 

Item 4: Capabilities

Please login or register to see this attachment.

Stored in quickAppVariable 'capabilities'
 

Item 5: Scene stepping

Added to RoomZoneQA (inherited by RoomZoneDimQA, RoomZoneSwitchQA):

- `nextScene()` — cycles forward through the room's scenes (wraps around)
- `prevScene()` — cycles backward through the room's scenes (wraps around)

Usage from another QA or scene:
fibaro.call(roomChildId, "nextScene")
fibaro.call(roomChildId, "prevScene")

The scene list is populated at startup in loadScenesForRoom and stored as self._sceneList. The current scene is tracked via the existing lastSceneId variable. Honors the sceneMode setting (static/dynamic).

 

Items 1, 2, 3 — Questions

Item 1 — Step dimming API
Does not exist. The Hue v2 API natively supports dimming_delta with action: "up"/"down" and brightness_delta (percentage of full range), which would be the most reliable mechanism — the bridge handles the ramp internally and it's compatible with existing stopLevelChange.

Question: Preferred API shape?
- fibaro.call(id, "stepValue", 5) / fibaro.call(id, "stepValue", -5) (Fibaro style)
- fibaro.call(id, "dimStep", "up", 5) / fibaro.call(id, "dimStep", "down", 5) (explicit)
 

Item 2 — Robust stopLevelChange
Already implemented. Both DimmableLight (line 789) and RoomZoneQA (line 1270) send dimming_delta={action='stop'} via the bridge's native stop command — the most reliable mechanism available at the API level.

Question: Have you observed specific stop failures? Under what conditions (fast ramp, specific light models, combined with other commands)?
 

Item 3 — Configurable dimming parameters
Partially exists. dimdelay (default 8000ms) and transition (default 0) are already configurable per-child via QuickApp variables. dimstep and diminterval are new and would be relevant for step dimming.

Question: Is diminterval needed for Yahue to handle internal repeat timing, or does the Matrix keypad/controller handle hold-repeat timing itself? (Typically the controller determines repeat rate — Yahue just needs to respond to each individual call.)

[ChristianSogaard 71]

16 hours ago, jgab said:

Thank You Jan, 
tack så mycket

The QA is here..

Please login or register to see this link.

Item 5: Scene stepping

Added to RoomZoneQA (inherited by RoomZoneDimQA, RoomZoneSwitchQA):

- `nextScene()` — cycles forward through the room's scenes (wraps around)
- `prevScene()` — cycles backward through the room's scenes (wraps around)

Usage from another QA or scene:
fibaro.call(roomChildId, "nextScene")
fibaro.call(roomChildId, "prevScene")

The scene list is populated at startup in loadScenesForRoom and stored as self._sceneList. The current scene is tracked via the existing lastSceneId variable. Honors the sceneMode setting (static/dynamic).

 

That sounds perfect for Matrix keypad use.

For my use case, nextScene() and prevScene() on RoomZoneQA, RoomZoneDimQA, and RoomZoneSwitchQA are exactly what I need.

Pressed3 = { "nextScene" }

Item 1 — Step dimming API
Does not exist. The Hue v2 API natively supports dimming_delta with action: "up"/"down" and brightness_delta (percentage of full range), which would be the most reliable mechanism — the bridge handles the ramp internally and it's compatible with existing stopLevelChange.

Question: Preferred API shape?
- fibaro.call(id, "stepValue", 5) / fibaro.call(id, "stepValue", -5) (Fibaro style)
- fibaro.call(id, "dimStep", "up", 5) / fibaro.call(id, "dimStep", "down", 5) (explicit)

 

For external controller integrations like Matrix keypads, I would prefer the explicit API:

fibaro.call(id, "dimStep", "up", 5)

fibaro.call(id, "dimStep", "down", 5)

 

Item 2 — Robust stopLevelChange
Already implemented. Both DimmableLight (line 789) and RoomZoneQA (line 1270) send dimming_delta={action='stop'} via the bridge's native stop command — the most reliable mechanism available at the API level.

Question: Have you observed specific stop failures? Under what conditions (fast ramp, specific light models, combined with other commands)?
When I release the Button, light continue Dimming for another 3-4 seconds, i tried Various methods
 

Item 3 — Configurable dimming parameters
Partially exists. dimdelay (default 8000ms) and transition (default 0) are already configurable per-child via QuickApp variables. dimstep and diminterval are new and would be relevant for step dimming.

Question: Is diminterval needed for Yahue to handle internal repeat timing, or does the Matrix keypad/controller handle hold-repeat timing itself? (Typically the controller determines repeat rate — Yahue just needs to respond to each individual call.)

For the Matrix keypad/controller use case, I think Yahue should not handle internal repeat timing.

The Matrix Button Configuration QA can handle the hold-repeat timing itself:

HeldDown starts a repeat timer
the QA calls dimStep("up", 5) or dimStep("down", 5) repeatedly
Released stops the repeat timer
optionally Released also calls stopLevelChange() as safety
So from my point of view, diminterval does not need to be handled by Yahue internally.

What would be useful in Yahue is:

dimstep as an optional per-child default value
but also allow the step size to be passed directly in the call

 

Edited Thursday at 06:41 AM by ChristianSogaard
Typo

[Sjakie 156]

Jan, I asume  also possibility to set time when go to next scene?

Item 5: Scene stepping

 

I now have 2 scenes where I switch every 3 minutes to the following scene around 30 in total.

[Sjakie 156]

Jan, if I change my rule switch on on 10%

Please login or register to see this code.

Visual the light goes strait on >> 70% no delay.

dimdelay is in GV set on see file

 

debug shows:

Please login or register to see this code.

 

Please login or register to see this attachment.

[jgab 2,644]

The :manual issue. Try Yahoo v0.2.61. It seems like when turning on/off a Yahoo light it sometimes sent multiple value events that confused ER,

[Sjakie 156]

jan I added

Please login or register to see this code.

 

Please login or register to see this code.

 

[jgab 2,644]

So it was actually using the 'transition' variable for the dimming... in v0.2.62 I use qvar 'dimdelay' if qvar 'transition' is not set, which makes sense.

[Sjakie 156]

Jan still no visual dimdelay.

If I move the slider manually I see in debug the values going up/down

if HC3 change value in this rule no debug change 10% >> 70%

Please login or register to see this code.

 

[jgab 2,644]

Try again v0.2.63

[jgab 2,644]

I looked at your PM log and saw some more issues.
It's REALLY difficult to make a Hue grouped light (room/zone) to behave like a QA light.
When you recall a scene on the group, the Hue hub does it's own thing asynchronously, and in this case cancels the setDim you also do...
I think I've made a patch in v0.2.64 that handles it, but at the end you need to start to treat the Hue lights a bit different - ex. insert waits before you issue
commands in sequence etc so the Hub gets a chance to respond sequentially. 

[Sjakie 156]

Jan,

I am using several daylight scenes in each room.

I want to do it for all zones/rooms with:

Please login or register to see this code.

Perhaps it's wrong because it does't work

If I add before setDim to switch on it switch on but with the previous color setting.

How to correct?

[ChristianSogaard 71]

On 6/4/2026 at 8:31 AM, ChristianSogaard said:

 

If you think this approach makes sense, would you consider adding nextScene/prevScene and dimStep to Yahue?

No pressure of course. I really appreciate the work you put into these QAs.

[ChristianSogaard 71]

Hi Jan,

Small question about Yahue v0.2.62: did the child method toggle() get removed or renamed?

After updating, my external EventRunner/Matrix rules still trigger correctly, but calls like this no longer seem to work:

 

fibaro.call(yahueChildId, "toggle")

turnOn, turnOff, and setValue still appear to exist, so I can work around it by doing my own state check and calling turnOn/turnOff.

Just wanted to ask if this was intentional, or if toggle() should still be part of the child API.

Thanks again.

[jgab 2,644]

46 minutes ago, ChristianSogaard said:

Hi Jan,

Small question about Yahue v0.2.62: did the child method toggle() get removed or renamed?

After updating, my external EventRunner/Matrix rules still trigger correctly, but calls like this no longer seem to work:

 

fibaro.call(yahueChildId, "toggle")

turnOn, turnOff, and setValue still appear to exist, so I can work around it by doing my own state check and calling turnOn/turnOff.

Just wanted to ask if this was intentional, or if toggle() should still be part of the child API.

Thanks again.

toggle is still there - works for me. Some special kind of light?
Do you still see event logs in the console? The event listener may have stopped?

For roomzone QAs there is a nextScene and prevScene commands implemented in 0.2.65

[Sjakie 156]

Jan,

For my grandchildren (and myself) I do:

Please login or register to see this code.

Can I do something similar with NextScene?

Also possible to start randome?