As announced on the RFXCOM blog http://blog.rfxcom.com, support for LucciAir DC speed 1 to 6 was added to the RFXCOM firmware version 1044 on May 20th, 2021. Direct speed control is already available for LucciAir DC II for a longer time but not for LucciAir DC until this update. It would be cool, if this could be added to the RFXCOM binding as well. I am happy to test this feature with my Lucci fan, as I previously did for RFXCOM.
The changes seem to be minimal, but we need some consideration how to keep it backwards compatible or decide not to:
https://download.martinvw.nl/org.openhab.binding.rfxcom-3.3.0-SNAPSHOT-lucca-fan.jar
Note the diff is a bit troubled but I’ll rebase later, the specific change is in:
Hi Martin,
Thanks! I will try to test it this evening and will let you know.
What kind of backward compatibility you are referring to?
BR,
Gerald
Dear Martin,
Just installed the Jar file. However, which Thing channel I have to use for speed control? I would have expected something like „Fan Speed“ like available for Lucca Air DC II. There is „Global Speed Control“, but this does not relate to the fix values of 1-6 but is rather represented by Rollershutter, right?
BR,
Gerald
Are you sure nothing is cached and that you removed the old version?
Quite sure. Deinstalled existing bundle, installed version in the Karaf console (by using your link)
300 │ Active │ 80 │ 3.3.0.202201131036 │ openHAB Add-ons :: Bundles :: Rfxcom Binding
Restarted OpenHAB as well to be sure.
Rollershutter LucciSpeed “LucciSpeed” { channel=“rfxcom:fan_lucci_dc:8d3bdfa9:fanSpeed”}
Works as previously. UP = speed 3; DOWN = speed 1
Number FanSpeed “Fan speed” {channel=“rfxcom:fan_lucci_dc:8d3bdfa9:fanSpeed”}
Has no effect (nothing happens)
Regarding compatibility: I have a Lucci Airfusion Akmani. It might be that this uses a protocol variant of Lucci Air DC. In my case the remote control has an UP/DOWN button, but the remote itself stores the speed values and send it to the fan (1-6, i.e. every UP button press increases the value on the remote control). The effect of the actual RFXCOM add-on using a Rollershutter is as described above (and thus limits the OpenHAB integration to just two out of six possible speeds in my case). Maybe UP/DOWN works differently for other Fans using the Lucca Air DC protocol?
Tried it now as well with an Item
String LucciControl "LucciControl" {channel="rfxcom:fan_lucci_dc:8d3bdfa9:commandString"}
and sending commands like
LUCCI_AIR_DC_SPEED_1
No effect.
The XML configuration is changed in such a way that it should have become numeric can you create a different device by hand and check whether that does render a different control? See also the changes in bundles/org.openhab.binding.rfxcom/src/main/resources/OH-INF/thing/fan_lucci_dc.xml
The command-string also looks okay, on first sight, do you have any DEBUG logging available?
I just checked the code this (sending literal command-strings) should be send as:
SPEED_1 instead
SPEED_1
via
String LucciControl "LucciControl" {channel="rfxcom:fan_lucci_dc:8d3bdfa9:commandString"}
works now (i.e., fan is reacting accordingly!), e.g. in
Selection item=LucciControl mappings=[UP="Hoch", DOWN="Runter", POWER="Power", LIGHT="Light", REVERSE="Reverse", NATURAL_FLOW="Flow", SPEED_1="Speed 1", SPEED_2="Speed 2", SPEED_3="Speed 3", SPEED_4="Speed 4", SPEED_5="Speed 5", SPEED_6="Speed 6"]
however
Number FanSpeed "Fan speed" {channel="rfxcom:fan_lucci_dc:8d3bdfa9:fanSpeed"}
does not sync its value.
Creating a new Lucci Air DC Thing created indeed the appropriate “Fan Speed” channel (formerly “Global Speed Control”! However, I was not yet able to use a corresponding item such as
Number FanSpeed "Fan speed" {channel="rfxcom:fan_lucci_dc:b4c7889b:ddab599665:fanSpeed"}
to control the device. As mentioned above
String LucciControl "LucciControl" {channel="rfxcom:fan_lucci_dc:8d3bdfa9:commandString"}
works now at least!
I used the following in my sitemap, and it seems to work:
Default item=RFXCOMFanDeviceLucci_FanSpeed
Switch item=RFXCOMFanDeviceLucci_FanSpeed mappings=[1="1", 2="2", 3="3", 4="4", 5="5", 6="6"]
With item defined as a number as shown by you
Hm, copied your configuration (of course changed the item name), still does not work. Could it be that
commandString
forwards the command directly to the firmware and thus would work which the previous add-on version as long as the new RFXCOM firmware is uploaded? Want to say that maybe I still have not the correct version installed, despite
bundle:list
is telling me
300 │ Active │ 80 │ 3.3.0.202201131036 │ openHAB Add-ons :: Bundles :: Rfxcom Binding
You mentioned some cache as possible error cause (I deinstalled the add-on via OpenHAB’s web front-end and installed yours by the karaf console using your link).The link to the jar file provided by you above is surely the right one?
Checked now my openhab.log when changing the speed via
fanSpeed
channel. I got the following exception:
2022-01-14 20:19:01.626 [ERROR] [nal.common.AbstractInvocationHandler] - An error occurred while calling method 'ThingHandler.handleCommand()' on 'org.openhab.binding.rfxcom.internal.handler.RFXComHandler@81e43f': null
java.lang.NullPointerException: null
at org.openhab.binding.rfxcom.internal.messages.RFXComFanMessage$Commands.bySpeed(RFXComFanMessage.java:150) ~[?:?]
at org.openhab.binding.rfxcom.internal.messages.RFXComFanMessage.handleFanSpeedCommand(RFXComFanMessage.java:444) ~[?:?]
at org.openhab.binding.rfxcom.internal.messages.RFXComFanMessage.convertFromState(RFXComFanMessage.java:378) ~[?:?]
at org.openhab.binding.rfxcom.internal.messages.RFXComMessageFactoryImpl.createMessage(RFXComMessageFactoryImpl.java:113) ~[?:?]
at org.openhab.binding.rfxcom.internal.handler.RFXComHandler.handleCommand(RFXComHandler.java:98) ~[?:?]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:?]
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
at org.openhab.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:154) [bundleFile:?]
at org.openhab.core.internal.common.InvocationHandlerSync.invoke(InvocationHandlerSync.java:59) [bundleFile:?]
at com.sun.proxy.$Proxy2799.handleCommand(Unknown Source) [?:?]
at org.openhab.core.thing.internal.profiles.ProfileCallbackImpl.handleCommand(ProfileCallbackImpl.java:80) [bundleFile:?]
at org.openhab.core.thing.internal.profiles.SystemDefaultProfile.onCommandFromItem(SystemDefaultProfile.java:48) [bundleFile:?]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:?]
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
at org.openhab.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:154) [bundleFile:?]
at org.openhab.core.internal.common.Invocation.call(Invocation.java:52) [bundleFile:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
at java.lang.Thread.run(Thread.java:829) [?:?]
I have some problems doing a full testing with my Rfxcom either the firmware is too old or I did not enable the fan messages so I can not yet do a full test.
The command string is not directly forwarded to the the firmware so something else seems to be going on, I will do some more testing tomorrow and see whether that null pointer gives me some new insights 
Found the error, I published a new version at:
https://download.martinvw.nl/org.openhab.binding.rfxcom-3.3.0-SNAPSHOT-lucca-fan-2.jar
I tested a bit more this time.
Works like a charm! Thanks!!!
What do you think now about the backward compatibility? Worth to check if the previous Rollershutter approach is the preferred one for other users not owning the Lucci Akmani fan? According to https://www.lightology.com/index.php?module=prod_detail&prod_id=964266 the remote is only compatible with the Akmani. Maybe there are more other Lucci DC around, which differ in slightly in the protocol. Would it help to define a new Sub Type, if my suspicion is true?
The problem is that I made a bad choice during the previous implementation, I choose the same name for the rollershutter-approach and the numeric-approach because in all cases the devices only supported one, but now we have a challenge because one device in the world of the rfxcom supports both, I could choose an inconsistent name here or break the existing one, I’m inclined to do the last one.
But then the next topping is naming, maybe I should rename all rollershutter channels to fanSpeedControl and keep all the numeric ones at fanSpeed that feels the cleanest to me, WDYT?