It’s not very pretty, but it’s simple and maybe sufficient for OH1 at least…
I can’t see any other way to do this - there needs to be some way to link the command class, to the actual device (and arguably, different versions of the device). It’s probably something we could configure in the database or something, but I’d suggest for now we just do the simple option above?
Are we talking about OH1?
I have been thinking about the openHAB 2 Z-Wave binding.
I just adding the OH1 PR link, that we have a code base that contains the changes that has been done that time.
As written above the FibaroFGRM222CommandClass.class contains a function “getCommandClass()” that does need to return a enum value (currently FIBARO_FGRM_222). If we have two, which one should returned (FIBARO_FGRM_222_1 or FIBARO_FGRM_222_2)? I don’t know what the caller does with this enum.
For me there is no need to add a quick and dirty solution.
IMHO (at least for the OH2 one) we should consider a “good” solution that fit the needs.
Yes - at least the original question was referring to OH1, and my answer was on this basis as it was asking about OH1 binding strings. I haven’t read every message since my earlier reply, so maybe the conversation changed to OH2 - sorry for that.
Well, if this is for OH1, I disagree, and I made the statement on this basis, so again, sorry for missing that this was now talking about OH2. I think for OH1, there’s no point in spending lots of time to make an elegant solution when in 3 years of maintaining the binding, this is the first time this has come up, and it’s unlikely the binding will receive a lot more work…
For OH2, I agree - I would like to do this properly, but as above, I thought we were talking about OH1 - sorry. .
I agree, for OH1 a solution that is working is enough. No need to do much work for that.
I assume we have been talked about OH1 all the time and I missed that.
So, I don’t think I will touch that code myself, as it is IMHO outdated and superseded by the OH2 binding of @chris (thanks a lot to that guy).
Sorry, but I need to say as a topicstarter, that I lost interest to this topic, because I see it a bit incorrect way to support lamellas positioning using manufacturer/specific z-wave class. For me it would be definitely more interesting if we would have an item, which controls venetian blinds in hardware-independent manner, and keep z-wave binding itself clean from so kind “manufacturer-specific” features. Nobody knows, as it is right now, when support will be dropped, or what to do if Fibaro suddenly change behaviour of this pretty undocumented feature.
Then you also don’t have a kind of headache, how to make “good” support for it in OH 2.
@Artyom_Syomushkin IMHO there is no other way to set the position correctly for the FGRM-222. If the manufacturer only offers the option using a non-standard command class, there is nothing we can do (except implement that class).
So, if you don’t like to use such a solution you cannot use the FGRM-222. Perhaps other devices of other manufacturers offers a “normal” command class.
But I am not such familiar with Z-Wave at all.
Venetian Blinds control algorithm, realized in FGRM-222 is nothing else than just a function, which switches ON up/down motor direction shortly after new blinds position is adjusted. the duration of this ON pulse is defined by needed lamellas angle and can be easily calculated, knowing that full turn takes about 1,5 seconds and lamellas are either fully closed or open after long movement of blinds, depending on previous direction.
So all is required is to generate such pulse after user adjusts new position or wants to change lamellas angle. This should be possible using rules as well, so I don’t see the problem to add some type if item(aka implement our own class) for this with it’s own accepted commands.
Well, I’m still interested because I want my freshly installed venetian blinds to fully work (lamella tilt) with my FGRM-222s, just as probably everybody who owns some of these does.
Most people still use OH1, and will continue doing for quite some time. So do I.
So please add the new device ID into OH1 binding’s special support for Fibaro’s proprietary class.
Quick and dirty, just like the existing FIBARO_FGRM_222 command support.
If you can do easily, please also forward-port this quick and dirty solution to OH2 (just to ease transition, anybody with this setup doing the move from OH1 to OH2 will be thankful). If it can’t be done quickly, for OH2 go for the long term solution.
As a long-term solution, I agree with @Artyom_Syomushkin that the ‘right’ solution is to add another short movement in the opposite direction after positioning.
That’s something that should not and need not be done using proprietary commands (so it’ll work with any other rollershutter device, too, including non-zwave ones), and it should not be done in the zwave binding.
I suggest to add this function to the core OH module that implements the “Rollershutter” item. Keep the type=[shutter|lamella] syntax and implement (or fix) the ‘lamella’ part - possibly that’s even meant to already work that way ?
Maybe @Artyom_Syomushkin you could raise an issue to ask the ‘rollershutter’ author and have him either fix or add the feature ?
Please let me know if it works - both with new and old devices (well - I’m sure people will say if it doesn’t work anyway ).
I don’t want to hack dirty solutions into OH2 - dirty hacks are hard to remove and are often joined by dirtier hacks to work around issues that should have been solved with a good design to start with.
Ultimately we need a good way to deal with the manufacturer specific classes. Currently this is the only one we have implemented, and maybe a more generic solution might be better. However, I do know that Fibaro have other interesting features in some of their devices that might be nice to hack one day, so we should have an elegant solution for incorporating them… I have some ideas, but I won’t rush into it if it’s not needed yet…
Well, not that many people trying this combo, I believe, so it’s up to us here in the thread to find out. Sorry it took me so long to try.
I’m afraid it doesn’t work. Now (cloudbees’ OH1 zwave addon jar as of yesterday) it does not work neither with old nor with new device.
Now the old device doesn’t know ‘FIBARO_FGRM_222’ command any more (“no such command class”), even after reinitializing the node from habmin (node.xml that got written see below. Same error now with the new device (and config that works with the 1.8.2 binding). Also tried command=FIBARO_FGRM_222_1. No error is logged with that one, but no lamella movement either. For both, old and new device. old_fgrm-222.xml (6.4 KB) new_fgrm-222.xml (6.4 KB)
no, then I get 2016-05-14 09:38:20.325 [WARN ] [.b.z.i.c.ZWaveConverterHandler] - NODE 113: No converter found for item = EG_Wohnen_Jalousie_links_Lamellen, ignoring command.
for both, old and new device. Also, command=FIBARO_FGRM_222 does not work any more on (non-reinitialized) old device.
Funny: I reverted to 1.8.2 but had accidentially kept the command=MANUFACTURER_PROPRIETARY,
and guess what? It works with the new actor. For the old HW revision actor, only FIBARO_FGRM_222 works.
The algorithm in the FGRM-222 is not rocket science, in that you’re right. But implementing that algorithm generically in OpenHAB (which I would prefer just like you do) would require either one of two things. 1) A zwave command in the FGRM to drive the blinds for a specified time instead of percentage of calibrated height. Or 2) a “near realtime” connection from OpenHAB via zwave controller, via a potentially varying number of routing zwave nodes to the FGRM. With OpenHAB installed on a Raspberry PI I have varying latencies of nearly zero to a couple of seconds, depending at least on CPU load but probably also on zwave components. Not sufficient to precisely drive the lamellas for a fraction of a 1.5s timespan is it?
For the first approach we’d just feed the calculated times into the FGRM, but I have not seen that type of command for the FGRM.
Concerning second option the problem definitely somewhere in Openhab, as Z-Wave, at least in my instalation, shows quite stable latencies of 40-60ms(100ms round trip). I was able to test them by connecting USB Z-Stick to my laptop and running Z-Wave health utility, which allows pinging any node on different power levels multiple times. So that should be fine.
Quite big time variation comes from OH Rules engine, but I will use different one.
I have just installed the rest of my FGRMs, so will return to this topic soon
Just wanted to know if there is any progress regarding the lamellas positioning for the roller shutters.
I’m very new to OpenHab and I’m not sure I’m looking in the right spots etc. but one key functionality I’m looking for is controlling my blinds.
Until now I managed to control the positioning of the blinds but not the angle of the lamellas.
OH2 is not the problem. Zwave binding in version 2 does not support the fibaro proprietary class at the moment. Chris is searching for a good implementation, which is not too proprietary at all, from what I know.
Faking the function from openhab rules/scripts will not work. With zwave you will never have guaranteed RTT. So any time based calculations will fail. Fibaro does the calculation for turning up or down on the device itself. So there is no variable latency, like Henning already wrote.
I do the lamella positioning by using mqtt to a second controller running zway.
.
).