I commented about odd z-wave at node initialise. I have reproduced this on several networks. All are running 3.01 on pi 4 openHabian latest all patched to latest.
It only happens at initial start of the binding or after a soft reset or disable/enable. In normal use it is not seen and therefore is not a significant issue. It just slows initial start.
Not sure how node 1 does not know how to route to node 1 or indeed why this goes out over the network.
The current binding is based on reverse engineering since the lates nn Z/IP standard is not yet publicly available.
You also know the proper place to file issues for the binding is on GitHub since users here in this forum can be of no assistance.
If this is a large concern for you I am sure @chris would also consider any PR you submit…
This thread is otherwise not helpful and, IMHO, should be locked by @moderators as off-topic flaimbait.
I am not sure it is an issue with the binding or I would have put it on Git. Also not sure how this can cause you so much offence. If others can also reproduce then it can go on Git but as I said it is not a big issue in this guise.
I can’t see any reason why node 1 should not attempt to loop back to node 1, it seems a reasonable “echo” validation of at least part of the normal pathway in the absence of any devices. Useful for avoiding jammed radio channels, perhaps, depending how far “out” the loop occurs.
And should someone else actually respond to node 1 query the controller would know to do something else.
That is a good thought that would explain why the firmware might allow this. Alas it is failing as you can see so the firmware is not capable to do that check but does either allow it or has a bug that causes it. Do you see the same on initialisation?
I can’t see any obvious changes in the code in the binding around that area so I can’t see it is a binding bug but possibly it is something new in OH3 code that causes the binding to do something odd.
Well, perhaps the part of this loopback that is visible to you “Is there a node 1 there?” - is expressly expected to fail. Else we’ve detected another controller and a fight would ensue.
Remember being node 1 does not say it is a controller. A controller can have any id but as it is normally the first node in a network it is commonly node 1. If you add a secondary then transfer primary role the primary controller can have an id other than 1.
But this one thinks it is going to be node 1,no?
Do an experiment - make yours into node 99 and look to see if it tests for the existence of another node 99 before doing any other business.
I don’t see why this is viewed as an error.
The reason I see it is an error because you can see it can not find a route. You can see it is trying all sorts of routes and all are failing ending in trying an explorer. This also fails.
I can’t remember if this behaviour was there in 2.5 but I never saw it bit possibly others did. Does it matter? Well not a lot other then as a bit of an oddity in this case.
Do you see same if you run Zniffer during start?
Logically a loopback from a controller to the same controller does not make a lot of sense to go over the air.
I don’t have zwave.
Why not? If it can “see” its own transmissions, it’s getting basic validation of tx/rx path.
I suspect it’s more about confirming there is not a duplicate node out there.
I don’t think that is a check z-wave makes. By design a network has a unique home id and each node is assigned a unique id by the controller. It would only be possible if there was a bug in the controller firmware and I know these controller firmware’s are sound.
Still not convinced it is a binding issue. I will have to dig through how the OH3 binding initialisation works and see if I can work out why the controller is being treated like a slave node. Certainly something that should not happen but if nobody else can see it then it can’t be a bug.
Just FYI. there have been no changes in the initialisation of 2.5 and 3.0.
Cheers Chris, I thought it was not a binding issue.
I think it must be coming from further up the stack.
Unless the inevitable failed calls to controller node from controller node causes problems it probably is not worth more time. I guess it could tip a poor network over the edge at initialisation as it will cause delays and more queuing while the binding and controller manage the failures and retries of the unnecessary calls. If whatever has changed causes other odd things this observation might help track down what is going on but other than that it is just a minor delay at start.
