Comments (6)
I see, now I also better understand the current approach. You could...
- implement it as a native VS Code extension (like you currently did),
- 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.
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.
Related Issues (20)
- !secret syntactic error HOT 4
- component.update action not suggested when there are polling components in the sketch
- pzemac.reset_energy action not suggested when pzemac is in use
- Editor Pop-up placement HOT 2
- bug: dashboard mode sends wrong path secrets.yaml file HOT 16
- New Climate 'Preset' options HOT 3
- Wrong indent in VSCode when pasting code snippets
- How to configure it when running ESPHome locally? HOT 2
- unknown tag <!lambda> when lambda used to return a value HOT 6
- Unexpected path traverse error when autocompleting in lambda HOT 1
- Provide commands HOT 1
- Catch too big display HOT 1
- Schema generation error HOT 5
- hidden files arent picked up HOT 5
- sgp4x platform not recognized HOT 3
- Improve documentation to indicate importance of setting file type HOT 2
- Errors not showing up as squiggles anymore. HOT 2
- platformio
- Incompatible Platformio 6.1.15
- Cannot connect to ESPHome dashboardError: getaddrinfo ENOTFOUND vscode
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from esphome-vscode.