2 minutes ago for testing:
2019-07-22 11:27:11.483 [vent.ItemStateChangedEvent] - POPP_Smoke_1_Sw changed from OFF to ON
2019-07-22 11:27:11.783 [vent.ItemStateChangedEvent] - POPP_Smoke_1_Sw changed from ON to OFF
1 Like
OK. Thanks 
Which firmware version does your Popp have? Mine are on 2.1.
And mine have: parameter 5 = inactive, parameter 6 =inactive
19:05:23.932 [INFO ] [smarthome.event.ItemCommandEvent ] - Item 'POPP_Smoke_1_Sw1' received command ON
19:05:23.940 [INFO ] [smarthome.event.ItemStateChangedEvent] - POPP_Smoke_1_Sw1 changed from OFF to ON
19:05:25.546 [INFO ] [smarthome.event.ItemStateChangedEvent] - POPP_Smoke_1_A changed from OFF to ON
It took 1,6 seconds that āAlarmā also was activated. Your switching took only 0,3 sec? What happens when you wait a little bit longer?
I can also remember that parameter 3 had a range from 0 to 255. Now only a range from 0 to 99 is possible.
It is set to -1 (=255) by DEFAULT. But zwave database states: 99. The latest manual of Popp is telling 63 by default. Iāve asked Popp support this a long time ago and they told me -1 is correct.
I tried 99 and 63. But both are leading to above shown result. And -1 is possibly ignored and not setable anymore.
Mine, too.
Family is kicking my ass.
Will try again when nobody is home.
Same here.
63 Hex equals 99 decimal. Manuals often state the hex value, for the config parameter we need the decimal value.
1 Like
Ok, thank you very much!
One thing Iāve recognized now, maybe overlooked it, your channels are as follows:
{ zwave="9:command=SENSOR_BINARY,respond_to_basic=true }
{ zwave="9:command=switch_binary" }
{ zwave="9:command=battery" }
But mine are:
{channel="zwave:device:e8445cf8:node3:switch_binary"}
{channel="zwave:device:e8445cf8:node3:sensor_binary"}
{channel="zwave:device:e8445cf8:node3:alarm_general"}
{channel="zwave:device:e8445cf8:node3:battery-level"}
Maybe itās the missing respond_to_basic=true? But I never used this and it was running well without it!
Regarding the documentation (or this), should it be added to the switch_binary?
That is because you are replying to a very old post, that definition is for the zwave 1.x binding.
OK thanks, I know, but my question was regarding to respond_to_basic=true?
And itās possible in OH2, too.
See this example from the docs:
Contact Garage "Garage is [MAP(en.map):%s]" {channel="zwave:21:command=sensor_binary,respond_to_basic=true"}
And here itās marked:
Does it mean that it uses automatically āBASICā or must it be configured through item/channel configuration?
10 seconds test, no other channel was triggered:
2019-07-23 10:15:07.626 [ome.event.ItemCommandEvent] - Item 'POPP_Smoke_1_Sw' received command ON
2019-07-23 10:15:07.642 [vent.ItemStateChangedEvent] - POPP_Smoke_1_Sw changed from OFF to ON
2019-07-23 10:15:17.862 [ome.event.ItemCommandEvent] - Item 'POPP_Smoke_1_Sw' received command OFF
2019-07-23 10:15:17.867 [vent.ItemStateChangedEvent] - POPP_Smoke_1_Sw changed from ON to OFF
Nope, this is now the Basic checkmark in the zwave device database.
Yes, but it depends on the config settings of devices: for some devices you can switch between multilevel command class and basic command class.
1 Like
Does it hurt if I add it (respond_to_basic=true) anyway? Only for testing?
Iām pretty sure you will get a syntax error in your log.
I donāt know if it will hurt, but at best it will not do anything as this is only usable for the OH1.x binding.
This link is not the zwave docs, so who knows where it has come from 
1 Like
I found the mistake!
The doc confused me.
I wrongly configured SENSOR_BINARY as a Switch item instead of a Contact item.
Now it works.
Strange - I checked the definition and it shows that it should be an OnOffType -:
<channels>
<channel id="switch_binary" typeId="switch_binary">
<label>Switch</label>
<properties>
<property name="binding:*:OnOffType">COMMAND_CLASS_SWITCH_BINARY,COMMAND_CLASS_BASIC</property>
</properties>
</channel>
<channel id="sensor_binary" typeId="sensor_binary">
<label>Binary Sensor</label>
<properties>
<property name="binding:*:OnOffType">COMMAND_CLASS_SENSOR_BINARY</property>
</properties>
</channel>
<channel id="alarm_general" typeId="alarm_general">
<label>Alarm</label>
<properties>
<property name="binding:*:OnOffType">COMMAND_CLASS_ALARM</property>
</properties>
</channel>
<channel id="battery-level" typeId="system.battery-level">
<properties>
<property name="binding:*:PercentType">COMMAND_CLASS_BATTERY</property>
</properties>
</channel>
</channels>
And the source code seems to correctly interpret this -:
case OnOffType:
return sensorEvent.getValue() == 0 ? OnOffType.OFF : OnOffType.ON;
Can you provide a debug log showing these updates please?
Unfortunately not this evening, because of my family.
But Iām going to provide it asap.
1 Like
At least the Java code hasnāt changed for 18 months. Checking the database is more difficult as the OH repositories changed a couple of months back, but I donāt think it will have changed either.
Thereās no hurry for the logs so donāt stress
1 Like
z-wave-log.txt (167.8 KB)
NODE3: SENSOR_BINARY --> item = Switch
NODE7: SENSOR_BINARY --> item = Contact
Then I switched on NODE3 --> SWITCH_BINARY
Then I switched it OFF again.
Then I switched on NODE7 --> SWITCH_BINARY
Then I switched it OFF again.
In all cases, the binding is setting the state as an OnOffType - both for node 3 and node 7. The binding doesnāt know how you have configured your items - it only know how the channels should be configured, which comes from the information I provided yesterday, and this all appears to be working fine.
Iām not really sure why it only works for you if you configure your item as a Contact.
I try to explain it again:
CASE1:
When both channels SWITCH_BINARY (=siren ON/OFF) and SENSOR_BINARY (=SMOKE ALARM) are configured as Switch and when I switch the siren to ON also āSmoke Alarmā is set to ON.
CASE2:
When I configure SENSOR_BINARY as Contact and I switch the siren to ON, then only the siren is switched to ON and SENSOR_BINARY does NOTHING.
I expect CASE2 as the intended behaviour of the manufacturer.