johannrichard / homebridge-dingz Goto Github PK

Describe the bug
mystrom app reports the temperature, one, 2nd one reports 0.

To Reproduce
install two mystrom v2 power plugs

Expected behavior
get real temperature of 2nd one

Ordered a myStrom motion sensor because I thought motion sensors are supported. Only now realized, this didn't apply to the myStrom devices, only to the Dingz devices.

Any plans for adding myStrom motion sensor support to the plugin?

Thanks

Generally speaking, any configuration change that modifies the physical setup of a dingz (i.e. DIP Switch changes, but also the Input / Output change of I1/D1) potentially requires that the accessory is removed and added again to Homebridge.

Some points to consider:

• We could update the dingz based on all configuration changes (i.e. remove and add services as we see fit); however
• changing from dimmers to blinds and back requires physical re-wiring; therefore
• an argument could be made that physical changes require drastic changes in HomeKit

Questions:

• What is best practice?
• What makes sense?

This plugin generated a warning from the characteristic 'Current Horizontal Tilt Angle': characteristic was supplied illegal value: number 100 exceeded maximum of 90. See https://git.io/JtMGR for more info.

The internal dingzStates representation is currently typeless. On the other hand, we have a DingzState interface that covers most of this representation. We should therefore bring these to definitions together and fold the dingzStates private property into the DingzState type.

Describe the enhancement
A dingz knows two different blind/lamella modes. This should be represented and accounted for in the code.

Examples and context
If lamella mode is enabled, a tilt angle can be set. If it is disabled, no tilt should be possible.

Describe the enhancement
Update the plugin to account for changes in the dingz FW API when getting/setting the tilt angle.

Examples and context

• The dingz firmware v1.1 used different values to set and get the lamella tilt angle (° vs %). The current code accounts for this
• The dingz firmware v1.2consitently uses percentages, which is incompatible with the way the v1.1 firmware handles this

Additional context
See #119 for a discussion why this fix is needed and why it might eventually introduce breaking changes for dingz with older firmwares.

Describe the bug
Since installing 2.0.x I get following errors in the log

