Good to hear that it works for you
Being included into the official release sounds like a plan for 2020 then. Although 2.5 is definitely not going to be feasible.
1 Like
Hi Daniel, that would be really great 
If this is going to happen, I would really like to also add a location to the thing, which is not possible right now.
Thing somfycul:somfydevice:sunshade “[somfy] Terrassenmarkise” @ “somwhere” (somfycul:culdevice:nanocul868)
This is probably quite easy I guess. Just as an idea.
Hi all,
I tried to set up the (nano)CUL-Stick to get it working with my Somfy RTS-Rollershutters in Openhab. I’m running OH2.5.0 (openhabian on Ubuntu).
I set up the binding like explained above by copying the jar to the addons-Folder, set up the Things and items and they are showing as ONLINE. Created the sitemap for the Programming-Switch and the Shutter-Control.
With copying the jar-File to the addons-Folder, I received
Unresolved requirement: Import-Package: gnu.io
witch I resolved with
feature:install openhab-transport-serial
But then I ran into the same issue like Jean-Marc mentioned above that the files in /var/lib/openhab2/somfycul are created as “./somfycul_somfydevice_kueche.properties” (so correct naming) but they are empty.
If I try to program a shutter, I receive the same “NULL”-Error.
2019-12-27 13:46:19.512 [INFO ] [ing.somfycul.handler.SomfyCULHandler] - channelUID: somfycul:somfydevice:kueche:program, command: ON
2019-12-27 13:46:19.514 [INFO ] [.binding.somfycul.handler.CulHandler] - Send message YsA180nullnull for thing Jalousie Kueche
2019-12-27 13:46:19.524 [ERROR] [nal.common.AbstractInvocationHandler] - An error occurred while calling method 'ThingHandler.handleCommand()' on 'org.openhab.binding.somfycul.handler.SomfyCULHandler@be1707': For input string: "null"
java.lang.NumberFormatException: For input string: "null"
at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) ~[?:1.8.0_232]
at java.lang.Long.parseLong(Long.java:589) ~[?:1.8.0_232]
at java.lang.Long.valueOf(Long.java:776) ~[?:1.8.0_232]
at java.lang.Long.decode(Long.java:928) ~[?:1.8.0_232]
at org.openhab.binding.somfycul.handler.SomfyCULHandler.handleCommand(SomfyCULHandler.java:106) ~[?:?]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_232]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:1.8.0_232]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_232]
at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_232]
at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:152) [bundleFile:?]
at org.eclipse.smarthome.core.internal.common.InvocationHandlerSync.invoke(InvocationHandlerSync.java:59) [bundleFile:?]
at com.sun.proxy.$Proxy5760.handleCommand(Unknown Source) [?:?]
at org.eclipse.smarthome.core.thing.internal.profiles.ProfileCallbackImpl.handleCommand(ProfileCallbackImpl.java:74) [bundleFile:?]
at org.eclipse.smarthome.core.thing.internal.profiles.SystemDefaultProfile.onCommandFromItem(SystemDefaultProfile.java:48) [bundleFile:?]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_232]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:1.8.0_232]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_232]
at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_232]
at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:152) [bundleFile:?]
at org.eclipse.smarthome.core.internal.common.Invocation.call(Invocation.java:52) [bundleFile:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:1.8.0_232]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_232]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_232]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_232]
Is there a way to identify the RollingCode and Address anyhow? I’m absolutely not experienced with CUL so an easy explenation would be much appreciated. 
Many thanks in advance
Matze.
Hi,
as I have not upgraded my installation to OpenHAB 2.5 I have not checked if the "old " plugin is working flawlessly. However when starting to port the plugin to the new OpenHAB version I found a couple of things that might break.
@MatzeG The address is an identifier that is set, when you learn your “new” remote to the shutter. It is being set by the plugin. The rolling code is an identifier that is updated after every command that was set by the according remote. - Technical details can be found at http://culfw.de/commandref.html#cmd_Y
So you can’t really identify those values, but they are “defined” when learning a new remote. The OpenHAB instance is thus considered a new remote for the shutter.
Cheers
Daniel
Hi Daniel,
thanks for the heads up on this and explanation. Tried further settings on this one but did not get it running with Openhab. Always had the “NULL”-Error in the logs. After several tries I decided to get back to bind the Shutters to my HomeMatic-Installation with CuxD and it works.
I just wanted to “clean up” and have the shutters controlled directly via Openhab.
But anyhow, thanks for the help and information.
Cheers, Matthias.
Hi,
I have migrated my OpenHAB installation to version 2.5 and I do have an adapted version of the plugin running. Learning new shutters should work as well. The jar file can be found at http://www.danielweisser.de/org.openhab.binding.somfycul-2.5.0.jar
The source is somehow based on https://github.com/weisserd/openhab2-addons/tree/binding-somfycul - somehow because of the current changes of OpenHAB to version 3 (Development of openHAB 3.0.0 and 2.5.x) I do not have all changes on my current branch on github.
The baud rate is now configurable and my settings look as follows:
somfycul:culdevice:cul [ port="/dev/ttyACM0", baudrate="9600" ]
2 Likes
Very nice, thanks. I’m going to try it out a.s.a.p.
Hi all,
I’ve tried the jar for OpenHAB 2.5 with OpenHAB 2.5. Both the ‘CUL stick’ and ‘Somfy RTS rollershutter’ Things are online and react (GUI). Everything works fine until I try to register my NanoCUL/OpenHAB with the Somfy RTS receiver of my shutters. I never receive any confirmation from the receiver (i.e. brief shutter movement down and up), and the registration process obviously fails: I can’t control the shutters subsequently with OpenHAB. The log files events.log and openhab.log don’t show any errors or unexpected entries (as far as I can tell). Also somfycul_somfydevice_.properties contains plausible content.
The NanoCUL used to work with the shutters with FHEM (2 years ago). Is there anything else that I could check?
Regards, Michael
Hi Michael,
did you follow the steps mentioned at the comment above (OpenHAB CULfw for Somfy RTS Rollershutters)?
Or a dirty hack might be to reuse the “configuration” of (a working and existing) FHEM installation and use the same identifiers.
Cheers
Daniel
Hi Daniel,
Yes, I followed these steps.
Unfortunately, I don’t have an FHEM installation at hand anymore. So I’m currently not able to do this cross-check.
Ciao, Michael
Hi Guys,
i´ve an active openhabian installation which is managing the whole house (roomheating, lights, warm water, photovoltaik, etc)
now i a have the issue that my rollershutters (somfy rts) only run with my fhem installation.
I need to integrate them to my openhabian (all is app based)
somfycul is not available and i don´t understand (no step by step manual available) to integrate it.
Can you send short howto, and maybe your configuration examples?
my build openHAB 2.5.3 Release
one rollershutter:
this is the config of the usb-serial-433 device:
i´ve added org.openhab.binding.somfycul-2.5.0.jar to /usr/share/openhab2/addons
but don´t see it in PaperUI
Hi,
@Patrick_Hornaus:
You may be running into the “missing gnu.io” issue (for description and solution, see further above).
@Daniel_Weisser:
I was able to dig out my former FHEM installation, where I have verified that I can still control my shutters with that installation. At the same time I have realized (and remembered) that I actually have a SIGNALduino rather than a nanoCUL. I assume that this is the reason why I can’t use it with the somfycul. Any idea what I could do (I am willing to do coding to a limited degree). I also have SomfyCULTest running (without success).
Cheers, Michael
Oops, of course, yes. I wasn’t aware of this auto-expansion thing. Trying to modify the original post.
that did the job:
login through ssh to openhabian,
then ssh -p 8101 openhab@localhost
default password is habopen
add to terminal: feature:install openhab-transport-serial
add to terminal: logout
now i have somfycul available,
quite easy if somebody helps you with an howto.
it looks like its sending something, i´ve followed the steps from Daniel:
The installation worked for me as follows:
1. Install the binding into your OpenHab installation (see Distributing bindings through the IoT Marketplace )
2. Add the appropriate things to your config (.things)*
* *somfycul:culdevice:cul [ port="/dev/ttyACM0" ]* *somfycul:somfydevice:esslinks (somfycul:culdevice:cul)* *3. Add a rollershutter as a switch to your sitemap for programming the switch (.items and .sitemap)
* *Switch Shutter_Ess_Links "Eßzimmer links" (somfyFF) {channel="somfycul:somfydevice:esslinks:program"} * *4. Set the rollershutter to programming mode via your remote (should go up and down slightly)
5. Press the switch in your sitemap (the rollershutter should go up and down slightly for confirmation)
6. Change the rollershutter in your items and sitemap to a rollershutter
* *Rollershutter Shutter_Ess_Links "Eßzimmer links" (somfyFF) {channel="somfycul:somfydevice:esslinks:position"} * *This is how I set up all my rollershutters in my house now via a CUL.
but my rts blinds do not react.
Hi Patrick,
are you using the JAR file from the marketplace? I have not changed that and adapted it to the new versions of openHAB, so that might cause some problems.
Hi Michael,
as I’m using the same commands as the FHEM installation (http://culfw.de/culfw.html) it should be able to bring it to work with OpenHAB as well.
Hi Daniel,
I tried my CUL with both the culfw and the SIGNALduino firmware, with no success. I used both OpenHAB with the SomfyCUL binding and the serial-cul-test Java program. However, I never managed to trigger any reaction on the Somfy receiver (shutter) side. So I suspect that my CUL may not be initialized correctly. It still works OK with FHEM and the Somfy shutters (as SIGNALduino).
Don’t know what else to try.
Cheers, Michael