[SOLVED] Insufficient time to complete transaction for RequestNodeNeighborUpdate for large z-wave networks

Thanks.

As mentioned in the PR, I agree with your assessment of the issue, but would like to solve it in a different way as your implementation will have side effects. I won’t go into the details here as we will duplicate everything.

1 Like

I don’t care if it is related to network layer or application layer. Heal does not work. Either the controller is busy with something (e.g. getting illumination report or temperature report) or the device is busy (e.g. sending illumination or temperature report) while the neighbors are also requested. There was a change in handling this properly in May or June 2019. Since then heal does not work for my three Fibaro FGMS-001. Waking them up manually during a heal solved the problem. I give it up now.

Maybe it doesn’t work - but we need to know why - and that does require someone to care even if you don’t!

I spend an aweful lot of time working on OH and I’m sorry I’ve not had the chance to look at this for you, but there are a lot of other things I also need to work on.

My apologies again.

3 Likes

No Chris
Thank you for everything you do and tirelessly diagnois all the zwave and zigbee stuff, maintain these great bindings, help in the forum… THANK YOU!!!
Many people use OpenHAB because the zwave is the best out there (from what I’ve heard)
I personally think you are OpenHAB’s greatest asset
I think I can speak for the entire community
Thank you

4 Likes

@Andrew_Rowe @chris

Just to make that clear. I am exactly the same opinion and grateful for all the support here. Thank you very much. :slight_smile: I’m just trying to share my ideas here to help solving the problem. Even if my ideas are wrong. I’m sorry.

1 Like

That is what brought me here after struggling with the mess that is openzwave. It seems especially bad for North American users.

1 Like

:+1:

4 Likes

I’ve worked on a couple of products in my career that implement z-wave hubs, but they all wanted to work in their own walled garden that only officially supported a handful of devices. Even they had significant issues over the years and were unable to even work with the new products that the same company was releasing. One case caused a lock to go through a set of batteries in a couple of days. Between my vivint system zwave going offline every couple of days and looking at the reviews for the smartthings hubs, I ended up here!

3 Likes

I don’t have to know that because I’m just a simple Z-Wave user. I don’t care whether there are two different layers in which the devices communicate with each other. In the end, the heal doesn’t work. I’m just trying to explain logically what might have changed in the meantime, that it no longer works. If my assumption is unlikely, then OK.

It is only surprising that heal works for some and not for others. I only have 10 nodes. So there shouldn’t be any problems. Which actually never existed until mid-2019. If it were a fundamental problem, everyone would have it. Probably the number of unreported cases is very high because many have simply deactivated the heal.

openzwave in most of the hubs is a very old cut so it is hard to compare to openHab but have to agree zwave in openHab is very good.

I would suggest that a lot of people suffering issues here with heal are those with more unsolicited traffic (reports configured) on their nodes and with higher node counts. I tend to use PC program when I need as it reads the topology from NVM and has many tools to resolve issues on the network. They are not perfect but they work. You can also back up the NVM on your USB so it is worth doing just for that.

Judging by some of the fixes people suggest, the timeouts are because the nodes are sending a load of reports at the same time as a network rebuild is on. The issue is not so much an issue with openHab other than possibly sending node updates more like PC programme does. For more normal levels of traffic and lower node counts probably no issue.

I still have no idea why anyone would rebuild their network every day but that is their choice.

It is better in my opinion to do it to make it good enough then let the network settle down. If you rebuild too often you will lose all the good work done by explorer frames and other mechanisms that help your network find a stable reliable state.

1 Like

I understand that early on, we offered to work together with openzwave but they declined the offer.

They have a version that works with a UZB7. Probably really good but not in any of the hub software. The thing is Z/IP is the only way forward for zwave so this line of development all becomes a bit of a dead end.

That’s fine, but it’s also the problem with OH - we provide a lot of tools, and many people expect a lot of information so I try and provide this - sorry.

This will change - I’m working with Silabs and they will be opening this up in future (later in the year). The ZIP requirement will be dropped although it’s unclear exactly what interfaces it will be replaced with (Silabs are still discussing this internally). Hopefully I can influence this direction to avoid host applications which is the current thought, but let’s see.

Unfortunately the binding requires a near complete rewrite to resolve other issues to allow certification so I don’t get my arse sued. This is my main focus right now.

Surely it is your choice to go for certification or not.

What areas are you having to revamp? Now I know Z/IP is not the only way forward it makes the current binding a lot more interesting.

Well, not really. We should not be claiming to support ZWave without certification as that’s a trademark violation.

1 Like

and thank you Alex for that. Your determination and curiosity has solved plenty of quirky bugs

1 Like

It will be pretty much a rewrite, so it’s a little bit of work :wink:

1 Like

OK, now this discussion is starting to get interesting

If not completely off topic now :wink:

1 Like

Well it does indicate why it might be better to use a workaround than you having to look at a change for this code line.

If it is indeed just on bigger networks or ones with a lot of reports it would be better if people helped themselves by reducing reporting as reported as helping in this thread.