Skip to content

Home

Jump to bottom
Johann Richard edited this page Nov 12, 2020 · 27 revisions

This plugin implements some (but not all) functions of dingz Smart Home Devices. The plugin also supports (some) myStrom Devices as they share much of the same API definitions and concepts with dingz.

dingz Devices

The plugin attempts to

  • auto-discover devices, and to
  • auto-identify dingz settings and thus accessories by using device type, dip switch settings and input configuration

The following dingz services are implemented:

  • Dimmers (LightBulb) & Non-Dimmable Lights
  • Shades (Blinds)
  • Room temperature (Temperature)
  • Front LED (LightBulb)
  • Light Sensor
  • Motion sensor status
  • Buttons (StatelessProgrammableSwitch), including a stealthy flip-switch mode
  • Motion sensor webhook (push mode instead of polling)

Not (yet) implemented:

  • Thermostat (Temperature)

Dimmers and Blinds

dingz supports different output modes, set with a DIP switch. The plugin supports all possible configurations. If you change this configuration of your dingz, then the Accessory must be initialised again to pick-up these settings correctly. If you use the Config UI X (highly recommended) plugin, you can simply remove the cached dingzZ accessories via the 'Homebridge Settings' menu. This will only break the accessories and automations related to the accessories you clear but will leave the remaining accessories intact.

Otherwise, either remove and re-add the plugin and the config in Homebridge or completely reinitialise the Accessory cache in Homebridge. The former will remove all devices added via the plugin only (incl. myStrom). The latter will also remove/reinitialise all other devices configured with any other plugin, and you will have to reconfigure all Accessories, Automations and Scenes in HomeKit again -- so be careful when using this option.

Dimmer and Non-dimmable lights

dingz outputs support dimmable and non-dimmable outputs alike with a user-configurable setting. The HomeKit accessories added with this plugin will follow this setting, even if you change it after you've added it to HomeKit. Non-dimmable outputs will be displayed as simple switchable lights whereas dimmed outputs will have a brightness setting.

Device Names

dingz outputs can has a custom name assigned. The HomeKit accessories added with this plugin will follow this too. If you change the name in dingz (and haven't manually changed the name in HomeKit before), your device will be renamed in HomeKit, too. Beware that this is a one-way street: Changing the name in HomeKit won't change anything in your dingz.

myStrom Devices

My original homebridge-myStrom plugin was written a while ago. HomeKit, Homebridge and the JavaScript/TypeScript world have all come a long way since then. Since the dingz devices share a similar approach to auto-dsicovery and API with myStrom Devices, it is in fact quite simple to implement basic support for myStrom Devices.

Currently, the following myStrom Devices are implemented in this plugin:

  • myStrom WiFi Switch CH V1 (tested, must be manually added)
  • myStrom WiFi Switch CH V2 (tested, w/ auto-discovery)
  • myStrom WiFi Switch EU (untested, should work with auto-discovery too)
  • myStrom WiFi Lightbulb (tested, w/ auto-discovery)
  • myStrom WiFi Button (tested, with restriction, and only the simple WiFi Button right now)
  • myStrom WiFi Motion Sensor (suggested and tested by @qx54)

Auto-discovery & Auto-configuration

Auto-discovery on your local network will run for 10 minutes after you've started HomeBridge. Auto-configuration will check your dingz every so often for changes in Names, Output settings etc. If you add new devices, just restart HomeBridge and they should magically show up in your HomeKit.

Usage

Easy: Install and configure the plugin via Config UI X. This is the recommended and supported way as it ensures your config has the correct syntax.

Harder: Install the plugin manually and configure it directly via the Homebridge config file:

npm install -g homebridge-dingz

Add a "dingz" platform block to your Homebridge config (under platforms)

"platforms": [

  {
      "name": "dingz SmartHome Devices",
      "platform": "dingz",
      "globalToken": "74ccbf570f4b4be09d37b7ff4ea03954551f9263"
  }
]

Note: The globalToken is only required if you've set a REST API Token which is shared by all dingz you own.

If your dingz Devices reside on a separate subnet than your Homebridge installation and/or use different REST API tokens each, then add the devices manually or via Config UI X.

  "platforms": [
    {
        "name": "dingz SmartHome Devices",
        "platform": "dingz",
        "globalToken": "74ccbf570f4b4be09d37b7ff4ea03954551f9263",
        "devices": [
            {
              "name": "dingz SmartHome Device #1",
              "address": "ip or address",
              "type": "dingz"
            }
        ]
    }
  ]

Rationale

Q: myStrom devices and dingz (eventually) support HomeKit directly, so why should I use that plugin?

A: There are a number of scenarios where using HomeBridge and this plugin with your Smart Home devices might be advisable. For example, you might want to put all IoT devices on a separate VLAN, both securing them and your other devices in case of security issues. With HomeKit alone, this quickly becomes a multicast nightmare -- with this plugin, you simply make the smart devices accessible for your HomeBridge device. You could for example isolate all IoT Devices in their VLAN from each other and only allow trusted devices from other subnets to access the dingz and myStrom REST API.

And wit auto-discovery integrated in any running Homebridge installation, the setup of new dingz and myStrom is dead easy: Connect them to your WiFi and let the plugin figure out anything.

Clone this wiki locally