Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Optional Components] ESPhome dashboard #1904

Open
moodyblue opened this issue Sep 21, 2024 · 15 comments
Open

[Optional Components] ESPhome dashboard #1904

moodyblue opened this issue Sep 21, 2024 · 15 comments
Labels
enhancement New feature or request help wanted Extra attention is needed

Comments

@moodyblue
Copy link

moodyblue commented Sep 21, 2024

Issue information:

Now that OH has an esphome binding it would be great that openhabian includes esphome dashboard

Description:

ESPhome dashboard allows one to manage ESP devices. It can be installed with pip3 install esphome and run with esphome dashboard <folder name>. Users can access it with http:\\openhabian:6052

@SeveranExp
Copy link

I’m using the docker container of esphome, so having it in openhabian would be great, since esphome provides access to a lot of sensors and others.

@ecdye ecdye added enhancement New feature or request help wanted Extra attention is needed labels Sep 22, 2024
@ecdye
Copy link
Contributor

ecdye commented Sep 22, 2024

This sounds like a great addition, I personally don't use this feature but I would be happy to review a pull request if one of you would be willing to implement it.

@moodyblue
Copy link
Author

moodyblue commented Sep 22, 2024

Install instructions are here https://esphome.io/guides/installing_esphome#linux

To run:

source venv/bin/activate
esphome dashboard <folder> &

This returns the pid to kill the process, if needed.

esphome can be updated using pip --upgrade

Pls note that I'm not a Linux expert.

@mstormi
Copy link
Contributor

mstormi commented Sep 23, 2024

Please note we don't build stuff on people's request. We're just the maintainers, that means we coordinate development.
If you want the thing to happen, please implement and test it yourself and provide a PR here then we can review and eventually merge it.

@moodyblue
Copy link
Author

moodyblue commented Sep 23, 2024

Is there any documentation on how to do it ? One thing is to change the Z2M installation (I've eventually found the way to do it), another is to create a new option in openhabian-config, with all its consequences (update, start and kill the process, etc)

@mstormi
Copy link
Contributor

mstormi commented Sep 23, 2024

No there isn't.
As one will have either a network coordinator OR a stick, it's both options. I'd think this should be the way to implement:
First you need to provide a routine that takes an option (to specify to install or remove/uninstall), and it needs to work in both modes, in interactive and in automated mode.
Next you should build a setup_z2m() function that likewise works in both modes that configures the z2m setup and lets you choose either network coordinator or local stick.
In menu, add install, remove and setup.
Check the code and menu on EVCC for a template (in packages.bash).

@moodyblue
Copy link
Author

moodyblue commented Sep 23, 2024

Actually my idea is slightly different. If there is a stick proceed as usual. If not, prompt the user for the ip:port address of the coordinator. The yaml is the same in both cases (stick or network), what changes is the port: clause.

  1. In the case of stick port: /dev/serial/xxx (detected by the script)
  2. In the case of network port: tcp://<ip address>:port (input by the user)

Incidently the SLZB-06 can also be discovered with port: mdns://slzb-06 if mDNS is active so the ability to edit configuration.yaml may be good.

What do you think ?

@mstormi
Copy link
Contributor

mstormi commented Sep 24, 2024

From a coding perspective, you should first be building a setup routine that takes coordinator or stick as a parameter at runtime (plus 2ndary parameters) and configures your system for the specified version.
Your implementation should be reusing (not copy!) and replace the existing 'stick' code.

Then next you can call that routine from the menu with an explicit parameter or from a parameterless routine that does some sort of autodetection.

@moodyblue
Copy link
Author

Something like this ?
imagem

@mstormi
Copy link
Contributor

mstormi commented Sep 24, 2024

yes if internally made like written above

@moodyblue
Copy link
Author

moodyblue commented Sep 29, 2024

I'm planning to use miflora_setup as the base for esphome dashboard. Questions:

  1. I've noticed that miflora_setup has no remove option. Can I do the same ?
  2. Can I call the new function espdashboard_setup ?

@mstormi
Copy link
Contributor

mstormi commented Sep 29, 2024

  1. no, please.
    miflora stuff is ancient and does not meet the standard for new additions (such as that 'remove' should also be implemented right away)
  2. any install+remove routine should not be called ..._setup, that's for setup routines, obviously.

@moodyblue
Copy link
Author

I'll do my best. I'm not a developer, and like myflora the "esphome dashboard" uses python venv.

I've seen that all other routines are _setup, why do you say that I cannot use that suffix ? Implementing one parameter ("install" or "remove") should be no problem.

@mstormi
Copy link
Contributor

mstormi commented Sep 29, 2024

like I said _setup should be for setup, i.e. configuring things, not for (un)install
and it's not all others.
Like I said use a recent addition such as evcc as your template .

@moodyblue
Copy link
Author

I see. install_espdashboard with "install" and "remove" options ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

4 participants