Bluetooth Proxy

[maltejarr]

The NSpanel has Bluetooth functionality which should be implemented, preferably as a Bluetooth proxy in ESPhome.

[edwardtfn]

The challenge here is to fit all we want in the limited memory. With the current version, if we enable Bluetooth proxy the total required memory will be around 105% of the available memory, so we are not that far, but we also don't wanna be too close to 100% so we can still work on new functionalities.

On v4.0 we introduced the concept of Add-ons, and maybe we could think about existing functionalities that could be moved to Add-ons and with that free up memory, so one would be able to choose how they wanna use their panel and what to compromise.

New ideas are very welcome. 😉

[maltejarr]

The memory is a good point. I have not tested the NSpanel as it should arrive today. But as far as I understand the approach, there are many features I will not use or need. So your idea to move certain functions into add-ons would make it more customable for everyone.

Edward Firmo @.***> schrieb am Mi., 27. Sept. 2023, 10:56:

The challenge here is to fit all we want in the limited memory. With the current version, if we enable Bluetooth proxy the total required memory will be around 105% of the available memory, so we are not that far, but we also don't wanna be too close to 100% so we can still work on new functionalities.

On v4.0 we introduced the concept of Add-ons, and maybe we could think about existing functionalities that could be moved to Add-ons and with that free up memory, so one would be able to choose how they wanna use their panel and what to compromise.

New ideas are very welcome. 😉

— Reply to this email directly, view it on GitHub https://github.com/Blackymas/NSPanel_HA_Blueprint/issues/1111#issuecomment-1736987900, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQNB7NTUYJW6WCNYZP55EN3X4PS2RANCNFSM6AAAAAA5I576PE . You are receiving this because you authored the thread.Message ID: @.***>

[Doughboy68]

There is an issue with with Bluetooth Proxy and the default ardruino framework. This apply to NSPanel?

https://esphome.io/components/bluetooth_proxy.html

I am using an $8 ESP32 chip and set up a BT proxy that way.

[edwardtfn]

As far as I know there's no support for Nextion display on esp-idf framework, so we are using the default framework, which is Arduino.

[edwardtfn]

Forget my previous message. I've just built using esp-idf and Nextion with a clean code.

[Doughboy68]

Is there any benefit to esp-idf that you can see?

[edwardtfn]

I'm not the best one to answer that, but from the few things I could read about, it was always saying about advantages of going to esp-idf and one of those was the fact that Espressif maintains it more frequently. The problem is doing the conversion... I've tried Nextion and it failed saying it was not supported by esp-idf. Then I've tried a clean code with Nextion. It failed the first time, but then after playing a bit it was compiling, however when I go to the source code I can see Arduino is required. It looks easy to adapt, but I'm really too busy to go this way right now. I promise to come back to this soon.

[grigi]

Could using https://github.com/myhomeiot/esphome-components#ble-gateway instead work better for this?

Also, re the memory, I've never had the need to use the captive portal or the web server, if those could be turned off to get more memory available, I'd do that if it means I could get BLE tracking functionality.

[edwardtfn]

So, just as an update, I haven't tested this component from @myhomeiot yet, but I've cleaned up the ESPHome code a bit, removing all the non-critical components (diagnostic sensors, some services, etc.) and still not having memory to add bluetooth_proxy with the Arduino framework. I took a look in the code on Nextion component and looks like the only part requiring Arduino is on the upload_tft (in my opinion the most fragile part of this component), more specifically in the http client used to fetch the TFT file from a server. As I've see this failing a lot, I don't mind spending some time later to give a try on the http client from esp-idf. If I succeed on that I will propose a change to the Nextion component on ESPHome in a way it could support both frameworks.

I will keep you updated.

By the way, if you want to try this solution from @myhomeiot by yourself, please use the code currently in dev, as that one is lighter than main and let us know your results.

[grigi]

FYI, testing on a personal project, using esp-idf resulted in notable savings in both RAM and Flash usage:

arduino:

RAM:   [=         ]  14.3% (used 46860 bytes from 327680 bytes)
Flash: [=====     ]  54.2% (used 995313 bytes from 1835008 bytes)

