Welcome to Pico-Green-Clock Discussions!

[astlouys]

👋 Welcome!

We’re using Discussions as a place to connect with other members of our community. We hope that you:

• Ask questions you’re wondering about.
• Share ideas.
• Engage with other community members.
• Welcome others and are open-minded. Remember that this is a community we
  build together 💪.

To get started, comment below with an introduction of yourself and tell us about what you do with this community.

[UltrashRicco]

Thank you André for creating this discussion! Hopefully more users will join and contribute.
I believe it would be useful to get this new FW to be better known by the community of Pico-Clock users! I believe I found the link to your project on Waveshare's own wiki page for the pico-clock-green: https://www.waveshare.com/wiki/Pico-Clock-Green

[astlouys]

Hi, thank you for your feedback ! Yes... I'm always curious to know what people do with the firmware once they have it... I hope users will find this opportunity to share their experience. I may send a word to Waveshare about this...
I guess you do have a Green Clock yourself ? Do you have some more info to share to feed the discussion ? Have you been using it for a long time ? Do you have "Daylight Saving Time" in your country (may I ask in which country you live) ? What are the features / options you like the most and what are the improvements you would like to see ? (...)

[UltrashRicco]

Yes this is actually Eric, I sent you an e-mail. :)
I do own several Pico Clock Greens and I like to gift them to family and friends as a fun DIY project for them to put together (I ship them with the Pico flashed already, and they have to do the soldering).

I really like the following with V5:

• better code readability (still tough for me as a beginner though)
• easier compile-time configuration
• support for French
• support for more levels of brightness
• support for external sensors, passive buzzer and remote, even though I am not using them (I tried the passive buzzer though)
• I like the scrambled animation at boot time :)
• support for daylight saving time
• in timer mode, the seconds get refreshed every second instead of every few seconds with the original FW
• blinking second dots

I am attaching my modifications to your V5 firmware.

I customized it by setting the following defaults at compile time, so that they are not lost upon reboot (I know you are working on a V6 that will save setting to flash though):

• French language as default
• daytime savings (I live in Spain... the time change dates differ from North America, I believe)
• 24h format as default
• automatic brightness activated by default + AutoLight LED ON accordingly
• much much reduced boot time (skips many tests)
• sped up scrolling speed
• scrolling frequency increased to once every 2 minutes
• much reduced scrolling information (only date and temperature)
• extra (intermediate) level of LED brightness

I should still remove support for the remote and for the passive buzzer, since I am not using them, but keeping them in the code still works for me (however if I plug a passive buzzer, it will play the tunes you programmed at boot time).

I am a beginner at coding (and what I did does not even qualify as coding actually), I had to manually comment out many things in the code. Commenting "define" functions often would not work for me, as the "ifdef" functions later on woudl generate compiling issues (so I commented everything out). Not very clean but it does work for my needs!

You did a great job at adding support for external sensors, passive buzzer and remote. However, I believe that the code should allow for an easier configuration in order to take the presence or absence of said sensors, buzzer and remote into account, and the default config should wome without support for them unless specified otherwise at copmile time, since the Pico Clock Green ships without them (just my view though).

Thank you so much, again, for putting toghether this improved FW for the Pico Clock Green! :)

Pico-Green-Clock-v5.zip

[astlouys]

Hi Eric, nice to see you in the group...

The Green Clock is effectively a nice gift to do.

I should post Version 6.00 very soon now and saving the configuration to flash should be a great help for you to setup the Pico before sending it to friends or family.

I understand that you had some problems trying to "undefined" some of the options (namely, add-on devices). This has been brought to my attention here, on GitHub. As you may imagine, all options are usually "On" here, since all the devices have been installed. So, there was a few glitches with "#ifdef" and "#endif". This should be solved in Version 6.00.

As for the other configuration options, I tried to put the most useful ones in the first block of code identified (and delimited) with "CLOCK CONFIGURATION OR OPTIONS". If you play outside of this block, you're on your own! (smile) But I still believe that the Green Clock is a very good tool to put our hands on code with the Raspberry Pi Pico.

