In the latest release somehow the variable ControlTimeout became too long. After installation mine became 60000 (60s) and was causing openLuup to intermittently freeze (API and API unresponsive) for about 1min. Remote connection in that case would also be not functional. I had to bring it down to 1000 to eliminate the issue.
I am not sure under what situation a value greater than 5s would be helpful.
[quote=“rafale77, post:1, topic:199851”]@amg0
In the latest release somehow the variable ControlTimeout became too long. After installation mine became 60000 (60s) and was causing openLuup to intermittently freeze (API and API unresponsive) for about 1min. Remote connection in that case would also be not functional. I had to bring it down to 1000 to eliminate the issue.
I am not sure under what situation a value greater than 5s would be helpful.[/quote]
For remote access to vera it is needed , at least for me
You should be able to change that default value
Yes I did so. I can confirm that this value was the reason for my openLuup to be temporarily unresponsive. I have not had a problem with it since. openLuup is single threaded and I guess the long timeout caused it to wait for something? I have a couple of bridges polling the openLuup instance.
I find that hard to believe, it is a client side timer waiting in JS to receive the first user_data. There must be some environmental issue. Is open Luup up and running when you start?
Yes openluup is up and running. I noticed the problem after updating ALTUI. I have been running my own branch of openluup for a few months now. When I check the service, it is still up and running even though both the API and ALTUI don’t respond… then I try to kill the service and it would make me wait for quite a long time before it closes (less than a min). I reduced the timeout to 1000ms and have not seen the problem for the past 2 days. It was at 10000ms before the ALTUI update.
Reducing the timer just make Altui stop waiting for an answer. You check the js console logs and please share your altui config esp around controller setup.
You probably want to debug this without altui, just with the direct url to get user_data and see why it is not responding fast enough
I actually think it is a problem with openLuup. When it stops responding, I don’t even get the ALTUI page with the “waiting for initial data”, I get no response at all. Homewave (which uses get user data) also gets no response from openLuup and apparently neither can systemd shut it down. I understand what you are saying and can’t explain why it does what it does. In my case, most of why remote access work with a timeout of 3 seconds.
My ALTUI config is pretty vanilla, I have a pretty big startup Lua of 170ish lines including the attribute settings.
[quote=“rafale77, post:7, topic:199851”]I actually think it is a problem with openLuup. When it stops responding, I don’t even get the ALTUI page with the “waiting for initial data”, I get no response at all. Homewave (which uses get user data) also gets no response from openLuup and apparently neither can systemd shut it down. I understand what you are saying and can’t explain why it does what it does. In my case, most of why remote access work with a timeout of 3 seconds.
My ALTUI config is pretty vanilla, I have a pretty big startup Lua of 170ish lines including the attribute settings.[/quote]
it works before the timeout fails but ALTUI continues so later on the call maybe successfull and you feel it works. you should see error in console log though.
I agree, it sounds like a openluup multiple entry / single thread problem
[quote=“amg0, post:8, topic:199851”][quote=“rafale77, post:7, topic:199851”]I actually think it is a problem with openLuup. When it stops responding, I don’t even get the ALTUI page with the “waiting for initial data”, I get no response at all. Homewave (which uses get user data) also gets no response from openLuup and apparently neither can systemd shut it down. I understand what you are saying and can’t explain why it does what it does. In my case, most of why remote access work with a timeout of 3 seconds.
My ALTUI config is pretty vanilla, I have a pretty big startup Lua of 170ish lines including the attribute settings.[/quote]
it works before the timeout fails but ALTUI continues so later on the call maybe successfull and you feel it works. you should see error in console log though.
I agree, it sounds like a openluup multiple entry / single thread problem[/quote]
I am not seeing an error in the console and I can now confirm that it is a significant problem on my openLuup installation which runs quite a few plugins pinging other APIs. It appears that openLuup just temporary freezes while waiting for this timeout to expire. Now that I reduced this timeout to 1s, the occasional missed updates from plugins like Vrainsensor, iPhonelocator, Ecobee or plantlink stopped. They work with a Luup.call_delay on a function which seem to have been missed while openLuup was temporarily frozen and therefore got themselves out of self updating.
[quote=“rafale77, post:9, topic:199851”][quote=“amg0, post:8, topic:199851”][quote=“rafale77, post:7, topic:199851”]I actually think it is a problem with openLuup. When it stops responding, I don’t even get the ALTUI page with the “waiting for initial data”, I get no response at all. Homewave (which uses get user data) also gets no response from openLuup and apparently neither can systemd shut it down. I understand what you are saying and can’t explain why it does what it does. In my case, most of why remote access work with a timeout of 3 seconds.
My ALTUI config is pretty vanilla, I have a pretty big startup Lua of 170ish lines including the attribute settings.[/quote]
Hoping Akboer can look at it
it works before the timeout fails but ALTUI continues so later on the call maybe successfull and you feel it works. you should see error in console log though.
I agree, it sounds like a openluup multiple entry / single thread problem[/quote]
I am not seeing an error in the console and I can now confirm that it is a significant problem on my openLuup installation which runs quite a few plugins pinging other APIs. It appears that openLuup just temporary freezes while waiting for this timeout to expire. Now that I reduced this timeout to 1s, the occasional missed updates from plugins like Vrainsensor, iPhonelocator, Ecobee or plantlink stopped. They work with a Luup.call_delay on a function which seem to have been missed while openLuup was temporarily frozen and therefore got themselves out of self updating.[/quote]
If a process hogs the CPU beyond the time that a luup.call_delay() function should run, then it is run as soon as possible afterwards. They are not missed.
Hi rafale77,
I have the time out set to 6 seconds because of remote access delays. I have not seen that lock up openLuup though. Just scanned the log file around the moment of logging in remotely and not seeing any pause in the log messages suggesting a pause.
I had one other scenario with an https request. The timeout in LUA does not seem to work in all cases and that would lockup or stall openLuup. Oddly only on one particular post request out of many to the same web service, sometimes after a day, sometimes not for two weeks, I never managed to figure out why as the https request simply would hang. I now redesigned to plugin and eliminated that particular request. Have you eliminated all those possible sources for lock ups or delays?
Cheers Rene
Hi Rene,
Thank you for this insightful post. No I have not looked into other possibilities. I only noticed that I started getting frequent temporary lock ups since the last ALTUI release. I proceeded by elimination. Since I have not touched openLuup or any other plugins in a few months, it had to be something in ALTUI. The ControlTimeout when I looked at it was extremely long. (60s) I believe to have manually set it at 6 or 7s in the past but it’s been incrementally extended over the past few months by updates. I admit to be running a lot of plugins which are making various API calls, including your Harmony with 3 remotes and fairly frequency. I too have observed what you are referring to but with the latest 60s release the lockups were daily. In any case, I have eliminated the problem by reducing the timeout back down to 1.2s. I am thinking that the lockups still occur but only last 1.2s at the most and then the backlog of actions continue as AK mentions. At 60s, it seems the backlog of code to run is too long and some things get dropped or crash out of sync.
Best Home Automation shopping experience. Shop at Ezlo!
© 2024 Ezlo Innovation, All Rights Reserved. Terms of Use | Privacy Policy | Forum Rules