Lagging Issue I Think?...

[aheywood89]

Hey all,

Not really sure how to explain this one... I have followed the setup etc... and have gotten to the point in which all appears to be in place, but the light behaviour isn't right?

Like my last post, I'm a complete noob and I hope its just my stupidity thats the issue!

Setup: Wifi router 2.4GHz and 5GHz 62mbps+ Raspberry Pi 3 Model b+ (Connected by ethernet) ESP8266 with 300 led WS2812b attached. (Connected to 2.4GHZ Wifi) iPhone X with updated Hue app.

LED Setup: First setup was set to 6 lights (50 LEDs each) then the second setup was 3 lights (100 LEDs each). [The problem is the same regardless of setup...]

Connecting the app and the pi is done, and connecting the 8266 is also complete.

The problem is: The lights are a step behind!? As in; when I open the app and turn on the room (which has just the strip in it) it does nothing, so I press the Relax scene, and the lights come on but to whatever the last scene was. Then say I press Nightlight scene and the bulbs will then display Relax scene. I then press the all off and the lights go to the Nightlight scene, so I press all on and they all turn off...

Its literally a complete step behind. Eventually when I do get the off command to be the current state the first 50 LEDs stay on at 1%. YET When I turn on/off/change scene on the normal Hue Bulbs, they respond with a slight (maybe 2sec lag).

I have completely restarted the project, I have tried a different ESP chip, I've clean booted the pi and started again, I have used the most up-to-date files from GitHub and I have completely reset/rebooted the wifi station to make sure there aren't any conflicts...

Honestly don't know what to do and would really appreciate the help :S

[mariusmotea]

To debug this is better to check ping reply from Raspberry Pi to lights ip. It must be 3-4ms. Be aware that there is a bug in Raspberry Pi 3 wifi firmware and if you connect it to your wifi network it send some packages that broke entire network. I return one expensive Mikrotik router because in some cases i had big lag and then i discover my raspberry pi 3 connected on both LAN and WIFi was the issue.

[aheywood89]

Seems like the ping rate keeps fluctuating. Last test was 50 packets:

--- 192.168.1.12 ping statistics --- 50 packets transmitted, 50 received, 0% packet loss, time 49079ms rtt min/avg/max/mdev = 1.165/6.712/64.268/12.260 ms

The pi is definitely on ethernet, im thinking it might be more to do with the 8266? Do you recommend any specific settings through Arduino IDE?

[mariusmotea]

Try to compile with cpu set to 160Mhz. But what is the ping reply from Pi to Esp board(s)?

[mcer12]

I also have significant ping issues. I thought it might be esp8266 pcbs issues but it does the same with yeelights and nodemcus that are literally two meters from the AP. The ping command starts with 100+ms and it drops to around 3-90ms fluctuating. I suspect this can be caused by crowded wifi channels.

[mcer12]

I should add that i use orange pi one with wired ethernet.

[mariusmotea]

Or a board like raspberry pi3 that sends nasty packages and create a mess on wifi communication like i had. For sure the yeelight has good wifi. You can find the nasty device by disconnecting clients from wifi one by one.

[mariusmotea]

Wired connectivity don't impact wifi

[mcer12]

I pointed it out so that we can rule out the bridge itself being the problem.

[mcer12]

I tinkered with it for a bit, changed wifi channel and 802.11n only and the performance increased significantly. What I keep seeing though is each time I ping one of the esp8266 lights, first packet (or sometimes first few packets) takes 100ms and then it drops to around 2ms. I suspected it might be some wifi-sleep functionality of esp8266 but google didnt help.

@aheywood89 if you're in an area crowded with wifi signals, try to pick different channel, helped me a good bit.

[mariusmotea]

first packet (or sometimes first few packets) takes 100ms and then it drops to around 2ms.

Same for me, but even with this behavior i don't have latency at all. https://forum.mikrotik.com/viewtopic.php?f=7&t=136659 https://github.com/raspberrypi/firmware/issues/839

[aheywood89]

Sorry gents, been on night shifts... greatly appreciate your continued support! Haven’t had chance to look but will hopefully tonight.

Just as an after thought... hopefully this will clean up the lag, but still confused as to why the light is a command behind... hopefully this is a 2-for-1 issue and will be corrected with the prior 😉

[mcer12]

From the mighty internet wisdom it seems like the initial long packet is caused by DNS lookup. So I guess with manual IP + DNS configuration in sketch (and IP allocation in router settings) this might be avoided.

[ghost]

@aheywood89 Have you tried mcer12's suggestions here?

[mcer12]

@cheesemarathon I tried my solution but it didn't have any impact whatsoever. For me the lag appears only on first few packets after few minutes of radio silence. I'm thinking to overcome this issue by pinging the bridge IP once a minute or so from each esp. This is what the ping usually looks like:

Příkaz PING na 192.168.0.50 - 32 bajtů dat: Odpověď od 192.168.0.50: bajty=32 čas=119ms TTL=255 Odpověď od 192.168.0.50: bajty=32 čas=41ms TTL=255 Odpověď od 192.168.0.50: bajty=32 čas=67ms TTL=255 Odpověď od 192.168.0.50: bajty=32 čas=90ms TTL=255 Odpověď od 192.168.0.50: bajty=32 čas=1ms TTL=255 Odpověď od 192.168.0.50: bajty=32 čas=2ms TTL=255 Odpověď od 192.168.0.50: bajty=32 čas=5ms TTL=255 Odpověď od 192.168.0.50: bajty=32 čas=2ms TTL=255 Odpověď od 192.168.0.50: bajty=32 čas=2ms TTL=255 Odpověď od 192.168.0.50: bajty=32 čas=3ms TTL=255 Odpověď od 192.168.0.50: bajty=32 čas=2ms TTL=255 Odpověď od 192.168.0.50: bajty=32 čas=2ms TTL=255 Odpověď od 192.168.0.50: bajty=32 čas=1ms TTL=255 Odpověď od 192.168.0.50: bajty=32 čas=3ms TTL=255 Odpověď od 192.168.0.50: bajty=32 čas=1ms TTL=255 Odpověď od 192.168.0.50: bajty=32 čas=4ms TTL=255 Odpověď od 192.168.0.50: bajty=32 čas=2ms TTL=255

[mcer12]

Or of course the bridge can ping all nodes on regular basis which might be more proper solution and see if that makes a difference. @cheesemarathon @mariusmotea

[ghost]

Ok, if you can test this fix by creating a function in your lights to ping the bridge every so often, then if it works we can look at adding a function to the bridge to do the same. That sound ok @mariusmotea @mcer12?

[mcer12]

Ping as a solution didn't work...

[mariusmotea]

Ping only looks to help because stop eps8266 power management (that increase the delay). The main issue remain the wifi network, noisy devices or too many wifi's one the same or near channel.

[mcer12]

Yes I think so. My theory is that the encryption handshake can take longer beacause of the interferrence but I'm no expert :) Lets see if @aheywood89 has some findings...

[ghost]

Hey @aheywood89 Have you tried changing your WiFi channel to see if that improves performance? It may be worth while changing your ZigBee channel as well to make sure that it's not interfering with your WiFi. If you use ZigBee devices that is.

[aheywood89]

Hey all, sorry I haven't responded for a while, finally on a Rest Day so I've had a play today... Decided to start from scratch and see what happened.

• The RPI3MB+ has a fresh install of Raspbian, connected to ethernet with Wifi disabled.

• Using the Automatic Install, the bridge is installed on the Pi. The Hue app is setup and connected.

• The ESP8266 is freshly formatted with the following:

• I have used the WifiManager and the setup is complete. The lights have also been found on the app and placed in to a single room.

• The ping is as follows:

pi@raspberrypi:~ $ ping 192.168.1.13 -c 50 PING 192.168.1.13 (192.168.1.13) 56(84) bytes of data. 64 bytes from 192.168.1.13: icmp_seq=1 ttl=255 time=81.0 ms 64 bytes from 192.168.1.13: icmp_seq=2 ttl=255 time=103 ms 64 bytes from 192.168.1.13: icmp_seq=3 ttl=255 time=25.3 ms 64 bytes from 192.168.1.13: icmp_seq=4 ttl=255 time=4.09 ms 64 bytes from 192.168.1.13: icmp_seq=5 ttl=255 time=2.86 ms 64 bytes from 192.168.1.13: icmp_seq=6 ttl=255 time=19.9 ms 64 bytes from 192.168.1.13: icmp_seq=7 ttl=255 time=3.76 ms 64 bytes from 192.168.1.13: icmp_seq=8 ttl=255 time=1.48 ms 64 bytes from 192.168.1.13: icmp_seq=9 ttl=255 time=2.01 ms 64 bytes from 192.168.1.13: icmp_seq=10 ttl=255 time=2.48 ms 64 bytes from 192.168.1.13: icmp_seq=11 ttl=255 time=4.02 ms 64 bytes from 192.168.1.13: icmp_seq=12 ttl=255 time=1.93 ms 64 bytes from 192.168.1.13: icmp_seq=13 ttl=255 time=3.49 ms 64 bytes from 192.168.1.13: icmp_seq=14 ttl=255 time=1.79 ms 64 bytes from 192.168.1.13: icmp_seq=15 ttl=255 time=2.44 ms 64 bytes from 192.168.1.13: icmp_seq=16 ttl=255 time=2.53 ms 64 bytes from 192.168.1.13: icmp_seq=17 ttl=255 time=1.87 ms 64 bytes from 192.168.1.13: icmp_seq=18 ttl=255 time=5.13 ms 64 bytes from 192.168.1.13: icmp_seq=19 ttl=255 time=4.01 ms 64 bytes from 192.168.1.13: icmp_seq=20 ttl=255 time=3.37 ms 64 bytes from 192.168.1.13: icmp_seq=21 ttl=255 time=2.62 ms 64 bytes from 192.168.1.13: icmp_seq=22 ttl=255 time=3.29 ms 64 bytes from 192.168.1.13: icmp_seq=23 ttl=255 time=1.77 ms 64 bytes from 192.168.1.13: icmp_seq=24 ttl=255 time=2.83 ms 64 bytes from 192.168.1.13: icmp_seq=25 ttl=255 time=10.1 ms 64 bytes from 192.168.1.13: icmp_seq=26 ttl=255 time=2.09 ms 64 bytes from 192.168.1.13: icmp_seq=27 ttl=255 time=1.89 ms 64 bytes from 192.168.1.13: icmp_seq=28 ttl=255 time=1.96 ms 64 bytes from 192.168.1.13: icmp_seq=29 ttl=255 time=1.72 ms 64 bytes from 192.168.1.13: icmp_seq=30 ttl=255 time=2.95 ms 64 bytes from 192.168.1.13: icmp_seq=31 ttl=255 time=1.32 ms 64 bytes from 192.168.1.13: icmp_seq=32 ttl=255 time=1.95 ms 64 bytes from 192.168.1.13: icmp_seq=33 ttl=255 time=8.32 ms 64 bytes from 192.168.1.13: icmp_seq=34 ttl=255 time=6.84 ms 64 bytes from 192.168.1.13: icmp_seq=35 ttl=255 time=8.81 ms 64 bytes from 192.168.1.13: icmp_seq=36 ttl=255 time=3.72 ms 64 bytes from 192.168.1.13: icmp_seq=37 ttl=255 time=2.62 ms 64 bytes from 192.168.1.13: icmp_seq=38 ttl=255 time=4.46 ms 64 bytes from 192.168.1.13: icmp_seq=39 ttl=255 time=1.93 ms 64 bytes from 192.168.1.13: icmp_seq=40 ttl=255 time=3.39 ms 64 bytes from 192.168.1.13: icmp_seq=41 ttl=255 time=2.23 ms 64 bytes from 192.168.1.13: icmp_seq=42 ttl=255 time=1.70 ms 64 bytes from 192.168.1.13: icmp_seq=43 ttl=255 time=10.1 ms 64 bytes from 192.168.1.13: icmp_seq=44 ttl=255 time=3.05 ms 64 bytes from 192.168.1.13: icmp_seq=45 ttl=255 time=3.11 ms 64 bytes from 192.168.1.13: icmp_seq=46 ttl=255 time=1.83 ms 64 bytes from 192.168.1.13: icmp_seq=47 ttl=255 time=1.74 ms 64 bytes from 192.168.1.13: icmp_seq=48 ttl=255 time=4.75 ms 64 bytes from 192.168.1.13: icmp_seq=49 ttl=255 time=2.28 ms 64 bytes from 192.168.1.13: icmp_seq=50 ttl=255 time=2.01 ms

--- 192.168.1.13 ping statistics --- 50 packets transmitted, 50 received, 0% packet loss, time 49073ms rtt min/avg/max/mdev = 1.329/7.695/103.583/17.950 ms

It appears that it keeps having periods of >3ms throughout the packets...

• And the one I truly don't understand, the lights are one step behind... Restarted the lights, pressed a scene (doesn't matter which) = noting, but press another scene and the first one comes on; press off and the second scene shows, do whatever next and the previous shows...

The only thing thats left is try to get rid of the Wifi interference. I think i might place the Pi, my phone and the ESP on a router with nothing else and see what happens?...

[mariusmotea]

In debug mode we can see exactly what is happening. I believe i need to add another entry in wiki to explain how to enable debug mode. I keep you updated

[mariusmotea]

Can you test to control the lights directly so we can remove the ESP as the problem cause?

from wifi:

curl "http://{light ip}/set?light=1&r=0&g=60&b=255&transitiontime=2000"  
curl "http://{light ip}/discover"

Arguments that can be passed in the URL:

