Announcement

**Guest** · July 5, 2019, 08:44 PM

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 .

**Michael McSharry** · July 6, 2019, 12:21 PM

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

**Michael McSharry** · July 12, 2019, 06:17 PM

I have completed the plugin updates for the Messaging Sign. Located at http://mcsSprinklers.com/mcsMQTT_4_1_0_0.zip and separate document at http://mcsSprinklers.com/mcsMQTT.pdf.

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.

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.

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.

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.

1.1.1.1 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.

1.1.1.2Send 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.

1.1.1.3 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.

1.1.1.4 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.

1.1.1.5 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 5.1.1.2 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.

1.1.1.6 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.

1.1.1.7 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

1.1.1.8 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 5.1.1.6 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. https://www.aliexpress.com/item/3290...chweb201603_53

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.

**Michael McSharry** · July 24, 2019, 08:13 PM

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 mcsTasmota.zip 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.

**Timon** · July 25, 2019, 11:21 AM

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.

**Michael McSharry** · July 25, 2019, 12:04 PM

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.

**Michael McSharry** · August 5, 2019, 01:25 AM

I obtained the 16 x 16 matrices to make a 48 x 32 sign at a cost of about $100 https://www.aliexpress.com/item/1666...1c3c23c8JXHLxZ. 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.

mcsMQTT at http://mcsSprinklers.com/mcsMQTT_4_1_2_0.zip was updated in 4.1.2.0 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.

**Burr178@gmail.com** · February 5, 2023, 09:57 PM

I trying to edit the led sign API and not having much luck. I am new to Tasmota and not understand how to edit it. I downloaded your bin file and got the sign working but missing 2 rows in each character. I am currently using 2 8x32 matrix panels. Any help would be greatly appreciated.

**Michael McSharry** · February 5, 2023, 10:21 PM

I am not understanding what you mean by editing the API. You can use to communicate with mcsMQTT as-is. You can change it to integrate with whatever you want, but doing so requires playing with the Tasmota source.

The two configurations that I implemented are 40 x 16 for two rows of text and 64 x 32 for four rows of text or graphics. Compile time defines in the config file are used to select between the two.

Each standard character for the font is seven pixels high and one vertical pixel space. The generation of the character is done by the LED library and is not something that is done in the Tasmota code. All that can be done in the code is to select the pixel coordinate where to start drawing a character.

**Burr178@gmail.com** · February 6, 2023, 08:12 AM

Sorry I did not explain what I'm trying to do very well. I'm looking to edit the size of the sign pixels I'm trying to make a one row 8 high by 64 long pixel sign using two 8x32 matrix panels. I have the sign partially working, I'm able to send messages from homeseer to the sign and it displays them. but I'm getting 2 blank rows of pixels in every character. Something like this - -- instead of --- hopeful this helps if not I can take a picture and upload it.

**Michael McSharry** · February 6, 2023, 12:59 PM

The my_user_config.h file contains the sign parameters. I did two signs and created the variable FOUR_ROWS to select one vs. the other. I originally used tile size of 8x8 and ten tiles oriented in two rows of five. The second FOUR_ROWS used eight 16x16 tiles oriented in two rows of four. I think the matrix and tile pixel definitions came from AdaFruit or FastLed library and LED_SIGN_ORIENTATION merged the definitions to represent the physical layout of the signs.

The #define LED_SIGN is used at various places in the Tasmota code to introduce the additional logic to support the signs and the API that I defined. I obviously tested it for the two-row configuration, but the intention was that it would work other layouts.

Have you modified this enhanced Tasmota build to characterize the tile layout that you are using?

I tried to do something with this source in PlatformIO about a year ago and the newer version of PlatformIO that I had installed no longer would compile it. I did minimal research to try to understand why, but what I recall, PlatformIO changed the configuration approach for better future support. My use of PlatformIO is by example so I did not have much understanding of how to configure it.

Code:

  #define USE_WS2812                               // WS2812 Led string using library NeoPixelBus (+5k code, +1k mem, 232 iram) - Disable by //
  #define USE_WS2812_CTYPE     NEO_GRB           // WS2812 Color type (NEO_RGB, NEO_GRB, NEO_BRG, NEO_RBG, NEO_RGBW, NEO_GRBW)
  //#define USE_WS2812_DMA                         // DMA supports only GPIO03 (= Serial RXD) (+1k mem). When USE_WS2812_DMA is enabled expect Exceptions on Pow
#define NEO_MATRIX_TOP         0x00 // Pixel 0 is at top of matrix
#define NEO_MATRIX_BOTTOM      0x01 // Pixel 0 is at bottom of matrix
#define NEO_MATRIX_LEFT        0x00 // Pixel 0 is at left of matrix
#define NEO_MATRIX_RIGHT       0x02 // Pixel 0 is at right of matrix
#define NEO_MATRIX_CORNER      0x03 // Bitmask for pixel 0 matrix corner
#define NEO_MATRIX_ROWS        0x00 // Matrix is row major (horizontal)
#define NEO_MATRIX_COLUMNS     0x04 // Matrix is column major (vertical)
#define NEO_MATRIX_AXIS        0x04 // Bitmask for row/column layout
#define NEO_MATRIX_PROGRESSIVE 0x00 // Same pixel order across each line
#define NEO_MATRIX_ZIGZAG      0x08 // Pixel order reverses between lines
#define NEO_MATRIX_SEQUENCE    0x08 // Bitmask for pixel line order
// These apply only to tiled displays (multiple matrices):
#define NEO_TILE_TOP           0x00 // First tile is at top of matrix
#define NEO_TILE_BOTTOM        0x10 // First tile is at bottom of matrix
#define NEO_TILE_LEFT          0x00 // First tile is at left of matrix
#define NEO_TILE_RIGHT         0x20 // First tile is at right of matrix
#define NEO_TILE_CORNER        0x30 // Bitmask for first tile corner
#define NEO_TILE_ROWS          0x00 // Tiles ordered in rows
#define NEO_TILE_COLUMNS       0x40 // Tiles ordered in columns
#define NEO_TILE_AXIS          0x40 // Bitmask for tile H/V orientation
#define NEO_TILE_PROGRESSIVE   0x00 // Same tile order across each line
#define NEO_TILE_ZIGZAG        0x80 // Tile order reverses between lines
#define NEO_TILE_SEQUENCE      0x80 // Bitmask for tile line order
#define FOUR_ROWS                   // 32 x 48 sign
#define LED_SIGN                    // enable code for LED Sign
#define NEOPIXEL_PIN 5              // GPIO 5 Wemos D1 (ESP32 pin 8) for Neopixel LED Sign
#define NEOPIXEL_PIN2 12             // GPIO 12 Wemos D6 (ESP32 pin ) for Neopixel LED Sign
#ifdef FOUR_ROWS
  #define IMAGE_BUFFER_SIZE 5000    // jpeg download buffer.  pixel buffer of 32x48 requires smaller RAM use here
  #define MATRIX_WIDTH 16 //8              // 16 x 16 pixel matrix
  #define MATRIX_HEIGHT 16 //8
  #define LED_SIGN_WIDTH 48 //40           // total number of horizontal pixels on sign
  #define LED_SIGN_HEIGHT 32 //16          // total number of vertical pixel on sign
  #define LED_SIGN_ORIENTATION NEO_MATRIX_TOP + NEO_MATRIX_LEFT + NEO_MATRIX_COLUMNS + NEO_MATRIX_ZIGZAG + NEO_TILE_TOP + NEO_TILE_ROWS + NEO_TILE_LEFT +  NEO_TILE_PROGRESSIVE
#else
  #define IMAGE_BUFFER_SIZE 9000    
  #define MATRIX_WIDTH 8              // 8 x 8 pixel matrix
  #define MATRIX_HEIGHT 8
  #define LED_SIGN_WIDTH 40           // total number of horizontal pixels on sign
  #define LED_SIGN_HEIGHT 16          // total number of vertical pixel on sign
  #define LED_SIGN_ORIENTATION NEO_MATRIX_BOTTOM + NEO_MATRIX_RIGHT + NEO_MATRIX_ROWS + NEO_MATRIX_PROGRESSIVE + NEO_TILE_TOP + NEO_TILE_ROWS + NEO_TILE_LEFT +  NEO_TILE_PROGRESSIVE
#endif
#define LED_SIGN_DWELL_SECONDS 10     // number of seconds a messages stays before being swapped out
#define LED_SIGN_SCROLL_MILLISECONDS 50 // number of milliseconds a message dwells before scrolling left one pixel
#define LED_SIGN_PAN_MILLISECONDS 150 // number of milliseconds a image dwells before scrolling left/up one pixel

Announcement

LED Messaging Sign

LED Messaging Sign

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment