Fibaro Door/Window Sensor FGK-10x

[TS-Tec]

Hello,

I have a Problem with the Fiabro Door/Window Sensor:

I included it in ZWay and it appears as a set of different devices like Alarm, temperatures, etc. The Problem is, that homebridge only recognizes the temperature device (I installed a DS18B20 to the sensor to report the temperature) and a "General Purpose Alarm" which is show as a window sensor in HomeKit but does only reflect the Tamper Sensor and not the reed contact of the sensor.

The status of the Window (reed sensor) is reported in an alarm device (in my case with ID ZWayVDev_zway_13-0-113-6-Door-A), which is not shown in HomeKit.

I tried some combination of homebridge tags to make it visible in HomeKit like "Homebridge.IsPrimary", "Homebridge.Service.Type:value" and also "Homebridge.Characteristic.Type:value" with different values (SensorBinary, Window, Door, ...). As a result of these tags, the temperature sensor disappears (I guess because I made an other device primary) and an "unsupported Device" appears in HomeKit with no functionality.

So my question: How do I get the Window Sensor working with homebridge? I want to see both, the temperature and the status of the window.

Thanks in advance for your support!

[SphtKr]

Hi, can I see the section of your devices.json that defines this device?

[TS-Tec]

Of course, here you go:

(13.0.48.1)"},"permanently_hidden":true,"probeType":"general_purpose","tags":[],"visibility":true,"updateTime":1480500000},{"creationTime":1479323823,"creatorId":1,"deviceType":"sensorMultilevel","h":-1456739598,"hasHistory":false,"id":"ZWayVDev_zway_13-0-49-1","location":5,"metrics":{"probeTitle":"Temperature","scaleTitle":"°C","level":17.1200016,"icon":"temperature","title":"Temperatur Bad"},"permanently_hidden":false,"probeType":"temperature","tags":[],"visibility":true,"updateTime":1480499399},{"creationTime":1479323835,"creatorId":1,"deviceType":"sensorBinary","h":-2108136022,"hasHistory":false,"id":"ZWayVDev_zway_13-0-113-4-2-A","location":5,"metrics":{"icon":"alarm","level":"off","title":"Fibaro Heat Alarm (13.0.113.4.2)"},"permanently_hidden":true,"probeType":"alarm_heat","tags":[],"visibility":true,"updateTime":1480461223},{"creationTime":1479323835,"creatorId":1,"deviceType":"sensorBinary","h":-2108132178,"hasHistory":false,"id":"ZWayVDev_zway_13-0-113-4-6-A","location":5,"metrics":{"icon":"alarm","level":"off","title":"Fibaro Heat Alarm (13.0.113.4.6)"},"permanently_hidden":true,"probeType":"alarm_heat","tags":[],"visibility":true,"updateTime":1480461223},{"creationTime":1479323835,"creatorId":1,"deviceType":"sensorBinary","h":1594949884,"hasHistory":false,"id":"ZWayVDev_zway_13-0-113-6-Door-A","location":5,"metrics":{"icon":"door","level":"off","title":"Fenster Bad"},"permanently_hidden":false,"probeType":"alarm_door","tags":["Homebridge.Characteristic.Type:sensorBinary"],"visibility":true,"updateTime":1480462200},{"creationTime":1479323835,"creatorId":1,"deviceType":"sensorBinary","h":-2105364498,"hasHistory":false,"id":"ZWayVDev_zway_13-0-113-7-3-A","location":5,"metrics":{"icon":"smoke","level":"on","title":"Fibaro Burglar Alarm (13.0.113.7.3)"},"permanently_hidden":true,"probeType":"alarm_burglar","tags":[],"visibility":true,"updateTime":1480462200},{"creationTime":1479323835,"creatorId":1,"deviceType":"sensorBinary","h":-2103519378,"hasHistory":false,"id":"ZWayVDev_zway_13-0-113-9-1-A","location":5,"metrics":{"icon":"alarm","level":"off","title":"Fibaro System Alarm (13.0.113.9.1)"},"permanently_hidden":true,"probeType":"alarm_system","tags":[],"visibility":true,"updateTime":1480461223},{"creationTime":1479323823,"creatorId":1,"deviceType":"battery","h":507194638,"hasHistory":false,"id":"ZWayVDev_zway_13-0-128","location":0,"metrics":{"probeTitle":"Battery","scaleTitle":"%","level":66,"icon":"battery","title":"Fibaro Battery (13.0)"},"permanently_hidden":false,"probeType":"","tags":[],"visibility":true,"updateTime":1480461223},{"creationTime":1479323842,"creatorId":1,"deviceType":"sensorBinary","h":146374528,"hasHistory":false,"id":"ZWayVDev_zway_13-0-156-0-A","location":5,"metrics":{"icon":"alarm","level":"on","title":"Fibaro General Purpose alarm Alarm (13.0.156.0)"},"permanently_hidden":true,"probeType":"alarmSensor_general_purpose","tags":[],"visibility":true,"updateTime":1480498020},

[TS-Tec]

Any idea??

[WolfgangDomroese]

I have the same problem but this sensor is the only one, I'm working with at the moment. When starting home bridge manually, I get an error immediately after the scan-code is shown:

events.js:160 throw er; // Unhandled 'error' event ^

Error: listen EADDRINUSE :::51826 at Object.exports._errnoException (util.js:1022:11) at exports._exceptionWithHostPort (util.js:1045:20) at Server._listen2 (net.js:1262:14) at listen (net.js:1298:10) at Server.listen (net.js:1376:9) at EventedHTTPServer.listen (/usr/lib/node_modules/homebridge/node_modules/hap-nodejs/lib/util/eventedhttp.js:60:19) at HAPServer.listen (/usr/lib/node_modules/homebridge/node_modules/hap-nodejs/lib/HAPServer.js:158:20) at Bridge.Accessory.publish (/usr/lib/node_modules/homebridge/node_modules/hap-nodejs/lib/Accessory.js:496:16) at Server._publish (/usr/lib/node_modules/homebridge/lib/server.js:114:16) at Server. (/usr/lib/node_modules/homebridge/lib/server.js:372:14)

