Aeotec Multisensor 6 binary/motion never shows in paper ui

Setup, Configuration and Use Beginners
,
1

openhabian snapshot

I’m opening this new thread since the other thread I started also had questions about the UV levels. This one is specific to the paperui and the binary and motion channel of the MS6

I just set up an Aeotec MS6. Mostly it is working.

Though I never see motion or binary change in the paperui, they show in the log and work with rules.

And I get reports of temperature, luminance, humidity, and battery to display in paperui.

The items for the binary and motion are as follows:

Switch ms6_binary "MS6 Switch [%s]" {channel="zwave:device:16500637f6a:node17:sensor_binary"}
Switch ms6_motion "MS6 Motion [%s]" {channel="zwave:device:16500637f6a:node17:alarm_motion"}

In the log there is a ~0.5 second delay between the change of the binary to on and the change of the motion channel.

I guess I don’t fully understand what the MS6 is doing.

Are the “binary” and “motion” channels changing based on the PIR?

I note, habmin, that the binary channel shows triggered or untriggered. And, the motion shows alarm or ok.

But the following rule prints on or off for both:

rule "M6 Motion"
    when
        Item ms6_binary changed
    then
        logInfo("M6 Motion", "binary state: " + ms6_binary.state)
        logInfo("M6 Motion", "motion state: " + ms6_motion.state)
end

But, I’d really like to know if it should change in paperui and if so, what have I got wrong…

2

Do you have a sitemap file, created with your items above, and do they change in the sitemap?

3

Have the multisensor6 as well. it doesn´t move in PaperUI (control panel). But it works just fine in sitemap files. I havn´t search for reason or fix, as I hardly ever use the control panel in PaperUI.

4

Not sure about the proper answer, but PaperUI is more for setup and some item’s are not displayed or controlled via PaperUI. I can’t answer why, guess that’s just the way OH works.

If everything is working and showing through your sitemap, you should be good.

5

To date, I have no sitemap. (Haven’t researched what they do or are for… :blush: )

Have done my general user interface with Habpanel.

The MS6 binary/motion works fine there as well as in rules. So I guess it’s just a paperui control panel behavior.

Apparently one is an alarm, the other a switch. Not sure why there is two… :thinking:

6

Because your items file has 2 items.

You can create a sitemap with your items and place into the sitemaps file like this:

Add BasicUI via PaperUI found under addons and User Interfaces tab

home.sitemap (create the file and name it, then copy whats below into the file and save)

sitemap home label="Name of your sitemap"
{
	Frame label="Motion and Switch"
	{
		Switch item="ms6_binary"
                Text item="ms6_motion" label="Motion detection"
	}
}
7

Let me rephrase: There is a binary and a motion channel in the automatically created thing definition (both habmin/paperui) Not sure why there is two.

I created the item file items for each of those channels.

Sure, but what does that buy me?

I can control all my devices, see the value of sensors, have rules act on mqtt changes, etc. in habpanel and have never created a sitemap.

I truly just don’t know why I need a sitemap…have I not tripped on it yet? :confused:

8

Just another way to view and control your items. Its not needed, I was just providing another option. It’s your system so go with what you like best.:smiley:

Because two were auto discovered.

9

This is not uncommon in ZWave - there are often multiple command classes that provide the same information. Often it’s to cater for different systems that may not have such flexibility. OH database import simply adds all options, so unless someone with knowledge of the device goes through and removes surplus channels, the duplication remains.

1 Like
10

:wink: OK, let me re-re-phrase: Why did Aeotec include electronics which duplicates functions?

This would seem to be not cost effective, unless it were for redundancy.

But, as @chris notes below, it’s probably due to multiple command classes, opposed to duplicate hardware.

11

There will be no duplicate hardware - just duplicate software to report the same hardware status in different ways to be as compatible with different systems as possible. Unfortunately this is one of the downsides with ZWave - it has evolved over time and there is often no clear and single way to do things…

12

It´s not a duplicate. One is Binary, and the other is Alarm. They both react the same though, which does make it rather confusing, (and understandable if someone calls then duplicate).

These are my items for Aeotec Multisensor 6:

