LifX Binding enters race condition of some sort. Causes LifX bulb(s) to flicker

I am using OpenHAB 2 (v4.1.3) with very minor configuration. I’ve added the LifX Binding while connected to a network with pre-existing LifX bulbs. I also added the MQTT binding with a Mosquitto broker. I am using Google Chrome’s extension “MQTTLens” and subscribed “#” to see all the messages come across.

Now, when I change the brightness the following occurs where “LIFX22E22D_Color” is configured from the configuration file ‘/conf/services/mqtt-eventbus.cfg’ using “${item}” as suggested here: https://docs.openhab.org/addons/bindings/mqtt1/readme.html

  1. I used the PaperUI to set the brightness one time to somewhere between 25-30%.
  2. In the MQTTLens application, I can see OpenHAB send out requests to set the brightness level to 27 and then to 28% back and forth forever until I “logout” of the OpenHAB runtime.
    2a. This leads to hundreds of thousands of messages really fast and hinders my OpenHAB runtime from operating in a reasonable amount of time.

Please attachment to see the effects of changing brightness of LifX bulb just one time.

Note: I’ve never contributed to OpenHAB before, nor do I know how to at this time. I’m a noob.

I’m hoping to receive feedback from either LifX Binding folk(s) and/or MQTT Binding folk(s). I can’t see the messages (with my current setup and knowledge of the system) without the MQTT binding.

Note: The offending bulb(s) only flicker if I play with their settings within this instance of the OpenHAB runtime. It appears to continue until I bring down the whole runtime and restart it.

When posting textual information such as configurations, never post an image. It’s useless. Paste the text itself or attach it as a file.

If pasting, place the pasted text between code fences.

The MQTT configuration is hardly of importance here. How do I find out who can help me with bugs in the LifX binding?

I should mention, I’ve pared back my metatags to include only LifX.

You’ve just discarded the help of one person. Why should anyone else try to help you?

I apologize if I’ve upset you by not fulfilling your request. But I would hope you can still help me out of the kindness of your heart?

I’ve pared back the problem. Even without MQTT binding installed, sending a request to a LifX bulb causes it to flicker. The attachments above are for MQTT usage only and are no longer relevant as the problem persists without MQTT. I can edit the original post and remove those attachments, or leave them so folks can follow this paper trail in case they have similar issues. I defer to your judgement.

There is no further configuration I can upload here for LifX. I’ve added the LifX binding with the PaperUI.

Can you help distinguish why usage of the LifX Binding with OpenHAB2 (v4.1.3) Paper UI would generate hundreds of thousands of messages (ie. causes LifX bulb to flicker upon first request to that offending bulb)?

I can’t reproduce your flicker issue but in the past I’ve sometimes seen an issue where Paper UI keeps sending commands. Does the flickering stop when you close all browsers connected to openHAB? What browser do you use and did you try other browsers as well? Chrome is probably the best tested browser.

There is no openHAB 2 v4.1.3. The v4.1.3 is probably the Karaf version used by openHAB.

Can you also test this with the new openHAB 2.3 release candidate?

@wborn

Thanks for this reply.

Does the flickering stop when you close all browsers connected to openHAB?

This did not resolve the barrage of messages.

What browser do you use and did you try other browsers as well?

I was using Google Chrome, but I just tried Safari and the problem persists even after closing the browser.

There is no openHAB 2 v4.1.3. The v4.1.3 is probably the Karaf version used by openHAB.

I retrieved the version information by issuing “version” within the OpenHAB runtime. I see the logo that comes up with the runtime states “2.2.0” now that you’ve mentioned usage of Karaf. (Please forgive me. This is my first time working with Karaf.)

Can you also test this with the new openHAB 2.3 release candidate?

I will let you know how this goes.

I have also ordered some Philips Hue bulbs to test with in a few days as well. I have no other devices to test with at this time aside from the LifX bulbs.

@wborn

Can you also test this with the new openHAB 2.3 release candidate?

Using “OpenHAB 2.3.0.RC1 Milestone Build” I am receiving same operation. It is still generating thousands of messages.

I have just found this logging page. I will review and post any novel messages.

I have found the culprit. I guess I’ve never successfully removed MQTT as a binding when I “pared” back the problem.

There was a feedback loop in my MQTT configuration. Which goes to prove I should’ve kept with the MQTT configurations earlier.

I was able to remove the MQTT binding in the Paper UI, then only set it in <openhab>/conf/services/addons.cfg. I was able to verify whether MQTT binding was installed or not through review of logs. I issued the following command in the OpenHAB runtime to view the logs and verify binding states:

openhab> log:display

I hope others don’t make the same mistake of subscribing and publishing to the same topic in their MQTT configuration(s). For those interested, this is the WRONG configuration for “<openhab>/conf/services/mqtt-eventbus.cfg”:

broker=mosquitto
statePublishTopic=/openHAB/out/${item}/state
commandPublishTopic=/openHAB/out/${item}/command
stateSubscribeTopic=/openHAB/**out**/${item}/state
commandSubscribeTopic=/openHAB/**out**/${item}/command

And this would be an example of a valid version:

broker=mosquitto
statePublishTopic=/openHAB/out/${item}/state
commandPublishTopic=/openHAB/out/${item}/command
stateSubscribeTopic=/openHAB/**in**/${item}/state
commandSubscribeTopic=/openHAB/**in**/${item}/command

Thanks!

Great that you’ve found the feedback loop @Joey_Morrow! :slight_smile:
I’m not using MQTT with openHAB myself yet but I’ll take great care with this in mind when I start using it.