[question] How to correct behaviour of Philio PAN in-wall relay?

[Swiftnesses]

Hi,

It seems the current behaviour of zwavejs2mqtt is the same as the 1st post here (3 switches, wrong behaviour):

https://github.com/OpenZWave/open-zwave/issues/2426

How can I correct this (with OZW I would modify the xml files), looking for some insight as to how to solve this kind of 'issue'.

Thank you in advance.

[jcam]

If you would fix it by updating the XML files in OZW, then you would fix it by updating the json files in node-zwave-js. The device files are all in here: https://github.com/zwave-js/node-zwave-js/tree/master/packages/config/config/devices Instructions here (the 'how do I get this into my build' instructions still need work) https://github.com/zwave-js/node-zwave-js/blob/master/docs/development/config-files.md

[Swiftnesses]

Hi @jcam,

Thanks for the help - that's really useful! Is it possible to have local files for certain devices do you know? How would I integrate these changes - I'm using docker with a persistent volume in Docker for wavejs2mqtt.

[Swiftnesses]

It looks like the OZW fix was to remove: https://github.com/home-assistant/open-zwave/blob/94267fa298c1882f0dc73c0fd08f1f755ba83e83/config/philio/pan06.xml#L39

I'm not sure the config files you linked allow me to achieve that?

The config in question appears to be: https://github.com/zwave-js/node-zwave-js/blob/9fa9a67cd52321de801efdb4d324dfe023759e86/packages/config/config/devices/0x013c/pan06_0.0-1.7.json

[jcam]

Take a look at the difference between the 0.0-1.7 pan06 config file and the 1.8 pan06 config file... I wonder if yours is functioning as one version but detected as the other?

[jcam]

In any case, the driver configs are in the node-zwave-js repo, and maintained primarily by @AlCalzone, so the fix is likely to be over there.

[AlCalzone]

I am not entirely sure, but if I understand correctly, you'll need to add the compat flag preserveRootApplicationCCValueIDs to keep the root device (endpoint 0) from being hidden.

Part of the confusion might be that OZW starts counting at 1 and zwave-js at 0.

[Swiftnesses]

Hi @AlCalzone, sounds a good place to start.

Can you point me in the right direction of how I can test this running zwavejs2mqtt in Docker?

Many thanks for the help - appreciate it.

[AlCalzone]

@robertsLando Is an easy way to test device config modifications with Docker?

[robertsLando]

@AlCalzone Actually nope. I could create an api that exec the npm update @zwave-js/config command?

[robertsLando]

The problem is that this in docker needs a new volume in order to make it persistent

[AlCalzone]

Okay then (until #1238 is done) we need a branch that changes this config file and @Swiftnesses can build the Dockerfile.contrib with that.

[Swiftnesses]

Not sure it helps, but I always use persistent volumes, I wasn't sure if it was possible to implement such changes via a file (a little like OZW allows mapping of a custom config directory, with associated xmls.

[Swiftnesses]

This is what I currently have in my docker volume....

[AlCalzone]

The included configs are not in the mapped volume. You'll find them inside the container in node_modules/@zwave-js/config/config/devices. Once the mentioned PR is implemented, you'll be able to just add additional configs to the volume and zwave-js will load them over the included ones.

[Swiftnesses]

@robertsLando did I see a PR for this, if so, please let me know what I can do to test...

[AlCalzone]

@Swiftnesses please give https://github.com/zwave-js/node-zwave-js/pull/1399 a try.

[Swiftnesses]

@AlCalzone I use the mqtt docker (dev) by @robertsLando, what's the best way to deploy the fix?

[AlCalzone]

Using the Dockerfile.contrib: https://github.com/zwave-js/zwavejs2mqtt/tree/master/docker#building-a-container-using-dockerfilecontrib

[Swiftnesses]

To make it easier I've mapped "/usr/src/app/node_modules/@zwave-js/config" in my container to a volume and modified the file as per your pull request. Is a restart / node refresh enough (it's a b**** to include this node again!).

Thanks :)

[AlCalzone]

yep, just refresh the node info

[Swiftnesses]

I've been waiting for the zwave network to come back up - I have run a refresh and then rediscovered the node. A new switch did appear! Sadly the node stopped responding (likely unrelated) - I'll try again in the morning :)

[AlCalzone]

were you able to test yet?

[Swiftnesses]

Howdy @AlCalzone I did, but it wasn't working as expected - the extra switch appeared and seemed to control the light, but the status wouldn't stay 'on', after turning it on, the light does in fact come on, but the switch then turns 'off' straight away, so the status is all wrong :(

What do you need to debug this?

[Swiftnesses]

Apologies for the slow response - the sensor is in my workshop and it's horrible outside, plus my kids are at home (COVID!).

[AlCalzone]

I think what you're seeing is just another case of all the issues concerning wrong status reports.

[Swiftnesses]

Perhaps - I don't know, but my initial thought was without the switch showing the right status in Home Assistant, it's not going to be useful. Is there a fix coming, I'll retest if there is..

Thanks :)

[Swiftnesses]

@AlCalzone just wondering if the status report fix is coming, until then I'll try and replace the node...

[Swiftnesses]

BTW, I confirm it seems to be a switch status issue in Home Assistant. If I switch it on, the light comes on (the switch then goes off, the light remains on). If I quickly turn the switch on and off, the light goes off (obviously the switch goes off, as it always does 😄).

[AlCalzone]

The problem is that zwave was not designed in a way that really supports mirroring the true status of devices. Almost all the integrations work around that by polling (which can quickly saturate the network) if the device does not send status updates by itself (which only newer devices do).

I can "fix" the part of a wrong status after changing it through zwave-js, but if the device does not report manual changes, it must be polled regularly. That also means your mirrored status will be delayed.

[Swiftnesses]

The question is, is the status wrong because of something in zwave-js (with this device, or with status updates in general), or is it because we need to poll the device? I remember in OZW that I only needed to poll when I switched things at the wall (to ensure status matched), I didn't need to poll to get what we're fighting with here working - so my feeling is it's status related (a bug?).

[AlCalzone]

OZW does verify the value change after setting it differently and I'm going to try and change that in zwave-js too.

[Swiftnesses]

I trust in your knowledge - for now I'll try and find another relay. Give me a shout if I can help test anything!