lordjaxom commented 2 years ago

The problem

When trying to upload a TFT file to the Nextion display in my NSPanel, I am always getting "Reading from UART timed out at byte 0!".

When flashing Tasmota and uploading the berry driver, the TFT upload is working, only with ESPHome I can't upload. I have tried with the stock firmware on the display (that one that's installed when it's new) and with the one that''s installed after perfoming these steps with Tasmota: https://docs.nspanel.pky.eu/prepare_nspanel/#flash-firmware-to-nextion-screen

After the messages seen in the log, the device restarts.

I have tried with and without PR#2956

I have also increased the UART timeout to 250, as proposed in another Issue here, with no success. (as committed in https://github.com/lordjaxom/esphome branch dev)

I have also tried several ESPHome configurations mentioned in this thread: https://community.home-assistant.io/t/sonoff-nspanel-uploading-tft-to-nextion-display-fails/418693

I have triggered the upload using the attached (stripped) YAML file by sending PRESSED to the MQTT topic nspanel/button/nspanel-dev_update_tft/command

Which version of ESPHome has the issue?

2022.8.0

What type of installation are you using?

pip

Which version of Home Assistant has the issue?

No response

What platform are you using?

ESP32

Board

NSPanel

Component causing the issue

nextion

Example YAML snippet

# Set some variables for convenience
substitutions:
  node_name: nspanel
  device_name: nspanel-dev

# Note: this may not be needed if the pull request has been merged.
# Check https://github.com/esphome/esphome/pull/2956 for current status.
external_components:
  - source: github://pr#2956
    components: [nextion]
    refresh: 1h

esphome:
  name: $node_name
  comment: $device_name

esp32:
  board: esp32dev

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

# Enable MQTT
mqtt:
  broker: !secret mqtt_broker
  id: mqtt_client
  client_id: $device_name
  discovery: false
  will_message:

# A reboot button is always useful
button:
  - platform: restart
    name: Restart $device_name

  # A button for the TFT upload
  - platform: template
    name: $device_name Update TFT
    device_class: update
    on_press:
      then:
        - lambda: 'id(disp1)->upload_tft();'

# Configure UART for communicating with the screen
uart:
  id: tf_uart
  tx_pin: 16
  rx_pin: 17
  baud_rate: 115200

# Configure the screen itself
display:
  - platform: nextion
    id: disp1
    uart_id: tf_uart
    tft_url: http://192.168.176.40:8080/hmi.tft

Anything in the logs that might be useful for us?

[22:22:32][D][button:013]: 'nspanel-dev Update TFT' Pressed.
[22:22:32][D][nextion_upload:169]: Connected
[22:22:32][D][nextion_upload:175]: Requesting URL: http://192.168.176.40:8080/hmi.tft
[22:22:32][D][nextion_upload:209]: Updating Nextion NX4832F035_011C...
[22:22:32][D][nextion_upload:235]: Waiting for upgrade response
[22:22:32][E][uart:015]: Reading from UART timed out at byte 0!
[22:22:32][E][uart:015]: Reading from UART timed out at byte 0!
[22:22:32][E][uart:015]: Reading from UART timed out at byte 0!
[22:22:32][E][uart:015]: Reading from UART timed out at byte 0!
[22:22:33][E][uart:015]: Reading from UART timed out at byte 0!
[22:22:33][E][uart:015]: Reading from UART timed out at byte 0!
[22:22:33][E][uart:015]: Reading from UART timed out at byte 0!
[22:22:33][E][uart:015]: Reading from UART timed out at byte 0!
[22:22:33][E][uart:015]: Reading from UART timed out at byte 0!
[22:22:33][E][uart:015]: Reading from UART timed out at byte 0!
[22:22:33][E][uart:015]: Reading from UART timed out at byte 0!
[22:22:33][E][uart:015]: Reading from UART timed out at byte 0!
[22:22:34][E][uart:015]: Reading from UART timed out at byte 0!
[22:22:34][E][uart:015]: Reading from UART timed out at byte 0!
[22:22:34][E][uart:015]: Reading from UART timed out at byte 0!
[22:22:34][E][uart:015]: Reading from UART timed out at byte 0!
[22:22:34][E][uart:015]: Reading from UART timed out at byte 0!
[22:22:34][D][nextion_upload:239]: Upgrade response is  42
[22:22:34][D][nextion_upload:242]: Available 0 : 0x00
[22:22:34][D][nextion_upload:242]: Available 1 : 0x00
[22:22:34][D][nextion_upload:242]: Available 2 : 0x00
[22:22:34][D][nextion_upload:242]: Available 3 : 0x00

Additional information

No response

Joni1983 commented 2 years ago

Same her :(

Joni1983 commented 2 years ago

[18:38:03][E][uart:015]: Reading from UART timed out at byte 0! [18:38:03][D][nextion_upload:239]: Upgrade response is U\xbb 43 [18:38:03][D][nextion_upload:242]: Available 0 : 0x55 [18:38:03][D][nextion_upload:242]: Available 1 : 0xBB [18:38:03][D][nextion_upload:242]: Available 2 : 0x13 [18:38:03][D][nextion_upload:242]: Available 3 : 0x00 [18:38:03][D][nextion_upload:242]: Available 4 : 0x65 [18:38:03][D][nextion_upload:242]: Available 5 : 0x76 [18:38:03][D][nextion_upload:242]: Available 6 : 0x65 [18:38:03][D][nextion_upload:242]: Available 7 : 0x6E [18:38:03][D][nextion_upload:242]: Available 8 : 0x74 [18:38:03][D][nextion_upload:242]: Available 9 : 0x2C [18:38:03][D][nextion_upload:242]: Available 10 : 0x73 [18:38:03][D][nextion_upload:242]: Available 11 : 0x74 [18:38:03][D][nextion_upload:242]: Available 12 : 0x61 [18:38:03][D][nextion_upload:242]: Available 13 : 0x72 [18:38:03][D][nextion_upload:242]: Available 14 : 0x74 [18:38:03][D][nextion_upload:242]: Available 15 : 0x75 [18:38:03][D][nextion_upload:242]: Available 16 : 0x70 [18:38:03][D][nextion_upload:242]: Available 17 : 0x2C [18:38:03][D][nextion_upload:242]: Available 18 : 0x33 [18:38:03][D][nextion_upload:242]: Available 19 : 0x39 [18:38:03][D][nextion_upload:242]: Available 20 : 0x2C [18:38:03][D][nextion_upload:242]: Available 21 : 0x65 [18:38:03][D][nextion_upload:242]: Available 22 : 0x75 [18:38:03][D][nextion_upload:242]: Available 23 : 0xDC [18:38:03][D][nextion_upload:242]: Available 24 : 0x50 [18:38:03][D][nextion_upload:242]: Available 25 : 0x50 [18:38:03][D][nextion_upload:242]: Available 26 : 0x50 [18:38:03][D][nextion_upload:242]: Available 27 : 0x50 [18:38:03][D][nextion_upload:242]: Available 28 : 0x50 [18:38:03][D][nextion_upload:242]: Available 29 : 0x50 [18:38:03][D][nextion_upload:242]: Available 30 : 0x50 [18:38:03][D][nextion_upload:242]: Available 31 : 0x50 [18:38:03][D][nextion_upload:242]: Available 32 : 0x50 [18:38:03][D][nextion_upload:242]: Available 33 : 0x50 [18:38:03][D][nextion_upload:242]: Available 34 : 0x50 [18:38:03][D][nextion_upload:242]: Available 35 : 0x50 [18:38:03][D][nextion_upload:242]: Available 36 : 0x50 [18:38:03][D][nextion_upload:242]: Available 37 : 0x50 [18:38:03][D][nextion_upload:242]: Available 38 : 0x50 [18:38:03][D][nextion_upload:242]: Available 39 : 0x50 [18:38:03][D][nextion_upload:242]: Available 40 : 0x50 [18:38:03][D][nextion_upload:242]: Available 41 : 0x50 [18:38:03][D][nextion_upload:242]: Available 42 : 0x50 [18:38:03][D][nextion_upload:248]: preparation for tft update failed 85 "U\xbb" [18:38:03][D][nextion_upload:324]: Restarting Nextion INFO nspanel.local: Error while reading incoming messages: Error while reading data: [Errno 104] Connection reset by peer INFO Disconnected from ESPHome API for nspanel.local WARNING Disconnected from API INFO nspanel.local: Ping Failed: Error while reading data: [Errno 104] Connection reset by peer INFO Successfully connected to nspanel.local

EzzatQ commented 2 years ago

+1 I am not able to upload the TFT file to my nspanel Every time I call the upload_tft service from HA, I get the following in my logs:

[21:12:06][D][nextion_upload:169]: Connected
[21:12:06][D][nextion_upload:175]: Requesting URL: http://10.0.1.1:8123/local/nspanel/hmi.tft
[21:12:06][D][nextion_upload:209]: Updating Nextion NX4832F035_011C...
[21:12:06][D][nextion_upload:235]: Waiting for upgrade response
[21:12:06][E][uart:015]: Reading from UART timed out at byte 0!
[21:12:07][E][uart:015]: Reading from UART timed out at byte 0!
[21:12:07][E][uart:015]: Reading from UART timed out at byte 0!
[21:12:07][E][uart:015]: Reading from UART timed out at byte 0!
[21:12:07][E][uart:015]: Reading from UART timed out at byte 0!
[21:12:07][E][uart:015]: Reading from UART timed out at byte 0!
[21:12:07][E][uart:015]: Reading from UART timed out at byte 0!
[21:12:07][E][uart:015]: Reading from UART timed out at byte 0!
[21:12:07][E][uart:015]: Reading from UART timed out at byte 0!
[21:12:07][E][uart:015]: Reading from UART timed out at byte 0!
[21:12:08][E][uart:015]: Reading from UART timed out at byte 0!
[21:12:08][E][uart:015]: Reading from UART timed out at byte 0!
[21:12:08][E][uart:015]: Reading from UART timed out at byte 0!
[21:12:08][E][uart:015]: Reading from UART timed out at byte 0!
[21:12:08][E][uart:015]: Reading from UART timed out at byte 0!
[21:12:08][E][uart:015]: Reading from UART timed out at byte 0!
[21:12:08][E][uart:015]: Reading from UART timed out at byte 0!
[21:12:08][E][uart:015]: Reading from UART timed out at byte 0!
[21:12:08][E][uart:015]: Reading from UART timed out at byte 0!
[21:12:08][D][nextion_upload:239]: Upgrade response is  19
[21:12:08][D][nextion_upload:242]: Available 0 : 0x00
[21:12:08][D][nextion_upload:242]: Available 1 : 0x00
[21:12:08][D][nextion_upload:242]: Available 2 : 0x00
[21:12:08][D][nextion_upload:242]: Available 3 : 0x00
[21:12:08][D][nextion_upload:242]: Available 4 : 0x00
[21:12:08][D][nextion_upload:242]: Available 5 : 0x00
[21:12:08][D][nextion_upload:242]: Available 6 : 0x00
[21:12:08][D][nextion_upload:242]: Available 7 : 0x00
[21:12:08][D][nextion_upload:242]: Available 8 : 0x00
[21:12:08][D][nextion_upload:242]: Available 9 : 0x00
[21:12:08][D][nextion_upload:242]: Available 10 : 0x00
[21:12:08][D][nextion_upload:242]: Available 11 : 0x00
[21:12:08][D][nextion_upload:242]: Available 12 : 0x00
[21:12:08][D][nextion_upload:242]: Available 13 : 0x00
[21:12:08][D][nextion_upload:242]: Available 14 : 0x00
[21:12:08][D][nextion_upload:242]: Available 15 : 0x00
[21:12:09][D][nextion_upload:242]: Available 16 : 0x00
[21:12:09][D][nextion_upload:242]: Available 17 : 0x00
[21:12:09][D][nextion_upload:242]: Available 18 : 0x00
[21:12:09][D][nextion_upload:248]: preparation for tft update failed 0 ""
[21:12:09][D][nextion_upload:324]: Restarting Nextion
[21:12:10][D][nextion_upload:327]: Restarting esphome

Please help, I've been on this for hours. I also tried removing everything that's not essential to the upload from my esphome config and this is what I'm left with:

substitutions:
  # Name the device and it's entities
  device_name: master_bedroom_nspanel

# Example config.yaml
esphome:
  name: master_bedroom_nspanel
  comment: $device_name

esp32:
  board: esp32dev

# Wifi settings. Add these to your secrets.yaml. fast_connect must be true for a hidden ssid.
wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

# API. 
api:

  services:
    # Service to update the HMI file
    - service: upload_tft
      then:
        - lambda: 'id(disp1)->upload_tft();'

        -  # Logger. Disable the temperature sensor etc. to focus on the HMI development
logger:
  baud_rate: 0
  level: DEBUG
  logs:
    sensor: WARN
    resistance: WARN
    text_sensor: WARN
    ntc: WARN

# OTA (Over the air updates) password. Add to your secrets.yaml
ota:

# Uart for the Nextion display
uart:
  tx_pin: 16
  rx_pin: 17
  baud_rate: 115200
  id: tf_uart

# Functionality for the Nextion display
external_components:
  - source: github://pr#2956
    components: [nextion]
    refresh: 1h

# Configure the screen itself
display:
  - platform: nextion
    id: disp1
    uart_id: tf_uart
    tft_url: !secret tft_upload_url

However, I still get the same logs and nothing happens. This is driving me crazy. (I've already ruined 2 nspanels trying to solder the wires directly to the nextion display and flashing it from nextion editor, And I really want this 3rd one to work 🥲)

lordjaxom commented 2 years ago

For the moment I have switched to Tasmota (the upload works flawlessly there as stated in my original post), implementing the necessary commands and responses with BerryScript.

Although I really fell in love with the concepts of ESPHome, which I only discovered a few months ago through the NSPanels (after using Tasmota for decades) this sadly is a showstopper :-(

EzzatQ commented 2 years ago

Any idea what the root cause is? The weird thing is that the upload initially worked. It stopped working after I updated the esphome config (doesn't seem to be related, but I guess it is), then after some playing around, it worked once more (no clue what made it work since I only changed what the physical buttons' actions on the NSPanel do), and then stopped again (it's been a week now)

I saw there are a lot of threads about this but no one seems to know what the issue really is.

Oh well. Could you please share what you did with Tasmota. I never worked with tasmota and would prefer to stay in esphome, but If that's the only way it'll work I guess I gotta do what I gotta do

romainrossi commented 2 years ago

Hi I came across this topic searching for another problem. I have 3 nspanel and the upload of the TFT file is working flawlessly. May I suggest to try something ? First of all, I had to add a 'on_setup' magic command to prevent a 30 pixel offset between the touch screen and display :

display:
  - platform: nextion
    id: disp1
    uart_id: tf_uart
    tft_url: $nextion_update_url
    on_setup:
      then:
        - lambda: id(disp1).send_command_printf("lcd_dev fffb 0002 0000 0020"); # Magic command to avoid 32pixel touchscreen offset on NSPanel (https://github.com/UNUF/nxt-doc/blob/main/Protocols/Full%20Instruction%20Set.md#readme)

Another thing : on my firsts attempts to upload TFT files on the NSpanel, I had some issues similar to the one you describe. At that time I thought it was my own incompetency so I didn't paid much attention and keep trying. It finally worked when I uploaded a very small TFT file before uploading the final one. If you want I can provide the one I used, but I really think it will work with any very small tft file. ... Or maybe, it was this : https://github.com/esphome/esphome/pull/2956

I am sorry that I can't be more specific on you issue, but maybe this advice can help. Good luck !

EzzatQ commented 2 years ago

thank you @romainrossi for your reply. For once someone gave concrete steps to take to fix this issue.

I will try to add the lambda to my ESPHome config. Could you please also provide the TFT file you used ? I think it would also be useful for other people with this issue.

EzzatQ commented 2 years ago

@romainrossi I tried adding the 2 lines you mentioned

on_setup:
      then:
        - lambda: id(disp1).send_command_printf("lcd_dev fffb 0002 0000 0020"); # Magic command to avoid 32pixel touchscreen offset on NSPanel (https://github.com/UNUF/nxt-doc/blob/main/Protocols/Full%20Instruction%20Set.md#readme)
        - lambda: id(disp1).send_command_printf("DRAKJHSUYDGBNCJHGJKSHBDN");

but the upload still failed. Trying to search for a small TFT file for now

romainrossi commented 2 years ago

@EzzatQ Here it is. It is not from me, I used a tft file from another project on Github (dear original author, forgive me as I don't remember who you are). small.zip I hope it will help...

cybericebyte commented 2 years ago

I have a hunch about this issue could you please check the tags on your display and tell me what it says the one on the left is the one I have an issue with as you can see the label tag is slightly different. I have been told that is just a printing error but Im not so sure NSPanel_side_by_side

EzzatQ commented 2 years ago

@romainrossi I tried uploading the small tft file but with no avail. @cybericebyte I have the EU version of the NSPanel. The sticker reads:

E32-MSW-NX
100162fdf2
P/N: WW220010
NSPanel-EU

EzzatQ commented 2 years ago

After spending so much time trying to get the TFT file to upload, I decided to go on and try to flash this project: https://github.com/joBr99/nspanel-lovelace-ui and honestly it is so much better and easier than ESPHome

randybb commented 2 years ago

I am using https://github.com/sairon/esphome-nspanel-lovelace-ui and no issues with tft upload. Have to mentioned that I never had such problem with our "default" nspanel component.

lordjaxom commented 2 years ago

After spending so much time trying to get the TFT file to upload, I decided to go on and try to flash this project: https://github.com/joBr99/nspanel-lovelace-ui and honestly it is so much better and easier than ESPHome

I used their instructions to get anything flashed at all. So flashing in general works definitely. Must be something with ESPHome's serial driver IMHO.

I didn't try actually using the Lovelace UI. Do you need special infrastructure for it? I'm using OpenHAB.

cybericebyte commented 2 years ago

ok guys in esphome yaml file for the panel try changing uart baud rate to 9600 or if already at 9600 change to 115200. thats what solved the issue for me example :

uart: tx_pin: 16 rx_pin: 17 baud_rate: 9600 #115200 id: tf_uart

platima commented 2 years ago

Hey I am getting this too. I tried replacing the PR with the on_boot action, not having the logger connected, dropping baud to 9600 instead of 115200, trying the 'small' HMI, to no avail. US version of the panel stamped "NSPanel 120 M Board V1.7 \n 2021.05.27" and the sticker says "E32-MSW-NX \n 10015d05c7 \n P/N: WW210954 \n NSPanel-US". After 4 hours I gave up and put the NSPanel back in the drawer. Could it be the HMI being meant for EU (square) not US (rect)? Would love any help!

cybericebyte commented 2 years ago

Quick check list check ribbon cable from display to board only change the UART baud rate no others if you do not have currently displaying tft file you may need to upload a new one but you should not see the errors in the log. also in my case I discovered with this one oddball display where I had to change the UART the partition for tft is smaller than the others. at one point I had to upload a different tft the small tft did not work for me

randybb commented 2 years ago

nextion will raise an error if is updated with a tft file for a different type

cybericebyte commented 2 years ago

nextion will raise an error if is updated with a tft file for a different type

believe it or not you can still get that error even if its not. I have 7 of these things and I have only tweaked the ui in small places and have gotten that error. sometimes I have to go back a few files upload one from another then upload the one I wanted.

platima commented 2 years ago

nextion will raise an error if is updated with a tft file for a different type

Oh awesome to know, cheers!

platima commented 2 years ago

Quick check list check ribbon cable from display to board only change the UART baud rate no others if you do not have currently displaying tft file you may need to upload a new one but you should not see the errors in the log. also in my case I discovered with this one oddball display where I had to change the UART the partition for tft is smaller than the others. at one point I had to upload a different tft the small tft did not work for me

I think you may be right re the ribbon cable - re-seating that is the only thing I did not try. Else I might also try flashing it directly via the TF_RX/TX pins to cut the ESPHome code out as the middleman. Would make UI tweaking a lot easier!

cybericebyte commented 2 years ago

Would make UI tweaking a lot easier!

agreed!

asferreira commented 1 year ago

The problem

When trying to upload a TFT file to the Nextion display in my NSPanel, I am always getting "Reading from UART timed out at byte 0!".

When flashing Tasmota and uploading the berry driver, the TFT upload is working, only with ESPHome I can't upload. I have tried with the stock firmware on the display (that one that's installed when it's new) and with the one that''s installed after perfoming these steps with Tasmota: https://docs.nspanel.pky.eu/prepare_nspanel/#flash-firmware-to-nextion-screen

After the messages seen in the log, the device restarts.

I have tried with and without PR#2956

I have also increased the UART timeout to 250, as proposed in another Issue here, with no success. (as committed in https://github.com/lordjaxom/esphome branch dev)

I have also tried several ESPHome configurations mentioned in this thread: https://community.home-assistant.io/t/sonoff-nspanel-uploading-tft-to-nextion-display-fails/418693

I have triggered the upload using the attached (stripped) YAML file by sending PRESSED to the MQTT topic nspanel/button/nspanel-dev_update_tft/command

Which version of ESPHome has the issue?

2022.8.0

What type of installation are you using?

pip

Which version of Home Assistant has the issue?

No response

What platform are you using?

ESP32

Board

NSPanel

Component causing the issue

nextion

Example YAML snippet
# Set some variables for convenience
substitutions:
  node_name: nspanel
  device_name: nspanel-dev

# Note: this may not be needed if the pull request has been merged.
# Check https://github.com/esphome/esphome/pull/2956 for current status.
external_components:
  - source: github://pr#2956
    components: [nextion]
    refresh: 1h

esphome:
  name: $node_name
  comment: $device_name

esp32:
  board: esp32dev

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

# Enable MQTT
mqtt:
  broker: !secret mqtt_broker
  id: mqtt_client
  client_id: $device_name
  discovery: false
  will_message:

# A reboot button is always useful
button:
  - platform: restart
    name: Restart $device_name

  # A button for the TFT upload
  - platform: template
    name: $device_name Update TFT
    device_class: update
    on_press:
      then:
        - lambda: 'id(disp1)->upload_tft();'

# Configure UART for communicating with the screen
uart:
  id: tf_uart
  tx_pin: 16
  rx_pin: 17
  baud_rate: 115200

# Configure the screen itself
display:
  - platform: nextion
    id: disp1
    uart_id: tf_uart
    tft_url: http://192.168.176.40:8080/hmi.tft
Anything in the logs that might be useful for us?
[22:22:32][D][button:013]: 'nspanel-dev Update TFT' Pressed.
[22:22:32][D][nextion_upload:169]: Connected
[22:22:32][D][nextion_upload:175]: Requesting URL: http://192.168.176.40:8080/hmi.tft
[22:22:32][D][nextion_upload:209]: Updating Nextion NX4832F035_011C...
[22:22:32][D][nextion_upload:235]: Waiting for upgrade response
[22:22:32][E][uart:015]: Reading from UART timed out at byte 0!
[22:22:32][E][uart:015]: Reading from UART timed out at byte 0!
[22:22:32][E][uart:015]: Reading from UART timed out at byte 0!
[22:22:32][E][uart:015]: Reading from UART timed out at byte 0!
[22:22:33][E][uart:015]: Reading from UART timed out at byte 0!
[22:22:33][E][uart:015]: Reading from UART timed out at byte 0!
[22:22:33][E][uart:015]: Reading from UART timed out at byte 0!
[22:22:33][E][uart:015]: Reading from UART timed out at byte 0!
[22:22:33][E][uart:015]: Reading from UART timed out at byte 0!
[22:22:33][E][uart:015]: Reading from UART timed out at byte 0!
[22:22:33][E][uart:015]: Reading from UART timed out at byte 0!
[22:22:33][E][uart:015]: Reading from UART timed out at byte 0!
[22:22:34][E][uart:015]: Reading from UART timed out at byte 0!
[22:22:34][E][uart:015]: Reading from UART timed out at byte 0!
[22:22:34][E][uart:015]: Reading from UART timed out at byte 0!
[22:22:34][E][uart:015]: Reading from UART timed out at byte 0!
[22:22:34][E][uart:015]: Reading from UART timed out at byte 0!
[22:22:34][D][nextion_upload:239]: Upgrade response is  42
[22:22:34][D][nextion_upload:242]: Available 0 : 0x00
[22:22:34][D][nextion_upload:242]: Available 1 : 0x00
[22:22:34][D][nextion_upload:242]: Available 2 : 0x00
[22:22:34][D][nextion_upload:242]: Available 3 : 0x00
Additional information

No response

I came across the same issue on my NS Panel (US Version) and it took me a long time to understand what really was going on! After many attempts to fix it I realized that every time I tried to trigger 'id(disp1)->upload_tft();' from a button component (the same way you did), the firmware update failed. In one of the attempts I decide to trigger the upload_tft() from the physical NS Panel's button (a gpio binary sensor component) and for my surprise, it worked! I still don't know the reason why triggering the upload_tft() using the button component fails and using the binary sensor does not, but since I've changed it, the firmware update has been working like a charm!

One more thing, I don't know if it is really necessary, but the first successful firmware upload I did after hit by the issue was using the small.tft file.

Hope it helps!

platima commented 1 year ago

Quick check list check ribbon cable from display to board only change the UART baud rate no others if you do not have currently displaying tft file you may need to upload a new one but you should not see the errors in the log. also in my case I discovered with this one oddball display where I had to change the UART the partition for tft is smaller than the others. at one point I had to upload a different tft the small tft did not work for me

Not the ribbon cable for me :(

platima commented 1 year ago

The problem

When trying to upload a TFT file to the Nextion display in my NSPanel, I am always getting "Reading from UART timed out at byte 0!". When flashing Tasmota and uploading the berry driver, the TFT upload is working, only with ESPHome I can't upload. I have tried with the stock firmware on the display (that one that's installed when it's new) and with the one that''s installed after perfoming these steps with Tasmota: https://docs.nspanel.pky.eu/prepare_nspanel/#flash-firmware-to-nextion-screen After the messages seen in the log, the device restarts. I have tried with and without PR#2956 I have also increased the UART timeout to 250, as proposed in another Issue here, with no success. (as committed in https://github.com/lordjaxom/esphome branch dev) I have also tried several ESPHome configurations mentioned in this thread: https://community.home-assistant.io/t/sonoff-nspanel-uploading-tft-to-nextion-display-fails/418693 I have triggered the upload using the attached (stripped) YAML file by sending PRESSED to the MQTT topic nspanel/button/nspanel-dev_update_tft/command

Which version of ESPHome has the issue?

2022.8.0

What type of installation are you using?

pip

Which version of Home Assistant has the issue?

No response

What platform are you using?

ESP32

Board

NSPanel

Component causing the issue

nextion

Example YAML snippet
# Set some variables for convenience
substitutions:
  node_name: nspanel
  device_name: nspanel-dev

# Note: this may not be needed if the pull request has been merged.
# Check https://github.com/esphome/esphome/pull/2956 for current status.
external_components:
  - source: github://pr#2956
    components: [nextion]
    refresh: 1h

esphome:
  name: $node_name
  comment: $device_name

esp32:
  board: esp32dev

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

# Enable MQTT
mqtt:
  broker: !secret mqtt_broker
  id: mqtt_client
  client_id: $device_name
  discovery: false
  will_message:

# A reboot button is always useful
button:
  - platform: restart
    name: Restart $device_name

  # A button for the TFT upload
  - platform: template
    name: $device_name Update TFT
    device_class: update
    on_press:
      then:
        - lambda: 'id(disp1)->upload_tft();'

# Configure UART for communicating with the screen
uart:
  id: tf_uart
  tx_pin: 16
  rx_pin: 17
  baud_rate: 115200

# Configure the screen itself
display:
  - platform: nextion
    id: disp1
    uart_id: tf_uart
    tft_url: http://192.168.176.40:8080/hmi.tft
Anything in the logs that might be useful for us?
[22:22:32][D][button:013]: 'nspanel-dev Update TFT' Pressed.
[22:22:32][D][nextion_upload:169]: Connected
[22:22:32][D][nextion_upload:175]: Requesting URL: http://192.168.176.40:8080/hmi.tft
[22:22:32][D][nextion_upload:209]: Updating Nextion NX4832F035_011C...
[22:22:32][D][nextion_upload:235]: Waiting for upgrade response
[22:22:32][E][uart:015]: Reading from UART timed out at byte 0!
[22:22:32][E][uart:015]: Reading from UART timed out at byte 0!
[22:22:32][E][uart:015]: Reading from UART timed out at byte 0!
[22:22:32][E][uart:015]: Reading from UART timed out at byte 0!
[22:22:33][E][uart:015]: Reading from UART timed out at byte 0!
[22:22:33][E][uart:015]: Reading from UART timed out at byte 0!
[22:22:33][E][uart:015]: Reading from UART timed out at byte 0!
[22:22:33][E][uart:015]: Reading from UART timed out at byte 0!
[22:22:33][E][uart:015]: Reading from UART timed out at byte 0!
[22:22:33][E][uart:015]: Reading from UART timed out at byte 0!
[22:22:33][E][uart:015]: Reading from UART timed out at byte 0!
[22:22:33][E][uart:015]: Reading from UART timed out at byte 0!
[22:22:34][E][uart:015]: Reading from UART timed out at byte 0!
[22:22:34][E][uart:015]: Reading from UART timed out at byte 0!
[22:22:34][E][uart:015]: Reading from UART timed out at byte 0!
[22:22:34][E][uart:015]: Reading from UART timed out at byte 0!
[22:22:34][E][uart:015]: Reading from UART timed out at byte 0!
[22:22:34][D][nextion_upload:239]: Upgrade response is  42
[22:22:34][D][nextion_upload:242]: Available 0 : 0x00
[22:22:34][D][nextion_upload:242]: Available 1 : 0x00
[22:22:34][D][nextion_upload:242]: Available 2 : 0x00
[22:22:34][D][nextion_upload:242]: Available 3 : 0x00
Additional information

No response
I came across the same issue on my NS Panel (US Version) and it took me a long time to understand what really was going on! After many attempts to fix it I realized that every time I tried to trigger 'id(disp1)->upload_tft();' from a button component (the same way you did), the firmware update failed. In one of the attempts I decide to trigger the upload_tft() from the physical NS Panel's button (a gpio binary sensor component) and for my surprise, it worked! I still don't know the reason why triggering the upload_tft() using the button component fails and using the binary sensor does not, but since I've changed it, the firmware update has been working like a charm!

One more thing, I don't know if it is really necessary, but the first successful firmware upload I did after hit by the issue was using the small.tft file.

Hope it helps!

Hey that is awesome - I have not tried triggering it using a button instead of a service!

I'll likely try that next week. Can I if you have a copy of the factory TFT / HMI file? Cannot find UART signals to download it.

Cheers

jflecool2 commented 1 year ago

Hello, After doing 8 consecutide TFT upgrade, it happened to me to.

Reset doesnt help,
9600 baud rate creates many error from esphome saying it cannot communicate,
the upgrade response is sometime 20 sometime 19.
I tried the reparse mode escape on boot, doesnt work
I tried physical button and service, doesnt work
my firmware is fine since my 2 other nspanel are on the same nspanel firmware and works well.
tried factory reset button
I think there's a mode that persist accross reboot or something... idk what...

jflecool2 commented 1 year ago

Update working on nspanel3: [22:20:57][D][nextion_upload:175]: Requesting URL: http://192.168.11.254:8123/local/tft/hmi_jf_gpsig.tft [22:20:57][D][nextion_upload:209]: Updating Nextion NX4832F035_011C... [22:20:57][D][nextion_upload:235]: Waiting for upgrade response [22:20:58][E][uart:015]: Reading from UART timed out at byte 0! [22:20:58][E][uart:015]: Reading from UART timed out at byte 0! [22:20:58][E][uart:015]: Reading from UART timed out at byte 0! [22:20:58][D][nextion_upload:239]: Upgrade response is 4 [22:20:58][D][nextion_upload:242]: Available 0 : 0x00 [22:20:58][D][nextion_upload:242]: Available 1 : 0x00 [22:20:58][D][nextion_upload:242]: Available 2 : 0x00 [22:20:58][D][nextion_upload:242]: Available 3 : 0x05 [22:20:58][D][nextion_upload:246]: preparation for tft update done [22:20:58][D][nextion_upload:283]: Allocating buffer size 65536, Heap size is 223476 [22:20:58][D][nextion_upload:305]: Updating tft from "http://192.168.11.254:8123/local/tft/hmi_jf_gpsig.tft" with a file size of 1072140 using 65536 chunksize, Heap Size 154248 [22:20:59][D][nextion_upload:044]: Requesting range: bytes=0-16383 [22:20:59][E][uart:015]: Reading from UART timed out at byte 0! [22:20:59][E][uart:015]: Reading from UART timed out at byte 0! [22:20:59][E][uart:015]: Reading from UART timed out at byte 0! [22:20:59][E][uart:015]: Reading from UART timed out at byte 0! [22:20:59][E][uart:015]: Reading from UART timed out at byte 0! [22:20:59][E][uart:015]: Reading from UART timed out at byte 0! [22:21:00][E][uart:015]: Reading from UART timed out at byte 0! [22:21:00][E][uart:015]: Reading from UART timed out at byte 0! [22:21:00][E][uart:015]: Reading from UART timed out at byte 0! [22:21:00][E][uart:015]: Reading from UART timed out at byte 0! [22:21:00][E][uart:015]: Reading from UART timed out at byte 0! [22:21:00][E][uart:015]: Reading from UART timed out at byte 0! [22:21:00][E][uart:015]: Reading from UART timed out at byte 0! [22:21:00][E][uart:015]: Reading from UART timed out at byte 0! [22:21:00][E][uart:015]: Reading from UART timed out at byte 0! [22:21:01][E][uart:015]: Reading from UART timed out at byte 0! [22:21:01][E][uart:015]: Reading from UART timed out at byte 0! [22:21:01][E][uart:015]: Reading from UART timed out at byte 0! [22:21:01][E][uart:015]: Reading from UART timed out at byte 0! [22:21:01][D][nextion_upload:117]: Nextion reported new range 786432 [22:21:01][D][nextion_upload:316]: Heap Size 170464, Bytes left 285708 [22:21:01][D][nextion_upload:044]: Requesting range: bytes=786432-851967 [22:21:07][D][nextion_upload:316]: Heap Size 177500, Bytes left 220172 [22:21:07][D][nextion_upload:044]: Requesting range: bytes=851968-917503

Update not working on nspanel2

[22:32:17][D][sensor:127]: 'NSPanel2 Temperature': Sending state 20.33959 °C with 1 decimals of accuracy [22:32:25][D][nextion_upload:169]: Connected [22:32:25][D][nextion_upload:175]: Requesting URL: http://MY_IP:8123/local/tft/hmi_jf_gpsig.tft [22:32:25][D][nextion_upload:209]: Updating Nextion NX4832F035_011C... [22:32:25][D][nextion_upload:235]: Waiting for upgrade response [22:32:25][E][uart:015]: Reading from UART timed out at byte 0! [22:32:25][E][uart:015]: Reading from UART timed out at byte 0! [22:32:26][E][uart:015]: Reading from UART timed out at byte 0! [22:32:26][E][uart:015]: Reading from UART timed out at byte 0! [22:32:26][E][uart:015]: Reading from UART timed out at byte 0! [22:32:26][E][uart:015]: Reading from UART timed out at byte 0! [22:32:26][E][uart:015]: Reading from UART timed out at byte 0! [22:32:26][E][uart:015]: Reading from UART timed out at byte 0! [22:32:26][E][uart:015]: Reading from UART timed out at byte 0! [22:32:26][E][uart:015]: Reading from UART timed out at byte 0! [22:32:26][E][uart:015]: Reading from UART timed out at byte 0! [22:32:27][E][uart:015]: Reading from UART timed out at byte 0! [22:32:27][E][uart:015]: Reading from UART timed out at byte 0! [22:32:27][E][uart:015]: Reading from UART timed out at byte 0! [22:32:27][E][uart:015]: Reading from UART timed out at byte 0! [22:32:27][E][uart:015]: Reading from UART timed out at byte 0! [22:32:27][E][uart:015]: Reading from UART timed out at byte 0! [22:32:27][E][uart:015]: Reading from UART timed out at byte 0! [22:32:27][E][uart:015]: Reading from UART timed out at byte 0! [22:32:27][E][uart:015]: Reading from UART timed out at byte 0! [22:32:27][D][nextion_upload:239]: Upgrade response is 20 [22:32:27][D][nextion_upload:242]: Available 0 : 0x00 [22:32:27][D][nextion_upload:242]: Available 1 : 0x00 [22:32:27][D][nextion_upload:242]: Available 2 : 0x00 [22:32:27][D][nextion_upload:242]: Available 3 : 0x00 [22:32:27][D][nextion_upload:242]: Available 4 : 0x00 [22:32:27][D][nextion_upload:242]: Available 5 : 0x00 [22:32:27][D][nextion_upload:242]: Available 6 : 0x00 [22:32:27][D][nextion_upload:242]: Available 7 : 0x00 [22:32:27][D][nextion_upload:242]: Available 8 : 0x00 [22:32:27][D][nextion_upload:242]: Available 9 : 0x00 [22:32:27][D][nextion_upload:242]: Available 10 : 0x00 [22:32:27][D][nextion_upload:242]: Available 11 : 0x00 [22:32:27][D][nextion_upload:242]: Available 12 : 0x00 [22:32:27][D][nextion_upload:242]: Available 13 : 0x00 [22:32:27][D][nextion_upload:242]: Available 14 : 0x00 [22:32:27][D][nextion_upload:242]: Available 15 : 0x00 [22:32:27][D][nextion_upload:242]: Available 16 : 0x00 [22:32:27][D][nextion_upload:242]: Available 17 : 0x00 [22:32:27][D][nextion_upload:242]: Available 18 : 0x00 [22:32:27][D][nextion_upload:242]: Available 19 : 0x00 [22:32:27][D][nextion_upload:248]: preparation for tft update failed 0 "" [22:32:27][D][nextion_upload:324]: Restarting Nextion

jflecool2 commented 1 year ago

An example of update not working with update rtesponse 19 instead (still on nspanel2) [01:21:52][D][main:476]: upload tft [01:21:52][D][nextion_upload:169]: Connected [01:21:52][D][nextion_upload:175]: Requesting URL: http://192.168.11.254:8123/local/tft/hmi_jf_gpsig.tft [01:21:52][D][nextion_upload:209]: Updating Nextion NX4832F035_011C... [01:21:52][D][nextion_upload:235]: Waiting for upgrade response [01:21:52][E][uart:015]: Reading from UART timed out at byte 0! [01:21:52][E][uart:015]: Reading from UART timed out at byte 0! [01:21:52][E][uart:015]: Reading from UART timed out at byte 0! [01:21:52][E][uart:015]: Reading from UART timed out at byte 0! [01:21:53][E][uart:015]: Reading from UART timed out at byte 0! [01:21:53][E][uart:015]: Reading from UART timed out at byte 0! [01:21:53][E][uart:015]: Reading from UART timed out at byte 0! [01:21:53][E][uart:015]: Reading from UART timed out at byte 0! [01:21:53][E][uart:015]: Reading from UART timed out at byte 0! [01:21:53][E][uart:015]: Reading from UART timed out at byte 0! [01:21:53][E][uart:015]: Reading from UART timed out at byte 0! [01:21:53][E][uart:015]: Reading from UART timed out at byte 0! [01:21:53][E][uart:015]: Reading from UART timed out at byte 0! [01:21:53][E][uart:015]: Reading from UART timed out at byte 0! [01:21:54][E][uart:015]: Reading from UART timed out at byte 0! [01:21:54][E][uart:015]: Reading from UART timed out at byte 0! [01:21:54][E][uart:015]: Reading from UART timed out at byte 0! [01:21:54][E][uart:015]: Reading from UART timed out at byte 0! [01:21:54][E][uart:015]: Reading from UART timed out at byte 0! [01:21:54][D][nextion_upload:239]: Upgrade response is 19 [01:21:54][D][nextion_upload:242]: Available 0 : 0x00 [01:21:54][D][nextion_upload:242]: Available 1 : 0x00 [01:21:54][D][nextion_upload:242]: Available 2 : 0x00 [01:21:54][D][nextion_upload:242]: Available 3 : 0x00 [01:21:54][D][nextion_upload:242]: Available 4 : 0x00 [01:21:54][D][nextion_upload:242]: Available 5 : 0x00 [01:21:54][D][nextion_upload:242]: Available 6 : 0x00 [01:21:54][D][nextion_upload:242]: Available 7 : 0x00 [01:21:54][D][nextion_upload:242]: Available 8 : 0x00 [01:21:54][D][nextion_upload:242]: Available 9 : 0x00 [01:21:54][D][nextion_upload:242]: Available 10 : 0x00 [01:21:54][D][nextion_upload:242]: Available 11 : 0x00 [01:21:54][D][nextion_upload:242]: Available 12 : 0x00 [01:21:54][D][nextion_upload:242]: Available 13 : 0x00 [01:21:54][D][nextion_upload:242]: Available 14 : 0x00 [01:21:54][D][nextion_upload:242]: Available 15 : 0x00 [01:21:54][D][nextion_upload:242]: Available 16 : 0x00 [01:21:54][D][nextion_upload:242]: Available 17 : 0x00 [01:21:54][D][nextion_upload:242]: Available 18 : 0x00 [01:21:54][D][nextion_upload:248]: preparation for tft update failed 0 "" [01:21:54][D][nextion_upload:324]: Restarting Nextion

jflecool2 commented 1 year ago

I think I found the issue. I cannot update TFT of nspanel3 and nspanel5 with the same problem. At this point I'm pretty sure the cause of my issues is sleep. In order to ensure a power-cycle (like in a power outage) wouldnt make my nspanel go full brightness on page 0, I made the first page configure sleep and go to sleep thsp=0 thup=1 ussp=0 usup=0 wup=3 sleep=1 Additionally, maybe im stupid, but after going to sleep that way it got woken up by default. Twice. So I made a counter that would put my nspanel to sleep every time it would wake up up to 3 time. That way, esphome would not be able to wake it up. TLDR: I made my TFT go to sleep very forcibly. Now I think something is preventing my nspanel from communicating. maybe is_ready, maybe is is_connected, maybe bkcmd=0 or bkcmd=3 sent by esphome doesnt get received because the nspanel is on sleep, and that is necessary for everything that follows, Im not sure. However, TFT update AND my nspanel->esphome text component doesnt trigger anymore and I would have to wipe my TFT in order to fix it but Im not sure how to do so.

rbr101 commented 1 year ago

Hi,

I had exact the same problem and adding on_boot statement below solved it for me:

esphome:
  on_boot:
    priority: 601
    then:
      - lambda: id(disp1).send_command_printf("DRAKJHSUYDGBNCJHGJKSHBDN");

brotherseb commented 1 year ago

Hey ! I had the same problem and just fixed it with a mix of all solutions i found :)

baud_rate set to 9600
commented the external_components section and added this in the esphome section (from https://github.com/esphome/esphome/pull/2956):
```
on_boot:
priority: 601
then:
  - lambda: id(disp1).send_command_printf("DRAKJHSUYDGBNCJHGJKSHBDN");
```

Set the left button to upload the TFT file

binary_sensor:
# Left button below the display
- platform: gpio
name: $device_name Left Button
pin:
  number: 14
  inverted: true
on_click:
  - lambda: 'id(disp1)->upload_tft();'

Comment all the actions in the display section (on_setup) so that nothing happens to the screen on boot
And finally configured home assistant to use http instead of httpS for the file: nextion_update_url: "http://192.168.1.66:8123/local/hmi.tft" (https worked but was VERY long)

Just unplugged and plugged the NSPanel, waited for 2 seconds and pressed the button to start the upload. Still some errors in the log but there was a progress bar on the screen. 50 minutes later it was done ;)

jn3va commented 1 year ago

I was having the same problem with seeing these after a successful flash of ESPHome

[14:55:09][E][uart:015]: Reading from UART timed out at byte 0! [14:55:09][W][nextion:078]: Nextion is not connected!

My display was not on and I could not get the TFT upload to work

I saw a post that mentioned that GPIO4 needs to be low to enable the display Once I added the switch configuration below the display was enabled

switch:
  - platform: gpio
    id: panel_power
    entity_category: config
    pin:
      number: 4
      inverted: true
    restore_mode: ALWAYS_ON

To upload the TFT these uart settings worked for me

uart:
  tx_pin: 16
  rx_pin: 17
  baud_rate: 115200
  id: tf_uart

for the display config I used https and not http (http was being blocked since ssl is enabled)

display:
  - platform: nextion
    id: disp1
    uart_id: tf_uart
    tft_url: https://192.168.1.111:8123/local/nsp.tft

I did not have success using on_boot / priority 601 / printf("DRAKJHSUYDGBNCJHGJKSHBDN"); ...

I reverted back and used

external_components:
  - source: github://pr#2956
    components: [nextion]
    refresh: 1h

After these change I was able to use the call service on the developer tools to trigger the TFT upload!

I had been trying variations of baud rates, tx/rx pins, and the on-boot and external component settings. The part that seemed to make the most difference was adding the switch for GPIO4. Once that was enabled the nextion was active and the rest started working.

jflecool2 commented 1 year ago

Fixed my issue. For everyone that made a TFT that sleep on start, here's how to unstuck yourself. By enabling verbose log:

logger:
  level: VERY_VERBOSE

Normal user should see lines like this in the logs:

[16:33:33][VV][nextion:304]: print_queue_members_ size 0
[16:31:32][VV][nextion:202]: print_queue_members_ (top 10) size 1
[16:31:32][VV][nextion:203]: *******************************************
[16:31:32][VV][nextion:213]: Nextion queue type: 4:TEXT_SENSOR , name: argstr1
[16:31:32][VV][nextion:216]: *******************************************
[16:33:33][VV][nextion:304]: print_queue_members_ size 0

If you see other stuff like [16:29:49][VV][scheduler:196]: Running interval 'update' with interval=5000 last_execution=125041 (now=130042) but dont see print_queuemembers, you are probably in the bad state, just like me.

Here's the steps to unstuck yourself:

Open Nextion Editor and remove the sleep=1 you put, generate TFT and upload it to your server

add this and upload the resulting esphome firmware to your nspanel

- service: customcmd
  variables:
    cmd_str: string
  then:
  - logger.log:
      format: "Force cmd: %s"
      args: [ cmd_str.c_str() ]
  - lambda: id(disp1).write_str(cmd_str.c_str());
  - lambda: id(disp1).write_array({0xFF, 0xFF, 0xFF});

wake nspanel from sleep using this new API (developer tools -> services -> ESPHome: nspanel2_customcmd) sleep=0
repeat until screen wake up
enter in the same API the following bkcmd=3
Verify that print_queuemembers now appears in the log
use your upload_tft api as you normally would (ESPHome: nspanel2_upload_tft)

codylo commented 1 year ago

binary_sensor:

Left button below the display

platform: gpio name: $device_name Left Button pin: number: 14 inverted: true on_click:

lambda: 'id(disp1)->upload_tft();'

I can confirm that after I change the trigger of upload tft to use the physical button it works. You can then change back to trigger the relay after the tft file have uploaded to the display.

binary_sensor:
  # Left button below the display
  - platform: gpio
    name: $device_name Left Button
    pin:
      number: 14
      inverted: true
    on_click:
      - lambda: 'id(disp1)->upload_tft();'

Goldwing1973 commented 1 year ago

binary_sensor:

Left button below the display

platform: gpio name: $device_name Left Button pin: number: 14 inverted: true on_click:

lambda: 'id(disp1)->upload_tft();'

I can confirm that after I change the trigger of upload tft to use the physical button it works. You can then change back to trigger the relay after the tft file have uploaded to the display.
binary_sensor:
  # Left button below the display
  - platform: gpio
    name: $device_name Left Button
    pin:
      number: 14
      inverted: true
    on_click:
      - lambda: 'id(disp1)->upload_tft();'

I had to fully disable the logger to get it working, changing the left button alone didn't solve it for me.

# Logger. Disable the temperature sensor etc. to focus on the HMI development
#logger:
#  baud_rate: 0
  #115200
#  level: DEBUG
#  logs:
#    sensor: WARN
#    resistance: WARN
#    text_sensor: WARN
#    ntc: WARN

alexandertonino commented 1 year ago

I tried pretty much the same stuff. But one change made it work:

logger:
  baud_rate: 0

also. 9600 baud for the UART did not work for me. I had to go back to 115200baud

HACSSYSTEM commented 1 year ago

Hello Guys!

it should look something like this?

`substitutions:

CHANGE ME START

device_name: "nsp3" wifi_ssid: "xxxxxxxxx" wifi_password: "yyyyyy"

nspanel_blank.tft" # URL to local tft File

nextion_update_url: "https://raw.githubusercontent.com/Blackymas/NSPanel_HA_Blueprint/main/custom_configuration/nspanel_blank.tft" # URL to Github

nextion_update_url: "http://raw.githubusercontent.com/joBr99/nspanel-lovelace-ui/main/HMI/nspanel.tft" # URL to Github

CHANGE ME END

UART FOR NEXTION DISPLAY

uart: tx_pin: 16 rx_pin: 17 baud_rate: 115200 id: tf_uart

DO NOT CHANGE ANYTHING!

binary_sensor:

Left button below the display

platform: gpio name: $device_name Left Button pin: number: 14 inverted: true on_click:
- lambda: 'id(disp1)->upload_tft();'

display:

platform: nextion id: disp1 uart_id: tf_uart tft_url: "http://raw.githubusercontent.com/joBr99/nspanel-lovelace-ui/main/HMI/nspanel.tft"

packages:

download esphome code from Github

remote_package: url: https://github.com/Blackymas/NSPanel_HA_Blueprint ref: main files: [nspanel_esphome.yaml] refresh: 300s

DO NOT CHANGE ANYTHING! #####`

if someone uploads code. thank you very much... :P

jflecool2 commented 1 year ago

@HACSSYSTEM

I think you're deeply lost in the woods of HA.

Please review the final format of your comment, and re-do it if it doesnt look right. It seems you're not using "code" and thus it all looks crazy.
Your 3 nextion_update_url has an url you should validate in your browser, one blank thats correct and one that only works with Tasmota on ESP, not ESPHome (uncommented)
Then you add Blackymas's project in the middle of your things... ?!? remote_package infers you need substitutions only, everything else in configured by the remote package...
Then those substitutions are not used by your "display" section
etc

At this point of being lost, my best advice is to pick nspanel-lovelace-ui or Blackymas or ESPHome custom. Then head on Youtube and picked a tutorial and follow it to a teeth. No fast-forward or skipping. Replicate 1:1 what the youtuber is showing.

HACSSYSTEM commented 1 year ago

Thank you for reading.

Actually, the problem is that:

I try to get back from this:

https://docs.nspanel.pky.eu/precare_nspanel/

It is also written down how to but fail! Then I decided to get to this version: https://github.com/blackymas/nspanel_ha_blueprint/wiki/(en)-common-issues-tft-upload-when-nspanel-lvelace-ui-been-in-installed

But here too, they describe how to. Video is also but not all the way you need

Pulpi86 commented 1 year ago

I had the same error, but the HA system was only available with HTTPS access. So I could not upload the .tft file from internal storage. So I downloaded the following program, made an internal HTTP connection, uploaded the .tft file and uploaded Tasmota.bin. There I uploaded it from the console and it uploaded fine, then I uploaded the ESPhome file back and it works fine since then. https://www.rejetto.com/hfs/?f=dl

I hope I was able to help those who are having the same problem.

OptimusGREEN commented 1 year ago

Same issue with a standard nextion screen, can't upload tft file anymore. used to work fine.

tjmonk commented 1 year ago

I had the same problems. I have noted 2 things.

1) When I was trying to program the TFT, I was supplying only 3.3V via the programming header (used during ESP32 programming). I tried the regular things everyone else here has tried but with no success. I suspect that either a) the 5V rail is required for flash erase, or the current supplied via the 3.3V source I was using was insufficient. So, I followed Christopher Masto's approach, and put the NSPanel back together and powered it from 120V. And the TFT upload worked!!

2) The nextion factory baud rate is 115200, but after programming the nspanel with Christopher Masto's TFT firmware, the baud rate changes to 9600 baud, so you will need to update your yaml to reflect the new baud rate after the initial program load.

Hope this helps some others out there. Power from 120V before trying to flash the TFT file!!!!!

kchiem commented 1 year ago

2. The nextion factory baud rate is 115200, but after programming the nspanel with Christopher Masto's TFT firmware, the baud rate changes to 9600 baud, so you will need to update your yaml to reflect the new baud rate after the initial program load.

My experience seems to be the opposite. Came here after trying to flash Blackymas's NSPanel_HA_Blueprint and the TFT flash (at 115200) left me with "System Data ERROR!" on the screen. The ESPHome "LOGS" output for the device was filled with:

Reading from UART timed out at byte 0!

After adding:

uart:
  tx_pin: 16
  rx_pin: 17
  baud_rate: 9600
  id: tf_uart

.. to my device yaml file and reinstalling, the errors went away. Then I had it flash a small blank tft and that succeeded, but after the reboot, the Reading from UART timed out errors came back. Removing the uart block above from my yaml file and reinstalling again got rid of the UART errors, and I was able to retry flashing the full tft file again, which happened at 115200.

So, it seems that when the Nextion is working properly, it's communicating at 115200 baud. But when it errors out, it reverts to 9600 baud.

NvL-WEAP commented 1 year ago

I tried everything mentioned in the discussions to get the .tft uploaded to the display.

I got errors like;

[21:24:21][E][uart:015]: Reading from UART timed out at byte 0!
[21:24:21][W][nextion:078]: Nextion is not connected!

Putting the .tft in homeasstant didn't help, due the upload to the ESP board went quickly. The serial transfer of the .tft to the display would take aprox 20 hours with the speed it was running (transfering a 8Mb file over serial).

I have the same effect on the EU and US version i'm currently testing.

After providing the blank .tft, everything went fine. After the successfully uploaded blank i altered the config back to the needed .tft. Then the upload went fine (within 10min).

So no need to alter the baudrate etc, just use the blank, and change is back to the needed .tft.

My config (stock);

substitutions:
  ###### DIT GEDEELTE AANPASSEN ######
  device_name: nspanelus1
  wifi_ssid: !secret wifi_ssid
  wifi_password: !secret wifi_password
  ##### EIND AANPASBARE SECTIE #####
  # nextion_update_url: "http://192.168.2.11:8123/local/nspanel_blank.tft"
  nextion_update_url: "http://192.168.2.11:8123/local/nspanel_us.tft"
packages:
  remote_package:
    url: https://github.com/Blackymas/NSPanel_HA_Blueprint
    ref: main
    files: [nspanel_esphome.yaml]
    refresh: 300s

Hope this helps other people who are experiencing the same issue as i did.

giannoug commented 1 year ago

@NvL-WEAP Can confirm that just flashing nspanel_blank.tft fixed my upload issues.

jtberge commented 1 year ago

Ditto, did it the hard way by installing the nextion editor and creating the small version but yes, small first at 9600 baud worked for me, after that the upload of the big boy goes at speed 115200. How ever i also removed a lot from nspanel_esphome.yaml first to make sure no other processes could intrude the process of updating nextion... Think this is still not for the faint harted ;)

giannoug commented 1 year ago

No need to hack anything. I've upgraded (and downgraded) countless times. When it hangs I just flash nspanel_blank.tft and it starts magically working again.

anarro commented 1 year ago

Hello, I have the same problems and I found these settings in Nextion Editor:

With this settings I fixed my problems!

jtberge commented 1 year ago

No need to hack anything. I've upgraded (and downgraded) countless times. When it hangs I just flash nspanel_blank.tft and it starts magically working again.

You may be right, but also hosting the tft files with nginx seemed to help, and isn’t the tftp specific to your display ? EU and US versions differ right ?(square/rectangular) or is that just optics ?

giannoug commented 1 year ago

EU and US versions differ right ?(square/rectangular) or is that just optics ?

I believe it's just the orientation. I found the blank file in this repo, here, so I believe the same file works for both variants

esphome / issues

NSPanel cannot upload TFT file to Nextion display #3519

The problem

Which version of ESPHome has the issue?

What type of installation are you using?

Which version of Home Assistant has the issue?

What platform are you using?

Board

Component causing the issue

Example YAML snippet

Anything in the logs that might be useful for us?

Additional information

The problem

Which version of ESPHome has the issue?

What type of installation are you using?

Which version of Home Assistant has the issue?

What platform are you using?

Board

Component causing the issue

Example YAML snippet

Anything in the logs that might be useful for us?

Additional information

The problem

Which version of ESPHome has the issue?

What type of installation are you using?

Which version of Home Assistant has the issue?

What platform are you using?

Board

Component causing the issue

Example YAML snippet

Anything in the logs that might be useful for us?

Additional information

Left button below the display

Left button below the display

CHANGE ME START

nextion_update_url: "http://192.168.1.150:8123/local/nspanel_blank.tft" # URL to local tft File

nextion_update_url: "https://raw.githubusercontent.com/Blackymas/NSPanel_HA_Blueprint/main/custom_configuration/nspanel_blank.tft" # URL to Github

CHANGE ME END

UART FOR NEXTION DISPLAY

DO NOT CHANGE ANYTHING!

Left button below the display

download esphome code from Github

DO NOT CHANGE ANYTHING! #####`