Don’t apologise - the whole point of this is to share experience & knowledge! 
3 Likes
Just for reference, this is the power supply and battery charger schematic:
EP is the battery charger chip (doesn’t give what chip is used). It has a VIN from USB connector and a separate pin for the battery (BAT+). It then takes care of sending power out VOUT-BAT which feeds into the Voltage regulator.
Excellent info thanks, where did you find the schematics?
It was in the zip file that zagnuts shared in post #43.
2 Likes
I’m working on getting the device into deep sleep using esphome (I’ve only done it using platformio and IDF before). It was pretty easy with the deep_sleep component but the problem I’m running into is that the device is still consuming 14mA when it is in deep sleep.
I’m trying to think through what could be causing such a high current usage in deep sleep, I’m expecting to see 0.000A when in deep sleep because this device cannot detect down to uA. Does anyone have any thoughts as to what could be the culprit? These are my immediate suspects:
- I’ve never used the ESPHome Deep Sleep component and have not looked at the code. Maybe it is not working the way I’m used to. Has anyone used it before with an esp32c3 and can confirm it should get the esp32c3 device down to uA current draw? I think this is the least likely issue but don’t want to rule it out.
- The GC9A01 display needs to be put into sleep mode before going into deepsleep. The device driver would need to be extended to send this I2C command I believe. This is the most likely reason…
- The CST816S touchscreen needs to be put into standby mode before going to deepsleep. The datasheet says it should only be drawing 1.6mA in the default mode so this cannot be the entire reason for 14mA draw.
Any ideas or input is appreciated.
Maybe the voltage regulator?
Sweet! It was the display:
Putting the display into sleep mode is getting us down to uA current draw with a swipe of the touchscreen waking up out of deep sleep. Now I can move forward with yaml for the deep sleep mode. But then that leaves the problem that when you wake up from deep sleep it takes 3-10 seconds to connect to Home Assistant. So the next step is to make an ESPNow component work so that we can have instant communication out of deep sleep.
3 Likes
To try deepsleep add the following:
esphome:
name: $devicename
friendly_name: $friendname
on_boot:
then:
- delay: 100ms
- script.execute: deepsleep_script
deep_sleep:
wakeup_pin: 0
wakeup_pin_mode: INVERT_WAKEUP
script:
- id: deepsleep_script
mode: restart
then:
- delay: 15s
- output.turn_off: gpio_3_backlight_pwm
- lambda: |-
id(watchface).sleep();
- deep_sleep.enter
external_components:
- source: github://GadgetFactory-Jeannie/[email protected]
components: ["gc9a01"]
- source: github://GadgetFactory/[email protected]
I am seeing 10mA current if I wirelessy monitor the logs when it goes into deepsleep. So be sure to turn off logging or don’t watch the logs. Will need to experiment more with this.
1 Like
This reminds me to ask - is there a repo or site I can get the esphome code from? Or do I have to search through this thread and copy/paste? No problem if I have to do that, but there have been lots of code snippets posted in the thread…
1 Like
I created this organization to start putting my code, right now there is only the forked drivers that were extended. But this is where I’ll start putting full examples when I get some time.
GadgetFactory-Jeannie (github.com)
3 Likes
I “solved” the thread, so if you go to that (ESP32-C3 with integrated GC9A01 - cheap touch controller - #72 by zagnuts) then you’ll see the working code. In the future I will update that if it changes significantly (and did that just then - my code now includes different pages for my thermostat and a light), but I do like the offer by jackgassett for making a repository as could have different examples of code for people who may be using the controller for different things…
1 Like
Does it make sense to continue working on getting this device to work off batteries in this thread? Or should that be a new topic? I’m happy to go either direction, I don’t want to hijack this thread if we feel getting it to work was the purpose and that has been accomplished. I look at getting it to work off a battery as getting it to work even better than it already is. But I’m also fine with a new thread if we want to keep things compartmentalized.
Doesn’t worry me either way - there’s only a handful of us playing with the thing at the moment so I don’t think it’s an issue if it stays in the one thread, and getting it to go into deep sleep is definitely nice to have as is adding in touch location detection (so in theory are all in the ‘getting the dang thing to work’ bucket), but feel free to start a new one if you think it makes more sense!
I think the thread turned to 2have all functions of device working” so it makes sense to continue research here and have one goto reference thread.
One day it will be ported to esphome …
Can you drill down on esp now quicker wake-up in esphome? Did not know
Thanks for the fantastic work !
Ok got it.
Did not know about espnow
Sorry for slow response, that’s right ESPNow is the only method I’ve found so far for the esp32c3 that allows you to wake up from deepsleep and send something out immediately. I’ve tested with mqtt, esphome api, and matter (over wifi) and none of them will send out an update until they make a connection. That takes from 4-10 seconds for all of them which is too long for my purpose, to turn a light on immediately when a gesture is performed. With ESPHome you have a gateway device, which can be any esp8266 or esp32, that is always connected to esphome and also listening on espnow. You can send a message out and have it control a light in milliseconds. I already have this working with native ESP-IDF code, just need to clean it up and port it to an ESPHome component.
The downside is needing the espnow gateway. I’ve also been testing with thread/matter and zigbee sleepy end devices which are able to last a long time on a battery while maintaining a connection without any kind of gateway. But that needs the esp32c6 or esp32h2 module. I designed a new board with the esp32c6 that I was planning to use for the gesture sensor and possibly for a ESPHome to matter/zigbee sleepy end device gateway. Still need to experiment and think that one through some more though.
Like I think I mentioned, my plan was/is to have the screen wake when motion is detected on a separate sensor to avoid having a distracting glowing thing on the wall in a bedroom at night. Mine will all be directly powered so I don’t have to worry about battery life, but perhaps you could use something similar ie the remote sensor detects motion or perhaps presence in the room so then wakes up the controller but possibly still leaves the screen off (to conserve power).
Not the perfect solution of course as the battery will be used more and you still have the delay for the device to get out of deep sleep, but you are using the motion sensor to start that before the person gets near the controller - by then it is hopefully awake and when the user touches the screen it turns on and does whatever you want the gesture to do. After a set time of inaction the screen goes off, then after a further set time with no motion and/or presence detected then the controller goes back into deep sleep.
I use the motion sensor to turn on/off the backlight of the screen. If you use a transition_length of about 1s, it gives a really nice fade in and out 
You can see an example of it in the end of this video: https://youtu.be/gYiDOfyO7jU
2 Likes
Unfortunately, you need an interrupt on one of the pins of the ESP32 to wake from deep sleep. So using something like a motion sensor to wake it up isn’t going to work without connecting a pin from the motion sensor to the esp32 which is not the route I’m looking for. Also, just turning off the display will only last about a week before a 2000mAH battery would be drained if my quick calculations are right.
On another note, I got the x,y coordinates working tonight but don’t have time to publish the code. I think it will be quick to also flip the screen and will try to add that in and publish them both soon.