Heltec SSD1306 Display Support

[NorthernMan54]

Description:

This should be good to be merged now. I added it to Platformio.ini as a separate environment as I do not have the ability to test and validate the heltec-wifi-lora-32 environments. It should be tested as I pulled in the Heltec library for the board, and it includes lora libraries as well.

Will include the support with the rtl_433_ESP environment as well.

Checklist:

• The pull request is done against the latest development branch
• Only one feature/fix was added per PR and the code change compiles without warnings
• I accept the DCO.

[1technophile]

Thanks I will test it by Monday

[NorthernMan54]

I just ran a compile of the 'heltec-wifi-lora-32-915' environment with the display enabled, and it fails due to duplicate lora functions. I then removed the library '${libraries.lora}' and it fails due to minor differences in the API between the Heltec version and the 'arduino-LoRa' library.

Let me try a different display library and see.

[NorthernMan54]

Switched to the thingpulse/ESP8266 and ESP32 OLED driver for SSD1306 displays@^4.3.0 library which was the base for the Heltec library. This should work with the lora module enabled now.

[1technophile]

Hello,

I have try to add BT to it and unfortunately I'm encountering an issue at start

************* WELCOME TO OpenMQTTGateway **************
N: Setup HELTEC Display end
[E][Preferences.cpp:472] getString(): nvs_get_str len fail: BTConfig NOT_FOUND
{
  "bleconnect": true,
  "interval": 0,
  "scanbcnct": 10,
  "onlysensors": false,
  "hasspresence": false,
  "presenceTopic": "presence/",
  "presenceUseBeaconUuid": false,
  "minrssi": -100,
  "extDecoderEnable": false,
  "extDecoderTopic": "undecoded",
  "filterConnectable": false,
  "pubKnownServiceData": false,
  "pubUnknownServiceData": true,
  "pubKnownManufData": false,
  "pubUnknownManufData": true,
  "pubServiceDataUUID": false,
  "pubBeaconUuidForTopic": false,
  "ignoreWBlist": false
}
Guru Meditation Error: Core  1 panic'ed (IntegerDivideByZero). Exception was unhandled.
Core 1 register dump:
PC      : 0x400fd7eb  PS      : 0x00060f30  A0      : 0x800fdc0e  A1      : 0x3ffcdc20
A2      : 0x00000133  A3      : 0x00000000  A4      : 0x00000032  A5      : 0x3ffbe0e0  
A6      : 0x0002bf20  A7      : 0x60013000  A8      : 0x00000113  A9      : 0x3ffcdc00
A10     : 0x00000000  A11     : 0x00000000  A12     : 0x3ffba9a8  A13     : 0x3ffc5d7c  
A14     : 0x00002710  A15     : 0x3ffbe0e0  SAR     : 0x0000001c  EXCCAUSE: 0x00000006
EXCVADDR: 0x00000000  LBEG    : 0x4000c46c  LEND    : 0x4000c477  LCOUNT  : 0x00000000  

ELF file SHA256: 0000000000000000

Decoded:

0x400fd7eb: i2cProcQueue at C:/Users//.platformio/packages/framework-arduinoespressif32/cores/esp32/esp32-hal-i2c.c line 1287
0x400fdc0b: i2cWrite at C:/Users//.platformio/packages/framework-arduinoespressif32/cores/esp32/esp32-hal-i2c.c line 1632
0x400e2d25: TwoWire::writeTransmission(unsigned short, unsigned char*, unsigned short, bool) at C:/Users//.platformio/packages/framework-arduinoespressif32/libraries/Wire/src/Wire.cpp line 144
0x400e2d59: TwoWire::endTransmission(bool) at C:/Users//.platformio/packages/framework-arduinoespressif32/libraries/Wire/src/Wire.cpp line 169
0x400e2db5: TwoWire::endTransmission() at C:/Users//.platformio/packages/framework-arduinoespressif32/libraries/Wire/src/Wire.cpp line 327
0x400d2661: SSD1306Wire::display() at .pio/libdeps/heltec-display-ssd1306/ESP8266 and ESP32 OLED driver for SSD1306 displays/src/SSD1306Wire.h line 151
0x400d2286: OledSerial::write(unsigned char) at D:/GitHub/OpenMQTTGateway/main/ZboardHeltec.ino line 123
0x401ac3f5: Print::print(char) at C:/Users/flori_i3xbglh/.platformio/packages/framework-arduinoespressif32/cores/esp32/Print.cpp line 94
0x400d3754: Logging::printLevel__FlashStringHelper const*>(int, __FlashStringHelper const*, ...) at .pio/libdeps/heltec-display-ssd1306/ArduinoLog/ArduinoLog.h line 287
0x400d37d5: Logging::notice__FlashStringHelper const*>(__FlashStringHelper const*) at .pio/libdeps/heltec-display-ssd1306/ArduinoLog/ArduinoLog.h line 226
0x400d40b2: BLEscan() at D:/GitHub/OpenMQTTGateway/main/ZgatewayBT.ino line 643
0x400d7035: coreTask(void*) at D:/GitHub/OpenMQTTGateway/main/ZgatewayBT.ino line 746
0x40091606: vPortTaskWrapper at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/freertos/port.c line 143

Here is the environment:

[env:heltec-display-ssd1306]   ; Heltec ESP32 Board with SSD1306 display
platform = ${com.esp32_platform}
board = heltec_wifi_lora_32_V2
lib_deps =
  ${com-esp.lib_deps}
  ${libraries.wifimanager32}
  ${libraries.ssd1306} 
  ${libraries.ble}
  ${libraries.decoder}
build_flags =
  ${com-esp.build_flags}
; *** OpenMQTTGateway Config ***
  '-DGateway_Name="OpenMQTTGateway_Heltec_Display"'
  '-DMQTT_USER=""'
  '-DTimeBtwRead=0'
  '-DScan_duration=5000'
  '-DMQTT_PASS=""'
  '-DMQTT_SERVER="192.168.1.17"'
  '-DScanBeforeConnect=10'
  '-DActiveBLEScan=true'
  '-DESPWifiManualSetup=true'
  '-Dwifi_ssid=""'
  '-Dwifi_password=""'
  '-DZgatewayBT="BT"'
; *** OpenMQTTGateway Modules ***
  '-DZboardHELTEC="HELTEC"'
; *** Heltec Board Options ***
  '-DLOG_TO_LCD=true'         ; Enable log to LCD
;  '-DLOG_LEVEL_LCD=LOG_LEVEL_TRACE'

If I comment:
'-DLOG_TO_LCD=true'
It works properly

Or if I set:

#  define LOG_LEVEL_LCD LOG_LEVEL_WARNING 

The gateway scan properly but stay stuck on the screen to the last Warning message "MQTT connection"

I had similar issue when implementing M5Stack screens, this is why their logs level is set by default to:

#define LOG_LEVEL_LCD LOG_LEVEL_WARNING

I haven't found the root cause, but I think it makes sense to restrict the display to Errors and Warnings unless action is required by the user.

Maybe we could leverage the same messages that are used for the M5 family like:

OpenMQTTGateway/main/main.ino

Line 527 in 8c7c114

#if defined(ZboardM5STICKC) || defined(ZboardM5STICKCP) || defined(ZboardM5STACK) || defined(ZboardM5TOUGH)

OpenMQTTGateway/main/main.ino

Line 1203 in 8c7c114

# if defined(ZboardM5STICKC) || defined(ZboardM5STICKCP) || defined(ZboardM5STACK) || defined(ZboardM5TOUGH)

OpenMQTTGateway/main/main.ino

Line 1230 in 8c7c114

# if defined(ZboardM5STICKC) || defined(ZboardM5STICKCP) || defined(ZboardM5STACK) || defined(ZboardM5TOUGH)

OpenMQTTGateway/main/main.ino

Line 887 in 8c7c114

# if defined(ZboardM5STICKC) || defined(ZboardM5STICKCP) || defined(ZboardM5STACK) || defined(ZboardM5TOUGH)

OpenMQTTGateway/main/main.ino

Line 876 in 8c7c114

# if defined(ZboardM5STICKC) || defined(ZboardM5STICKCP) || defined(ZboardM5STACK) || defined(ZboardM5TOUGH)

To sum up my suggestions:

1. Filtering per default the log message to LCD with the warning level
2. adding this board with the messages pointed out above

Alternatively, you could investigate the root cause for the core dump, but I'm not sure we need to display INFO or NOTICE level on these small LCDs, mainly because those long messages will be difficult to read.

[NorthernMan54]

I personally found that NOTICE level logging was more interesting to watch, but will change the default to WARNING.

In regards to your second suggestion, I saw the M5Print messages, and was thinking to refactor that code so that it would work with either the M5 or Heltec display. And simplify it for future use. But this would need regression testing with a M5 device. I don't have an M5 in my setup, do you have the ability to do some testing ?

In regards to the crash when running the BT decoder, I'm going to dig into this further. I had some issues with my rtl_433_ESP code, and the display getting corrupted that was triggered by a task doing logging from core0. Resolved by moving the task to core1.

[1technophile]

For sure I can do regression testing on the M5 family.

If you found the root cause I will be happy to keep it to notice and maybe with a smaller font :-)