esp-idf:

RAM:   [=         ]   9.7% (used 31936 bytes from 327680 bytes)
Flash: [=====     ]  48.5% (used 889881 bytes from 1835008 bytes)

[Doughboy68]

Could using https://github.com/myhomeiot/esphome-components#ble-gateway instead work better for this?

Also, re the memory, I've never had the need to use the captive portal or the web server, if those could be turned off to get more memory available, I'd do that if it means I could get BLE tracking functionality.

I couldn't get captive portal working, not that I really need to use it, but was testing trying to connect to a NSPanel using WiFi... I got the login at 192.168.4.1, but kept disconnecting... maybe something is broken in it or the computer I was trying? I agree though it could be removed to save space.

[edwardtfn]

I've removed captive_portal on v4.1dev, although the change in memory consumption isn't that big.

I still working on develop a version of upload_tft compatible with esp-idf. I can compile without that routine, and those are the results (I've also compiled in this same situation with arduino, for comparison):

arduino:

RAM:   [=         ]  13.3% (used 43632 bytes from 327680 bytes)
Flash: [======    ]  59.7% (used 1095385 bytes from 1835008 bytes)

It's impressive to see that upload_tft alone is 10% of flash.

esp-idf:

RAM:   [=         ]   9.3% (used 30380 bytes from 327680 bytes)
Flash: [=====     ]  53.0% (used 973005 bytes from 1835008 bytes)

Not that big gain when compared to arduino.

I've also tried adding bluetooth_proxy and as upload_tft wasn't there, I could compile in both frameworks, although I felt the system a bit unstable on my super-short tests.

arduino (with bluetooth_proxy):

RAM:   [==        ]  17.0% (used 55868 bytes from 327680 bytes)
Flash: [==========]  97.8% (used 1793865 bytes from 1835008 bytes)

After this test my panel died and I was forced to unassembled and flash it via serial.

esp-idf (with bluetooth_proxy):

RAM:   [==        ]  16.6% (used 54548 bytes from 327680 bytes)
Flash: [========  ]  78.8% (used 1446625 bytes from 1835008 bytes)

[grigi]

Wow, bluetooth_proxy is HUGE. It's alone 28-38% of the flash. :thinking: Not sure I need the feature THAT badly...

Just image all the other more useful features that can be added in that space...

[edwardtfn]

Today I've finally uploaded a TFT file using esp-idf framework, however, the upload engine takes a lot of memory on this framework, just like it was with arduino. The part responsible for taking all this memory is the http client library, which I'm not gonna touch as this a core part of those frameworks.

Those are the results in terms of memory consumption:

esp-idf (core only):

RAM:   [=         ]   9.7% (used 31872 bytes from 327680 bytes)
Flash: [======    ]  59.4% (used 1089137 bytes from 1835008 bytes)

esp-idf (core + bluetooth_proxy):

RAM:   [==        ]  17.1% (used 56068 bytes from 327680 bytes)
Flash: [========= ]  85.1% (used 1560785 bytes from 1835008 bytes)

So, looks like bluetooth_proxy can be viable in this scenario. I've set the Upload TFT to work with smaller chunks when the memory is limited, so I don't think this will be a problem (other than a couple of seconds more when transferring TFT, which probably won't be noticeable).

I still have to find time to play more with the system and make sure the available memory is enough for the operation. Any help here is very welcome. 😉

[edwardtfn]

Unfortunately it happened a couple of times that I lost communication with ESPHome when running this with bluetooth_proxy. Just leaving the panel there for a while and it stopped the WiFi, I couldn't restart with the settings page also, power cycle didn't helped. Only flashing again using cable. 😞 I will try to clean the code a bit more to see if it gets more stable.

[grigi]

Transfer chunk size should have to do with RAM, and not Flash (which is code), so I don't know if it's worth it to reduce the chunk size. Also, you could allocate that RAM only if the upload is busy happening, so that shouldn't affect the general execution much.

What is the current chunk size?

Re the dropping off WIFI, the ESP32's share the same radio for both Wifi and Bluetooth, so for BT to work Wifi has to be "paused". I found that the sample in the docs is a bit weird, as in my experience adjusting the scan_parameters tend to make Wifi signal less stable.

I found on my one system where I have been experiementing with bluetooth_proxy, that setting fast_connect: true on the wifi config was practically a requirement to get wifi stable at all.

Also, to make uploads more reliable you should definitely stop active scanning on BT: https://esphome.io/components/esp32_ble_tracker#esp32-ble-tracker-stop-scan-action

But, maybe the issue is something else, as re-flashing using cable implies that the flash somehow got corrupted, and nothing should write to flash other than an ota.

[grigi]

If you want me to do some testing for you, I'm willing. I have an NSPanel unit that I can use for experimentation.

[edwardtfn]

What is the current chunk size?

Since the beginning and up to version 4.0.2, chunk size was 65535 bytes. For v4.1 I'm changing this to a maximum of 32768, however if the available memory is below certain values (not on top of my memory now) it will reduce, but never smaller than 4096 bytes. I've tested a lot and the results are quite good. I believe this is where v4.0.x is failing more, as the firmware itself takes more memory now.

Also, you could allocate that RAM only if the upload is busy happening, so that shouldn't affect the general execution much.

Well, I'm kind of doing this now, but still using quite a lot of code from the original Nextion component available in ESPHome. My intention is to create a PR there with my findings so far and then I start looking for areas for improvement.

Transfer chunk size should have to do with RAM, and not Flash (which is code), so I don't know if it's worth it to reduce the chunk size.

Well, the limitation when transferring in with "heap" size, and the chunk is taking from there, so it is what I'm using to define it's size. Free heap is in pretty OK levels (~160kb) until we allocate memory for the TFT transfers. On v4.0.x it was going bellow 64kb at that moment and I believe this is where the system started failing the communication with either the http server and/or uart. Flash is taking by the http client library, which both in Arduino and IDF takes something around 20~30% of available flash.

One option would be leave the upload TFT as an add-on, so we definitely will have all the flash memory we need, but could be a bit more complex for non experience users to deal with Add-ons.

I found on my one system where I have been experiementing with bluetooth_proxy, that setting fast_connect: true on the wifi config was practically a requirement to get wifi stable at all.

Good to hear. I will play with that.

If you want me to do some testing for you, I'm willing. I have an NSPanel unit that I can use for experimentation.

That would be great! In fact the esp-idf code is already in dev. It's a mess, but it is functional and I'm planning to clean up during this weekend, but if you wanna try just change to ref: dev and add the following to your ESPHome settings:

esp32:
  framework:
    type: esp-

[grigi]

wow, that's far less available memory than I expected it would have...

I just noticed you reverted back from esp-idf to arduino? Which version should I test for you?

[grigi]

Update, built dev (commit 4daf567f44a7450dd9f9b4b3f638fc6cd3eacc2f) using the Arduino framework. Did an update of blueprint and the display firmware. The display firmware updated a little faster, I think. Connecting to HA and getting the blueprint after a reboot was really really slow the first 2 bootups, but after that seemed normal again.

Looking at the commit, it should just work if I set the framework to esp-idf

[grigi]

esp-idf build succeeded and is quite tiny:

RAM:   [=         ]   9.8% (used 32032 bytes from 327680 bytes)
Flash: [======    ]  59.6% (used 1093385 bytes from 1835008 bytes)

Updating the tft using esp-idf failed though. This is the logs as it was attempting to update:

[14:51:25][D][script.upload_tft:2124]: Starting...
[14:51:25][D][script.upload_tft:2755]: Try #1
[14:51:25][D][script.upload_tft.upload_tft_esp_idf:2589]: Nextion TFT upload requested
[14:51:25][D][script.upload_tft.upload_tft_esp_idf:2590]: url: http://192.168.0.25:8123/local/nspanel_eu.tft
[14:51:25][D][script.upload_tft.upload_tft_esp_idf:2591]: baud_rate: 115200
[14:51:25][D][script.upload_tft.upload_tft_esp_idf:2603]: Setting Nextion protocol reparse mode to passive
[14:51:25][D][script.upload_tft.upload_tft_esp_idf:2631]: HTTP Status Code: 206
[14:51:25][W][script.upload_tft.upload_tft_esp_idf:2645]: Failed to fetch Content-Range header. Error: 0
[14:51:25][D][script.upload_tft.upload_tft_esp_idf:2650]: Fetched Content-Length header: 0
[14:51:25][D][script.upload_tft.upload_tft_esp_idf:2657]: Parsed content length: 0
[14:51:25][E][script.upload_tft.upload_tft_esp_idf:2660]: File size check failed. Size: 0
[14:51:25][D][script.upload_tft.upload_end_:2208]: Completed: 0
[14:51:25][D][script.upload_tft.upload_end_:2209]: Restarting Nextion
[14:51:25][D][script.upload_tft.send_nextion_command:2140]: Sending: rest
[14:51:27][D][script.upload_tft.upload_end_:2218]: Nextion TFT upload will try again
[14:51:27][D][script.upload_tft:2757]: Turn off Nextion
[14:51:27][D][switch:016]: 'nsplanel1 Screen Power' Turning OFF.
[14:51:27][D][switch:055]: 'nsplanel1 Screen Power': Sending state OFF
[14:51:28][D][script.upload_tft:2764]: Turn on Nextion
[14:51:28][D][switch:012]: 'nsplanel1 Screen Power' Turning ON.
[14:51:28][D][switch:055]: 'nsplanel1 Screen Power': Sending state ON

That error is interesting, as when I do a GET on that url I clearly get the Content-Length header. Accept-Ranges: bytes is also set, and when doing a partial request the Content-Range: bytes 0-1023/5409224 looks sane.

So I'm suspecting an error in the HTTP library used by esp-idf.

I'm leaving the esp-idf firmware running on there for now to try and test stability in the mean time.

[grigi]

A question on that commit: In some cases you used ifdefs to handle delays differently between frameworks:

            #ifdef ARDUINO
            delay(1500);
            #elif defined(ESP_PLATFORM)
            vTaskDelay(pdMS_TO_TICKS(1500));
            #endif

and in other places you changed from delay(x) to vTaskDelay(pdMS_TO_TICKS(x)); ?

This seems inconsistent?

[grigi]

RAM:   [==        ]  17.2% (used 56236 bytes from 327680 bytes)
Flash: [========= ]  85.6% (used 1570297 bytes from 1835008 bytes)

That's with me manually adding the bluetooth proxy to the same build from dev. Testing with this config:

esp32:
  framework:
    type: esp-idf
    version: recommended
    sdkconfig_options:
      COMPILER_OPTIMIZATION_SIZE: y
    advanced:
      ignore_efuse_mac_crc: false

wifi:
  fast_connect: true

esp32_ble_tracker:

bluetooth_proxy:
  active: true

[grigi]

I added these back on my build:

sensor:
  ##### Uptime Sensors #####
  - name: ${device_name} Uptime seconds
    id: uptime_sec
    platform: uptime
    internal: true

  ##### WIFI Signal stregth
  - name: ${device_name} RSSI
    platform: wifi_signal
    update_interval: 60s

Which I consider pretty important for diagnostics (especially to determine if the wifi signal does weird stuff with the bluetooth proxy).

Build size seems hardly larger, so I would request you please put those sensords back in:

RAM:   [==        ]  17.2% (used 56244 bytes from 327680 bytes)
Flash: [========= ]  85.7% (used 1572105 bytes from 1835008 bytes)

[edwardtfn]

A question on that commit: In some cases you used ifdefs to handle delays differently between frameworks:

#ifdef ARDUINO
delay(1500);
#elif defined(ESP_PLATFORM)
vTaskDelay(pdMS_TO_TICKS(1500));
#endif

and in other places you changed from delay(x) to vTaskDelay(pdMS_TO_TICKS(x)); ?

This seems inconsistent?

First, this is something I still testing. The upload tft is quite unstable on esp-idf and there is a need of a wait after sending the http request (which is not needed on arduino framework) and looks like some of those delays are making the system to crash, than the reason I'm playing with those. Also, you will find methods that are shared between arduino and idf, and in those you will find the first case where only the delay is based on the compiler, and you will find cases where the entire method is under the compiler conditionals, so no need to add this test again.

[edwardtfn]

By the way, on my tests so far the system becomes quite unstable when bluetooth proxy is enable. I was required to flash by wire a few times. :(

[grigi]

So far mine is behaving decently, but I feel if we do Bluetooth Proxy, it should be opt-in only, and with huge disclaimers.

I'm more interested in testing and getting esp-idf working reliably, so we can have smaller builds so we can add more features :grin:

Hence, I'm just using the BT-Proxy as a load-testing feature right now.

[edwardtfn]

We don't have plans to add Bluetooth proxy as part of a core package or add-ons, but it could be in the customizations and, indeed, with huge disclaimers. However, I still wanna make it more flexible for advanced users to be able to play more while keeping it simple for normal users. Right now I've split the upload tft code from the core code. It still be included for all users, but it's easier to remove now and make a lot of memory available, so one would be able to disable "Upload TFT" in normal use and then use that additional memory for something else (BT?). When they want to transfer TFT file they can disable that something else and enable TFT upload, then revert back after the file is transferred. I'm not sure however if the problem with BT is related to lack of memory or the BT proxy itself. It needs testing.

[grigi]

An update on the esp-idf build of a few days ago. It's been running for 4 days straight with the same reliability/performance as before. Other than for the upload tft, which for me isn't working at all though.

[edwardtfn]

An update on the esp-idf build of a few days ago. It's been running for 4 days straight with the same reliability/performance as before.

You have BT included, right? How is the BT performance?

Other than for the upload tft, which for me isn't working at all though.

Yeah, I still pending work with this. 😩

[grigi]

Yes, the BT proxy has been running. This is the full config:

substitutions:

###### CHANGE ME START ######

  device_name: "nsplanel1" 
  wifi_ssid: !secret wifi_ssid
  wifi_password: !secret wifi_password

  nextion_update_url: "http://192.168.0.25:8123/local/nspanel_eu.tft" # URL to local tft File
#  nextion_update_url: "https://raw.githubusercontent.com/Blackymas/NSPanel_HA_Blueprint/main/nspanel_eu.tft" # URL to Github

##### CHANGE ME END #####

##### DO NOT CHANGE ANYTHING! #####

packages:
  ##### download esphome code from Github
  remote_package:
    url: https://github.com/Blackymas/NSPanel_HA_Blueprint
    ref: dev
    files: [nspanel_esphome.yaml]
    refresh: 300s

esp32:
  framework:
    type: esp-idf
    version: recommended
    sdkconfig_options:
      COMPILER_OPTIMIZATION_SIZE: y
    advanced:
      ignore_efuse_mac_crc: false

wifi:
  fast_connect: true

esp32_ble_tracker:

bluetooth_proxy:
  active: true

sensor:
  ##### Uptime Sensors #####
  - name: ${device_name} Uptime seconds
    id: uptime_sec
    platform: uptime
    internal: true

  ##### WIFI Signal stregth
  - name: ${device_name} RSSI
    platform: wifi_signal
    update_interval: 60s

##### DO NOT CHANGE ANYTHING! #####

Re BT performance, it can see devices that support BLE only, and I can use it to track if e.g. my headphones are on/off. I don't have a proper BLE sensor/device supported by HA to test, unfortunately.

It can't see my wife's BT headphones as those don't seem to support BLE :shrug:

[grigi]

In any case, once the upload is working on esp-idf, you could consider changing to esp-idf, or update the docs saying esp-idf is available if you want to enable more features and run into build size issues?

[edwardtfn]

If everything works fine with esp-idf I would propose to the team to use that as the default framework for this project.

[edwardtfn]

But in that case we probably should keep support for Arduino as a customization.

[edwardtfn]

So, I believe the ESP-IDF version of Upload TFT is quite stable now, so I've changed the default framework to this and from now I will be running all my test with ESP-IDF. It would be nice if you can give some feedback.

By the way, if you wanna try arduino you will have to add this to your yaml:

esp32:
  framework:
    type: arduino

[Doughboy68]

I just remotely installed the dev on my panel at home in my office... seems like it flashed tft ok, will go home in a couple hours and check it out.

[Doughboy68]

Seems to work without any issue. Tft flashed fine. Anything specific to test ?

[grigi]

Hi. Sorry, I only managed to get time to look at it now.

Upload of TFT worked for me. It's still slow, but at least there is consistent, stable, progress :smile:

[grigi]

I now have a blueprint version mismatch error: I'm getting this error:

Panel: nspanel1
TFT: 4.1dev3
ESPHome: 4.1dev3
Blueprint (reported by ESPHome):
Blueprint (expected): 4.1dev3

The version of blueprint installed is "4.1dev3", and I even restarted HA to see if that makes a difference.

[grigi]

Did a clean & rebuild and added nspanel_esphome_advanced.yaml to files and now the problem went away.

The build is still only 1.1MB big for everything, which is WAAAAY smaller than before.

Nice :+1:

[edwardtfn]

nspanel_esphome_advanced.yaml isn't mandatory, so it should work without that. I will try a bit tomorrow.

Thanks for your feedback. 🙂

[Doughboy68]

I had the mismatch but eventually went away. I was also updating ESPHome to latest versions so not sure if that was related.
I did not add the advanced yaml.

[grigi]

It was weird that it was reporting the version as an empty string. But after restarting HA it went away once, but when I restarted the panel it got stuck again until I rebuilt the firmware. I found the whole thing rather weird.

Suspect it was to do with some bad cache as initially it was saying 2023.9.3 but after clearing caches and rebuilding it now correctly says 20203.10.6. (I updated everything to latest versions today as well, want to play with new features)

[edwardtfn]

It was weird that it was reporting the version as an empty string

That means the component didn't informed it's version to ESPHome in a reasonable time (I think it is 1 minute). I will investigate it more.

[grigi]

I had a power outage, and the panel now refuses to load the blueprint. I wonder if it's related to #1217 in some way (as updating esphome to 2023.10.6 from 2023.9.3 may have broken this)?

It appears to only load the blueprint when I do a build. If it restarts at later times, it will just get stuck retrying forever and showing me the version as an empty string.

The ESPhome logs contain this:

[23:06:45][D][script.check_versions:2103]: ESPHome version: 4.1dev3
[23:06:45][D][script.check_versions:2104]: TFT version: 4.1dev3
[23:06:45][D][script.check_versions:2106]: Blueprint version: 
[23:06:45][E][script.check_versions:2107]: Blueprint version mismatch!
[23:06:50][D][text_sensor:064]: 'nsplanel1 NSPanel event': Sending state '{"page": "boot", "event": "timeout", "value": 1, "version": "4.1dev3", "display_mode": "1"}'
[23:06:50][E][text_sensor.disp1_nspanel_event:1145]: Starting
[23:06:50][E][text_sensor.disp1_nspanel_event:1153]: page: boot
[23:06:50][E][text_sensor.disp1_nspanel_event:1154]: component: null
[23:06:50][E][text_sensor.disp1_nspanel_event:1155]: value: 1
[23:06:50][E][text_sensor.disp1_nspanel_event:1156]: entity: 
[23:06:50][D][nextion_textsensor:014]: Processed text_sensor "nspanelevent" state "{"page": "boot", "event": "timeout", "value": 1, "version": "4.1dev3", "display_mode": "1"}"

It only prints the blueprint version mismatch once.

I'm going to try building with Arduino in case there's some other library regression...

[edwardtfn]

Anything on Home Assistant logs (Settings > System > Logs)?

[Doughboy68]

I am experiencing the same issue... I just restarted my NSPanel and blueprint is just saying Retry with a number behind.

Some logs that may be of help from ESPHome... Says TFT mismatch but I have correct TFT version Does not seem to be getting blueprint version.

[17:32:45][D][sensor:094]: 'nspanel05 Uptime seconds': Sending state 53.93900 s with 0 decimals of accuracy [17:32:45][D][sensor:094]: 'nspanel05 RSSI': Sending state -63.00000 dBm with 0 decimals of accuracy [17:32:52][D][script.check_versions:2240]: ESPHome version: 4.0.2 [17:32:52][D][script.check_versions:2241]: TFT version: 4.1dev3 [17:32:52][E][script.check_versions:2242]: TFT version mismatch! [17:32:52][D][script.check_versions:2243]: Blueprint version: [17:32:52][E][script.check_versions:2244]: Blueprint version mismatch! [17:32:58][D][text_sensor:064]: 'nspanel05 NSPanel event': Sending state '{"page": "boot", "event": "timeout", "value": 1, "version": "4.1dev3", "display_mode": "2"}' [17:32:58][D][nextion_textsensor:014]: Processed text_sensor "nspanelevent" state "{"page": "boot", "event": "timeout", "value": 1, "version": "4.1dev3", "display_mode": "2"}" [17:33:24][D][sensor:094]: 'ntc_source': Sending state 1.66400 V with 2 decimals of accuracy [17:33:24][D][resistance:039]: 'resistance_sensor' - Resistance 11391.7Ω [17:33:24][D][sensor:094]: 'resistance_sensor': Sending state 11391.68750 Ω with 1 decimals of accuracy [17:33:24][D][ntc:026]: 'nspanel05 Temperature' - Temperature: 22.1°C [17:33:24][D][sensor:094]: 'nspanel05 Temperature': Sending state 22.09622 °C with 1 decimals of accuracy [17:33:45][D][sensor:094]: 'nspanel05 Uptime seconds': Sending state 113.93500 s with 0 decimals of accuracy [17:33:45][D][sensor:094]: 'nspanel05 RSSI': Sending state -62.00000 dBm with 0 decimals of accuracy [17:34:03][D][text_sensor:064]: 'nspanel05 NSPanel event': Sending state '{"page": "boot", "event": "timeout", "value": 2, "version": "4.1dev3", "display_mode": "2"}' [17:34:03][D][nextion_textsensor:014]: Processed text_sensor "nspanelevent" state "{"page": "boot", "event": "timeout", "value": 2, "version": "4.1dev3", "display_mode": "2"}"

[Doughboy68]

What is also strange is that after I do a rebuild/install.. It works and I check log and shows compiled today with 2023.10.6. After I reboot my NSPanel, and it is stuck on Retry.. .if I look at log in ESPHome it shows 2023.10.5 compiled on Oct 31 and Home Assistant is saying there is an update for it...

Does the panel somehow hold two different versions/banks and rebooting reverts back to the previous? Could have something to do with ESP-IDF.

I also deleted the unused exit reparse entity before, and it re-appeared again in my nspanel05 after reboot.

@grigi please confirm if you are experiencing same thing.. .check your compile version and date from log after rebooting panel.

Edit: reverted panel and tft back to main, reboot several times and all weirdness above is gone.

[grigi]

I was experiencing a similar issue @Doughboy68 where it would fail to get the blueprint on reboot.

My build of dev branch using ESPHome 2023.10.6, but just changing the build to use the arduino framework:

esp32:
  framework:
    type: arduino

Seems to start up reliably. Rebooted it several times now.

@edwardtfn BTW, for the esp-idf build, the only logs in HA itself was these:

Error while executing automation automation.nspanel1_configuration: extra keys not allowed @ data['embedded_climate_friendly_name']
November 4, 2023 at 11:05:56 PM – (ERROR) Automation - message first occurred at November 3, 2023 at 7:36:06 PM and shows up 21 times
NSPanel1 Configuration: Error executing script. Invalid data for choose at pos 1: extra keys not allowed @ data['embedded_climate_friendly_name']
November 4, 2023 at 11:05:56 PM – (ERROR) Automation - message first occurred at November 3, 2023 at 7:36:06 PM and shows up 65 times

[edwardtfn]

I will take a look. Thanks for the logs. :)