Device interview fails

[maros]

After experimenting with my test/development network and including more devices, one of the old devices, a Fakro ZWS230/12 (one that already worked properly) stopped working. Expert UI says that "Device interview stage is not complete".

When I take a look at the interview results, only Basic, ManufacturerSpecific and Version are complete. Forcing a re-interview produces the same result. However, according to the logs all interviews finish with a success message: see https://gist.github.com/maros/91b2074e8729e868a259

Cheers
Maroš

[pofs]

Looks like device stops responding to anything after it sends ManufacturerSpecific report.
So z-way attempts to interview remaining command classes, it successfully sends requests to device (they're reported as delivered), but device answers nothing back. That's why some command classes are stuck in the interview stage.

[maros]

Yes, it's certainly due to an unreliable device. Excluding and re-including fixed the issue. However, I believe that this can and should be fixed on z-way side. Let me explain the reasoning behind this:

Currently I'm running a "production" network with 45 Zwave devices (on Vera and planing to switch to Zway), as well as a development/testing network with 7 devices on Zway. After re-interviewing all my devices in my test network half of them did not come back properly and had to be excluded and re-included. A Fibaro FGS-222 turned into a dimmer, the Fakro ZWS 230 had the aforementioned issue as well as a Philio PAN06. While this is acceptable in a test network, it is not acceptable in a production network where half of my devices can only be reached with considerable effort, eg. by climbing a ladder, opening electrical distribution boxes, ... When browsing through the form I also get the impression that I'm not alone with these kinds of issues.

I also agree that this is most likely due to a faulty implementation on the device side and in no way a fault of the Zway software. However it needs to be addressed on the Zway side, since getting firmware upgrades from the manufacturers for dozen devices is almost impossible (and not even supported for older devices). So - without knowing if this is a feasible approach - I would like to propose a solution to fix these kind of issues once and for all:

Once an interview succeeds every interview step should be saved to a backup file. If a subsequent interview fails there should be an option in ExpertUI to partially or fully restore the last successful interview for a given device.

What do you think about this?

[remoticz]

+1

[PoltoS]

Why to re-run interview if the last one was successful?

[maros]

Well, that's a good question. I can think of two reasons why this might be necessary

1) the device does not work as expected (re-interviewing a device is often suggested in this forum)
2) network reorganization after a device was moved to another location or multiple new devices were added

[remoticz]

What bothers me is that the device descriptions do get lost once in a while. That should not happen I think

[maros]

Just had another case of messed up device interviews. After adding twenty devices to my network, I saw in the routing matrix that some devices couldn't reach their neighboring devices (many red squares). Pushing the 'Update' button in the routing screen fixed this, however some devices completely changed. Two Fakro shutter blinds suddenly turned into battery operated binary sensors - at least that's what the interview screen shows. Even a forced re-interview does not help - the interview always tries to get info on the Battery and Wakeup cc which obviously fails

[PoltoS]

@remoticz: more info needed. What is lost?

[pz1]

I remember having posted about this on Github quite a while ago. The situation is that initially I included successfully a device. Selected and saved the device descriptor. Then later because of some problems the device needs a re-interview. Apparantly the link to the device descriptor gets lost. That is awkward, because sometimes it is hard to find the correct device descriptor (see for example Fibaro Universal sensor about which I did suggest some corrections).
I don't know if this descriptiopn link is removed deliberately or accidentally. IMHO it should be kept.