Modbus bit_switch and bit_sensor implementation by yury-sannikov · Pull Request #47240 · home-assistant/core

yury-sannikov · 2021-03-01T19:47:27Z

Breaking change

This PR adds new functionality and should not introduce any breaking changes.
❗ This PR is based on the @janiversen PR #46591

Proposed change

bit_switch allows mapping Modbus holding register bits to a HomeAssistant Switch. All switch operations such as on, off, and toggle works against individual bits of a Modbus holding register. You may use the Modbus input register as well, however, a switch will remain read-only.

bit_sensor is pretty similar to the bit_switch. However, with the bit_sensor you are not limited to 16bit Modbus register length. You may specify any arbitrary count and specify the bit number of the interest.

Since multiple sensors or switches can read from the same Modbus register, a functools.lru_cache caching was added to cache Modbus register for one second. This should be enough to avoid re-reads. Any write operation to any of the registers reset the cache.

Type of change

Dependency upgrade
Bugfix (non-breaking change which fixes an issue)
New integration (thank you!)
New feature (which adds functionality to an existing integration)
Breaking change (fix/feature causing existing functionality to break)
Code quality improvements to existing code or addition of tests

Example entry for `configuration.yaml`:

# Example configuration.yaml
modbus:
  - name: powermain
    type: tcp
    host: 192.168.5.222
    port: 2020
    sensors:
      - name: pwrmain_input_status
        slave: 16
        address: 512
        input_type: holding
    bit_switches:
      - name: pwrmain_shut_off_secondary_ups_load
        slave: 16
        address: 516
        command_bit_number: 0
      - name: pwrmain_airconditioneer_feed_from_solar_invertor
        slave: 16
        address: 516
        command_bit_number: 1
    bit_sensors:
      - name: pwrmain_main_feed_under_over_voltage
        slave: 16
        address: 514
        bit_number: 1
      - name: pwrmain_controller_fault_watchdog_took_over
        slave: 16
        address: 514
        bit_number: 2
      - name: pwrmain_main_feed_phase_order_error
        slave: 16
        address: 514
        bit_number: 6
      - name: pwrmain_watchdog_failure
        slave: 16
        address: 514
        bit_number: 7
      - name: pwrmain_emergency_feed_outage
        slave: 16
        address: 514
        bit_number: 10
      - name: pwrmain_reserve_feed_outage
        slave: 16
        address: 514
        bit_number: 11

Additional information

This PR fixes or closes issue: fixes #
This PR is related to issue:
Link to documentation pull request:
Modbus bit sensor switch home-assistant.io#16831

Checklist

The code change is tested and works locally.
Local tests pass. Your PR cannot be merged unless tests pass
There is no commented out code in this PR.
I have followed the development checklist
The code has been formatted using Black (black --fast homeassistant tests)
Tests have been added to verify that the new code works.

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

Documentation added/updated for www.home-assistant.io

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

The manifest file has all fields filled out correctly.
Updated and included derived files by running: python3 -m script.hassfest.
New or updated dependencies have been added to requirements_all.txt.
Updated by running python3 -m script.gen_requirements_all.
Untested files have been added to .coveragerc.

The integration reached or maintains the following Integration Quality Scale:

No score or internal
🥈 Silver
🥇 Gold
🏆 Platinum

To help with the load of incoming pull requests:

I have reviewed two other open pull requests in this repository.

probot-home-assistant · 2021-03-01T19:49:53Z

Hey there @adamchengtkc, @janiversen, @vzahradnik, mind taking a look at this pull request as its been labeled with an integration (modbus) you are listed as a codeowner for? Thanks!
_{^{(message by CodeOwnersMention)}}

yury-sannikov · 2021-03-01T19:50:04Z

cc @nagyrobi

janiversen · 2021-03-02T08:23:50Z

Look good from a first view, I will go into detail a bit later

yury-sannikov · 2021-03-02T08:58:26Z

Cool, then I will start working on the documentation PR. lmk if you feel we can use better names

janiversen · 2021-03-02T09:17:43Z

Remark I have an open PR for documentation as well, yours should extend my PR.

yury-sannikov · 2021-03-03T17:49:19Z

Documentation PR has been added based on the home-assistant/home-assistant.io#16678 PR

janiversen · 2021-03-07T18:33:50Z

Hi I wanted to do a proper review, but for some reason I cannot exclude my PR so I review only your changes. As soon as my PR is merged (just waiting for a maintainer to do it), then I swiftly review your PR.

I have downloaded it too, and it works on my Mac.

janiversen

Your changes in sensor/switch needs some more thinking. I like the idea of a base class.

janiversen · 2021-03-10T14:27:48Z



+@lru_cache(maxsize=32)
+def _read_cached(client, what, unit, address, count, ttl_bucket):


I really do not see the need for this added complexity, it does not seem to make your bit implementation easier, and it complicates the rest. I suggest to remove the lru_cache part (unless you have some good arguments, why not).

If I have a configuration where each sensor/switch has the same address (in the case below it's 514) I have N read calls of the same Modbus register to the Modbus Client. If I have 16 sensors attached to the same address, the integration will end up with 16 reads of the same value through the Modbus.

This read cache holds the first read value for one second. This helps avoid making sequential calls. We can remove the cache, however, then we will be making the same read calls multiple times. This is not a big deal, however, may slow down updates.

The cache protects from multiple reads only during one update cycle and should be empty on the next cycle, which ensures by the 1 second expiration time.

bit_sensors: - name: pwrmain_main_feed_under_over_voltage slave: 16 address: 514 bit_number: 1 - name: pwrmain_controller_fault_watchdog_took_over slave: 16 address: 514 bit_number: 2 - name: pwrmain_main_feed_phase_order_error slave: 16 address: 514 bit_number: 6

Since Modbus device is a black box, we can't assume that the cache will be valid for a longer period of time. That's why I picked one second.
Also, any write to the Modbus invalidates the cache. This might be unnecessary though because the next read cycle will start not earlier than a second later and the cache won't hit anyway.

Your use case is a bit different than the normal ones, normally you would just read the 16bits in one go, and then split them. What I do not like here is that you force the cache on all read, and I am not so sure it is a good idea.

What you could easily do is make a bit_sensor.py, and in that file have special handling for the update call. E.g. you group the sensors (according to the bit pattern), the update call to the first sensor reads physically and either stores the value for the other sensors or updates all sensors. Update call to all other sensors are dummies.

Good idea. Let me think about how to do that. I will revert _read_cached changes

janiversen · 2021-03-10T14:49:31Z

+    read_result = (
+        ReadResult(register_words)
+        if register_words
+        else ModbusException("Modbus error")


you are testing the test setup ?

Nope, I just want to emulate a disconnected state, when the read_* call throws an exception. I found a bug in my code and decided to add a test for that as well.

Ahhh that is a good idea, I like that.

janiversen

Second part of review. I have downloaded your PR, to isolate your changes, making it a bit harder to review, but I wanted to give you some feedback.

janiversen · 2021-03-10T14:50:44Z

    ), mock.patch(
        "homeassistant.components.modbus.modbus.ModbusUdpClient", return_value=mock_sync
+    ), mock.patch(
+        "homeassistant.components.modbus.modbus._read_cached", return_value=read_result


But your cache is in our source, I am patching pymodbus, because I want to test the code we have in the read functions.

hm, not sure why you need to patch pymodbus to make it work. read_cached basically wraps all read* calls, that's why I removed the code with the ReadResult below.

janiversen · 2021-03-10T14:53:03Z

    check_config_only=False,
    config_modbus=None,
    scan_interval=None,
+    **kvargs,


I like that you have added test for write, but it should be done properly, with named parameters.

Ok, make sense

janiversen · 2021-03-10T15:08:08Z

        entity_id = f"{entity_domain}.{device_name}"
+
+        # Call an arbitrary service
+        if "call_service" in kvargs:


Looks like you are allowing both a read and a write test in the same call, the idea of this function is one call pr test.

Yeah, this test design might be confusing. Let me rethink it based on the cache decision

janiversen · 2021-03-10T15:09:56Z

+        # check write_register call
+        if "write_register" in kvargs:
+            args, kvargs = kvargs["write_register"]
+            mock_sync.write_register.assert_called_once_with(*args, **kvargs)


We should check that the values sent to pymodbus (bytes) correspond the to the parameters in the original call (which could be e.g. STATE_ON).

janiversen · 2021-03-10T15:13:43Z

+            STATE_OFF,
+            SERVICE_TURN_ON,
+            # 0x40 yields OFF state due to the status bit 5
+            # however, SERVICE_TURN_ON enables bit 6 which make bit untouched


nice comment !!

yeah, except 0x40 and 0x41, lol

yury-sannikov · 2021-03-10T18:10:27Z

@janiversen thank you for the review. I will make changes a bit later this week. The main takeaways are:

remove _read_cached in favor of some sort of read manager handling the sequential reads
keep non bit_sensor/bit_switch read logic as-is
refactor unit tests to roll back _read_cached changes
refactor unit tests to split state check, service call, and asserts on the Modbus write_ calls.
create separate bit_sensor/bit_switch.py files
lmk if I missed anything.

janiversen · 2021-03-10T18:14:23Z

I think those are the big thing, once that is done I will look at it all again

Your idea of having a base sensor class is very good, please keep that.

yury-sannikov · 2021-03-13T11:56:41Z

Hi @janiversen. I think I addressed all the issues except extracting bit_sensor and bit_switch into their own files. That will require extracting the base classes into their own separate files which may increase the complexity of understanding the code.
Also, I separated the read cache from the others. Only bit sensor/switch uses it right now.

janiversen · 2021-03-13T15:05:53Z

ok, I will take a look, but it might be a couple of days until I get some free time

janiversen · 2021-03-28T06:35:59Z

The modbus integration have changed on dev, so you need to do:

git pull on the dev branch
git rebase dev on your pr branch
git push -f on your pr branch
once done I will do a review

yury-sannikov · 2021-03-30T10:11:37Z

                )
        except ConnectionException:
            self._available = False
+            self.schedule_update_ha_state()


w/o this, the state would be STATE_UNKNOWN instead of STATE_UNAVAILABLE. Added tests as well.

Please be aware your PR is about bit_sensor, so please only add changes to that respect.

yury-sannikov · 2021-03-30T10:12:45Z

+    ):
+        """Initialize the modbus bit sensor."""
+        super().__init__(
+            ModbusReadCache(hub),


Only bit switch/sensor uses read cache as a wrapper. Regular sensors/switches would not use read cache.

OK. Before you start doing changes, please make sure your branch is rebased against dev, so that this PR only contain your changes (also no merge commits), in order to facilitate review.

Regarding the cache, we are currently thinking about a different more general way. You instanciate an object of each bit_sensor configured, but an alternative it is modbus.py to have 2 classes one with the real read and one with a virtual read (reusing the first read). That way you would instanciate the first bit_sensor with the real class (reading modbus) and the following with the second class. The reason we are thinking of this, is that we often see a configuration that read address, +1, +2 ..... and that like your bit_sensor is overload.

janiversen

You have a ton of good code, but there are 2 general issues:

it seems (maybe wrongly) that you have moved code around, that is tricky
a number of your changes are not related to bit_sensor/bit_switch
Avoiding those 2 would make review a lot easier and you would have approval a lot faster.

janiversen · 2021-03-30T10:56:12Z

        vol.Optional(CONF_STATE_OFF): cv.positive_int,
        vol.Optional(CONF_STATE_ON): cv.positive_int,
        vol.Optional(CONF_VERIFY_REGISTER): cv.positive_int,
+        vol.Optional(CONF_VERIFY_STATE, default=True): cv.boolean,


Why are you adding this, is that needed for your bit_sensor implementation ?

Yep, I will remove it

janiversen · 2021-03-30T10:59:35Z

@@ -0,0 +1,26 @@
+"""Read cache wrapper for the Modbus Hub methods."""


This is something local to bit_sensor / bit_switch so at least the file name is wrong. I would prefer you put this content in bit_sensor, and imported it in bit_switch.

janiversen · 2021-03-30T11:00:42Z

    CALL_TYPE_REGISTER_HOLDING,
    CALL_TYPE_REGISTER_INPUT,
+    CONF_BIT_NUMBER,
+    CONF_BIT_SENSORS,


This seems to belong in bit_sensor.py

janiversen · 2021-03-30T11:01:29Z

        config = None

-    for entry in discovery_info[CONF_SENSORS]:
+    for entry in discovery_info.get(CONF_BIT_SENSORS, []):


Please do not mix sensor with bit_sensor !

Please see my comment https://github.com/home-assistant/core/pull/47240/files#r604390837

janiversen · 2021-03-30T11:03:25Z


-class ModbusRegisterSensor(RestoreEntity, SensorEntity):
-    """Modbus register sensor."""
+class ModbusSensorBase(RestoreEntity, SensorEntity):


Are you sure that we should not have 2 base on for register and one for coil ?

janiversen · 2021-03-30T11:17:02Z

+    sensor_name = "test_sensor"
+    config_sensor = {CONF_NAME: sensor_name, CONF_ADDRESS: 51, CONF_BIT_NUMBER: 5}
+    if do_options:
+        config_sensor.update(


Please see in the other test files. if/else in the test cases are to be avoided

looks like it's common practice
https://github.com/home-assistant/core/blob/dev/tests/components/modbus/test_modbus_sensor.py#L46
https://github.com/home-assistant/core/blob/dev/tests/components/modbus/test_modbus_switch.py#L62

That is old standard, as I noted somewhere else...when you present new code, maintainers look with the present standards. I was asked to remove specifically the “if do_options” in my last PR (and it do make sense). This is a good example why not to move old code.

When I get time, I will change all tests to follow this new pattern.

Oh, cool. Sorry, that's my first PR to the HA, I might not know all the rules

janiversen · 2021-03-30T11:17:35Z

+    array_type = None
+    device_config[CONF_ADDRESS] = 1234
+
+    if do_options:


janiversen · 2021-03-30T11:19:35Z

@@ -0,0 +1,91 @@
+"""Test modbus read cache."""


This should be part of the bit_sensor / bit_switch test, we do not want to caching generally.

nagyrobi · 2021-04-01T14:57:16Z

Will this affect the coils as switches in any aspect?
Any improvement can be done perhaps to read the states in one go?
As far as I can see, on my 24-relay card, each coil state is being read one by one. Whilst with the standard, all of them could be read in one go.

janiversen · 2021-04-01T15:17:49Z

@nagyrobi sounds likeyour problem is more what I described in issue #48497 which are in development

yury-sannikov · 2021-04-02T10:59:38Z

hi @janiversen
I created a pretty simple PR out of the dev branch which shows the issue I have with the bit_sensor. My goal is to make tests to work against the new bit_sensor. What I see is that async_setup_platform is never called.
Could you please take a quick look at the https://github.com/yury-sannikov/core/pull/2/files PR. You might spot the issue I'm fighting for a long time. Thank you!

janiversen · 2021-04-02T17:34:18Z

you are basically missing to update modbus.py (the loop that calls all platforms under modbus). I have added some review comments.

yury-sannikov · 2021-04-02T19:09:17Z

Thanks for pointing out it. I added suggested changes to the test PR and I'm getting the error I had before:

ERROR:homeassistant.setup:Setup failed for bit_sensor: Integration not found.

This happens when I add (CONF_BIT_SENSOR, CONF_BIT_SENSORS), to the list for the load_platform

If I do (CONF_BINARY_SENSOR, CONF_BIT_SENSORS) instead, binary_sendor integration initialized instead of bit_sensor.

That's why I think there are only 2 ways to hook into:

add bit_sensor code into binary_senor async_setup_platform fn
set up a bit_sensor integration (which I feel is an overkill)

I'm looking for the third approach, which I'm struggling to find out.

janiversen · 2021-04-02T19:47:47Z

have a look at pr #48558 a fan is also no standard.

yury-sannikov · 2021-04-03T13:43:11Z

@janiversen, unfortunately, a fan is a standard domain https://github.com/home-assistant/core/blob/dev/homeassistant/components/fan/manifest.json

yury-sannikov · 2021-04-05T07:46:18Z

Any suggestions on how can I go ahead with this PR for the non-standard domain (senor and switch)?

janiversen · 2021-04-05T08:42:59Z

For a non-standard domain you need to ask in the developer forum or use discord. But I still do not see why you continue trying to make a non-standard domain.

What you try to do looks like a specialised version of binary_sensor and switch (as I have written earlier). If you cannot trix HA to call you directly (load_component) then 1 single "if" in setup() of binary_sensor.py and switch.py is all that are needed to call you setup and do what you like (well and of course import a function from your file(s)), no need to make things more complicated.

One of the problems I have had reviewing your PR is all your changes in the existing code, causing me to wonder why they are need in order to add a specialised binary_sensor/switch. A clear implementation without all the other stuff is easier to review and easier to guide you on.

Apart from that, your changes in existing code are in conflict with dev, please rebase without merge.

janiversen · 2021-04-05T08:57:46Z

Specific example:

from <yourfile> import <your setup func>

def async_setup_platform(
...
   for entry in ......
       if <your_key> in entry
           <your setup func>
          return

you can do it this simple, and without touching other parts of the existing code.

yury-sannikov · 2021-04-05T09:00:44Z

Oh, cool, that makes sense now. I thought I'm not allowed to do any changes in the binary_sensor.py and switch.py. If I can hook into it like #47240 (comment) I think I'm good now. Thank you!

janiversen · 2021-04-09T10:08:19Z

are you aware that you have changes in 12 files? that sound like overkill for what you want to implement.

may I suggest you do “git rebase” and squash the commit so you have only a few where you easier check which files are changed.

When your PR get merged the maintainer will squash all commits into one, but keep the commit message from every commit.

yury-sannikov · 2021-04-09T10:50:43Z

Squashed into one commit. I would appreciate it if you can guide me on how can I reduce the number of changed files. I might be missing something.

janiversen · 2021-04-09T11:55:26Z

If you say it is all needed changes, then you cannot reduce the number and at least you have removed 2 files. It looks to as if your changes to conftest.py does not really matter.

I see you are still using "sensor" as base, but as I understand it bit_sensor can return true/false, that is the definition of binary_sensor. I wonder if you will get problems with Lovelace when forcing a sensor (not binary_sensor) to only be true/false.

I see you have introduced your own setup which is good, but I think your code have an unintended sideeffect. For a bit_sensor your setup is called to add the sensor, but then the sensor code continues with the same discovery_info, meaning it is added a second time. (this was just a quick look, I might have overlooked something).

yury-sannikov · 2021-04-09T18:49:11Z

I see you are still using "sensor" as base, but as I understand it bit_sensor can return true/false, that is the definition of binary_sensor. I wonder if you will get problems with Lovelace when forcing a sensor (not binary_sensor) to only be true/false.

Right, forgot about you mentioned it earlier. Let me fix it a bit later.

I see you have introduced your own setup which is good, but I think your code have an unintended sideeffect. For a bit_sensor your setup is called to add the sensor, but then the sensor code continues with the same discovery_info, meaning it is added a second time. (this was just a quick look, I might have overlooked something).

bit_sensor uses discovery_info.get(CONF_BIT_SENSORS, []) and sensor use discovery_info.get(CONF_SENSORS, []) Should be no dupes even if both setup_bit_sensors and the code after it adds the sensors

yury-sannikov · 2021-04-16T11:44:19Z

Hi @janiversen
I believe I addressed all the issues. I checked the code against my hardware setup and it's working as expected. If you have some time, could you pls do another round of review?

janiversen · 2021-04-16T19:16:32Z

2 general items:

please update the description the PR you refer is merged.
please update the doc. PR as frenck requested a while ago.

janiversen

I have not looked too closely at your test cases, it seems to me you are redefining the test harness we use for other platforms, and that makes the code a lot harder to read.

janiversen · 2021-04-16T19:21:30Z

        config = None

-    for entry in discovery_info[CONF_BINARY_SENSORS]:
+    sensors.extend(setup_bit_sensors(hass, discovery_info))


This needs at very least a comment. Reading this code, it looks as if you first extend sensors with bit-sensors and the continue with the normal sensors.

janiversen · 2021-04-16T19:41:33Z

-    for entry in discovery_info[CONF_BINARY_SENSORS]:
+    sensors.extend(setup_bit_sensors(hass, discovery_info))
+
+    for entry in discovery_info.get(CONF_BINARY_SENSORS, []):


Why change to info.get ? That is not a needed change.

janiversen · 2021-04-16T19:43:02Z

+import logging
+import time
+
+from pymodbus.exceptions import ConnectionException, ModbusException


There are no need to check for ConnectionException it is also a ModbusException.

janiversen · 2021-04-16T19:44:08Z

+import time
+
+from pymodbus.exceptions import ConnectionException, ModbusException
+from pymodbus.pdu import ExceptionResponse


You only need to check for ModbusException. Which btw is something which are currently being removed in all platforms, I have a PR pending merge for that.

janiversen · 2021-04-16T19:47:35Z

+_LOGGER = logging.getLogger(__name__)
+
+
+@lru_cache(maxsize=32)


If you limit to 32, then you should also check that no more than 32 are used.

janiversen · 2021-04-16T20:29:46Z

    array_name_discovery,
    array_name_old_config,
-    register_words,
+    register_words_or_exception,


Please do not change the test methods in a PR where you implement new functionality. In case of problems it is quite hard to determine whether it is the new functionaliy or the test changes.

janiversen · 2021-04-16T20:30:16Z

        }

    mock_sync = mock.MagicMock()
+    # Setup inputs for the sensor


?? This is not just for a sensor.

janiversen · 2021-04-16T20:31:42Z

+            register_words_or_exception
+            if isinstance(register_words_or_exception, Exception)
+            else ReadResult(register_words_or_exception)
+        )


This is a good idea, but we do not want to test pymodbus in every platform, that is the responsibiliy and thus testing of modbus.py.

It's not a Modbus test, it's a negative case testing wish Modbus integration lack of, unfortuately

janiversen · 2021-04-16T20:32:08Z

            async_fire_time_changed(hass, now)
            await hass.async_block_till_done()

-        # Check state


Why remove this comment ?

janiversen · 2021-04-16T20:35:40Z

+        ),
+    ],
+)
+@mock.patch.object(ModbusHub, "read_holding_registers")


There are a standard function in conftest you should use.

yury-sannikov · 2021-04-17T19:22:15Z

Most of the review comments do not make much sense to me. Not sure I will ever be able to make it to conform to the controversial suggestions here. Feel free to use some portions of the code for further development of the platform. I will focus my energy on more meaningful things. Thanks for your time.

homeassistant added the cla-signed label Mar 1, 2021

probot-home-assistant Bot added has-tests integration: modbus new-feature labels Mar 1, 2021

yury-sannikov mentioned this pull request Mar 3, 2021

Modbus bit sensor switch home-assistant/home-assistant.io#16831

Closed

8 tasks

janiversen requested changes Mar 10, 2021

View reviewed changes

janiversen reviewed Mar 10, 2021

View reviewed changes

janiversen requested changes Mar 10, 2021

View reviewed changes

yury-sannikov force-pushed the jan_based_bin_sensor branch 2 times, most recently from d84828a to e0eb8d0 Compare March 10, 2021 18:38

yury-sannikov mentioned this pull request Mar 16, 2021

Modbus TCP Server (Modbus TCP Slave) implementation #47994

Closed

20 tasks

yury-sannikov force-pushed the jan_based_bin_sensor branch from b2bd5e9 to 1ec7bb4 Compare March 30, 2021 10:01

yury-sannikov commented Mar 30, 2021

View reviewed changes

janiversen requested changes Mar 30, 2021

View reviewed changes

Comment thread tests/components/modbus/test_modbus.py Outdated

yury-sannikov force-pushed the jan_based_bin_sensor branch from 7026a65 to 9952081 Compare April 9, 2021 08:51

yury-sannikov force-pushed the jan_based_bin_sensor branch from 43d23c3 to e95cb0b Compare April 9, 2021 10:45

implemend bit_switch and bit_sensor

c9a3b6f

yury-sannikov force-pushed the jan_based_bin_sensor branch from 5df256f to c9a3b6f Compare April 16, 2021 10:41

janiversen requested changes Apr 16, 2021

View reviewed changes

yury-sannikov closed this Apr 17, 2021

github-actions Bot locked and limited conversation to collaborators Apr 18, 2021



		@lru_cache(maxsize=32)
		def _read_cached(client, what, unit, address, count, ttl_bucket):

		@@ -0,0 +1,26 @@
		"""Read cache wrapper for the Modbus Hub methods."""

Uh oh!

Conversation

yury-sannikov commented Mar 1, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Breaking change

Proposed change

Type of change

Example entry for configuration.yaml:

Additional information

Checklist

Uh oh!

probot-home-assistant Bot commented Mar 1, 2021

Uh oh!

yury-sannikov commented Mar 1, 2021

Uh oh!

janiversen commented Mar 2, 2021

Uh oh!

yury-sannikov commented Mar 2, 2021

Uh oh!

janiversen commented Mar 2, 2021

Uh oh!

yury-sannikov commented Mar 3, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

janiversen commented Mar 7, 2021

Uh oh!

janiversen left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

yury-sannikov Mar 10, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

janiversen left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

yury-sannikov commented Mar 10, 2021

Uh oh!

janiversen commented Mar 10, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

yury-sannikov commented Mar 1, 2021 •

edited

Loading

Example entry for `configuration.yaml`:

yury-sannikov commented Mar 3, 2021 •

edited

Loading

yury-sannikov Mar 10, 2021 •

edited

Loading

janiversen commented Mar 10, 2021 •

edited

Loading