Hue scene follow a switch

Can one use transformation on channels with the follow profile?
I have been searching my heart out, but I can’t seem to figure out if it’s possible. So in each room, we have 4 different buttons for 4 different scenes, which leads to more than 50 rules just for the scenes. For example 1 scene rule:

First of all, is this causing any performance hit? I’ve moved from using OpenHAB 2.5 with Node-Red to combine it all in OpenHab 3.2 and I feel like it’s just a tiny bit slower now.

Second, I’m currently having a brightness of a room follow a dimmer button, so if the dimmer is set to 57% this is forwarded to the room using follow. It works beautifully. So I’m now investigating, if I can somehow use a follow transformation profile for the buttons to their respective scenes in hue?
Eg. the profile should, instead of ON => ON, send ON => k1lBjpxUFZ3FbRK. Is this possible, so I can remove the majority of all my rules?

I have been looking at this, but that would just lead to the same amount of profiles instead of rules. Are “transformations” the correct path for me to dig into? Or are rules the correct approach?

PS. everything is done in the UI.

Hopefully someone can point me in the right direction. Thanks!

Profiles work exclusively on the links between a Channel and an Item.

Not with the follow profile and it’s not clear if we are talking about Items or Channels here either. The transform profile can work to translate but it translates from the Channel to the Item, not the other way around.

Sometimes the bindings have a way to apply a transformation but I don’t know if Hue does.

I bet Rules are the best approach but you would benefit from taking the next step from creating simple codeless rules in the UI and move up to Script Actions. You could probably do it all in one rule instead of the 50.

Doubtful unless all 50 are trying to run all at the same time. There might be a measurable increase in the amount of RAM but I doubt even that.

Thank you for the quick reply! :slightly_smiling_face:

I have considered this using switch case in Java – is this what you are referring to? So one would need to add all the buttons to the trigger and then in the javascript filter on event.itemName?

I have been playing around using Xms256m and Xmx512m (running in Docker on a Synology), but from the very limited testing I have done so far, I only see a memory increase and not really a performance increase. Would memory increase theoretically mean better performance/less garbage collection?

After 10 minutes of uptime:

Current Memory usage on container is 600MB. Before setting Xms and Xmx using no JAVA_OPTS, that was around 170-200MB.

Something like that but you could be more clever than that depending on which language you want to write the script action in and how clever you want to get. Other options are included at Design Pattern: Encoding and Accessing Values in Rules though note that’s an old tutorial I’ve not updated yet and not all those options are available in the UI.

I would probably use the Item name approach or the Item Metadata approach.

What I meant was having 50 rules would require a tiny, perhaps unmeasurable, more RAM than having just the one rule. In other words, there is no meaningful performance impact to having the 50 rules.

The default Xms and Xmx settings are fine. And I think the Xmx setting causes Java to go out and grab that amount of memory when it starts up.

1 Like

Thank you! I have found that individual rules are the most convenient and reliable, and to be fair, good performance. Dropping the Xms and Xmx adjustments also seem to have made a slight difference, but with absolutely no proof :smile:

Now that we are in the “performance” category and “Follow” profiles, I have a dimmer setup in the Niko Home Control Binding with a brightness channel as well as a room (group) in the Hue Binding with a brightness channel.

I have configured the brightness channel of Hue to follow the brightness channel of Niko. It works perfectly, if one does simple changes, from lets say 20->80% brightness. But once you starting using the dimmer slider and drag it from 20->80%, means that the channel is rapidly updated with new values in between. The first few changes are alright, but then that delay starts increasing to the point where changes can take up to 10 seconds to reflect on the lights until it catches up. If one uses the slider directly in the Hue app, the brightness changes instantaneously and smooth while sliding. So before I create a separate topic for this, do you believe I should address it as a OpenHAB or Hue Binding challenge?

openHAB is limited in what it can do by the API presented by Hue. For what ever reason, that API is limited and can become overwhelmed if you send it too many commands too close together. It looks like the Hue binding may queue up the commands and prevent them from being sent too close together which results in dropped commands.

Something else that could be going on is that if there is a rule involved here the commands could be coming faster than it takes a rule to process it which results in the commands queuing up and being processed in order. Though you mention you are using the follow profile here so that may not be the case.

Is this referring to an openHAB UI slider? That would be generating commands to an Item.
As you note, Follow profile works off state changes. Commands are not states, so there is another process or two between twiddling UI slider and instructing Hue that you need to unsderstand the flow of.

The slider is a “physical” slider on a touchscreen or in the Niko app :slightly_smiling_face:

So the whole chain of events is driven by the Niko update mechanism. You need to throttle or debounce that? Might be worth looking at your events.log to find a typical sequence.