Hue "tubable white" feedback and persistence

[evazzoler]

Hi, I noticed that white temperature values are not sent back on the bus (on the tunable white status GA) like happens for dim values. Is this wanted, do I make something wrong or is it a bug?

I see that dim value is not remebered between on/off cicles as happens with hardware KNX dimmer modules. The plugin should also remember the DIM and RGB values before OFF and restore it at ON, aka "persistence". Is there a way for doing that (and I'm wrong in something) or should I put it in a feature request?

[Supergiovane]

Hi, i’m sorry to inform, that my father has passed away today. I’m unable to work. I’ll take a look at that, but not now. Please play with the node and then tell me if there is something i must do. Thanks!

[evazzoler]

Se ieri sono rimasto basito dalla velocità e l'immediatezza, oggi resto basito per questa terribile notizia. Non posso che esprimere insieme alla stima e alla gratitudine, il mio cordoglio. Mi dispiace veramente tanto!

[Supergiovane]

Grazie di cuore.

[evazzoler]

Take your time, I write today only for not forgetting what I did last night.

My Vimar and MDT KNX input devices have only one dimmer object (dim+, dim- and stop dimming) then switch on/off (toggle) and boolean switch state for toggle.

"Behaviour section":

"Link color/bright to on/off switch" set to YES

• light always turns on immediately at the default indicated value, no dim/white value persistence
• if I leave the RGB field blank, it is reset to the default ( { "red": 255, "green": 255, "blue": 255 } ) when I hit "done" button

"Link color/bright to on/off switch" set to NO

• light turns on/off with a random delay (0.5-3 seconds)
• the node remembers the white value but forgets dim value between on/off cycles
• the light turns on at minimum brightness value
• while dimming, dim value is periodically sent to the configured GA, white value isn't

Looking at the KNX bus log I noticed that if I turn the light OFF from the HUE app or HUE remote, the node is OFF updated and will send a ON remembering the dim value, I don't see dim percent messages on the bus while fading. When I turn OFF from the node, the OFF fading sends dim percent messages on the bus, so I suppose it is an "artificial dim/fade" to the 0% value. So I suppose because the last value is 0%, the node will remember 0% as last used value (the end of the fading value instead the start of the fading value).

Regarding the delay, I don't know which is its origin. Regarding the dim, on the node side I would try to save the value before the fading when a off command is sent. BUT... With Philips it shouldn't be necessary to "artificially fade" because the fading is device-embedded. I see that in the same system, original Philips always fades off and non-original (i.e. Innr) immediately cuts the light.

[Supergiovane]

I see that dim value is not remebered between on/off cicles as happens with hardware KNX dimmer modules. The plugin should also remember the DIM and RGB values before OFF and restore it at ON, aka "persistence". Is there a way for doing that (and I'm wrong in something) or should I put it in a feature request?

With "Link color/bright. to on/off switch" set to No, there is currently an issue with the HUE App. Switching the light ON and OFF via the API, the brightness value is not set as previous. The HUE App correctly shows, for example, "100%", but switching on and off the light via the Hue App, causes the light to turn on at the lowest brightness value possible ("1%"). Only after several seconds, the HUE App returns to behaving normally. This is not the intended behaviour and i'm investigating how to overcome such issue.

[Supergiovane]

Ciao Enrico poiché non riesco a elaborare correttamente ciò che hai scritto (mi dispiace, ma al momento ho il cervello annebbiato), puoi aprire una nuova "issue" e in cui chiedi semplicemente cosa vuoi che faccia il nodo HUE Light? Il più semplicemente possibile per favore :-) Attualmente è impostato per comportarsi come il dispositivo "ISE Connect HUE", ma capisco che i ragnetti/ingressi KNX, si comportano spesso ognuno diversamente dall'altro. Devo mantenere la finestra di configurazione del nodo il più semplice possibile, ma sono disposto a inserire opzioni avanzate, in cui è possibile ottimizzare il nodo, per soddisfare meglio le esigenze personali di ognuno.

Hi Enrico as i cannot correctly elaborate what you wrote (sorry for that, but i'm currently in a foggy-brain condition), can you open an issue and simply ask what you want the HUE Light node to do? Currently, it's set to behave like the "ISE Connect HUE" Device, but i understand that there a lot of different KNX input behaving differently. I must keep the node configuration window as simple as possible, but i'm willing to put advanced options, where you can fine tuning the node, to better suit everyone personal need.

[evazzoler]

Ok, I don't want you to think about that at this bad time... So, because I own a ISE Connect Hue I wanted to leave in the drawer, I will install it, try with my input devices and report, if !null || !undefined, what ISE does and I cannot reach with the node. In summary, I need to turn on the light or light group at the same brightness and colour it was before I turned it off. If this is possible today, I'm doing something wrong with my inputs (but I use the only one setting possible: dim with one button).

[Supergiovane]

Hi If you disable the Link color/bright. to on/off switch option, it should work exactly as you want. I will try again tomorrow. Do you maybe have the ISE still connected to the bus? If yes, please turn it off.

[evazzoler]

With the flag disabled it turns always on at 1% cold white. My ISE was never unboxed.

[Supergiovane]

Yes, like mine. Basically, by unlinking that option, i send only the command “switch on/off” to the hue bridge. The bridge retains an object for every light, containing the light status, including all the % for every property and, as for the API standards, it applies to tue light the last values of rgb, hsv, brightness, etc. In the HUE API documentation, it’s clearly indicated, not to send redundant values to the light, because the object representing the light, already retains all properties. The node itself doesn’t retain any value. Prior to the latest bridge firmware update, all was working correctly.

[Supergiovane]

Comunque, domattina ho il funerale, nel pomeriggio ci do di nuovo un’occhiata.

[Supergiovane]

Mi serve anche per distrarmi un po’.

[evazzoler]

Ok, ma non sentirti obbligato. Io non ho urgenza e in quella casa ci devo ancora traslocare. 🙂

[Supergiovane]

Hi node-red-contrib-knx-ultimate@2.1.51 it out. Please try it and let me know.

[Supergiovane]

Hi Enrico Have you tried using the new version 2.1.51?

[evazzoler]

Hi Enrico Have you tried using the new version 2.1.51?

Hi Massimo, no, I was away from home this weekend. Tomorrow I'll deep test the new version and keep you updated. Thank you!

[evazzoler]

Tested! This is the behaviour with "Link color/bright. to on/off switch" set to OFF:

• With single lamp it remembers bright. and white between cycles, as expected
• With group lamp (grouped with zone funcion in Hue app) it always start at minimum brightness

I used "zones" because my "ufficio" room has several lamps but I want to control only some lamps with one switch. The main lantern in this room has 3 lamps (for lumen reasons... I will always use them as they are one single lamp), so I have:

• "Ufficio": the whole room, the 3 lamps of the lantern + other 2 lamps
• "Lampadario ufficio": 3 lamps on the main lantern (contained in the room and containing the 3 lamps)

So, those are the cases:

1. If in the node I select one of the 3 lamps (i.e.: "Lampada Ufficio A") I control it as expected (persistence is OK)
2. If in the node I select the "Lampadario ufficio" group (it is a Zone, not a Room!) persistence don't work
3. If in the node I select the "Ufficio" group (it is a Room) persistence don't work

Via hue app persistence always work.

My input dim works this way:

• if status is off, long press always sends 100%+ / $09 (it is a 3.001 increment, not an absolute value), when I release it sends a break $00
• if status is on, long press sends alternate by release 100%+ / $09 and 100%- / $01, when I release it sends a break $00
• short press is a normal toggle with 1.001 on and off

I hope this helps you investigating! Ciao!

[Supergiovane]

Yupp… you’re right. Tomorrow i’ll take a look at zones and rooms as well.

[Supergiovane]

Hi Enrico The issue with grouped light/zones should have been fixed. Please try the node-red-contrib-knx-ultimate@2.1.52 and let me know. If it works, i'll move on to fix the DIM direction. I must proceed step by step, because my brain are still foggy.

[evazzoler]

Hi Enrico The issue with grouped light/zones should have been fixed. Please try the node-red-contrib-knx-ultimate@2.1.52 and let me know. If it works, i'll move on to fix the DIM direction. I must proceed step by step, because my brain are still foggy.

Yahoooo! Bingo! 10 e lode!

"Ma ditemi in sostanza se c'è qualcuno che affronti il governo e i matusa con grinta e simpatica verve come quel matto di Supergiovane" [Cit.]

In other words... It works! I don't close the issue because you are referring to a DIM direction issue I didn't reported. I had a couple of direction issues, but I think it was a nework problem, becase after a while they disappeared.

[Supergiovane]

Hi Enrico I'm even younger than Mangoni. Glad it works. The DIM directions automatically sync after the first DIM command. If it's not a problem for you, i close this issue. Please let me know if you find other problems. Thanks.

[evazzoler]

Not a problem for me! It works and I appreciate it! If you love "elegance" and want the node to behive like a real dimmer and ISE, you can leave this issue open with low priority or open a new feature request with low priority. Thank you so much!

[Supergiovane]

The DIM messages are handled correctly, with start and stop telegrams, but the increase/decrease step is not taken into consideration, it's fixed. I must investigate, how the ISE handles the step.

[evazzoler]

Only one think: I noticed you have a disk space for the palette. Would be wonderful if hue persistence would be saved on the disk (i.e. every minute as the global file variables do for not r/w to much the disk). This way persistence would survive to Node Red reboot/deploy... Actually if I'm developing a node and redeploy every 10 minutes, everytime I deploy I reset every lamp to its minimal brightness... A fast workaround would be to set max brightness as default value after redeploy.

[Supergiovane]

Hi Enrico. This problematic behaviour has started to appear recently. Some weeks ago, the HUE bridge was correctly retaining all previous values. I think, with the introduction of Matter, something wrong has happened. While using the Hue App, this is unnoticeable, because the app retains itself the previous values. At start, the node asks every hue device to send the properties/values and stores it in a JSON variable. Having the HUE Bridge not retaining some values anymore, your suggestion to use persistence file is a clever one.

[evazzoler]

Honestly I have a doubt about app retaining values... App and Vimar "Friends of Hue" piezo switches are always synced (with app closed or not), so I suppose that value retention is located only into the bridge.

[evazzoler]

Hi, unfortunately the problem of always finding the lights at minimum brightness after restarting node red is becoming unbearable for my family... Today I discovered that if I turn off and immediately on a light, it remembers the brightness. If I wait about a minute, often (about 1/15) it turns on at minimum and cold white..

[Supergiovane]

Hi Enrico, you're having too many issues. There is something wrong somewhere. Do you have more than one node, controlling the same light?

[evazzoler]

POC = proof of concept

No, I have only one node per light (or group) with one GA for the command and a different one for the state. At the boot of node red, KNX Ultimate ask every GA state on the bus.

[Supergiovane]

I nodi di cui dici che la luce si accende all'1%, sono tutti con l'opzione Specify switch on brightness disattivata? Scusa ma sono stanco, è una settimana che giro per pompe funebri, comune, commercialista... non ho voglia di pensare a come scrivere in inglese.

[Supergiovane]

Hi Enrico. Can you test the node-red-contrib-knx-ultimate@2.1.57 The issue with brightness value should now be fixed.

[evazzoler]

I nodi di cui dici che la luce si accende all'1%, sono tutti con l'opzione Specify switch on brightness disattivata? Scusa ma sono stanco, è una settimana che giro per pompe funebri, comune, commercialista... non ho voglia di pensare a come scrivere in inglese.

Sì, tutti i nodi avevano quell'opzione disattivata.

[evazzoler]

Hi Enrico. Can you test the node-red-contrib-knx-ultimate@2.1.57 The issue with brightness value should now be fixed.

Sure! Tomorrow I will do an intensive testing. Thank you for the release! In the meanwhile a question: why "night mode" disappeared for lights that before had it available?

This is a GU10 spot over the WC, intended to use at night. Night mode is its purpose... ;-)

[Supergiovane]

It should be there. Try scrolling down. Or try to clear browser cache (or use incognito mode).

[evazzoler]

Ok, it remembers correctly the latest values when switching on/off.

It remains the node red reboot/deploy behaviour: if I turn on with app after the reboot/deploy, it remembers the values, if I turn on from KNX, it turns on at minimum. I think the node fails to ask and obtain from the bridge the latest values of the lamp when the node is initialized.

[Supergiovane]

Hi Enrico Yes, i'm going step by step. I have limited time. Upcoming version (out in minutes) has a color picker helper. I'll try to fix your issue (reboot) in the upcoming version as well ;-)

[Supergiovane]

Hi Enrico I'm not able to reproduce your issue. Upon Node-Red restart, the HUE nodes, read the state from HUE Bridge. This takes some time, because the HUE Bridge allow a limited number of telegram per second. Upon restart, please wait until you see a status under the node, stating that the node is connected (you should see a blue rectangle). Then try to switch on the light.

[Supergiovane]

node-red-contrib-knx-ultimate@2.1.59 is out. Please do what i told you (wait..before reboot) and let me know Ciao!!

[Supergiovane]

Hi Enrico many fixes on new 2.2.0 version, out now. If you have other issues, please feel free to write!

[evazzoler]

Hi, sorry for the delay, I was really busy... And I'm almost back today. I always made tests after the node reached a status. The result of the release is a regression for me: with Specify switch on brightness to off it always turns on at minimum. Nothing changes changing the "KNX Brightness Status" setup. But... I notice a "NaN" status for zones. Maybe something wrong in recovering zone/group status?

Please, let me know if you can reproduce that on zones!

Another tick: please, move back night lighting outside the condition Specify switch on brightness set to yes. I need (and think this is a normal behaviour) the light rembers the settings I leaved it during the day, but turn on in different way at night. Currently I can specify "night mode" only if I choose "day mode", but may and should be separate.

Thank yoy!

[Supergiovane]

Hi on what version are you? The last ist 2.2.2

[evazzoler]

Hi on what version are you? The last ist 2.2.2

Ops... I upgraded yesterday night and tested today. In the meanwhile a release came... It was 2.2.1, now I upgraded to 2.2.2. Night mode is back as separate, thank you!

Unfortunately the zone state is still "NaN" and the zone always turns on at minimum brightness.

[Supergiovane]

Unfortunately the zone state is still "NaN" and the zone always turns on at minimum brightness.

On a grouped light, right?

[evazzoler]

Unfortunately the zone state is still "NaN" and the zone always turns on at minimum brightness.

On a grouped light, right?

They are grouped with the "zone" concept.

[Supergiovane]

I'm working on that...

[Supergiovane]

Hi please check it again with version 2.2.3 and let me know if it solved your issue. Thanks

[evazzoler]

Great! Clapping hands! Now it works as expected. It remains one issue to fix: if I set "KNX Brightness Status" as "Leave as is", that zone will not connect. If I change that setting, the light connects immediately. This is the situation after 5 minutes:

[Supergiovane]

Hi Enrico, it could be a wrong status. The new version that i'll post this evening, does fix that.

[Supergiovane]

Hi v. 2.2.4 is out. Check it out. You should haven't any problem more (at least discussed here).