I thought that Daylight Saving Time parameters were more or less the same for most north hemisphere countries. If you have more details about what they are in Spain, I may take a look and eventually implement an option for it. In fact, next change is coming soon as it is the first Sunday of November (Nov 6th), at 3h00 in the morning, it will be 2h00. You will see if the Green Clock follows your local rules...

I also had the suggestion for a "QUICK_START" define to skip some tests at power-up. This is also part of Version 6.00 and should make your life easier if you want the time to be displayed faster.

[olavandrade]

Hello all, and "Thanks, André" for starting this discussion.

Eric, like you, I've previously exchanged email with André. We discussed "internationalization" (often abbreviated "i18n") and the need to support multiple languages for settings.

Unlike previous generations of appliances, this new generation comes with fast processors, large address spaces, and large onboard flash: 2 million bytes. Bill Gates famously said he didn't see a need for anyone to have more than 65 thousand bytes, or so! A good use for that flash memory is multi-lingual support.

Also, let me point out the rabbit hole you are heading down with Summer time/Daylight Savings time. (By the way, the naming of the time shift falls under an issue related to language support, but is known as "localization" -- Brits and Americans are often described as two people who are joined by an ocean, and divided by a common language :)

Let me get back to time changes: this is non-trivial -- it is entirely a political decision, and politicians change their minds all the time! Americans are debating permanent adoption of Daylight Savings Time. Will you issue updates to your clock software when that happens? How long will you support these updates? Next year? Ten years from now? I have clocks older than that!

There is no way to future-proof clock firmware. Instead, think about ways of making the time shift easier. When displaying time, some presses "up" add an hour! "Down" pressed? Subtract an hour. There's nothing to learn! And this allows you to easily move the clock to most other time zones. People aren't going to forget setting the time when it's this easy -- and yes, pressing "mode" will advance to minutes -- for those oddball timezones (Newfoundland, Iran, India, Nepal, parts of Australia) or people who like to live in their own five-minutes-early time zone.

Also, the Pico W adds whole new dimensions for literally(!) pocket change. Consider using http://worldtimeapi.org/ to get info about the current timezone, and daylight/summer time.

Properly putting the clock on someone's network involves a little two-step to acquire their local network credentials. I'm investigating some related work using the raspberry pi zero to see if it can be leveraged.

Other things I'm working on, are to use the PIO state machines, to handle the LED refresh. This is often handled by hardware, so removing it from the clock would make the internationalization/ localization more useful, and able to be shared with other clocks.

The typical way of handling translations is to hash the string you want, and look up it's translation at runtime. If there is no translation available, let the user upload one (we have crowd sourcing on the internet now!) and provide a default. That way you can support many languages, without requiring them compiled into your code. (And it separates the translation from the coding.) Te clock itself should accept translations in Unicode, and downgrade them (e.g., remove accents) to match what can be shown on the display . The Pico-Green-Clock has very short display, and accents aren't legible -- but the translation should allow a clock with a 320x240 LCD to display them correctly, without incurring the costs, in time and money, of requiring new translations.

I'm currently playing with a couple of different clocks, and hoping to share the software base between them. I'm eager to see what others are doing with their clocks, and thanks again, André, for starting the discussion.

[astlouys]

Hi Olav,

Thank you for joining us and sharing ideas about the Green Clock and its firmware...

1. A few words about "Daylight saving time" (DST)...

