esphome/esphome/components/switch/switch.h

127 lines
3.8 KiB
C
Raw Normal View History

🏗 Merge C++ into python codebase (#504) ## 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).
2019-04-17 12:06:00 +02:00
#pragma once
#include "esphome/core/component.h"
#include "esphome/core/preferences.h"
#include "esphome/core/helpers.h"
namespace esphome {
namespace switch_ {
#define LOG_SWITCH(prefix, type, obj) \
if (obj != nullptr) { \
ESP_LOGCONFIG(TAG, prefix type " '%s'", obj->get_name().c_str()); \
if (!obj->get_icon().empty()) { \
ESP_LOGCONFIG(TAG, prefix " Icon: '%s'", obj->get_icon().c_str()); \
} \
if (obj->assumed_state()) { \
ESP_LOGCONFIG(TAG, prefix " Assumed State: YES"); \
} \
if (obj->is_inverted()) { \
ESP_LOGCONFIG(TAG, prefix " Inverted: YES"); \
} \
}
/** Base class for all switches.
*
* A switch is basically just a combination of a binary sensor (for reporting switch values)
* and a write_state method that writes a state to the hardware.
*/
class Switch : public Nameable {
public:
explicit Switch();
explicit Switch(const std::string &name);
/** Publish a state to the front-end from the back-end.
*
* The input value is inverted if applicable. Then the internal value member is set and
* finally the callbacks are called.
*
* @param state The new state.
*/
void publish_state(bool state);
/// The current reported state of the binary sensor.
bool state;
/** Turn this switch on. This is called by the front-end.
*
* For implementing switches, please override write_state.
*/
void turn_on();
/** Turn this switch off. This is called by the front-end.
*
* For implementing switches, please override write_state.
*/
void turn_off();
/** Toggle this switch. This is called by the front-end.
*
* For implementing switches, please override write_state.
*/
void toggle();
/** Set whether the state should be treated as inverted.
*
* To the developer and user an inverted switch will act just like a non-inverted one.
* In particular, the only thing that's changed by this is the value passed to
* write_state and the state in publish_state. The .state member variable and
* turn_on/turn_off/toggle remain unaffected.
*
* @param inverted Whether to invert this switch.
*/
void set_inverted(bool inverted);
/// Set the icon for this switch. "" for no icon.
void set_icon(const std::string &icon);
/// Get the icon for this switch. Using icon() if not manually set
std::string get_icon();
/** Set callback for state changes.
*
* @param callback The void(bool) callback.
*/
void add_on_state_callback(std::function<void(bool)> &&callback);
optional<bool> get_initial_state();
/** Return whether this switch uses an assumed state - i.e. if both the ON/OFF actions should be displayed in Home
* Assistant because the real state is unknown.
*
* Defaults to false.
*/
virtual bool assumed_state();
bool is_inverted() const;
protected:
/** Write the given state to hardware. You should implement this
* abstract method if you want to create your own switch.
*
* In the implementation of this method, you should also call
* publish_state to acknowledge that the state was written to the hardware.
*
* @param state The state to write. Inversion is already applied if user specified it.
*/
virtual void write_state(bool state) = 0;
/** Override this to set the Home Assistant icon for this switch.
*
* Return "" to disable this feature.
*
* @return The icon of this switch, for example "mdi:fan".
*/
virtual std::string icon(); // NOLINT
uint32_t hash_base() override;
optional<std::string> icon_{}; ///< The icon shown here. Not set means use default from switch. Empty means no icon.
CallbackManager<void(bool)> state_callback_{};
bool inverted_{false};
Deduplicator<bool> publish_dedup_;
ESPPreferenceObject rtc_;
};
} // namespace switch_
} // namespace esphome