[11/30/2020, 2:00:05 PM] [dingz] [dingz Küche] ALIVE (192.168.227.12)
[11/30/2020, 2:00:10 PM] [dingz] [dingz Küche] ALIVE (192.168.227.12)
[11/30/2020, 2:00:15 PM] [dingz] [dingz Küche] ALIVE (192.168.227.12)
[11/30/2020, 2:00:20 PM] [dingz] [dingz Küche] ALIVE (192.168.227.12)
[11/30/2020, 2:00:25 PM] [dingz] [dingz Küche] ALIVE (192.168.227.12)
[11/30/2020, 2:00:30 PM] [dingz] [dingz Küche] ALIVE (192.168.227.12)
[11/30/2020, 2:00:30 PM] [dingz] [dingz Küche] Error: timeout of 3000ms exceeded (GET http://192.168.227.12/api/v1/state)
[11/30/2020, 2:00:30 PM] [dingz] [dingz Küche] HTTP ECONNABORTED Connection aborted --> 192.168.227.12
[11/30/2020, 2:00:30 PM] [dingz] [dingz Küche] Error -> unable to fetch DeviceMotion data DeviceNotReachableError DeviceNotReachableError: Device can not be reached -> dingz Küche-> 192.168.227.12
[11/30/2020, 2:00:31 PM] [dingz] [dingz Küche] Device --> recovered from unreachable state (192.168.227.12)
[11/30/2020, 2:00:35 PM] [dingz] [dingz Küche] ALIVE (192.168.227.12)
[11/30/2020, 2:00:40 PM] [dingz] [dingz Küche] ALIVE (192.168.227.12)
[11/30/2020, 2:00:45 PM] [dingz] [dingz Küche] ALIVE (192.168.227.12)

To Reproduce
Install 2.0.4 and check log

Describe the bug
With the DIP=1 setup and the Dimmers D1 & D2 set to not_connected, one dimmer shows up anyway.

To Reproduce
Steps to reproduce the behaviour:

1. Set DIP=1
2. Set both Dimmers to not_connected
3. Restart homebridge
4. Single Dimmer shows up (D1/I1)

Expected behaviour
No Dimmer shows up

Originally posted by @granturism0 in #139 (comment)

When the config is updated with a new hostname/IP, we’re not currently updating the accessory as the plugin stops the update without this being checked.

We should (also) check for updates in the hostname/80 to cater for changes these.

Describe the bug
The following piece of code is triggered when updateDimmerState is called for dimmers when "starting up". In that case, state is null/undefined. The current if/else is a workaround that should be fixed by properly checking whether we want to update a dimmer that's in fact configured as a blind motor.

To Reproduce

• Use two dimmers as a blind
• Observe the log

Expected behavior

• No error / plugin-killig

Thank you so much for this implementation. I was able to add Dingz to Homebridge (via Config UI) but it seems like the dip-Switches are not recognized correctly. The dip switches are both set to 'light' but Dingz is shown as a 'Window Covering' device in HomeKit.

Furthermore this is what is shown in the log:
[5/14/2020, 3:54:29 PM] [Dingz] Error: SyntaxError: Unexpected end of JSON input at JSON.parse (<anonymous>) at /homebridge/node_modules/homebridge-dingz/node_modules/servie/src/node.ts:104:39 at processTicksAndRejections (internal/process/task_queues.js:97:5) at DingzDaHomebridgePlatform.fetch (/homebridge/node_modules/homebridge-dingz/src/platform.ts:500:25) at DingzDaAccessory.getWindowCovering (/homebridge/node_modules/homebridge-dingz/src/dingzDaAccessory.ts:1005:19)

HomeBridge (using it for hue and Sonos) is running inside a docking container on a Synology NAS.

Describe the enhancement
The updateAccessory() method of the dingz accessory needs refactoring:

• integrate updating of the Accessory metadata (FW, Serial, Name etc.)
• call DingzEvent.UPDATE_INFO to initiate an accessory Update
• untangle some of the intertwined code snippets that doe (almost) the same thing e.g. in getDingzDeviceInfo() and platform.getDingzDeviceInfo

Examples and context

Describe the bug
Typo in changelog

To Reproduce
Install plugin update, read changelog 🤓

Screenshots

I see ETIMEDOUT intermittently in the log. Don't see any issue on my network leading to this.

[5/25/2020, 5:54:58 PM] [dingz] Update accessory -> Check for changed config.
[5/25/2020, 6:25:30 PM] [dingz] Update accessory -> Check for changed config.
[5/25/2020, 7:22:28 PM] [dingz] Update accessory -> Check for changed config.
[5/25/2020, 8:22:28 PM] [dingz] Update accessory -> Check for changed config.
[5/25/2020, 9:22:28 PM] [dingz] Update accessory -> Check for changed config.
[5/25/2020, 9:55:51 PM] [Sonos] Studio Sonos: get Remaining Duration return 0s
[5/25/2020, 10:22:28 PM] [dingz] Update accessory -> Check for changed config.
[5/25/2020, 11:22:28 PM] [dingz] Update accessory -> Check for changed config.
[5/26/2020, 12:22:28 AM] [dingz] Update accessory -> Check for changed config.
[5/26/2020, 1:22:28 AM] [dingz] Update accessory -> Check for changed config.
[5/26/2020, 2:04:45 AM] [dingz] Error: Error: connect ETIMEDOUT 192.168.227.12:80
    at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1141:16) {
  errno: 'ETIMEDOUT',
  code: 'ETIMEDOUT',
  syscall: 'connect',
  address: '192.168.227.12',
  port: 80,
  config: {
    url: 'http://192.168.227.12/api/v1/motion',
    method: 'get',
    headers: {
      Accept: 'application/json, text/plain, */*',
      Token: '',
      'User-Agent': 'axios/0.19.2'
    },
    transformRequest: [ [Function: transformRequest] ],
    transformResponse: [ [Function: transformResponse] ],
    timeout: 0,
    adapter: [Function: httpAdapter],
    xsrfCookieName: 'XSRF-TOKEN',
    xsrfHeaderName: 'X-XSRF-TOKEN',
    maxContentLength: -1,
    validateStatus: [Function: validateStatus],
    data: undefined
  },
  request: Writable {
    _writableState: WritableState {
      objectMode: false,
      highWaterMark: 16384,
      finalCalled: false,
      needDrain: false,
      ending: false,
      ended: false,
      finished: false,
      destroyed: false,
      decodeStrings: true,
      defaultEncoding: 'utf8',
      length: 0,
      writing: false,
      corked: 0,
      sync: true,
      bufferProcessing: false,
      onwrite: [Function: bound onwrite],
      writecb: null,
      writelen: 0,
      afterWriteTickInfo: null,
      bufferedRequest: null,
      lastBufferedRequest: null,
      pendingcb: 0,
      prefinished: false,
      errorEmitted: false,
      emitClose: true,
      autoDestroy: false,
      bufferedRequestCount: 0,
      corkedRequestsFree: [Object]
    },
    writable: true,
    _events: [Object: null prototype] {
      response: [Function: handleResponse],
      error: [Function: handleRequestError]
    },
    _eventsCount: 2,
    _maxListeners: undefined,
    _options: {
      protocol: 'http:',
      maxRedirects: 21,
      maxBodyLength: 10485760,
      path: '/api/v1/motion',
      method: 'GET',
      headers: [Object],
      agent: undefined,
      agents: [Object],
      auth: undefined,
      hostname: '192.168.227.12',
      port: null,
      nativeProtocols: [Object],
      pathname: '/api/v1/motion'
    },
    _redirectCount: 0,
    _redirects: [],
    _requestBodyLength: 0,
    _requestBodyBuffers: [],
    _onNativeResponse: [Function],
    _currentRequest: ClientRequest {
      _events: [Object: null prototype],
      _eventsCount: 6,
      _maxListeners: undefined,
      outputData: [],
      outputSize: 0,
      writable: true,
      _last: true,
      chunkedEncoding: false,
      shouldKeepAlive: false,
      useChunkedEncodingByDefault: false,
      sendDate: false,
      _removedConnection: false,
      _removedContLen: false,
      _removedTE: false,
      _contentLength: 0,
      _hasBody: true,
      _trailer: '',
      finished: true,
      _headerSent: true,
      socket: [Socket],
      connection: [Socket],
      _header: 'GET /api/v1/motion HTTP/1.1\r\n' +
        'Accept: application/json, text/plain, */*\r\n' +
        'Token: \r\n' +
        'User-Agent: axios/0.19.2\r\n' +
        'Host: 192.168.227.12\r\n' +
        'Connection: close\r\n' +
        '\r\n',
      _onPendingData: [Function: noopPendingOutput],
      agent: [Agent],
      socketPath: undefined,
      method: 'GET',
      insecureHTTPParser: undefined,
      path: '/api/v1/motion',
      _ended: false,
      res: null,
      aborted: false,
      timeoutCb: null,
      upgradeOrConnect: false,
      parser: null,
      maxHeadersCount: null,
      reusedSocket: false,
      _redirectable: [Circular],
      [Symbol(kCapture)]: false,
      [Symbol(kNeedDrain)]: false,
      [Symbol(corked)]: 0,
      [Symbol(kOutHeaders)]: [Object: null prototype]
    },
    _currentUrl: 'http://192.168.227.12/api/v1/motion',
    [Symbol(kCapture)]: false
  },
  response: undefined,
  isAxiosError: true,
  toJSON: [Function]
}
(node:2635) UnhandledPromiseRejectionWarning: TypeError: Cannot read property 'success' of undefined
    at /homebridge/node_modules/homebridge-dingz/src/dingzAccessory.ts:862:20
    at runMicrotasks (<anonymous>)
    at processTicksAndRejections (internal/process/task_queues.js:97:5)
(node:2635) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 2)
(node:2635) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
[5/26/2020, 2:22:29 AM] [dingz] Update accessory -> Check for changed config.
[5/26/2020, 3:22:29 AM] [dingz] Update accessory -> Check for changed config.
[5/26/2020, 4:22:29 AM] [dingz] Update accessory -> Check for changed config.
[5/26/2020, 5:22:29 AM] [dingz] Update accessory -> Check for changed config.
[5/26/2020, 6:04:37 AM] [dingz] Error: Error: connect ETIMEDOUT 192.168.227.12:80
    at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1141:16) {
  errno: 'ETIMEDOUT',
  code: 'ETIMEDOUT',
  syscall: 'connect',
  address: '192.168.227.12',
  port: 80,
  config: {
    url: 'http://192.168.227.12/api/v1/motion',
    method: 'get',
    headers: {
      Accept: 'application/json, text/plain, */*',
      Token: '',
      'User-Agent': 'axios/0.19.2'
    },
    transformRequest: [ [Function: transformRequest] ],
    transformResponse: [ [Function: transformResponse] ],
    timeout: 0,
    adapter: [Function: httpAdapter],
    xsrfCookieName: 'XSRF-TOKEN',
    xsrfHeaderName: 'X-XSRF-TOKEN',
    maxContentLength: -1,
    validateStatus: [Function: validateStatus],
    data: undefined
  },
  request: Writable {
    _writableState: WritableState {
      objectMode: false,
      highWaterMark: 16384,
      finalCalled: false,
      needDrain: false,
      ending: false,
      ended: false,
      finished: false,
      destroyed: false,
      decodeStrings: true,
      defaultEncoding: 'utf8',
      length: 0,
      writing: false,
      corked: 0,
      sync: true,
      bufferProcessing: false,
      onwrite: [Function: bound onwrite],
      writecb: null,
      writelen: 0,
      afterWriteTickInfo: null,
      bufferedRequest: null,
      lastBufferedRequest: null,
      pendingcb: 0,
      prefinished: false,
      errorEmitted: false,
      emitClose: true,
      autoDestroy: false,
      bufferedRequestCount: 0,
      corkedRequestsFree: [Object]
    },
    writable: true,
    _events: [Object: null prototype] {
      response: [Function: handleResponse],
      error: [Function: handleRequestError]
    },
    _eventsCount: 2,
    _maxListeners: undefined,
    _options: {
      protocol: 'http:',
      maxRedirects: 21,
      maxBodyLength: 10485760,
      path: '/api/v1/motion',
      method: 'GET',
      headers: [Object],
      agent: undefined,
      agents: [Object],
      auth: undefined,
      hostname: '192.168.227.12',
      port: null,
      nativeProtocols: [Object],
      pathname: '/api/v1/motion'
    },
    _redirectCount: 0,
    _redirects: [],
    _requestBodyLength: 0,
    _requestBodyBuffers: [],
    _onNativeResponse: [Function],
    _currentRequest: ClientRequest {
      _events: [Object: null prototype],
      _eventsCount: 6,
      _maxListeners: undefined,
      outputData: [],
      outputSize: 0,
      writable: true,
      _last: true,
      chunkedEncoding: false,
      shouldKeepAlive: false,
      useChunkedEncodingByDefault: false,
      sendDate: false,
      _removedConnection: false,
      _removedContLen: false,
      _removedTE: false,
      _contentLength: 0,
      _hasBody: true,
      _trailer: '',
      finished: true,
      _headerSent: true,
      socket: [Socket],
      connection: [Socket],
      _header: 'GET /api/v1/motion HTTP/1.1\r\n' +
        'Accept: application/json, text/plain, */*\r\n' +
        'Token: \r\n' +
        'User-Agent: axios/0.19.2\r\n' +
        'Host: 192.168.227.12\r\n' +
        'Connection: close\r\n' +
        '\r\n',
      _onPendingData: [Function: noopPendingOutput],
      agent: [Agent],
      socketPath: undefined,
      method: 'GET',
      insecureHTTPParser: undefined,
      path: '/api/v1/motion',
      _ended: false,
      res: null,
      aborted: false,
      timeoutCb: null,
      upgradeOrConnect: false,
      parser: null,
      maxHeadersCount: null,
      reusedSocket: false,
      _redirectable: [Circular],
      [Symbol(kCapture)]: false,
      [Symbol(kNeedDrain)]: false,
      [Symbol(corked)]: 0,
      [Symbol(kOutHeaders)]: [Object: null prototype]
    },
    _currentUrl: 'http://192.168.227.12/api/v1/motion',
    [Symbol(kCapture)]: false
  },
  response: undefined,
  isAxiosError: true,
  toJSON: [Function]
}
(node:2635) UnhandledPromiseRejectionWarning: TypeError: Cannot read property 'success' of undefined
    at /homebridge/node_modules/homebridge-dingz/src/dingzAccessory.ts:862:20
    at runMicrotasks (<anonymous>)
    at processTicksAndRejections (internal/process/task_queues.js:97:5)
(node:2635) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 4)
[5/26/2020, 6:22:29 AM] [dingz] Update accessory -> Check for changed config.
[5/26/2020, 7:22:29 AM] [dingz] Update accessory -> Check for changed config.

Describe the bug
If an output/dimmer of a dingz has been visible in HomeKit and is subsequently set to not_connected(implemented via #114), it will not disappear from HomeKit.

To Reproduce

1. Addd dingz to HomeKit with at least one Dimmer enabled
2. Once it is running, remove the Dimmer in dingz by setting it to not_connected in the UI
3. The Dimmer will remain in HomeKit and even survive the restart of HomeBridge

Expected behavior
A Dimmer that is set to not_connected shall be removed from HomeKit (similar to the input / output switch handling)

Plugin environment (please complete the following information):

• dingz/myStrom Device Firmware Version 1.2.x
• Plugin Version: 1.8.0
• Node.js Version 14.14.0
• Homebridge Version 1.1.6

For inspiration, this is what needs to be done if an output is set to not_connected:

Hello @johannrichard
unfortunately the blinds do not work after version 3.0. With version 3.0 everything works great and in 3.1.2 they no longer work.
When I press the button for the blinds on the Apple Home nothing happens anymore. The switches still work though....
I have also removed everything and reinitialized, but without success.
Can you please take a look at this and I will thus go back to version 3.0.
Best regards
@granturism0

Describe the bug
Found more places where 'DingZ' instead of 'dingz' is used.

To Reproduce
Use Config UI X to configure dingz service

Plugin environment (please complete the following information):

• Plugin Version [e.g. 1.5.1]
  Screenshots

Describe the bug

If a device (PIR, dingz, button) can not be reached when the plug-in starts, the callbacks will not reliably be set, even if the device recovers later on.

To Reproduce

• Configure device normally,
• Remove (unplug) it from the network,
• Restart plugin,
• Add device again,
• Callback url is not necessarily set

Expected behavior

• Callback will be checked and set when the device recovers

Just saw following in HB log:

[5/25/2020, 5:19:35 PM] [dingz] Update accessory -> Check for changed config.
[5/25/2020, 5:21:08 PM] [dingz] Update accessory -> Check for changed config.
[5/25/2020, 5:24:45 PM] [dingz] Update accessory -> Check for changed config.
[5/25/2020, 5:27:53 PM] [dingz] Update accessory -> Check for changed config.
[5/25/2020, 5:37:15 PM] [dingz] Update accessory -> Check for changed config.
(node:2635) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 set listeners added to [Characteristic]. Use emitter.setMaxListeners() to increase limit
(node:2635) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 set listeners added to [Characteristic]. Use emitter.setMaxListeners() to increase limit
(node:2635) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 set listeners added to [Characteristic]. Use emitter.setMaxListeners() to increase limit
[5/25/2020, 5:54:58 PM] [dingz] Update accessory -> Check for changed config.
[5/25/2020, 6:25:30 PM] [dingz] Update accessory -> Check for changed config.
[5/25/2020, 7:22:28 PM] [dingz] Update accessory -> Check for changed config.
[5/25/2020, 8:22:28 PM] [dingz] Update accessory -> Check for changed config.
[5/25/2020, 9:22:28 PM] [dingz] Update accessory -> Check for changed config.

Describe the bug
Temperature and light don't get updated in Homebridge and Home app anymore, although http://<PIR-IP>/api/v1/sensors shows up-to-date temperature and light values.

To Reproduce
Steps to reproduce the behavior:

1. In the Homebridge GUI navigate to Accessories
2. Light will have an old value
3. Open http://<PIR-IP>/api/v1/sensors in browser
4. Light value will be different, but correct

Expected behavior
The light and temperature values in Homebridge should have the same values as the ones provided by the API.

Plugin environment:

• myStrom PIR Firmware Version: 3.8.2
• Homebridge Server: Raspberry Pi 4
• Plugin Version: 1.8.0
• Node.js Version: 14.15.1
• Homebridge Version: 1.1.6

Additional context
The issue appears only after some time. Upon re-starting Homebridge it works again, but will stop working after a couple of hours.

When installing your plugin v.1.2.1 isn't pulled. Latest version is shown as 1.2.0

Describe the enhancement
Each dingz can be configured with its proper name. We don't use this when discovering / Adding dingz, though.

Examples and context
Identifying dingz would be much easier (if properly set up)

How does the ALIVE check for the MyStrom buttons work?

They're undead. ☺️ Right now, the call to getDeviceStateUpdate() always resolves the promise and thus they're ALIVE. I have plans to change that to UNKNOWN at some point as we just don't know their state, but it was not highest priority anyway (since it's merely a heartbeat and status indicator in the logs).

Good observation though. ☺️😊

Originally posted by @qx54 @johannrichard in #139 (comment)

Hoobs stops randomly, please see the log file. Basically this happens after a Dingz button was pressed in order to close or open the shutter.

The log file is full of messages like this:

[21.04.21, 18:49] [HOOBS ABCD@Storen Büro@Motor rechts@Current Horizontal Tilt Angle] characteristic was supplied illegal value: number 100 exceeded maximum of 90

Randomly the server shuts down after such a message:

[21.04.21, 18:49] [dingz and myStrom SmartHome platform] [ACTION] Button ::ffff:192.168.1.235 (6/1)

