blasphemy: Switch to HA Integration instead of Blueprint? #1983
Labels
Enhancement
For suggestions that add new features or improve existing functionalities.
Comments
Bascht74
added
the
Enhancement
|
I thought about that a couple of times. It will definitely open new options and make the whole process simpler, as the way Blueprints work requires more communication between the panel and the blueprint, which could be minimized with this approach. And, the biggest blocker to this is my lack of time to invest on it. 😞 But it's nice to see those PRs you shared. That will certainly improve the user interface on the Blueprint side, which is also limiting us sometimes. |
|
Yeah, time is always an issue... As for PSRAM:
It seems to be used, e.g. by: You could add a sensor to get the free space: or: https://esphome.io/components/debug.html e.g. esphome/esphome#5872 The chip on the NSPanel seems to be a ESP32-D0WD-V3 (revision 3) that doesn't have PSRAM-bugs the the revisions befor had: According to https://blakadder.com/nspanel-teardown/ it has a 4MB Winbond flash (W25Q32JVSSIQ with 4 Mbyte) and a 16MB PSRAM chip (from https://pallavaggarwal.in/2022/12/23/teardown-sonoff-nspanel-wifi-tft/ you can see that it is a ESP PSRAM16H, so it is 16MBit so 2 MByte PSRAM) Custom GPIO Layout for the PSRAM |
|
I don't know how to set these pins via ESPHOME. ahhh. maybe I found it:
That is maybe interesting as well:
So accordingly to https://blakadder.com/nspanel-teardown/ : the compile options should then (maybe) add something like:
default values: https://docs.espressif.com/projects/esp-idf/en/release-v4.2/esp32/api-guides/external-ram.html PSRAM Vcc (pin 8) > ESP32 VCC_SDIO |
|
By the way, I just found this: As you can see, somebody tried the same and it seems to work with that configuration. He set: I will try tomorrow with: |
|
Wow, I've looked for enabling this PSRAM many times and got to most of those things you mentioned, but never to that esphome/feature-requests#2369 from @olicooper which looks to be in the right direction: I still have to play a bit more to find a way to map all the 16Mb, but anyhow, 2Mb is very welcome if that works with no issue. Thanks a lot for your support!! |
This was referenced Mar 26, 2024
16Mbit = 2Mbyte, so all fine? |
|
You are right. From the teardown (form long time ago) I understood it was 16MBytes, but just opened my panel to double check the PSRAM chip and it is indeed 16 Mbit: ESP PSRAM16H |
|
So, the downside of this is breaking the Arduino compatibility: https://github.com/Blackymas/NSPanel_HA_Blueprint/actions/runs/8436027984 But this is expected to some moment anyways. |
|
Ah yes, the reason I was looking in to the PSRAM of the NSPanel is because I am developing a native ESPHome component for the NSPanel (seen here) but as you have noticed, the various assets required to give it all the required features makes it difficult to manage without this additional memory! I came across the same issue with Ardunio not supporting updates to the required defines without rebuilding the Arduino binary (making it not feasible for most people). I am planning to move over to esp-idf as a result. This will have the added benefit of improving performance and reducing space requirements. I'm not sure if you can do the same? |
|
@olicooper this is the way :) |
|
I have no questions about ESP-IDF. I'm using this myself since a while and it is rock solid. The Nextion component on ESPHome is now fully compatible (including the upload TFT engine) with ESP-IDF. But before I forget, thanks a lot for giving the directions to PSRAM. 😃 |
|
Couple of thoughts: For ESP-IDF with BLE and upload TFT:
and:
Could be the solution to split the basic package e.g. like this: or maybe like this |
|
About splitting the files, I thought that also, but it will require all the arduino users to change they yaml. It isn't the end of the world, but will require good communication... |
|
I will try this with |
|
Very excited about it. Maybe it changes something. I cannot try myself right now (still in Frankfurt - football game yesterday…) |
|
I've tried, but unfortunately still the same issues. 😞 |
|
Everyone using arduino have this on their panel's yaml to specify the framework: esp32:
framework:
type: arduinoThey just have to change to this: esp32:
framework:
type: arduino
sdkconfig_options: !removeI wish we could have something like |
|
Related configuration defines that might be needed for SPI RAM usage:
So far, I'm not 100% confident it's working in ESPHome, had many crashes with my ESP32 when these were enabled in ESP-ADF, and it's very hard to debug post mortem with ESPHome. |
|
I'm using the following since a while with no noticeable issues: sdkconfig_options:
CONFIG_BT_ALLOCATION_FROM_SPIRAM_FIRST: "y"
CONFIG_BT_BLE_DYNAMIC_ENV_MEMORY: "y"
CONFIG_D0WD_PSRAM_CLK_IO: "5"
CONFIG_D0WD_PSRAM_CS_IO: "18"
CONFIG_ESP32_REV_MIN_3: "y"I've also tried those, but then I have issues when uploading TFT from a remote https server (GitHub): # CONFIG_LWIP_MAX_SOCKETS: "5"
# CONFIG_MBEDTLS_DYNAMIC_BUFFER: "y"
# CONFIG_MBEDTLS_DYNAMIC_FREE_CA_CERT: "y"
# CONFIG_MBEDTLS_DYNAMIC_FREE_CONFIG_DATA: "y"
# CONFIG_MBEDTLS_EXTERNAL_MEM_ALLOC: "y"
# CONFIG_MBEDTLS_SSL_VARIABLE_BUFFER_LENGTH: "y"
# CONFIG_SPIRAM_TRY_ALLOCATE_WIFI_LWIP: "y"I don't know exactly which one(s) was causing the issue. I will try more later to map the impact of each one of those. Additionally, I've tried those, but I haven't noticed any impact (neither positive or negative), so I've removed: #BOARD_HAS_PSRAM: "y"
#CONFIG_D0WD_PSRAM_MISO_PIN: "19"
#CONFIG_D0WD_PSRAM_MOSI_PIN: "23"
#CONFIG_SPIRAM_CACHE_WORKAROUND: "y"
#CONFIG_SPIRAM_SUPPORT: "y"I've also tried different modes and speeds on the PSRAM component, with no noticeable impact. 2024-04-05 Edit: |
|
Some of the keys are already added by the PSRAM component: async def to_code(config):
if CORE.using_arduino:
cg.add_build_flag("-DBOARD_HAS_PSRAM")
if CORE.using_esp_idf:
add_idf_sdkconfig_option(
f"CONFIG_{get_esp32_variant().upper()}_SPIRAM_SUPPORT", True
)
add_idf_sdkconfig_option("CONFIG_SPIRAM", True)
add_idf_sdkconfig_option("CONFIG_SPIRAM_USE", True)
add_idf_sdkconfig_option("CONFIG_SPIRAM_USE_CAPS_ALLOC", True)
add_idf_sdkconfig_option("CONFIG_SPIRAM_IGNORE_NOTFOUND", True)
if CONF_MODE in config:
add_idf_sdkconfig_option(f"{SPIRAM_MODES[config[CONF_MODE]]}", True)
if CONF_SPEED in config:
add_idf_sdkconfig_option(f"{SPIRAM_SPEEDS[config[CONF_SPEED]]}", True)
var = cg.new_Pvariable(config[CONF_ID])
await cg.register_component(var, config) |
This is added by default by ESPHome PSRAM component. 👀 |
|
@olicooper, this might be useful for you, as I've successfully enabled PSRAM with Arduino by using this: esphome:
name: ${name}
friendly_name: ${friendly_name}
platformio_options:
build_flags:
- -Wno-macro-redefined
- -Wno-missing-field-initializers
- -DBT_ALLOCATION_FROM_SPIRAM_FIRST
- -DBT_BLE_DYNAMIC_ENV_MEMORY
- -DCONFIG_ESP32_REV_MIN_3
- -DCONFIG_D0WD_PSRAM_CLK_IO=5
- -DCONFIG_D0WD_PSRAM_CS_IO=18
psram:I got lots of warnings when compiling, which I haven't tested exhaustively, but ESPHome is reporting that additional memory as available. 😉 |
edwardtfn
added a commit
that referenced
this issue
Apr 4, 2024
Supports #1983 Supports #1946 Supports #1815 Could support esphome/feature-requests#2369
Solved! 😃 Still some warnings for the ones using Arduino, but I think we can leave with this (unless someone have a tip to remove those warnings related to macro redefined). |
See red section in this page. |
|
Mmmm |
|
@edwardtfn So you got psram working with custom pins in Arduino? A long time ago I tried Unfortunately I can't use Also, in my |
To be honest, I'm not sure how much this is really true. It is working pretty solid in 2 of my 3 panels, but the one panel where it was serial flashed using Arduino, it doesn't detect the PSRAM unless I flash it (OTA) with IDF, then I can flash OTA back to Arduino and the PSRAM will be there.
Well, I've used esphome:
platformio_options:
build_flags:
- -DDCONFIG_D0WD_PSRAM_CLK_IO=5
- -DDCONFIG_D0WD_PSRAM_CS_IO=18It works just like when adding to the component (same warnings when compiling, same everything).
That's a good idea. I still considering this PSRAM as "experimental", so I won't move to the component yet. It's much easier to ask users to add a |
I tried, but no success: configuration: |
|
Ok, some more results: Because there is a different response depending to the baud rate chosen, I think that there is another cause that the upload doesn't work and there is a different "fast" drain of heap memory. So I thought this might be because of BT. I tried to add: ... but same result. Still not working. So I tried to remove the script and add everything the right way (by copying the complete script and adding the ble code to the top): This time the upload worked with a lot of heap memory and stable remaining memory: |
|
Conclusion:
|
|
Wow, this is a great find. Thanks a lot! |
|
It is part of dev now |
|
Nice! Works here as it should. |
|
And you are not using psram... Have you added some code to remove that? |
|
no, that was on the prebuilt test nspanel. I assumed psram was now default ... Although - why did it not use more ram then, if the firmware is older than the change that should fix it.
|
|
Mmmm... It should build with every commit. I will take a look. |
|
I compiled with the new dev version and removed a lot of my additions. Results: This is my new (much smaler) configuration: Trying to update TFT: Wow, even more (stable) heap memory with this version: Great! Thx for fixing that! As I need BT for my temp sensors (I am not using the internal one, only as backup) I can now migrate all my nsplanels to your repository as soon as the new main version is out. Seb P.S. |
|
The pre-build is updated now. 😉 |
Just tried it and WOW - very consistant free DRAM. No leaking at all: |
|
I'm thinking about having a |
I tried it. It works fine, but I do need the ble_tracker only, not the bluetooth_proxy. The proxy features are taking a log more flash memory: now (with add-on) Could you make two add-on's as in the actuals docs right now?
One more question: How could I use some parameters for the ble_tracker: It would be good if a user can set these two... |
That should work. By the way, I can have another add-on, but you shoukd be able to either use as you are using before (without using the add-on, just adding the BLE tracker with the right id or you can use the new add-on and remove the BLE proxy with something like this: bluetooth_proxy: !remove |
I get: |
|
I will play with this and come back here |
|
I tried without the extend and it worked fine: esp32_ble_tracker:
scan_parameters:
interval: 1100ms
window: 1100ms |
esp32_ble_tracker:
scan_parameters:
window: 60ms
active: false |
|
And this is with the defaults: |
That is being released this week. I've already implemented the section on our blueprint. 😉 |
|
Great! I saw it. |
|
It's in |
|
Many month have passed. What is the status now? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Enhancement Summary
With your own integration, you could break out of the corset of the one (!) blueprint and realize some things that are difficult now more easily and flexibly.
Detailed Description
E.G. https://github.com/Sian-Lee-SA/Home-Assistant-Switch-Manager is using its own integration (in the background it is using blueprints as well!) to do some fance UI stuff. This would streamline the users experiance and would enable the possibility to add features that are right now not possible:
I know this stepp would be more of a radical one, but maybe it could set you guys free of all mayer limitations of blueprints.
Additional Context
Another way/alternative to control the length of the blueprint would be to add sections or the possibilty to hide stuff in the blueprint itself.
These are the people working on the editor of the blueprints itself:
https://github.com/home-assistant/frontend/commits/dev/src/panels/config/blueprint
And this is a pull request that could fire the whole project in an new area:
home-assistant/frontend#19946
home-assistant/core#110513
... and if they would add an option to hide input fields based on others afterwards that would make everything easy and smooth...
The text was updated successfully, but these errors were encountered: