[bug] Unknown manufacturer/product even though zwave-js eventually detects it #347
Comments
|
@robertsLando I guess the event recorder + fake driver we talked about would be an easy way to analyze this issue :-). |
|
@AlCalzone any clue? Could it be that the ready eventi is still triggered without the deviceConfig loaded ? |
|
@ahochsteger do you have a full log? Of both |
|
@robertsLando both logs are in files.zip (see also link in the description). |
|
FYI: @robertsLando, @AlCalzone I still had two more nodes (25 and 36) this morning that have not yet been successfully discovered which I just re-interviewed again a few times resulting in both showing up as "unknown". Again I can see the pattern, that zwave-js is eventually able to discover the node with the correct manufacturer name: |
Should be easy to find in the log. |
|
Okay it is not that easy. There are like 10 interviews of Node 25 going on, some in parallel, some are started after the node was successfully interviewed and marked ready. @ahochsteger you're likely to have some better luck not restarting the interviews all the time. Wake up the battery powered nodes manually, even multiple times in a row if necessary. My guess is that part of the chaos you're seeing is caused by multiple concurrent interviews - which should not happen, but zwave-js/node-zwave-js#903 and zwave-js/node-zwave-js#900 exist for a reason. |
And then So to answer my own question yes seems that the manufacturer producttype and id are retrived after the node is ready |
|
@AlCalzone thanks for your feedback! @robertsLando maybe this is something we can improve in the UI to give the user more feedback about what's going on to take informed decisions about what to do in case of problems ... |
@AlCalzone How can this be possible? I mean shouldn't a new interview abort the running one? @ahochsteger Do you have something in mind about how to help users? I mean there is the interview stage shown that should be enought |
|
@robertsLando concerning the undefined manufacturerId: |
Short answer: It should, but doesn't. I have several things I want/need to change here - so for the meantime the solution is: "don't" ;) |
@robertsLando no, I don't have any specific in mind yet. To be honest I did not trust the interview stage very much since I've seen nodes with no information at all that were already in the stage "Complete" and nodes that have been in the ProtocolInfo or NodeInfo stage for hours or even days. :-/ |
That means no communication with the node yet
That takes up the heap of the interview - so that is not suprising for battery-powered devices. IMO the main UX problem is that you don't see any progress here. |
What should I show so? |
|
You can't. There's no information exposed you could use. |
Hi, I have a TriSensor which is battery powered sleeping device suffering from exactly the same issues. A proposal - reuse the cache values before the interview is finished. I mean if the node has already been discovered and the supported classes have not changed and most likely the configuration either. So why not initialize the GUI and HA with the same values from the last successful interview? The status can be changed accordingly "interview in progress" or something. There is "end of interview" message so it is possible to know when the cache needs to be updated or the status to changed. I understand that this is more of a workaround/hack but it can be made optional behaviour if you know your network and don't play with the setting often. |
zwave-js does. Can't speak for zwavejs2mqtt, but AFAIK it listens for the node ready event. That happens pretty quick on subsequent startups. Your problem likely is that the interview didn't ever complete, so the node isn't considered ready yet. This causes z2m not to display the manufacturer info. |
I was talking for zwaveJS2mqtt GUI. The observed behaviour is not only for the sleeping devices. After restart the devices go from "Complete" to "RestartFromCache" mode but parameters are being removed if the values are in state "undefined" as shown in the original ticket. |
|
@robertsLando why are they undefined anyways? They should be in the zwave-js cache unless they have never been read before. |
That's a question I would ask to you, I sincerly dunno why this happens but the informations says that's undefined 🤷♂️ |
|
Again, can't tell without an interview that is not restarted all the time through user intervention. |
|
@ahochsteger Could you give a try to #376 |
|
@robertsLando I can definitely confirm that this helps to fix the problem since I found a way to fully reproduce the problem on my test device using the following procedure:
This always leads to "Unknown manufacturer" without this PR. Well done! :-) |
Is that before or after the re-interview? |
|
As I see it the "unknonw manufacturer" is shown just after pressing the button on the door sensor 3x - so I would say it is after triggering the re-interview in the UI but before the re-interview is finished, but I have not analyzed the logs to confirm the exact times of the events. But I just found out an important difference which may have to do with the way I'm waking up the device: Waking it up just by 1x pressing the button is now working reliably (maybe due to other fixes in the past) so I won't have to do the 3x press anymore. Here are the logs where this can be further analyzed, if it is of any help: |
|
@ahochsteger what a mess 😆 BTW glad that this problem seems fixed now, I have added many different checks that should fix this in all cases, even with messy devices |
|
@robertsLando FYI, I'm still experiencing this, specifically with two Schlage locks ("Allegion - BE469"). One of them, Node 16, shows correctly in the dashboard:
The other, Node 5, shows as unknown in the dashboard:
zwave-js version: 6.1.1 zwave-js log ( Perhaps my z2m version doesn't contain this fix? |
|
|
Thanks, @AlCalzone. I was probably impatient. 😂 I'm still able to interact with the node and its entities, so the fact that it doesn't return info isn't the end of the world. |
|
I have something similar: Zwave JS integration reads the device just fine. But the addon dashboard shows as Unknown Manufacturer:
Actually everything was working fine until all of a sudden I lost all devices. So I Zwave had to find all devices again, and the battery operated devices got left behind. When I managed to add them back again one of the got its full information (Aeon Minimote) but a door sensor got stouck with Unknown Modifier. Apart from the name, the device is working just fine as the integration sees it correctly. |
|
Try yo manually wakeup your devices |
|
Mine have started doing this again today.. They have been up and running for weeks with no issues |
|
Please post a driver log (level debug) of the startup. |
Here you go, thanks. I also have an issue with node 3, I don't have that node and I cannot delete it, it is always stuck on ProtocolInfo |
|
That's not a driver log. ==> https://zwave-js.github.io/zwavejs2mqtt/#/troubleshooting/bug_report?id=driver-logs |
oops sorry |
|
@markrennie71 The log claims the nodes are ready. Can you share your cache files As for node 3: you're looking for the "remove failed node" function in zwavejs2mqtt. |
|
The nodes all work in home assistant but in zwavejs2mqtt they look like the attached. also here are the files you requested. PS the remove failed node doesn't work in this case. I guess I could reset the stick and start again, but that is a pain in the arse :)
|
The
Why not? What's in the driver log then? |
when I try I get the following, even thought this is 100% not on my mesh `Error while calling api removeFailedNode: The node removal process could not be started because the node responded to a ping. |
|
Please share a driver log where you try that. |
|
edit, I tried about 10 times and nothing, then out of the blue it worked.. odd. Thanks for your help |
|
I lost power last night. My pi4 went down and after the power came back on .. the unknown devices appeared. This is not the first time. The last time I decided to do a zwave-js upgrade and perhaps this problem would remedy itself. That was totally wrong and I ended up loading 45 devices from scratch. I was not a happy camper. It took a lot of my time. This time I will leave it alone and see if it remedies itself. Shouldn't reloading the node-js file from backup fix this? This is very un-acceptable. |
Version
Build/Run method: Docker
zwavejs2mqtt version: 1.0.0-rc.1 (master branch)
zwavejs version: 6.0.2
Describe the bug
(For updated logs and similar problems with nodes 25+36 see: [https://github.com//issues/347#issuecomment-767346459])
I still have the problem with "Unknown manufacturer / product" for some battery-powered devices that take a longer time to be interviewed successfully, esp. if they are a bit further from the Z-Wave controller away.
Most of the time it is possible to trigger a re-interview in zwavejs2mqtt and waking up the device which causes the device to fully show up in the nodes table.
Unfortunately some devices show then up as "Unknown manufacturer/product" which cannot be changed to the correct names by re-interviewing again, even though zwave-js is able to successfully detect the name - although it may take a longer time (e.g. 20-30h).
Here are screenshots for the 2 problematic nodes (25, 150):
The attached logs for both zwavejs2mqtt and zwave-js show about 30 hours from a fresh start (empty store directory) up until after the problem occurred again and include all the relevant config files: files.zip
The problematic nodes are: 25 and 150 - both Shenzhen Neo NAS-DS01Z Door/Window sensors.
These are some interesting log lines from zwavejs2mqtt:
Interesting is, that it seems that zwavejs2mqtt already got the correct manufacturer and product names but I don't remember to have seen them in the UI - otherwise I wouldn't have triggert a re-interview that often. One day later the device is not shown empty in the UI anymore but shows up as "Unknown manufacturer/device".
These are interesting log lines from zwave-js (from date 2021-01-25 - btw. can we output the date in the zwave-js logs too?) where a re-interview of node 150 has been triggered:
A related question:
What happens, if a device reports data (e.g. door opened/closed) while it has not yet been successfully interviewed?
I have the suspicion that this may trigger a race condition, but I have not been able to track this down.
Hopefully the logs and config files give enough information to find out what's going on.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
zwavejs2mqtt should be able to recover from an "Unknown" device state as soon as zwave-js is able to correctly detect the device.
Additional context
This issue has already been reported as part of #233 where fixes have been committed which did not reproduce the problem until now why I'm opening a new issue with new information.
The text was updated successfully, but these errors were encountered: