Skip to content

Home

Jump to bottom
Johann Richard edited this page Dec 5, 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.

Caveats

There's a breaking change for blinds between the version v1.x.x and v2.x.x of this plugin which unfortunately could not be avoided. If you have a dingz with blinds (and only then), you must remove these dingz from HomeBridge and add them again (With the excellent homebridge-config-ui-x plugin/package, you can do this in a comfortable way from the UI: You can choose to remove individual cached accessories).

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 (By default in PUSH Mode. POLLER Mode is now deprecated, might be removed in the future)
  • Buttons (StatelessProgrammableSwitch), including a stealthy flip-switch mode

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.

Configuration changes (dingz only)

Initially, the plugin attempts to create the dynamic accessories based on the dingz configuration. Keeping up with configuration changes once a dingz has been added to HomeKit has become increasingly challenging and error prone. New features in the firmware and a mixed hardware and software-defined configuration (DIP switch and UI settings) can change physical properties of your dingz.

This applies to the following configurable properties:

  • DIP switch changes (changing blinds to dimmers and vice-versa),
  • D1/I1 output/input setting,
  • `not_conected outputs (a software setting, see #114,

Changing these can lead to stale services (e.g. leftover lamps, leftover dimmers or blinds) if the configuration is somehow not tracked properly. Considering this, right now, the best way to deal with these configuration changes is therefore:

  • to remove the dingz accessory from the accessory cache,
  • restart homebridge, which will add the accessory again, with the new configuration

As a physical change is probably quite unlikely to happen many times (adding blinds, adding inputs, removing lights etc.), it is safe to say that this approach is probably the most effective way to deal with that.

While there still is some code dealing with different hardware configuration settings, these parts will eventually be removed for good.

myStrom Devices

Currently, the following myStrom Devices are supported by 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