-
Notifications
You must be signed in to change notification settings - Fork 117
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
bug/crash with scheduler api #414
Comments
I did have an issue with something similar, thought I fixed it, will have a look. |
I see some events.getnext() in scheduler.cpp without checking if there's such next event first, could this be the culprit ? |
While working on the Timers part of the new GUI, I get this issue as the UX I'm doing is creating each timer separated. I confirm the OpenEvse-wifi crash if there's only one timer. It doesn't happend if there's more, whatever the enable/disable parity is respected or not. |
@jeremypoulter , do you have any hints on this issue yet ? |
Sorry, I have not had a chance to look at it yet |
@jeremypoulter Just a hint as I'm looking at it, it's not the fact that we have only one timer, it seems to need booth an active and disabled timer. I've tried with 2 enabled or disabled timers, and it also crash the firmware. |
getNextEvent could get stuck in an infinate loop if searching for a type that is not in the list. This can happen when there is only enteries ofa single type, eg disabled and you search for active, as the LCD module does causing a watchdog timeout. Fixes #414
I'm in holiday I can't track it but seems I saw a bug if only one schedule is set ( for example a "disabled" schedule with id: 1 , without an "enabled" one )
Can't see if it's a crash or bug from here, but then common status data from create_rapi_json are not published on MQTT, I think it's the same with http, event_send is not called. Either it crashes before or something else.
The text was updated successfully, but these errors were encountered: