n0bel
Discussion: PiClock² -- Made out of ?, Features are ?
TL;DR: Invitation to discuss the next generation PiClock
A while ago I created a new repository https://github.com/n0bel/PiClock2. It has had zero progress.
Much of the reason is that I'm having trouble deciding what it should be. The only three criteria that I am sure of is:
- Plug in based (modules)
- Browser based configuration option
- Theme and skinning ability
The remaining questions are fundamental design choices, such as:
Platform:
-
Stick with Python/Qt4
- Skins/themes based on Qt4 Style Sheets and a framework
- Plugins are python class modules
- Configuration is done by coding the MAIN module and instantiating plugin classes.
-
Take a cue from MagicMirror and use node.js and electron.
- Everything is Javascript and HTML and CSS
- node.js module framework for plugins
- Configuration via JSON
- Probably would require Pi2 as a minimum.
-
Make PiClock² a set of MagicMagic Mirror modules
- I've not seen a magic mirror module for animated radar
- Clock is already done
- Magic Mirrors seem to be less colorful (maybe thats my bias)
-
Some other choice or combination of choices.
Module Framework Design:
- How much should a module control the appearance/placement of data
- What is the best balance between data and its appearance
- example: weather provider 1 provides tide info, but weather provider 2 doesn't
- Stylesheets for data placement (and therefore dependancies on specific modules)?
- Stylesheets limited to colors of predefined "things", which modules then pick?
- What is the best balance between data and its appearance
So, lets get into it.. what should happen next?
/K
I am using PiClock on a touch screen display on my Pi 3. I had to not include the GPIO assignments in the setup instructions. I am a beginner when it comes to python, I think I can read it but I have difficulty writing it. I am in process of changing pieces of the program to fit my needs and likes. It is good that the images folder is not buried. I was able to find them quickly from the config file.
One thing that I would like to have is the ability to switch out APIs as I please easily. The weather API sprinted to 500 hits without doing anything, so I chose to remove it. I plan to replace it with either a Google Calendar API (so I can see my next important date) or some music API like Spotify (so it can be a clock radio). I do not know if this is possible with your PiClock 1, but I am going to try.
I'd REALLY like to have this contain alarms and a snooze functionality, in order to use as a bedside clock. add GPIO button support for snooze, etc.
In an effort to fan some flames I'll add more comments.
In my original comment I talked about using Electron and Nodejs, as a possibility. I've done some research and some testing, and come to the conclusion that Electron (which uses Chromium as a base) has a ton more cpu requirements than python with PyQt. Raspberry Pi 1's are not supported (possibly for this reason?).
Believe it or not, my original (unpublished) PiClock used a browser as its platform. Check this: http://n0bel.net/v1/index.php/projects/raspberry-pi-clock/8-raspberry-pi-clock-how-to-waste-a-saturday-afternoon
Chrome and or Chromium at that time barely ran on the Pi. The only thing that worked at that worked reasonably at that time was Midori. This initial version of PiClock ran on my wall (and a friend's too) for over a year. I decided to give it a face lift, and moved to a better weather api. Still it was all in the browser, with lots of nice look and feel elements added. At this point is when it started getting really slow.
You could see the second hand hesitate when it clicked to 12, as it had to update the hour hand. So I could see this was near the end of the capacity of the Pi 1. Also the gif images for radar started simply not looping alot of the time. CPU was generally around 80%, sometimes pinging at 100% briefly.
So in the last week or so I did some experiments with Electron and Nodejs on a Pi 3 I have. I added 2 gifs and some moving boxes to simulate a clock. It ran fine and used 50-60% CPU. PiClock runs on the same Pi 3 at 25-30% cpu.
I think this in itself is the decision maker for staying with Python and PyQt4. PiClock will only grow in features. I think it would be better to start at 25-30% cpu rather than 50-60.
So I think I've settled on the platform, that PiClock2 will use. I'll stick with Python. I'll probably switch to Python3, but I've not totally decided. Since Pi is the main target hardware, I'll go with the supported versions.
I'll also try to keep in mind other hardware platforms, possibly with their own install streams. I have some Orange Pi's and want to allow for
Please send comments!
I love the fact that you keep improving it Kevin. Keep up the great work.
I've created a dev branch in the PiClock repository, which will be for PiClock². I've deleted the PiClock2 repository.
This is more of a brain dump than a good discussion piece on the topic.
I don't think Electron and JS are the way to go, but it looks like @n0bel already talked himself out of it.
For Magic Mirror functionality, radar and colors probably aren't used because they wouldn't display well through the one-way glass. It would be interesting to try if someone's got a setup that they can actually test and see how well it works. If nothing else, having a blank background or just a theme dedicated to Magic Mirror (less colors, less lines, no background) may suffice.
PiClock gives me a feeling of the Unix Philosophy, of do one thing and do it well. Display a clock, weather, and radar given a low resource device like an RPi. Making this modular probably blurs this a bit, but I would argue the focus should remain to display a clock, weather, and radio at the core, everything else being modules/extensions. While this would ultimately result in pretty much a big rewrite, the approach may be better at implementing features rather than start from scratch. At some point though, it would ultimately result in a major version change, probably sooner than later.
I still like the idea of using weather libraries to be able to get results from various APIs, which would ease rate limiting for people like myself that don't want to pay for API access. This does require an abstraction layer to pull what you need out of that API, but there may be a smooth way to incorporate this with the plugin architecture that is discussed here and leave that up to the module creator. This also allows for features like those suggested of an RSS feed reader (#31), Music (#21), and there may have been a couple other I'm forgetting.
Some code things that I believe should have some level of priority as they may make it easier to install, debug, and contribute to:
- Refactor code to use setuptools (installable via pip)
- Use python libraries to take over functions currently done in bash (configargparser to handle config and arguments, logger to handle log files)
- Versioning (with auto update functionality?)
- Install script
- First time setup using google maps api to set locations and zoom fields
edited to remove the prevalent "I think"s spread throughout
So now I'm torn with which config file format to use... Python's included ConfigParser or PyYAML.
ConfigParser uses .INI like files. .INI?? maybe I'm biased, didn't we leave these behind sometime around y2k?
PyYAML uses .yaml files. These seem to me to be better.. arrays, dicts, etc. Simple to edit. White space dependency, however is not ideal for users.
I'd like to have the ability to serialize the config back out, while both have that, both would also suffer loosing the comments if I chose to use serialize write, if I do programmatic config updates. Maybe I shouldn't care about comments in the config?
Comments Please!
I'm a huge fan of yaml. A decent syntax highlighting text editor and a bit of experience seems to resolve issues of user-unfriendliness or complexity. But, still a learning curve over flat files due to the required indentation. I came to argue for ini config formatting, even used configargparser as an example in my previous comment.
.... Then I remembered that Config.py is a python file anyway. It's already got the complexity of formatting and indentation of Python, so moving to yaml isn't going to increase any complexity. The simplicity gained for the user of ini would be trivial considering the skills required to get to the point of installing this software (knowledge of git, python, Linux). And for complex configurations like the radar animations, the ability to structure that in yaml and handle it so easily on the code side really wins it over.
For the serialized config, comments in the config file might be best handled through documentation, including a sample configuration. Something like a config.yml and config.sample, with the .sample commented, not to dissimilar to the multiple configs it currently has.
That's my opinion, but I'm also interested in hearing other opinions/ideas.
I think we're in agreement. I'd like to see someone else throw in their two cents regarding .ini format or .yaml format.
We're also of the same mind on how to deal with the comment/serialization issue. There's something called 'ruamel.yaml' which preserves comments. It uses ordereddict objects, which I guess it would have to. Below is a sample. I'm not sure I'd want to use a less-than-mainstream module. But I could be persuaded.
import sys
import ruamel.yaml
yaml_str = """\
# example
name:
# details
# details2
family: Smith # very common
given: Alice # one of the siblings
"""
code = ruamel.yaml.round_trip_load(yaml_str)
code['name']['given'] = 'Bob'
code['aaa']='nnn'
print(code)
ruamel.yaml.round_trip_dump(code, sys.stdout)
I love this project and I am turning it into a present for my father. Keep up the good work.
A few things I would love to throw in for suggestions: Better GPIO configuration ability. love having the extra buttons, made cramming this into a 19" tv that much more slick, but some more control over what the buttons do would be great. I don't really see much need for more than 3, but allowing for more to be added on if need be would be nice. I have always been a man who appreciates options.
The next 3 suggestions sort of relate to my first suggestion as they could be assigned to button presses. more creative use of the background space. Although I do love someones suggestion to have various pictures relate to the weather outside (something that would be cool as an option along with my suggestion), I think using it like a photo frame style system with a changing photo would be cool. Now I understand that might create an issue with visibility of on screen elements or obstruction of the background image, but it would still be a nice option to implement. As it stands my only thought for how to do this would be to use chrontab to switch skins with different backgrounds.
Being able to soft shutdown with GPIO button. I have this running from the usb power on the tv, so it turns on the pi when the tv turns on. Being able to soft shutdown would make my fathers enjoyment during future use much higher.
Finally, I would love a little better software control of the RGB leds if for no other reason than to turn them on and off. Having a GPIO controlled button to accomplish this would be great. Maybe even a way to have them be on certain times of the day or at least a way to set the brightness. Sure a way to change patterns would be great, but other than suggesting I have no programming skills to help with that function. Although I am using this endeavor to learn a little bit more.
Thanks again, and I can't wait to see how this gets better!
Its been a while since I've added to this discussion. I've been experimenting with another small project for use on my Pi. Its a food scale, attached to the Pi with api connection to FatSecret, to help track you food intake. Its a personal project, however it will make it up to GitHub when its more functional.
I'm using it to explore several things. yaml configs. Python3. PyQt5. Worker threads instead of timers. All of these things will help make PiClock² better in the long run.
I think I've settled in my mind the structure of a "module" or "plugin" (haven't settled on a name yet), These will be how one will add features to the PiClock. The structure that I'm thinking about is that a module or plugin is responsible for both its data gathering (i.e. weather) and its visualization. In MVC terms it will have both the model and views. It can also just provide the model which another view can tap into.
The framework in which the module or plugin will reside in will provide screen placement, size and standard color scheme (themes)(stylesheets) hints that the view should use. By allowing a module to provide a view, specific data provider data can be shown, rather than having to reduce, for example, a weather provider, to the least common denominator.
I'm also thinking of providing a generic view generator, which would be based on config data only, such as a clock view, which would get its data from a clock model. I'll have to review the best way for events (new weather, time tick, etc) to be communicated to the views.
These are my rambling thoughts so far.
Since the food scale project is going well with Python3 and PyQt5, this will probably be the first task in the PiClock² task list, that is move the code to Python3 and PyQt5.
I'd like to see a function to turn the monitor off or sleep during the night and if it hasn't seen motion in some time. I plan to wrote a separate python script for that eventually, just an FYI
Also, it would be cool to show a small picture of the moon in each of its phases. I have added numbers to the clock face so I can use it to teach my kids how to read an analog clock (it's the only analog clock I've seen in years). I'm also teaching them how to read a weather radar. Currently it pulls weather data that I send to weather underground from my own weather station. I love this project, thanks so much for making happen!
I am interested in adding my Google Calendar to the display. Since it was brought up, a media player would be great as well!
I would really like to see these in another iteration of this project. I do not have any experience with programming, but I do like tinkering. If anyone can give me any direction on how to replace the radar with my calendar, I would appreciate it!
I built a diy weather station using a Pi, weewx, sensors and simple python code to read sensors. I'm thinking of modifying your code to use my wx data instead of WU. tnx 73 KD3SU
I did the same using the sparkfun weather shield. I send the data over a serial link to the rPi then use python to split it up and upload it to WU but it's a pain because WU occasionally errors out and stops the script so my weather data is always old. I can't use typical WU data for my area because the weather reports are very vague in the mountains. Going direct to the clock would be excellent
On Mar 17, 2017 16:30, "hamradiovoip" [email protected] wrote:
I built a diy weather station using a Pi, weewx, sensors and simple python code to read sensors. I'm thinking of modifying your code to use my wx data instead of WU. tnx 73 KD3SU
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/n0bel/PiClock/issues/54#issuecomment-287495701, or mute the thread https://github.com/notifications/unsubscribe-auth/AQDWAvUocUYcB1iPWNV0iXLD2H7-bWigks5rmxd7gaJpZM4L3l2q .
I've setup a github Project and started adding ToDo's for PiClock². Remember that the dev branch is for PiClock² development. https://github.com/n0bel/PiClock/projects/1
#64 is done, Python3/PyQt5 port of the clock. I've created two more issues to handle updating the temperature server, and NeoPixel process. Remember that PiClock² is on the dev branch.
I've had PiClock up and running since xmas '16 when I had some time to spare before visiting the in-laws. Enjoyed it since.
I say if its not broken, don't reinvent it. I know nothing about the difference between python2 and python3. If python3 has more options to add more to PiClock, go for it. If not....
I changed the F2 key to open a internet radio stream instead of the NOAA radio streams as have been mentioned were unreliable. The one request I would ask for is more function key be enabled in the code.
I am not a programmer at all but I usually have some luck looking at code and finding the one string or part and than modify it to either do a little bit more or add something to it. No luck here on my part yet but I haven't given up yet either. I'll probably end up asking for some friends at the college (Henry Ford, Dearborn) who do programming to help out in the Fall.
As for the media player, I was introduced to mpg123 with this project and like it as it seems to be simple and works. I have used mpd/mpc in the past for an internet radio streamer. There are a few google play apps available to control it if that is a way to go.
As for the background, persoanlly I would like to see a way to access the ISS HD video streams from ustream using omxplayer. Do a google search for "ISS HD ustream raspberry pi" to find a write up on how that was setup.
BTW - using my PiClock on a model a+ for the past three months with no problems/slowdowns.
I would love to see alarm functionality added. I have a 5" HDMI monitor connected to my Rpi3 and would like to use PiClock as my nightstand alarm clock..
Really like the Pi Clock! Thanks for sharing!
Since I live at the beach, I added another hand to the analog clock, making it also a tide clock. It works great with the tide data coming from NOAA via JSON. I do need to do another dial face indicating the tide movement time.
I have it running right now on a Pi Zero and use VNC to display it full screen on other PCs and tablets around the house.
Again, thanks!
I use piClock on a Touchscreen in the kitchen where i also run the interface to FHEM (https://fhem.de/) and display a GoogleCalendar or play music using QuodLibet.
so it might be a better handling if i don't need to Stop piClock when i want to switch to another view. (e.g. if it would be displayed as a webpage i would just need to switch tabs of the webbrowser)
Hesitated to add this, as this is not updated is a long time, but still add . . .
Regarding the configuration, I'd like to add the possibility to include nested configuration files.
As example: a Config-day and Config-night both describing how the clock should look
And these configs both use a separate Config-common that describes the location / locales to use.
The best would be if the main PyQtClock does not need to know in what config a variable "lives"
