Open popy2k14 opened 3 months ago
I have now made a workaround -> reboot when more than 10000x on_empty_queue triggers in one minute.
on_empty_queue:
then:
lambda: |-
id(queue_empty_count) = id(queue_empty_count) + 1;
...
interval:
#workaround that clock reboots, when it loops
- interval: 1min
then:
lambda: |-
//check on empty queue count
ESP_LOGI("interval", "empty queue counter is: %i", id(queue_empty_count));
if (id(queue_empty_count) > 10000) {
ESP_LOGI("interval", "empty queue is looping -> reboot");
id(reboot).press();
}
id(queue_empty_count) = 0;
...
There is possibly a problem with the memory management that leads to your behavior. I will try to find a solution or implement your work araound.
There is possibly a problem with the memory management that leads to your behavior. I will try to find a solution or implement your work araound.
Thx s lot for looking into this. I have changed my workaround to > 10000, with 20 it has false triggers. I could give feedback in 1-2 months if it helps.
If you need tests (ex. debug Version with memory log messages), I am here to help testing 😃
on_empty_queue
is triggered each tick (~16ms) which is "stupid". To trigger it once (breaking change) or in a larger interval (not so breaking change) is more clever. I think I will go for once, which is more structured. Or are there aspects which are better with once a minute?
Or are there aspects which are better with once a minute?
Isn’t it possible that we won’t have anything on the screen for almost a minute?
I personally find it rather irritating that you, as a user have the possibility to have an empty/black screen and must serve the clock as content! It's a clock and should always show the clock (as it did in previous versions).
The workaround in yaml (see above or if it's in c code) is just a workaround.
As you can see in my yaml i am adding a clock_screen when on_empty_queue
is triggered.
So i think the real issue is an underlaying issue in the queue (on adding or consuming screens).
I think adding something in c is not the real solution.
So i think there are multiple ways to solve this (sor):
Search the underlaying issue with the queue As stated, i am here to let an debug version run and see if the issue pop's up again and this time have more precise logs.
Add https://github.com/lubeda/EspHoMaTriXv2/issues/208 and maybe this issue is not present anymore. But that's also rather an workaround. But it's not so irritating as having the possibility to have an black screen! I know the feature was added because you as a user have more possibilitys in features, But i find it irritating for most of us users. Looked at the code and there is an defen alerady so clock_screens does'nt get remove. Maybe as an beginning fpr #208 just add this define as default for clock and date_screen and add and config option to set other screens also as static later.
Add my yaml workaound in c code not prefered.
What do you think which route we should go?
PS.: Added the above text also to #208 so we can discuss it there?
It's a clock and should always show the clock
If you see this as a clock, you are totally right, if you see this as a status-display the on_empty_queue way is more flexible.
As you can see in my yaml i am adding a clock_screen when
on_empty_queue
is triggered.
That is the way to go if you want a clock.
Bug report
Describe the bug
The clock displayed nothing but was reachable with HA. But it's really busy! Viewing Logs online was hard and HA freezes because of the amount of logs messages (because of the loop). Display and "Night mode" was on. It looped and always triggered "on_empty_queue"
Additional information
To Reproduce
Steps to reproduce the behavior: I dont know. I just was running stable for ~25 days and one night this issue occured.
Expected behavior
Trigger "on_empty_queue" -> my yaml triggers "set_night_mode_on()" (or off) which add's at least an clock_screen. Do not loop.
Configuration
Logs