Philio PAN04-1A lost multichannel interview

[SirHegel]

Hello,

I have lots of Philio Pan04 (2-chanel) relays and they stopped working as multi-channel devices. So far they have worked flawlessly for years.

Some of them showed as "interview not completed", forcing interview does not proceed on these devices until each interview is clicked individually. MultiChannel interview does not work at all.

I can curl the interviewDone parameter to true, getting rid of errors in the management console, but obviously that does not bring the 2 channels back alive.

Any hints how to fix this?

I am using old and goldie z-wave board on raspberry pi, considering to upgrade it to modern hardware if I cannot get those working.

[SirHegel]

For details, if I use the zniffer and look at the traffic, when pressing "interview" on "MultiChannel", I can see following data:

27.09.2023 18:24:11 92 1 - -68 dBm - - Multi Channel End Point Find Report (00, FF, FF, 00, 00, 00)
27.09.2023 18:24:10 1 92 9.6 kbps -69 dBm,not available 9 - Multi Channel End Point Find (FF, FF)
27.09.2023 18:24:10 92 1 - -68 dBm - - Multi Channel End Point Report (C0, 03)
27.09.2023 18:24:10 1 92 9.6 kbps -68 dBm,not available 9 - Multi Channel End Point Get

So IMHO it seems that the device responds, but the z-way server does nothing with the data.

[Vovven]

Hi,

I have the same problem.
After reinterviewing one of my PAN04, multichannel interview failed and consequently it now only works as a single relay.
I thought it was a hardware pblm so I replaced it with another brand that has dual relays.
But maybe it's not hardware related, if others experience the same problem.
I'm on v4.1.1

[SirHegel]

Thanks for the feedback. I doubt it very much it is hw related. Relays which work normally lose channels if I click on force review, after which the channel review will not complete. IMHO it is somewhat unlikely all my relays have broken.

I could verify this by interviewing all philo relays, but most lilely I would lose all duall channels.

[SirHegel]

I realized I could perhaps look at the z-way server logs to see what is going on:

Code: Select all

[2023-09-28 10:50:04.904] [D] [zway] Node 91:0 CC MultiChannel: Dynamic endpoints
[2023-09-28 10:50:04.904] [I] [zway] Adding job: MultiChannel Endpoint (v2) Find to node 91
[2023-09-28 10:50:04.904] [D] [zway] SENDING (cb 0x5a): ( 01 0B 00 13 5B 04 60 0B FF FF 25 5A AC )
[2023-09-28 10:50:04.906] [D] [zway] RECEIVED ACK
[2023-09-28 10:50:04.910] [D] [zway] RECEIVED: ( 01 04 01 13 01 E8 )
[2023-09-28 10:50:04.910] [D] [zway] SENT ACK
[2023-09-28 10:50:04.911] [D] [zway] Delivered to Z-Wave stack
[2023-09-28 10:50:05.171] [D] [zway] RECEIVED: ( 01 18 00 13 5A 00 00 1A 01 BC 7F 7F 7F 7F 01 01 03 09 00 00 00 01 01 00 00 03 )
[2023-09-28 10:50:05.171] [D] [zway] SENT ACK
[2023-09-28 10:50:05.172] [I] [zway] Job 0x13 (MultiChannel Endpoint (v2) Find to node 91): Delivered
[2023-09-28 10:50:05.172] [D] [zway] SendData Response with callback 0x5a received: received by recipient
[2023-09-28 10:50:05.173] [D] [zway] SETDATA devices.91.data.lastSendInternal = **********
[2023-09-28 10:50:05.173] [D] [zway] SETDATA devices.91.data.lastSend = 6217911 (0x005ee0b7)
[2023-09-28 10:50:05.173] [D] [zway] Job 0x13 (MultiChannel Endpoint (v2) Find to node 91): success
[2023-09-28 10:50:05.173] [I] [zway] Waiting for job reply: MultiChannel Endpoint (v2) Find from node 91
[2023-09-28 10:50:05.299] [D] [zway] RECEIVED: ( 01 12 00 04 00 5B 08 60 0C 00 FF FF 00 00 00 BB 00 01 09 65 )
[2023-09-28 10:50:05.300] [D] [zway] SENT ACK
[2023-09-28 10:50:05.300] [D] [zway] SETDATA devices.91.data.lastReceived = 0 (0x00000000)
[2023-09-28 10:50:05.300] [D] [zway] Received reply on job (MultiChannel Endpoint (v2) Find to node 91)
[2023-09-28 10:50:05.300] [D] [zway] Node 91:0 CC MultiChannel: Endpoint with this generic/specific type does not exist
[2023-09-28 10:50:05.300] [D] [zway] Node 91:0 CC MultiChannel: Endpoint with this generic/specific type does not exist
[2023-09-28 10:50:05.301] [D] [zway] Node 91:0 CC MultiChannel: Endpoint with this generic/specific type does not exist
[2023-09-28 10:50:05.301] [D] [zway] SETDATA devices.91.instances.0.commandClasses.96.data.endPoints = 0 (0x00000000)

So the device responds to the interview, but z-way server tells "Endpoint with this generic/specific type does not exist". Does anyone know if this is a hardware problem related to the relay or is the problem in the z-way server?

I can verify that now all my philio relays behave in the same way if the interview is forced. Interview does not proceed automatically, but each interview has to be clicked manually and the MultiChannel interview fails and as a result, the 2-channel functionality stops working.

I am so frustrated I am planning to replace my z-way stack with some other system than z-wave.me.

[seattleneil]

I have 2 suggestions that you may want to pursue:

1. Z-Way has an advanced feature to "fix" devices that don't work correctly using postfix records. The postfix records are defined in the file /opt/z-way-server/automation/modules/ZWave/postfix.json. In looking at the file, I see an entry for PAN04-1B that changes the name of the device. A postfix record can do much more than change the name - it can block command classes, modify configuration settings, change command class data and even run JS code. In other words, in theory, I think it should be possible to "fix" whatever is broken with the multichannel interview. In practice, I think it's going to take a lot of trial and error on your part to figure out the fix.

2. See if Z-Wave JS UI works better. You can read the documentation here - https://zwave-js.github.io/zwave-js-ui/. This is the default Z-Wave stack used by Home Assistant and is completely open source. Installing standalone Z-Wave JS UI will not interfere with the Z-Way software installation (other than requiring you to stop z-way-server when you want to run Z-Wave JS UI and vice-versa). If you choose to install Z-Wave JS UI as part of Home Assistant, I would start with a fresh SD card (i.e., preserve the SD card with Z-Way installed) and do a clean install of Home Assistant on a second SD card. Note that Home Assistant requires significantly more CPU and RAM than Z-Way, so a Pi 4 is recommended. Running Z-Wave JS UI in standalone mode should work fine on a Pi 3. The user interface for Z-Wave JS UI is on HTTP port 8091 (vs. Z-Way using HTTP port 8083). Just don't run Z-Way and Z-Wave JS UI at the same time since you can't have 2 Z-Wave stacks controlling the same serial port.

Ideally, a Z-Way developer will provide a better response.

[lanbrown]

If they worked fine for years, what changed? Did you upgrade Z-Way? Is a downgrade a possibility?

[Vovven]

Of course an upgrade is involved.
The PAN04's were interviewed without problems many years ago.
It's impossible to remember what Z-Way version was used at that time.
Hence downgrading would be a guessing game as to what Z-Way version to downgrade to.

[lanbrown]

Why not try 3.2.3 and see what happens?

[SirHegel]

Thanks, Ian, for the suggestion, I will downgrade some releases to see what happens.