I must confess something: when I first saw the Pico Green Clock on Amazon, I was looking for an electronic clock that could automatically handle DST since I was frustrated to have to adjust all the clocks in the house twice a year (yeah,,, I'll still have many other clocks and equipment requiring adjustment anyway, but...). When I've seen the Green Clock, I thought "great! if ever it does not support DST, I'll implement it!" So, you understand why I want it to be automatic and why it is one the first options I worked on (I added it in Version 2.00) - smile. The way DST is implemented in the code would make it relatively easy to implement other "standards" for different countries. If ever in ten years, someone needs a new standard that is not supported, in the worst case, he will have to manually adjust it (the same way I'm doing now with all the clocks throughout the house - too bad).

That being said, I like your idea of a fast "increase" / fast "decrease" by one hour. To make it easier and faster. I may take a look at this after publishing Version 6.00. The main problem with the "basic" product is the limitation due of the three clock buttons. I may give it a first try with the remote control.

As for the situation if ever politicians decide to keep the same time all-year round, this is already supported in current version (User guide of Version 5.00, page 20, section 6 - Option 0).

I didn't have the chance to work with the Pico-W yet, but I will definitively give it a try, sooner or later. (my work on micro-controllers is simply a hobby, after all !). This should add the possibility to set the clock time using NTP.. As you mention, problem comes from the fact that we need to enter credentials, either at compile time, either at run-time but then, we need some device to do it. Let me know if you come-up with something interesting with the Pi Zero.

2. LED refresh:

I thought about using PWM to do it and free the Pico from this task. However, I'm not sure it's "that easy" to do, since there seems to be some timings that are inter-related (clock display is turned Off before scanning change from column to column and things like that). Since more than one PWM signal are available on the clock and they all originate from the same basic clock, it may be possible to synchronize everything - if ever it needs to be - but I guess this requires some planing beforehand.

3. Multi-language translations:

Flashing languages to Pico's memory is a good idea. I could probably help someone to do it whenever someone volunteer to implement a new language. A separate tool to flash languages would then be required and since I worked this code (writing to flash) in Version 6.00, such a tool would be relatively easy.

Thanks again for your comments, Olav.

André

[olavandrade]

https://data.iana.org/time-zones/tz-link.html Have at it )) -olav

…

Sent from my iPad

On Oct 23, 2022, at 23:06, astlouys ***@***.***> wrote:  Hi Olav, Thank you for joining us and sharing ideas about the Green Clock and its firmware... A few words about "Daylight saving time" (DST)... I must confess something: when I first saw the Pico Green Clock on Amazon, I was looking for an electronic clock that could automatically handle DST since I was frustrated to have to adjust all the clocks in the house twice a year (yeah,,, I'll still have many other clocks and equipment requiring adjustment anyway, but...). When I've seen the Green Clock, I thought "great! if ever it does not support DST, I'll implement it!" So, you understand why I want it to be automatic and why it is one the first options I worked on (I added it in Version 2.00) - smile. The way DST is implemented in the code would make it relatively easy to implement other "standards" for different countries. If ever in ten years, someone needs a new standard that is not supported, in the worst case, he will have to manually adjust it (the same way I'm doing now with all the clocks throughout the house - too bad). That being said, I like your idea of a fast "increase" / fast "decrease" by one hour. To make it easier and faster. I may take a look at this after publishing Version 6.00. The main problem with the "basic" product is the limitation due of the three clock buttons. I may give it a first try with the remote control. As for the situation if ever politicians decide to keep the same time all-year round, this is already supported in current version (User guide of Version 5.00, page 20, section 6 - Option 0). I didn't have the chance to work with the Pico-W yet, but I will definitively give it a try, sooner or later. (my work on micro-controllers is simply a hobby, after all !). This should add the possibility to set the clock time using NTP.. As you mention, problem comes from the fact that we need to enter credentials, either at compile time, either at run-time but then, we need some device to do it. Let me know if you come-up with something interesting with the Pi Zero. LED refresh: I thought about using PWM to do it and free the Pico from this task. However, I'm not sure it's "that easy" to do, since there seems to be some timings that are inter-related (clock display is turned Off before scanning change from column to column and things like that). Since more than one PWM signal are available on the clock and they all originate from the same basic clock, it may be possible to synchronize everything - if ever it needs to be - but I guess this requires some planing beforehand. Multi-language translations: Flashing languages to Pico's memory is a good idea. I could probably help someone to do it whenever someone volunteer to implement a new language. A separate tool to flash languages would then be required and since I worked this code (writing to flash) in Version 6.00, such a tool would be relatively easy. Thanks again for your comments, Olav. André — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.

[UltrashRicco]

Hi guys,

1. Europe will switch to winter time on October 30th, whereas North America will switch one week later (one week difference, as usual). I knew about this discrepancy, yet I still enabled DST in my complie-time configuration, and my mother is going to be bothered with it...

Quick hour setting with the +/- buttons without even having to enter the time setting menu: why not, however having to change the time twice yearly is not much of a hassle either (to me at least).

The Pico W is an interesting way to go in order for the clock to fetch the current time, but apart from the WiFi connection wizard or SSID/password input required either at compile time or runtime, I believe it would also be necessary to input the user's timezone, right? It could be fetched from the IP address geolocation information though, I guess. Selecting a network and inputting long and complex alphanumeric WPA credentials from the clock itself could be a real pain. It would be easier to handle at compile-time, but it makes it less accessible of course.

2. LED refresh: not sure I understand the issue nor the benefit of delegating that to PIO in order to free compute time on the microcontroller (is it currently saturated with this task?), except for Olav's idea of putting together a "universal" clock FW that would be hardware-agnostic.

3. Localizations: i could live with plain English, and actually I did with the V1 FW, but localization is a nice touch for sure! I could help with a translation to Spanish.

[KaeroDot]

Hi, I have made a pull request with a new language, Czech. I would like to hear your opinion.

[astlouys]

Hello KaeroDot,

Yes, I did receive your modifications with the Czech language. You made a great job with it !

I was already working on version 10.0 at that time and Frank Seidel did send me translation for German language which I had already begun to integrate. While working on the German language, I realized that it would be a good idea to restructure the code to "standardize" a little bit more and make multi language support easier.

I was happy to receive your modifications since it allowed me to test the new structure and it proved relatively easy to implement Czech (I had to cut-and-paste your changes, though, since the new structure (and the new German language) would have conflicted with many of your changes. But the cut-and-paste was easy since your code was clear and well documented. I did fix a few "undocumented features" in your code at the same time (smile).

I had less time to work on the code in the past few weeks, but I may publish the new version without the "Reminders" (electronic post-it) as I was planning to do, in order to release it sooner. You will have to check the Czech translation since I admit there is not much I can do to test it (and understand it) myself :-)

André

[KaeroDot]

Wonderfull! Yeah, I thought you could be working on a new version, unfortunately I am not a C coder and it took me some time to make the translation. Maybe a developement branch updated regularly would be usefull, but it seems to me you are struggling a little with git?
I did try to make some standardization by using if/else if structures, but maybe there is some better way. In other languages I would make some subfunction to select proper text in proper language, but this was too big change for my zero knowledge of C language.

[astlouys]

You did a great job if you're not a C coder ! However, while implementing German, I mostly used "switch - case" statements. They give the same approach than the multi "if - then - else" but as a personal taste, I find the "switch - case" structure to make the code clearer. It should now be easier to add new languages. If ever flash size becomes a problem, we must consider selecting a specific language as a compile option.

[KaeroDot]

With switch statements I was not able to make a case for multiple languages, and this leaded to repeated code lines (that I do not like). E.g. day-month is common for French, Czech, German, Spanish, and month-day is for English.
Anyway, today I have found an error in my version of the code. After some time the clock switch from Czech to French by itself. If I set it again to Czech, it again switch back after more than 40 minutes. Maybe it is related to unavailable NTP server (wifi router switched off) but I am not sure. So I am happy you will make new version by yourself, because my one does not work correctly :)

[astlouys]

You can do the same with "switch - case", simply by adding more "case" (you will see in the code).

I've seen an error with language setting (as offset 0 does not work on the matrix, 2 being the left-most column) and also short names for months (or days, I don't remember) had a discrepancy between long name and short name. I didn't see a problem with language change, but I didn't make many tests so far...

You'll have to check that with the next release :-)

[KaeroDot]

Thanks for a new version!
I believe there is a bug: the debug.h is missing a definition of the DEBUG_REMINDER. This affects both release and developer modes.

If develooper mode is set, the compilation makes a warning:
".../Pico-Green-Clock.c:15897:33: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
15897 | DisplayBuffer[Loop1UInt8] = 1 << Loop2UInt8;"

Probably not really a bug, but it took me some time to understand - if developer mode is set, files CalendarEventsAndre.cpp and RemindersAndre.cpp are missing - maybe generic versions should be here. The same applies for Credentials.cpp at line 2284, I had to comment this.

[astlouys]

Hello KaeroDot,

1. As indicated in the User Guide, the "Reminders" are not implemented yet (in fact, they were fully implemented, but this is one of the things I lost in the source when my system crashed a few weeks ago). So, if you try to enable the debug for the Reminders, you may have many funny surprises (I left some parts of the Reminders source code that I re-coded, but by no means they are tested code for now). However, you should have no error and no warning while building the code if you leave the "#define DEBUG_REMINDER" undefined.

2. As for line 15897, it is part of the "Test section" of the code. As mentioned in the User Guide, this relatively huge chunk of code has been used while I was testing some algorithms throughout the development process. As the code evolves / changes, those tests are sometimes re-used and / or changed, but they are not maintained up-to-date. When the main "official" code evolves, sometimes a piece of test code becomes faulty (does not match any more changes made in the "main" source code) and should simply be erased or commented out so that it does not interfere with the compile process. As stated, I left this code for the benefit of the developers who want a skeleton to start their own tests.

3. The files that you report as missing are "my own personal files" to prevent publishing my own Calendar Events, my own network credentials, etc. When I compile my version of the Green Clock Firmware (as DEVELOPER_VERSION), those personal files are used. However, all what you have to do if you want, is to make a copy of CalendarEventsGeneric.cpp and call it CalendarEventsAndre.cpp. The format of the content is the same for both files, except that in the "CalendarEventsAndre.cpp" file, I actually put things like my family birthday dates, etc...

The same logic applies to RemindersAndre (but keep in mind that Reminders is still a work-in-progress and is even not in alpha state).

The "Credentials.cpp" lines may be simply commented-out in the source code while you uncomment and put your credentials in the 2 lines above.

Hope this help...

P.S. Let me know if the Czech translation is OK when you have a change.

[KaeroDot]

Ad reminders - when I try to compile the vanilla code (without any changes) I get error " error: 'DEBUG_REMINDER' undeclared" at line 2048. I just thought it should be possible to compile the unmodified code on the first time.

I am still testing the translation if all sentences are correct.

[astlouys]

Oups...

You're right KaeroDot. I didn't have any error on my side, so I thought you tried to work on Reminders... Then, I realized that debug.h was tagged as "4 months ago" on GitHub. It looks like I forgot to update it... My mistake. I just updated it, you should be OK now.

[KaeroDot]

Concerning the czech language, I have found error on lines 9593-9594 and 9599-9601. The special characters are added at bad position, and has to be added by counting from the end of the string, because strcat is used in previous lines. So the lines should look like this:

9593: String[strlen(String) - 9] = (UINT8)131; // i-acute
9594: String[strlen(String) - 7] = (UINT8)136; // c-caron

9599: String[strlen(String) - 15] = (UINT8)131; // i-acute
9600: String[strlen(String) - 9] = (UINT8)131; // i-acute
9601: String[strlen(String) - 7] = (UINT8)136; // c-caron

I have just tested it. See commit:
KaeroDot@cd80e7c

[astlouys]

Hi KaeroDot,

Thank you for taking the time to test the Czech language and reporting those two glitches. I'll take care of them for the next release.

I'll refer to the line numbers you indicated in version 9.02 since the source code has evolved since the time of this release.

[KaeroDot]

There are some minor details that could be improved, yet it is sort of nitpicking. Sorry, it is my field of expertise (metrology), so I have to comment it :)
The unit volt is written either as a symbol "V", or used in lowercase as "volts". E.g. code
sprintf(String, "%2.2f Volts ", Volts);
should be either:
sprintf(String, "%2.2f V ", Volts);
or:
sprintf(String, "%2.2f volts ", Volts);
There should always be a space between the number and the unit, e.g. code
sprintf(String, "Pico temp: %2.2f%cC ", DegreeC, 0x80);
should be:
sprintf(String, "Pico temp: %2.2f %cC ", DegreeC, 0x80);
There is no such unit as "msec", it is simply "ms".

[PaulBags]

Hello, and thank you! I was looking for a plug in kitchen clock that wouldn't lose time like cheap analogue battery clocks do - and your firmware made the Wareshare clock about 90% cheaper than a commercial NTP clock, at least compared to what I can buy locally.

The changes that I've made of any note are quite simple:

• Disabling brightness dimming now sets the brightness to 100 duty, I noticed that disabling brightness while the display was dim didn't reset it - nor is there any mechanism to change brightness manually. I'm just calling pwm_set_duty_cycle() directly before flag change, should possibly be in adjust_clock_brightness() instead.
• Short press of middle ("up") button in time mode now toggles display scroll.
• Altered the autobrightness logic because it was dimming a tad early for my liking. I wanted to keep the low end low so I divided by 2.0 instead of 3.0 and added an if to bring duty back to 100 if it went over.

On to ideas:

• While making those changes mentioned I noticed there's three different places where the same block of code exists for changing auto brightness setting, also I had to copy and paste a block of code to change button function. I'd like to see more bits of code broken out into functions to make behaviour changes and moving things around easier.

• I'd also like to see more (ideally all) settings broken out into compile time options - especially timezone.

• The button settings menu could perhaps be a few sub-menus, eg. SYS (Lang,KeyBeep,Scroll,AutoBright,TempUnit), TIME (Hour,Minute,24/12,Month,DoM,Year,SummerTime,TimeZone), DING (chime stuff), MOON (nightlight stuff).

For the PicoW specifically:

• Possibly add a stats scroll, e.g. I'd rather trigger a display of NTP errors manually than after date and temperature.

• Ability to set device hostname, based on board ID could be a simple way to keep it unique without recompiling.

Again, thank you, without you I'd still be looking for a new clock.

[astlouys]

Hello PaulBags ("Paul", I guess ?)

Thank you very much for taking the time to send your comments !

I'm glad you find my version of the Firmware useful (that's the goal !) But also thanks to Waveshare to come up with those products based on the Pico (PicoW) micro-controller. I hope they will continue to provide the users' community with more interesting products like that. Beside the Pico-Green-Clock and Pico-RGB-Matrix (also from Waveshare), I haven't seen other "finished" (or "end-user") products... :-(

Do you allow me to forward your comment about "cheaper NTP" clock to Waveshare ? I already received this comment a few times and I'm not sure Waveshare realize that they have a good product in hands (they don't publicize much).

