-
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
LCD Energy Savings (backlight off) #8
Comments
If you're in there tinkering with storing energy cost anyway, it would be really great to report accumulated cost for the current period, total cost for last period, and day of the month the period starts. TOU electrical rates that everyone in California is on make this slightly more complicated, which is why I haven't tackled this myself. |
While I doubt the energy savings will be much - probably not more than a few cents a month. The bigger issue is a brightly lit screen drawing attention to an outdoor installation at night. |
I agree the LED off while not actively charging would be nice to reduce light pollution and drawing attention to the installation. |
I also agree the LED off. On the other hand, as for the smoke detectors, two LCD or LED flashing per minute will allow to know the status of the openevse when the LCD is off. (No button to activate the openevse) |
Very much want this feature as well. Currently I unplug my openevse and stop charging to watch stars at night. |
I've wanted this feature for quite a while, but see it has been open for 4 years. Thank you |
The dimming is for the LEDs, but we can however set the backlight off. The problem is more when to turn it back on, especially for units with no button. That being said this is probably going to be the next issue to work on. |
Thanks Jermey, I was wondering if I could help, but I think its probably too early for me until I get to know the codebase and how it works.
I’ll stick with trying to turn a GPIO on for relay control for now :)
… On 27 Mar 2023, at 18:35, Jeremy Poulter ***@***.***> wrote:
The dimming is for the LEDs, but we can however set the backlight off. The problem is more when to turn it back on, especially for units with no button.
That being said this is probably going to be the next issue to work on.
—
Reply to this email directly, view it on GitHub <#8 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB7LLAQZZDHDCUADAQFFTKTW6HFWZANCNFSM4IMKVWSQ>.
You are receiving this because you commented.
|
You’ve have a much better understanding than me, could it me turned on for say 5 seconds every time a claim or released ?
Then you’d only have to potentially hook into one function (he says not knowing the code at all !)
… On 27 Mar 2023, at 18:35, Jeremy Poulter ***@***.***> wrote:
The dimming is for the LEDs, but we can however set the backlight off. The problem is more when to turn it back on, especially for units with no button.
That being said this is probably going to be the next issue to work on.
—
Reply to this email directly, view it on GitHub <#8 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB7LLAQZZDHDCUADAQFFTKTW6HFWZANCNFSM4IMKVWSQ>.
You are receiving this because you commented.
|
Hi Jermey, I've create a pull request OpenEVSE/open_evse#16 for you to have a look at. It would probably make sense to be able to disable this, by say setting the timeout to 0. From my simplistic analysing of the code, some things are obvious
Let me know what you think. |
I will take a look, but probably it would be better for the LCD backlight to be controlled by the WiFi firmware, that is where the majority of the logic is now. One thing to bear in mind is that the backlight should remain on in error conditions. |
I think there is a lot of confusion between the LED and LCD. Looks like J1772 seems to control it for the most part, which would seem sensible to me (it knows what condition its in and backlight reflects that)> |
Definitely a lot of confusion between the LCD and LED, but not in this case ;-) (although the LED probably does need to do the same) the vast majority of the LCD control at this point comes from the WiFi module via RAPI commands and probably will move the LCD to be directly connected to the WiFi module at some point. It also is a lot harder to update the EVSE firmware we try not to implement new features on the EVSE board. |
That's a good point on the difficulty of updating it. It would be great if ESP32 could flash the AVR (like esplink) but the amount of code and complexity to make that so would be daunting, and likely not even have the room to do so. I had in an other thread mooted the idea of moving the LCD control to the wifi board (to free up the i2c port), but looking at the code, it is a seriously heavy lift. I'm not sure if the EVSE can work without the wifi board, so having the LCD on openevse may need to stay if that is the case. I've no skin in the game, I just want the damn backlight off :) FYI... because I haven't quite learnt the etiquette of branching quite yet, this pull request also includes the code to allow relays to work independently... you'll see in the other thread you're tagged in. |
Add basic energy savings.
Add ability to turn of LCD back light after x minutes of inactivity with the RAPI command $FB 0.
back light will turn back on automatically with any state change.
The text was updated successfully, but these errors were encountered: