WebUI does not update values automatically

[korkbaum]

Dear all, when in sync mode or while being controlled through API calls (JSON or HTTP), the Web UI does not update to the new values. Sync works fine. I can also control my lights through curl but I would really like to see the Web interface picking up the new/most recent values on its own without a reload of the web page.
Am I missing some point (or setting) here or is there some sort of enhancement required to achieve this? Thanks in advance for your comments.

BTW, WLED is really a great project!

Best Regards -korkbaum

[korkbaum]

Hi again, after several attempts, I think I found a solution myself.

I added a few javascript lines to index.htm in function onLoad():

// Create new WebSocket var wsurl = 'ws://${locip}/ws'; var mySocket = new WebSocket(wsurl); // Attach listener mySocket.onmessage = function(event) { requestJson(); updateUI(); }

At least first tests show good results; the synced LED is picking up the commands and shows them in the GUI instantly.

Anyway, maybe this approach is not quite well and if there are any better suggestions I would love to hear them.

BR -korkbaum

[blazoncek]

Have you tried this with live view (Peek) enabled?

[korkbaum]

Hi @blazoncek, thanks for your comment but no, live view / Peek doesn't give me the result I'm looking for. BR, korkbaum

[blazoncek]

Sorry I did not ask if live view solves your issue but if your solution works with live view. :) Another thing to consider is the possibility that websockets are not enabled in particular build.

[korkbaum]

Apologies for the misunderstanding. Yes, live view also follows the new/updated state. I did enable websockets in my build, as the modification I made relies on websocket messages coming in. Before my change to index.htm, the UI did not update although sync worked.

[Aircoookie]

Hi @korkbaum , thank you for trying out connecting to the WebSocket from the UI! This was my plan all along and the main reason I implemented WebSockets to the ESP backend. However during preliminary testing, I found out that the (about 3kB of) memory used by the WebSockets connection were not always released correctly and could therefore cause a low memory condition, but definitely let me know how it works for you :)

[korkbaum]

Hello @Aircoookie, I'm more than happy to run further testing and see if there are crashes or unexpected behaviour. Will let you know. So far it works well, regardless if updates are coming through as JSON or HTTP POST, from other WLED clients or by curl commands. TBH, I was thinking quite a while about how the GUI updates can be achieved and was really stunned that it finally works with just a handful of JS code lines. Let me take the chance and thank you so much for driving the WLED project. Just great. BR korkbaum

[blazoncek]

You may need to adjust your URL: var wsurl = loc ? 'ws://${locip}/ws':'ws://${window.location.hostname}/ws';

But I can confirm (on 0.12 beta) that ESP8266 is running out of memory rather quickly with 900 pixels attached (on two strips). And I can see a lot of "Not Found HTTP call".

[sansillusion]

Mabe it sould be made conditional to esp32 only ? I personally like the idea. I dont use esp8266 because of their lack of memory.

Just my two cents.

I love to see how good wled was when I discovered it a long time ago already. And it evolved a LOT since. Cool to see the community adding their part on top of Aircookie's great work.

Le lun. 8 mars 2021 2 h 46 p.m., Blaž Kristan notifications@github.com a écrit :

You may need to adjust your URL: var wsurl = loc ? 'ws://${locip}/ws':'ws://${window.location.hostname}/ws';

But I can confirm (on 0.12 beta) that ESP8266 is running out of memory rather quickly with 900 pixels attached (on two strips).

[image: Screenshot 2021-03-08 at 20 44 06] https://user-images.githubusercontent.com/7722392/110372843-14858b00-804f-11eb-8d44-dc26b226fcad.png

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/Aircoookie/WLED/issues/1790#issuecomment-793025433, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHBFDCXHL3GSL3VFXKETBOTTCUSSZANCNFSM4YYAUS7Q .

[Legsmaniac]

I dont use esp8266 because of their lack of memory.

How is 16M a lack of memory? The Wemos D1 Mini Pro is 8266 and has 16M memory.

Having said that, I'm using the latest WLED with no problems on 4M 8266 devices. Personally, I far prefer 8266 over ESP32, I have more issues with 32 than 8266. 😊

[sansillusion]

I understand that wled is made to work with esp8266 but it could do much more if it was not limited by the esp8266 memory.

Le lun. 8 mars 2021 5 h 46 p.m., Legsmaniac notifications@github.com a écrit :

I dont use esp8266 because of their lack of memory.

How is 16M a lack of memory? The Wemos D1 Mini Pro is 8266 and has 16M memory.

Having said that, I'm using the latest WLED with no problems on 4M 8266 devices. Personally, I far prefer 8266 over ESP32, I have more issues with 32 than

8266. 😊

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Aircoookie/WLED/issues/1790#issuecomment-793141236, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHBFDCWZ35WXXYNULG62VFDTCVHUJANCNFSM4YYAUS7Q .

[Legsmaniac]

It does exactly what it's designed to do perfectly well. As I said, 16 meg is hardly what I'd call "limited". Not sure what this "so much more" you're referring to that you'd like WLED to do but for most user purposes, it's more than enough as it is, I feel.

[Aircoookie]

Why you guys always confuse flash memory with RAM memory? 😄

Both ESP32 and ESP8266 commonly have 4MB of flash - that is not a common limiting factor, and if so, both are easily available with 16MB.

RAM is what makes a HUGE difference though. Typically on ESP32 190kB remain unused / available for network activity, while it is down to only 20kB on ESP8266, limiting the project in a lot of ways.

I agree that enabling websockets in UI for ESP32 by default might be a good choice :)

[Legsmaniac]

Why you guys always confuse flash memory with RAM memory?

That is true. I always forget that. And it's only down to 20kB if you switch too much stuff on. Not everything is needed.

[blazoncek]

And it's only down to 20kB if you switch too much stuff on.

With EVERYTHING OFF, you can hardly get past 23k with a very low LED count. :) And web sockets being one of the things turned off.

[Legsmaniac]

with a very low LED count

What constitutes "very low"? Is 2040 LEDs very low? (Actually 6120 if you count each RBG as a single LED) Yes, I've run 2040 WS2812B LEDs using a NodeMCU 8266 with no problems at all. Even used Glediator and Jinx to control the LEDs via WLED very successfully. Another NodeMCU is powering a chain of LEDs round the roof of my home.
If that's "very low", the mind boggles at how many LEDs you're using.

[blazoncek]

What constitutes "very low"? Is 2040 LEDs very low? (Actually 6120 if you count each RBG as a single LED) Yes, I've run 2040 WS2812B LEDs using a NodeMCU 8266 with no problems at all.

I am happy that your setup works for you, but not everyone is so lucky. And not every configuration so "simple".

[Legsmaniac]

Hmmmm. I dunno, maybe I have been lucky. Even when I first started trying out WLED, they've always worked right from the start, never had a problem. Maybe it helps that I have an electronics background and a good understanding of computers, Arduino and self-compiling, I dunno. Currently, I have some 14 Arduinos all running WLED in some project or another, all of them 8266's, 9 of them for Christmas lights and I have played with and tested maybe a dozen more, including a 60 X 34 LED Matrix board, the above mentioned 2040 LEDs which is probably (so far!) the maximum number I have used.

I have indeed read on here the number of problems users seem to have and I have tried to help a few. Some have WiFi issues and many have power supply issues. Others have problems with their data line either being too long or not supplying the required 5v hence the need for a logic level shifter and some are using wires that are too thin hence greater resistance/voltage drop. All of which obviously are not problems with their device. Those with unlucky device problems often appear to be either faulty or cheap inferior Chinese boards. I don't believe any problems should arise from the use of a number of LEDs/low memory, if I can run 2040 LEDs, anyone can.

Obviously I cannot speak for those who use WLED in other modified projects but running WLED as it's designed shouldn't present any problems. All I can say is that your comment "I don't use esp8266 because of their lack of memory" is a bit ambiguous and could put of potential new users from trying 8266. 😊

[sansillusion]

Donyou use all effects ? I know se need way more ram than others. Also segments are an issue with low ram on esp8266.

Le mar. 9 mars 2021 7 h 43 a.m., Legsmaniac notifications@github.com a écrit :

Hmmmm. I dunno, maybe I have been lucky. Even when I first started trying out WLED, they've always worked right from the start, never had a problem. Maybe it helps that I have an electronics background and a good understanding of computers, Arduino and self-compiling, I dunno. Currently, I have some 14 Arduinos all running WLED in some project or another, all of them 8266's, 9 of them for Christmas lights and I have played with and tested maybe a dozen more, including a 60 X 34 LED Matrix board, the above mentioned 2040 LEDs which is probably (so far!) the maximum number I have used.

I have indeed read on here the number of problems users seem to have and I have tried to help a few. Some have WiFi issues and many have power supply issues. Others have problems with their data line either being too long or not supplying the required 5v hence the need for a logic level shifter and some are using wires that are too thin hence greater resistance/voltage drop. All of which obviously are not problems with their device. Those with unlucky device problems often appear to be either faulty or cheap inferior Chinese boards. I don't believe any problems should arise from the use of a number of LEDs/low memory, if I can run 2040 LEDs, anyone can.

Obviously I cannot speak for those who use WLED in other modified projects but running WLED as it's designed shouldn't present any problems. All I can say is that your comment "I don't use esp8266 because of their lack of memory" is a bit ambiguous and could put of potential new users from trying

