Probably you have seen this in the Aeon engineering specification, which is a detailed document describing what the different bits and bytes mean. It’s not targeted at the user though, but the developer.
Different manufacturers may of course provide different information, but I also try and provide good documentation for every device directly in the openHAB docs that are (hopefully 
) clear.
Perhaps a note in the properties, just in case someone is as strange as me reading the engineering specifications 
IMO, it is a really bad idea to be removing “duplicate” channels.
In OH1, we could chose the item type used for a specific CC. That freedom of choice was removed in OH2. In some cases, devices supported multiple command classes, so multiple Channels, and therefore multiple supported Item types. What is key for me, is the ability to have all of my motion sensors, contact sensors, locks, garage doors, etc. be the some Item type, so that they can be used together in groups, eliminating much of the rule logic needed to automate things. If the similar channels were removed, it would also unintentionally eliminate this emergent functionality and flexibility. The functionality of the channels may be duplicated, but, without the ability to select a Channel type, having both Channels provides the option to chose a Channel type that suits the use case.
Instead of pruning out functionality, there should be an improvement in the visibility of it… along the lines of Simple mode vs Expert mode. This is a big concept and way beyond the scope of the discussion in this thread, but there are many areas within OH where this would be useful. But for now, Habmin and Paper UI allow for Channels to be essentially hidden (I’m thinking of the Tools> Show advanced settings option and Show More button, respectively).
Personally, I’m adamantly opposed to catering to people who need things to be simplified by removing functionality that is used by people who comprehend it. UIs can be used to filter the underlying complexity. Streamline without precluding innovation! 
Why?
We (ie you and I) have recently been doing similar things for scene channels (I forget the device) so I’m surprised as you never said anything then?
I really see no utility in having duplicates. It causes the binding a nightmare as we somehow need to find names for them, and it simply confuses most users. Very often we have duplicate switches as we have “Switch” on the root endpoint, and “Switch 1” on endpoint 1 - they are EXACTLY the same, and it confuses people as they don’t understand why there are 2 channels, and which one they should use for what, and what endpoints are…
We also worse situations with sensors (such as this one) where you can have a BINARY_SENSOR, SENSOR_ALARM, and NOTIFICATION all providing EXACTLY the same function. Firstly, I can’t easily handle this in the binding as they should all have the same channel type, and this causes problems with the database. We have been removing these duplicates to avoid this problem for a long time. However, on many devices, it gets worse, as in addition to the root endpoint, channels are often duplicated on other endpoints, so we would end up with 3-4-5 channels all doing exactly the same thing. I really do not understand why this is useful.
As I mention above, if we now want to provide all these extra channels, I need to rethink how the binding works (or at least how the database exporter works) to allow duplicates as it has never been the case. Recently we have seen that ESH has imposed a check, and if there are duplicate channels in a thing, then it will throw an error, and this has meant that where we have allowed some duplicates, they now must be removed.
So you want (for example) two binary_switch channels for the same switch - one on endpoint 0, and one on endpoint 1? Or in the case of this sensor, two sensor_door channels - one connected to the SENSOR_BINARY, and one connected to the ALARM? I really can’t understand the point when they do exactly the same thing? If you just want to be able to link this to multiple items, then you can do this with a single channel.
I don’t understand this point. Here we are discussing duplicate channels - the channel type should be the same. If we want to add extra channels to provide duplicate functions, then that’s a whole different question. I have no problem what-so-ever with that, and I do that regularly (eg different alarm channels). I think maybe you’re getting issues mixed up?
It’s not just simplifying it for people who don’t understand! It’s about providing the devices functionality, but adding loads of channels just to fill a list is of no benefit (that I can see anyway). This is perfectly normal in most HA software - this is what causes the problem in the first place (ie that devices provide multiple ways of interacting with the same functionality on a device in order to cater for different HA systems - it doesn’t mean that an HA system should be using all options). It probably slows things down as the system would have to cater for the additional channels that are not required.
Sure - but again, why provide exactly the same function multiple times, and then filter it out!?! 
. I can understand if there’s some extra features being provided, but here we are talking about duplicate functions, and I’m really at a loss as to why we would provide this.
I’m happy to be convinced if there’s a good argument, but so far, I don’t see one, and providing these duplicates is going to take quite a lot of work, so I don’t want to do it without good rational!
Just thinking out loud…
Maybe the duplicate functions can be noted some how so the user (particularly a new user) would at least know that the function they might be looking for is a duplicate of another and can be found in channel “x”?
Also, would it be possible to have a concept of alias or pseudonym for duplicate channels?
Why? Why provide duplicate functions, with all the pain that brings, and then note that it can’t be used? I just don’t understand. The functions are exactly the same - why provide duplicates? If it’s a new user, then providing duplicate channels is likely to be a lot more confusing isn’t it?
This is something I’ve been thinking about as it could be useful in some instances. Unfortunately, there’s no easy way to resolve this automatically, so it would require a LOT of manual work to link this together.
I should note that what I am doing here is consistent with the way ZWave is meant to work (as I’ve repeatedly explained above). You’re not missing out on something.
Hi Chris
Further to the above quote, I too was using the SENSOR_BINARY channel for triggering my rules and since updating to 2.4.0 and losing this channel I have found something interesting. Previously when using the SENSOR_BINARY channel I had configured Option 3. Motion Sensor Reset Timeout to trigger rules as this functionality was an inbuilt timer in the Motion Sensor & it worked really well allowing me to trigger rules on motion detected and when it resets after its timeout. Now that I am using the MOTION_ALARM channel this Option 3 no longer applies and the MOTION_ALARM channel never resets thus my rules to trigger on the motion resetting never happen.
I also had a friend setup OpenHab2 recently on 2.3.0 and encountered the same findings that the Motion Sensor Reset Timeout did not apply to the alarm channel but did when on the Binary Sensor.
Is there anyway we can get this channel back as it is providing different functionality for the 2 channels?
*Edit - After further testing the Alarm Channel does reset after the timeout configured but does not notify the controller that it has changed state as the Binary Channel did.
After several restarts of OpenHab it looks like it is now reporting the Motion State. I will keep an eye on it and report back after Christmas.
To be honest I’m a little surprised about this. Yes, we can add the channel back, but I would prefer to try and standardise things if possible - this makes it easier to support for starters. Please can you provide a log showing what is received and I will take a look.
Hi Chris,
I’ve just tried upgrading to OpenHab 2.4. I have a number of these Aeotec 6 in 1 sensor devices that I use to provide temperature and room occupation data for my heating system control. I also make use of the motion sensor time out functionality as menzy describes. As the SENSOR_BINARY channel has been removed my room occupation sensing does not work. I have not tried to change to the MOTION_ALARM channel as yet so cannot confirm menzy’s findings. I have now reinstated my OpenHab 2.3 configuration. In re-reading the version 1.11 firmware manual for EU devices I can find no reference to a PIR alarm output channel, however the type of report sent can be selected by configuration parameter 5. Is having two end points for this sensor therefore related to the type of reporting selected?
I greatly appreciate the work you have put into this binding Chris. I understand your drive towards simplicity for new starters, however I do feel that making the decision to remove reporting channels in this way should not be taken lightly, particularly for an established sensor like this. Backwards compatibility should always be considered a high priority.
The binding was heavily rewritten, and while I understand that backward compatability is always nice, there are now so many ways to do things in ZWave, that supporting this is becoming a nightmare. I currently spend a couple of hours pretty much every day supporting ZWave, and more supporting ZigBee, so I really want to simplify things - both for myself, and users.
Since you haven’t even tried to use the new channels, can I suggest that you give it a try? The binding was changed a long time back (well, a good few months) and I think that this issue would likely have come up previously if it was really a problem since there are a lot of people using these devices.
The manual for version 1.11 has the following -:
I think therefore it is supported.
Not normally - endpoints normally just split functionality, although much of it is also available through the root.
Hi Chris,
Sorry if I came across as being overly critical here. I produce and maintain software for a living so I fully understand your position. My intentions are purely constructive.
I have only been using OpenHab for about a year now and have very little knowledge or experience of Java.
I am therefore one of your new starters, with perhaps a little advantage based on my background.
As a new starter I have only utilised the OpenHab stable releases and have resisted the temptation to install any of the snapshots or milestone builds. As OpenHab 2.4 was released just prior to Christmas I decided to give it a try. This is why I have only just come across this issue.
I have now tried using the MOTION ALARM channel. The switch and timer functionality does seem to be the same. I do have an issue with my sitemap however. The status strings being returned from the MOTION ALARM channel are “ALARM” and “OK”. I had these channels configured as Text elements and displayed the status with the [%s] formatting in the label. Previously using the SENSOR BINARY channel the status was returned as simply “ON” or “OFF”. Unfortunately the returned status is now inappropriate for my use case.
I tried changing the sitemap element to Switch hoping to replace the text status with the switch graphic but unfortunately the returned status strings are not recognised by OpenHab as a simple boolean switch.
The status is displayed as two selection buttons with “ALARM” and “OK” displayed on them. So basically no improvement.
The only solution to this that I can see at the moment is to change back to a Text element and use a MAP transform to change the displayed text. As a beginner I don’t consider this a simple task.
From my point of view if one of the channels needed to be removed I would have preferred the removal of the alarm channel. It’s easier to work with a simple boolean switch status. This may of course raise complaints from people using these sensors for security purposes. I wouldn’t have thought there would be too many of them though as the secure comms functionality has not been available until this release.
Perhaps a better approach is to provide access to both channels and allow the user to select the one most appropriate to their use case.
Any other suggestions as to a work around for my sitemap issues would be gratefully received.
The newer command class is the NOTIFICATION class (AKA ALARM) so it doens’t make sense to remove this. This is the direction that ZWave is going, and it provides the best support for these events.
Sorry - I’m not really a sitemap expert, but this channel is used in dozens or hundreds of ZWave devices, so it should be workable. The type of this channel is ON/OFF type, so again, it should work (the binding is returning On/Off to ESH at least).
Hi Chris
I can confirm after updating to the Alarm channel that everything is working as expected.
Hi infrared
I use the following to display motion status.
home.sitemap:
Text label="Motion Detectors" icon="motion" {
Text item=LoungeZW100MultiSensor6_BinarySensor label="Lounge Motion Detected [MAP(OFFNoONYes.map):%s]" icon="motion"
Text item=FamilyZW100MultiSensor6_SensorMotion label="Family Motion Detected [MAP(OFFNoONYes.map):%s]" icon="motion"
Text item=KitchenZW100MultiSensor6_BinarySensor label="Kitchen Motion Detected [MAP(OFFNoONYes.map):%s]" icon="motion"
Text item=HallwayTopZW100MultiSensor6_SensorMotion label="Hallway Top Motion Detected [MAP(OFFNoONYes.map):%s]" icon="motion"
}
Map file:
OFFNoONYes.map
OFF=No
ON=Yes