Automate apps testing

Third party integrations AppDaemon
21

thats what i tried at first too.
untill i found out that the bigger and more complicate the app was getting, the worse it was to add new situations.

22

Can you read the readme of my appdaemon app? How would you simplify it using small simple parts?

23

i would for example lose the night mode.

now you do:

motion_light:
  module: motion_lights
  class: MotionLights
  sensor: binary_sensor.living_room_motion
  entity_on: light.tv_led
  delay: 300
  brightness: 80
  night_mode:
    delay: 60
    brightness: 20
    start_time: '22:00:00'                  # required
    end_time: '07:00:00'                    # required

i would do:

motion_light_day:
  module: motion_lights
  class: MotionLights
  sensor: binary_sensor.living_room_motion
  entity_on: light.tv_led
  delay: 300
  brightness: 80
  start_time: '07:00:00'           
  end_time: '22:00:00'   
motion_light_night:
  module: motion_lights
  class: MotionLights
  sensor: binary_sensor.living_room_motion
  entity_on: light.tv_led
  delay: 60
  brightness: 20
  start_time: '22:00:00'    
  end_time: '07:00:00'

start and endtime could be normal AD constraints
so you dont need to program anything for that
and the biggest advantage is that you can split up in as many parts of the day you like.
morninglight, eveninglight,darkdaylight, etc.

thats the way i look at it. not trying to program for a whole day in 1 app, but split it up to parts of the day.

you are actually not way beyond if then not when.
you have

if then turnon not when
the setup is simular to mine, but i made it a little more global.
i can place any entity and a specific state on the place you have motion sensors
i can turn on/off lights/switches/booleans, set state from sensors/input numbers/input selects
and on the place from your state entities i can place any entity and compare with any state

but the structure is not that different.

1 Like
24

I wish I realised that before implementing night mode hahaha.
One problem is state management because motion_light_night won’t know about the other lights internal state. Which has weird behaviour at transition times.

25

so let the app set the state from a sensor when a callback is activated and off when its off again.
that way app 1 knows about what state app 2 was.

26

I want to avoid this because it creates coupling. Need to have a think about it. Thanks

27

but there shouldnt be any strange behavior.
when motion is detected lights need to turn on based on the settings from that moment, not based on the settings from the moment in the previous time part.
the only thing that will happen is that the lights will change brighness on motion (thats what happens here)

28

It does have internal state. The app solved a specific motion lighting problem. If you don’t have that problem, then it’s not the right solution for you.

29

Any new experiences in appdaemon unit testing?

I share the interest in and understanding of the need for unit testing appdaemon apps. I split out most logic (state machines etc) in standalone python modules which were unit testable, and used Python’s own unittest framework. The appdaemon apps then were thin wrappers that instantiated these modules. This worked quite well.

However, that might become too complex for my next plans, where I will have many apps that interact. I will check out the https://github.com/FlorianKempenich/Appdaemon-Test-Framework route.

1 Like