Z-Wave: Reverse RollerShutter direction

[Nuno Pereira]

Hi,

I've the same issue as reported on #1060. 

I'm using a ZME_05436 (Flush Mountable Blind Control Set DUWI Everlux) and a Fibaro FGRM-222, both having the same behavior. However they seem to be correctly wired because the switches work correctly.

 Anyone else has this issue?

BRegards,

Nuno

[ma.voo...@iname.com]

Yes,

I have the same issue with Fakro zwave products. We have 6 rollershutters and 3 rollercurtains, all zwave controlled. They all show reverse open/close directions. So we have to give reverse commands with openhab. It is very annoying en confusing. Especially because I am interfacing with a KNX-system with a visualisation...

All the wires seem to be correctly wired, I checked it for all the shutters and curtains AND because the original Fakro zwave remote-controll works flawless (up command opens the shutters and curtains, down command closes them).

It would be very helpfull if their could be a kind of 'reverse'-switch in the item-definition of the zwave items or zwave-database definitions for Fakro.

Anyone else using Fakro zwave products?

BRegards,

Michel

Op maandag 9 juni 2014 16:09:37 UTC+2 schreef Nuno Pereira:

[gilles.l...@gmail.com]

Yes me too,

I have to do more tests, I'm a vera user , everything ok for updown and dim, but with openhab up/down is inverted.

I think the best way to know is to connect directly a swith and see where is up wire to continue on a zwave device so no doubt.

Cheers

Gilles.

[Hans Vanbellingen]

Hey,

I had the same problem with my fibaro roller shutters. I solved it by switching all the cables on the fibaro (inverse the outgoing up and down, and the incoming cables from the physical switch).

So that openhab and the switches both go up for up and down for down.

regards

[Thorsten Lanfer]

Hi,

i am the author of the above mentioned issue on github (#1060).

I was thinking about rewiring, but it would mean i had to not only rewrite, but also turn the switches upside down.

When i wanted to give that a try on one of my switches i saw a label on the back, showing which way should be up, so i think this is something that should be dealt with in Software, not hardware.

I did not yet have a look at how other apps deal with this, but i think this is something that should be dealt with in software.

[Nuno Pereira]

I already tried other apps and the shutters are working correctly. Seems to be something wrong on the Zwave binding that has the inversed values for open and close.

--
You received this message because you are subscribed to a topic in the Google Groups "openhab" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openhab/IZMVP4BZTkU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openhab+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.
Visit this group at http://groups.google.com/group/openhab.
For more options, visit https://groups.google.com/d/optout.

[ma.voo...@iname.com]

With the Fakro zwave rollershutters and -curtains the zwave chip/controller and moter is integrated in the product. The only rewiring I can do is to switch the 12V polarity that feeds the zway-chip and the motor. If I do that, despite the clear directions in the manual, nothings works anymore. I have to wire the polarity like it says in the manual.

So, the reverse operation of these zwave products is not a wiring fault with these products.

BRegards,

Michel

[maihacke]

I had to reverse wiring for my fibaro rollershutters, too.

They were inverted in open-zwave-controll-panel, too. So I don't know it's a software or hardware/documentation fault.

Maybe we can introduce a per item parameter for rollershutters?

[Chris Jackson]

They were inverted in open-zwave-controll-panel, too. So I don't know it's a software or hardware/documentation fault.

I don’t have any roller shutters, but clearly this is an issue so I’ll try and help… I assume this is the multilevel switch command class? Looking at the docs, it states the following -:

Up/Down (1 bit)

If the Up/Down bit is set to 0 the switch should increase the level. If field is set to 1 the switch should decrease the level.

In the binding, we use 1 for down, and 0 for up - at first glance this appears to be consistent with the above definition, but this definition is actually not clear! It states setting to 0 will increase the LEVEL, but this isn’t (necessarily) the same as UP - i.e. is 100% down or up? If it’s fully DOWN, then this would be around the wrong way.

So, I suspect, since everyone has the same problem, that this is around the wrong way so I’ll take a look at swapping this around.

Chris

[Chris Jackson]

Please try the binding version I just loaded to the HABmin site - this should reverse the direction. Gilles has tested it and it seems ok now.

I'll probably make this configurable, but for now, this should provide a fix for those who need it.

Chris

[Paul Hampson]

Can you make this a configurable behaviour (default as it was orginally?)? Re wiring many relays may be a pain. Also there is a risk unsuspecting users may get a surprise when this gets pushed and they upgrade to find everything switches round!!

Paul

[maihacke]

I second this. Rewiring all my switches would be a no go.

[maihacke]

Please notice that ozwcp uses the same semantic as openhab (at the moment)

[gilles.l...@gmail.com]

As Chris said,

For the moment this version is just a fix. I test it and it perfectly works.

Chris send me another version with configurable option, if it's ok he will do a version on github.

Gilles.

[Chris Jackson]

That's the plan and ive actually sent a test version out to Gilles already with this option. Once it looks ok I'll make it available.

Cheers

Chris 

Sent from Samsung Mobile

-------- Original message --------

From: Paul Hampson

Date:14/06/2014 20:22 (GMT+00:00)

To: ope...@googlegroups.com

Subject: Re: [openhab] Re: Z-Wave: Reverse RollerShutter direction

Can you make this a configurable behaviour (default as it was orginally?)? Re wiring many relays may be a pain. Also there is a risk unsuspecting users may get a surprise when this gets pushed and they upgrade to find everything switches round!!

Paul

--
You received this message because you are subscribed to the Google Groups "openhab" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openhab+u...@googlegroups.com.

[Chris Jackson]

Yes, but both are wrong it seems. Other users (including myself) have Vera so we should get the polarity correct as per the standard and not just make it consistently wrong with another system (In my opinion).

Chris

Sent from Samsung Mobile

-------- Original message --------

From: maihacke

Date:14/06/2014 21:51 (GMT+00:00)

To: ope...@googlegroups.com

Subject: Re: [openhab] Re: Z-Wave: Reverse RollerShutter direction

Please notice that ozwcp uses the same semantic as openhab (at the moment)

Am Samstag, 14. Juni 2014 16:33:08 UTC+2 schrieb Chris Jackson:

Please try the binding version I just loaded to the HABmin site - this should reverse the direction. Gilles has tested it and it seems ok now.

I'll probably make this configurable, but for now, this should provide a fix for those who need it.

Chris

--

[Paul Hampson]

Great! Thanks Chris.

You received this message because you are subscribed to a topic in the Google Groups "openhab" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openhab/IZMVP4BZTkU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openhab+u...@googlegroups.com.

[Chris Jackson]

Can you make this a configurable behaviour (default as it was orginally?)?

Actually, one caveat on this - I would prefer to make it default to the ‘correct’ way.  I think it’s better for people to be able to wire equipment up as per their devices instructions and expect it to work, and (I think) most people who already have wired around the other way will know about the issue so adding an extra ‘invert_state=true’ to their bindings shouldn’t be an issue?

Chris

[maihacke]

For me that's fine.

If I member correctly rollershutter support is relative new, so we can except not to confuse to many people already using them.

[Chris Jackson]

Please note that as of this afternoon, the new roller shutter code is merged! This reverses the direction of the roller shutter, but also adds an option to invert the direction.

From the wiki -:

invert_state=true can be used to invert the state of a multilevel switch command class. eg this can be used to reverse the direction of a rollershutter.

Any problems, please yell :)

Cheers

Chris

[Jürgen Langwost]

I just installed a FIBARO FGRM 222 (roller shutter V2 with energy meter and positioning) in my ready-to-begin smart home.
The up/down behaviour with the latest z-wave snapshot from Chris is working as expected using the switch and motor wiring from the handbook and no invert_state.
This nice FIBARO device is able to understand the commands up, down, stop as well as percentage (!)
However, the device return values rollers full up = 100% and rollers full down = 0% (and of course all values in between) seems to be contrary to the openhab images and to "my" understanding of rollershutters.

Anybody else out there having this kind of return values from the rollershutters?

Greetings
Jürgen

[gilles.l...@gmail.com]

 Yes Everything is ok from now to me too.

Just icon doesn't follow the position value.

As 100 % is fully open , icon show a closed roller shutter whereas it would be open.

Chris could you do something or it is from openhab side ?

Cheers,

gilles

[Chris Jackson]

Hi,
I suspect that the definition of UP and DOWN between OH and ZWave is reversed - we already know that the documentation is confusing, so I’d like to get a log from someone with the following test.

Move the shutter all the way down
Move the shutter up to quarter of the way up (just by looking at it).
Then 50%, then 75%, then all the way up.

I can easily align the definitions, but I just want to be able to see what’s happening first.

Thanks
Chris

[Gilles L]

I can do it if you want.  Or someone want to test it?
Cheers,
Gilles.

[Chris Jackson]

Hi Gilles,
That would be great - thanks :)

Cheers
Chris

[Gilles L]

Chris,
I almost finish my test.
I'll send log by Mr.
Cheers,
Gilles

[Chris Jackson]

Thanks Gilles.

[Jürgen Langwost]

Hi Chris,

please find the log attached. I hope you can get through. Rollershutter is node 6.

Strange behaviour: When I tried to start OH in debug mode (start_debug.bat), the rollershutter was working in the wrong direction. Tried 3 times, then again start.bat and everything was fine. I have to look into this detail soon, because I don't understand what debug session makes the binding act different ?!

Jürgen

[Chris Jackson]

Thanks. I will try and fix this tonight - I'll probably put a test version on the HABmin site before pushing the change...

Regarding the debug, this is strange - it shouldn't make any difference, but please let me know what you find.

Cheers

Chris

[Chris Jackson]

Thanks Gilles and Jürgen for the files.
I can confirm that zwave device returns 0 for down, and 100 for up, so this is the reverse of the definition used by OH… I’ll swap this around in the binding and will upload a new version to the HABmin site tonight.

Chris

[Gilles L]

Your welcome. Thank you for your quick answer. So I'll try it tonight. Just have not to open my wife roller shutter. 😁
Gilles.

Le 7 juil. 2014 18:03, "Chris Jackson" <ch...@cd-jackson.com> a écrit :

Thanks Gilles and Jürgen for the files.

I can confirm that zwave device returns 0 for down, and 100 for up, so this is the reverse of the definition used by OH... I'll swap this around in the binding and will upload a new version to the HABmin site tonight.

Chris

[Chris Jackson]

I’ve just loaded the test version to the HABmin site - please blame me if your wife gets upset :)

Cheers
Chris

[Jürgen Langwost]

Sorry to tell you, but nothing changed :-( Still 100% full open, 0% full closed.

Cheers
Jürgen

[Chris Jackson]

Something seems to have gone astray. I'm sure I sent an email describing this, but I don't see it in the forum :(

Anyway, you need to add the argument invert_percent=true to the item definition...

Chris

[Jürgen Langwost]

Hi Chris,

Thanks a lot. Now it works perfect.
Within the next few days I will get a few more of the Fibaro's - looking forward to automate the house at the weekend ;-)

Jürgen

[Chris Jackson]

Cool - I’ll push this.  Gilles has raised another issue regarding dimmer widget use, but I’ll have to have another think about that…

Cheers

Chris

--

You received this message because you are subscribed to the Google Groups "openhab" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openhab+u...@googlegroups.com.

[Jürgen Langwost]

Hi Chris,

I don't know if the pm worked yesterday, therefore I try again in the group.

In my view the "invert_percent=true" thingy has to be adjusted a bit.
I have the following setup here:

Item:
Rollershutter Shutter_Living1         "Rollade WZ Seitentür [%d %%]"        (gEG,gShutters) {zwave="6:command=switch_multilevel,invert_state=false,invert_percent=true"}

Rule:
sendCommand(Shutter_Living1, 83)
--> shall close Shutter to almost close

Result: Roller Shutter is moving to 17% (almost open) :-(

Any Idea?

Cheers
Jürgen

[Jürgen Langwost]

It seems that my posting got lost over summer vacation :-(
Is there any chance to take a look for this "feature"?

Thanks and best regards,

Jürgen