Sandboxed HA to test App/develop GUI (reuse production configuration)

I wanted to have a development instance of Home Assistance in order to develop and test my automations, Apps and GUI. The goal was to reuse as much as possible of my production configuration.

My production server is a raspberryPi running Raspian and Home Assistant in a Python virtualenv as suggested in the documents. I have some zwave devices controlled from a RaZberry card and a Tellstick Duo connected on a USB hub to control Nexa switches and read Nexa sensors.

For the development server I choose my Windows 10 laptop and installed Home Assistant and Appdaemon using pip in a virtualenv.

This is how the front end now looks on my development machine where I have reconstructed one of my cards:


To the left is the Hallway group which is identical with the group card on my production server. It consists of a Fibaro wall switch, an Aeotec Multisensor 6 and an input slider:

hallway:
  name: Hallway
  entities:
    - switch.fibaro_system_fgwpef_wall_plug_switch
    - binary_sensor.aeotec_zw100_multisensor_6_sensor
    - sensor.aeotec_zw100_multisensor_6_luminance
    - input_slider.hallway_min_light_level

To the right is the Hallway stub group card which is how I manipulate the stubbed zwave devices:

  • Wall plug switch: This emulates the Fibaro wall plug switch’s physical on/off button
  • Motion: This emulates motion detected by the Aeotec multi 6 sensor
  • Brightness level: This emulates the light level reported by the Aeotec multi 6 sensor


Here I have lowered the simulated light level to below the threshold and then activated motion by turning Motion on. My App then turned on the fibaro switch (Hallway Light) which is also reflected on the Wall plug switch.

What I did was to replace my real zwave devices with template devices, while keeping the entity ids:

...
# This template switch replaces my zwave switch on the development server
switch:
  - platform: template
    switches:
      fibaro_system_fgwpef_wall_plug_switch:
        value_template: "{{ is_state('input_boolean.fibaro_system_fgwpef_wall_plug_switch', 'on') }}"
        turn_on:
          service: input_boolean.turn_on
        turn_off:
          service: input_boolean.turn_off

# This template replaces my zwave binary_sensor on the development server
binary_sensor:
  - platform: template
    sensors:
      aeotec_zw100_multisensor_6_sensor:
        value_template: "{{ is_state('input_boolean.aeotec_zw100_multisensor_6_sensor', 'on') }}"

# These are used to hold values for the templates above
input_boolean:
  fibaro_system_fgwpef_wall_plug_switch:
    name: Wall plug switch
    icon: mdi:power-socket-eu
  aeotec_zw100_multisensor_6_sensor:
    name: Motion
    icon: mdi:walk

input_slider:
# This is identical on my production server as well as on my development machine
  hallway_min_light_level:
    name: Light threshold
    initial: 4
    min: 0
    max: 20
    step: 1
    icon: mdi:lightbulb-on-outline

# For simulating the light level reported by the zwave device
  aeotec_zw100_multisensor_6_luminance:
    name: Brightness level
    initial: 20
    min: 0
    max: 40
    step: 1
    icon: mdi:weather-sunny

This specific card group uses an App for automation with the following configuration (which now is identical on my development and production server):

smart_hallway_light:
  module: motionLightSensor
  class: MotionLightSensor
  light_slider: input_slider.hallway_min_light_level
  light_level: '5'
  delay: '1800'
  switch: switch.fibaro_system_fgwpef_wall_plug_switch
  binary_sensor: binary_sensor.aeotec_zw100_multisensor_6_sensor
  light_sensor: sensor.aeotec_zw100_multisensor_6_luminance

App features which I wanted to test out through the stub card:

  • Turns on switch when motion is detected and light level is not above configured threshold.
  • Turns off switch after configured delay period
  • If the motion sensor is still active after delay period, keep light on and start a new delay period.
  • Optionally, use input_slider to set light threshold and switch adjusts directly.

It’s only the delay time that I currently cannot test since it was hard coded in the App configuration above.

The next step is to find out how to place the configurations across files in such a way that I only need to do minimal adjustments while reusing the same files on both my production and development server (ideally from same branch in the repository). E.g. the addition of the input_slider above should probably move out to a separate file…

Hopefully I may inspire someone and perhaps also get suggestions for improvements :wink:

I also have a development box, but it is a VirtualBox VM running Lubuntu on a Windows 10 PC. This enables me to run the same Linux commands on the test box as the working machine (RasperryPi B+)

That would indeed nicely complement my setup, thanks.

Can I ask how you move tested configurations to your live server? I’m trying to replicate what I’m used to with web development where I use a repo on Codebase and DeployHQ to deploy changes from Dev environment to live. At the moment I’m just using SCP to copy across but it feels a little clunky.

I use a private git account on a server, so I do a git push from the VM and git pull on the Pi.

You can also do a git pull on the Pi directly from the VM, but I like to have an off-site backup as well.

Thanks. Tried this but got some issues with permissions on the .homeassistant directory (running in virtualenv). Seems like the right approach though so will keep plugging away.

You have to use git has the same user. that runs HA, and so has the correct permissions for the .homeassistant directory.

The virtualenv is a python only construct, so has no effect on git.

1 Like