search

Supergiovane / node-red-contrib-knx-ultimate

Control your KNX intallation via Node-Red! A bunch of KNX nodes, with integrated Philips HUE control and ETS group address importer.
https://youtu.be/egRbR_KwP9I
MIT License
141 stars 34 forks source link

"DIM/Brightness" inaccessible at some bridges #322

Closed willchr closed 6 months ago

willchr commented 6 months ago

Hi,

I'm using 3 Bridges, with same age and identical software-version, each for 1 level of my house.

Depending on which Bridge I configure in the node, the "Dim/Brightness"-part is either accessible for all dimmable lights/groups of this bridge, or for none.

It seems not to be multi-bridge-issue, because I deleted all bridges except one of the two with the disabled brightness button. The result was the same, still no brightness/dim-function .

All lamps and the bridges themselves are at the newest software version. Knx-Ultimate as well. ( 2.3.5)

Node-Red runs within an IO-Broker-Enviroment on a VM in promox.

I also did restart node-red and IOBroker already.

I think, its a bug, but if not, please give me a hint how to solve this issue.

best regards Christian

willchr commented 6 months ago

UPDATE: If I first delete alle bridges, then restart the node-red-instance (important) and then insert any of the three then the lamps of the first configured bridge have the dim-functionalities, all other bridges not.

Then it seems to be, contrary to my first post, a multibridge-issue after all.

Supergiovane commented 6 months ago

Hi Everytime you do a full deploy, knx-ultimate will reconnect to KNX bus and to the HUE bridge. Then, it reads the capabilities of all your lights, to enable/disable parts of the GUI. For example, if a lamp has no color capability, the “color” tab is disabled. This process takes some seconds to be fulfilled (about 20 seconds). You should wait until the HUE node status changes from “waiting” to “ready”. Does you issue appears soon after you deploy the flow, or does it appears independently from deploy?

willchr commented 6 months ago

Hi,

thank you for answering.

Let me describe my approach and observation:

1.) Inserting a new Hue Light Node 2) choosing KNX gateway (no Hue bridge defined so far) 3.) adding/connecting a new Bridge "A". ( I leave the Name field in the PhillipsHue section below empty for now) 4) Full deploy Observation: The node status at the bottom of the node changes from "waiting" to "initialize-please wait" after approx. 10 seconds. This status no longer changes (I waited approx. 5 minutes). However, the lights/groups can now already be selected in the configuration area of the node. 5) I select an RGB light - click on "DONE" 6) Observation: The node status at the bottom edge of the node remains on "initialize-please wait". (I have waited approx. 2 minutes). 7) Full deploy Observation: The node status at the bottom edge of the node changes from "waiting" to "initialize-please wait" after approx. 10 seconds and then to "READY" after a further 5 seconds. Dimming can be configured in the node as it should be.

INTEGRATING SECOND BRIDGE:

8.) Inserting a new Hue Light Node 9.) choosing KNX-Gateway and deselecting Bridge "A" 10.) adding/connecting a new Bridge "B". ( I leave the Name field in the PhillipsHue area empty again for now) 11) Full deploy Observation: The node status of "B" remains at "initialize-please wait". The lights/groups of "B" can be selected correctly again. 12) I select an RGB light - click on "DONE" 13) Full deploy Observation: The node status of "A" and "B" BOTH change after approx. 10 seconds from "waiting" to "initialize-please wait" and another 5 seconds to "READY". In node "A", dimming can be configured as it should be; in node "B", dimming, color temperature and light color are NOT selectable.

The same behavior can be observed if you swap both bridges, i.e. first integrate "B" and then "A". The luminaires/groups of "A" are then not dimmable.

Does that answer your question a bit?

Supergiovane commented 6 months ago

Hi Christian Thank you! Please leave me some time to check that, as i'm currently in Holiday. In the meantime, please setup all the things as you want but, instead of full deploy, do a partial deploy everytime. In this manner, node-red will start only the changed nodes. Generally speaking, and as a suggestion, doing a full deploy force all nodes to restart and it's not good to restart the whole node-red while setting up your automations. I recommend to do a partial deploy everytime.

Node-RED___192_168_1_16
willchr commented 6 months ago

Thank you Massimo, will follow your hint.

After deploying with "deploy modified nodes" a new hue-light-node gets the different status "I am new and ready". The dim-sector however is still disabled.

Have a nice holiday and thank you again for addressing my issue.

willchr commented 6 months ago

I don't know if it its helpful or not.

After Connecting Bridge "A" ( works fine) and then "B" (dimming is not available) I deleted "A" ( the configuration-node) again and observed, that "B" is still not dimmable although its the only bridge then.

Just the first connected bridge after removing all bridges is dimmable.

Supergiovane commented 6 months ago

Hi Christian are you able to test a beta version? Are you skilled enough, to revert back to a previuos version if the beta doesn't work well? (for that, you need to enter the .node-red/ folder and do a npm install node-red-contrib-knx-ultimate@2.3.5 command). If yes, please update to node-red-contrib-knx-ultimate@2.4.0-beta.0

Supergiovane commented 6 months ago

Hi Christian have you tried installing the 2.4.0-beta.0? You must do that by issuing the command npm install node-red-contrib-knx-ultimate@2.4.0-beta.0 in the .node-red/node_modules folder.

willchr commented 6 months ago

Hi , sorry for my late response. I will check this out today evening and will come back to you.

Gesendet von Outlook für iOShttps://aka.ms/o0ukef

Von: Massimo Saccani @.> Gesendet: Monday, January 15, 2024 4:08:43 PM An: Supergiovane/node-red-contrib-knx-ultimate @.> Cc: Christian Will @.>; Author @.> Betreff: Re: [Supergiovane/node-red-contrib-knx-ultimate] "DIM/Brightness" inaccessible at some bridges (Issue #322)

Hi Christian have you tried installing the 2.4.0-beta.0? You must do that by issuing the command npm install @.*** in the .node-red/node_modules folder.

— Reply to this email directly, view it on GitHubhttps://github.com/Supergiovane/node-red-contrib-knx-ultimate/issues/322#issuecomment-1892348688, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ADXW7JHWOYD7RCIGQ3OQGMTYOVA7XAVCNFSM6AAAAABBY5LNIKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJSGM2DQNRYHA. You are receiving this because you authored the thread.Message ID: @.***>

willchr commented 6 months ago

after the install node-red crashed while initializing the flows. Will restore the VM, then deactivate the knx-ultimate flows first, then upgrade then will try to successfully activate single knx-ultimate-node step by step

willchr commented 6 months ago

Thank you Massimo, it works.

The crash came from installing into the wrong directory, my fault. I have connected a second Bridge and both the dim, color and temperature-options are available. I wont test the functionality tonight, but I assume, it will work as it does with the first bridge.

Thank you for this very quick beta! Now its awesome!!

One additional question: Am I right to think, "the smaller the configured dimming-speed ( I am testing with 1500ms), the quicker the commands to the bridge and therefore the higher the load for the bridge"? So maybe might makes sense to don't define the dimming-speed not too small?

Thank you again, I am very happy :))

Supergiovane commented 6 months ago

Am I right to think, "the smaller the configured dimming-speed ( I am testing with 1500ms), the quicker the commands to the bridge and therefore the higher the load for the bridge"? So maybe might makes sense to don't define the dimming-speed not too small?

Yes, you are right. Usually, a dim speed between 5000 and 10000ms is fine.
I use 10.000, but it’s my own taste. Anyway, the node handles the HUE commands in a queue, by limiting the maximum command per second, the hub permits.