Difference between revisions of "LED Sign"
From Makers Local 256
(Replace page with prototype for new version.) |
(add requirement for it to be small.) |
||
| Line 17: | Line 17: | ||
** For instance, pushing a message to a certain screen will be done by publishing to the correct mqtt endpoint. But the sign will not listen to any endpoints except its own - an external app will have to, for instance, listen to CasCADE messages and publish them to the sign in a modified form. | ** For instance, pushing a message to a certain screen will be done by publishing to the correct mqtt endpoint. But the sign will not listen to any endpoints except its own - an external app will have to, for instance, listen to CasCADE messages and publish them to the sign in a modified form. | ||
* Support "signcode" (formatting instructions like {green}). | * Support "signcode" (formatting instructions like {green}). | ||
| + | * Run on a Raspberry Pi so it can be physically contained in the sign itself. | ||
== Notes == | == Notes == | ||
Latest revision as of 20:25, 24 July 2017
|
Creator: |
Overview
There is a giant LED sign at the shop. I am very lazy so I am not going to tell you what kind it is. However, I do know that the python library for Alpha American and Betabrite signs will drive it just fine.
Old versions:
- LED Sign/v1
- LED Sign/v2 (current production)
Goals for this version
- Be completely driven from mqtt.
- Split out the logic into two parts: the display part, and any "processing" tasks.
- For instance, pushing a message to a certain screen will be done by publishing to the correct mqtt endpoint. But the sign will not listen to any endpoints except its own - an external app will have to, for instance, listen to CasCADE messages and publish them to the sign in a modified form.
- Support "signcode" (formatting instructions like {green}).
- Run on a Raspberry Pi so it can be physically contained in the sign itself.
