Add support for ElkM1 alarm/automation panel #16952

gwww · 2018-09-28T19:06:38Z

Description:

Support for the ElkM1 alarm/automation panel. This has been in development for around 6 months. A number of people have installed and have been testing the code as a custom_component.

Looking for feedback on how to improve.

Related issue (if applicable): fixes #

Pull request in home-assistant.io with documentation (if applicable):
home-assistant/home-assistant.io#6587

Example entry for `configuration.yaml` (if applicable):

elkm1:
  host: elk://192.168.1.201:2101
  temperature_unit: celsius
  area:
    include: [1]
  counter:
    include: [1]
  keypad:
    include: [1-3]
  output:
    include: [9]
  task:
    include: [1]
  thermostat:
    enabled: false
  plc:
    include: [1-10, 13-14, 17-20, 22-24]
  setting:
    enabled: false
  zone:
    include: [1-5, 8, 10-31]

Checklist:

The code change is tested and works locally.
Local tests pass with tox. Your PR cannot be merged unless tests pass

If user exposed functionality or configuration variables are added/changed:

Documentation added/updated in home-assistant.io

If the code communicates with devices, web services, or third-party tools:

New dependencies have been added to the REQUIREMENTS variable (example).
New dependencies are only imported inside functions that use them (example).
New or updated dependencies have been added to requirements_all.txt by running script/gen_requirements_all.py.
New files were added to .coveragerc.

If the code does not interact with devices:

Tests have been added to verify that the new code works.

homeassistant/components/light/elkm1.py

MartinHjelmare

Thanks for the PR. First strip this PR down to only add the elkm1 component and the alarm_control_panel platform. Further platforms should be added one platform and PR at a time. We want PRs to be as small as possible to make review and merge quicker.

I've commented on the component and the alarm_control_panel platform.

MartinHjelmare · 2018-09-30T10:25:59Z

homeassistant/components/alarm_control_panel/elkm1.py

+                                 STATE_ALARM_DISARMED, STATE_ALARM_PENDING,
+                                 STATE_ALARM_TRIGGERED, STATE_UNKNOWN)
+
+from homeassistant.components.elkm1 import (DOMAIN, create_elk_devices,


Import the elkm1 domain as another name. This platform belongs to the alarm_control_panel domain.

MartinHjelmare · 2018-09-30T10:27:07Z

homeassistant/components/alarm_control_panel/elkm1.py

+from homeassistant.components.elkm1 import (DOMAIN, create_elk_devices,
+                                            ElkDeviceBase,
+                                            register_elk_service)
+from elkm1_lib.const import AlarmState, ArmedStatus, ArmLevel, ArmUpState


This won't work. Requirement library names must only be imported within functions.

This does work. Is there a reason for importing only within functions?

I understand the normal reasoning (that things would crash if trying to import a library not yet installed by HASS as a dependency). In this case it won't cause that problem (though it breaks with the established pattern) since trying to load the component by itself probably fails terribly.

The alarm_control_panel.elkm1 (and light and so on) never get loaded unless they were loaded by the top-level elkm1 component being configured, which means the library must be installed, which makes this safe (even if not "how it's done").

Even if we made things get imported only in functions, you couldn't load alarm_control_panel by itself without configuring the elkm1 platform.

If we have to move those imports into functions it means a lot of repetitive imports. If we have to, we have to, it's just annoying and ugly (and maybe impacts performance, but I imagine that after the first import the repeats are nearly zero cost).

https://developers.home-assistant.io/docs/en/creating_platform_code_review.html#1-requirements

So what is established is:

There's a rule.

The rule doesn't take into account when a platform derives from a base that has a requirement.

The Elk alarm_control_panel has no REQUIREMENTS because the REQUIREMENTS are in the base.

The Elk base elkm1/__init__.py follows the rule because the code won't run if the rule isn't followed (and, yah, I stumbled on this and it took an hour to figure out).

What would have to happen to improve the rule?

The rule is there for a reason. We can't guard users from configuring a platform directly instead of the component. If the users would do that, there would be an error, since the platform is imported before the dependencies are loaded and requirements installed.

Thank-you. That helps.

MartinHjelmare · 2018-09-30T10:27:53Z

homeassistant/components/alarm_control_panel/elkm1.py

+
+DEPENDENCIES = [DOMAIN]
+
+STATE_ALARM_ARMED_VACATION = 'armed_vacation'


This isn't used.

MartinHjelmare · 2018-09-30T10:28:16Z

homeassistant/components/alarm_control_panel/elkm1.py

+DEPENDENCIES = [DOMAIN]
+
+STATE_ALARM_ARMED_VACATION = 'armed_vacation'
+STATE_ALARM_ARMED_HOME_INSTANT = 'armed_home_instant'


This isn't used.

MartinHjelmare · 2018-09-30T10:28:38Z

homeassistant/components/alarm_control_panel/elkm1.py

+
+STATE_ALARM_ARMED_VACATION = 'armed_vacation'
+STATE_ALARM_ARMED_HOME_INSTANT = 'armed_home_instant'
+STATE_ALARM_ARMED_NIGHT_INSTANT = 'armed_night_instant'


This isn't used.

The extra states aren't used yet because we couldn't use them on the old regular HASS UI, without them being added to polymer, etc.

We've been trying to hammer out what additional states are needed so we can get them added to HASS properly.

See home-assistant/architecture#54 for more on that, if you're curious.

MartinHjelmare · 2018-09-30T10:52:39Z

homeassistant/components/elkm1/__init__.py

+            'config']['temperature_unit'] == 'celsius' else TEMP_FAHRENHEIT
+        self._unique_id = platform + '.elkm1_' + \
+            self._element.default_name('_').lower()
+        self.entity_id = self._unique_id


Don't do this. The best thing is to let the core define the entity_id via the name property. If we need a specific entity_id, then define it properly using entity_id format imported from each base component, alarm_control_panel, light etc.

MartinHjelmare · 2018-09-30T10:53:24Z

homeassistant/components/elkm1/__init__.py

+        return self._unique_id
+
+    @property
+    def state(self):


Let each platform entity class define this.

Can you explain why?

Home assistant is built around base components that define base entity classes that define certain properties. Only some of those properties should be overwritten to complete the implementation. We want to keep the entity model strict for each component, so usually state is defined in the base component and then we let the subclass overwrite another property that is used in the state property. Keeping the model strict per entity gives a number of advantages. Eg being able to build a nice GUI.

I'm confused (still).

What I understand from the explanation is that the state property is defined in the base entity classes. So for example in switch/__init__.py is how I interpret that. I don't see the state property in that file. So, that can't be the meaning.

Continuing to use switch as the example, there's ElkSwitch(ElkDeviceBase, ToggleEntity) and ToggleEntity(Entity). Four classes to choose from. Right now I define the state property is defined in ElkDeviceBase. If I move the property to ElkSwitch, how does that provide an advantage?

The disadvantage is I define the exact same property ~10 times, once for each Elk entity type.

If nothing else, perhaps one thing that can come from this discussion is that a FAQ could be started with patterns such as mine. I can't see any other way of knowing a rule such as this one.

For a switch entity you should not overwrite the state property at all. This is handled by the base switch class, which extends ToggleEntity. You should overwrite is_on to define state for a switch entity. Different components have different requirements on properties and methods that should be overwritten. So when defining a general class that you want to reuse for multiple platforms, you should only have the common properties and methods that are not specific to any component in that class.

Please read our dev docs:
https://developers.home-assistant.io/docs/en/architecture_entities.html
https://developers.home-assistant.io/docs/en/entity_index.html
https://developers.home-assistant.io/docs/en/entity_switch.html

If you are interested in exactly how it all works, please read the source.

MartinHjelmare · 2018-09-30T10:54:45Z

homeassistant/components/elkm1/__init__.py

+        return False
+
+    @property
+    def hidden(self):


Probably don't use this. This is going away.

MartinHjelmare · 2018-09-30T10:55:26Z

homeassistant/components/elkm1/__init__.py

+        """The underlying element's attributes as a dict."""
+        attrs = {}
+        attrs['index'] = self._element.index + 1
+        attrs['state'] = self._state


Don't duplicate state in state attributes.

MartinHjelmare · 2018-09-30T10:59:08Z

homeassistant/components/elkm1/__init__.py

+        """Register callback for ElkM1 changes and update entity state."""
+        self._element.add_callback(self._element_callback)
+        self._element_callback(self._element, {})
+        self._hass.data[DOMAIN]['entities'][self.entity_id] = self


We are not allowed to store entities in a shared dictionary like this. Entities should only be accessed directly from within their respective platforms.

It's ok to store entities in each platform and also store the entity_ids separately in a shared dictionary in hass.data. Then use our dispatch helper to signal the entity methods.

See the tuya component and platforms for example.

Can you point me at the dispatch helper. I didn't see an example of that in tuya. I think all that I care about is that I can call an entity's method on a service call. If the dispatch helper will do that then I'm all good!

https://github.com/home-assistant/home-assistant/blob/dev/homeassistant/components/tuya.py#L102

https://github.com/home-assistant/home-assistant/blob/dev/homeassistant/components/tuya.py#L111

https://github.com/home-assistant/home-assistant/blob/dev/homeassistant/components/tuya.py#L129-L132

frenck · 2018-09-30T13:37:10Z

Could not find a related documentation PR. Added docs-missing label.

gwww · 2018-09-30T20:21:36Z

I appreciate the comments! I'm looking to be platinum :) so I'll be working to fix them all plus some :)

gwww · 2018-10-02T00:24:15Z

Checking, what is the protocol for using "Resolve conversation"? Do you click that when the comment has been resolved? Thx

MartinHjelmare · 2018-10-02T09:05:45Z

I prefer to let github automatically hide conversations when new commits are pushed that change the corresponding lines. Then I'll go through any remaining conversations and resolve them manually if they have been resolved.

MartinHjelmare · 2018-10-03T20:06:05Z

At this point it feels like we're arguing more than trying to get this PR merged. I'm happy to answer questions but defending the home assistant architecture is not what this PR review should be about. Please continue that discussion in the dev discord chat or in our architecture repo.

gwww · 2018-10-03T20:20:18Z

@MartinHjelmare You're right. I apologize. I'll do my best to make be better.

houndci-bot · 2018-10-06T04:12:39Z

homeassistant/components/elkm1/__init__.py

+    for item, max_ in configs.items():
+        config[item] = {}
+        (config[item]['enabled'], config[item]['included']) = \
+                parse_config(item, max_)


continuation line over-indented for visual indent

houndci-bot · 2018-10-06T04:12:40Z

homeassistant/components/elkm1/__init__.py

+    host = config_raw[CONF_HOST]
+    username = config_raw.get(CONF_USERNAME)
+    password = config_raw.get(CONF_PASSWORD)
+    if host.startswith('elks:') and (username is None or password is None): 


trailing whitespace

houndci-bot · 2018-10-06T04:12:40Z

homeassistant/components/elkm1/__init__.py

+    })
+}, extra=vol.ALLOW_EXTRA)
+
+SUPPORTED_DOMAINS = ['alarm_control_panel',]


missing whitespace after ','

gwww · 2018-10-06T04:23:50Z

I believe that I have address all comments except the voluptuous parsing. I don't know any way to do it differently given there is a dependance on elkm1_lib to properly parse. I did tune up code, changing error logs to vol.Invalid exceptions.

MartinHjelmare

Nice!

MartinHjelmare · 2018-10-06T10:39:39Z

homeassistant/components/alarm_control_panel/elkm1.py

+        }
+
+        if self._element.alarm_state is None:
+            self._state = STATE_UNKNOWN


Use None to represent unknown state. The base entity class will handle this and convert to the correct state name.

MartinHjelmare · 2018-10-06T10:54:03Z

homeassistant/components/alarm_control_panel/elkm1.py

+
+    for service in _arm_services():
+        hass.services.async_register(
+            ELK_DOMAIN, service, _arm_service, alarm.ALARM_SERVICE_SCHEMA)


We probably should register these services under the alarm_control_panel domain, and add the platform name as a prefix to the service name.

If a service is only relevant for a platform it probably should be registered under the domain of the platform. But let me know what you think. You know the integration best.

MartinHjelmare · 2018-10-06T10:54:21Z

homeassistant/components/alarm_control_panel/elkm1.py

+        async_dispatcher_send(hass, SIGNAL_DISPLAY_MESSAGE, *args)
+
+    hass.services.async_register(
+        ELK_DOMAIN, 'alarm_display_message',


MartinHjelmare · 2018-10-06T10:54:48Z

homeassistant/components/alarm_control_panel/elkm1.py

+        ELK_DOMAIN, 'alarm_display_message',
+        _display_message_service, DISPLAY_MESSAGE_SERVICE_SCHEMA)
+
+    return True


Nothing is checking this return value, so we can remove the statement.

MartinHjelmare · 2018-10-06T10:56:18Z

homeassistant/components/alarm_control_panel/elkm1.py

+        from elkm1_lib.const import ArmedStatus
+
+        ELK_STATE_TO_HASS_STATE = {
+            ArmedStatus.DISARMED.value:               STATE_ALARM_DISARMED,


We only use one whitespace after the colon.

MartinHjelmare · 2018-10-06T11:49:43Z

homeassistant/components/elkm1/__init__.py

+    host = config_raw[CONF_HOST]
+    username = config_raw.get(CONF_USERNAME)
+    password = config_raw.get(CONF_PASSWORD)
+    if host.startswith('elks:') and (username is None or password is None):


Move this check to the config validation schema. We can break it out into validator function.

Would love some help on this. I spent a couple of hours and could not figure out how to make voluptuous handle making something Required based on another value matching a pattern.

I looked as using Match to no avail.

Look at the persistence file validator in the mysensors component for example.

MartinHjelmare · 2018-10-06T11:54:01Z

homeassistant/components/elkm1/services.yaml

+      description: Up to 16 characters of text (truncated if too long). Default blank.
+      example: the universe, and everything.
+
+sensor_speak_word:


This isn't used.

MartinHjelmare · 2018-10-06T11:54:23Z

homeassistant/components/elkm1/services.yaml

+      description: Word number to speak.
+      example: 458
+
+sensor_speak_phrase:


This isn't used.

MartinHjelmare · 2018-10-06T11:59:15Z

homeassistant/components/elkm1/__init__.py

+    def parse_value(val, max_):
+        """Parse a value as an int or housecode."""
+        i = int(val) if val.isdigit() else (housecode_to_index(val) + 1)
+        if i < 1 or i > max_:


Can we use vol.Range instead?

No. The problem with using voluptuous for this bit of config is that I don't know max until my REQUIREMENT is loaded. Since REQUIREMENTS aren't loaded until after voluptuous is run I can't think of any way to use voluptuous.

I mean just replace the code here with a schema and use vol.Range in the schema, and call the schema with the values. Since we will need to catch a voluptuous error later anyway, it could fit nicely.

MartinHjelmare · 2018-10-06T12:01:59Z

homeassistant/components/elkm1/__init__.py

+    elk.connect()
+
+    hass.data[DOMAIN] = {'elk': elk, 'config': config,
+                         'entities': {}, 'keypads': {}}


Are we still using 'entities' and 'keypads' keys?

entities no.

keypads will be used as soon as the keypad sensor is submitted as a PR

MartinHjelmare · 2018-10-06T14:26:59Z

homeassistant/components/elkm1/__init__.py

+
+    def parse_value(val, max_):
+        """Parse a value as an int or housecode."""
+        i = int(val) if val.isdigit() else (housecode_to_index(val) + 1)


Break out housecode_to_index(val) + 1 into a validator function, is_housecode. Then do eg:

schema = vol.Schema(vol.Any(vol.Coerce(int), is_housecode)) val = schema(val)

Expand the schema as needed before using it.

MartinHjelmare · 2018-10-06T14:32:34Z

homeassistant/components/alarm_control_panel/elkm1.py

+        entity_ids = service.data.get(ATTR_ENTITY_ID, [])
+        arm_level = _arm_services().get(service.service)
+        code = service.data.get('code')
+        if arm_level and code:


This should be validated by the service schema. arm_level is always there since that's the name of the service. Make code required in the schema if that's needed.

MartinHjelmare · 2018-10-06T14:34:17Z

homeassistant/components/alarm_control_panel/elkm1.py

+        code = service.data.get('code')
+        if arm_level and code:
+            args = (entity_ids, arm_level, code)
+            async_dispatcher_send(hass, SIGNAL_ARM_ENTITY, *args)


Instead of signaling all entities, connect each entity to a specific signal by adding the entity_id to the signal string.

MartinHjelmare · 2018-10-06T14:34:48Z

homeassistant/components/alarm_control_panel/elkm1.py

+        for keypad in self._elk.keypads:
+            keypad.add_callback(self._watch_keypad)
+        async_dispatcher_connect(
+            self.hass, SIGNAL_ARM_ENTITY, self._arm_service)


MartinHjelmare · 2018-10-06T14:35:42Z

homeassistant/components/alarm_control_panel/elkm1.py

+
+    async def _arm_service(self, entity_ids, arm_level, code):
+        if self.entity_id in entity_ids:
+            self._element.arm(arm_level, int(code))


Move integer copy to service schema.

MartinHjelmare · 2018-10-06T14:39:09Z

homeassistant/components/elkm1/__init__.py

+    host = config_raw[CONF_HOST]
+    username = config_raw.get(CONF_USERNAME)
+    password = config_raw.get(CONF_PASSWORD)
+    if host.startswith('elks:') and (username is None or password is None):


Look at the persistence file validator in the mysensors component for example.

gwww · 2018-10-06T16:14:36Z

Still can't figure out the elks:// using voluptuous.

I want the config to be either:

host: elks://foo
username: bar
password: baz

Or

host: elk://foo

I cannot find a way to get first one to work where username/password are required for elks://

homeassistant/components/elkm1/__init__.py

MartinHjelmare · 2018-10-07T17:23:47Z

homeassistant/components/elkm1/__init__.py

+                raise vol.Invalid("Invalid range {}".format(rng))
+            values[rng[0]-1:rng[1]] = [set_to] * (rng[1] - rng[0] + 1)
+
+    conf = hass_config.get(DOMAIN)


conf = hass_config[DOMAIN]

MartinHjelmare · 2018-10-07T17:27:43Z

homeassistant/components/elkm1/__init__.py

+
+    for item, max_ in configs.items():
+        config[item] = {'enabled': conf[item][CONF_ENABLED],
+                        'included': [len(conf[item]['include']) == 0] * max_}


{ ..., 'included': [not conf[item]['include']] * max_, }

MartinHjelmare · 2018-10-07T18:22:02Z

homeassistant/components/elkm1/services.yaml

@@ -0,0 +1,53 @@
+# Describes the format for available ElkM1 alarm control panel services
+
+elkm1_alarm_arm_vacation:


Move these to the alarm control panel services.yaml.

MartinHjelmare

Nice!

I think the config parsing is hard to follow, but I don't have a better suggestion at the moment.

Can be merged when docs PR is linked and build passes.

gwww · 2018-10-07T18:31:45Z

Thank you.

gwww · 2018-10-07T18:52:42Z

home-assistant/home-assistant.io#6587

gwww · 2018-10-07T19:05:06Z

You should probably remote the climate, light, switch, and sensor labels. Those PRs coming real soon now.

Add support for ElkM1 alarm/automation panel.

881d3ea

homeassistant added new-platform platform: alarm_control_panel.elkm1 integration: elkm1 cla-signed labels Sep 28, 2018

ghost added the in progress label Sep 28, 2018

houndci-bot reviewed Sep 28, 2018

View reviewed changes

homeassistant/components/light/elkm1.py Outdated Show resolved Hide resolved

homeassistant/components/light/elkm1.py Outdated Show resolved Hide resolved

fix lines too long

2d9f094

MartinHjelmare requested changes Sep 30, 2018

View reviewed changes

frenck added the docs-missing label Sep 30, 2018

Address PR comments

e882ea9

houndci-bot reviewed Oct 6, 2018

View reviewed changes

Fix hound ci errors

4cf93a8

MartinHjelmare reviewed Oct 6, 2018

View reviewed changes

Glenn Waters added 2 commits October 6, 2018 09:20

Changes for PR comments

a4046bf

Use vol.Range for checking range value

bc308c6

MartinHjelmare reviewed Oct 6, 2018

View reviewed changes

Address PR comments

1d38a2b

MartinHjelmare reviewed Oct 7, 2018

View reviewed changes

homeassistant/components/elkm1/__init__.py Show resolved Hide resolved

Add housecode converter

12f359d

MartinHjelmare reviewed Oct 7, 2018

View reviewed changes

Glenn Waters added 2 commits October 7, 2018 14:06

fix PR comments

3b5adf8

fix syntax error

a59f4d8

home-assistant deleted a comment from houndci-bot Oct 7, 2018

MartinHjelmare reviewed Oct 7, 2018

View reviewed changes

Fix PR comment

a3e3bb9

MartinHjelmare approved these changes Oct 7, 2018

View reviewed changes

MartinHjelmare removed the docs-missing label Oct 7, 2018

MartinHjelmare removed platform: climate.elkm1 labels Oct 7, 2018

home-assistant deleted a comment from houndci-bot Oct 7, 2018

MartinHjelmare changed the title ~~Add support for ElkM1 alarm/automation panel.~~ Add support for ElkM1 alarm/automation panel Oct 7, 2018

MartinHjelmare merged commit 06a64c0 into home-assistant:dev Oct 7, 2018

ghost removed the in progress label Oct 7, 2018

gwww deleted the elkm1 branch October 7, 2018 19:47

This was referenced Oct 7, 2018

Add Elk-M1 home-assistant/home-assistant.io#6587

Merged

Add Elk-M1 switch and scene platforms #17256

Merged

Add Elk-M1 sensor platform documentation home-assistant/home-assistant.io#6705

Merged

Add Elk-M1 sensor platform #17342

Merged

balloob mentioned this pull request Oct 26, 2018

0.81 #17809

Merged

home-assistant locked and limited conversation to collaborators Feb 5, 2019

ghost removed the platform: alarm_control_panel.elkm1 label Mar 21, 2019


		DEPENDENCIES = [DOMAIN]

		STATE_ALARM_ARMED_VACATION = 'armed_vacation'

		@@ -0,0 +1,53 @@
		# Describes the format for available ElkM1 alarm control panel services

		elkm1_alarm_arm_vacation:

Add support for ElkM1 alarm/automation panel #16952

Add support for ElkM1 alarm/automation panel #16952

Conversation

gwww commented Sep 28, 2018 • edited by MartinHjelmare Loading

Description:

Example entry for configuration.yaml (if applicable):

Checklist:

MartinHjelmare left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

MartinHjelmare Oct 3, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

MartinHjelmare Oct 2, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

frenck commented Sep 30, 2018

gwww commented Sep 30, 2018

gwww commented Oct 2, 2018

MartinHjelmare commented Oct 2, 2018

MartinHjelmare commented Oct 3, 2018

gwww commented Oct 3, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gwww commented Oct 6, 2018

MartinHjelmare left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

MartinHjelmare Oct 6, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gwww Oct 6, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

MartinHjelmare Oct 6, 2018 • edited Loading

Choose a reason for hiding this comment

MartinHjelmare Oct 6, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gwww commented Oct 6, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

MartinHjelmare left a comment

Choose a reason for hiding this comment

gwww commented Oct 7, 2018

gwww commented Oct 7, 2018

gwww commented Oct 7, 2018

gwww commented Sep 28, 2018 •

edited by MartinHjelmare

Loading

Example entry for `configuration.yaml` (if applicable):

MartinHjelmare Oct 3, 2018 •

edited

Loading

MartinHjelmare Oct 2, 2018 •

edited

Loading

MartinHjelmare Oct 6, 2018 •

edited

Loading

gwww Oct 6, 2018 •

edited

Loading

MartinHjelmare Oct 6, 2018 •

edited

Loading

MartinHjelmare Oct 6, 2018 •

edited

Loading