Entity Controller Mega Thread (Motion Lighting Controller)

Hi all,
If you are looking for a motion lighting implementation with lots of customisation options check out mine on Github. I just released version 1.0.0 (a major rewrite). Some features include:

  • define control entities
  • define sensor entities
  • override entities (disable motion lighting when tv is playing for example)
  • state entities (for queriring state, advanced configuration)
  • support for event and duration based sensors
  • Night mode
  • custom service data
  • maintains entities with state and interesting attributes (for use in other automations)
  • script inputs
  • exponential delay increase (for recurring motion in an area)
  • customise state strings (in case “playing” means “on”)
  • draw state diagrams in real time (to be consumed by file camera, for example)

Find the component on Github

The component is available on HACS and can be installed and kept up-to-date easily.

Edit: include video


Have tried with a basic configuration, working ok.
If you are taking feature requests:grin:

  • incorporate light sensor value(Some of my lights are to be activated if the light level in the room is below a threshold)
  • Sensors activated in sequence: Activate the lights only if the sensors are activated in sequence
    Outside motion detected-> door opened within 10 sec -> inside motion detected in ten sec-> Lights on and remains on until the door opens again.(This is specific to bathrooms and toilets where there may not be motion for extended periods but the lights needs to be on, I have a bad habit of reading):wink:
    Anyway thank you for sharing your app.

This is very well done; and some nice work. Using the state machine framework really helps clean it up.

It is too bad it’s not a custom component itself; as needing AppDaemon means many won’t experience how well done this is.

Could probably port it to a custom component. I don’t remember why I went for appdaemon. I guess the original motion light app was appdaemon based.

1 Like

There is an inifinite number of use cases. I suggest you create a binary sensor of some kind (probably using template platform) that is on when those conditions are satisfied.

The bathroom lighting use case is interesting, and I actually have the same problem. I think this requires a custom component (because it must store some internal state, which is difficult to do in HA… unless you want to do it with input_booleans that only represent variable value). It requires some logic smarts to implement.
Is it possible to simply this and have it observe the state of the door and the bathroom motion sensor? The outside motion sensor is not strictly required, I don’t think.


Buy one of those head mounted camping lights :wink:

1 Like

oh my… I dont think headmounted flash light will be an acceptable solution!! :smile:
I am surprised they have sensors on internal doors and the bathroom.

1 Like

This looks fantastic. I really appreciate the great documentation and examples.

1 Like

Porting it to a light platform. Should it be under the light domain? or its own component and the possibility of differing platforms underneath?
Need some help from the design point of view because I just realised, if we make it a component, then we can implement different platforms for example, one platform for normal and one platform for lights that stay on. IN other words, platform dictate special behaviour.
What do you think?The other issue is that I need the OS to have dot package installed in order to produce diagrams. I do not think HA’s allows components to install packages on the OS. The only way to achieve this would be to build a custom docker image or ask users to install dot manually.
dot is only required for drawing state machine graphs (not critical).

Wow; didn’t think you would move forward!

I’d call it motion_trigger as the platform/domain as that’s what it is; and this is the best implementation I’ve seen thus far and maybe it ends up being part of the official release. It is something that a home automation package needs as a base feature.

Perhaps leave out the diagram portion for now; it is a nice feature but more the icing on the cake versus the cake itself. I know that in the past some of the zwave mesh graphers used extra packages for the graphing; which was a manual side install to get that feature working.

Thanks for doing this work; I was getting ready to take the plunge back into AppDaemon!

The appdaemon version will be abandoned. I went for AD because the python interfaces are really nice. HAs Python API is tricky and confusing… way less productive.
It will be worth it though once it’s part of HA as a native component. What do you think, should it be a platform under light domain or its own component with root level motion_light entry in configuration?

I suspect people will use this to trigger lights, switches, and scripts. If you place it under the light domain, like flux is under the switch domain, it feels a bit lost. This is why I liked motion_trigger as it feels more generic.

I agree it would get lost. Are you a developer? Would appreciate some help on this :slight_smile: for things like config validations

if you want it to be integrated it needs to be in the right place.
it needs to create an entity.

its actually not that different from the flux switch.

so i think it needs to be like:

  - platform: motion

because the motion is used as switch to turn the lights on and off.

Yep, that sounds fair enough. Will place it in the switch domain then.

Background is an electrical engineer. But for the last decade I’ve been managing technical teams and not so much hands on.

I can code in C++/# and Python but not elegantly – and will gladly help however I can!

Morning - any idea as to why the module would not be loading? Restarted Appdaemon and the it does not want to start. Remove the lighting_sm.py files and all is ok.

2018-12-27 09:50:37.446058 WARNING AppDaemon: ------------------------------------------------------------
2018-12-27 09:50:37.446398 WARNING AppDaemon: Unexpected error loading module: /home/homeassistant/.homeassistant/appdaemon/apps/lights/lighting_sm.py:
2018-12-27 09:50:37.446537 WARNING AppDaemon: ------------------------------------------------------------
2018-12-27 09:50:37.448455 WARNING AppDaemon: Traceback (most recent call last):
File “/srv/appdaemon/lib/python3.6/site-packages/appdaemon/appdaemon.py”, line 2026, in check_app_updates
self.read_app(mod[“name”], mod[“reload”])
File “/srv/appdaemon/lib/python3.6/site-packages/appdaemon/appdaemon.py”, line 1809, in read_app
self.modules[module_name] = importlib.import_module(module_name)
File “/usr/lib/python3.6/importlib/init.py”, line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
File “”, line 994, in _gcd_import
File “”, line 971, in _find_and_load
File “”, line 955, in _find_and_load_unlocked
File “”, line 665, in _load_unlocked
File “”, line 678, in exec_module
File “”, line 219, in _call_with_frames_removed
File “/home/homeassistant/.homeassistant/appdaemon/apps/lights/lighting_sm.py”, line 7, in
from transitions import Machine
ModuleNotFoundError: No module named ‘transitions’

The transitions python package must be installed for the app to work. There is an appdaemon app that installs all dependencies automatically before loading apps. I forget what it’s called though.

Thanks Danny, will investigate further.

@ReneTode @jwelter I am having major problems getting transitions to work in a HA component because both use a class attribute called state. transitions state machine fails to initialise because it attempts to assign its own values to HA’s state attribute…which throws an AttributeError of course.
This is a lot of effort. :confused:

Update: making progress. The problem i see with switch domain is that the motion light itself is not ‘on’ or ‘off’. it’s states correspond to the state machine states, which can be active, idle, disabled, blocked etc. Switch displays a toggle switch in the front end as well (rather than the state of the entitiy).
Isn’t there a generic entity domain? Checked out the automation domain as well however, that is for defining automation YAML syntax.