* Use #line directives in generated C++ code for lambdas
The #line directive in gcc is meant specifically for pieces of imported
code included in generated code, exactly what happens with lambdas in
the yaml files: https://gcc.gnu.org/onlinedocs/cpp/Line-Control.html
With this change, if I add the following at line 165 of kithen.yaml:
- lambda: undefined_var == 5;
then "$ esphome kitchen.yaml compile" shows the following:
INFO Reading configuration kitchen.yaml...
INFO Generating C++ source...
INFO Compiling app...
INFO Running: platformio run -d kitchen
<...>
Compiling .pioenvs/kitchen/src/main.cpp.o
kitchen.yaml: In lambda function:
kitchen.yaml:165:7: error: 'undefined_var' was not declared in this scope
*** [.pioenvs/kitchen/src/main.cpp.o] Error 1
== [FAILED] Took 2.37 seconds ==
* Silence gcc warning on multiline macros in lambdas
When the \ is used at the end of the C++ source in a lambda (line
continuation, often used in preprocessor macros), esphome will copy that
into main.cpp once as code and once as a // commment. gcc will complain
about the multiline commment:
Compiling .pioenvs/kitchen/src/main.cpp.o
kitchen.yaml:640:3: warning: multi-line comment [-Wcomment]
Try to replace the \ with a "<cont>" for lack of a better idea.
* Correct implementation of comparisons to be Pythonic
If a comparison cannot be made return NotImplemented, this allows the
Python interpreter to try other comparisons (eg __ieq__) and either
return False (in the case of __eq__) or raise a TypeError
exception (eg in the case of __lt__).
* Python 3 updates
* Add a more helpful message in exception if platform is not defined
* Added a basic pre-commit check
## Description:
Move esphome-core codebase into esphome (and a bunch of other refactors). See https://github.com/esphome/feature-requests/issues/97
Yes this is a shit ton of work and no there's no way to automate it :( But it will be worth it 👍
Progress:
- Core support (file copy etc): 80%
- Base Abstractions (light, switch): ~50%
- Integrations: ~10%
- Working? Yes, (but only with ported components).
Other refactors:
- Moves all codegen related stuff into a single class: `esphome.codegen` (imported as `cg`)
- Rework coroutine syntax
- Move from `component/platform.py` to `domain/component.py` structure as with HA
- Move all defaults out of C++ and into config validation.
- Remove `make_...` helpers from Application class. Reason: Merge conflicts with every single new integration.
- Pointer Variables are stored globally instead of locally in setup(). Reason: stack size limit.
Future work:
- Rework const.py - Move all `CONF_...` into a conf class (usage `conf.UPDATE_INTERVAL` vs `CONF_UPDATE_INTERVAL`). Reason: Less convoluted import block
- Enable loading from `custom_components` folder.
**Related issue (if applicable):** https://github.com/esphome/feature-requests/issues/97
**Pull request in [esphome-docs](https://github.com/esphome/esphome-docs) with documentation (if applicable):** esphome/esphome-docs#<esphome-docs PR number goes here>
## Checklist:
- [ ] The code change is tested and works locally.
- [ ] Tests have been added to verify that the new code works (under `tests/` folder).
If user exposed functionality or configuration variables are added/changed:
- [ ] Documentation added/updated in [esphomedocs](https://github.com/OttoWinter/esphomedocs).
* Support SDS011 component.
* improve if condition
* Check update interval is multiple of minute
* do not allow update intervals longer than 30 min
* fix sensor schema name
* remove query_mode
* Warn if rx_only mode used together with update interval
* Allow update intervals below 1min
Messed that up before, as the docs say update intervals below 1min are allowed
* Use update interval in minutes
* use set_update_interval_min() to set update interval
* Add relative_url, streamer_mode, status_use_ping dashboard options
Additionally Hass.io now stores all build files in /data, so that snapshots no longer get huge.
* Lint
* Lint
* Replace tabs with spaces
