Feature request. OLED Plugins about rpieasy HOT 34 CLOSED

8 lines is so small, that i've not tested it since the first commit. Yes, 8th line is just hidden below the display. Fixed in 9db3881

from rpieasy.

Is that possible?

Sure it can be done. The tricky part will be displaying that which will may involve some PIL image manipulation. I think the OLED command can be implemented in that way. It's only a matter of time. :)

from rpieasy.

OK i will try to implement a similar thing.

from rpieasy.

Thanks.. If simple OLED works as it supposed to be, than Framed OLED will be next in the line.

from rpieasy.

Framed OLED plugin is now implemented in commit a07b64d
Feel free to report issues. Animation is a bit choppy and it won't be smoother... I am wondering if it is okay to refresh time only when page changes, or it needs to be refreshed at every second? The same question is for the Wifi strength indicator.

from rpieasy.

Nice work boys 👍

from rpieasy.

My knowledge about I2C is pretty limited but for the choppiness my guess would be the 100kb/s speed you mentioned. I guess the ESPEasy I2C speed is 400kb/s? Don't know if its relevant but there is a setting at the bottom of ESPEasy's advanced settings page for an "I2C clock stretch limit". Never used or changes it on any of my stuff. From what I read at this page I guess its for certain devices to request a certain clock speed. Have no clue how that works though.

Working great here!! Thanks for your hard work on all this. I was looking for something like this for the Raspberry to make it possible for a non-programmer like me to do this kind of stuff. There are all kinds of example code out there but I could never find something that put all this into something "easy" Thats when I found ESPEasy and got into the ESP modules. With RPIEasy now we have the best of both worlds!!

from rpieasy.

Hm it can be done.
OLED crossed my mind earlier, but i am using HDMI/SPI 5" touch panels at my Raspberrys. Altough I can imagine some use case for a tiny OLED.

from rpieasy.

Framed OLED can be done, but first, try the normal OLED plugin. It is highly experimental, special characters are not implemented yet.
dce3e3c
I trying to learn more about the luma.oled library, that controls the SSD1306. Write text message command (OLED,,, ) implementation seems to be a little problematic as Canvas() always clears the display.

from rpieasy.

Cool. Will give it a try later tonight and report back.

from rpieasy.

Tried on 2 different devices. Cannot get the OLED dependencies installed. Using the plugins and dependencies page to install them. When trying to configure a device I get error message

Importing failed, please double check dependencies! libtiff.so.5: cannot open shared object file: No such file or directory

Can you tell me the commands to install dependencies manually?

edit: I2C is working fine by the way.

from rpieasy.

Please try:

sudo apt install libtiff5

I will insert this package into dependencies...

This was that i used, based on Luma Wiki:

sudo apt-get install python3-dev python3-pip libfreetype6-dev libjpeg-dev build-essential
sudo -H pip3 install luma.oled

If more error will pop up try also:
sudo apt install libopenjp2-7
Then retry dependency resolving in RPIEasy.

from rpieasy.

Ok. After installing those it now works. Seems to be displaying as it should. On, off and clear commands work. Only question I have is how text scales in relation to the number of lines selected. This may be by design but as the less lines you use the less useful it becomes. See pics.

This is with 8 lines selected. Only 4 filled out. All pics are with same text in the first 4 lines. Last 4 are blank.

This is with 4 lines selected.

This is 2 lines selected.

And with 1.

from rpieasy.

Was the libopenjp2-7 also needed? If yes, I have to include that in the dependency list.

The font height is calculated from the (selected display resolution height (for ex: 64) divided by the selected line count) + 2

For the resize operation, a truetype font is needed, currently i have selected "UbuntuMono-R.ttf". Maybe there are other better alternative that is more slimmer.

I can add another numeric box to specify maximal line width in characters which can influence the above calculation. In this case vertical alignment will also be necessary as there were a lot of empty space.

from rpieasy.

Was the libopenjp2-7 also needed? If yes, I have to include that in the dependency list.

Yes. Did not work at all without it.

I trying to learn more about the luma.oled library, that controls the SSD1306. Write text message command (OLED,,, ) implementation seems to be a little problematic as Canvas() always clears the display.

If the display clears when writing to a certain line it would probably fill in at the interval setting.

from rpieasy.

If the display clears when writing to a certain line it would probably fill in at the interval setting.
Yes, but if you want to write several lines, than the previous line will always disappear (by design as the Luna Canvas works in that way).
Unless all written text is buffered by the plugin and rewritten to the new canvas.

from rpieasy.

Unless all written text is buffered by the plugin and rewritten to the new canvas.

Is that possible?

from rpieasy.

Internal canvas implemented with oled cmd,x,y,text .. Are x and y 0 based, or may i convert it to 1 based?
13de3bc
Also there are a new numeric box at plugin settings, which make sure that longer strings fits in line properly... in theory. :)

from rpieasy.

That is working much better. Much more options!!

Are x and y 0 based, or may i convert it to 1 based?

Not sure what you mean on this?

from rpieasy.

This command writes the top left corner now:
oledcmd 0,0,Left corner
Is it OK, or top left corner is at (1,1)? Just to have some compatibility with ESPEasy.

from rpieasy.

I think 1,1 to stay command compatible with ESPEasy would be best if its not much trouble.

from rpieasy.

OLED command fixed in e69ac66

from rpieasy.

Working well now. One issue I see now though. Say you have all eight lines selected but you have only 4 with variables or fixed text. You use the other 4 to write to with the oled command. When the update interval happens the lines written to are cleared. At the update interval only the lines with fixed content should be rewritten. In other words only clear and redraw lines with fixed content at the update interval.

from rpieasy.

It is by design. ESPEasy only clears only portions of the screen when updates it?
If it is not what you need, you can set interval to 0 and use only manual writes and manual clear.
Update: maybe i can add an option to clear not the full lines but only lines with data at the specified interval, with a black rectangle... I don't know if it will cause unforeseen display problems, but it will turn out.

from rpieasy.

ESPEasy only clears only portions of the screen when updates it?

From my experience, yes.

from rpieasy.

"Clear only used lines" option added in 8ff9d7a

from rpieasy.

That works great. But now there is another anomaly with the amount of lines. I have 8 lines selected but only 7 show up in the config page. Not absolutely sure this was not present b4 this update but it sure is now. Also only 7 lines in the display itself. If attempting to write to line 8 nothing shows. See pic.
+

+
+EDIT 2 I see now that there are actually 8 lines. Did not notice line 1 was line 0. Problem actually is I can only get 7 actual lines on the display itself.

from rpieasy.

Indeed, they are quite small. :) Seems to be working fine now. Great work!!

from rpieasy.

There is one thing that would be nice also. I put a request in the ESPEasy Github quite some time ago too. Was hoping for a "clearline" command. This command would be used to clear a specific line b4 writing something else to it. Because it does not erase whats already there first the display can get garbled.

I dont know how difficult that would be but it would be handy at times. Not essential. See this issue.

letscontrolit/ESPEasy#706

from rpieasy.

It is not so complicated, i will try to implement it soon.

from rpieasy.

clearline command added in commit 5af2fe7

from rpieasy.

As for the Wifi indicator I don't see any need for it to change unless the strength does. As for the seconds update I would not update every second. That would use a lot of resources wouldn't it?

Seems to be working ok so far. You are right about the choppy animation. Is that due to the particular library software? It is quite smooth in the ESPEasy version. I guess its not a big deal. Just curious.

from rpieasy.

Yes, updating the time may consume more resources, but i think i can find a way to store the actual minute, check it at every second, but only refresh if the minutes changed.
The wifi indicator currently changes its state when the content refreshed (at interval time) this can be changed a way as the time display if needed, but i am not sure that it is critical.

LUMA Oled library has a virtual viewport that can be scrolled, and when i tried it presented a very similar choppy effect, than tried to implement my own method with a new empty canvas, with writing text to it White color, after erasing the content with overwriting the same text with Black color - this method was also slow. After it i do full canvas erase after rewriting White text, and it is looked like the same speed and effect like the previous attempts, so i gave up for now. :) Interesting thing, that ESPEasy does similarly an erase by fillrect() on the canvas, write the strings than wait 2 microseconds.
Either the library uses too much functions to do things in the background or the RPI 100kb/s default I2C speed is too low. But changing this to higher, for example 400kb/s may affect other I2C devices, i experienced that AM2320 go wild with increased I2C speeds.

from rpieasy.

Thank you for your feedbacks and for testing the plugin! If another bug found, feel free to open a new issue. This feature request is now closed.

from rpieasy.