VSCode plugin thread about esphome-vscode HOT 6 CLOSED

I see, now I also better understand the current approach. You could...

1. implement it as a native VS Code extension (like you currently did),
2. implement the language server protocol

For the Home Assistant plugin I ended up implementing a language server for several reasons.

• Extend on the existing work done in the yaml-language-server
• Enable other IDE's than VS Code
• Implement known contracts for 'definition', 'completion', etc. / nicer abstractions / less plumbing

Then I had to decide to build it local (running as a proces in the IDE) or remote (as an endpoint in HA):

• Local
  Pro: Works offline, direct access to disk/files, low latency / state in memory
  Con: requires (ws) connection to HA. Deal with complex '!include_**' logic. Reuse the VS Langserver package.
• Remote
  Pro: Run validation against actual HA schema's. Completion with 'live' data.
  Con: Requires HA. No Python Lang Server Protocol package (?).
  In both cases you need a 'client' (example) which starts the server and connects the dots (via a tcp socket).

I ended up building a local language server. For ESPHome, it might make more sense to implement the lang-server protocol in ESPHome/the device (remote). This and this are example server implemented in Python.

from esphome-vscode.

The challenge is very similar to the one (I tried) to solve for Home Assistant, recently. If you would like, I'd love to do a PR to refactor the code to be very similar to mine, implementing a completionProvider.

I'm still in the proces of getting complete schema validation/completion to work for HA. Normally that would be quite easy by leveraging the yaml-language-server and creating a JSON schema. However, custom tags (like !include) make it very hard and this will -most likely- require quite some custom code (working on that right now).

from esphome-vscode.

Hi @keesschollaart81,

Yeah I know that plugin - also helped me get a bit familiar with the vscode API :)

As for the question: So completionProvider is something quite different to diagnostics, right? The think I'm trying to accomplish here is to get validation into VSCode; completion would also be nice but that's not a focus for now plus I don't think there's much to auto-complete in ESPHome other than config keys.

As for the JSON schema approach: Yeah I also tried that approach some time ago (back then to get it working with IntelliJ IDEs). First with manually written schemas and afterwards semi-automatically generated ones. But that's not going to be solution here because:

• If you get more complex validators (like functions), it's impossible to convert them to JSON schemas. Any time vol.All is used you will run into problems.
• All base validators (boolean, time period etc) need to be re-implemented twice. And of course when one accepts some user input where the other one doesn't that will be bad UX.
• Custom tags like you mentioned will be harder to do - especially with ESPHome's !lambda.
• Only applies to ESPHome: ESPHome uses rich validators in many places. They automatically tell the user what to do in certain situations (like typos etc). Those won't be able to be done in JSON schema.

Anyway, I don't such a solution will work too well. And especially since ESPHome can already give you all necessary info with an API call, why not use that directly? Then, you only have a single source of truth for validation and the plugin doesn't even need to be able to parse the YAML.

Basically, what I'm looking for is some way to write the code that connects to the websocket, sends the necessary info and passes that directly to VSCode.

Btw, most of this plugin would also apply to HA - ESPHome and HA use more or less the same infrastructure in many places. The paths have diverged in a couple of places but it will 100% be possible to get this system to work with HA too once it works and someone ports the code.

from esphome-vscode.

Hi @OttoWinter

Does the plugin get enabled for all .yaml files?

I get errors when trying to edit my homeassistant configuration file.

from esphome-vscode.

@daned33 I do disable the home assistant extension in the workspace

from esphome-vscode.

I ended up building a local language server. For ESPHome, it might make more sense to implement the lang-server protocol in ESPHome/the device (remote). This and this are example server implemented in Python.

Overall this answer is very helpful. However if I go implementing LSP in ESPHome I will need to do completion / hover in python, and I already got the json schema. So I believe a better approach will be to do like you did, override the yaml-language-server and feed it with the json schema just for completion / hover (disable validation), and for validation keep current approach which is sending yaml to ESPHome.

Btw, how do you maintain the ts files with the schema? is there any sync going on with ha docs / source?

For me writing some sticky glue code enabled me not only to pull completion (schema) and docs from ESPHome code base, but also improved on docs completeness as there are now exceptions which can be raised on documentation inaccuracies.

from esphome-vscode.