I noticed today that the Zwave dev branch still seems to have the old multi_instance_association problem. When you include a device with this functionality (e.g. Fibaro FGS223, Qubino ZMNHBD etc…) with the dev branch then the device is not correctly reporting updates to the different endpoints. I am using the dev branch from 20170528.
When I include the same device with the actual snapshot (937, Zwave binding from 20170602) everything is fine.
If the device was included with a “good” version of the Zwave binding, then it also works correctly in the dev branch. However, inlcusion with the dev branch itself will lead to the issues which are solved since January in the main branch.
Please can you provide logs showing what the problems are and what configuration you have. This is quite a complex issue and it depends also on how you configure your device, so it’s hard to know what is going on. There hasn’t been any change in this area, so I’m not sure how a problem could now “be back” and we need to understand what’s actually happening…
Some of your statements make no sense. The inclusion for example doesn’t matter - what matters is when the binding starts up - if there’s no XML then the binding will do a complete initialisation of the device. This initialisation includes setting the associations where they are configured to be set to the controller in the database.
When you swap from the development branch to the snapshot branch, the XMLs are not compatible. This will cause the binding to initialise the device in the same way as if the XML was not there - the binding should then reinitialise the associations that are set to be automatically configured.
So… If these are the associations you are talking about, I don’t understand how it’s possible that it works if the device is initialised using the snapshot, and you then change to the development binding since the binding should reconfigure them.
Anyway, please provide the logs and the configuration and I can take a look at what’s happening.
To explain in more detail:
I used the snapshot branch until 6 weeks ago. All devices were included and initialized with the snapshot branch orginally. The endpoints were reporting correctly.
After siwtching to the Dev branch (with a fresh install, no XML files left from snapshot branch) the devices continued working correctly.
After excluding and reincluding three of the devices with the dev branch this weekend, the only endpoint reported was 0. I tried it multiple times, letting the system hours to complete initialization until the new XML was written. But only endpoint 0 was reported.
I then set up a fresh test install of the snapshot branch, excluded the devices and reincluded them with the snapshot branch, waited for initialisation to complete and checked that endpoint reporting was ok.
I then restarted the dev branch where the devices were now initialised (with their new node numbers from the inclusion in snapshot branch). And endpoint reporting works fine in dev branch.
I tried this with three different devices and they all needed a first inlcusion and initialisation with the snapshot branch to report endpoints correctly again.
So I assume that the initialisation process in the dev branch might be the issue. It takes very very long for all my double relay switches (FGS223 and ZMNHBD), first initialisation often only after hours (it hangs in status STATIC_VALUES for all these nodes very long).
So my experience is that the way how to include makes a big difference. An inclusion only with my Aeon Z-Stick 5 (without OH running) also never leaded to correct endpoint reporting. It is probably not the inclusion, but the initialisation steps right after inlcusion.
For a debug log: Which moment do you need?
Ok, so this doesn’t really make any sense, sorry. As mentioned before, the inclusion itself does nothing in the binding - it’s the initialisation that does all the work, and this is done any time there is no XML. My guess is that there is something else at play.
I guess it would be good to know your configuration, and get the log from the initialisation (ie no XML file restart) and then to see what is being reported.
Ok, so I just choose the advanced option ‘Reinitialise node’ in Habmin and send this as debug log?
Yes - that should be fine - thanks. Make sure there’s also some reports in the log after initialisation…
ok, I started reinitialisation for NODE 64 (Fibaro FGS223) at 13:03. It is still not finnished with initialising, hanging in ‘STATIC_VALUES’. The first 20 minutes of debug log are here:
And finally the initialisation completed at 14:48 after 1 hour and 45 minutes (Node 64, starting at 13:03).
The complete 45MB debug log can be found here:
https://filebin.ca/3P2kiREkSrsy/ohlog1450.log
However, the reinitialisation did not bring a solution for the problem of endpoint reporting. The device still is only reporting endpoint 0.
From my experience up to here the device will report endpoints again after a reinclusion with the snapshot branch (why ever…)
Any clue, @chris?
Thanks. I don’t know why it would take so long to initialise, but I’ll take a look and see. Maybe it’s worth excluding and adding back in to see what the difference in the initialisation is? (would be good if you don’t mind).
Ok, I will try that tonight. Can’t do it at the moment as exclusion and inclusion require my physical presence for pushing the button on the device 3 times…
Just to clarify: Initialisation with the snpshot branch (which according to my experience will make it work) or the dev branch ?
Try the snapshot and we’ll see what the difference is…
In the log above, the associations don’t get set at all.
Don’t worry about the other log for now - I will take a look at why this is happening first.
Ok, this explains also why the initialisation with the snapshot branch helped. The snapshot set the correct associations and they were not overwritten when initialising the nodes with the dev branch. On the contrary initialisation only with the dev branch therefore never set the associations (which explains my experiences).
Well, I tried last night to exlcude and reinclude the node 64 with the snapshot branch. As the initialisation took extremely long I even let the process continue the night long. However, even this morning at 6:30 am the initialisation process for the node formerly known as 64 was not completed (still hanging in STATIC_VALUES). I stopped the initialisation then and restarted my production environment with the dev branch…so sorry I do have more than 100MB of debug log but not the final initialisation…
Well, I did a couple of more tests tonight and my experience (from a user perspective at least) is different.
We agree that the dev branch binding does not set associations correctly while the snapshot does. If it was true that the initialisation of the node (e.g. writing a fresh xml file) does all the work then it would be possible to “heal” a node that was first included by the dev branch just by operating it in a fresh install of the snapshot. The snapshot would discover the existing node, set the associations, write its own xml file and things should be fine. But this is NOT the case. If the node was included for the first time with the dev branch it remains with incomplete associations even after a later initialization with the snapshot, only endpoint 0 reporting.
On the other hand all nodes first included with the snapshot (or even with the old 2.0.0 release version) work perfectly with all versions (dev branch, snapshot, release).
So, my finding is that the binding seems to set the associations only in the moment of inclusion of a new node, not when initialising a node which was already a member of the network (tetsted with both snapshot937 and release version 2.0.0).
This is definitely incorrect - sorry. The inclusion doesn’t do anything - the initialisation is where all the good stuff happens. Initialisation is performed any time there’s no XML file.
But could it be possible that the binding performs more/different initialisation steps when it works on a first inclusion?
No - there’s no way this can happen. There’s no link with inclusion. The initialisation is the same each time.
But why are the associations not set on already included nodes? I tested it several times - reproducable…
I would look at the logs to answer your question? What do they show?
It’s worth noting that the binding will only set associations if they need to be set. So it reads the associations, and if they aren’t set correctly, then it will set them. Maybe this is what you are seeing?