Update: got my blinds mounted yesterday, then just spent the morning installing the modules, result:
With one of the old (blue cover bar, firmware application version 22.22) FGRM-222, everything works as expected (can control lamella tilt using Fibar class commands).
With a new (green cover bar, firmware application version 25.25) FGRM-222, it does not (no Fibar commands available -> no separate lamella control).
What you can do in the meantime is to create a series of commands after positioning (send UP, short pause, then STOP) to simulate what the lamella control part does in a working module. That of course is just an uncomfortable workaround, but at least you can turn lamellas that way.
Still, I canât believe they actually removed this feature in latest hardware or firmware.
Iâve posted this in the Fibaro forum, but no feedback yet.
The proprietary fibaro command class is currently tied to one specific device with id 0x010F, 0x0301. Your new roller shutter has probably a different id and is not recognised as having the fibaro command class.
Hmm. Right, my working devices have that ID while the newer ones have 0x010F,0x0302 (but note manufacturer is 1001 instead of 1000).
I checked the zwave database, in products.xml both IDs are known and refer to the same fgrm-222.xml file.
Shouldnât the device itself announce its capabilities, i.e. its proprietary class ? Or what part of the code do you refer to where we would need to add the new deviceâs ID ?
This is the PR of the initial addition in the openHAB 1 binding:
@chris There is one key per manufacturer and device ID combination.
Using different CommandClass enums with different keys (manu/dev) that all reference to the FibaroFGRM222CommandClass.class (code) will work in this direction.
But the class itself reference to a CommandClass (code).
Have you any ideas how to implement that one?
One option would be to make FibaroFGRM222CommandClass abstract with the abstract method âgetCommandClass()â and the different enums (key / manu+dev) reference to different child classes.
But that is not nice.
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.
.
).