8266. 😊

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Aircoookie/WLED/issues/1790#issuecomment-793836316, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHBFDCTNNDHNBCDEDUOOPXLTCYJWPANCNFSM4YYAUS7Q .

[Legsmaniac]

Donyou use all effects ?

Yes. And no. I have tested all effects and they all work fine but I don't "use" all effects in most given scenarios as each project calls for a specific set of effects or lighting.

Also segments are an issue with low ram on esp8266.

Again, I cannot comment on that because that's not my own finding with my currents uses of any 8266 I have. I've used segments, as many as possibly 4 or 5 on my projects but again, I have tested using 10 once for the benefit of another user who needed help so I set up a test environment and it worked fine.

[blazoncek]

I have trouble believing that 2040 pixels and 12 segments run fine with any effect (except solid) on the ESP8266. Especially Fireworks Strarburst and simultaneously updating UI! What was the FPS you got and what usermod did you enable for 2040 pixel? I'm really curious since I thought I've optimized my multistrip fork as best as it could be but apparently I'm wrong.

[Legsmaniac]

Er.... not 2040 pixels AND 12 segments, not that I mentioned 12 anyway. :neutral_face: As I said, 2040 pixels was a matrix board I created, 60 LEDs per strip width by 34 rows of them on a board just over a metre wide by about 600mm high. It was intended to be a Christmas :santa: centrepiece to be mounted up high on the outside apex wall but I changed my mind when I realised how much faff it would be to haul it up and take it down every year, not to mention the dangers up a ladder. My wife was happy about that! But I did set it up to run a few Christmas animations I'd put together which did look cool. I also tested playing an avi file through Jinx which to my surprise, also ran perfectly. (The avi was the start theme to Eastenders TV soap!) The avi was not easy to make out really as there wasn't really enough pixels for a decent image.

https://streamable.com/sakg6e

The above was an early test of just one (fairly rubbish!) animation on the board before it was completed as I was awaiting delivery of more rolls of LEDs.

https://streamable.com/23v6b7

And this was the Eastenders theme on the finished board. You'll notice there are unused pixels left and right, this was because the avi was 4:3 If you look carefully, you'll just make out the River Thames of central London which is the location of Eastenders.

Sadly, I can't find any other videos at the moment, I'm pretty sure I did one of the finished board with more cool animations.

As for segments, a max of 10 was tested on shorter strips, no more than 300 LEDs which would be a complete 5mtr roll of 60 LEDs per mtr.

Hope this helps you believe it now and satisfy your curiosity. Obviously, you'll have to trust me that I was using an 8266 as I simply don't use anything else.

[blazoncek]

I am currently experimenting by polling for state by JS in requestJson() like this:

if` (refreshTimer) clearTimeout(refreshTimer);
refreshTimer = setTimeout(function(){requestJson({'v':true},false);},15000);

This uses less RAM but has a drawback to update every 15s. @Aircoookie mentioned that this was used in pre-0.9 but still occasionally produced instability. If you want to test, this is available in my WLED repo in dev branch (with a few other enhancements).

[korkbaum]

Hello @blazoncek, sounds like an interesting alternative and less resource-hungry approach. However, I'm not really in favor of cyclic updates which are likely unnecessary most of the time. The event-driven approach with the websockets would be better in case the setup (number of LEDs/segments etc.) permits. I'm actually running several WLED lamps and these are all different with not that many LEDs (122 is the most). One main driver for me is that I want to build some fancy WLED hardware controllers and basically only use the UI as a dashboard to control my settings. In that scenario, the 15s approach is not an option. However, I appreciate that other users really use huge amounts of LED stripes to wrap their houses. I can imagine that such use cases may rule out the websocket approach. I didn't really have much time for more testing in the past two weeeks but I hope I can report soon how it works. Thanks again and Best Regards

• korkbaum

[blazoncek]

@korkbaum I think I have solved the issue and the solution you proposed now works with much smaller RAM footprint. I added JS handler to parse websockets JSON response instead of calling requestJson() from within websocket event handler. Available in dev branch in my WLED fork.

[korkbaum]

Hi @blazoncek, that sounds really good and is likely a more elegant solution. I will try to have a closer look over the weekend. Thanks for picking up the topic and investigating several approaches. BR, korkbaum

[blazoncek]

@korkbaum would this fulfill your request? https://youtu.be/NIxu5bFjgaM

[korkbaum]

Looks great - seems you really like the idea and take it to a new level! Thx for sharing.

[stale[bot]]

Hey! This issue has been open for quite some time without any new comments now. It will be closed automatically in a week if no further activity occurs. Thank you for using WLED!