This is the devices file: {"data":{"structureChanged":true,"updateTime":1482939725,"devices":[{"creationTime":1482937461,"creatorId":5,"deviceType":"text","h":-1261400328,"hasHistory":false,"id":"InfoWidget_5_Int","location":0,"metrics":{"title":"Dear Expert User","text":"

If you still want to use ExpertUI please go, after you are successfully logged in, to
Menu > Devices > Manage with ExpertUI
or call
http://MYRASP:8083/expert
in your browser.

You could hide or remove this widget in menu
Apps > Active Tab. ","icon":"app/img/logo-z-wave-z-only.png"},"permanently_hidden":false,"probeType":"","tags":[],"visibility":true,"updateTime":1482937461},{"creationTime":1482932339,"creatorId":7,"deviceType":"battery","h":-592588978,"hasHistory":false,"id":"BatteryPolling_7","location":0,"metrics":{"probeTitle":"Battery","scaleTitle":"%","title":"Battery digest 7","level":100},"permanently_hidden":false,"probeType":"","tags":[],"visibility":true,"updateTime":1482937462},{"creationTime":1482933380,"creatorId":1,"deviceType":"sensorBinary","h":-1248874786,"hasHistory":false,"id":"ZWayVDev_zway_3-0-48-1","location":1,"metrics":{"probeTitle":"General purpose","scaleTitle":"","icon":"motion","level":"on","title":"Fibaro General purpose (3.0.48.1)"},"permanently_hidden":true,"probeType":"general_purpose","tags":[],"visibility":true,"updateTime":1482937462},{"creationTime":1482933389,"creatorId":1,"deviceType":"sensorBinary","h":-1124283479,"hasHistory":false,"id":"ZWayVDev_zway_3-0-113-6-Door-A","location":0,"metrics":{"icon":"door","level":"on","title":"SchlafzimmerFenster"},"permanently_hidden":false,"probeType":"alarm_door","tags":["Homebridge.Service.Type:ContactSensor"],"visibility":true,"updateTime":1482937462},{"creationTime":1482933389,"creatorId":1,"deviceType":"sensorBinary","h":2006559841,"hasHistory":false,"id":"ZWayVDev_zway_3-0-113-7-3-A","location":1,"metrics":{"icon":"smoke","level":"off","title":"Fibaro Burglar Alarm (3.0.113.7.3)"},"permanently_hidden":true,"probeType":"alarm_burglar","tags":[],"visibility":true,"updateTime":1482937462},{"creationTime":1482933379,"creatorId":1,"deviceType":"battery","h":-40289343,"hasHistory":false,"id":"ZWayVDev_zway_3-0-128","location":0,"metrics":{"probeTitle":"Battery","scaleTitle":"%","level":100,"icon":"battery","title":"Fibaro Battery (3.0)"},"permanently_hidden":false,"probeType":"","tags":[],"visibility":true,"updateTime":1482937462},{"creationTime":1482933394,"creatorId":1,"deviceType":"sensorBinary","h":-667222861,"hasHistory":false,"id":"ZWayVDev_zway_3-0-156-0-A","location":1,"metrics":{"icon":"alarm","level":"on","title":"Fibaro General Purpose alarm Alarm (3.0.156.0)"},"permanently_hidden":true,"probeType":"alarmSensor_general_purpose","tags":[],"visibility":true,"updateTime":1482937462}]},"code":200,"message":"200 OK","error":null}

I cannot retrieve accessories....

Any idea?

[SphtKr]

@WolfgangDomroese In your case it seems you have another instance of Homebridge running already, which is using the port it expects to run on:

Error: listen EADDRINUSE :::51826

Try ps -ef | grep homebridge and see if you have another process running that you don't expect. If so, kill that process and try again.

[WolfgangDomroese]

Thanks!

Obviously this a problem in my autostart-script. The process is not killed correctly - I will try to solve.

But even when only one process is running, I don't get results.

On start of homebridge I get no initializing of z-wave devices, as I see in other logfiles on the web. I just get

Initializing ZWayServer platform...

... thats it.

Any Idea? If I can support debugging, please let me know.

Wolfgang

Am 29.12.16 um 06:44 schrieb SphtKr:

@WolfgangDomroese https://github.com/WolfgangDomroese In your case it seems you have another instance of Homebridge running already, which is using the port it expects to run on:

Error: listen EADDRINUSE :::51826

Try |ps -ef | grep homebridge| and see if you have another process running that you don't expect. If so, kill that process and try again.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/SphtKr/homebridge-zway/issues/69#issuecomment-269584713, or mute the thread https://github.com/notifications/unsubscribe-auth/AOtuiP2LamcACKZi889GyW6TUHgtLpBzks5rM0jFgaJpZM4K1AF6.

-- Wolfgang Domröse Von Eichendorff-Str. 23 37539 Bad Grund (Harz)

[SphtKr]

@TS-Tec Back to your original issue, it seems that that sensor is no longer reporting itself as door-window, but is now only reporting itself as several different alarm_* types :-/. Unsure if this is due to a firmware update on the device or a Z-Way server version update--they changed a bunch of probeTypes in the latest version 😠 (can you tell me your version of Z-Way Server?).

I'll have to work in a fix, but this is a little tricky...many other devices publish those alarm types and they mean something slightly different, usually (you can turn on/off triggering of the alarm channel)...so I don't want a change to interfere with the way other devices work.

[SphtKr]

@WolfgangDomroese Try running homebridge in Debug mode, with one of the following methods:

homebridge -D
DEBUG=* homebridge
DEBUG=ZWayServer homebridge

See the Homebridge project's page for more info. If you see something amiss, probably open a new issue at this point, we're mixing things up with the original bug now.

[joergs-git]

I can confirm that this behavior still exists on my side too. Running newest versions of z-way, Homebridge and Homebridge-zway etc. certain contact sensors do not show up anymore, while some still do. Really strange.

[WolfgangDomroese]

I opened a new issue with the complete debug-message. The part regarding ZWayServer is here:

ZWayServer Authenticating... +256ms ZWayServer Authenticated. Resubmitting original request... +69ms ZWayServer Device ZWayVDev_zway_3-0-48-1 skipped! +50ms ZWayServer { permanently_hidden: true, ZWayServer Skip: false, ZWayServer Include: false, ZWayServer opt_in: undefined } +1ms ZWayServer Device ZWayVDev_zway_3-0-113-7-3-A skipped! +5ms ZWayServer { permanently_hidden: true, ZWayServer Skip: false, ZWayServer Include: false, ZWayServer opt_in: undefined } +0ms ZWayServer Device ZWayVDev_zway_3-0-156-0-A skipped! +1ms ZWayServer { permanently_hidden: true, ZWayServer Skip: false, ZWayServer Include: false, ZWayServer opt_in: undefined } +1ms ZWayServer Got grouped device BatteryPolling_7 consisting of devices: +1ms ZWayServer BatteryPolling_7 - battery.Battery +5ms ZWayServer WARN: Didn't find suitable device class! +0ms ZWayServer Got grouped device InfoWidget_5_Int consisting of devices: +0ms ZWayServer InfoWidget_5_Int - text +0ms ZWayServer WARN: Didn't find suitable device class! +1ms ZWayServer Got grouped device ZWayVDev_3-0 consisting of devices: +0ms ZWayServer ZWayVDev_zway_3-0-113-6-Door-A - sensorBinary +0ms ZWayServer ZWayVDev_zway_3-0-128 - battery.Battery +0ms ZWayServer WARN: Didn't find suitable device class! +0ms

Am 03.01.17 um 07:10 schrieb SphtKr:

@WolfgangDomroese https://github.com/WolfgangDomroese Try running homebridge in Debug mode, with one of the following methods:

|homebridge -D DEBUG=* homebridge DEBUG=ZWayServer homebridge |

See the Homebridge project's page for more info. If you see something amiss, probably open a new issue at this point, we're mixing things up with the original bug now.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/SphtKr/homebridge-zway/issues/69#issuecomment-270056493, or mute the thread https://github.com/notifications/unsubscribe-auth/AOtuiMpadvvc7GfKLX-85i6atChGHazQks5rOeY_gaJpZM4K1AF6.

-- Wolfgang Domröse Von Eichendorff-Str. 23 37539 Bad Grund (Harz)

[TS-Tec]

@SphtKr same behaviour on 2.2.4 and 2.2.5

Thanks for your support!

[SphtKr]

Can somebody try the diff in the above commit fc5ffeb ? That may do the trick.

Also, @TS-Tec I noticed that you had tagged your sensor with Homebridge.Characteristic.Type:sensorBinary , but that's not right, you probably mean Homebridge.Characteristic.Type:ContactSensor, or Homebridge.Characteristic.Type:Door.

[WolfgangDomroese]

Sorry, I'm out of home. I could change the file but as the pi is now in another place, obviously apples home-kit does not work at all. And I do not know, how to reset.....

So, we have to wait until Friday afternoon CET.

Am 05.01.17 um 07:40 schrieb SphtKr:

Can somebody try the diff in the above commit fc5ffeb https://github.com/SphtKr/homebridge-zway/commit/fc5ffeb12bdbdaf785ed906caa72720f504ba556 ? That may do the trick.

Also, @TS-Tec https://github.com/TS-Tec I noticed that you had tagged your sensor with |Homebridge.Characteristic.Type:sensorBinary| , but that's not right, you probably mean |Homebridge.Characteristic.Type:ContactSensor|, or |Homebridge.Characteristic.Type:Door|.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/SphtKr/homebridge-zway/issues/69#issuecomment-270575112, or mute the thread https://github.com/notifications/unsubscribe-auth/AOtuiHPjAx4q-cVXZqqRmChSMGYf1uP4ks5rPJBNgaJpZM4K1AF6.

-- Wolfgang Domröse Von Eichendorff-Str. 23 37539 Bad Grund (Harz)

[TS-Tec]

@SphtKr Sorry, I am not really familiar with this GitHub stuff.. How can I install your change on my raspberry to test your commit?

[SphtKr]

Basically, click the link on fc5ffeb , and there is one added line in green. Find your copy of index.js in your homebridge-zway folder, and find the same place in that file that has the same lines above and below the green line. Paste (add) the green line into that spot. Then restart Homebridge and see if the door sensor shows up properly.

[SphtKr]

Oh, but don't add the + that's at the beginning of the line.

[SphtKr]

Hold on, not quite, also requires 2f7f54d . But I'm pretty sure that fixes it.

[SphtKr]

I think this is now fixed in 0.5.0-rc1, everyone update to that version (and restart Homebridge) and see if it solves your issues.

I was able to test this by Homebridge.Skipping the regular door-window device on one of my Devolo door sensors which left only the alarm_door sensor like the Fibaros have, and it seems to be working.

[WolfgangDomroese]

Sorry - I still do not get it. Here is the DEBUG output. There is still a Warning....

There are two sensors included, but one is not working (absent).

pi@pi_1_zwave:~ $ DEBUG=ZWayServer homebridge WARNING The program 'nodejs' uses the Apple Bonjour compatibility layer of Avahi. WARNING Please fix your application to use the native API of Avahi! WARNING For more information see http://0pointer.de/avahi-compat?s=libdns_sd&e=nodejs WARNING The program 'nodejs' called 'DNSServiceRegister()' which is not supported (or only supported partially) in the Apple Bonjour compatibility layer of Avahi. WARNING Please fix your application to use the native API of Avahi! WARNING For more information see http://0pointer.de/avahi-compat?s=libdns_sd&e=nodejs&f=DNSServiceRegister [2017-01-06 19:49:18] Loaded plugin: homebridge-contactsensor [2017-01-06 19:49:18] Registering accessory 'homebridge-contactsensor.ContactSensor' [2017-01-06 19:49:18] --- [2017-01-06 19:49:19] Loaded plugin: homebridge-zway [2017-01-06 19:49:19] Registering accessory 'homebridge-zway.ZWayServer' [2017-01-06 19:49:19] Registering platform 'homebridge-zway.ZWayServer' [2017-01-06 19:49:19] --- [2017-01-06 19:49:19] Loaded config.json with 1 accessories and 1 platforms. [2017-01-06 19:49:19] --- [2017-01-06 19:49:19] Loading 1 platforms... [2017-01-06 19:49:19] Initializing ZWayServer platform... ZWayServer Fetching Z-Way devices... +0ms [2017-01-06 19:49:19] Loading 1 accessories... [2017-01-06 19:49:19] [DummySensor] Initializing ContactSensor accessory... contact sensors { '22': Service { displayName: 'Dummy 1', UUID: '00000080-0000-1000-8000-0026BB765291', subtype: 'Dummy 1', iid: null, characteristics: [ [Object], [Object] ], optionalCharacteristics: [ [Object], [Object], [Object], [Object], [Object] ] }, '24': Service { displayName: 'Dummy 2', UUID: '00000080-0000-1000-8000-0026BB765291', subtype: 'Dummy 2', iid: null, characteristics: [ [Object], [Object] ], optionalCharacteristics: [ [Object], [Object], [Object], [Object], [Object] ] } } ZWayServer Authenticating... +246ms ZWayServer Authenticated. Resubmitting original request... +71ms ZWayServer Device ZWayVDev_zway_3-0-48-1 skipped! +54ms ZWayServer { permanently_hidden: true, ZWayServer Skip: false, ZWayServer Include: false, ZWayServer opt_in: undefined } +1ms ZWayServer Device ZWayVDev_zway_3-0-113-7-3-A skipped! +5ms ZWayServer { permanently_hidden: true, ZWayServer Skip: false, ZWayServer Include: false, ZWayServer opt_in: undefined } +0ms ZWayServer Device ZWayVDev_zway_3-0-156-0-A skipped! +2ms ZWayServer { permanently_hidden: true, ZWayServer Skip: false, ZWayServer Include: false, ZWayServer opt_in: undefined } +0ms ZWayServer Device ZWayVDev_zway_4-0-48-1 skipped! +1ms ZWayServer { permanently_hidden: true, ZWayServer Skip: false, ZWayServer Include: false, ZWayServer opt_in: undefined } +6ms ZWayServer Device ZWayVDev_zway_4-0-113-7-3-A skipped! +2ms ZWayServer { permanently_hidden: true, ZWayServer Skip: false, ZWayServer Include: false, ZWayServer opt_in: undefined } +0ms ZWayServer Device ZWayVDev_zway_4-0-156-0-A skipped! +2ms ZWayServer { permanently_hidden: true, ZWayServer Skip: false, ZWayServer Include: false, ZWayServer opt_in: undefined } +0ms ZWayServer Got grouped device InfoWidget_5_Int consisting of devices: +2ms ZWayServer InfoWidget_5_Int - text +0ms ZWayServer WARN: Didn't find suitable device class! +1ms ZWayServer Got grouped device BatteryPolling_7 consisting of devices: +3ms ZWayServer BatteryPolling_7 - battery.Battery +1ms ZWayServer WARN: Didn't find suitable device class! +1ms ZWayServer Got grouped device ZWayVDev_3-0 consisting of devices: +0ms ZWayServer ZWayVDev_zway_3-0-113-6-Door-A - sensorBinary +0ms ZWayServer ZWayVDev_zway_3-0-128 - battery.Battery +0ms ZWayServer WARN: Didn't find suitable device class! +1ms ZWayServer Got grouped device ZWayVDev_4-0 consisting of devices: +0ms ZWayServer ZWayVDev_zway_4-0-113-6-Door-A - sensorBinary +0ms ZWayServer ZWayVDev_zway_4-0-128 - battery.Battery +0ms ZWayServer WARN: Didn't find suitable device class! +1ms Scan this code with your HomeKit App on your iOS device to pair with Homebridge:

Am 06.01.17 um 06:13 schrieb SphtKr:

I think this is now fixed in 0.5.0-rc1, everyone update to that version (and restart Homebridge) and see if it solves your issues.

I was able to test this by |Homebridge.Skip|ping the regular |door-window| device on one of my Devolo door sensors which left only the |alarm_door| sensor like the Fibaros have, and it seems to be working.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/SphtKr/homebridge-zway/issues/69#issuecomment-270833036, or mute the thread https://github.com/notifications/unsubscribe-auth/AOtuiMpJigROsRDMk9TgeUntsLicx_Beks5rPc2PgaJpZM4K1AF6.

-- Wolfgang Domröse Von Eichendorff-Str. 23 37539 Bad Grund (Harz)

[TS-Tec]

@SphtKr Tested your commits and can say that the sensor is now handled by HomeKit but:

• it is shown as a door and can not be configured as window
• it offers an function to open and close (to a percent value) which leads to an "transition" state in home kit like "opening" or closing" which does not make sense for a passive sensor
• if the window is closed and I open it, HomeKit does nit change the status to "open" but to "closing..."

So it is not handles as a sensor but as an controllable device... This also means I cannot use it as an sensor input for HomeKit automatization...

Is there a chance that it could be handled like a passive door/window sensor which only shows its state without possibility to change its value in HomeKit??

But thanks for the great work until here!!

P.S.: I changed the ZWay Tag to Homebridge.Characteristic.Type:ContactSensor and also tried Homebridge.Characteristic.Type:Door and Homebridge.Characteristic.Type:Window - same behavior... It is shown as a Door in HomeKit with above described behavior...

[WolfgangDomroese]

In fact - after complete reset of razberry and including one device without any settings, the device is shown!

But without any reaction on open / close!

Looking at the Z-Wave>Me, I find 4 devices: Fibaro-General Purpose Alarm/ Access Control/ Burglar Alarm/ General Purpose). But only Access Control reacts on moving the sensor!

But the device shown in iPhone is General Purpose - as mentioned: without any reaction!

So, before I try a lot of settings: how to set hardware of the device and tags.

Can anybody help?

Thanks for all your support!

Wolfgang

Am 07.01.17 um 12:52 schrieb TS-Tec:

@SphtKr https://github.com/SphtKr Tested your commits and can say that the sensor is now handled by HomeKit but:

• it is shown as a door and can not be configured as window
• it offers an function to open and close (to a percent value) which leads to an "transition" state in home kit like "opening" or closing" which does not make sense for a passive sensor

Is there a chance that it could be handled like a passive door/window sensor which only shows its state without possibility to change its value in HomeKit??

But thanks for the great work until here!!

P.S.: I changed the ZWay Tag to |Homebridge.Characteristic.Type:ContactSensor|

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/SphtKr/homebridge-zway/issues/69#issuecomment-271079229, or mute the thread https://github.com/notifications/unsubscribe-auth/AOtuiI7gkfYAQWgAVtXp2lFqnz8wsukuks5rP3yDgaJpZM4K1AF6.

-- Wolfgang Domröse Von Eichendorff-Str. 23 37539 Bad Grund (Harz)

[TS-Tec]

I found out what went wrong on my constellation:

It looks like that this.platform.getTagValue(vdev, "Service.Type") does not deliver a known Service Type and therefore uses the default in index.js line 535: services.push(new Service.Door(vdev.metrics.title, vdev.id)); which is a Door that is handled like a controllable door in HomeKit.

I changed this to: services.push(new Service.ContactSensor(vdev.metrics.title, vdev.id)); and now it is handled as a Contact sensor and works fine!

[WolfgangDomroese]

I changed in in line 537 in rc1!

But there is no difference for me. I'm not familiar with zwave. But as I see from the server's webinterface, one phsical device (Fibaro FGK-10x) can have some (in my case 4) logical devices. And homebridge bridges the wrong one as I reproted in my last mail.

Am 07.01.17 um 18:36 schrieb TS-Tec:

I found out what went wrong on my constellation:

It looks like that |this.platform.getTagValue(vdev, "Service.Type")| does not deliver a known Service Type and therefore uses the default in index.js line 535: |services.push(new Service.Door(vdev.metrics.title, vdev.id));| which is a Door that is handled like a controllable door in HomeKit.

I changed this to: |services.push(new Service.ContactSensor(vdev.metrics.title, vdev.id));| and now it is handled as a Contact sensor and works fine!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/SphtKr/homebridge-zway/issues/69#issuecomment-271097700, or mute the thread https://github.com/notifications/unsubscribe-auth/AOtuiCZozfN5lGxxOuyW6YxK7SnIzQf-ks5rP80FgaJpZM4K1AF6.

-- Wolfgang Domröse Von Eichendorff-Str. 23 37539 Bad Grund (Harz)

[SphtKr]

@TS-Tec That line was correct, you need to instead add the tag Homebridge.Service.Type:ContactSensor or another value--see the documentation on this. I think that once you specify the Homebridge.Service.Type then you should not need to specify Homebridge.Characterisic.Type like you were doing--it should figure out the right Characteristic type.

Also be aware that those changes will always require restarting Homebridge, and may actually not reflect in your HomeKit app immediately (this is tricky, sometimes turning WiFi off/on causes an update, other times you have to wait...strictly speaking, I don't think changing Service type of an accessory is really supported in HomeKit, but it usually works eventually).

@WolfgangDomroese Hmm...that's puzzling, specifically because @TS-Tec seems to be working now. I admit I was guessing which of the four devices was actually going to be updated by default, but if it's working for him...that's odd. I have assumed that the cause of this problem in the first place was a firmware update on the Fibaro device...I wonder if you two have different firmware versions.

In any case, I don't think I've seen your devices JSON, so: could you try and capture your devices JSON data, and do it while the contact sensor is open, so I can see which device it is and which attributes it has? Thanks!

[WolfgangDomroese]

BTW: I tried to get the "General Purpose" to work as it is bridged to homekit. But I did not succeed. Whenever I try to set hardware configuration No 1 (operation mode) from Door/Window to External Switch I get an error on saving. But why the hell do I have 4 logical devices when I get only one to work????

Looking at the device Type Info I get: 6.51.06 Fibaro FGK-10x 3.2 Unknown device type: 7

I tried to find additional Information on Fibaro Site but I did not find anything besides theire centarl control unit. So, I do not know if firmware 3.2. is latest. Do you have additional sources?

The devices JSON is as follows:

Contact on Hardware open: Showing: Access Control on Burglar Alarm off General Purpose Alarm on General Purpose on

{"data":{"structureChanged":true,"updateTime":1483863807,"devices":[{"creationTime":1483802057,"creatorId":5,"deviceType":"text","h":-1261400328,"hasHistory":false,"id":"InfoWidget_5_Int","location":0,"metrics":{"title":"Dear Expert User","text":"

If you still want to use ExpertUI please go, after you are successfully logged in, to
Menu > Devices

Manage with ExpertUI
or call
http://MYRASP:8083/expert
in your browser.

You could hide or remove this widget in menu
Apps > Active Tab.

","icon":"app/img/logo-z-wave-z-only.png"},"permanently_hidden":false,"probeType":"","tags":[],"visibility":true,"updateTime":1483811172},{"creationTime":1483802057,"creatorId":7,"deviceType":"battery","h":-592588978,"hasHistory":false,"id":"BatteryPolling_7","location":0,"metrics":{"probeTitle":"Battery","scaleTitle":"%","title":"Battery digest 7","level":100},"permanently_hidden":false,"probeType":"","tags":[],"visibility":true,"updateTime":1483830700},{"creationTime":1483802176,"creatorId":1,"deviceType":"sensorBinary","h":1303282175,"hasHistory":false,"id":"ZWayVDev_zway_2-0-48-1","location":1,"metrics":{"probeTitle":"General purpose","scaleTitle":"","icon":"motion","level":"on","title":"Fenster_SZ"},"permanently_hidden":false,"probeType":"general_purpose","tags":[],"visibility":true,"updateTime":1483811173},{"creationTime":1483802185,"creatorId":1,"deviceType":"sensorBinary","h":-613749302,"hasHistory":false,"id":"ZWayVDev_zway_2-0-113-6-Door-A","location":1,"metrics":{"icon":"door","level":"on","title":"Fibaro Access Control Alarm (2.0.113.6.Door)"},"permanently_hidden":false,"probeType":"alarm_door","tags":[],"visibility":true,"updateTime":1483863751},{"creationTime":1483802185,"creatorId":1,"deviceType":"sensorBinary","h":-1995004448,"hasHistory":false,"id":"ZWayVDev_zway_2-0-113-7-3-A","location":1,"metrics":{"icon":"smoke","level":"off","title":"Fibaro Burglar Alarm (2.0.113.7.3)"},"permanently_hidden":false,"probeType":"alarm_burglar","tags":[],"visibility":true,"updateTime":1483811173},{"creationTime":1483802176,"creatorId":1,"deviceType":"battery","h":-927793024,"hasHistory":false,"id":"ZWayVDev_zway_2-0-128","location":0,"metrics":{"probeTitle":"Battery","scaleTitle":"%","level":100,"icon":"battery","title":"Fibaro Battery (2.0)"},"permanently_hidden":false,"probeType":"","tags":[],"visibility":true,"updateTime":1483830700},{"creationTime":1483802190,"creatorId":1,"deviceType":"sensorBinary","h":1129728498,"hasHistory":false,"id":"ZWayVDev_zway_2-0-156-0-A","location":1,"metrics":{"icon":"alarm","level":"on","title":"Fibaro General Purpose alarm Alarm (2.0.156.0)"},"permanently_hidden":false,"probeType":"alarmSensor_general_purpose","tags":[],"visibility":true,"updateTime":1483811173}]},"code":200,"message":"200 OK","error":null}

Contact on Hardware closed: Showing: Access Control off Burglar Alarm off General Purpose Alarm on General Purpose on

{"data":{"structureChanged":true,"updateTime":1483864071,"devices":[{"creationTime":1483802057,"creatorId":5,"deviceType":"text","h":-1261400328,"hasHistory":false,"id":"InfoWidget_5_Int","location":0,"metrics":{"title":"Dear Expert User","text":"

If you still want to use ExpertUI please go, after you are successfully logged in, to
Menu > Devices

Manage with ExpertUI
or call
http://MYRASP:8083/expert
in your browser.

You could hide or remove this widget in menu
Apps > Active Tab.

","icon":"app/img/logo-z-wave-z-only.png"},"permanently_hidden":false,"probeType":"","tags":[],"visibility":true,"updateTime":1483811172},{"creationTime":1483802057,"creatorId":7,"deviceType":"battery","h":-592588978,"hasHistory":false,"id":"BatteryPolling_7","location":0,"metrics":{"probeTitle":"Battery","scaleTitle":"%","title":"Battery digest 7","level":100},"permanently_hidden":false,"probeType":"","tags":[],"visibility":true,"updateTime":1483830700},{"creationTime":1483802176,"creatorId":1,"deviceType":"sensorBinary","h":1303282175,"hasHistory":false,"id":"ZWayVDev_zway_2-0-48-1","location":1,"metrics":{"probeTitle":"General purpose","scaleTitle":"","icon":"motion","level":"on","title":"Fenster_SZ"},"permanently_hidden":false,"probeType":"general_purpose","tags":[],"visibility":true,"updateTime":1483811173},{"creationTime":1483802185,"creatorId":1,"deviceType":"sensorBinary","h":-613749302,"hasHistory":false,"id":"ZWayVDev_zway_2-0-113-6-Door-A","location":1,"metrics":{"icon":"door","level":"off","title":"Fibaro Access Control Alarm (2.0.113.6.Door)"},"permanently_hidden":false,"probeType":"alarm_door","tags":[],"visibility":true,"updateTime":1483864001},{"creationTime":1483802185,"creatorId":1,"deviceType":"sensorBinary","h":-1995004448,"hasHistory":false,"id":"ZWayVDev_zway_2-0-113-7-3-A","location":1,"metrics":{"icon":"smoke","level":"off","title":"Fibaro Burglar Alarm (2.0.113.7.3)"},"permanently_hidden":false,"probeType":"alarm_burglar","tags":[],"visibility":true,"updateTime":1483811173},{"creationTime":1483802176,"creatorId":1,"deviceType":"battery","h":-927793024,"hasHistory":false,"id":"ZWayVDev_zway_2-0-128","location":0,"metrics":{"probeTitle":"Battery","scaleTitle":"%","level":100,"icon":"battery","title":"Fibaro Battery (2.0)"},"permanently_hidden":false,"probeType":"","tags":[],"visibility":true,"updateTime":1483830700},{"creationTime":1483802190,"creatorId":1,"deviceType":"sensorBinary","h":1129728498,"hasHistory":false,"id":"ZWayVDev_zway_2-0-156-0-A","location":1,"metrics":{"icon":"alarm","level":"on","title":"Fibaro General Purpose alarm Alarm (2.0.156.0)"},"permanently_hidden":false,"probeType":"alarmSensor_general_purpose","tags":[],"visibility":true,"updateTime":1483811173}]},"code":200,"message":"200 OK","error":null}

Am 08.01.17 um 05:24 schrieb SphtKr:

@TS-Tec https://github.com/TS-Tec That line was correct, you need to instead add the tag |Homebridge.Service.Type:ContactSensor| or another value--see the documentation on this https://github.com/SphtKr/homebridge-zway/#doorwindow-sensor-service. I /think/ that once you specify the |Homebridge.Service.Type| then you should not need to specify |Homebridge.Characterisic.Type| like you were doing--it should figure out the right Characteristic type.

Also be aware that those changes will always require restarting Homebridge, and may actually not reflect in your HomeKit app immediately (this is tricky, sometimes turning WiFi off/on causes an update, other times you have to wait...strictly speaking, I don't think changing Service type of an accessory is really supported in HomeKit, but it usually works eventually).

@WolfgangDomroese https://github.com/WolfgangDomroese Hmm...that's puzzling, specifically because @TS-Tec https://github.com/TS-Tec seems to be working now. I admit I was guessing which of the four devices was actually going to be updated by default, but if it's working for him...that's odd. I have assumed that the cause of this problem in the first place was a firmware update on the Fibaro device...I wonder if you two have different firmware versions.

In any case, I don't think I've seen your devices JSON, so: could you try and capture your devices JSON data https://github.com/SphtKr/homebridge-zway/#getting-zautomationapiv1devices, and do it /while the contact sensor is open/, so I can see which device it is and which attributes it has? Thanks!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/SphtKr/homebridge-zway/issues/69#issuecomment-271128957, or mute the thread https://github.com/notifications/unsubscribe-auth/AOtuiOWV5Ui3tGirVSsYcXZskPT0n0gkks5rQGUagaJpZM4K1AF6.

-- Wolfgang Domröse Von Eichendorff-Str. 23 37539 Bad Grund (Harz)

[SphtKr]

@WolfgangDomroese Okay: After staring at this a bit, I think I see what's going on.

In 0.5.0-rc1 I added the alarm_door probeType as being able to create a Door/Window/ContactSensor. But, I obviously had to leave in the ability for it to bridge a general_purpose probeType device for other hardware models, and in fact those general_purpose devices is preferred. In your case--for whatever reason--your hardware is publishing both of these, and only updating the alarm_door one. I'm not sure if this is a firmware difference or device configuration difference or something else entirely, but that's what it's doing.

Fortunately, I think I know how you can fix this: Just add the tag Homebridge.Skip to the general_purpose one, that is the one titled "Fenster_SZ". After that (and restarting Homebridge) it should ignore that skipped device, only see the alarm_door one that is updating, and you should be good.

Let me know if that fixes your issue!

[WolfgangDomroese]

Thanks - but at moment, there is nothing working at all. Yesterday I tried to get two PI with homebridge on each to work. One with "homebridge-contactsensor" and one with zway. So, I made some changes in config.json. Suddently zway does not show anything in iOS. I do not find any hint in DEBUG mode. So, I did uninstall and install again of homebridge-zway. No success. I think, I have to start with a new SD-Card this afternoon....

Am 12.01.17 um 07:51 schrieb SphtKr:

@WolfgangDomroese https://github.com/WolfgangDomroese Okay: After staring at this a bit, I think I see what's going on.

In 0.5.0-rc1 I added the |alarm_door| probeType as being able to create a Door/Window/ContactSensor. But, I obviously had to leave in the ability for it to bridge a |general_purpose| probeType device for other hardware models, and in fact those |general_purpose| devices is preferred. In your case--for whatever reason--your hardware is publishing /both/ of these, and only updating the |alarm_door| one. I'm not sure if this is a firmware difference or device configuration difference or something else entirely, but that's what it's doing.

Fortunately, I think I know how you can fix this: Just add the tag |Homebridge.Skip| to the |general_purpose| one, that is the one titled "Fenster_SZ". After that (and restarting Homebridge) it should ignore that skipped device, only see the |alarm_door| one that is updating, and you should be good.

Let me know if that fixes your issue!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/SphtKr/homebridge-zway/issues/69#issuecomment-272090172, or mute the thread https://github.com/notifications/unsubscribe-auth/AOtuiCjICitKvTlpSLTb1G1Vyhh8omgtks5rRc2LgaJpZM4K1AF6.

-- Wolfgang Domröse Von Eichendorff-Str. 23 37539 Bad Grund (Harz)

[WolfgangDomroese]

It's not OK:

The general_purpose device is skipped but now no other dive is shown. When debugging, there is no more init-process of a device....

Am 12.01.17 um 07:51 schrieb SphtKr:

@WolfgangDomroese https://github.com/WolfgangDomroese Okay: After staring at this a bit, I think I see what's going on.

In 0.5.0-rc1 I added the |alarm_door| probeType as being able to create a Door/Window/ContactSensor. But, I obviously had to leave in the ability for it to bridge a |general_purpose| probeType device for other hardware models, and in fact those |general_purpose| devices is preferred. In your case--for whatever reason--your hardware is publishing /both/ of these, and only updating the |alarm_door| one. I'm not sure if this is a firmware difference or device configuration difference or something else entirely, but that's what it's doing.

Fortunately, I think I know how you can fix this: Just add the tag |Homebridge.Skip| to the |general_purpose| one, that is the one titled "Fenster_SZ". After that (and restarting Homebridge) it should ignore that skipped device, only see the |alarm_door| one that is updating, and you should be good.

Let me know if that fixes your issue!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/SphtKr/homebridge-zway/issues/69#issuecomment-272090172, or mute the thread https://github.com/notifications/unsubscribe-auth/AOtuiCjICitKvTlpSLTb1G1Vyhh8omgtks5rRc2LgaJpZM4K1AF6.

-- Wolfgang Domröse Von Eichendorff-Str. 23 37539 Bad Grund (Harz)

[WolfgangDomroese]

I'm one step ahead.

After studying docs and source code and doing a little bit debugging, I think:

The problem is to find the primaryDevice! The code looks through all virtual devices and the first primaryDevice is schown as accessory. In my case, "general-purpose" is the first. May be, in other firmware this is changed.

The solution for this is simple: I set a tag "Homebridge.IsPrimary" for the door-device. I found this in source code - but I did not see it before in the documentation :-(

Setting a second Tag "Homebridge.Service.Type:ContactSensor" makes (nearly) all fine. The sensor is shown perfectly in homekit - but I still do not see any change in state. Having a look at the zwave.me interface, the access sensor reacts perfectly. But nothing happens on iOS.

Any idea?

Am 12.01.17 um 07:51 schrieb SphtKr:

@WolfgangDomroese https://github.com/WolfgangDomroese Okay: After staring at this a bit, I think I see what's going on.

In 0.5.0-rc1 I added the |alarm_door| probeType as being able to create a Door/Window/ContactSensor. But, I obviously had to leave in the ability for it to bridge a |general_purpose| probeType device for other hardware models, and in fact those |general_purpose| devices is preferred. In your case--for whatever reason--your hardware is publishing /both/ of these, and only updating the |alarm_door| one. I'm not sure if this is a firmware difference or device configuration difference or something else entirely, but that's what it's doing.

Fortunately, I think I know how you can fix this: Just add the tag |Homebridge.Skip| to the |general_purpose| one, that is the one titled "Fenster_SZ". After that (and restarting Homebridge) it should ignore that skipped device, only see the |alarm_door| one that is updating, and you should be good.

Let me know if that fixes your issue!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/SphtKr/homebridge-zway/issues/69#issuecomment-272090172, or mute the thread https://github.com/notifications/unsubscribe-auth/AOtuiCjICitKvTlpSLTb1G1Vyhh8omgtks5rRc2LgaJpZM4K1AF6.

-- Wolfgang Domröse Von Eichendorff-Str. 23 37539 Bad Grund (Harz)

[SphtKr]

You said you might have to start with a new SD card...did you have to reinstall? If so are you sure you got v0.5.0-rc1?

I think you may still need the Homebridge:Skip tag. The Homebridge.IsPrimary will make that device be used to decide what kind of Service to publish, but the general_purpose device may still get picked for the Characteristic to use within the Door service.

You can tell which VDev is being used by running

DEBUG=ZWayServer homebridge

(If you're not doing that already.) In the console output, before the PIN code is shown, look for something like:

[1/2/2017, 12:08:30 PM] Initializing platform accessory 'Front Door'...
Mon, 02 Jan 2017 11:08:30 GMT ZWayServer Configured Characteristic "Name" for vdev "ZWayVDev_zway_6-0-48-10"
Mon, 02 Jan 2017 11:08:30 GMT ZWayServer Configured Characteristic "Current Position" for vdev "ZWayVDev_zway_6-0-48-10"
Mon, 02 Jan 2017 11:08:30 GMT ZWayServer Configured Characteristic "Position State" for vdev "ZWayVDev_zway_6-0-48-10"
Mon, 02 Jan 2017 11:08:30 GMT ZWayServer Configured Characteristic "Target Position" for vdev "ZWayVDev_zway_6-0-48-10"
Mon, 02 Jan 2017 11:08:30 GMT ZWayServer Configured Characteristic "Obstruction Detected" for vdev "ZWayVDev_zway_6-0-48-10"
Mon, 02 Jan 2017 11:08:30 GMT ZWayServer Found and configured Service "Door" for vdev "ZWayVDev_zway_6-0-48-10" with typeKey "sensorBinary.Door/Window"
Mon, 02 Jan 2017 11:08:30 GMT ZWayServer Configured Characteristic "Name" for vdev "ZWayVDev_zway_6-0-128"
Mon, 02 Jan 2017 11:08:30 GMT ZWayServer Configured Characteristic "Battery Level" for vdev "ZWayVDev_zway_6-0-128"
Mon, 02 Jan 2017 11:08:30 GMT ZWayServer Configured Characteristic "Charging State" for vdev "ZWayVDev_zway_6-0-128"
Mon, 02 Jan 2017 11:08:30 GMT ZWayServer Configured Characteristic "Status Low Battery" for vdev "ZWayVDev_zway_6-0-128"
Mon, 02 Jan 2017 11:08:30 GMT ZWayServer Found and configured Service "BatteryService" for vdev "ZWayVDev_zway_6-0-128" with typeKey "battery.Battery"
Mon, 02 Jan 2017 11:08:30 GMT ZWayServer Configured Characteristic "Name" for vdev "ZWayVDev_zway_6-0-49-1"
Mon, 02 Jan 2017 11:08:30 GMT ZWayServer Configured Characteristic "Current Temperature" for vdev "ZWayVDev_zway_6-0-49-1"
Mon, 02 Jan 2017 11:08:30 GMT ZWayServer Found and configured Service "TemperatureSensor" for vdev "ZWayVDev_zway_6-0-49-1" with typeKey "sensorMultilevel.Temperature"
Mon, 02 Jan 2017 11:08:30 GMT ZWayServer Configured Characteristic "Name" for vdev "ZWayVDev_zway_6-0-49-3"
Mon, 02 Jan 2017 11:08:30 GMT ZWayServer Configured Characteristic "Current Ambient Light Level" for vdev "ZWayVDev_zway_6-0-49-3"
Mon, 02 Jan 2017 11:08:30 GMT ZWayServer Found and configured Service "LightSensor" for vdev "ZWayVDev_zway_6-0-49-3" with typeKey "sensorMultilevel.Luminiscence"
Mon, 02 Jan 2017 11:08:30 GMT ZWayServer Loaded services for Front Door

You can look at which VDev identifier is used for your service, and see if that's the right or wrong one.

I will have to test this. I'm making good progress on a unit testing setup that will let me simulate some of these situations by putting your devices JSON directly through the code and seeing what happens.

[WolfgangDomroese]

Thanks. Working now!

Wolfgang Domröse (mobile)

Am 12.01.2017 um 20:50 schrieb SphtKr notifications@github.com:

You said you might have to start with a new SD card...did you have to reinstall? If so are you sure you got v0.5.0-rc1?

I think you may still need the Homebridge:Skip tag. The Homebridge.IsPrimary will make that device be used to decide what kind of Service to publish, but the general_purpose device may still get picked for the Characteristic to use within the Door service.

You can tell which VDev is being used by running

DEBUG=ZWayServer homebridge (If you're not doing that already.) In the console output, before the PIN code is shown, look for something like:

[1/2/2017, 12:08:30 PM] Initializing platform accessory 'Front Door'... Mon, 02 Jan 2017 11:08:30 GMT ZWayServer Configured Characteristic "Name" for vdev "ZWayVDev_zway_6-0-48-10" Mon, 02 Jan 2017 11:08:30 GMT ZWayServer Configured Characteristic "Current Position" for vdev "ZWayVDev_zway_6-0-48-10" Mon, 02 Jan 2017 11:08:30 GMT ZWayServer Configured Characteristic "Position State" for vdev "ZWayVDev_zway_6-0-48-10" Mon, 02 Jan 2017 11:08:30 GMT ZWayServer Configured Characteristic "Target Position" for vdev "ZWayVDev_zway_6-0-48-10" Mon, 02 Jan 2017 11:08:30 GMT ZWayServer Configured Characteristic "Obstruction Detected" for vdev "ZWayVDev_zway_6-0-48-10" Mon, 02 Jan 2017 11:08:30 GMT ZWayServer Found and configured Service "Door" for vdev "ZWayVDev_zway_6-0-48-10" with typeKey "sensorBinary.Door/Window" Mon, 02 Jan 2017 11:08:30 GMT ZWayServer Configured Characteristic "Name" for vdev "ZWayVDev_zway_6-0-128" Mon, 02 Jan 2017 11:08:30 GMT ZWayServer Configured Characteristic "Battery Level" for vdev "ZWayVDev_zway_6-0-128" Mon, 02 Jan 2017 11:08:30 GMT ZWayServer Configured Characteristic "Charging State" for vdev "ZWayVDev_zway_6-0-128" Mon, 02 Jan 2017 11:08:30 GMT ZWayServer Configured Characteristic "Status Low Battery" for vdev "ZWayVDev_zway_6-0-128" Mon, 02 Jan 2017 11:08:30 GMT ZWayServer Found and configured Service "BatteryService" for vdev "ZWayVDev_zway_6-0-128" with typeKey "battery.Battery" Mon, 02 Jan 2017 11:08:30 GMT ZWayServer Configured Characteristic "Name" for vdev "ZWayVDev_zway_6-0-49-1" Mon, 02 Jan 2017 11:08:30 GMT ZWayServer Configured Characteristic "Current Temperature" for vdev "ZWayVDev_zway_6-0-49-1" Mon, 02 Jan 2017 11:08:30 GMT ZWayServer Found and configured Service "TemperatureSensor" for vdev "ZWayVDev_zway_6-0-49-1" with typeKey "sensorMultilevel.Temperature" Mon, 02 Jan 2017 11:08:30 GMT ZWayServer Configured Characteristic "Name" for vdev "ZWayVDev_zway_6-0-49-3" Mon, 02 Jan 2017 11:08:30 GMT ZWayServer Configured Characteristic "Current Ambient Light Level" for vdev "ZWayVDev_zway_6-0-49-3" Mon, 02 Jan 2017 11:08:30 GMT ZWayServer Found and configured Service "LightSensor" for vdev "ZWayVDev_zway_6-0-49-3" with typeKey "sensorMultilevel.Luminiscence" Mon, 02 Jan 2017 11:08:30 GMT ZWayServer Loaded services for Front Door You can look at which VDev identifier is used for your service, and see if that's the right or wrong one.

I will have to test this. I'm making good progress on a unit testing setup that will let me simulate some of these situations by putting your devices JSON directly through the code and seeing what happens.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[TS-Tec]

@SphtKr Just recognized that commit 2f7f54d is not included in the latest release! Therefore, it still do not work until code is manually added. After it works as before!

[SphtKr]

@TS-Tec 😕 😱 😖 😳 🤦‍♂️ It's in the master branch properly! No idea how that happened, but you're right. Now I gotta compare and see if anything else is missing.

[SphtKr]

0.5.0-rc2 is published now which adds the missing commit and and another small fix for WindowCovering devices. I think I see now where my workflow messed up last time, should get it right from now on.