[Feature Request] Native ESPHome Component

[olicooper]

FEATURE DESCRIPTION

I love this project and I think the UI looks great, but I found that the NSPanel would feel unresponsive if the WIFI signal was poor. I also didn't want to use MQTT or AppDeamon as this complicated the setup and meant I had to maintain more software packages.

So, to tackle the issue I decided to create a native ESPHome component for the NSPanel which utilises the UI from this project. The project is still in beta and doesn't have all the features implemented but I wanted to share it to see if this was something the community wanted and was worth investing more time in? The downside of my solution is that you unfortunately lose the quick config updates that you get with the AppDaemon solution as you have to compile the ESPHome firmware after changing the yaml config, but the panel is more responsive due to the logic being handled internally on the device.

I am hoping that this will solve a few problems:

• Reduce bandwidth consumption by utilising the efficient TCP communication implemented by ESPHome.
• Remove the need for an MQTT broker and make the device able to function on a minimal level during network outages.
• Make the screen more responsive by having the ESP32 do some of the heavy lifting (the ESP32 is actually quite powerful!)

The project can be found here: https://github.com/olicooper/esphome-nspanel-lovelace-native

Any feedback and/or help would be greatly appreciated!

I apologise in advance if this is not the best place to post this.
Thank you for creating such a great project!

ADDITIONAL CONTEXT

_I am the owner of the above repository 😄 _

PANEL / FIRMWARE VERSION

N/A (it should work with any panel, but only tested on the EU version)

[joBr99]

Hey looks interesting, do you have discord?

https://discord.gg/98V7qp4

[r0bb10]

wow this would be really really good!

[CultusMechanicus]

I had no idea how much I would want this! Absolutely watched!

Edit: Absolutely no disrespect intended to the AppDaemon back end, but the upstream mess around v14 to v15 and the Weather changes have kinda soured me on AppDaemon itself. This already has the basics working, is self contained and has esp-idf support being worked on (to free up space for BTProxy). Once cardThermo and cardAlarm are in, I'll switch over in a heartbeat.

[grericht]

i am interested!

[janprive]

Interested too!

[joBr99]

I had no idea how much I would want this! Absolutely watched!

Edit: Absolutely no disrespect intended to the AppDaemon back end, but the upstream mess around v14 to v15 and the Weather changes have kinda soured me on AppDaemon itself. This already has the basics working, is self contained and has esp-idf support being worked on (to free up space for BTProxy). Once cardThermo and cardAlarm are in, I'll switch over in a heartbeat.

Around the time of this mess around v14 and v15 I started to reimplement everything without appdaemon in a standalone addon #1058, it's missing documentation and some error handling, but feature-wise pretty much everything is implemented.

[olicooper]

Once cardThermo and cardAlarm are in, I'll switch over in a heartbeat.

@CultusMechanicus I have just implemented initial support for the alarm card if you feel like testing it.. I cannot give you a timeline on the thermo card right now though (it is harder to implement and I have no HVAC controls in my HA instance to test against 😆). IDF is also the default now.

@joBr99 Would it be possible to update the HMI readme to include the latest TFT command structure/examples? I realise this could be a big job so feel free to say no. It has been a great documentation source for working out how to structure the project and figure out the common string building patterns across all of the cards (like page navigation and entity icons) - so thank you for making it 👍

[joBr99]

@olicooper
You can add demo: to your configuration.yaml and you have a lot of entities to test with.
https://www.home-assistant.io/integrations/demo/

The documentation in the Readme should be mostly up-to-date, holler on Nextion discord if you want to have something to test your generated commands easier.

[CultusMechanicus]

Once cardThermo and cardAlarm are in, I'll switch over in a heartbeat.

@CultusMechanicus I have just implemented initial support for the alarm card if you feel like testing it.. I cannot give you a timeline on the thermo card right now though (it is harder to implement and I have no HVAC controls in my HA instance to test against 😆). IDF is also the default now.

I'll give it a go soon, my two nspanels see pretty heavy use day to day, so I'll have to do some sneaky weekend updating :)

@olicooper, you should probably enable 'Issues' on your Github repo. Probably not the best idea to have all your discussion on joBr99's repo :)

Around the time of this mess around v14 and v15 I started to reimplement everything without appdaemon in a standalone addon #1058, it's missing documentation and some error handling, but feature-wise pretty much everything is implemented.

I have actually seen this, but a) there's no docs that I could find on how to use it and b) I'm using the esphome-nspanel-lovelace-ui from sairon on the actual panels (so they double up as BT proxies) and I was a bit unsure if the two would play well together.

[CultusMechanicus]

Ok, I have (finally) given Oli's work a go, it's extremely solid for the features I use. Screensaver, grids of lights/switches, guest wifi QR code etc all work and the whole thing is very snappy. Yes, there's a few issues on the snagging list, but for the most part I think this is the way forward for me. I can drop AppDaemon and not have a custom component, just ESPHome (which is used for other stuff too).

[grericht]

I have a question.
I'm currently using this lovelace UI. Specifically, I'm using the tasmota_nspanel firmware on the nspanel and at some point I uploaded the tft file there. App daemon runs in home assistant. And I write the contents of the panels (I have 2) into the apps.yaml. I have to honestly say that I don't know exactly how everything works together.

