Difference between revisions of "LED Sign"

From Makers Local 256
Jump to: navigation, search
(add informational endpoint)
(add requirement for it to be small.)
 
(One intermediate revision by one user not shown)
Line 1: Line 1:
 
{{Project|Creator=brimstone
 
{{Project|Creator=brimstone
|Status=<onlyinclude>Prototype of new version completed</onlyinclude>                                <!--LEAVE ONLYINCLUDES FOR STATUS HACK-->  
+
|Status=<onlyinclude>Planning</onlyinclude>                                <!--LEAVE ONLYINCLUDES FOR STATUS HACK-->  
 
|Born On=the beginning of time                                                                  <!--DO NOT EDIT -->
 
|Born On=the beginning of time                                                                  <!--DO NOT EDIT -->
 
|Last Updated={{#time: H:i, d F Y| {{REVISIONTIMESTAMP}} }} (CDT)              <!--DO NOT EDIT -->
 
|Last Updated={{#time: H:i, d F Y| {{REVISIONTIMESTAMP}} }} (CDT)              <!--DO NOT EDIT -->
Line 8: Line 8:
 
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 [https://github.com/msparks/alphasign python library for Alpha American and Betabrite signs] will drive it just fine.
 
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 [https://github.com/msparks/alphasign python library for Alpha American and Betabrite signs] will drive it just fine.
  
The old code was written by [[User:brimstone]], I believe, before there were really libraries out there for using the sign. So the protocol was written into the script by him. I ([[User:hfuller]]) wrote the current Python version, using the library.
+
Old versions:
 +
* [[LED Sign/v1]]
 +
* [[LED Sign/v2]] (current production)
  
It's also now integrated into [[RQ]] for the !alert functionality. It subscribes to <code>ml256/irc/+/command/alert</code> to respond to alert commands in IRC, and it publishes to <code>ml256/bigsign/alert</code> whenever an alert is displayed. More information can be found on [[RQ#Big_Sign|the RQ page]].
+
== Goals for this version ==
 
+
* Be completely driven from mqtt.
To make informational messages appear on the sign in a distinct and less annoying fashion, publish instead to <code>ml256/info/(anything)</code> a message with this format: <code>{"source":"description of the thing sending it", "message":"the message goes here"}</code> - you are encouraged to use this for any random stuff you want to tell the entire shop about.
+
* 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.
== Status of new code ==
+
* Support "signcode" (formatting instructions like {green}).
 
+
* Run on a Raspberry Pi so it can be physically contained in the sign itself.
[https://github.com/makerslocal/bigsign]
+
 
+
This code does the same thing the old code did, with a lot of sweetening for the !alert stuff. It also utilizes the sign's clock functionality to allow it to update on its own, even if the computer explodes. However, there is still a script called 'graph.bash' from the old code that is run every five minutes to graph the temperature data, as well as write the current date, temperatures, blurb message, and ping time to a file. The python code just reads that file from disk to display it. This needs to be made more efficient but it's Good Enough(tm) for now.
+
 
+
== Goals ==
+
* <s>Continuously update the sign in an "inexpensive" way so we can have a more accurate clock and other readouts.</s>
+
** This is done to an extent. More stuff could be updated using strings (the more inexpensive way, basically - embed strings in the page and then update the strings)
+
* Add extra screens for stuff like alert and other messages.
+
* <s>Expose all relevant functions over REST, especially the extra screens for alert functionality.</s>
+
** Superseded by RQ
+
* Tie the extra screens into RQ.
+
* figure out sign graphics protocol and test.
+
* Contribute graphics extensions into upstream library.
+
  
 
== Notes ==
 
== Notes ==
* [http://blog.miguelgrinberg.com/post/designing-a-restful-api-with-python-and-flask REST API notes]
 
 
* [http://www.alpha-american.com/alpha-manuals/M-Protocol.pdf Alpha sign protocol]
 
* [http://www.alpha-american.com/alpha-manuals/M-Protocol.pdf Alpha sign protocol]
  
  
 
[[Category:Hardware]] [[Category:Software]]                                                  <!--MAKE AS MANY CATEGORIES AS YOU NEED-->
 
[[Category:Hardware]] [[Category:Software]]                                                  <!--MAKE AS MANY CATEGORIES AS YOU NEED-->

Latest revision as of 20:25, 24 July 2017

Creator:
brimstone
Status:
Planning
Born On:
the beginning of time
Last Updated:
20:25, 24 July 2017 (CDT)

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:

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.

Notes