Also, may I ask you from which country you are ? (always interesting to know that your code is running in different parts of the world.

A few words about your interesting comments:

• Brightness: The behaviour of the clock when we toggle from "auto-brightness" to "manual-brightness" was done on purpose, as indicated in the User's Guide (page 39 of Version 9.02). While on "auto", you can play (with your hands and / or a flashlight) to change the display brightness. Then, when you change to "manual", the brightness remain as it was while in "auto" mode. You do prefer to have it at 100% bright (which is fine), but if someone wants it to be dimmer (say, 50%), he can do it easily as explained. Of course, as you mention, it could be possible to add a "manual brightness setting". I guess I wanted to keep things simpler (smile).

• Display scroll with middle ("Top") button: That's a good idea. Personally, the Green Clock I use the most is physically located in a relatively "high" location, so I use a remote control to trigger the scrolling. But I like your idea which could be useful for those who have easy access to the clock (and / or that have not implemented a remote control). I may keep - and use - your idea for a future release.

• Auto-brightness: I thought about adding two parameters in the compile-time configuration: 1) Setting a limit to the lowest brightness. The clock now becomes VERY dim when ambient light is low. A user could specify to "not go below such a value". 2) As you did, in some way, establish some kind of threshold and / or slope at which to decrease (or increase) the brightness according to ambient light. Once again, I may refer to your comments to see how you did it and do something in a future release.

