I’ve changed this parameter to 1 byte. Note though that the description is now not right as it states +/- 32768. Can you confirm what this should be please?
Thanks. Will wait for next cloudbees build and tell you the outcome.
Correct range is [-100,100] as per latest Aeon engineering manual.
See the link in my previous post (yes, sorry @xsnrg for the ads that you have to get through … I guess that’s nowaday’s price for not being spied on by NSA and GCHQ … if you don’t make it, tell me your email then I will send it).
Oh, by the way @jamborta: To change param #111 to something other than the default does work for me
(as chris noted, it’s already 4 bytes in size as it should be, so I was somewhat wrong when I told you I had the same problem - the symptom seemed to be the same, while the cause apparently is not).
Just another idea: did you check parameter #252 ? According to the manual, setting it to 1 results in config being locked.
regards
Markus
Here’s the quote on parameter #111 from the latest manual I posted.
Do I correctly assume you run on battery ? I guess that would explain it.
The interval time of sending reports in Report group 1 (Valid values 0x05-
0x28DE80).
1. The unit of interval time is second if USB power.
2. If battery power, the minimum interval time is 60 minutes by default, for
example, if the value is set to be more than 5 and less than 3600, the interval
time is 60 minutes, if the value is set to be more than 3600 and less than 7200,
the interval time is 120 minutes. You can also change the minimum interval time
to 4 minutes via setting the interval value(3 bytes) to 240 in Wake Up Interval Set
CC.
1 Like
Can you put this somewhere that is actually possible to download please?
I grabbed it, but cannot upload here… Oh wait, it is a .pdf.jpg 
It uploads then, but there does not seem to be a good way to download it.
The trick to download the previous link was to wait for the countdown after the capcha. You then get a download button.
Thanks - it seemed to download a bunch of files, but the big one is the right one
Ok, this just adds to the confusion, and also supports not merging the change request…
The XML in the following link, which I believe comes from a multi sensor 6, contains parameters that are apparently not in this engineering file (eg parameter 6). The XML only gets parameters added when there is actually a response from the device for this parameter
<entry>
<int>6</int>
<configurationParameter>
<index>6</index>
<size>1</size>
<value>127</value>
<readOnly>false</readOnly>
<writeOnly>false</writeOnly>
</configurationParameter>
</entry>
Anyone any thoughts - it seems to me that this latest spec isn’t correct - or at least something isn’t consistent…
Could maybe reach out to Chris at Aeotec for a doc right from them? They also have 3 different multi-sensors now it seems. The original 4 in 1, and new one called gen5 that is the same size as the original, and the Multisensor 6, which is a new 6 in 1 gen5 device. Kind of confusing, but want to make sure we are talking and looking at docs for the Multisensor 6.
Unfortunately I don’t have a Multisensor 6 to experiment with.
Well. First, yes it’s a .XML from a multisensor 6 (because it shows it has the ultraviolet sensor).
I removed parameter 6 (and 7, I believe) in my change request because they are not contained in the latest spec. That may or may not as well be a mistake in the Aeon doc, though. The doc I posted is for multisensor 6, codename ZW100-A.
I removed param 6 also because there is a param 5 which, looking at the descriptions, seems to have the same
function (PIR detection sensitivity). I don’t know, though, where the old description of #6 came from. Maybe it has been nonsense on from the very beginning. I also removed param 7, which I have not seen any equivalent for in latest spec.
Actually, #6 and #7 are already missing in previous versions of the multisensor (@chris: the manual you have sent if for that older sensor, and they lack #6 and #7, too).
If, as you say, parameters only find their way into the .XML when the device reports them, I guess it wouldn’t do harm if you keep the parameters in the binding database (because there’s a chance they were forgotten about in Aeon’s doc).
That, however, will cause confusion for all users whether to use param 5 or 6 or even both … just as it is confusing me.
I have an open ticket @Aeon and will try to check with them on the meaning of #6.
I agree it’s confusing, but the most important thing is it’s correct. Adding parameters that aren’t there, or not having them if they are there is both a bad idea…
Thanks. Let’s discuss once they respond - either way your PR will need updating due to merge errors.
Chris
Works. Thanks, you just cooled my room down by about 4° C (param #201 is temperature calibration offset).
Got a response from Aeon:
The parameter that has 0 - 127 sensitivity no longer exists. its all covered by parameter #5.
Parameter 6 and 7 were removed as configurations so there is no need to pay attention to them.
So I suggest we should ignore parameter #6 even if sent, to avoid confusion, i.e. remove it from the binding.
Do you agree ?
Then my pull request should still be fine, (well, more or less, except for the merge errors you mentioned, of course. Sorry it had been a long day and I had/have no XML syntax checker at hand).
Markus
Ugh. Does this mean older sensors then need a firmware update to work right with the zwave binding, or was the doc incorrect all along?
Huh? I don’t understand what you mean - what does that have to do with the sensor’s firmware version?
Older sensors might still announce a parameter 6, but the future version of the zwave binding will ignore it so it won’t appear in habmin. No loss of functionality, as you shouldn’t use it anyway, according to Aeon.
Also, you can still access parameter 5 which has the same functionality.
If the change to not use 6 was a firmware update from Aeon, then older firmware devices will not have that function available through the binding if the parameter is ignored, right? If on the other hand it was just a mistake in the doc and 6 should never have been used, then all is well.
If I understand you correctly though, you are saying that parameter 5 was the same as 6, even in the older sensors and 6 is just removed in newer devices and docs, then I agree, removing 6 from the xml config should have no affect on the feature set of the sensor being available in the z-wave binding.
I agree with @xsnrg - it would be good to understand if this is related to software version, or if every version of this sensor has parameters 6 and 7 ‘removed’. It certainly reads as though this parameter was originally included in this sensor and then removed in later versions of the firmware, but that might not be the case…
Unfortunately, it’s not that simple. The binding assumes that the configuration parameters in the binding are available in the device. During the initialisation, the binding requests all this information so that it’s available in HABmin so that you can view the configuration. If a parameter is not available in a device that is specified in the database, then it will cause the initialisation to go very slow, and possibly timeout.
Hopefully, Aeon keep a firmware version number (like Fibaro does with all their versions). If so, we can use this to distinguish between the different versions. I don’t have one of these devices, so I can’t check, but it would be good if a few people with different versions can check the version number, and post the XML for the device.
I’m not sure what you mean? We can obviously delete the parameter from the config file, but then it’s not available. We could also make it write only, so that it doesn’t get read and so doesn’t upset devices that don’t support it, but then for those that need it (if that’s anyone) it’s not able to be read…
This is what I want to see - maybe some of the older ones set this to a lower number? If so, we can have multiple versions of the config file based on this - the binding supports this, and it’s used with Fibaro devices that have different parameters for different firmware versions. We could then (maybe) say that for versions 1.6 and above, don’t have parameter 6, and for versions below 1.6, we leave it in.
If we’re 100% sure that no-one will ever need parameter 6, then I’m happy to remove it. The question raised by @xsnrg was if older versions of the firmware use this parameter. I believe his reasoning is that just because the new sensor has removed parameter 6 (since it’s covered by parameter 5), doesn’t mean that this was implemented in the same way in the older firmware versions. Presumably, Aeon put this in the original version for a reason, and decided to remove it after they changed the firmware…
So, the question is still if it’s needed in any version of the firmware or not…
I don’t necessarily agree. If the firmware has changed, then maybe parameter 5 used to be required - presumably Aeon added it for a reason - they didn’t just put it there and say “we’ll make 2 parameters do the same thing as that’s twice as good” 
Anyway - it’s a bit theoretical since we don’t really know…
Fair point. Let’s change to the latest definition then - if you update the PR, I’ll merge.
Thanks.
Cheers
Chris