search

jdomeij / node-red-contrib-node-lifx

Node RED nodes for controlling Lifx lights
Apache License 2.0
7 stars 9 forks source link

Mode switching issues #3

Closed cakefornoreason closed 7 years ago

cakefornoreason commented 7 years ago

Knowing that the root level of the message contains some important info, I've been playing with that and noticed some odd behaviors with the mode.

It seems that after I've just deployed a revision in Node Red, the output nodes default to "brightness" mode and don't return the state of the light accurately. For example if I set a bulb to a color using the LIFX app, say a red that translates to HSV [30, 100, 75] and then deploy a revision, the initial message from an output node doesn't seem to know that the bulb is displaying a color. It outputs the V value correctly, but leaves H and S at 0, even though that's not what the light is showing.

It might be related, but if I send a payload to the input node that's just "on" or "off" while the actual bulb is displaying a color, it works properly. If the bulb was set using a Kelvin value in the LIFX app, though, an "on" resets the Kelvin to 2500. This only seems to be an issue when the output node shows the "brightness" mode. If I've sent a message that has made it change to the "Color" mode, the "on" command works as expected.

Both seem tied to the fact that the node knows perfectly well when the mode changes within Node Red, but they don't seem to know when the mode has changed via the LIFX app or the bulb has been modified by any app outside of Node Red. It's all fine if the new values fall within the node's current mode, but it gets weird if that mode is changed.

I'm not sure if my description makes sense, but can you replicate this kind of thing or do you think it might it be something about my usage?

jdomeij commented 7 years ago

Yes is see where the problem is, I have begun to remove the mode flag because it doesn't make sense for the Lifx lights because they can control temperature and color independently. Testing the app I see that when switching from temperature to color mode the temperature value of the light is kept, the app only sets the saturation to zero when going to temperature mode

The plan is allow control of temperature and color independent, to emulate the app behavior you need to manually set saturation to zero when setting temperature, but then it's up to the user to control it. I still need to add some capability information for each light

jdomeij commented 7 years ago

I've pushed out an change that removes the mode flag and add capabilities instead (added to root node), I only have original Kickstarter lights so I don't know if this works on other types of lights.

cakefornoreason commented 7 years ago

It happens I was already at my computer when you updated, so I gave this a try. I have Gen 2 lights and perhaps there's some difference, as it worked fine before, but now it's doing some odd stuff. The status indicators for each light used to behave normally, but now they seem to randomly hop around.

The only thing I've noticed so far that might be useful is that an output node that previously sent messages from only the designated light is now sending messages that it labels as coming from others, though the actual numbers in the payload appear to still be coming from the designated lights.

I've attached a video and a couple of photos to show what I mean. img_0479 img_0478 IMG_0477.MOV.zip

jdomeij commented 7 years ago

Hmmm I have no idea whats happening, but I looked over the changes and noticed some timing issues which I pushed out an fix for. This behavior shouldn't depend on which model it it, one limitation of the solution is that everything is wiped on deploy which means that it will need to query each light for information, I only have two lights in my setup so I probably don't get the same problem.

jdomeij commented 7 years ago

Think I found the problem, the initialization check in the setReachable function was wrong. I hacked together an simple node-lifx emulator so i could simulate large amount of lights with different state

cakefornoreason commented 7 years ago

Hmm... I tried it after the update you made yesterday and the flickering status indicators from the video had stabilized. Just tried the new version from this morning, though, and now Node Red won't start:

8 Jan 09:26:13 - [red] Uncaught Exception: 8 Jan 09:26:13 - TypeError: Cannot read property '0' of undefined at LightItem.getColors (/home/pi/.node-red/node_modules/node-red-contrib-node-lifx/lib/lifx-light.js:532:26) at LightServer.statusUpdateLight (/home/pi/.node-red/node_modules/node-red-contrib-node-lifx/lib/lifx-server.js:167:24) at light.initialize (/home/pi/.node-red/node_modules/node-red-contrib-node-lifx/lib/lifx-server.js:149:10) at lifx.getState (/home/pi/.node-red/node_modules/node-red-contrib-node-lifx/lib/lifx-light.js:148:5) at Client. (/home/pi/.node-red/node_modules/node-lifx/lib/lifx/light.js:206:5) at Client. (/home/pi/.node-red/node_modules/node-lifx/lib/lifx/client.js:355:26) at Array.forEach (native) at Client.processMessageHandlers (/home/pi/.node-red/node_modules/node-lifx/lib/lifx/client.js:341:24) at Client. (/home/pi/.node-red/node_modules/node-lifx/lib/lifx/client.js:178:12) at emitTwo (events.js:106:13)

Does that error log suggest a code issue or do you think it's something in my setup?

cakefornoreason commented 7 years ago

It have been something in my config. I cleared out and rebuilt my flows and I can get Node Red to launch again, but the flickering status indicators are back. It also seems as though commands sent to the bulbs are having some trouble. Not all of them seem to go through and the ones that do are delayed by several seconds when that wasn't an issue before.

I'm also seeing it tending to report to an "on" status at 0% brightness frequently, if that helps point to the cause.

jdomeij commented 7 years ago

Hmmm it shouldn't crash there, I have pushed out another version that where I added more error checking and cleanup the initialization. I noticed two problems, first the initial reachable state was incorrect set if the light was in the off state, poll interval was hardcoded to 500ms.

cakefornoreason commented 7 years ago

Those fixes seem to have worked, as the status detection is back to working properly for me!

The only issue I'm still seeing is related to the color/kelvin thing. If the bulb is already displaying based on kelvin and the node gives a kelvin command, it works properly. If the bulb is displaying a color, though, a kelvin command usually makes no change. A couple of times when issuing a kelvin command to a bulb showing a color, I've had it lighten the color to a 0 or 1% saturation without changing the hue or brightness.

Looks like you've almost got it nailed, though!

jdomeij commented 7 years ago

This is the expected behavior, the temperature color is independent of the light color, if you toggle between 3000 and 6000 kelvin you should notice that the color change even though you have set an color. This is because the lifx light can control the color temperature independent from the rgb color.

When selecting an temperature in the app it automatically sets the saturation to zero, I was thinking of doing the same but I though it would be nice to let the user choose.

cakefornoreason commented 7 years ago

Ah, okay. I see what you mean. Because of the approach in the LIFX app and in other LIFX nodes I've used I hadn't thought of it working that way. It's only a couple of additions lines of code, though, so that seems easy enough.

Thanks again for being open to feedback on the code--I sincerely appreciate your sharing this and I'll be looking forward to trying to implement this in my setup!