• Blocks of code: Of course, the code should be more "object oriented" than it is currently. I have to confess that I didn't build the code from scratch but instead I started from Waveshare's Version (that I called "Version 1.00") and if you've taken a look at it, it was not really user friendly... So, current code may suffer some flaws inherited from the code base. You know how it is... once you begin to get results, you focus more on "features" than on "re-construct the code". However, I tried to keep it as clean as possible as it evolves and I often work on cleaning some parts here and there as I go, which is in line with your comment.

• Compile-time options: Here too I tried to make things simpler for potential users. I thought that not all users are tech-savvy and I tried to group the options that could be easily understand and configured at the beginning of the code (as indicated and delimited in the source code). I may add a few more configuration parameters below this delimited section that could be useful for the "intermediate" to "advanced" users.

• Button submenus: This is already done... but with the remote control (smile). Using three buttons to cover all parameters / options that were implemented was a challenge ! It is much easier to use a remote control with many more buttons to do a better and more intuitive job. I also have something in mind that would involve a PC with a terminal emulation program... One user already suggested that a while ago. At the time, There were less items to configure, so I skipped the idea. But since more and more parameters / options / configurations are possible / required, this idea becomes more interesting.

• NTP stats: Again, this is covered with the remote control, but I wanted the users who can't rebuild the code to have access to this info.

• Hostname setting: Not sure I understand your idea... As far as I know, there is no "board ID" for the Green-Clock, so I supposed you refer to the PicoW ID. You seem to make some kind of relationship between the micro-controller and the network and I don't see it. Maybe my English lacks some language nuance...

Thanks again for your constructive comments. As a conclusion, I keep your ideas in the background and will definitely use some of them in the future releases...

André

[PaulBags]

Yes, definitely thanks to Waveshare as well. Personally I didn't want to do any soldering, I'd love to see more plug and go hardware for development boards. I was a little disappointed that the Pico WH doesn't quite fit with the debug port intact.

Pass whatever you like on to Waveshare, my comments here are effectively in public.

I'm in New Zealand. In the end I ordered parts from the UK though, I couldn't source any Pico WH locally. I'm not set up to debug anything, and I didn't manually check that DST is working - but assuming it's working for other people the code appears to be correct logic with correct values for me.

• I did wonder if the brightness behaviour was on purpose. For my needs though I'm either trusting auto, or I want to definitely be able to see it. As for considering what's best for the majority of users, that's not something I'm good at :).
• Although the pico green clock is versatile and could have a lot of functions, my intended use doesn't require access. Or anything beyond displaying accurate time. I mainly changed this button because I wasn't sure if the household as a whole would want the scrolling or not, this way there's nothing complicated if anyone wants to turn it off.
• Brightness setting could be adjusted from auto through 100 down to 0, and set floor and ceiling. Or it could be defined by time rather than auto, like the night light/chime: bright hours and dim hours. Though personally variations in daylight hours make that a non-starter for me.
• Personally I flunked out of my Bachelors in ICT and haven't touched code for a few years, and never worked with c before, I'm not really comfortable altering the logic yet let alone restructuring blocks of code. Waveshares' code was.. yeah I didn't want to sit down with google translate to read the comments and figure it out. I did enjoy misspelling month as mouth.
• I'm not a big one for reading, and got confused when I set my DST location and my timezone was still wrong `:). Perhaps standard time UTC offset could be set in the DST array, make it one setting (locale?) rather than two? Though that means adding DST_NONE countries to the array, and I'm aware microcontroller resources are at a premium. Disabling key beep is also a must for me, though I can kind of see why 'on' is the best default.
• I wonder if the settings menu could be a common function between 3 button and IR. The three button interface requires a next-up-down walk through but a remote could, for example - assuming a numpad - go to menu 2 option 3 and set (per my suggested order) toggle 24/12 hour time format. I haven't looked through the IR code though, I'm guessing it's more intuitive than already knowing what number option you want to change. If they have to be different control flows, but performing the same/similar functions, that's further argument for breaking out functions to be modified/maintained in one place - I'm thinking more model-view-control than object orientated.
• They'd still have access if it was moved, but I'll admit it was useful starting out to have it there by default.
• Yes, sorry, the PicoW ID; or rather PicoUniqueId. One of the first rudimentary checks I made of network function was checking my routers DHCP leases, to see that it made it through wifi and got an IP address assigned. Hostname, if reported by a client to the DHCP server, shows up in these leases. Having unique hostnames would make it easier to check on multiple clocks on the same network. I could also specify a specific IP address for DHCP to assign based on the hostname, and while that wouldn't be all that useful now it could be down the line - e.g. if configuration over network were added, or maybe just ping all my clocks and check they're still connected. I did stumble on this discussion, though I'm far from understanding enough to implement something like it.

I sometimes have ideas. Much less often do I implement them successfully, if they make any sense in the first place :). Happy to chuck ideas out there for consideration though.