V3.1 several problems found

[goudi76]

Yesterday I have tried to do the setup in reality... I found out that V3.1 does not load the whole webpage using "tally light setup" WLAN connection. It also does not recognize settings after pressing the "save" button at all. It stored half of the settings sometimes.

When it was connected to the network, it shows "white" status but then directly shows the ATEM status??? I guess it should stay blue if it does not find the ATEM?

Then I decided to flash down to Version "3.0" and some things changed: Webside was always loaded properly and much quicker! in "tally light setup" Wlan as well in operational Wlan connection. It also recognized the "save" button correctly.

Problem with the white LED status was still there

It was problematic to get connection to ATEM Mixer for sometimes all connected Tally lights (3pcs) directly but most times one or two lights get connection and then it stopped. (There were no other connection opened and ATEM was fresh booted) I have also setup all IP Adresses fixed and close to each other. Interesting point was also when it was connected, it stays connected. Sometimes it needed several reboot of the tally light to get connection to the ATEM but the Tally was connected to the operating WLAN showing "white" status light. It didn't find the ATEM Mixer in that mode if it didn't recognize it directly after reboot.

I hope this all helps to find the Problem(s). BR

[goudi76]

An Idea, reading all the other issues: Maybe the Server does not wait long enough? Maybe the Tally light does stop searching for the ATEM Mixer? I also forgot to tell, that the Tally light "Serial Monitor output" does recognize the operational WLAN, but not the ATEM Mixer, and the Status Light is white.

[AronHetLam]

If it turns white, it's because it didn't connect to your WiFi in the first try. It'll keep trying though, even when serving "tally light setup". Once connected to WiFi it's pink, until it connects to the ATEM. I does continue retying to connect to the ATEM. The connection process varies in length, depending on multiple factors, but it can go so fast that it seems it skips a step. I don't see that anything is wrong with the status indication... If it's only with the strip I can't really test it...

The problem with not loading the complete site is most likely an issue with the chip not being to powerful in a heavily used WiFi/network environment. Reloading it a few times usually gets it going. Nothing regarding loading the webpage changed between versions, other that the size of it. The same counts for saving. In a browser you can see it's only about 7KB of data. I'm not an expert at networking, but as far as i know the chip has to process quite a few other network packages than just the ones we actually need. most of those would probably be broadcast packages sent by devices that need to make themselves known (such as a chromecast or a printer - even the ATEM). I would assume limiting the amount of unnecessary broadcast traffic would give more stability. I run mine in a fairly isolated LAN network.

Maybe selecting the higher bandwith lwIP variant can help. But again, I'm not sure what exactly it does.

Regarding connecting to the ATEM itself - Once a connection spot on the ATEM has been used, it takes some time before it frees it up again (probably because it's trying to reconnect to it's client). I'm not sure if the connection process sometimes goes wrong, and it therefore makes a spot unavailable for a little while. That's specific to the ATEMbase library though. uncommeting line 268 atemSwitcher.serialOutput(0x80); //Makes Atem library print debug info might give you a clue about what's happening during the connection process.

[goudi76]

Thanks for that detailed answer. I do not have the ATEM at home anymore - that makes trouble shooting much more time consuming. Probably I can check that on sunday. At home I'm using your "ESP8266 Atem simulation" board. Using that everything is fine. The Problem is with V3.1 and I flashed already down and it occurs with V3.0.1 also. Maybe I need to go down all versions I have offline until it works again correct to find the problem. @AronHetLam If you are interested in one of the striped versions please send me a PN. I will give an update when I found something. I guess having all versions on Desk and see which is the last working one could help to find the failure as quick as possible.

[Hitower78]

Hi

ESP8266 Atem simulation ? How can i find it? Because: we use 16 ATEM Mini, but most times i cannot use one here in my Office

Thx for Help

Daniel

[AronHetLam]

Just pushed a few commits.

First, i stripped the HTML for unnecessary white-spaces, reducing the amount of data sent when loading the website by 10-15% Hopefully that'll speed it up a bit.

Secondly, I finally made a better version of the test server, which can be found in the root of the repo. It has the same support for 2 LEDs and Neopixels as the main program, It doesn't try to connect to a switcher any more, and actually have the lights indicate the state it's sending to it's clients. 😊 You scroll through the tally states by sending a CR (\r) in the serial monitor.

[AronHetLam]

@goudi76, It doesn't make sense that it broke between v3.0 and v3.0.1. Look ad this diff Only the limit of Neopixels changed in the HTML, which wouldn't affect anything regarding loading the page... Something else is going on..

