I`m preparing a release #190
Comments
lubeda
added
help wanted
|
Happy New Year Lubeda! |
|
Happy New Year! |
|
Hi, I'm testing the pre release and the text supposed to be the date over the calendar icon is just a blinking exclamation mark. Is this issue the right place to report bugs ? |
|
This is bug in your YAML. Somehow the display gets no time. Check your configuration and the log |
|
I double checked (md5sum) and the ulanzi-easy.yaml file is 100% identical to the one from the install/ folder of this repo (i did create a secrets.yaml file containing the ota and wifi passwords -- you may want to update this in the Readme btw, because it still suggests editing the ulanzi-easy.yaml file directly). Plus, i DO get the time (just not the day): Logs: |
|
Can you edit the log-level to debug a post a new log? logger:
level: DEBUGI tried it on two devices, and it works for me. We have to investigate a bit. can you also provide this part of your config? external_components:
- source:
type: git
url: https://github.com/lubeda/EspHoMaTriXv2
ref: "2024.1.0"
refresh: 600s
components: [ ehmtxv2 ] |
|
Here is the DEBUG log: As i said, i did not touch the yaml file, so the external_components part is: |
|
OK, ehmtxv2:
weekdays: "DiLuMaMeJeVeSa"And please try again. |
|
Thanks for the suggestion, which i tried; no change unfortunately:
Here is the diff between my device's |
|
Now i have the same bug! I think you have to use 2023.9.1 until i found the problem. désolé ;-) I like spending my holiday time in France, mostly in the Bretagne and Normandy. |
|
Oh, strange that you did not reproduce 1 hour ago... But i'm glad you do now. No problem i can wait ! Vielen Dank ;) |
The icon name in the sample was wrong: This will work: on_empty_queue:
then:
- lambda: |-
id(rgb8x32).set_infotext_color(20,20,20,20,20,20,false,1);
id(rgb8x32).icon_clock("calendar|day#0",1440,10,false); |
|
Great, that did it, it works now, many thanks !!! I'm not sure it is intentional but you commited the DEBUG level. Maybe another, issue, the get_status service call seems to do nothing for me (i open the log in esphome, then run the get_status service within HA -- i expect to see the status in the esphome logs, but i see nothing; what am i missing ?) |
|
Hi, DEBUG level helps me if there are issues, for normal use it isn't necessary. The get_status service should write details to the ESP-log with the level INFO, so now you should see something in your log. |
|
You are talking about the log that is viewed by clicking here, right ?
Then i call the service
But nothing:
|
|
Again, strange. I will investigate.... |
|
Actually, in DEBUG i see the status (i guess): Is this expected (if so the readme should maybe mention it)? |
|
Yes, that is the expected result. |
|
Ok, got confused because the default install yaml was WARN (hiding the get_status log). I can contribute improvements to the readme, should I open a PR for it ? |
|
Sure, every PR is welcome. |
|
Done, i hope you'll like my changes ! |
|
Hi. Testing now the pre-release and have a question about the night mode. Looked at the code and saw that when night mode is on all screens are skipped which are not flagged as night mode. How can I specify just "clock" as night mode screen and apply a color? |
|
Got it, there is night_mode_screens like so: Experimenting now. |
|
Working as expected, but how to correctly use the trigger? This doesn't work: |
You need to turn on the night mode |
I'll switched it on (tested with a switch and the exported service). Tested in 2023.9.1 and 2024.1.0-prerelease branches. My definition: The switch: I can see that nightmode is enabled in the logs and also just the night_mode_screens are showed. But the trigger is not called When I uncomment the set_clock_color in the switch, it's working but I want my customizations on the callback, for a cleaner for Thx |
I checked everything, it should work. What if we add a little feedback? |
|
I think this switch can be simplified a little and one global variable removed. |
Merged ... |
|
I have now set screenmode 2 (clock) as night_mode_screens, it's working as expected. When night mode is on, they dont show up now (also with force_screen), which isn't that great. Any chance to get a force_screen flag to temorarily override night_mode_screens and show the forced screen? thx |
|
Another thing. |
Change: to or to and use |
When I debug code, I often modify it using OTA, this has never happened before. |
Thx using alert_screen now because I can seperate important alerts and not. |
Yeah, I think an issue with the hardware... |
|
|
All good regarding the night_mode_screens :-) A question regarding the function: I have this in my config, because otherwise no clock is shown. That changed on newer releases. I noticed after some time the clock and date is gone. Sure 😁 lifetime is set to 10 minutes and other screens (weather, ...) are long time queued. Can lifetime be set to "always show clock&date" (infinity)? Or do I have to use esphome timers to queue it again. Thx |
|
I have now done this as a workaround. Workaround removed, was not working. I think it's an overkill and there should be (or is?) an lifetime infinity value like -1. |
Look #93 |
That's exactly my issue! My workaround for now: That should keep the clock alive. |
|
The Issue was not opened, apparently everyone decided it similar to your solution, I recreate it once a day. Whether to open it or not is up to you. |
|
Done see #208 |
|
As stated, since I am on 2024.1.0 the clock crashes 50% after OTA (black screen) and needs a serial reflash to bring it back to live. This happens on my two clocks. Two times also just a few minutes after flash. The WAF is currently not so high, so I reverted to V1, and all runs fine again. PS: maybe it has Todo with my HW mods (always on mod + no battery + DC/DC converter). But as stated it's rock solid on v1 |
I have Ulanzy TC001 and no problem? In you clock Esp32? or 8266? Maybe decrease icon count and check? |
|
I have two ulanzi's with ESP32 and both showed the issue. Sorry the WAF was very low, i am now back at v1 since two days, and they are running flawlessly. |
|
Yesterday I flashed Ulanzi without any problems. |
|
Look like we need 2024.2.0 release :) |
|
Looks like we need a 2024.3.0 release ;-P |
|
OK, I released a very but didn't improve the documentation like I had planned. :-( Too much work too few time! Thanks for your support! |
|
You (and all the other contributors) are doing an amazing job. Thanks so much for all your hard work on this helpful software. |
|
@andrewjswan here is a serial log when the issue described above happens. It just doesnt boot anymore after a while: And here is part of important yaml: As stated, v1 is running without an issue. I think it has todo with the display switch restore state to off, calling "id(rgb8x32)->set_display_off();" on boot. When the display was on (written to flash) before reboot the clock boots up normally after power down. So it seems when calling "id(rgb8x32)->set_display_off();" during boot, it fails. Any chance that you use my config to reproduce the issue? Thank you |
|
Now i can reproduce the issue!
|
|
Easier to reproduce, just add the following switch with "restore_mode: ALWAYS_OFF": The issue happens immediately on boot. @andrewjswan Can you please look into the issue? Thank you |
|
@andrewjswan @lubeda i have created an issue here: #222 |
|
I think we should do a release, or there is confusion about the branches. Maybe we should put all the changes into main, and then people will get to the current version at once. |
|
Maybe it makes sense to set the latest branch as the default branch? |
|
Would make sense. |
Hi there,
in the last time there were so many new features added (thanx @andrewjswan a) that it is now necessary to restructure the repo, clean it up and make the documentation easier to read and understand. I'm preparing it in the 2024.1.0-prerelease branch.
So stay calm, until the new release (with no new features), I suggest using the 2023.9.1 branch.
See you soon.
The text was updated successfully, but these errors were encountered: