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

[jgab 2,651]

Ok, the parse error could actually have been a problem that caused 429 in other scenarios too.
I uploaded v 0.2.66 with some fixes I hope will improve it - including allowing for better performance.

[Sjakie 156]

Jan, after update v02.66 I have only warnings, so Yahue works great!

Please login or register to see this code.

Can I perhaps solve a few warnings?

[jgab 2,651]

15 minutes ago, Sjakie said:

Jan, after update v02.66 I have only warnings, so Yahue works great!

Please login or register to see this code.

Can I perhaps solve a few warnings?

The "Missing resource type:xxx" is no problem, just a reminder that these Hue resources are not supported.
The "Variable sseHeartbeat not found", I have made silent.

"Class does not have 15 function defined - action ignored" is very strange. I made some changes in the last version, please report if you still get the warning-

[Sjakie 156]

After update and extra restart:

Please login or register to see this code.

 

[jgab 2,651]

The restart was unexpected, try version v0.2.68 I just uploaded.

 

[Sjakie 156]

Please login or register to see this code.

 

vo.2.68

[jgab 2,651]

22 minutes ago, Sjakie said:

Please login or register to see this code.

 

vo.2.68

Yes, that's better. The missing resource warnings will be there.

Edited Friday at 10:00 AM by jgab

[Finzzownt 0]

4 hours ago, jgab said:

Ok, the parse error could actually have been a problem that caused 429 in other scenarios too.
I uploaded v 0.2.66 with some fixes I hope will improve it - including allowing for better performance.

Thank you very much! I will try v0.2.68 today and let you know.

[Finzzownt 0]

@jgab First test: works. I'll test it this evening, maybe the Hue motion sensor gives off different events or data, I don't know.

During daylight I see no errors in the console and the Controller click successfully controls the Hue light via YahueV2, even after having passed the motion sensor multiple times.

[Flexo 0]

Thanks for the QuickApp - it works perfectly with the HUE lamps.

 

With the NEUHAUS lamps I can switch them on and off, but I cannot change the light warmth (color temperature). Is this adjustment planned?

 

That would be great.

 

Thanks!

Edited Friday at 07:58 PM by Flexo
Solved.

[ChristianSogaard 73]

On 6/3/2026 at 4:36 PM, jgab said:

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.)

 

Hi Jan,

Thank you for the detailed update.

For the step-dimming API, I would prefer the Fibaro-style approach:

`fibaro.call(id, "stepValue", 5)`
`fibaro.call(id, "stepValue", -5)`

The keypad/controller should handle hold-repeat timing, so I do not think Yahue needs an internal `diminterval` repeat function.

Regarding stopLevelChange, I have not identified a specific failure pattern. My main focus is ensuring reliable interoperability between EV7 and Yahue, so EV7’s level-change and stop behaviour maps cleanly to Hue’s native dimming_delta commands.

The capabilities variable and the scene-stepping additions also look good.

My immediate focus has unfortunately shifted. My HC3 entered recovery mode twice, and I spent nearly two weeks with Fibaro Support trying to identify the cause and prevent it from happening again. I have now given up on that support process and decided to start over instead.

Fortunately, I had saved a substantial part of my rules on my Mac, so migrating the logic to EV7 should be much easier.

Best regards,
Christian