[goudi76]

Hy Aron, thx for your Answer and your Help inbetween anyhow! Today I have flashed them all (all content) with "high Bandwith" and the latest 3.1 Version. 1) Tally setup Wlan worked stable today, the setup inside the operational network was working proper. I don´t know if this setting change was the "problem solver" or not, but half loaded pages haven´t come up again. 2) We found out that we have been on IPs reserved by Fritzbox for VPN use. This was xxx.xxx.xxx.200-xxx.xxx.xxx.204. These IP Table seems to be reserved for VPN network. I didn´t know that and it worked sometimes but not stable and sometimes the Tally lights lost their connection.

Today I found out that another IP table (inside DHCP area) worked better but still not perfect - but in anycase this has nothing to do with this projekt. Sometimes the Tally lighs are connected to the network but not to the Atem Mixer (showing white Status LED (maybe Pink is to close to white?)) this is shown in the web side inside of the tallys. To see the status there helps alot! We are running a ATEM mini Pro ISO Mixer on version 8.6. A reboot of the ATEM solves the status of not "recognized by ATEM" and all Tallys got connection to the ATEM Mixer. I don´t know if someone else have simmilar probs? I don´t know if this can be solved in the code? If the maximum of connections are reached, is there an error message somewhere in the ATEM? Today we have been connected with 5 devices - this should not hit the maximum of connections.

Another Idea which came up today during the usage of the tallys: Why not have a Status LED only in case of an error. If there is no error it can be used for normal Program / Preview setting - as "no status" LED I don´t know if this setting is far away but it would help for the usage with LED stripes (which really work perfect)

[AronHetLam]

Good to see you are getting through your issues.

Digging into the FastLed's colours, it seems it's using HTML colour names, so it's pink is (R, G, B) 255, 192, 203, whereas mine is 255, 0, 255 (essentially). Making theirs more white... I found my pink is named Fuchsia. I committed a change, see if the colour is better.

I don't know of a place the ATEM or software control shows if the limit is hit. I once saw some unused code in the Skaarhoj's libraries that might be able to help tell if the connection actually was rejected. With that I might be able to signal unconnected and rejected separately.

I'm not entirely sure what you are asking for with the last part. Is it that you would like the status led on the LED-strip to act as a tally-LED once connected? Like the RGB-LED's act? That should be possible, but some might find it nice to have something indicating it's on and connected, even when no tally indication should be shown.

[goudi76]

Thanks for your explanations. I will test the colors later on. To my last question to the Status LED. There are 3 Modes of Status LED 1) First LED on the stripe 2) Last LED on the stripe 3) None I request a new status 4) First LED on the stripe Status "not connected"

What would it do? The First LED shows all Status messages as long the Atem is "not connected" If the Atem is "connected" The first LED went to the mode defined in Tally Light setup (Program only, Preview stays on ect.) In my case you can see the blue LED from the Wemos D1 mini when it is not in Program - for me that is enough status light - and looks cool. In case of any error (defined as not "connected to Atem") the status LED comes up telling you what is wrong automatically.

I hope this is better explained.

[Stephan-Kl]

Hey, how do i test the setup with the tally test server? When I upload the sketch and hit (/r) nothing happen. I have the D1 with a 6 pixel long Neo-LED Strip connected.

Thank you.

[AronHetLam]

Just hit enter in the serial monitor, that should make it scroll through the different states. Does it write the state change when you hit enter? If not, make sure you select both NL and CR in the bottom.

[Stephan-Kl]

Yes, in the serial monitor the state changes are showing up. But the less are not changing the color.

[AronHetLam]

I found the problem. It never updated the LED strip, only the 2 main LEDs. That commit should do the trick.

[Stephan-Kl]

Awesome, works perfectly.

[goudi76]

I don´t know if you have uploaded the correct code yesterday, but it seams that the neopixels are not updated correctly. Sometimes it shows red and green at the same time including the (correct) Status LED

The Color Fuchsia looks much better! Thanks not having 2 "white" color status!

I have found out that the Neopixel did not show the correct status after a loss of connection! I have uncomment Line 268 and watched the status in the serial monitor - which does not fit to the neopixels status. The serial monitor was always correct (connection lost to Atem) but not updating the Neopixels.

I´m lost in the code but could you please have a look what happened? I also found out that it is actually running much slower than version 3.0? was. Are the ESP32 questions take so much time?

[AronHetLam]

@goudi76, I cannot reproduce any of the issues you are describing... Are they all related to the test sever, or are some of them related to the main program?

Good the color is better, I also just changed green to lime, which will make the green color full brightness.

Uncommenting this // #define DEBUG_LED_STRIP in line 21 will make it print the colors for all LEDs every time it changes, and Updated LEDs when it actually shows the changes (which is the slow part, so it only does this if anything changed). With 2 neopixels selected and first LED as status LED this is what i get, and it looks as expected. If you are able to make it print unexpected colors, I'd need to know exactly how you've set it up. I only did 2 neopixels here to reduce serial spam, but with 10 or 100 it still looks fine.

Program
Tally:  
0, RGB: 25, 16, 0
1, RGB: 255, 0, 0

Updated LEDs
Preview
Tally:  
0, RGB: 25, 16, 0
1, RGB: 0, 255, 0

Updated LEDs
Program and preview
Tally:  
0, RGB: 25, 16, 0
1, RGB: 255, 0, 0

Updated LEDs
Off
Tally:  
0, RGB: 25, 16, 0
1, RGB: 0, 0, 0

Updated LEDs

Regarding slowness, how did you measure it, and did you have it print debug info when it was slow? Printing to the serial port is super slow, and should be turned off in production - this is the main reason i don't have any print statements in the part of the code that runs all the time. In C++ (the coding language used) any line starting with a # is a preprocessor statement, and is only used during compilation. those doesn't make it into the code. So eg. in this part of the code

#if ESP32
    html += WiFi.getHostname();
#else
    html += WiFi.hostname();
#endif

the compiler will compile it as if only html += WiFi.getHostname(); is there if ESP32 is set, and as if only html += WiFi.hostname(); is there if not.

[AronHetLam]

Works with a real ATEM. At the moment only on the website.

Also, if I restart the fifth unit connected, Initially it's rejected, but the slot on the ATEM is freed up again after a little bit, and it automatically reconnects, even after having been rejected. So the rejected status is possible.

[goudi76]

All issues I have pointed out are related to the main program. I have never used the Server with the neopixels. I'm using a blank ESP 8266 as a server for testing. Sorry for being not so clear.

[goudi76]

I have two tally lights running. One is on the new software, the other one is on an old software (before ESP32 implementation) Sometimes the Light comes up earlier. I do not measure it, but I can see which light up first.

But this case means the time between startup and "working" condition. If it is "online" I haven't seen a time difference anymore. But startup is quite good visible. Well, I don't know if this problem should be forced anymore. Maybe the failure is within the reconnection to an existing Atem?

[framejb]

Friends, I'm having trouble setting up Tally, I finish the setup and the wifi is not registered on the D1 mini. Someone with knows where I did it wrong. thanks. Francisco - Brazil

[goudi76]

@framejb stupid questions: Are Wlan credentials correct? and did you press the "save" button? If you have the ESP connected to Arduino pleas open the "serial" window and share the logs which are shown there. What are the WLAN settings on your router? Is WPA allowed?

[framejb]

I am very happy with your help. Problem solved: I was using “ino 3.0” when using 3.1 o no more problem. Thank you very much.

Francisco Melchior

Enviado do meu iPhone

Em 21 de mai. de 2021, à(s) 15:01, goudi76 @.***> escreveu:



@framejbhttps://github.com/framejb stupid questions: Are Wlan credentials correct? and did you press the "save" button? If you have the ESP connected to Arduino pleas open the "serial" window and share the logs which are shown there. What are the WLAN settings on your router? Is WPA allowed?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/AronHetLam/ATEM_tally_light_with_ESP8266/issues/31#issuecomment-846139365, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AMKBIIFK6TVTQHIGEDIFBHLTO2NYVANCNFSM4ZJ7NLKQ.

[goudi76]

@AronHetLam I found the main problem why I have had such that problems: It is the router which is sometimes not recognizing the Tally Light parts. Other devices "looses their connection" as well but it hasn't been that clear - because they are not that time critical like the tallies are. I have tested Version 3.1 at home with two (three devices at all) Lights and there everything worked. But in the "production area" I have had trouble with them. Now we found out that it is not the tally alone having trouble. I would suggest to close this issue - I guess I will not be able to bring up more detailed information which are repeatable. Malfunction wich is not repeatable is pretty complicated and it should be the same on different network infrastructures but it is not - so I guess It must be the network rooter. BR

[AronHetLam]

Sounds more like a network setup issue than the tallys programming. If you do find something that you can recreate easily let me know, else well just keep this closed. 🙂 Btw, did you upgrade to v3.1.1? It comes with a patch to the reconnection process.