// Aeotec Multisensor6
Number  ZWaveNode5ZW100MultiSensor6_SensorRelativeHumidity 			"Multisensor6 SensorRelativeHumidity [%.0f %%]"   			<Humidity>  	(Fugtighed)		{channel="zwave:device:512:node5:sensor_relhumidity"} 
Number  ZWaveNode5ZW100MultiSensor6_SensorUltraviolet 				"Multisensor6 Ultraviolet Sensor [%.0f %%]"   				<Temperature>  				{channel="zwave:device:512:node5:sensor_ultraviolet"} 
Number  ZWaveNode5ZW100MultiSensor6_SensorTemperature 				"Multisensor6 Temperatur Sensor [%.1f °C]"   				<cu_heating>  	(Temperatur)		{channel="zwave:device:512:node5:sensor_temperature"} 
Number  ZWaveNode5ZW100MultiSensor6_SensorLuminance 				"Multisensor6 Lumiance Sensor [%.0f Lux]"   				<Light>  	(gLumiance)		{channel="zwave:device:512:node5:sensor_luminance"} 
Switch  ZWaveNode5ZW100MultiSensor6_TamperAlarm 				"Multisensor6 Tamper Alarm Sensor [%s]"  				<switch>  				{channel="zwave:device:512:node5:alarm_tamper"} 
Switch  ZWaveNode5ZW100MultiSensor6_BinarySensor 	"Multisensor6 PIR Binary [%s]"  							<cum_motion>  	(gMotion)		{channel="zwave:device:512:node5:sensor_binary"}
Switch  ZWaveNode5ZW100MultiSensor6_MotionAlarm 	"Multisensor6 PIR Alarm [%s]"  								<cum_motion>  	(gMotionAlarm)		{channel="zwave:device:512:node5:alarm_motion"} 								```
13

They both report the state of the motion sensor don’t they? If so, they are duplicates and only one is required since they are both reporting the same thing through different command classes. This is quite common in ZWave.

14

They do, almost…
There is a small delay on the Alarm triggering. I´ve even have seen the Binary triggeringg without the Alarm triggering. But this could be due to some internal timings inside the software of the sensor, specielly if it detects a very fast moving hand or something simular.

99% of the time with a normal moving in front of the sensor, both channels will trigger, which is why it´s okay to say they´re duplicates. But I think Aeotech thought they´ll do two channels, and call one of the channels alarm and the other binary, so the user can decide which suits his system best from it´s name. But in real life, it makes no difference.

I have all my sensors (Z-wave and Zigbee) set up in a little “test lap” here one of my monitor speaker… When I test, I just wave my hand in front of all of them :joy: My Neo Coolcam sensor is placed outside though in a corner underneat the roof, clear of the rain, just to test how it performs outside, specially when its warm and cold weather, (tests going well, except the lux sensor is highly unstable unfortunaly). It´s not build to be placed outside, but I wanted to see what happened :grinning:

15

I think that’s just processing - it doesn’t mean that they aren’t the same sensor.

As I said above, it is normal for most devices to do this sort of thing as some gateways don’t support newer command classes. Again though, this does not mean that they are different sensors, or act differently, and in general, I would recommend removing one from the database to avoid such confusion.

16

Wouldn´t it be wrong to remove one of them from the database, when the device do support both channels?
In a real life it does not make any sense. But I would hate if I knew someone else was in charge of which channels a device should support. I would prefere to make my own choise. In openhab, it´s easy just to remove one of the channels.

1 Like
17

No - we would just make it support a single channel - if they are the same, there’s no need to have both channels.

We get a lot of confusion caused by this sort of thing and it is better for people to have a system that doesn’t provide such confusion.

Why do you need two channels that do the same thing? Maybe I’m missing something?

No - that’s not true. Both channels will show up in the UI - there’s no way to remove channels at all other than not to add them in the first place. This is confusing to people as they see multiple channels, and then need to understand how to configure the device in multiple ways to use the different sensors. We then have long discussions (as we did earlier here) trying to understand why there are two channels that do the same thing.

I can GUARANTEE that these two channels are exactly the same (I had this confirmed by my contact in Aeotec just now).

1 Like
18

I understand.
But this confusion would get even worse, when a user (god forbid :joy:) read the manual, and in there can see there is suppose to be a binary and a alarm channel. Then we´ll have to explain that.

I dont need both. But I need to know if the device if working the way it´s suppose to. So when the manual says there are 7 channels. I would expect 7 channels. Getting only 6 channels will rise a question and as explained above confusion.
Next, when beeing told someone else decided to remove one of them, my concern would be, what does he decide to remove next time I buy an device and not see the same amount of channelse.
I fear taking this kind of actions will result in even more confusion as well as not trusting either the device or the database.

Yeah they will show in PaperUI. But it´s easy to remove the link (or not link) if you know why. And then just decide which one to use, (or use both if someone get that strange idea).

Again, my main concern is, the major arguments about who should decide to remove one from the database, and which one. And second, the confusion it will rise, when looking at the manual and not see the same in the setup.

19

I disagree.

If we provide every channel, as you are suggesting, then we will have a LOT more channels. Most devices provide duplicate channels - they duplicate this across endpoints, and across command classes. We can easily have a channel duplicated 3 times in some devices and that is (IMHO) not a good idea, and should be eliminated. We have already done this on a number of devices as people were confused, as we saw that in this thread already.

The manual doesn’t talk about channels at all. Channels are an openHAB concept, and the openHAB documentation will present the features the device supports within openHAB. Additionally, most device manuals don’t talk about the different command classes, and this is the case with the ZW100. It doesn’t mention the command classes at all (note - I’m talking about the manual that comes with the unit in the box - not the engineering specification).

In OH2, we try and focus on ease of use, and I am constantly (well, regularly :wink: ) answering questions relating to this so it does confuse people.

As I said, we are already doing this on many devices as it WAS causing confusion.

No - you are mixing up channels and items. Channels can not be removed - they will always show up.

Respectfully, I disagree, and I want to keep a consistent approach which we have been doing for some time.

20

Hmm if the manual doesn´t say, then I agree. (I am pretty sure however that I read it somewhere regarding the multisensor 6. I could been wrong though, as I just looked in the manual, and it doesnt specific mention binary and alarm sensor).
I was not aware that this is typical scenary for most devices… (thank god, otherwise I would have filled this community with questions myself).

1 Like