marqsm / led-bot Goto Github PK

We need to setup a debian startup script.

What it needs to do:

1. Install the Octoscroller cape Device Tree Overlay, it lives in /lib/firmware the command to use is

echo CAPE-BONE-OCTO > /sys/devices/bone_capemgr.8/slots

You can cat /sys/devices/bone_capemgr.8/slots to see what's installed

1. Run the LEDscape opc-rx listener

~/LEDscape/bin/opc-rx > /dev/null 2>&1

3.Run the bot-scheduler

~/LED-bot/bot_scheduler.py

Do we have simple instructions that explain how to run a local dev/test environment?
If we don't we could write some up. I noticed even i'm slightly confused as to how to test my stuff (in a hurry & didn't want to commit blindly :) )

When someone opens the front door, say

' WELCOME BACK, 24601! #{random_compliment_or_motivational_generator()'

let people register with their rfid tag.

this only works of the tags are unique

Images often appear too bright or with low contrast. Pillow has a bunch of image filtering methods, lets try to find some parameters that work better on the screen!

Parse emoji from text strings and render them on the screen. Possibly helpful, list of Zulip emoji strings, images seem to live at https://www.zulip.com/static/third/gemoji/images/emoji/EMOJI_STR.png, the PIL paste method

document the hardware and software build process so it can be reproduced

Add a command to kill the current item, or everything, in the queue (in case of spammer take-over, emergencies, overflows, or other unpredictable circumstances)

Add some basic logging, see kudos bot for example

It seems some PNG images break the image loading.

This fails (8 bit / RGB):
http://cdn.wikimg.net/strategywiki/images/f/fc/Contra_NES_sprite_player2.png

This works (8 bit / indexed):
http://img1.wikia.nocookie.net/__cb20090404163326/finalfantasy/images/6/64/Firion_NES_sprite.png

Here's a list of different kinds of PNG images for testing. They are included in the test-folder also.
http://www.schaik.com/pngsuite/#basic

I opened this issue to discuss long term ideas for this application!

Some day, in the future, if we were to refactor to remove Zulip code from the core and make it really modular it could suit a variety of LED installations and inputs (web interface, IRC, Zulip, Slack, SMS, etc).

Inputs -> Processing, Queuing and Scheduling -> out via Open Pixel Control

We could have a REST API something like

https://ledbot/status
https://ledbot/text?message=hi hi hi
https://ledbot/image?image=http://image.url or file

Thoughts?

It could be really fun to integrate the LEDs with Doorbot, when someone successfully opens the door it enqueues and displays a message, [Greeting] [Person]

Responses like "JUST GIVE ME A SEC I'LL SHOW YOUR STUFF WHEN I CAN!
WE'RE ALL UNDER A LOT OF PRESSURE HERE!!!" are sent to everyone instead of just the sender, when sent on a stream instead of a private message.

first source from hackerschool.com/projects

but maybe integrate with a #hsworkingon from twitter

I did

sudo pip install virtualenv
virtualenv ~/.pythons/ledbot
source ~/.pythons/ledbot/activate

Last one returned an source: no such file or directory:-error.
Should the virtualenv manager create the activate-file or where should it come from?

Currently you need to type:

led-bot show-text <your text>
led-bot show-image <your image url>

To display things. Marcus and I discussed simplifying things. Perhaps we could do something like:

led-bot image <your image url>
led-bot <your text>
?

Implement directional scrolling, display at center, etc for images

Currently reads subscriptions.txt - when new zulip-threads are created, they are not automatically added.

The app needs a better mechanism for subscribing to all zulip threads.

Currently the IP of the beaglebone running the LED-screen is just hard-coded in bot_scheduler.py - this is not a stable solution (because of DHCP etc). It should always default to ledbone.local in local network. This should be tested.

Let users customize text color and background. Maybe look at Brian's Memebot, which parse parameters from Zulip messages

When the screen is relatively idle, display filler information like weather, quotes, ...

for 30 seconds or until some other message gets queued up

I've had success with the TP-LINK TL-WN722N Wireless but it should be tested more as it requires a relatively recent kernel, and I have no idea how to get the PRU working on newer kernels.

There's probably better adapters out there, suggestions?

Reply with an estimate of the time before we the message/image sent would be displayed.

We need to setup a 64x32 grid, see http://openpixelcontrol.org/

Add HTTP-based listener to the bot, this would make it easy to send messages to LEDBot via other projects (doorbot, etc). A simple Flask server or something would probably work! Take a look at zulipRequestHandler and cli_handler

Set a max length on the length of text messages that can be sent to the bot.

This bot monopolizes the connection to the Open Pixel Control socket. At some point I imagine folks will want to stream cool Processing sketches, Canvas games and other visualizations to LEDs in addition to what LEDBot can provide. Create a command that can get / toggle state of OPC connection. If inactive messages will queue up for later.

Currently upon receiving a textual message we just go to an infinite display loop.

We should have some kind of mechanism for handling incoming messages systematically (a queue probably?) and some kind of event emitter, scheduler or something that would trigger the next task when the time is right.

This one is for the systems programmers / C hackers out there!

Andrew pointed out that Open Pixel Control is communicating over a TCP socket, which is really unnecessary for this application. We're currently using this server code on the Beaglebone

LEDscape, which deals with lower level stuff, has a UDP option, but the protocol is a bit different. If we keep things in the OPC style this application would be more easily compatible with other LED products and existing OPC adapters. This fork of LEDscape has an improved OPC server with a UDP, but is designed for different LED hardware (WS2812 strips in a grid, rather than 16x32 panels of the type we are using) so adaptations will probably need to take place.