But the channels are ALWAYS OnOffType - the channels are never ContactType - we can see this in the log. The binding doesn’t know anything about the item configuration, but the channel configuration cannot change - it’s always OnOffType.
Are you also changing some configuration in the device, or just the configuration of the item definition?
If you mean “device” = zwave parameters of the node, then yes.
I set parameter 5 and 6 both to inactive.
I also do not use .thing files.
And I changed configuration of items in the .items file.
Here are my original .items
Switch POPP_Smoke_1_Sw1 "Siren" {channel="zwave:device:e8445cf8:node3:switch_binary"}
Switch POPP_Smoke_1_A "Smoke Alarm" {channel="zwave:device:e8445cf8:node3:sensor_binary"}
Switch POPP_Smoke_1_GA "General Alarm"{channel="zwave:device:e8445cf8:node3:alarm_general"}
Number POPP_Smoke_1_BATT "Battery" {channel="zwave:device:e8445cf8:node3:battery-level"}Ok, so you mean that you are changing parameter 5 when you are doing these different configurations?
One thing I noticed in the log is that you are getting the ALARM messages in one configuration rather than the BINARY_SENSOR (or maybe as well as). The ALARM messages are normally better to use, but I don’t think there are any channels linked to this message.
This doesn’t matter - the binding doesn’t know anything about how you configure your things.
Again, this doesn’t matter as the binding knows nothing about items. The binding only knows about channels, and these are configured in the XML file from the database.
Just to further clarify what I mean -:
In the above, we see that for both nodes, we are receiving the same information, and we are setting the state of the channel to the same ON or OFF value, and always with the type of OnOffType.
The binding doesn’t know anything about how you have configured your item.
Maybe I’m still missing something in relation to your issue - my apologies if that is the case.
NO.
I changed parameter 5 and 6 with Habmin, because I don’t want to mesh the smoke alarm and low battery alarm through the whole house.
I don’t understand - sorry. If you changed parameter 5 and 6, even with HABmin, then you are still changing the parameters. 
In any case, I don’t know what these parameters do, and from what I can see in the logs, it’s not changing the channel state anyway - this is always processed in the same way.
Sorry - I feel I’m misunderstanding something here, for which I apologise.
Before I ever started with any item configuration (2 years ago) I included 5 Popp Smoke Sensors (004001) via inclusion mode. (node3, node4, node5, node6, node7)
Then I went to Habmin and changed things → Configuration Parameter: 5 and 6 to inactive:
THEN I NEVER CHANGED IT AGAIN.
Then later I created new entries in the .item file:
Switch POPP_Smoke_1_Sw1 "Siren" {channel="zwave:device:e8445cf8:node3:switch_binary"}
Switch POPP_Smoke_1_A "Smoke Alarm" {channel="zwave:device:e8445cf8:node3:sensor_binary"}
Switch POPP_Smoke_1_GA "General Alarm"{channel="zwave:device:e8445cf8:node3:alarm_general"}
Number POPP_Smoke_1_BATT "Battery" {channel="zwave:device:e8445cf8:node3:battery-level"}
And it was running there with exactly above items.
I Switch POPP_Smoke_1_Sw1 to on → Siren ON (pepp, peep, …)
I Switch POPP_Smoke_1_Sw1 to offF → Siren OFF (silence)
After serveral snapshot updates and binding updates in the meantime, I TESTED above Switches again, this week.
But now:
I Switch POPP_Smoke_1_Sw1 to on → Siren = ON and Smoke Alarm = on
I Switch POPP_Smoke_1_Sw1 to OFF → Siren = OFF and Smoke Alarm = off
Sorry - maybe my misunderstanding is here - you are sending commands TO the smoke sensor, or just getting updates FROM the smoke sensor?
Is this a command problem, or a channel update problem - maybe this is where my misunderstanding is since the messages coming from the sensor are the same - as shown above?
That said, if the issue is with commands TO the smoke alarm, the binding is still doing the same thing for both devices 
I’m afraid I don’t see any difference - do you?
Parameters 5 and 6 should not impact how the binding is receiving the data from the sensor - it might stop it receiving anything at all if it’s not using routing (which is what I think is probably the meaning of these settings) but that will not change the way the binding works.
I send ON/OFF commands to the internal siren. This is NOT intented as a Smoke Alarm. It turns only the internal siren ON and OFF.
If there is a fire in the house, the smoke sensor = SENSOR_BINARY should turn to on and activate the siren.
From the log, this command looks fine for both nodes.
As far as I can tell from the log, this also looks fine, although obviously I can’t correlate the log messages with actual siren events.
Which one of these two doesn’t work - from what I can see in the logs, both node 3 and node 7 look to be working exactly the same from the binding perspective - the messages being processed, and the commands being sent are the same. We always have OnOffType for both commands and sensor data, so I’m at a loss to see the difference and I don’t understand the issue - sorry again 
.
1 Like
Both nodes (3 and 7) turn on the internal siren. With SWITCH_BINARY. This is correct.
But node 3 turns on also the Smoke Alarm = SENSOR_BINARY.
This is wrong. I do not have a smoke alarm simultaneously.
Here you can see it: SENSOR_BINARY_REPORT and “node3:sensor_binary”
Why is it in the logs? I did not do anything with it.
I only turned on SWITCH_BINARY.
I’m not sure - clearly this is not a binding issue - I guess this is a device configuration, but as I don’t know how these device configuration are set I’m not really able to help with that question. It may also be linked to association groups, so I would also check these.
I really cant see how the item configuration between using OnOff or Contact will have ANY impact on this at all.
1 Like
I’m going to provide all the information about node3 and node7 doing own investigations. I’m going to provide it tomorow.
Thank you very much for staying with me. I appreciate all your help.
1 Like
here are my investigations:
node3: channel: sensor_binary is configured as Switch (in .items file = POPP_Smoke_1_A)
18:27:12.754 [INFO ] [smarthome.event.ItemCommandEvent ] - Item 'POPP_Smoke_1_Sw1' received command ON
18:27:12.759 [INFO ] [smarthome.event.ItemStateChangedEvent] - POPP_Smoke_1_Sw1 changed from OFF to ON
18:27:14.366 [INFO ] [smarthome.event.ItemStateChangedEvent] - POPP_Smoke_1_A changed from NULL to ON
.
.
.
node7: channel: sensor_binary is configured as Contact (in .items file =POPP_Smoke_5_A)
18:27:30.494 [INFO ] [smarthome.event.ItemCommandEvent ] - Item 'POPP_Smoke_5_Sw' received command ON
18:27:30.498 [INFO ] [smarthome.event.ItemStateChangedEvent] - POPP_Smoke_5_Sw changed from OFF to ON
.
nothing else happens…
.
.
A comparison of node3 and node7:
.
Both SWITCH_BINARY doing exactly the same. They switch on the SIREN! --> this is OK!
And both devices (node3 and node7) then get a SENSOR_BINARY_REPORT::255(2) = #NUM!
.
node3 (SENSOR_BINARY = configured as Switch) can interpret 255(2) = #NUM! --> ==ON
and then POPP_Smoke_1_A changed from NULL to ON
.
node7 (SENSOR_BINARY = configured as Contact) can NOT interpret 255(2) = #NUM! --> NOTHING ELSE HAPPENS!
So, now the question is: "Why does the device switch ON automatically also SENSOR_BINARY = smoke alarm?
As you can see in the manufacturers description: from here (=CD Jackson Device Summary)
Product Usage
In case smoke is detected by the smoke detector the device will sound, the red LED will blink and the wireless module will issue a Z-Wave alarm command to the main controller and other associated devices. A low battery will be indicated on short siren noise plus the Z-Wave controller will be informed using Battery Low warning commands.
Note: All communication of the wireless module is performed with application level security if the device was included securely and all communication partners support secure communication as well. In case a non-secure device is associated for switching on smoke alarm, the smoke detector will detect this and change its communication styla with this very device to non-secure. This process happens one time and will take about 20 seconds. This delay will happen on first communication only.
The siren can be used for other alarm indication. For this reason the device will be shown at Graphical user interface as a simple on/off switch. Turning on this switch start the siren, turning it off will stop the noise. The generic siren alarm has a different acoustic pattern than the permanent sound caused by smoke. The configuration parameters 1 and 2 define the style of the sound.
.
.
Comment from me:
"The siren can be used for other alarm indication" e.g. burglar alarm, how can I achieve this when SENSOR_BINARY = smoke alarm is triggerd while switching ON the siren (e.g. for a burglar alarm).
You can not distinguish this.
And I swear it did not trigger a fire alarm when I put the smoke detectors into operation about 1.7 years ago!
Well, as you can see in the log, the binding seems to be processing this channel and sending the STATE UPDATE. What happens after this is up to you and the configuration of your item. For this device, you say that you have configured this as a Contact, and in this case I believe that OH will not be able to link the channel to the item, and you will therefore not get an item update.
Please change the ITEM type to a switch and it should work the same as the other node since the binding is processing both nodes the same.
Sorry, but this is not correct. As I showed a few days ago, both devices have channels that are configured as OnOffType.
This is just a display issue in my log viewer - it has no impact on the binding.
I think you simply have not configured your items inline with the channel types and therefore it is not working properly.
I know that “Contact” for SENSOR_BINARY is the wrong configuration (as you told)! I had it configured as “Switch” for 1.7 years. But my tests (one week ago) failed. I only wanted to get rid that “Smoke Alarm” was also triggerd! So I changed it to “Contact” like @sihui s example in post # 2 above (Link)
And btw, the device does it completely wrong! How can someone use the internal siren for OTHER alarms (like in the device description it is CLEARLY stated, see above) when ALWAYS a “smoke alarm” is triggerd while ONLY switching the siren ON?
Out of interest, does it make the warble sound or the smoke alarm sound when you trigger via switch channel?
I can not remember exactly. My original tests (with fire alarm test spray) were almost two years ago.
But it could be both (Siren Alarm and Fire Alarm) the same sound or minimal different sound!
But I could change parameter 1 and 2 (to find out!)
Parameter 1: Siren alarm sequence interval
The additional siren is creating a different acoustic signal differentiate from the smoke alarm. This sound is partly on and partly off. This parameter defines the total length of the interval in seconds.
Size: 2 Byte, Default Value: 10
Setting Description
03 - 127 seconds
Parameter 2: Siren alarm tone length
The additional siren is creating a different acoustic signal differentiate from the smoke alarm. This sound is partly on and partly off. This parameter defines the total length of the sound versus silence within this interval.
Size: 1 Byte, Default Value: 08
Setting Description
03 - 127 seconds