Closed TD-er closed 6 years ago
OLEDf_contrast ? 😅
My suggestion: (current implementation)
if (tmpString.equalsIgnoreCase(F("OLEDFRAMEDCMD")) && display)
{
success = true;
argIndex = string.lastIndexOf(',');
tmpString = string.substring(argIndex + 1);
if (tmpString.equalsIgnoreCase(F("Off")))
P36_setContrast(P36_CONTRAST_OFF);
else if (tmpString.equalsIgnoreCase(F("On")))
display->displayOn();
else if (tmpString.equalsIgnoreCase(F("Low")))
P36_setContrast(P36_CONTRAST_LOW);
else if (tmpString.equalsIgnoreCase(F("Med")))
P36_setContrast(P36_CONTRAST_MED);
else if (tmpString.equalsIgnoreCase(F("High")))
P36_setContrast(P36_CONTRAST_HIGH);
So your suggestion is to also change the command name?
On my testboard, this now works:
http://192.168.1.75/control?cmd=OLEDFRAMEDCMD,high
Nah, lets go with your suggestion. If we're about to make a remake of the commands we need to think more than twice.
OK then, off to bed now :)
I would like to request that commands be added to "OLEDFRAMEDCMD" that would allow for gpio state changes to change the contrast of the display.
Maybe just add "low", "medium" and "high" to "on" and "off"?
Would be great for the Wemos tiny display to be used on a night stand during day and night.
Thanks Matt
Or use an integer and connect a photo transistor to the ADC...
It is not that linear to control the contrast. It takes 3 parameters and I don't know yet how they interact exactly. These 3levels were somewhat trial and error
IMHO the 3 chosen levels appear very linear. I build flashlights and drivers and even modes are some of the more difficult to achieve.
I'm not much of a programmer, but may dl the repo and try to help. Second instance of IDE and first learn to compile the full code.
The 3 levels I set, were from what I considered good noticeable changes in brightness. But if you look at the 3 values used, they are partly depending on eachother. Below a certain value, you have to enable some other register and to go even lower you have to set another register.
And at some levels my display started to make high frequency noises. At these levels it is silent :)
I build flashlights when I have time, that noise is likely a PWM driving frequency that is just not right. We can run into that when building drivers that use PWM to control the led high power output.
With OLEDs there is no backlight you can replace. Each pixel is the lightsource. So perhaps I don't understand what you mean?
I assume there is something doing pwm to control the output... I have never really examined code to control an oled. So my opinion may not be worth a whole lot.
I guess there is some voltage regulator on board. And indeed that probably is one of a switching kind.
So there are some "good" values and some "bad" ones and we should have to create a lookup table with some interpolation. But still that will involve a lot of testing and perhaps using multiple modules. There was at least one report of a module which would not work when set to "low" and also didn't work with the previous default settings. It may be possible some cheap versions of those boards are missing a voltage regulator, or perhaps a somewhat faulty one.
I am game to test. I have the wemos display and maybe 1 or 2 other displays. Will have to see what cpu they use.
Keep in mind that the eye has a logarithmic sensitivity curve... That interpolation may become quadratic or so....
If we have like 8 or 10 points, I guess interpolating between then doesn't have to be that complex. The real complexity is in finding proper limits for when to start changing another parameter. (en when probably some other screens stop working)
I still have to test the SH1106 displays for contrast changes. So perhaps first add some command which operates very low-level to start testing? And when the relation between the parameters is clear, translate it to some range from 0..255?
It could be some values may destroy the display when used for prolonged amount of time, so I will make a separate build just for testing. Not for use by the general public.
Can you tell me what the commands are and I will test it this evening on my units.
OLEDFRAMEDCMD,On OLEDFRAMEDCMD,Off OLEDFRAMEDCMD,Low OLEDFRAMEDCMD,Med OLEDFRAMEDCMD,High
Thanks, will test it with button control this evening! I think I see how to do it... it would be done in rules but I am not sure of the syntax.
Lets say you push a button to set contrast to high (from normal low) I'd do it like this:
On Switch#Press Do
If [Switch#Press]=1
OLEDFRAMEDCMD,High
Else
OLEDFRAMEDCMD,Low
Endif
Endon
Thanks, will test it with button control this evening! I think I see how to do it... it would be done in rules but I am not sure of the syntax.
Grovkillen, that was more or less where I was headed! Thanks for the confirmation!
Mine would be On Display#Switch Do.... since I will be trying to use the button on the display. By the way the display shield has 2 buttons. Only one visible in the "Display - OLED SSD1306/SH1106 Framed " devices panel. Should it be a request in a new thread here to enable the second buttion?
Hmm, I was just thinking of something... Yesterday I added a small update to the OLED framed plugin. The WiFi symbol is now updated every second, regardless of the delay in the OLED plugin. But I did not think of "disabled" display. So could you also test using the latest build, to see if it keeps staying off when set to off via the commands, or that the wifi symbol will enable the display again?
Forgot to test that one.
Sure, would be happy to test that. Would issuing the command to turn off the oled be enough or should that be tested with button press as well. Now on the framedoled I have never seen the wifi symbol.
Issuing the command would be enough to test. If you've never seen the symbol, what size of display do you have? On smaller displays (e.g. 64x48), the symbol may be outside the visible range.
Verzonden vanaf laptop
On 13 February 2018 at 15:44, mattlward notifications@github.com wrote:
Sure, would be happy to test that. Would issuing the command to turn off the oled be enough or should that be tested with button press as well. Now on the framedoled I have never seen the wifi symbol.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/letscontrolit/ESPEasy/issues/839#issuecomment-365287102, or mute the thread https://github.com/notifications/unsubscribe-auth/ADk9lvHI8UAAMvYx1s-FjmkHlV-7iXNrks5tUZ-rgaJpZM4SAm1C .
That would be the issue, I am working with the 64x48 wemos display. It stacks well and can be velcro'ed with a cpu, sht30 and display on a dual base to the wall. I need to get a larger display for testing. Is there a suggested good I2C display that has more real estate?
I can still test the display off, it would awaken even if it is off screen, or should.
Well, I still have to allow support for smaller displays in the plugin. There are SSD1306 0.96" OLED displays with 128x64 and I2C. These are available in various colors (single color, 1bit, per pixel)
But I will test it later tonight at home.
So the wifi symbol on the little i2c cell displays actually means something here? I have some of the little nokia 5110 displays, alas they are not i2c. I assume for the sake of simplicity that a monochrome display is best. Will have to find an order a couple to test with.
Hmmm, not sure if we understand eachother. On the 128x64 display, using the OLED Framed plugin, a symbol is drawn indicating the WiFi strength. Up to 5 bars will be shown depending on the RSSI value from the WiFi. With no connection, it is currently empty, but I was planning on showing something indicating the nr of retries, or something like that.
Verzonden vanaf laptop
On 13 February 2018 at 16:05, mattlward notifications@github.com wrote:
So the wifi symbol on the little i2c cell displays actually means something here? I have some of the little nokia 5110 displays, alas they are not i2c. I assume for the sake of simplicity that a monochrome display is best. Will have to find an order a couple to test with.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/letscontrolit/ESPEasy/issues/839#issuecomment-365293826, or mute the thread https://github.com/notifications/unsubscribe-auth/ADk9ljse2ObE7_5mvQQWeyKuI4AmskmGks5tUaSwgaJpZM4SAm1C .
That link you provided, is quite expensive for one. If my memory serves me right, I paid about half per piece. Doesn't really matter if you buy one, but if you plan on buying more... ;)
Also pay attention on the pinout. There exist two versions. VCC, GND, <I2C
pins> and GND, VCC,
Verzonden vanaf laptop
On 13 February 2018 at 16:28, mattlward notifications@github.com wrote:
That sounds awsome! Will have to order 1 today! https://www.ebay.com/itm/0-96-I2C-IIC-Serial-128X64-White- OLED-LED-Display-Module-for-Arduino-SSD1306/391968484031? epid=2011557194&hash=item5b43246abf:g:5YcAAOSw301aaWBz:sc: USPSFirstClass!61849!US!-1
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/letscontrolit/ESPEasy/issues/839#issuecomment-365300905, or mute the thread https://github.com/notifications/unsubscribe-auth/ADk9lpa1fiA-_AxgjYE4PisIyN9cM6nyks5tUaoOgaJpZM4SAm1C .
You are probably right about the price. Did not want to wait weeks to get it from China. Buying 1 now for testing and if they work out well and I can house the unit some way I may get more.
Tested this and it works like it should.
For the SH1106 displays, only two levels of contrast work. On those displays, there is no difference between medium and high.
The command OLEDFRAMEDCMD,Off works great! Setting up to test the button idea now.
It works!!!
My rule:
On Switch#SwitchA Do
If [Switch#SwitchA]=1
OLEDFRAMEDCMD,High
Else
OLEDFRAMEDCMD,Low
Endif
Endon
I had a mistake in the names of the switch and the switch port.
I did have to define my last devices slot as a switch, this should be doable on the the display device. I was not able to figure out how to do it. Also the display device only has one button slot, not 2.
The name of the display device is "Display", but I could not figure out the name of the switch on the display to call the action.
You did it correctly. The "display button" in the display device setting can't be detected in rules since it's only a defined gpio for the display plugin.
So, my SSD1306 display came in and it is actually an SH1106 display. looks great, only has 2 display levels. I2C id's it as a PCF8574A. When configured as a 1306 the display is garbage an when 1106 it looks great.
See discussion here: https://www.letscontrolit.com/forum/viewtopic.php?p=24406#p24406