HackTouch 2.0: Difference between revisions
Jump to navigation
Jump to search
(Add HackTouch picture) |
m (Fix external links) |
||
Line 2: | Line 2: | ||
HackTouch is a lab-control-interface writen in ruby. The previous version (1.0) was written in a mix of non-OSS technologies, and was not maintainable by the majority (if not all) of the current lab membership. To remedy this and make the system maintainable and extensible by the lab's current membership, we've rebuilt the functionality into a new system, HackTouch 2.0. | HackTouch is a lab-control-interface writen in ruby. The previous version (1.0) was written in a mix of non-OSS technologies, and was not maintainable by the majority (if not all) of the current lab membership. To remedy this and make the system maintainable and extensible by the lab's current membership, we've rebuilt the functionality into a new system, HackTouch 2.0. | ||
You can find the code for this project here: | You can find the code for this project here: [https://github.com/hacklabto/hacktouch] and here [https://github.com/hacklabto/HackTouchUI] | ||
Latest revision as of 02:21, 2 July 2014
HackTouch is a lab-control-interface writen in ruby. The previous version (1.0) was written in a mix of non-OSS technologies, and was not maintainable by the majority (if not all) of the current lab membership. To remedy this and make the system maintainable and extensible by the lab's current membership, we've rebuilt the functionality into a new system, HackTouch 2.0.
You can find the code for this project here: [1] and here [2]
Functionality
- Main:
- Clock
- Music Controls (Volume, stop/start)
- Streetcar times
- News
- Music Player
- Control playback
- Select stream
- Todo: Pass currently playing info on to the LED Sign
- Door log
- Todo: integrate with the wiki instead of keeping its own database of photos
- News
- Weather
- Polled from Yahoo Weather API
- Streetcars
- Polled from Nextbus API
- Kittens
- Polled from kittenwar
Technologies Used
Backend
- Ruby (all/most daemons are written in Ruby)
- RabbitMQ (AMQP broker used to link all backend/frontend systems)
- VLC (used for playing media, launched/controlled by hacktouch_audiod)
Frontend
- Ruby (the server-side code is all Ruby)
- MooTools (used for client-side functionality for AJAX and UI-prettyness)
Hardware
- Small shuttle system (Athlon single core system)
- PXE boot
- Radeon graphics card
- Running Arch Linux
- Touchscreen
- Serial old SFP touchscreen. Found protocol, wrote driver using uinput. See: [[3]]
Future Planned Functionality
- Today's Events
- Display the events for the current day (and maybe the next?) from the Google Calendar
- Audio selector
- Desk audio port would to HackTouch 2.0's Line In, and when audio is detected on it the system would stop/pause any currently playing media and route Line In to the amplifier.
- Projector connectivity
- Projector "remote control" for on/off
- Display bulb life and end-of-life warnings
- Add a second VGA/DVI output and connect it to the projector
- Extend media playing interface to be able to play videos on the projector via HackTouch
- Demo mode
Ideas/Resources
- Panic's Status Board is very nifty, may want to model some of the UI along these lines?
Further details
Startup
- /usr/lib64/systemd/system/sfp.service -> Script for touchpanel
- Slim configured to start x automaticaly and log in as hacklab (/etc/slim.conf)
- Hacklab's ~/.xinitrc launches hacktouch code + chromium
Initial Architecture Ideas
- Backend written in Ruby (much of the lab knows and uses Ruby)
- Web-based frontend to handle all user interaction
- Rails seems like overkill for this, it's bigger and more complex than we need, and more database-oriented.
- Sinatra seems very lightweight and quick/easy to learn/understand. I'm looking at the possibility of using this instead.
- Simple HTTP interface for new plugins
- Message queuing for connection between frontend and backend
- AMQP seems to be the way the industry is going, and is well supported with Ruby.
- RabbitMQ is already in use at the lab for doorbot, so might as well go this route.
- Flock of specialized daemons approach
- hacktouch_audiod
- Consume messages from hacktouch.audio.request queue for volume up/down, mute, play, stop, etc.
- Publish messages to hacktouch.audio.response queue for responses to status check commands
- Publish messages to hacktouch.audio.song queue when the playing song changes
- hacktouch_newsd
- Fetches/caches/refreshes news stories of interest to hacklab members/visitors
- Consume messages from hacktouch.news.request queue for news requests
- Publish messages to hacktouch.news.response queue for news stories
- hacktouch_signd
- Consume messages from hacktouch.audio.song queue and write to the LED Sign
- Really this just needs to be a 'queue joiner' because the notification.text exchange already writes to the sign, so we just have to pull from hacktouch.audio.song and feed to notification.text
- hacktouch_doord
- Consume messages from hacktouch.door.request queue for door log inquiries
- Publish messages to hacktouch.door.response queue for responses to door log inquiries
- hacktouch_weatherd
- Fetches weather information
- Consume messages from hacktouch.weather.request queue for weather inquiries
- Publish messages to hacktouch.weather.response queue for responses to weather inquiries
- hacktouch_audiod