The parameter 41 is defined as “Treshold time for power reporting”, which seems (with some slight wording changes) a duplicate of the parameter 42 definition. Parameter 42 actually does exist and works as advertised.
I checked multiple versions of the manufacturer manual (2.2-1, 2.2-2, 2.5, 2.6) and nowhere is ever spoken of parameter 41.
Additionally, both the Z-Wave Alliance and OpenZWave also do not list this parameter for this device.
Lastly, I tried setting the parameter, but could not detect any changed behaviour.
Can we delete this parameter from the definition to avoid any confusion?
Looking at the details, the description for 41 is confusing. It is the time between periodic reports.
@Chris last updated that device so I will give him a chance to comment.
I looked in our manual and at the zwave alliance entry and do not see parameter 41 either. Sometimes we add parameters based on input from vendor support, especially if the manual is confusing.
I have some motion sensors that are missing a configuration parameter that is in our database but some variants have that configuration.
I would not have made any significant change - certainly I would not have added such a parameter and I probably just updated a channel or something like that.
Clearly it is not available in your version, but my guess is it is may have been available in older versions of the product in which case it should be removed from newer versions. We would need to work out what version this parameter was removed, and then create a new database entry.
I don’t know. Normally we set the versions to be ALL so that newer versions will work out of the box. If there is then a new version that changes something such as the configuration, then we create a new entry.
My guess (and it is a guess as I’ve not found a V1 manual) is that V1 had this parameter as this entry is probably a couple of years old. I could probably find out from my contact at Qubino - let me do that first…
I understand, and that seems like a good approach with regards to usability. However the apparent drawback is that information is lost about the actual firmware version that the entry was based upon and tested with. It might be an idea to add an extra database field “Verified-for-Firmware-Versions” (or something). So that we know for which firmware versions the present database config is actually known to apply. So while “Firmware Versions” contains “ALL”, in this case, the “Verified-for-Firmware-Versions” would have contained “1.0” (if your guess is correct, that is).
Sometimes Sihui has a copy of the original xml in his email. That would have the version information. The configuration parameters are not in that data though.
In theory, we have access to the XML file, but that doesn’t necessarily help. Someone can use the wrong manual to add parameters, and we don’t know if (for example) V1 has a specific parameter or not. Unless we are sure that the manual matches the version, then I don’t think it really helps.
The other issue is you don’t know 100% that the person who creates a device even identifies the device correctly - this is normally only an issue where devices are called names like “mini-dimmer” or whatever and you find there are a bunch of different “mini-dimmers” available that are all a little different. Here at least Qubino have a clearly identifiable product name…
I appreciate it’s not perfect, but we do our best. Ideally, ZWave Alliance, or manufacturers would produce a database of their products, but I’m not really aware of anything that is of any real use.
I understand what you are saying, but I still think an easy improvement can be made here. Maybe not by literally adding the database field I mentioned earlier, but the idea behind it is still worth exploring IMO.
As far as i know, for this particular Smart Plug we now have the following situation:
Either the current thing/parameter definition comes straight from the manual that is currently referenced by the database. In which case having parameter 41 in the database is an error, because it simply isn’t in this manual.
Or (more likely), the current thing/parameter definition in the database comes from one or more other sources (a manual? vendor contact? user testing?) that are not named as such in the public database. Maybe you or another developer could identify these original sources from memory or mailbox or from somewhere else, but this information is not accessible to the public, so the public has no way to know where the current definition comes from.
I think it would probably help if the database would contain information about the sources that were used for creating a thing definition.
This offers 2 benefits IMO:
It is easier to investigate situations like the current one (with things having multiple hardware/firmware versions that differ slightly)
It enables anyone to investigate, not just the developers who have access to the source information (meaning, this would possibly lighten the dependency on the developers to do this work).
I guess what I’m saying is: obviously I’m glad you and Bruce are helping me here, but you could probably enable the wider public to do (part of) the work here, by adding extra information to the database.
I will see if I can add a verified version field - I’m just not sure it will be useful as it requires people to go back and edit the database once they confirm that it works. Most people tend to do the minimum required to get the device working. Initially, I didn’t enforce adding information such as the overview and wakeup, inclusion/exclusion information, and no-one filled it in. The database now won’t allow people to request a device to be approved until this is filled in, so we have a better quality database now…
However, I think that generally people will not go back and add their version number to the “verified version” once they confirm it works. Unless such a feature is really supported by people updating the database, it will likely add more confusion as the list of verified devices will be very limited, and you end up with people thinking their device is not supported.
In general, this should come from the manual, and the manual should (ie must) be attached to the database - this is a requirement before the database entry can be approved.
However, after 2 years, it’s not impossible for this to change. Manuals are often wrong, and it’s hard to capture the information. I try to get people to add a comment to the comments where there are references or whatever, but it’s difficult to police and the database maintainers also have other things to do.
I’m really not sure what information exactly that you are looking for that would really help. We have well over 1000 devices in the database and we do our best to police things and get people to add all the right information. The database enforces a certain level of information before a device can be approved (including the requirement to upload the manual) but at the end of the day it’s hard to really police this within the community. It relies on community engagement, and the goodwill and time from people like @sihui, @Bruce_Osborne, @5iver to try and keep it in check.
Absolutely - this really helped with a lot of the older devices from before I added code to enforce a better standard prior to approval. I know even now some devices are added with the bare minimum that people can get away with - ultimately it’s hard to enforce. We can’t force people to add the data, and in general we can’t leave it to one person as it would nearly be a full time job.
To take a step back - the reason I wrote the database in the first place was that in OH1, everyone needed to edit the XML files by hand. That was really prone to error and inconsistencies and often left to me to to. I spent a lot of my time doing the database files, and I really think what we have now is a bit improvement. The database also generates the documentation, and while I agree it’s far from perfect, I still think it massively contributes to the overall usability of openHAB. With 1000+ devices, managing XML files manually is really not feasible.
I try to control this by requiring people request access, but it doesn’t stop people making changes that are wrong. The maintainers will review the changes, but we can’t check everything - we ultimately have to take someones word and also rely on people being honest.
I’m not sure what sort of attack you are thinking of and is it really relevant to this discussion? There is always more that could be done, and I’ve admitted that the database is not perfect, but it’s been running for 4 years now and I keep nightly backups so I think it’s ok.