I'm actually quite happy with it. What bothers me is that the system seems very sluggish. I also don't think some of the visual implementations are quite as successful, but I can live with that.

I liked the blueprint version much better visually (implementation of the buttons) but I miss the energy dashboard and I miss the setting options.

I've read that it's possible to use esphome too. There seem to be several options for that, right?

1. Also with app daemon via mqtt and therefore probably just as sluggish?
2. the version here that works via the esphome api? is that smoother?

What exactly do I have to do to get to this variant and is there anything I need to take into account? Will there be any problems?

[olicooper]

I think you'll find that you will need to compromise with any of the available solutions.
There are three main elements to these solutions:

1. Home Assistant to control your home
2. The ESP firmware which provides the communication between Home Assistant and the screen
3. The screen/TFT/HMI which displays the interface and tells the ESP32 what button has been pressed etc.

Now the main difference is about who/how we talk to Home Assistant (I may be over-simplifying the following explanations):

• Both the blueprint and nspanel-lovelace-ui repositories directly communicate with the screen and use the ESP32 to 'proxy' the commands to and from Home Assistant so the ESP doesn't really do much. The blueprint version uses Home Assistants 'blueprint' functionality to do the processing, and nspanel-lovelace-ui uses a custom integration which is run with AppDaemon. What is good about these are that the config can be updated without re-compiling firmware but the compromise is the sluggishness.
• esphome-nspanel-lovelace-native moves the processing from Home Assistant to the nspanel itself which makes if feel much snappier. It still relies on HA to actually control your home but it can communicate with the screen without needing WiFi or needing to install extra software like MQTT or AppDaemon. This uses has the same look as nspanel-lovelave-ui because it uses the same screen firmware. The downside to this version is that right now it is in beta and doesn't yet support all the available features like the energy card you mentioned. The readme will probably help you to understand it a bit more (and provide install instructions if you want to try it - the same goes for the other repos too 😃)

Tasmota is a tool that is meant to provide a way to create firmware for the ESP without much/any coding. ESPHome solves the same problem but in a different way (using yaml config files). ESPHome is my preferred choice which is why I built esphome-nspanel-lovelace-native on it.

You are best just trailing each one out and seeing which fits best for you. All repos are actively developed so things are evolving all the time and may work better for you in the future so just keep your eye out for updates 👍

[grericht]

Thank you for this comprehensive explanation. I originally had a few Tasmota devices, but have now completely moved away from them except for the NSPanel and an SML SMI. I now also use ESP Home and would therefore like to try this. But there is a link to an ESPHome project for the NSPanel at https://docs.nspanel.pky.eu/stable/prepare_nspanel/: https://github.com/sairon/esphome-nspanel-lovelace-ui
There is a thread there about using the ESPHome API. So am I right in assuming that Sairon's project does not bring any improvement, since ESPHome is simply used instead of Tasmota but the ESP is also bypassed? Is this the result of the thread with the request to use the API (sairon/esphome-nspanel-lovelace-ui#34)?

[olicooper]

The issue you linked replaces MQTT with the NativeAPI which is quicker because it uses protobuf over a TCP socket, but yes it still bypasses the ESP.

[joBr99]

The ESPHome project from sairon is an 1:1 replacement of the task tasmota does. Relay MQTT Messages to the Nextion Display.
However it is also possible to use the HomeAssistant API with ESPHome instead of MQTT.

ESPHome+API is probably faster than Tasmota+MQTT

On the backend side there is the appdaemon backend and the "beta" #1058 Backend that is also based on python but without appdaemon (faster).

Besides that there is the Compnent linked in this thread which moves the entire backend to esphome.

[grericht]

Thanks for the explanation. I'm very sure that they want to move away from Tasmota and go to Esphome. If it's faster, I'd also like to move away from appdeamon as the backend and seem to have 2 options for testing:

1. this naive implementation (which primarily lacks the PowerFlowCard)
2. "ESPHome project from sairon is a 1:1 replacement of the task tasmota does." + "However it is also possible to use the HomeAssistant API with ESPHome instead of MQTT." + "On the backend side there is the appdaemon backend and the "beta" Rewrite of HomeAssistant Backend without AppDaemon #1058 Backend that is also based on python but without appdaemon (faster)."

it's not likely that 2. is noticeably slower than 1.?
Unlike 1., are all functions available in 2.?

What do you think which of the two variants will be productive faster?
How should I proceed to test if I come from tasmota? Do I have to remove it again and flash it with esphome using a serial cable?

[olicooper]

You won't easily be able to use 2 with the 'beta' changes because they have not been merged yet. All functions are available with 2 but still requires AppDaemon to work for now. The configuration for both options is similar so I would just try both and see what you are happier with. 1 is quicker to get working though (no AppDeamon to install, just add device to HA and tick the box to "Allow the device to make Home Assistant service calls") so try that first?

[joBr99]

no, the beta python backend works with esphome (both mqtt and api) and also tasmota and has more or less everything implemented from appdaemon - it's a 1:1 replacement for the appdaemon component (config is more or less compatible)

[olicooper]

Ah my mistake, I only looked at the release notes for the last few versions and a few commits but didn't see anything mentioned about the HA addon. So @grericht can try both pretty easily to decide now! Thanks 👍