Tasmota: i2c character LCD Display support

Created on 31 Jul 2017  Â·  9Comments  Â·  Source: arendst/Tasmota

Hi,

I'm using ESP8285 with tasmota and really enjoying it.
Meanwhile connected two leds, switched and relay.
Also planning to connect a DHT22 and a LCD Display screen.
I really wanted to know if currently or in the furue there is or will be support in a i2c character LCD display like the following ([https://www.banggood.com/IIC-I2C-2004-204-20-x-4-Character-LCD-Display-Module-Blue-p-908616.html]).
I would really love it if I'll be able to send throw MQTT a 4 lines to be written to the LCD display.
Is there a way to do it right now? or planned to be?
Thanks a lot for all the good work!

stale

Most helpful comment

I´ve 'by default' upgraded all of my S20 and alikes with a 4 Mbit chip, thus space is currently no problem (at least for me). I would also second chukiki 's comments: Why not leave it up to the user to decide: Have a standard version which works without any hazzle on a plain S20 and alikes or have (memory-)upgraded devices that allow additional bells and whistles, such as LCD-support.

All 9 comments

Once worked on it. Have one in use but the problem is that what I like someone else doesn't and then there have to be made code additions that someone likes but another doesn't so I have to satisfy three people already. There are millions of these individuals around all wanting something different involving more code and code space is scarce on a 0.5 M device.

Bottomline, I could implement a simple driver for a I2C screen with basic mqtt commands like LCDCOL, LCDROW and LCDTEXT but I doubt if it would be enough...

I suggest to add a user.ino with a user_lcd() function editable by user. By default print Hello word, then the user can adapt the output to it's own needs. There are 2 lines displays, 4 lines and more other. First user will need the humidity and temperature, the second all 4 temperature sensors, the third the switch state .....

Better allow each user to configure output. A list of available useful variables (temperature, relay state, switch) with a short description at the beginning of the file will help.

I agree about few configurable options, while the basic and most important is the one that arendst suggested. Maybe I would extend it a little to support an mqtt command of setline , .
Regarding what ionciubotaru said, second step I would allow to configure 2 line\4 line and what to be shwon, while basic is if connected to wifi or not and ip adress and connected device state (power1: on... temperature, humidity, etc).
Regarding the space issue, will it be possible to supply several build like with the BE_MINIMAL
So also build that fits people who has or upgraded to 4MB flash and contains more options?
My router's firmware open-source project (http://tomato.groov.pl/) does that to supply several different builds depending on the features that you want\you router brand and memory you have in it...

This feature is the best idea I've read so far. Even if it keeps basic with
minimal options.

Le mar. 1 août 2017 08:41, chukiki notifications@github.com a écrit :

I agree about few configurable options, while the basic and most important
is the one that arendst suggested. Maybe I would extend it a little to
support an mqtt command of setline , .
Regarding what ionciubotaru said, second step I would allow to configure 2
line\4 line and what to be shwon, while basic is if connected to wifi or
not and ip adress and connected device state (power1: on... temperature,
humidity, etc).
Regarding the space issue, will it be possible to supply several build
like with the BE_MINIMAL
So also build that fits people who has or upgraded to 4MB flash and
contains more options?
My router's firmware open-source project (http://tomato.groov.pl/) does
that to supply several different builds depending on the features that you
want\you router brand and memory you have in it...

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/arendst/Sonoff-Tasmota/issues/669#issuecomment-319282376,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AcMo5QI9mI7OJ_7lq4Ongw5Jxp6-yrH6ks5sTsiSgaJpZM4OoYw3
.

Haha, which one of them? I had several out there :)

I´ve 'by default' upgraded all of my S20 and alikes with a 4 Mbit chip, thus space is currently no problem (at least for me). I would also second chukiki 's comments: Why not leave it up to the user to decide: Have a standard version which works without any hazzle on a plain S20 and alikes or have (memory-)upgraded devices that allow additional bells and whistles, such as LCD-support.

I think the best option is to enable the capability through a compiler Option. That makes is suitable for all users to decide how to work and what to compile. My SONOS Relays get a different compile than the nice WEMOS with 4MB. Anyhow, quite soon we will also hit limitations in the RAM. And this is not easy to overcome on the EPS8266. It is just a mini computer. The new ESP32 will add much more capabilities and then i2c displays are no more an issue. Currently, we should accept the limits.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

This issue will be auto-closed because there hasn't been any activity for a few months. Feel free to open a new one if you still experience this problem.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

grizewald picture grizewald  Â·  3Comments

Vujagig picture Vujagig  Â·  3Comments

Joeyhza picture Joeyhza  Â·  3Comments

j4k3 picture j4k3  Â·  3Comments

abzman picture abzman  Â·  3Comments