[21.04.21, 18:49] Got SIGTERM, shutting down Bridge...

[21.04.21, 18:49] [HOOBS ABCD@Storen Wohnzimmer@Motor rechts@Current Horizontal Tilt Angle] characteristic was supplied illegal value: number 100 exceeded maximum of 90

[21.04.21, 18:49] [HOOBS ABCD@Storen Büro@Motor rechts@Current Horizontal Tilt Angle] characteristic was supplied illegal value: number 100 exceeded maximum of 90

[21.04.21, 18:49] [dingz and myStrom SmartHome platform] Process ended, socket destroyed

Plugin environment

• dingz Firmware Version Front 1.2.7
• dingz Firmware Version Base1.1.21
• Homebridge Version 3.3.5
• Homebridge UI X Version [e.g.4.37.0]
• Homebridge Server: Raspberry
• Plugin Version 3.1.6

Hoobs log file.rtfd.zip

Not sure what this is but showed up after I cleared all cached devices in HB:

[11/30/2020, 9:50:02 PM] [dingz] [dingz Küche] Adding output devices for  192.168.227.12  -> [...]
HAP Warning: Characteristic 00000074-0000-1000-8000-0026BB765291 not in required or optional characteristics for service 00000089-0000-1000-8000-0026BB765291. Adding anyway.
HAP Warning: Characteristic 00000074-0000-1000-8000-0026BB765291 not in required or optional characteristics for service 00000089-0000-1000-8000-0026BB765291. Adding anyway.
HAP Warning: Characteristic 00000074-0000-1000-8000-0026BB765291 not in required or optional characteristics for service 00000089-0000-1000-8000-0026BB765291. Adding anyway.
HAP Warning: Characteristic 00000074-0000-1000-8000-0026BB765291 not in required or optional characteristics for service 00000089-0000-1000-8000-0026BB765291. Adding anyway.

Hello @johannrichard
I have just discovered another bug (in version 2.0.1) in relation to the tilt angle.
For example, if I have the blinds at 50% and set the tilt angle of the blinds to 0 degrees (TargetHorizontalTiltAngle = 0), then the blinds will go up completely (also to position 0).
So the angles of the slats somehow also control the blinds in terms of height.

Describe the feature requested
Most devices from myStrom don't let the user set a name directly on the device. In Order to make them more recognisable (and in line with their own naming), we should use the MAC address (or parts thereof) when setting the name in HomeKit.

Examples and context

e.g. a myStrom-Switch-F00BAD would be named the same or myStrom Switch F00BAD.

Alternatively, the host name could be resolved and if something meaningful is returned, could be used.

E.g. kitchen.my.local would be named Kitchen.

Change DingzDa to Dingz

[11/30/2020, 9:32:05 PM] [dingz] [dingz Küche] Identify! -> Who am I? I am a DingzDaAccessory listeting to the name of dingz Küche a.k.a. dingz Küche -> MAC: 246F28161968

Describe the bug
Typo in HB>Config>Hostname / IP to use for button callback

Screenshots

Describe the enhancement
The callback URL for motion is currently always set, even if no PIR sensor is installed in a dingz. It would be more precise to only set this when a PIR sensor is indeed installed. It does not break anything but is a small glitch in the code that can be fixed.

"pir":	{
		"generic":	"",
		"single":	"post://192.x.y.42:18081/button",
		"double":	"",
		"long":	"",
		"press_release":	true
	},

Spotted and reported by @simonnelli in #13

Wait for homebridge/homebridge#2698 to fix / change this.

Describe the bug
Configuring a dingz button in Home.app works as expected but with a big delay (~6 sec).
Looking at the log I suspect a IPv6 vs. IPv4 problem. Could it be that it first tries to use IPv6, time out (fail) and then try IPv4?

This seems to be unrelated to the callback URL, as button presses are also triggered correctly (with 6sec lag) to Home.app even without working callback URL.

To Reproduce
Steps to reproduce the behavior:
Configure Docker host as IPv6/IPv4-Dual-Stack, check how long it takes for button presses to register in Home.app

Expected behavior
Very low latency for button actions

Plugin environment (please complete the following information):

• dingz/myStrom Device Firmware Version 1.49.0
• Homebridge Server: Homebridge Docker on Synology
• Plugin Version v1.5.1
• Node.js Version v12.17.0
• Homebridge Version: 1.1.0
• Special settings: without auto-discovery

Screenshots

Additional context
My IPv6 understanding isn't very deep, could be a wrong config as well on my network

The pollers are still badly timed. Depending on interactions by the user, the plugin throws lots of errors from too many parallel callbacks:

(node:5309) UnhandledPromiseRejectionWarning: Error: This callback function has already been called by someone else; it can only be called one time.
    at /usr/lib/node_modules/homebridge/node_modules/hap-nodejs/src/lib/util/once.ts:6:13
    at DingzDaAccessory.getOn (/usr/lib/node_modules/homebridge-dingz/src/dingzDaAccessory.ts:463:5)
    at Characteristic.emit (events.js:322:22)
    at Characteristic.EventEmitter.emit (/usr/lib/node_modules/homebridge/node_modules/hap-nodejs/src/lib/EventEmitter.ts:42:22)
    at Characteristic._this.getValue (/usr/lib/node_modules/homebridge/node_modules/hap-nodejs/src/lib/Characteristic.ts:451:12)
    at /usr/lib/node_modules/homebridge/node_modules/hap-nodejs/src/lib/Accessory.ts:1219:22
    at Array.forEach (<anonymous>)
    at Bridge.Accessory._this._handleGetCharacteristics (/usr/lib/node_modules/homebridge/node_modules/hap-nodejs/src/lib/Accessory.ts:1147:10)
    at HAPServer.emit (events.js:310:20)
    at HAPServer.EventEmitter.emit (/usr/lib/node_modules/homebridge/node_modules/hap-nodejs/src/lib/EventEmitter.ts:42:22)
(node:5309) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 1)
(node:5309) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
(node:5309) UnhandledPromiseRejectionWarning: Error: This callback function has already been called by someone else; it can only be called one time.
    at /usr/lib/node_modules/homebridge/node_modules/hap-nodejs/src/lib/util/once.ts:6:13
    at DingzDaAccessory.getOn (/usr/lib/node_modules/homebridge-dingz/src/dingzDaAccessory.ts:463:5)
    at Characteristic.emit (events.js:322:22)
    at Characteristic.EventEmitter.emit (/usr/lib/node_modules/homebridge/node_modules/hap-nodejs/src/lib/EventEmitter.ts:42:22)
    at Characteristic._this.getValue (/usr/lib/node_modules/homebridge/node_modules/hap-nodejs/src/lib/Characteristic.ts:451:12)
    at /usr/lib/node_modules/homebridge/node_modules/hap-nodejs/src/lib/Accessory.ts:1219:22
    at Array.forEach (<anonymous>)
    at Bridge.Accessory._this._handleGetCharacteristics (/usr/lib/node_modules/homebridge/node_modules/hap-nodejs/src/lib/Accessory.ts:1147:10)
    at HAPServer.emit (events.js:310:20)
    at HAPServer.EventEmitter.emit (/usr/lib/node_modules/homebridge/node_modules/hap-nodejs/src/lib/EventEmitter.ts:42:22)
(node:5309) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 2)
(node:5309) UnhandledPromiseRejectionWarning: Error: This callback function has already been called by someone else; it can only be called one time.
    at /usr/lib/node_modules/homebridge/node_modules/hap-nodejs/src/lib/util/once.ts:6:13
    at DingzDaAccessory.getOn (/usr/lib/node_modules/homebridge-dingz/src/dingzDaAccessory.ts:463:5)
    at Characteristic.emit (events.js:322:22)
    at Characteristic.EventEmitter.emit (/usr/lib/node_modules/homebridge/node_modules/hap-nodejs/src/lib/EventEmitter.ts:42:22)
    at Characteristic._this.getValue (/usr/lib/node_modules/homebridge/node_modules/hap-nodejs/src/lib/Characteristic.ts:451:12)
    at /usr/lib/node_modules/homebridge/node_modules/hap-nodejs/src/lib/Accessory.ts:1219:22
    at Array.forEach (<anonymous>)
    at Bridge.Accessory._this._handleGetCharacteristics (/usr/lib/node_modules/homebridge/node_modules/hap-nodejs/src/lib/Accessory.ts:1147:10)
    at HAPServer.emit (events.js:310:20)
    at HAPServer.EventEmitter.emit (/usr/lib/node_modules/homebridge/node_modules/hap-nodejs/src/lib/EventEmitter.ts:42:22)

Describe the bug
Now that we found the edge case with my pre production dingz I'm still seeing following all the time in the log (3.0.0). Tried to set the update interval to 20s but that didn't help. Not sure if my unit is just slower to respond or if it is a general issue?
(I will write the iolo-guys for a replacement as it seems to me that the device is behaving differently than the final ones)

[12/9/2020, 1:06:29 PM] [dingz] DEAD Device --> entered unreachable state (192.168.227.12)
[12/9/2020, 1:06:29 PM] [dingz] HTTP ECONNABORTED Connection aborted --> 192.168.227.12
[12/9/2020, 1:06:47 PM] [dingz] ALIVE Device --> recovered from unreachable state (192.168.227.12)
[12/9/2020, 1:08:29 PM] [dingz] Error: timeout of 3000ms exceeded (GET http://192.168.227.12/api/v1/state)
[12/9/2020, 1:08:29 PM] [dingz] DEAD Device --> entered unreachable state (192.168.227.12)
[12/9/2020, 1:08:29 PM] [dingz] HTTP ECONNABORTED Connection aborted --> 192.168.227.12
[12/9/2020, 1:08:49 PM] [dingz] Error: timeout of 3000ms exceeded (GET http://192.168.227.12/api/v1/state)
[12/9/2020, 1:08:49 PM] [dingz] DEAD Device --> entered unreachable state (192.168.227.12)
[12/9/2020, 1:08:49 PM] [dingz] HTTP ECONNABORTED Connection aborted --> 192.168.227.12
[12/9/2020, 1:09:06 PM] [dingz] ALIVE Device --> recovered from unreachable state (192.168.227.12)
[12/9/2020, 1:10:09 PM] [dingz] Error: timeout of 3000ms exceeded (GET http://192.168.227.12/api/v1/state)
[12/9/2020, 1:10:09 PM] [dingz] DEAD Device --> entered unreachable state (192.168.227.12)
[12/9/2020, 1:10:09 PM] [dingz] HTTP ECONNABORTED Connection aborted --> 192.168.227.12
[12/9/2020, 1:10:29 PM] [dingz] Error: timeout of 3000ms exceeded (GET http://192.168.227.12/api/v1/state)
[12/9/2020, 1:10:29 PM] [dingz] DEAD Device --> entered unreachable state (192.168.227.12)
[12/9/2020, 1:10:29 PM] [dingz] HTTP ECONNABORTED Connection aborted --> 192.168.227.12
[12/9/2020, 1:10:47 PM] [dingz] ALIVE Device --> recovered from unreachable state (192.168.227.12)

Describe the bug
'DingZ' should be renamed everywhere to 'dingz' to match the manufacturers naming convention

one more improvement: can't we give the LEDs a proper label? For example, the LED+ device name, which we will read out.

Originally posted by @granturism0 in #139 (comment)

Describe the bug
Since updating to v2.0.0-nightly I often get following error message in the log. Everything works as expected as I can see.

[11/25/2020, 8:40:32 AM] [dingz] HTTP Response Error ->http://192.168.227.12/api/v1/dimmer/2/off/
[11/25/2020, 8:40:32 AM] [dingz] Request failed with status code 404
[11/25/2020, 8:40:32 AM] [dingz] 
[11/25/2020, 8:40:32 AM] [dingz] 404
[11/25/2020, 8:40:32 AM] [dingz] {
  connection: 'close',
  'content-type': 'text/html',
  'content-length': '0',
  'access-control-allow-origin': '*'
}

To Reproduce
Install v2.0.0-nightly, check log

Expected behavior
no errors in log

Plugin environment (please complete the following information):

• dingz/myStrom Device Firmware Version [e.g. 1.49.0]
• Homebridge Server: [e.g. Homebridge Docker]
• Plugin Version [e.g. 1.5.0]
• Node.js Version [e.g. 14.1.0]
• Homebridge Version [e.g. 1.1.0]
• Special settings [e.g. with/without auto-discovery]

Screenshots and Logs
If applicable, add screenshots to help explain your problem.

You can enclose log files, JSON output from API endpoints and other output in a code fence like this:

```
Code or Log output
```

This makes it easier to read for the developer (and yourself). You can even add the language used for better formatting:

```json 
{  
    "employee": {  
        "name":       "sonoo",   
        "salary":      56000,   
        "married":    true  
    }  
}  
```

will be rendered as

{  
    "employee": {  
        "name":       "sonoo",   
        "salary":      56000,   
        "married":    true  
    }  
}  

Additional context
Add any other context about the problem here.

Describe the bug
'Switch' is misspelled in the log

Screenshots

Describe the bug
Since Homebridge 1.3.x I'm getting lots of warnings like this:
[3/2/2021, 11:54:14 PM] [homebridge-dingz] This plugin generated a warning from the characteristic 'Current Ambient Light Level': characteristic was supplied illegal value: number 0 exceeded minimum of 0.0001. See https://git.io/JtMGR for more info.

To Reproduce
Install latest Homebridge 1.3.1, latest homebridge-dingz v3.1.5 and check log

I've just released a "release candidate" of the plugin. You can install it in your homebridge by running npm i homebridge-dingz@next from the Terminal in Homebridge Config UI X or your command line and then restart homebridge.

One note: it will BREAK YOUR BLINDS -- I had to implement a change that is unfortunately incompatible with old setups. It should be much more reliable now but I can't tell for sure. If you have a test-server you can run along your main server to do the testing, that will help (you can also run a local homebridge instance on your computer for some testing and to avoid touching your main setup -- you will just have to set-up a new Home in HomeKit and add the bridge there).

Please have a look at it. It should fix quite a few problems and will make it easier to solve additional little ones. I'd be grateful to see some testing before I release this as a major version.

Release notes can be found here: v2.0.0-rc

Fixes and implements changes and bugs reported in #3, #103, #116, #120, #123, #124, #129, #135
(@qx54, @granturism0, @simonnelli: I'd be very grateful if you could help with testing in your different environments.)

The plugin does not work for me. Although devices appear in "Home" they cannot be controlled. Also other plugins are not working anymore.

To Reproduce
I have one dingz connected to my network. It is setup to use Output 2 as button and output 3/4 to control a blind. I just install the plugin and observe. See copy from log file below

Plugin environment (please complete the following information):

• Homebridge Server: Homebridge on RaspberryPI
• Plugin Version : homebridge-dingz v1.5.0
• Node.js Version: v12.14.1
• Homebridge Version: 1.1.0
• Special settings: with auto-discovery

Screenshots
The log file might give a hint for the reason for this behaviour:

[Dingz & myStrom SmartHome platform] Update accessory -> Check for changed config.
(node:22232) UnhandledPromiseRejectionWarning: TypeError: Cannot read property 'blind' of undefined
at DingzDaAccessory.updateWindowCoveringState (/usr/local/lib/node_modules/homebridge-dingz/src/dingzAccessory.ts:817:33)
at DingzEventBus.emit (events.js:228:7)
at /usr/local/lib/node_modules/homebridge-dingz/src/dingzAccessory.ts:200:32
at processTicksAndRejections (internal/process/task_queues.js:94:5)
(node:22232) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 17)

Additional context
Add any other context about the problem here.

• Move DingzDaBaseAccessory to an interface
• Extend a BaseAccessory class with this interface
• Acceossories implement the interface

See Interfaces extending classes for details.

Hello Johann,

I have the following problem since the latest update:

I have 2 buttons configured as switches and one as a dimmer. The switches work fine, but the dimmer does not work in Homekit and in Homebridge.
With the dimmer (in Homekit/Homebridge) I can only turn the light on and off, but not dim it. In the Dingz app the dimming works and this value is also displayed in Homekit and the Homebrige.

Dingzplugin is version 3.1.4
Homebridge is version 1.2.5
node.js is version 14.15.4
nmp is version 6.14.10

I uninstalled the dingz plugin and then reinstalled it.

Thanks for your help,
Michael

Describe the bug
I just updated to v2.0.5 and the MyStrom motion sensor stopped working. The log is getting flooded with entries:

[30/11/2020, 18:05:35] [dingz and myStrom SmartHome platform] [Button] ALIVE (192.168.1.98)
[30/11/2020, 18:05:35] [dingz and myStrom SmartHome platform] [myStrom Motion Sensor] DEAD (192.168.1.137)
[30/11/2020, 18:05:35] [dingz and myStrom SmartHome platform] [Button] ALIVE (192.168.1.239)
[30/11/2020, 18:05:38] [dingz and myStrom SmartHome platform] [myStrom Motion Sensor] Error: timeout of 3000ms exceeded (GET http://192.168.1.137/api/v1/sensors)
[30/11/2020, 18:05:38] [dingz and myStrom SmartHome platform] [myStrom Motion Sensor] Device --> entered unreachable state (192.168.1.137)
[30/11/2020, 18:05:38] [dingz and myStrom SmartHome platform] [myStrom Motion Sensor] HTTP ECONNABORTED Connection aborted --> 192.168.1.137
[30/11/2020, 18:05:38] [dingz and myStrom SmartHome platform] [myStrom Motion Sensor] Error: timeout of 3000ms exceeded (GET http://192.168.1.137/api/v1/sensors)
[30/11/2020, 18:05:40] [dingz and myStrom SmartHome platform] [Button] ALIVE (192.168.1.98)
[30/11/2020, 18:05:40] [dingz and myStrom SmartHome platform] [myStrom Motion Sensor] DEAD (192.168.1.137)
[30/11/2020, 18:05:40] [dingz and myStrom SmartHome platform] [Button] ALIVE (192.168.1.239)
[30/11/2020, 18:05:43] [dingz and myStrom SmartHome platform] [myStrom Motion Sensor] Error: timeout of 3000ms exceeded (GET http://192.168.1.137/api/v1/sensors)
[30/11/2020, 18:05:43] [dingz and myStrom SmartHome platform] [myStrom Motion Sensor] Device --> entered unreachable state (192.168.1.137)
[30/11/2020, 18:05:43] [dingz and myStrom SmartHome platform] [myStrom Motion Sensor] HTTP ECONNABORTED Connection aborted --> 192.168.1.137
[30/11/2020, 18:05:43] [dingz and myStrom SmartHome platform] [myStrom Motion Sensor] Error: timeout of 3000ms exceeded (GET http://192.168.1.137/api/v1/sensors)

To Reproduce
Steps to reproduce the behavior:

1. In Homebridge update plugin to v2.0.5
2. verify motion sensor is not working and find the [myStrom Motion Sensor] DEAD entry in the log

Expected behavior
Motion sensor should be working and not be marked as DEAD in the log.

In my setup v.1.2.0 breaks all other HB-plugins I use (Sonos and Hue). As soon as I uninstall homebridge-dingz the other plugins work again. Log looks normal.

Hallo
Ich versuche seit einiger Zeit die Dingz-Schalter in mein Hoobs zu integrieren, was einfach nicht klappt. Egal ob per auto-discovery oder per manueller Eingabe.

Habe das Plugin schon mehrmals entfernt und wieder installiert. Keine Änderung. Auch die MyStrom-Geräte werden nicht erkannt. (Nur vom MyStrom-Plugin, durch manuelle Eingabe, welches glaube ich auch von Dir kommt)

Mache ich was falsch?

Front:
Firmware 1.1.49
Webinterface 2.3.13
Hardware 1.1.2
Model DZ1F-4B

Base:
Bootloader 1.0.0
Firmware 1.1.18
Hardware 1.1.2
Model DZ1B-4CH

• Homebridge Server: Raspberry PI3b mit Hoobs
• Plugin Version 1.6.0
• Node.js Version 12.16.3
• Homebridge Version Hoobs 3.2.6

Ich betreibe keinen proxy und habe nichts besonderes im Netzwerk.
Auch keinen REST-API-Token vergeben. Es sollte eigentlich alles „standard“ sein.

Describe the bug
Latest update breaks connection between HomeKit and Homebridge.
Deleting Homebridge in HomeKit and trying to add the Bridge to HomeKit leads to Error message: "accessory is out of compliance"

Deleting Dingz-plugin from HomeKit resolves the issue

To Reproduce
Steps to reproduce the behavior:
Install latest Dingz-plugin in Homebridge

Plugin environment (please complete the following information):

• dingz/myStrom Device Firmware Version [1.2.7]
• Homebridge Server: [Homebridge Docker]
• Plugin Version [v1.8.0]
• Node.js Version [v14.15.0]
• Homebridge Version [v1.2.3]

        {
            "name": "dingz",
            "motionPoller": true,
            "autoDiscover": false,
            "callbackHostname": "192.168.227.10",
            "devices": [
                {
                    "type": "dingz",
                    "name": "dingz Küche",
                    "address": "192.168.227.12"
                }
            ],
            "platform": "Dingz"
        },

Additional context
Remember #5 ? :D

Describe the enhancement
If devices are not reachable (e.g. plugs not plugged in, WiFi woes), the plugin will still try to contact them regularly, leading to a log full of errors. By setting the reachability and having a exponential retry policy, this could be alleviated.

Examples and context
Feature wise, this doesn't break anything but it's not good practice to brute-force a status update from the device that is polled.

Additional context

The property this.accessory.context.device.dingzInputInfo[0] can be empty if the one input of a dingz is not set / set as output. Currently, the code which checks the config crashes when it tried to access this property.