I have not read your code but i guessed this behavior.
Actually, i use also another soft to control KLF200 : PYVLX pyvlx
But in python and no openhab compliant.
This soft works perfectly but uses only name as device ID, not serial (that’s why it works indeed).
Perhaps is it possible to add a new channel as actuator ID ? Exemple :
{ velux="thing=actuator;channel="UNIQUENAME_INSTEADOF_SERIAL" } //?
Or perhaps the NodeID ?
Hi Fabien @funcat,
could you please share some more information about the Somfy devices: is a unique node name guaranteed? Or would it make more sense to differentiate them by the registration seat (i.e. number)?
Any hints are appreciated!
Hello @funcat,
you’ll find an adapted binding for somfy devices with unusual serial numbers (00:00:00:00:00:00:00:00:00) at https://github.com/gs4711/org.openhab.binding.velux
It should display the retrieved device names (which are used instead of the numbers) during start.
Regards, Guenther
Now, those warnings are eliminated. 
how, where? 
Hi Guenther,
I tried your last version and it works.
All devices are registered now, with name instead of serial.
How can i reference and access them after that ?
I try { velux="thing=actuator;channel=serial#name } ?
Or something like { velux="thing=actuator;channel=name#name } ?
Many thanks for your hard work.
Hi Fabien,
as the simpliest way was to replace the serial by the device name: Every configuration statement where the serial number was mentioned can be used with the name, now.
Of course, this leads to some restrictions which are not solved yet:
Not having the possibility to run a QA, I suggest to configure it like:
Rollershutter SomfyBathrool "Somfy Bath [%d]" { velux="thing=actuator;channel=serial#MyVerySpecialSomfyName" }
This looks very similar to your trial:
If it fails, please increase the loglevel to TRACE and send me the output. Thx in advance!
I´ll give it a try later when I get back home (or sometime during the weekend).
Hi Guenther,
Tested your last release, it works like a charm !
There are just two little anoying things :
[INFO ] [ding.velux.bridge.slip.SCgetProducts] - setResponse(): device provided invalid serial number, using name 'bureau' instead.
This log is on level INFO and come for all device at every refresh.
I know this is not the default behaviour with name instead of serial, but perhaps can you remove this warning or set it to TRACE level ?
Second thing is at initialization :
[INFO ] [.velux.handler.VeluxBridgeHandlerOH1] - Result: check failed: The following scenes are unused: [cuisine_open, maisonHautRue_my, maisonRue_my, maisonHautJardin_my, maisonHautJardin_open, maison_open,│
20│ maisonBasRue_my, maisonHautJardin_close, maisonBasJardin_my, maisonBas_my, maisonBasJardin_open, maisonJardin_close, cuisine_my, maisonJardin_my, maisonRue_open, cuisine_close, maison_close, maisonBas_close, maisonJardin_open, mai│
20│sonBasRue_close, maisonBas_open, maisonHautRue_close, maisonHautRue_open, maisonBasRue_open, maisonBasJardin_close, maisonRue_close, maison_my].
Your check function for used/unused scene still reports failures (again because of zero-serials i guess)
Thanks a lot 
Good point. Will be changed to level DEBUG in next minor release.
For this issue I’m not sure whether this is related to the serial numbers as it informs about unused scenes - this means, scenes, which are defined on the gateway, but never used within any item definition.
Am I wrong?
@funcat: now available as org.openhab.binding.velux-1.14.0.201907200449.jar. Have fun and thank you again for your support!
Blockquote
Good point. Will be changed to levelDEBUGin next minor release.
Thanks, logs are clean now, nice job.
For the scenes, OK no more warning, perhaps my items was off last time i did not remember.
Notice just a minor bug, on my first configuration attempt some days ago i had a bad initialization file with a field “dgeIPAddress” instead of “bridgeIPAddress” (thanks to vi …).
And now, more days after and with a correct config file, i still have the warnings :
20│2019-07-21 12:28:01.612 [WARN ] [.binding.velux.internal.VeluxBinding] - updated(): unknown configuration entry dgeIPAddress:=192.168.0.23. │
20│2019-07-21 12:28:01.621 [WARN ] [.binding.velux.internal.VeluxBinding] - updated(): unknown configuration entry service.pid:=org.openhab.velux.
Perhaps still in memory elsewhere ?
(i did not restart openhab for a looooong time)
Anyway, thanks for all.
Hello @funcat,
This entry is passed to the binding for whatever reason - it seems to be some OH2 internals.
Your other additional configuration should disappear after a restart of openHAB.
Hi @gs4711
I realize now there is a little missing feature for somfy devices.
All my 13 somfy devices (i guess that does apply for all somfy stuff) have a special position named 'MY" that the user can memorize and configure as he wish. (‘sunny’ for exemple)
This position is recorded in KLF-200 as position “108%” (strange but that’s it).
All scene are working perfectly for this position, but when i try to send a command to actuator, openhab says me :
20│2019-07-22 12:23:55.316 [WARN ] [rthome.model.script.actions.BusEvent] - Cannot convert '108' to a command type which item 'bureauVolet' accepts: [UpDownType, StopMoveType, PercentType, RefreshType]. │
Is this a limitation due to item type rollershutter or whatever ?
I have no idea how can i manage this “108% position” for actuator within openhab and the binding KLF200. (all my 32 scenes that handle this are already set)
Any hint ?
Hello Fabian,
this sounds very funny… a position of 108%. Do you have a pointer to a Somfy manual where we could get some more information about this behaviour?
Perhaps this feature can be handled by a special somfy-dedicated positioning but I’d like to check the circumstances before allowing such an approach.
Very helpful could be a debugging output of the values returned by the Somfy device (i.e. with level TRACE on org.openhab.binding.velux.things) . Thx.
Now the following changes are incorporated into the openHAB release (PR#5833):
Bugfixes:
Enhancements:
Final note: The comments for activation with OH2 are removed as there is a good documentation available at distribution doc.
Thanks to everyone for your support with questions, trace files and a lot of patience 
.
Thank you even more for your hard work Guenther… Without, we would have nothing to complaint about 