tasmota lcd display manufacturer

The display driver is able to display predefined setups of text or user defined text. To display text using DisplayText set DisplayMode to 0, or set DisplayMode to 1 for the HT16K33 dot-matrix display.

To use the seven-segment-specific TM1637, TM1638 and MAX7219 Display- commands, set DisplayMode to 0. Parameter LCD Display OLED Display TFT Display 7-segment Display (TM163x and MAX7219) 0 DisplayText DisplayText DisplayText All TM163x Display- functions

The DisplayText command is used to display text as well as graphics and graphs on LCD, OLED and e-Paper displays (EPD). The command argument is a string that is printed on the display at the current position. The string can be prefixed by embedded control commands enclosed in brackets [].

In order to use the DisplayText command the DisplayMode must be set to 0 (or optional 1 on LCD displays) or other modes must be disabled before compilation with #undef USE_DISPLAY_MODES1TO5.

In the list below p stands for parameter and may be a number from 1 to n digits. On monochrome graphic displays things are drawn into a local frame buffer and sent to the display either via the d command or automatically at the end of the command.

Pfilename: = display an rgb 16-bit color (or jpg on ESP32) image when file system is present, Scripteditor contains a converter to convert jpg to special RGB16 pictures See ScriptEditor Ffilename: = load RAM font file when file system is present. the font is selected with font Nr. 5, these fonts are special binary versions of GFX fonts of any type. they end with .fnt. an initial collection is found in Folder BinFonts

Draw up to 16 GFX buttons to switch real Tasmota devices such as relays or draw Sliders to dimm e.g. a lamp Button number + 256 - a virtual touch toggle button is created (MQTT => TBT)

When a file system is present you may define displaytext batch files. If a file named "display.bat" is present in the file system this batch file is executed. The file may contain any number of diplaytext cmds, one at a line. You may have comment lines beginning with a ;

E-Paper displays have 2 operating modes: full update and partial update. While full update delivers a clean and sharp picture, it has the disadvantage of taking several seconds for the screen update and shows severe flickering during update. Partial update is quite fast (300 ms) with no flickering but there is the possibility that erased content is still slightly visible. It is therefore useful to perform a full update in regular intervals (e.g., each hour) to fully refresh the display.

The data sheets of the TFT and OLED displays mention burn-in effects when a static display is shown for extended periods of time. You may want to consider turning on the display on demand only.

The EPD font contains 95 characters starting from code 32, while the classic GFX font contains 256 characters ranging from 0 to 255. Custom characters above 127 can be displayed. To display these characters, you must specify an escape sequence (standard octal escapes do not work). The ~character followed by a hex byte can define any character code.

The I2C address must be specified using DisplayAddress XX, e.g., 60. The model must be specified with DisplayModel, e.g., 2 for SSD1306. To permanently turn the display on set DisplayDimmer 100. Display rotation can be permanently set using DisplayRotate X (x = 0..3).

E-Paper displays are connected via software 3-wire SPI (CS, SCLK, MOSI). DC should be connected to GND , Reset to 3.3 V and busy may be left unconnected. The jumper on the circuit board of the display must be set to 3-wire SPI.

Waveshare has two kinds of display controllers: with partial update and without partial update. The 2.9 inch driver is for partial update and should also support other Waveshare partial update models with modified WIDTH and HEIGHT parameters. The 4.2 inch driver is a hack which makes the full update display behave like a partial update and should probably work with other full update displays.

In black and white displays, a local RAM buffer must be allocated before calling the driver. This must be set to zero on character or TFT color displays.

Universal Display Driver or uDisplay is a way to define your display settings using a simple text file and easily add it to Tasmota. uDisplay is DisplayModel 17. It supports I2C and hardware or software SPI (3 or 4 wire).

Initial register setup for the display controller. (IC marks that the controller is using command mode even with command parameters) All values are in hex. On SPI the first value is the command, then the number of arguments and the the arguments itself. Bi7 7 on the number of arguments set indicate a wait of 150 ms. On I2C all hex values are sent to I2C.

bit 2: enable async DMA, 0 wait for DMA to complete before returning, 4 run DMA async in the background. This later mode is only valid if the SPI bus is not shared between the display and any other SPI device like SD Card Reader.

# Scripter is the nost convenient way to edit and develop a uDisplay driver. On every scripter save the display is reinitialized and you immediately see results of your changes.

There are also many variants of each display available and not all variants may be supported. #define directive Description USE_DISPLAY Enable display support. Also requires at least one of the following compilation directives

This driver simulates an additional relay in your Tasmota device. If you have N physical relays and you configure GPIO pin functions DLP Tx and DLP Rx you"ll see relay (N+1) after reboot. The two GPIO pins will be used for serial communication with your LCD or DLP projector. The communication protocol is unique for each manufacturer (compile-time option). The driver polls the projector"s state periodically and updates the fake relay state. When you toggle the fake relay, serial commands are sent to the projector to power it up or down. While the projector is running, the driver prevents to switch off the real relay that feeds the projector. This protects the lamp of the projector (needs to be cooled down before power is cut from the device).

Connect your Tasmota GPIO pins (3.3V TTL level) to a MAX3232 interface (cheap items on internet sales). Such interface changes TTL signals to proper RS232 levels. There are 4 wires on TTL side (Vcc, GND, Rx and Tx) and 3 wires on RS232 side (GND, Tx and Rx). A wire jumper between pins 7(RTS) and 8(CTS) may be needed in DSUB9 connector going to projector.

Check your projector settings concerning Serial port. It must match Tasmota settings eg. 9600 8N1. Some models have "ID number" feature to allow several projectors in one room. The control commands in Tasmota contain ID 0. Please switch off the "ID" control completely or set the ID to 0.

After flashing Tasmota, open the web UI of the device and navigate to Configuration -> Auto-configuration. Select your device from the drop-down and click Apply Configuration.

After flashing Tasmota, open the web UI of the device and navigate to Configuration -> Auto-configuration. Select your device from the drop-down and click Apply Configuration.

This article explains in detail how to use and debug SSD1306 displays.  In this article, I use the Segger emWin library and MBEDOS, but for all practical purposes this discussion applies to all other interfaces to the board including Arduino, Raspberry Pi, Adafruit, etc.  I will say from the outset that I spent far far too much time digging into the inner workings of an 11 year old graphics driver.  Oh well, hopefully someone will get some benefit.

A year ago (or so) I designed a user interface board called the CY8CKIT-032 to go with my Cypress WICED WiFi book and class.  This board uses a PSoC 4 Analog co-processor which can do a bunch of cool stuff.  I have a series of articles planned about that board, but that will be for another day.  One of the things that I did was put a 0.96″ I2C OLED Display based on a SSD1306 driver on the board.  These displays are widely available from Alibaba and eBay for <$2.  I think that the displays are being used in inexpensive cells phones in China so there are tons of them and they are CHEAP!  The bad news is that if you google “ssd1306 problems” you will find an absolute rogues gallery of unpleasantness.  It seems that tons of people struggle to get these things working.

This whole thing started last week as Cypress released and update to our MBED OS implementation.  This update included releasing a complete set of the Segger emWin drivers.  I had been wanting to step up to a more robust graphics library than the Adafruit library that I used in this article.  I was pleased to see that our release included the emWin SPAGE driver which knows how to talk to a bunch of different page based displays including the SSD1306.

But, as always, I had to wrestle with the display a little bit before I got everything working.  This time I wrote down what I did/learned.  So, for this article I will describe

There is not a lot to know about the electrical interface.  The data sheet specifies that the device can use I2C, SPI, 6800 and 8080.  I have not seen either the 6800 or 8080 interface put onto any of these OLED displays.  Like all driver chips, the SSD1306 has an absolute boatload of pins, in fact, 281.  The chip is long and skinny and was made to be mounted either on the display under the glass or on the flex connector.  Of the 281 pins, 128+64=196 are connected to the segments and commons in the display.  The rest of the pins are either capacitors, no-connects, power/ground or data signals.  The data signals are

One thing you should be careful about is the I2C connections.  I looked around on eBay and Alibaba to find a few pictures of the I2C displays.  You should notice that all three of these displays are I2C, but all three of them have a different position and ORDER of VCC/GND/SCL/SDL  When we ordered displays from China to go onto the CY8CKIT-032 we found displays in the same BATCH that had different orders of the VCC/GND.

The first part is the command interface.  Inside of the chip there are a bunch of logic circuits which which configure the charge pumps, sequence COMs and SEGs, charge and discharge capacitors etc.  All of these things are configurable to allow for different configurations of screens e.g. different x-y sizes, configuration of what wires are connected to what places on the glass etc.  Before you can get the display to work correctly you must initialize all of these values by sending commands.  All the commands are 1-byte followed by 0 or more command parameters.

The second part is the data interface.  Inside of the SSD1306 chip there is a Graphics Display DRAM – GDDRAM which has 1 bit for every pixel on the screen. The state machine inside of the chip called the Display Controller will loop through the bits one by one and display them on the correct place on the screen.  This means that your MCU does not need to do anything to keep the display up to date.  When you want a pixel lit up on the screen you just need to write the correct location in the GDDRAM.

As to the fundamental commands.  I tried a bunch of different contrast settings on my screens and could not tell the difference between them.  I tried from 0x10 to 0xFF and they all looked the same to me.  The best course of action is to use the default 0x7F.  I don’t really know why there is a command 0xA5 “Entire Display ON ignore RAM”.  The data sheet says “A5h command forces the entire display to be “ON”, regardless of the contents of the display data RAM”.  I can’t think of a single use case for this.  I suppose that if you issue 0xAE the screen will be all black… and if you issue 0xA5 the screen will be all white?  But why?

In the next section of the command table are the “Scrolling” commands.  It appears that this graphics chip was setup to display text that is 8-pixels high.  The scrolling commands will let you move the screen up/down and left/right to scroll automatically without having to update the the frame buffer.  In other words it can efficiently scroll the screen without a bunch of load on your MCU CPU or on the data bus between them.  The Adafruit graphics library provides the scrolling commands.  However, I am not using them with the Segger Library.

The hardware configuration registers allow the LED display maker to hookup the common and segment signals in an order that makes sense for the placement of the chip on the OLED glass.  For a 128×64 display there are at least 196 wires, so the routing of these wires may be a total pain in the ass depending on the location of the chip.  For instance the left and right might be swapped… or half the wires might come out on one side and the other half on the other side.  These registers allow the board designer flexibility in making these connections.  Commands 0xA0, 0xA1, 0xA8, 0xC0, 0xC8, 0xD3, 0xDa will all be fixed based on the layout.  You have no control and they need to be set correctly or something crazy will come out.

These displays require a high voltage to program the liquid crystal in the display.  That voltage can either be supplied by an external pin or by an internal charge pump.  All the displays that I have seen use an internal charge pump.

In order to actually get data to display on the screen you need to write 1’s and 0’s into the Graphics Data RAM that represents your image.  The memory is actually organized into 8 pages that are each 128 bits wide and 8 bits tall.  This means that if you write 0b10101010 to location (0,0) you will get the first 8 pixels in a column on the screen to be on,off,on,off,on,off,on,off.  Notice that I said vertical column and not row.  Here is a picture from the data sheet.  That shows the pages:

If you have the speckled screen this means that your screen is displaying an uninitialized frame buffer which the SSD people call the GDDRAM.  These are basically the random 0 and 1s that are the startup values in the SSD1306.  If this is happening then your graphic data is probably not being transferred between your MCU and the SSD1306.  This almost certainly means you have a problem in your porting layer.

This clever utility uses a security loophole to trick your Tuya device into thinking that it’s installing an updated version of itself, when in fact it’s replacing itself with Tasmota. This means you can do the conversion without any electrical connection to the device: you don’t need a serial connection, and you don’t need to open the case.

If you only had one device to convert, you can say “N” (or just press ENTER) and Tuya-Convert will exit. You’re now ready to follow the normal Tasmota setup and configure your device.

Tuya-Convert installs a very basic Tasmota binary that will allow your device to connect to WiFi, but it may not be the specific Tasmota build that your device requires for its features to work.

Power up your device, and then follow the usual Tasmota setup process to connect your phone or tablet to its network. Then you can open its web interface, and if necessary you can install a different build of Tasmota that suits your device.

The best place to get information about specific devices is the Tasmota Device Templates Repository. Look up your device there to find out what Tasmota build you need to install, and how it should be configured.

Xmas DIY projects part 2: ESP8266 based central heating monitor (up to 4x DS18B20 thermal sensor; up to 3x 230V AC input to keep track of when which pump is enabled). Hardware athttps://gitea.osmocom.org/laforge/esp8266-projects/src/branch/master/esp8622_heating_monitoring…using stock Tasmota as software, feeding mosquitto->influxdb->grafana

Now it is important to put the Sonoff TH Elite into flashing mode. We do that by pressing and holding the button on the device while plugging the USB to TTL adapter into the USB port of the computer. When plugged release the button and as a result device should be in flashing mode. Chose your com port, and browse to tasmota32.bin path and that`s it. Hit the Flash button, and it should end like this.

Now, get the phone or laptop and scan for Wi-Fi networks. It is wise to turn off mobile data transfer if you are using your phone since sometimes it makes some problems. There will be a tasmota-something network and connect to it. In addition, open your browser and enter 192.168.4.1 in the address bar.

Under GPIO25 find Si7021. Si7021 is the actual name of the temperature and humidity sensor that Sonoff calls THS01. You will not find THS01 in tasmota configuration. After that save the configuration. That is it you are ready to roll.

One winter morning during the onslaught of the great Polar Vortex, I stumbled out of bed to take a shower and had the realization that my toes were much colder than normal. A quick glance at the in-floor heat thermostat confirmed that something wasn’t right. The LCD display was dead and the GFCI light was blinking red. Uh oh, that’s not good. A GFCI fault usually means there is water where it shouldn’t be. I opened up the electrical box where the thermostat was mounted and sure enough, there was some water in there. I cleaned up the water and attempted to reset the GFCI but realized that I couldn’t…the GFCI reset function was part of the LCD control panel that wasn’t functioning. A call to technical support informed me that a blinking red GFCI light didn’t actually indicate a GFCI fault (that would have been a solid red light and a working LCD screen), but rather that the device was “End of Life”. And it was just out of warranty, go figure.

Because the standard Sonoff firmware wouldn’t work for my application, I had to do something a little more custom. I considered the Tasmota open source firmware, but I would have needed to modify it to access the ADC and kind of wanted this to be a standalone solution that didn’t depend on an external MQTT broker for thermostat control. Instead, I decided to write myown firmware that would set up the ESP8266 to act as a web server and create a small web page to allow me to change the thermostat settings from my LAN.

With the ADC now functioning it was time to implement thermostatic control. I put together a web interface that allowed me to set up different heating schedules for M-F, Saturday, and Sunday. The HTML GUI also logs temperature once per minute, stores the values in RAM, and displays a graph of temperature over the previous 24 hours. The ESP8266 gets the current time from an NTP server. Rather than specifying the time at which the heat would turn on, I wanted to specify the time at which the floor would be at my desired temperature. To accomplish this, I logged some additional data to get a feel for how quickly the floor heats up. Simplifying things a bit with linear interpolation, I guestimated that the floor heats at a rate of about 5 degrees F per hour.