Lights randomly turning on

[jcbbas]

Hello, I have been using AiLight for quite some time, great work! Recently I had an issue with with my router not being able to handle the number of devices connected to it and it would crash. I ended up adding the wifi reconnect timeout and ever since, it seems my lights randomly turn on for a few moments, then turn off. I ultimately replaced my router with more/better equipment so the crashing is no more, but the lights still randomly turn on and off.

This does not seem to be on a consistent basis and looks to be completely random. The WebUI becomes unresponsive when this occurs so I am wondering if they are coming on while attempting to reconnect to wifi for whatever reason. Is there a way to get to the logging on the light? Looking through documentation I unfortunately have not seen a way.

[stelgenhof]

Sorry to hear about the issues you have. Can you share maybe what version of the firmware you are using and what your settings are?

Cheers! Sacha

[jcbbas]

Not a problem! I am not entirely sure the whole issue is with your firmware and not my wifi network at this point. Hoping logs from the lights will help determine that! Version 0.6.1-dev From my config.h file

/**
 * Light
 * ---------------------------
 * Use the below variables to set the default behaviour of your Ai-Thinker RGBW
 * Light. These will be used as the factory defaults of your device.
 */
#define LIGHT_STATE false
#define LIGHT_BRIGHTNESS 0
#define LIGHT_COLOR_TEMPERATURE 0
#define LIGHT_COLOR_RED 64
#define LIGHT_COLOR_GREEN 64
#define LIGHT_COLOR_BLUE 64
#define LIGHT_COLOR_WHITE 0

#define HOSTNAME "Entry1"
#define ADMIN_PASSWORD "password"

#define POWERUP_MODE POWERUP_OFF 

/**
 * LedDriver
 * --------------------------
 * Define type and number of chips used. Allow firmware use with multiple types/designs of lights
 */
#define MY92XX_TYPE MY92XX_MODEL_MY9291
#define MY92XX_COUNT 1

/** 
 * OTA (Over The Air) Updates
 * ---------------------------
 */
#define OTA_PORT 8261

/**
 * WiFi
 * ---------------------------
 * Use the below variables to set the default WiFi settings of your Ai-Thinker
 * RGBW Light. These will be used as the factory defaults of your device. If no
 * SSID/PSK are provided, your Ai-Thinker RGBW light will start in AP mode.
 */
#define WIFI_SSID "wifi"

#define WIFI_PSK "wifi12"
#define WIFI_OUTPUT_POWER 1.0 // 20.5 is the maximum output power

/**
 * Timeout period for the device to keep trying to (re)connect to the configured WiFi 
 * Access Point. If this timeout period has been reached, the device will assume a WiFi
 * connection can not be made and will switch to Soft AP mode.
 */
#define WIFI_RECONNECT_TIMEOUT 60

/**
 * MQTT
 * ---------------------------
 * Use the below variables to set the default MQTT settings of your Ai-Thinker
 * RGBW Light. These will be used as the factory defaults of your device and
 * making the connection to your Home Assistant instance. Most of these settings
 * can also be changed in the UI environment.
 */
#define MQTT_PORT 1883
#define MQTT_SERVER "192.168.1.98"
#define MQTT_USER "mosquitto"
#define MQTT_PASSWORD "password"
#define MQTT_RECONNECT_TIME 45
#define MQTT_QOS_LEVEL 0
#define MQTT_RETAIN true
#define MQTT_KEEPALIVE 30

#define MQTT_PAYLOAD_ON "ON"
#define MQTT_PAYLOAD_OFF "OFF"

#define MQTT_STATUS_ONLINE "online"
#define MQTT_STATUS_OFFLINE "offline"

#define MQTT_HOMEASSISTANT_DISCOVERY_ENABLED false
#define MQTT_HOMEASSISTANT_DISCOVERY_PREFIX "homeassistant"

/**
 * Home Assistant 0.84 removed the "mqtt_json" platform type, replacing it with
 * a combination of "platform: mqtt" and "schema: json". If you are using version 0.84
 * or older of Home Assistant and using the MQTT discovery feature, set the following
 * directive to "true" 
 */
#define MQTT_HOMEASSISTANT_DISCOVERY_PRE_0_84 false

/**
 * HTTP
 * ---------------------------
 * Use the below variables to set the default HTTP settings of your Ai-Thinker
 * RGBW Light. These will be used as the factory defaults of your device.
 */
