search

enesbcs / rpieasy

Easy MultiSensor device based on Raspberry PI
GNU General Public License v3.0
159 stars 33 forks source link

Feature request. OLED Plugins #11

Closed Budman1758 closed 5 years ago

Budman1758 commented 5 years ago

I know that you are trying to track down any and all bugs before adding new features and I agree wholeheartedly with that. This request should take a back seat to that. I would just like it a whole lot that when you are ready to add more functionality that you consider the OLED stuff first. :>) Preferably the "Framed OLED"

Thanks for the great work you are doing!!

enesbcs commented 5 years ago

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.

enesbcs commented 5 years ago

Framed OLED can be done, but first, try the normal OLED plugin. It is highly experimental, special characters are not implemented yet. https://github.com/enesbcs/rpieasy/commit/dce3e3c70f0edec163c1f3f2901072ad0d06e3f7 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.

Budman1758 commented 5 years ago

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

Budman1758 commented 5 years ago

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.

enesbcs commented 5 years ago

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.

Budman1758 commented 5 years ago

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. 8 lines This is with 4 lines selected. 4 lines This is 2 lines selected. 2 lines And with 1. 1 line

enesbcs commented 5 years ago

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.

Budman1758 commented 5 years ago

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.

enesbcs commented 5 years ago

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.

Budman1758 commented 5 years ago

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

Is that possible?

enesbcs commented 5 years ago

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. :)

enesbcs commented 5 years ago

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

Budman1758 commented 5 years ago

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?

enesbcs commented 5 years ago

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.

Budman1758 commented 5 years ago

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

enesbcs commented 5 years ago

OLED command fixed in https://github.com/enesbcs/rpieasy/commit/e69ac666ade2dd86cb9e9833f7d568b39491b3a4

Budman1758 commented 5 years ago

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.

enesbcs commented 5 years ago

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.

Budman1758 commented 5 years ago

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

From my experience, yes.

enesbcs commented 5 years ago

OK i will try to implement a similar thing.

enesbcs commented 5 years ago

"Clear only used lines" option added in https://github.com/enesbcs/rpieasy/commit/8ff9d7acc9d6cc036d4dbc1dda1ffb1807461742

Budman1758 commented 5 years ago

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. + 7 lines + +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.

enesbcs commented 5 years ago

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 https://github.com/enesbcs/rpieasy/commit/9db38816010f53ccd22d18508e3cf117880aa0d1

Budman1758 commented 5 years ago

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

enesbcs commented 5 years ago

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

Budman1758 commented 5 years ago

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.

https://github.com/letscontrolit/ESPEasy/issues/706

enesbcs commented 5 years ago

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

enesbcs commented 5 years ago

clearline command added in commit https://github.com/enesbcs/rpieasy/commit/5af2fe743fcee850faaf000b231f8d0c33bda04a

enesbcs commented 5 years ago

Framed OLED plugin is now implemented in commit https://github.com/enesbcs/rpieasy/commit/a07b64da79647f1a14d27a71021bf56c61e69d80 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.

Budman1758 commented 5 years ago

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.

enesbcs commented 5 years ago

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.

haraldtux commented 5 years ago

Nice work boys :+1:

Budman1758 commented 5 years ago

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!!

enesbcs commented 5 years ago

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.