Attaches to Fibaro Roller Shutter incorrectly

[MikeHCam]

Hi I have homebridge and homebridge-openzwave installed and running on a Raspberry Pi 3B. I have linked it to my homekit hub on an apple TV. I am attempting to test it with a Fibaro Roller Shutter 3 (https://www.fibaro.com/en/products/smart-roller-shutter/). The device is currently wired up with its two relays lighting up two led strips rather than attached to the blind, as I want to be sure it works before I install it outside. If I press the hard switches the led strips light as you would expect. I believe the Fibaro should appear to the zwave controller as two, multi-level, switches - one to open the blinds and one to close them. But I admit that this is my first attempt to use zwave so that may be an error on my behalf. I note that openzwave has a definition for this device, but I don't pretend I can understand all the settings. It actually connects as a single switch, which I can see could be mapped to the two separate switches (turning it on = open blinds and fires one switch, turning it off = closed blinds and fires the other), but turning the single switch on or off in the Hombridge UI, or homekit UI, has no affect. Any help would be welcome, including explaining why I am missing the obvious, if I am. And apologies if I am. Thanks

[MikeHCam]

More information... I now do not think this is an issue with the hardware or with openzwave or openzwave-shared. It may be a device mapping issue which would mean it should not necessarily be an issue here. However....

I continue to dig deeper (and learn more) and I found the test examples in /usr/local/lib/node_modules/homebridge-openzwave/node_modules/openzwave-shared.

In particular, I edited test2.js and changed the function called on 'scan complete' to be:

zwave.on('scan complete', function () {
    console.log('====> scan complete');
    // set dimmer node 5 to 50%
    // zwave.setValue(5,38,1,0,50);
    // zwave.setValue({node_id:5,   class_id: 38,   instance:1, index:0}, 50 );
    console.log();
    console.log("Deploying fully...");
    zwave.setValue({ node_id: 4, class_id: 38, instance: 1, index:0}, 0x63);
    setTimeout(
    () => {
        console.log();
        console.log("Retracting fully...");
        zwave.setValue({ node_id: 4, class_id: 38, instance: 1, index:0}, 0);
    },
    10000
    );
    zwave.requestAllConfigParams(3);
});

Then I stopped the homebridge server (to allow access to the Aeotec usb zwave controller) and called: node test2.js

And this appeared to work. That is...

After a delay for the scan, the first call to setValue caused the blind controller to close one relay (lighting up one led strip) for a second or so, which would signal to the blinds to deploy. Ten seconds later the second call to setValue caused the blind controller to close the other relay for a second (lighting up the other led strip), which would signal the blind to retract.

I have attached a log of the output from the console. working.log

This worked every time I tried it, very reliably! So I think the hardware, zwave link, openzwave and openzwave-shared all appear to be working.

But if I use the homebridge UI to set what I presume is the same value to either maximum or zero, nothing happens at the controller. To be precise, I immediately restarted the homebridge server, and found that I could turn the accessory on and off in the Accessories tab, but the blind controller did not do anything (no led's lit).

Other times I have tried this, the accessory turned on and immediately off again in the UI (with no result at the controller).

I now suspect the default manufacturer's definition for the device may be wrong, or it may be assuming the device is operating in a different mode.

So that is my next piece of research!

I would love to find a log file or error message that might throw some light on this. The homebridge log file doesn't show anything (on whatever settings it is on by default).

Any help welcome, and again my apologies if this isn't actually an issue with this software.

Mike

[MikeHCam]

Apologies that this is becoming a log of my findings - but I may as well continue.

Firstly I have now persuaded openzwave to output a log file! Horah!

Unfortunately the online log interpreter on the openzwave web site (http://www.openzwave.com/log-analyzer/) is not proving helpful as it insists that it is being compromised by the presence of the zwcfg_*.xml file when the log file is being written. There is no such file on my pi anywhere , but it insists there is. There is a file called ozwcache_0xcf66e7f1.xml which I suspect may be the culprit. Unfortunately every-time I delete it and reboot the server to create a new log file, the system recreates it. Wonder how you stop that?

So my current test is to start the homebridge server, to switch to the accessories tab and to try to switch the roller controller on, once. And then to look at the log file.

By manual inspection of the log files it would appear that the zwave scan seems to work correctly. It finds the usb stick and the blind controller and interrogates it successfully (although I don't know enough to spot problems).

When I attempt to switch the roller blind controller on, I can hear the zwave signals flying by the emf interference with my computer's speakers (v useful actually!), and according to the log file it attempts to:

2020-07-07 12:33:49.190 Info, Node004, Value::Set - COMMAND_CLASS_SWITCH_MULTILEVEL - Level - 0 - 3 - 255

Which has got me stumped already.

The equivalent line from the log file of the successful direct use of openzwave (see above) is: 2020-07-04 19:04:55.213 Info, Node004, Value::Set - COMMAND_CLASS_SWITCH_MULTILEVEL - Level - 0 - 1 - 99

The latter works, the former doesn't.

Possibly in an attempt to rectify the issue, the non working log file then has a second attempt to set the value:

2020-07-07 12:33:49.511 Info, Node004, Value::Set - COMMAND_CLASS_SWITCH_MULTILEVEL - Level - 0 - 3 - 99

which would appear to be the correct value, but the wrong instance (I think 1 v 3), and I don't know what the controller would think of being told to set to a different value so soon afterwards.

But please remember that although I am learning, the fog is only lifting slowly. So this interpretation may be nonsense.

I will continue to dig/learn....

All help welcome...