#define REST_API_ENABLED false

The firmware shows "power_off" as power up mode, but I do have every light configured to use "As before". Looking at my MQTT server logging, it does appear that the light that seems to come on is also reconnecting to the MQTT server, so it could be that the wifi is dropping and the bulb reconnects. I guess the only thing you might be able to address in this whole scenario is why the light comes on at reconnect? Barring any weird MQTT behavior telling the light to come on and go right back off. In either case, if there is a way to view the logs (if there is any) will go a long way here. Thanks for the help btw! This firmware has been rock solid for essentially the entire time I have been using it. About a year now!

[jcbbas]

I also just restarted my MQTT broker to turn up log levels, and upon reboot, all the lights came on and went back off. I am half wondering if I need to change optimistic/retain settings. Odd this was not an issue previously though, so I wonder if its tied to the Wifi Reconnect setting I enabled on all lights recently. Or it could simply be Home Assistant giving me headaches as well, and if that does end up being the case, sorry for bugging you!

[stelgenhof]

Thanks! I try to keep the firmware as clean and stable as possible :)

Can't really see anything wrong from your settings. Debugging might be a bit hard, but what I usually do is hook up a cheap ESP8266 board (e.g. LOLIN) that acts as my test board (before uploading to a bulb). If you open up a terminal (connected to USB) you can monitor the output and logs.

As for MQTT, this could be related but not entirely sure about it. What you can also try is, use the code in the 'feature/mqtt_reconnect' branch: this includes some improved code regarding the connectivity to the MQTT broker.

I will also have a look if the lights are set to 'As before'.

Cheers! Sacha

[jcbbas]

"Debugging might be a bit hard, but what I usually do is hook up a cheap ESP8266 board (e.g. LOLIN) that acts as my test board (before uploading to a bulb). If you open up a terminal (connected to USB) you can monitor the output and logs." I was worried that might be the best /only way! lol Ill give that a shot on the MQTT reconnect code! I did notice in the past they seem to reconnect a lot, just never nailed down if they are dropping wifi or the MQTT broker, hence both reconnect timeouts are actually set. Also setup MQTT explorer so will see if that helps pinpoint the issue at all.

[stelgenhof]

Yeah, connecting the bulb to your PC/USB and to the mains at the same time is not really a good idea :) That's why the ESP8266...

Let me know if you find anything interesting or need more help.

[jcbbas]

Well unfortunately after implementing the code for the MQTT reconnect, I do not see the lights running the code actually connecting to my MQTT broker, so need to figure out what is going on there.

I will say this definitely seems tied to MQTT, every time one of the bulbs reconnect to it, they pop on and turn off. Can watch everything do it at the same time if I reboot the broker.

[jcbbas]

I also should have brought up, I went to run build and got errors trying to download the libraries.

