Popp 09501 Flow Stop

Just bought myself a Popp 09501 Flow stop.

I’ve added it to openhab, but it seems that it’s discoverd as 012501 Electric Strike Lock Control from Popp?

Is there something I can do, or should this be updated on the zwave database level (@chris ?) ?
I’ve added the corresponding xml to this topic. Not sure if this can help?

popp09501.xml (8.5 KB)

This is a problem as your device has the same device type and device id.
Your firmware version is 1.1, so I extended the existing database entry from only using 1.2 to 1.1 to 1.2.
But I can’t add your device type and id as this is used by the Electric Strike Lock.
If we knew the firmware versions of the Electric Strike Lock this would be a solution …

We need to have @chris to take a look :sunglasses:

From what I have found the Electric Strike Lock is using firmware versions 1.04 and 1.5:

This does not make it any easier.

Unfortunately you’re right… Without more information on the lock we can’t work out how to differentiate these two devices. If the lock is using 1.4 and 1.5, and the valve is using 1.1 and 1.2, then we could create the device.

I guess we can make that assumption, and see if anyone complains and work out what to do from there. It’s not the nicest approach, but if the manufacturer doesn’t respect the ZWave requirements, it makes life difficult.

@sihui if you update the database with these assumptions, please add a comment to each device as sooner or later we might want to remind ourselves about this discussion :slight_smile:

Unfortunately this is even more complicated: the lock is using firmware versions 1.04 (not 1.4) and 1.5, so we need three devices: two entries for the Electric Strike Lock Module, one with firmware 1.0, one with firmware version 1.5 and above and another entry for the Flow Stop with firmware version 1.1 to 1.2. :skull_and_crossbones:

Will do.

This is just a printing issue. Version numbers are <major>.<minor> - the two numbers are independent. So, 1.1, is the same as 1.01, or 1.001… Major version 1, minor version 1, in all cases…

1 Like



1 Like

Your device was added to the database, after the changes got merged into the binding you need to upgrade to the latest 2.5 zwave snapshot binding.

1 Like

Maybe 2 additional questions?

  • I’ve just removed the binding from my paperUI, and reinstalled it by the paperUI. But I don’t see much difference in the binding itself (2.5.0.M1) or after exclude/include the node (still Popp 012501). Or should I download the binding manual and put in the addon folder?

    openhab> bundle:list | grep ZWave
    252 │ Active   │  80 │ 2.5.0.M1               │ ZWave Binding
  • Is there somewhere an easy way to see the complete versions/release date?
    Maybe the step above was correct, but the new binding wasn’t released yet?

ps thanks for all your guys effort!!! We don’t say this enough I think. :woozy_face:


No, Karaf is a good way to see the binding version.

Changes should be in the latest zwave 2.5 binding if the build did not fail this time :grinning::

Damned, some updates, and ex-/includes laters, no luck?

Bundle version:
276 | Active   |  80 |     | openHAB Add-ons :: Bundles :: ZWave Binding

### Z-Wave Node 086: 012501 Electric Strike Lock Control
012501 Electric Strike Lock Control

Any suggestion?

For the binding to get to work, I also needed to download:


ps, I was not able to include it over paperUI. I should really need to understand/study the ‘security’ option in the include. Played for about 2 hours with it, but not 1 correct inclusion of the device. Sometimes it’s been noticed, but then not fully initalized. And sometimes, a lot of other things went offline? I even got 2 now that aren’t reachable anymore? Maybe another story.
But when I add it the hard way (button on stick), it works 1-2-3… Nicely included,and initalized after +/- 2 minutes. Sadly still as electric lock.

Maybe the changes to the binding did not make it yet into the latest build, but I’m not sure.


Yezzz, it’s in! Thank you very much!
Next week they expect a heat wave in Belgium, so just in time to open the water from my lazy chair. :wink:

On/Off works fine.
A bit suprised that they’re a dimmer function in it? Is that to open the valve fe 25%? For the moment, it’s not working. :blush:

Dimmer Kogelkraan_Kelder_Dimmer "Water [%s]" <water> {channel="zwave:device:30038385:node86:switch_dimmer" }

Slider item=Kogelkraan_Kelder_Dimmer

I have just created an account for this…
I struggled for 2-3 days to understand why after upgrade from 2.4 to 2.5 my door lock didn’t work anymore… and it was wrongly detected as Flow Stop.
My door lock is a few years old and it has firmware 1.2 !!
I had to modify the database to solve this issue.


Welcome to the forum.

Please post your xml for that device.

There are no recent updates to the database:

I thought the problem was pretty clear.
My lock is firmware 1.2 which got mapped to flow stop after installing 2.5.
I made a copy of the zwave binding, where I removed the flow stop xml (9501)and modified the 12501 xml just with min 1.2 (instead of 1.4).
Then it worked fine as before…

Yes, but what is the solution?

Of course, you will say that we just change the database, and this will fix your problem. However, does it cause someone else a problem? Maybe the manufacturer has used the same codes for two devices? Are you sure this is not the case?

We should investigate this - it might just be a database error where someone has made a mistake, or it might be the manufacturer has made a mistake?

This is why we like to get the XML files - to help with diagnosing issues.

Yes, it really looks like the manufacturer used the same code for different devices.
I just had to remove the one I don’t need. I don’t know what a better solution would be…

Ok, that’s always a sad situation…

The only possibility is to try and use the version to differentiate the devices - maybe we can just map your device to V1.2, and do something else with the other device.

Oh dear - reading further up this thread (which I had not done till now) it looks to be a real mess as the same codes are used for loads of different devices :cry:

So yes, it looks like we’re out of options as there is now an overlap of versions and codes :frowning: