KNX addon question

WebThings
#1

Hi, guys,
I play with the hub since several days and I’m pretty excited of the ideas behind and how much traction it gains now. Honestly speaking, I was working on a similar project, but nothing close to this scale. Anyways, in short - I have a full-blown KNX system in my home and I would like to try build a KNX addon. However, KNX is not yet another IoT toy, at least not in the meaning of “off-the-shelf” kind of IoT product with predefined functionality. There’s no device discovery mechanism in KNX, so I can’t just find and add available KNX devices (furthermore, there could be logical devices that are different from physical devices). Devices must be manually specified and configured somehow in UI. I see that you’ve just added a JSON SCHEMA for addon config description, using input fields, dropdowns, checkboxes, etc. I think something like that should do the job for a manual device description too.

My question is - have you thought about such cases, where user needs to manually define a new device? KNX is the perfect example of such a case. Another is e.g. “MySensors”, but there are many more out there.

#2

I think addon-config is available for define a new device.
Users can add and configure devices by using the following schme.
You can test here.

{
  "definitions": {
    "KNX": {
      "type": "object",
      "properties": {
        "name": {
          "type": "string",
          "default": "knx"
        },
        "property1": {
          "type": "string"
        },
        "property2": {
          "type": "string"
        }
      }
    }
  },
  "type": "object",
  "properties": {
    "devices": {
      "type": "array",
      "title": "KNX devices",
      "items": {
        "$ref": "#/definitions/KNX"
      }
    }
  }
}

Is there any case that this method can not support? Considering the different properties set by device type, we may need to support JSON-SCHEMA dependencies.

#3

Thanks for the answer. But I can’t figure out where in the UI this kind of JSON SCHEMA is rendered? And I can’t find the HTTP endpoint used for adding a new manually defined device. Can you give me a cURL example of how such a request should look like?

#4

How to access configuration UI.

  • First step
    Update to the latest on github.

  • Second step
    Add schema to package.json on your add-on.

  "moziot": {
    "api": {
      "min": 2,
      "max": 2
    },
    "enabled": true,
    "schema": {
      "definitions": {
        "KNX": {
          "type": "object",
          "properties": {
            "name": {
              "type": "string",
              "default": "knx"
            },
            "property1": {
              "type": "string"
            },
            "property2": {
              "type": "string"
            }
          }
        }
      },
      "type": "object",
      "properties": {
        "devices": {
          "type": "array",
          "title": "KNX devices",
          "items": {
            "$ref": "#/definitions/KNX"
          }
        }
      }
    }
  • Third step
    Access Gateway > Settings > add-ons > your addon > Configure.

If configure on form and click apply button, add-on will be restarted with the new config given.

function loadYourAddon(addonManager, manifest, _errorCallback) {
  const config = manifest.moziot.config;  // this contains the value set in the UI.
}

module.exports = loadYourAddon;
#5

Thanks, I will try that.
But this is for addon config, not device config. What I’m interested in is applying the same logic, but for device manual configuration. In KNX world we don’t have device discovery. User must define manually a virtual device with so called Group Addresses (GA). There is usually one GA for READ and another for WRITE of each property. So, imagine we have a virtual KNX device that is a dimmable light and it has a property “on” and “level”. We need to render on UI 4 fields for user to enter Group Addresses - READ and WRITE fields for the “on” property and READ and WRITE fields for the “level” one.

The way I see it is to introduce a list of predefined virtual devices like JSON SCHEMA descriptions. E.g. like “light switch”, “dimmable light”, “roller shutter”, “thermostat”, “binary sensor”, etc. User selects one of these predefined devices and then UI renders READ and WRITE fields (there could be only READ or only WRITE) for each property of that device. User writes GAs in those fields and saves that as a new device in the gateway.

#6

I think that setting device type and GA in addon config and configuring the device using it.
It can be realized with the following code.

class YourAdapter extends Adapter {
  constructor(addonManager, manifest) {
    super(addonManager, 'your-addon-id', manifest.name);
    this.manager.addAdapter(this);

    const config = manifest.moziot.config;
    if (config && config.devices && Array.isArray(config.devices)) {
      const devices = config.devices;
      devices.forEach(function (device) {
        switch (device.type) {
          case 'dimmableLight':
            const onREAD = device.on.READ;
            const onWRITE = device.on.WRITE;
            // create your device
            this.handleDeviceAdded(yourNewDevice);
            break;
          case 'onOffLight':
            /////
            break;
        }

      }.bind(this));
    }
  }
}

function loadYourAddon(addonManager, manifest, _errorCallback) {
  const config = manifest.moziot.config;  // this contains the value set in the UI.
  new YourAdapter(addonManager, manifest);
}

module.exports = loadYourAddon;

Do you have any problem with this method?

#7

As I understand, your idea is to use addon config UI to actually add devices? I’m not sure this is gonna play well at the end. Imagine we could have 100 devices, each one having ~5 properties. And we can’t just render some 1 000 fields in the config page, there should be UI controls for adding, editing and deleting of devices.

#8

Who is this “we” intending?

If addon developer, it is easy to render 1000 fields in the config page.
JSON-SCHEMA of array type provides variable length input fields that can be added and deleted. The addon user hit 100 add buttons and the fields for 100 devices will be rendered.
In order to realize this, addon developer has to write a few dozen lines of schema.

If you are intending addon user, are you interested in usability?
How do you want to improve usability by dividing the configuration for each device?
Since I am not familiar with KNX, as I imagined, is not it usability good to input GA’s pattern instead of setting 100 individual device config?
In here it seems that GA address is set based on several patterns.

#9

Hi, “we” = developer(s). :slight_smile:

KNX GA addresses could be based on anything that makes sense for the particular installation. There’s no any tech related limitation. Yes, there are some common patterns, like structure by rooms and structure by functions, but in the end the installer has the full freedom to structure it the way it makes sense for the project. Anyways, GAs are just the unique ID that identifies some READ or WRITE address for a property, and from gateway point of view it totally doesn’t matter what it is.

I see your point about JSON-SCHEMA. I played with arrays and add/remove items here. However I was hoped we could introduce things dedicated setting page or something, where we could have a unified way of adding devices that don’t support discovery. And have a unified way to see all (discovered and manually added) devices, search them, filter them, hide/show them, delete them. IMHO from UX point of view that would be the best approach.

#10

Thank you for detailed explanation. I understood your idea!

This means that it is more intuitive for the user to inform that setting is necessary after adding the device rather than setting the addon to add the device, right?
This way is not currently available. Also, this has an alternative method (addon configuration that is not intuitive).

I think that such a UI is a good idea. There is no way to do this at the moment, let’s create an issue on github.

#11

Yes, the whole point is about UX. Device related config should be on device related page, not on addon page. On addon config page we have another config stuff, like in the KNX case, the addon config JSON SCHEMA would contain 2 fields - gateway IP and gateway port. That’s it. On addon config page we are not interested in KNX devices, only in KNX gateway.

So, if we introduce a “devices” or “things” settings page where users can manually add or discover devices, that would be the logically right place for devices to be manually configured.

#12

P.S. Furthermore, we really need per-device config even for discoverable devices. For example all Z-Wave door locks implement a security pass code config. There are e.g. 256 pass key slots and user needs to set/get a passkey there. So we have a discoverable Z-Wave device, but it needs some manual config in order to work at all. Additionally we may have some more Z-Wave related stuff, like device associations or Device Parameters. All these are not “command & control” related and should not be rendered by the UI as thing properties and be on the floorplan, but these are device configs by nature.

#13

Hi, sogaani,
will you create an issue in github, as you suggested, or I should? I would really like to bring up a discussion about that topic. IMHO the gateway can’t be a fully functional without such functionality. You can read the use cases I gave earlier here.

#14

HI, mishoboss.
I suggested the per-device config here
https://github.com/mozilla-iot/gateway/issues/668.
I will develop the use case on KNX-add-on, and write more details in above issue.
Could you subscribe the issue and join a discussion?

#15

Thanks, subscribed and will follow it.
You mean that you will implement a fully functional KNX-add-on, or you will just use the KNX use case for describing the per-device config? If a KNX-add-on is in your plans, I highly suggest to use this module: https://www.npmjs.com/package/knx
It is a pure JS implementation and very well maintained.

#16

I will only implement the per-device config.
I hope for you to develop KNX-add-on and make a feedback.

#17

OK, sure. I have a KNX system in home, as well as experience with the KNX module I mentioned above, so it won’t be hard for me to do a plugin. If per-device config provides all tools needed to config and register a new KNX device.