Looking for AsyncMqttClient library in registry ?[33m[API] ConnectionError: HTTPConnectionPool(host='api.platformio.org', port=80): Max retries exceeded with url: /v2/lib/search?query=name%3A%22AsyncMqttClient%22 (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0x000000000544E8D0>: Failed to establish a new connection: [Errno 10060] A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond',)) (incremented retry: max=5, total=1)?[0m

I copied the libraries I had from my dev-ota folder to the others, not sure if that will cause issues. Unfortunately I do not know a lot about development in general, but once flashing it back to the AiLight-develop branch with Prod-OTA instead of Dev-OTA, MQTT functionality returned. Looking to see if I still have the problem, as apparently I didnt realize the I had always been using Dev-OTA.

[jcbbas]

Well odd enough, after flashing the prod-ota of the develop branch.. The odd random turning on is now gone. I can restart the broker over and over and not a single light comes on. I do still see a good chunk of socket errors etc in my MQTT log, but not sure if that is more of my wifi dropping connections or the lights themselves. In either case, they seem to reconnect without an issue. Still interested in your other branch so will maybe try that with one of my extra bulbs. When I get some spare down time.

Thanks again for trying to help me along though!

[jcbbas]

So this went away for quite a while, and I noticed it was happening again. So to rule out any issues with my wifi, I have constant pings running to essentially all of my smart bulbs(17 of them, all running AiLight). Thus far, pings have been going without an issue with a random 1 ping timing out here and there. During this time, I see quite a few socket errors on my MQTT broker with the lights.

Sometimes it reconnects, other times it appears I have to restart the bulb. I snipped the reconnects out as the others had local IP addresses, sorry for being paranoid.

1577144601: Socket error on client Ailight3-Hall, disconnecting. 1577144699: Socket error on client Lohas3-Entry2, disconnecting. 1577145249: Socket error on client Lohas-LivingFan1, disconnecting. 1577145670: Socket error on client Lohas2-Entry1, disconnecting.

So, potentially there is an issue with MQTT as it appears the wifi connections are stable? I dont see a long list of dropped pings so far. Going to do some more digging and look into getting your other firmware working as I hope that can address any issue with MQTT that could be present. Any thoughts? I am not sure if its the lights or the broker at this point.

[jcbbas]

Sorry to keep "spamming" this thread. I tried the MQTT - Reconnect branch again, unfortunately it still seems like it will not connect to my broker for whatever reason. After a full reboot of the light, most of the config info is showing blank on the webpage and controlling the light does not seem to work.

Anyways, I still appreciate all the great work you have done! This so far has been rock solid, and I would rather deal with whatever issues come of using your firmware and MQTT over letting my devices talk to china all the time!

[jcbbas]

And I think I finally narrowed down the issue. Apparently this is happening when the transition value is specified with turn_off and the MQTT packet has it saved as the state.. This appears to cause the light to come back on then right back off when it reconnects to the MQTT broker. I cleared out these values and put it intentionally on one light. That is the only light that is now coming on when the broker is restarted or the socket connection error occurs. It went away earlier because I had cleared out the MQTT states and when the wife came home, my node red calls added these back, thus lights going on and off again.

So I think there is two problems at hand, one, socket connection errors cause the lights to lose connection with the broker. Two,upon connect, having the state off with transition specified causes the light to come back on, then go right back off.

[stelgenhof]

Thanks for all the details! Definitely not spamming as it is very helpful.

Based on your findings, I indeed think the mqtt_reconnect will not help as that addresses a different issue.

When you says 'transition_value' you mean the option to have the lights transition from one color to another? If so, that is something I haven't seen before in combination with MQTT. It is definitely possible from what you are describing. COuld you perhaps provide more detailed steps (values and settings) what you did to replicate the issue? Then I can try the same on my side.

Thanks! Sacha

[jcbbas]

Yea that's the one! It's almost like on reconnect, it thinks it has to transition back to off since that is the last state it was in. I also noticed in general, the transition doesn't actually work, the light simply turns off after the set time instead of slowly fading to off. It seems to do this when the color temperature is used instead of the actual RGB values.

In node red, transition is set here:

This then reflects on the MQTT server as:

When the light pops on, it stays on for however long the transition was set to then turns off immediately. This coincides with the socket error and subsequent reconnect to the MQTT broker. I can either wait for the socket error, or restart the broker to reproduce it.

I also just discovered I can reproduce the turning on then off by sending a "turn_off" command with transition set, and the light will turn back on, wait the set time, then turn back off. So maybe something can be addressed from the firmware side to ignore the transition value if the light is already off?

As for the socket errors, I am not sure how to tell if its my network, the MQTT broker, or the light itself. Ill keep digging on that front. I use the Mosquitto broker in the official add ons for home assistant as my broker.

[jcbbas]

Just switched over the light to use the RGB values, and the light does come back on, but then slowly fades to off adhering to the transition value. This happens even if the light is already off, oddly only on the first time I send the request. After that, it seems to ignore it but only the RGB seems to have this behavior.

So I think when using color temp, it just turns off instead of fading off, when using RGB value, it slowly fades from color to off. In either case, it pops back on, goes through the transition time, then turns off. It is interesting that when using a RGB value, the light does it the first time I re send the value of off with transition, but after that, it seems to ignore it.

[stelgenhof]

Thanks for the info! I'll need to make set up things on my side first in order to see if I can reproduce this.

As for the socket errors, there could be many reasons. Often it is the network (WiFi) and also not every ESP8266 modules is the same (different manufacturers). In a forum I read that people fixed socket errors by providing a username/password for the MQTT connection (event though authentication was disabled).

Not sure if these are applicable to your situation, but perhaps worth to investigate. Another option I can think of is setting up a different MQTT broker. Just to rule out you current setup. You can install it on another machine, VM or docker.

Cheers! Sacha

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days

[stelgenhof]

I've seen this as well now with one of my lights. Still need to understand what's causing this though...

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days

[stelgenhof]

Can confirm this happens but very infrequently.

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days