No announcement yet.

LED Messaging Sign

  • Filter
  • Time
  • Show
Clear All
new posts

    LED Messaging Sign

    Click image for larger version  Name:	sign.png Views:	0 Size:	306.3 KB ID:	1314463

    I have completed my development of the LED message sign that accepts MQTT display requests and shows them on the sign. My development configuration is a 16 x 40 pixel sign using neopixels that were obtained from The ten tiles were arranged to be two high and five wide thus giving a 40 pixel wide by 16 pixel high sign of dimensions 13 inches by 5.5 inches. Any size sign can be constructed with the constraint being the size of the power supply used for driving the pixels. I typically run 3 amps for images and much less for text.

    It is interfaced to an ESP8266 and specifically a Wemos D1 mini in my case. It will display colored text in each of two rows and scroll the text when it does not fit. It will also display jpeg images and pan these when they do not fit. In addition it will put pull weather data from Open Weather Map when no other info is being displayed in the bottom row. In the image one can see a Friday forecast of over..cast clouds and an externally requested multicolor text of "Short"

    It is developed under Tasmota so other Tasmota features are available to piggy-back if so desired. Naively the DH11T is used to provide the current temp/humidity while the 5 day forecast is being displayed.

    My initial attempt was with ESP32, but was disappointed the the RTOS that comes with ESP32 could not reliably provide the timing necessary for smooth scrolling. This is in spite of an entire CPU being dedicated to this function. Of course nothing wrong with ESP8266 as they are cheaper and smaller. I was just on a roll from the ESP32 BLE effort.

    My next step is to update mcsMQTT to make it easier to use in a HS context. It can be used now with any MQTT plugin based upon the API that is provided at Section 15.17.

    In the plugin I will be adding image processing features that will take general jpeg files, size them for use in the sign and download the resultant image. I will also being augmenting the HS event actions to include the sign as a destination. I am open to other suggestions for how others may want to use such a sign.

    this is really impressive ! I might give my smartledmessenger ( it receives http get commands and it is only available in one color) to my mother. I'll play with this , this summer, if i can plunge into the ESP8266 world..

    This is bigger than the one i have now... + have image processing + colors!

    Suggestion :

    #1 Maybe a way to format actual hs3 devices by mcsmqtt,. So, one can send a message directly to the panel from the hs3 device page ( or from hsmobile) without having to send/create an event.

    E.g I know my GF is at home. And i want to send a message on the led. So i pick up hsmobile and send a message directly from there ( from a device created by mcsmqtt).

    #2 Another way to do this would be to have prefigured responses already set by event. So when i press on of the button of the device, it sends something to the led sign.

    I think #1 is more flexible ( #2 would be done by your new event actions, or by send a mqtt message) but not sure it would be easy to mess with device creation to allow sending a message ''on the go'' to the panel .


      Let us say the plugin has a page that allows a sign device to be created with the color, row and duration properties and when the DeviceString of the device changes then it is sent to the sign. In this #1 case the user would need a means to store the desired text in the DeviceString which is done as a text box on DeviceManagement.

      Another scenario #2 is that the plugin creates a device that includes the DeviceString and when the "Send" button on DeviceManagement is pressed the message (or image file contained in DeviceString) is sent.

      Consider a scenario #3 such as Caller ID being available from HS and it is to be sent to the screen when a call is received. The CID will be contained in a non-plugin DeviceString. If this device was Accepted in mcsMQTT and the DeviceString changes then the DeviceString is published per sign formatting template that is added to Edit page. In this case substitution variables e.g. $$STRING: could be used as part of the sign template so mcsMQTT know from where to pull the text. The duration parameter in this case would likely be relatively short such a one minute since the CID info only has immediate use.

      Consider scenario #4 with use of the HS Log information so when something goes to the log it also goes to the sign. The plugin would have ability to filter the messages by Type/Error or to use this log attribute to change color

      Another example #5 is with an irrigation plugin such as mcsSprinklers where the current zone being irrigated is displayed on the screen or the predicted date/date of the next irrigation cycle. In this case the mcsSprinklers plugin script function needs to be called to get the device code / name of the desired zone and then from the script one would use the mcsMQTT plugin function to send a MQTT message per the JSON format expected by the sign.

      Case #6 is to display current energy consumption where a HS device contains in DeviceValue the daily energy use. The implementation is the same as #3 but the substitution variable setup will be $$VALUE:. The message is sent each time the DeviceValue changes.

      Case #7 is where multiple status data is to be shown on the same row and the sign round-robins through them. This could use any combination of the other scenarios where the same row attribute of the sign is used. For this case one needs to be aware of the limit of twelve retained messages in the sign.

      Case #8 is an example of a graph being shown that shows the hourly energy use. The jpg graph is periodically refreshed and recognized as new file change date. When the date changes the image will be sent to the sign. Similar concept for a camera that creates snapshots on motion. This may not be effective depending upon what is contained in the image vs. the sign pixel resolution. At least jpeg uses color shades to improve effective resolution.

      Please comment on these ideas and add other useful applications


        I have completed the plugin updates for the Messaging Sign. Located at and separate document at

        Some changes to the API were made to be able to better integrate with HS, but otherwise follows the concepts that were discussed above.

        Three areas of change to the plugin. The Pub List tab has been expanded to include the overall configuration of sign operation. This allows the general parameters used by the sign to be modified. It provides the ability to send HS Log entries to the sign and to monitor a folder for image file changes that will be sent to the sign.

        Click image for larger version  Name:	Capture1.PNG Views:	0 Size:	69.0 KB ID:	1315327

        The second is with a new Control/Status UI type called Sign. When selected then the API of the Sign is used as part of the publish activities. The sign has twelve message buffers and one image buffer. Each of these has a status and control that is available on Device Management. The control buttons select which of the rows will be used to display the message.

        Click image for larger version  Name:	Capture3.PNG Views:	0 Size:	8.8 KB ID:	1315328

        The third is a Sign Parameters popup that is available from where the Sign Control/Status UI is selected. The popup allows the default properties of a message or image to be defined. This properties setup can be used with any non-Plugin or Plugin device.

        Click image for larger version  Name:	Capture2.PNG Views:	0 Size:	15.3 KB ID:	1315329

        An extract from the manual for some use cases is shown below to give some ideas on how it can be used.

        1.1.1 Messaging Sign Use Cases

        The following discussion provides concepts of how mcsMQTT can support use of the Messaging Sign. In all cases HS devices will exist with the Control/Status UI having been selected as the type. For plug-in devices this is the radio on the Edit page. For non-Plug-in devices this is also a radio on the Edit page label “Publish To Sign” as shown on Figure 7. Send Text to Sign when HS DeviceString Changes

        When the DeviceString of any HS device receives a change in its content then the text of the string will be stripped of any HTML encoding and sent to the sign. The duration that the text will continue to be displayed, color information and the row on the sign and on the sign are setup from the “Configure Sign Parameters” hyperlink on the Edit tab. See Figure 7 and Figure 8. The topic used is taken from the Publish topic that is setup on either the Edit tab or the Association tab.
        If the Sign’s corresponding status topic has been associated to a HS device then the Sign will acknowledge receipt of the text by echoing the row number on which the text was displayed. For example, if published to topic LEDSign/cmnd/TEXT2 then the Sign will publish acknowledge status on LEDSign/TEXT2. If the duration countdown expires then the Sign will again publish LEDSign/TEXT2 but in this case the payload will be 0 to indicate that the text is no longer being displayed on the sign. Augmented Text to Sign when HS DeviceString Changes

        This scenario is the same as the first scenario but additional text is added to the DeviceString content to provide context of the text. An example is Caller ID being available from HS and it is to be sent to the screen when a call is received. The CID will be contained in a non-Plug-in DeviceString.
        In this case the Publish Template from the Edit page is used to provide a prefix “CID:” along with substitution variable $$STRING:. The Publish Template text box would look like “CID:$$STRING:” mcsMQTT would then pull the DeviceString text and append it to the “CID:” prefix before sending the Sign. The duration parameter on the Sign Parameters popup (Figure 8) in this case would likely be relatively short such a one minute since the CID info only has immediate use. After one minute the Sign will remove the CID message. Send Static Text to Sign

        Consider a scenario where the text to be sent is predefined such as “Amber Alert” and an HS DeviceValue changes when the “Amber Alert” is occurring. The HS DeviceString will be null and the Publish template will be null. The Default Text in the Sign properties popup (Figure 8) is set to “Amber Alert”.
        For discussion let us use the LedSign/cmnd/TEXT2 as the Publish Topic and Sign Duration of 65535 to indicate that the message will continue to be shown until manually removed. The plug-in device “A”ssociated with Topic LedSign/TEXT2 will have a “Off” button that can be used to do the removal. Alternately the DeviceValue of the plug-in device can be set to 0. Either of these actions cause a LedSign/cmnd/TEXT2 Topic to be sent with a payload containing a JSON content of Duration being 0 that supersedes the 65535 minutes originally sent. Send Text to Sign via Script

        In this scenario consider an irrigation Plug-in such as mcsSprinklers where the predicted date of the next irrigation cycle is desired. In this case the mcsSprinklers Plug-in script function needs to be called to get the predicted date and then from the script one would use the mcsMQTT Plug-in function SendSignMessage to send a MQTT message per the JSON format expected by the sign. See Section 5.4 for information on the scripting within mcsMQTT.
        In this scenario the script formats the text as desired before passing it along with the parameters for row, duration and color used in the SendSignMessage Plug-in function. There is no dependence on any other HS device for this operation to function. Status feedback from the Sign does continue to be provided in the HS device “A”ssociated with the corresponding TEXT or PTEXT topic. Send Augmented Text to Sign when DeviceValue Changes

        In this scenario consider a HS DeviceValue that contains the daily energy use that is updated every minute. The implementation of this scenario is the same the one described in Section except the substitution variable is $$VALUE: rather than $$STRING: to indicate that mcsMQTT should pull the value from DeviceValue rather than DeviceString.
        Each time the DeviceValue changes an updated message will be sent to the sign to replace the one that was previously viewed. In this case the Sign Duration parameter could be set to something like 2 minutes so the message will be removed from the sign if it becomes stale. Send all HS Log Entries to Sign Generated by Specific Plug-in

        On the Publist/Sign tab Messaging Sign Setup section is a text box where a regular expression can be entered to specify a filter for HS Log entries. If, for example, the plug-in of interest is mcsSprinklers then it will place the text “mcsSprinklers” in the Log’s type/error column. This is what would be used in the regular expression to indicated any occurrence of this text.
        At this same location is a radio to enable use of the HS log as source of messages to the Sign.
        The TEXT8 topic will be used for HS Log publications to the Sign. The Publish Topic will be setup to be something like “LedSign/cmnd/TEXT8”. The Sign Parameters popup ((Figure 8) contains a radio to select HS Log entries to be sent to Sign.
        The other Sign parameters should also be setup as desired. In the HS Log case the Color parameter is ignored and the color used by the HS Log will also be used by the Sign. Send Jpeg Image to Sign

        A Topic similar to “LedSign/cmnd/IMAGE” is used to deliver an image to the Sign. The image will supersede any text that is currently being displayed. A subsequent text message to screen will remove the image from the Sign.
        The jpg file name can be contained in DeviceString or Sign Properties popup Default Text property. When a DeviceString changes, mcsMQTT will look at the last four characters for “.jpg” and send the file content rather than sending the text. If the file does not exist then nothing will be sent.
        All the methods described in the text-oriented scenarios can be used for images but the Publish Topic should use the IMAGE rather than the TEXT or PTEXT keywords Automatically Send Updated Jpeg Charts to Sign

        On the Publist/Sign tab Messaging Sign Setup section is a text box where a file name or a folder name can be entered. mcsMQTT will monitor this location and every ten seconds when the last change date changes for a .jpg file then it will scale the image and send it to the Sign. The remaining setup is the same as used from HS Log monitoring described in Section except file monitor radio is selected and the only other Sign parameter of interest is the image scaling percentage.
        If a folder is being monitored then mcsMQTT will select the most recent file if multiple files change in the last ten seconds. Charts that have fine detail will perform poorly with this use due to the resolution of the Sign. Things like Area and Column charts will have more success than Line or Scatter charts.
        I am repackaging the physical sign and will update the manual with pictures that show its construction. My sign is 16 pixels high and 40 pixels wide, but any practical size can be constructed. The LEDs I used consisted of 10 8x8 pixel tiles with three wires going to each tile. This means 30 solder connections for which I used Cat 5 (24 gauge) wire. I have seen others use the LED light strips which are cut to the desired length of the sign. This could result in fewer solder connections needed. I see 16x16 panels that look to have connectors between panels so the only additional wiring needed is to supply power to each panel.

        I included a photo-resistor so that the sign intensity will be reduced based upon ambient light. I also included a DH11T temperature/humidity sensor so when the sign is not showing anything else in the bottom row it will scroll the local temp/humidity and the five-day forecast it downloads from Open Weather Map. Neither of these are required. The microcontroller is a ESP8266 with the Wemos D1 mini being a good choice for its small, but easy usable size.

        Power requirements depend upon the number of pixels illuminated. Most are not illuminated when showing text. Images have most, but generally the amount of white content is modest so still not a big energy hog. May be able to get away with a 5VDC/2.5A wallwart or something a little bigger to give more headroom.


          I tweaked the firmware in the sign as well as completed the final install. No change to the API. Updates made to mcsMQTT.pdf to show the construction pictures as well as application text in Section 15. I moved the DH11T to the outside of the frame so that it is not affected by the heat that is generated by the LEDs. I also added a switch for local on/off control. This switch does not control power, but controls the LEDs so that switching on/off has an immediate effect on what is shown on the screen.

          It now accepts Alexa commands (or any other command source) to turn on/off. The dimmer control can be used to adjust the brightness to ambient conditions while still adjusting the intensity as the lighting conditions change.

          Each hour when downloading the weather forecast it has a few second pause that affects anything that may be scrolling. Not a big deal, but in the future I will try again to use asynchronous web access and avoid this pause.

          I also update by CID application so that it will send the number and name directly to the sign. Both are in and source for both replaces the prior source as described in the manual.

          With the mcsMQTT integration provided in 4.1.x.x it provides are really seamless way to use it with Homeseer. This is also described in the manual.

          The WS2812B LEDs now come in panels of 16x16 or 8x32 to minimize the wiring requirements. A sign with one row of text with ten characters shown at a time can be built without much effort or cost. Aliexpress sells them for about $17 including shipping and only two would be needed. Wemos D1 mini and a 5V 2.5A wallwart adds another $10 or so.

          Click image for larger version

Name:	Sign2.jpg
Views:	216
Size:	49.3 KB
ID:	1317493


            Love what you are doing here. I was hoping to do something similar by using some Adafruit matrix panels and a RaspberryPi Zero W thus allowing them to be totally standalone modules.

            Will it be possible to get the information on what's being published and subscribed to make this work with different panel designs using the same interface on the HS side of the world?

            This would give us lots of options, I my self would like to use this 32x64 panel using this bonnet on a RPi Zero W mounted in a nice wood frame that can be hung anywhere as long as you can get 5V from a power brick to it. If you want a bigger display the modules can be daisy changed to a single control board.

            Click image for larger version

Name:	2278-00.jpg
Views:	161
Size:	169.1 KB
ID:	1317595
            HomeSeer Version: HS3 Standard Edition
            Linux version: Linux auto 4.15.0-72-generic #81-Ubuntu SMP Tue Nov 26 12:20:02 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
            Number of Devices: 484 | Number of Events: 776

            Enabled Plug-Ins: AirplaySpeak | BLBackup
   EasyTrigger | 1.3.7006.42100: LiftMaster MyQ
   mcsMQTT | PHLocation2 | Pushover 3P
   RaspberryIO | Z-Wave

            Z-Net version: 1.0.23 for Inclusion Nodes
            SmartStick+: 6.04 (ZDK 6.81.3) on Server


              The mcsMQTT manual contains the API for communicating with the sign so you are able to roll your own. The source is available as described in the manual. It uses the Adafruit libraries.

              There was another discussion the past few months of another user that went the RPi route using the HUB75 interface provided by the Bonnet. In his case he used Python and was looking for a way to interface with HS. My intention when I developed the API was to make it so that any implementation of the hardware could be used.

              The HUB75 is a row/column multiplexed interface that allows for higher density panels so physical construction can be done with fewer tiles and at a lower cost. The downside is that the visual effect is compromised when the sign or the one looking at the sign is moving. The Neopixels provide a static rather than multiplexed display so motion has no effect.


                I obtained the 16 x 16 matrices to make a 48 x 32 sign at a cost of about $100 This size is better suited for images, but also provides for four rows of text. These were much easier to assemble into a final product because the connection between tiles are snap connectors rather than solder connections. A power/ground bus is also run to which each tile needed a solder connection. I suspect if this extra power was not connected there would be a difference in brightness between the first and last tile.

                I used double-sided tape to mount the tiles on a piece of 3/16 plywood skin and cutout two slots to give access the the wiring connections of the tile. The Wemos, LDR, DHT11 and power socket were also mounted on the plywood.

                Click image for larger version

Name:	back.jpg
Views:	223
Size:	62.6 KB
ID:	1319269

                mcsMQTT at was updated in to be able to manage multiple signs. Change only affected the Publist/Sign tab of the mcsMQTT setup page. Under the hood, the screen size reported by the sign is now used to support images scaling. Previously it was hard-coded in the plugin to match my first sign.

                Changes were also made in the Tasmota firmware to add display on the first row of the current time in HH:MM:SS, API commands to select the color of the time display and the weather display, and optimization of the forecast processing so that RAM buffer needs are reduced. This was done by processing each day during the download rather than waiting until the full forecast was downloaded. I originally thought that occasional pause in the scrolling was due to the forecast download, but learned it was something else. My guess it is associated with managing the WiFi connection.

                For the first sign I used plexiglass that I sanded to difuse the LED light to provide better visuals. On this larger sign I just used the styrene panels that are used in drop-down ceiling panels to serve the same function and need no additional treatment other than cutting to desired size.

                Click image for larger version

Name:	BSign.jpg
Views:	136
Size:	59.7 KB
ID:	1319270