"on": 1 to set light on, 0 to set the light off.
"r", "g", "b": Set the light color using RGB values between 0 and 255.
"x" and "y": Values between 0.0 and 1.0 to set the light color using a CIE chart.
"ct": Value between 153 (max warm white) and 500 (max could white) http://en.wikipedia.org/wiki/Mired
hue: Value between 0 and 65535, representing the hue of the light.
sat: Set the saturation of the light. 255 is the most saturated and 0 is the least saturated.
bri: Set the brightness of the light, 255 is the maximum brightness, 1 is the minimum, 0 will turn the light on to previous state
transitiontime: Duration of the transition from the light’s current state to the new state. The default is 4 representing 0.4 seconds.
bri_inc: Increase or decrease the brightness with a specified value

[aheywood89]

Forgive me, I'm not sure what you need. Here is the response from the Pi to the light IP (192.168.1.13)

pi@raspberrypi:~ $ curl "http://192.168.1.13/set?light=1&r=0&g=60&b=255&transitiontime=2000" OK, x: 0.56, y:0.40, bri:1, ct:367, colormode:0, state:1pi@raspberrypi:~ $ curl "http://192.168.1.13/discover" File Not Found

URI: /discover Method: GET Arguments: 0

[mariusmotea]

Send some commands to bulb and ensure it always apply the last one, not the previews one.

[aheywood89]

Sorry @mariusmotea I understand now, I have completed this and they are all a step behind. I also used the web interface and the same happened.

It's almost as if the command sits in a buffer; and then when a new one comes in, it releases the first. Whether that's the Pi or the ESP I'm not sure. If it helps, the Official Hue Bulbs are slow to react but they don't fall a command behind?

[mariusmotea]

So if with curl commands directly to light you have the same problem, then it means the issue is on the light (ESP8266). did you use the latest libraries for neopixel, esp8266?

Is very wired behaviour and i cannot understand how esp can allocate extra ram to store the previews state when there is no such allocation in the sketch. You flashed the esp with the sketch from here?

[aheywood89]

I know :{ The sketch is from the DIYHue repository... and without any modifications. All of the Arduino Libraries are up-to-date and the ESP Board Manager is the latest.

I'm going to start all afresh again tonight and let you know...

[mariusmotea]

How many leds and virtual lights are you using? Can you paste the sketch header with #define variables you are using?

[mcer12]

@aheywood89 just to be clear. Do you have only one ESP light or have you tried others? Does the light behave this way every time you change the scene or does it sometimes refuse to change at all?

[aheywood89]

So currently there is only the one ESP with the WS2812B 300 Strip.

include

include

include

include

include

include

include

include

define light_name "WS2812 Hue Strip" //default light name

define lightsCount 6

define pixelCount 300

define button1_pin 4 // on and bri up

define button2_pin 5 // off and bri down

define use_hardware_switch false // on/off state and brightness can be controlled with above gpio pins. Is mandatory to connect them to ground with 10K resistors

@mcer12, it seems to always be one step behind, but if you were to press a bunch of scenes one after the other rapidly, it doesn't really keep up and then settles on one, not really sure if it was the last one pressed...

[aheywood89]

Another thing, when adding lights to the Hue app, I find if I tap on a Philips Bulb it flashes, but if I press the strip the light comes on and stays on. Press to flash the next and the first will go off and the next will come on and stay on, this then happens regardless of which you push. Basically, the discover flash light behaviour is different.

[mariusmotea]

I test now on mine and i don't have this behaviour. I believe it can happen only if you power on the stript without to apply any state to the lights and also you did not select any scenes in light webgui.

[aheywood89]

Have to admit I'm completely lost with this, I haven't deviated anywhere...

[ghost]

@aheywood89 I just had an idea. Perhaps there is something with your network config that is causing this issue. Do you have a wireless router you could use to test this out. Just connect your device running diyHue, your phone and one or two wifi bulbs to the router to test if the issue persists?

[aheywood89]

Hey, so finally had some time again to play with this.

I set up an old router I had hanging around with no internet plugged in. I placed the Pi, the WS2812+ESP8266 and my phone with Philips Hue on it (these were the only devices on it). Fresh installed everything to all devices. And...

It works!

So at least we know it must be either that there are too many devices on my normal router or that it has a setting issue...

I have noticed that the lights have a fade effect when changing the lights. IF it is that my router is too full or a lag issue; then could it be that this is the reason things are behind because it isn't completing each process. I only say this because there was no visible fading effect on the previous configuration? Maybe removing these and any other effects and literally striping it to basic functions could assist in the error?

However, at least we're getting closer to a cause ;)

[ghost]

Hey @aheywood89 Have you managed to find any more of a cause? I'm thinking overloaded router. You could probably test this by connecting more and more devices to your test router until it in theory breaks.

[ghost]

@aheywood89 I think you have found the issue to be your network setup is probably overloaded. We can't really help with debugging that so I'm closing this issue. If you perform more debugging and find an issue that we need to fix or need some more help, feel free to open this issue. :smile: