automate-home documentation
Why yet another home automation project?
Because I believe that a smart light could be more than just on or off. And I believe that a smart light should not need your control, neither local nor remote.
This project is not yet another interface to access and control your smart devices, I’m pretty sure your smart devices already have a great interface to do that.
This is an automation framework. It lets you build simple and complex automations, interact with and control them. But building a system that acts on behalf of you brings some problems that this project strives to solve:
User should win over the system
When a smart home system connects your devices then there is someone else in charge of controlling them besides you.
What if you and your smart home system disagree? A really smart home automation system should let you win.
Examples
Light
Suppose you have a light which is turned on/off when a motion detector sensor, in the light zone, is triggered/untriggered. You can turn on/off this same light with a button when you need it because, as an example, you come and go.
Now you need it, you turn on the light and you go away for some time. In the meanwhile someone else is arriving at home and the motion sensor went triggered and a few minutes later untriggered. The motion sensor, in a smart home automation system, should not turn off your light because the light is not just on but it is forced on by you; and you should win over the system because you already knew you would be back in a moment.
Curtain
Suppose you have an automated curtain: it is closed by the system when both the sun is shining and the sun is hitting the curtain’s window. You can open/close the curtain with a button.
Now, for some reason, you need more light and you open the curtain’s window with the button. It is a partly cloudy day and sun comes and goes, nevertheless your curtain should not be closed again at least until sun goes down.
User should not feel a sense of losing control
When the system acts on your behalf but you don’t understand why, you may experience a feeling of losing control.
For these reasons a good system should let you know, at every moment, what action it has taken and why.
The more automations you have, and the more complex they are, the more likely it is that the system will seem to have gone haywire — unless you know exactly what happened.
Examples
Light
If, for any reason, User Bob was not aware of User John then User Bob probably thought the system was wrong: since the garage light did not turn off (an automated light).
A light model should let User Bob know that User John forced the light on.
Curtain
When the curtain is up even though the sun is shining, someone else might think the system is broken unless they know the curtain is up because you forced it open (an automated curtain).
A curtain model should let other users know that you forced the curtain open.
Contents:
- Architecture
- Requirements
- Appliance
- Appliances Implementations
- Performer and Protocols
- Scheduler and Triggers
- Scheduler Trigger vs Protocol Triggers
- Scheduler (Class Diagram)
- Scheduler (Sequence Diagram)
- Trigger Class
- cron.Trigger
- interval.Trigger
- date.Trigger
- sun.sunrise.Trigger
- sun.twilight.civil.sunrise.Trigger
- sun.sunset.Trigger
- sun.twilight.civil.sunset.Trigger
- sun.sunhit.Trigger
- sun.sunleft.Trigger
- protocol.Trigger
- protocol.delay.Trigger
- protocol.enum.Trigger
- protocol.mean.Trigger
- protocol.mean.LesserThan
- protocol.mean.GreaterThan
- protocol.mean.InBetween
- protocol.multi.Trigger
- circadian_rhythm.Trigger
- state.entering.Trigger
- state.entering.delay.Trigger
- state.entering.delay.duration.Trigger
- state.exiting.Trigger
- state.exiting.delay.Trigger
- Protocols Integrations
- Example Projects