Yes. I have it working. I don’t remember exactly how I set it up. I know I followed the instructions on the wiki with regards to the item files. I also used openhabian.
I seem to remember that I changed something about how openhab logs in order to see more information.
I do wonder whether your devices work. I seem to remember that only a limited number of devices are supported.
Sorry it is all a bit vague.
@mark_leonard_tuil
How do you know if your gateway is working properly? Do you see it somewhere on the control tab within PaperUI, comparable to, let’s say, a Z-Wave controller?
No, you don’t. I saw messages in the logs after I tweaked the log settings. I did that about a year ago under openhab1. I copied my item files for enocean to openhab2. I think you also have to set a kind of serial port. See the documentation
That was apparently not entirely correct. I changed the serial port to “serialPort=/dev/ttyAMA0”.
I then tried to define my Etalko FT55-rw switch in my .items file according to the EnEocean binding documentation like this, where FE:F9:EB:23 is the ID of my Etalko switch.
Switch Button01top "Switch left top" <wallswitch> { enocean="{id=FE:F9:EB:23, eep=F6:02:01, channel=A, parameter=O}" }
Switch Button01bottom "Switch left bottom" <wallswitch> { enocean="{id=FE:F9:EB:23, eep=F6:02:01, channel=A, parameter=I}" }
Switch Button02top "Switch right top" <wallswitch> { enocean="{id=FE:F9:EB:23, eep=F6:02:01, channel=B, parameter=O}" }
Switch Button02bottom "Switch right bottom" <wallswitch> { enocean="{id=FE:F9:EB:23, eep=F6:02:01, channel=B, parameter=I}"
The log file shows some entries regarding the EnOcean binding.
21:29:28.050 [DEBUG] [org.openhab.binding.enocean ] - BundleEvent STARTING - org.openhab.binding.enocean
21:29:28.057 [DEBUG] [ng.enocean.internal.EnoceanActivator] - enocean binding has been started.
21:29:28.114 [DEBUG] [org.openhab.binding.enocean ] - ServiceEvent REGISTERED - {org.openhab.model.item.binding.BindingConfigReader, org.openhab.binding.enocean.EnoceanBindingProvider}={component.name=org.openhab.binding.enocean.genericbindingprovider, component.id=165, service.id=290, service.bundleid=185, service.scope=bundle} - org.openhab.binding.enocean
21:29:28.120 [DEBUG] [org.openhab.binding.enocean ] - BundleEvent STARTED - org.openhab.binding.enocean
21:29:28.327 [INFO ] [.enocean.internal.bus.EnoceanBinding] - Connecting to Enocean [serialPort='/dev/ttyAMA0' ].
21:29:28.330 [DEBUG] [org.openhab.binding.enocean ] - ServiceEvent REGISTERED - {org.osgi.service.event.EventHandler, org.osgi.service.cm.ManagedService}={event.topics=openhab/command/*, service.pid=org.openhab.enocean, component.name=org.openhab.binding.enocean.binding, component.id=164, service.id=295, service.bundleid=185, service.scope=bundle} - org.openhab.binding.enocean
21:29:29.235 [DEBUG] [.enocean.internal.bus.EnoceanBinding] - Updating item state for items [Button02bottom, Button01top, Button02top, Button01bottom]
However, if I hit a button on my switch, nothing shows up in the logs. So I doubt that my physical switch is really connected to my EnOcean gateway. How can I check if a connection between the switch and the gateway has been established?
Also, the LED of the EnOceanPi card in my RPi3 is constantly showing a green light. Nothing blinks or something like that when hitting a button on my physical switch, which I guess it should, shouldn’t it?
I used to use FHEM before. In FHEM you had to ‘teach in’ the physical switch, i.e. make the connection to the gateway. I am surprised that something like this is not needed in OH2.
At that point I would highly appreciate some further hints 
Just checked the LED. Mine does not blink either when I press the button.
Checked my item file. I have a switch configured like this
Switch SW1 { enocean="{id=BB:FB:B1:D0, eep=F6:02:01, channel=A, parameter=O}" }
I think at least in your last switch you seem to be missing a final curly bracket.
I know I didn’t teach in the switches. Are you sure about the switch id’s? Any typo there and nothing works. That is why in changed the log level. That way you can see what signals are being received on the enocean board. Normally you will only see anything in the logs if and only if a switch you configured in the item files is used.
This was a Copy&Paste mistake. The final curly bracket is in my .items file.[quote=“mark_leonard_tuil, post:6, topic:26262”]
Are you sure about the switch id’s? Any typo there and nothing works.
[/quote]
100% sure. The ID is written on the back of the physical switch: ID: FEF9EB23. I used exactly the same ID in FHEM, in conjunction with eep=F6:02:01. Therefore, my switch should be supported by OH2.
All right, here’s what I did in Karaf:
log:set TRACE
log:tail org.openhab.binding.enocean
Then I restarted the bundle using
bundle:restart org.openhab.binding.enocean
The output of the LOG has been as follows. The shutdown of the binding caused some JAVA errors. I have no idea whether this is something serious. The following start seems to be OK.
11:06:43.309 [DEBUG] [org.openhab.binding.enocean ] - ServiceEvent UNREGISTERING - {org.osgi.service.event.EventHandler, org.osgi.service.cm.ManagedService}={event.topics=openhab/command/*, service.pid=org.openhab.enocean, component.name=org.openhab.binding.enocean.binding, component.id=180, service.id=309, service.bundleid=185, service.scope=bundle} - org.openhab.binding.enocean
11:06:43.312 [ERROR] [org.openhab.binding.enocean ] - [org.openhab.binding.enocean.binding(180)] The deactivate method has thrown an exception
java.lang.NullPointerException
at org.opencean.core.EnoceanSerialConnector.disconnect(EnoceanSerialConnector.java:71)
at org.openhab.binding.enocean.internal.bus.EnoceanBinding.deactivate(EnoceanBinding.java:95)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)[:1.8.0_121]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)[:1.8.0_121]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)[:1.8.0_121]
at java.lang.reflect.Method.invoke(Method.java:498)[:1.8.0_121]
at org.apache.felix.scr.impl.inject.BaseMethod.invokeMethod(BaseMethod.java:224)[32:org.apache.felix.scr:2.0.6]
at org.apache.felix.scr.impl.inject.BaseMethod.access$500(BaseMethod.java:39)[32:org.apache.felix.scr:2.0.6]
at org.apache.felix.scr.impl.inject.BaseMethod$Resolved.invoke(BaseMethod.java:617)[32:org.apache.felix.scr:2.0.6]
at org.apache.felix.scr.impl.inject.BaseMethod.invoke(BaseMethod.java:501)[32:org.apache.felix.scr:2.0.6]
at org.apache.felix.scr.impl.inject.ActivateMethod.invoke(ActivateMethod.java:302)[32:org.apache.felix.scr:2.0.6]
at org.apache.felix.scr.impl.inject.ActivateMethod.invoke(ActivateMethod.java:294)[32:org.apache.felix.scr:2.0.6]
at org.apache.felix.scr.impl.manager.SingleComponentManager.disposeImplementationObject(SingleComponentManager.java:343)[32:org.apache.felix.scr:2.0.6]
at org.apache.felix.scr.impl.manager.SingleComponentManager.deleteComponent(SingleComponentManager.java:152)[32:org.apache.felix.scr:2.0.6]
at org.apache.felix.scr.impl.manager.AbstractComponentManager.doDeactivate(AbstractComponentManager.java:813)[32:org.apache.felix.scr:2.0.6]
at org.apache.felix.scr.impl.manager.AbstractComponentManager.deactivateInternal(AbstractComponentManager.java:787)[32:org.apache.felix.scr:2.0.6]
at org.apache.felix.scr.impl.manager.AbstractComponentManager.dispose(AbstractComponentManager.java:579)[32:org.apache.felix.scr:2.0.6]
at org.apache.felix.scr.impl.manager.ConfigurableComponentHolder.disposeComponents(ConfigurableComponentHolder.java:706)[32:org.apache.felix.scr:2.0.6]
at org.apache.felix.scr.impl.BundleComponentActivator.dispose(BundleComponentActivator.java:523)[32:org.apache.felix.scr:2.0.6]
at org.apache.felix.scr.impl.Activator.disposeComponents(Activator.java:452)[32:org.apache.felix.scr:2.0.6]
at org.apache.felix.scr.impl.Activator.access$300(Activator.java:54)[32:org.apache.felix.scr:2.0.6]
at org.apache.felix.scr.impl.Activator$ScrExtension.destroy(Activator.java:306)[32:org.apache.felix.scr:2.0.6]
at org.apache.felix.utils.extender.AbstractExtender$2.run(AbstractExtender.java:290)[32:org.apache.felix.scr:2.0.6]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)[:1.8.0_121]
at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_121]
at org.apache.felix.utils.extender.AbstractExtender.destroyExtension(AbstractExtender.java:312)[32:org.apache.felix.scr:2.0.6]
at org.apache.felix.utils.extender.AbstractExtender.bundleChanged(AbstractExtender.java:186)[32:org.apache.felix.scr:2.0.6]
at org.eclipse.osgi.internal.framework.BundleContextImpl.dispatchEvent(BundleContextImpl.java:902)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:148)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEventPrivileged(EquinoxEventPublisher.java:165)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEvent(EquinoxEventPublisher.java:75)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEvent(EquinoxEventPublisher.java:67)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at org.eclipse.osgi.internal.framework.EquinoxContainerAdaptor.publishModuleEvent(EquinoxContainerAdaptor.java:102)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at org.eclipse.osgi.container.Module.publishEvent(Module.java:466)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at org.eclipse.osgi.container.Module.doStop(Module.java:624)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at org.eclipse.osgi.container.Module.stop(Module.java:488)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at org.eclipse.osgi.internal.framework.EquinoxBundle.stop(EquinoxBundle.java:419)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at org.apache.karaf.bundle.command.Restart.doExecute(Restart.java:44)[38:org.apache.karaf.bundle.core:4.0.8]
at org.apache.karaf.bundle.command.BundlesCommand.execute(BundlesCommand.java:54)[38:org.apache.karaf.bundle.core:4.0.8]
at org.apache.karaf.shell.impl.action.command.ActionCommand.execute(ActionCommand.java:83)[55:org.apache.karaf.shell.core:4.0.8]
at org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(SecuredCommand.java:67)[55:org.apache.karaf.shell.core:4.0.8]
at org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(SecuredCommand.java:87)[55:org.apache.karaf.shell.core:4.0.8]
at org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:480)[55:org.apache.karaf.shell.core:4.0.8]
at org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:406)[55:org.apache.karaf.shell.core:4.0.8]
at org.apache.felix.gogo.runtime.Pipe.run(Pipe.java:108)[55:org.apache.karaf.shell.core:4.0.8]
at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:182)[55:org.apache.karaf.shell.core:4.0.8]
at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:119)[55:org.apache.karaf.shell.core:4.0.8]
at org.apache.felix.gogo.runtime.CommandSessionImpl.execute(CommandSessionImpl.java:94)[55:org.apache.karaf.shell.core:4.0.8]
at org.apache.karaf.shell.impl.console.ConsoleSessionImpl.run(ConsoleSessionImpl.java:274)[55:org.apache.karaf.shell.core:4.0.8]
at java.lang.Thread.run(Thread.java:745)[:1.8.0_121]
11:06:43.380 [DEBUG] [org.openhab.binding.enocean ] - ServiceEvent UNREGISTERING - {org.openhab.model.item.binding.BindingConfigReader, org.openhab.binding.enocean.EnoceanBindingProvider}={component.name=org.openhab.binding.enocean.genericbindingprovider, component.id=181, service.id=307, service.bundleid=185, service.scope=bundle} - org.openhab.binding.enocean
11:06:43.391 [DEBUG] [org.openhab.binding.enocean ] - BundleEvent STOPPING - org.openhab.binding.enocean
11:06:43.404 [DEBUG] [ng.enocean.internal.EnoceanActivator] - enocean binding has been stopped.
11:06:43.409 [DEBUG] [org.openhab.binding.enocean ] - BundleEvent STOPPED - org.openhab.binding.enocean
11:06:43.414 [DEBUG] [org.openhab.binding.enocean ] - BundleEvent STARTING - org.openhab.binding.enocean
11:06:43.416 [DEBUG] [ng.enocean.internal.EnoceanActivator] - enocean binding has been started.
11:06:43.474 [INFO ] [.enocean.internal.bus.EnoceanBinding] - Connecting to Enocean [serialPort='/dev/ttyAMA0' ].
11:06:43.476 [DEBUG] [org.openhab.binding.enocean ] - ServiceEvent REGISTERED - {org.osgi.service.event.EventHandler, org.osgi.service.cm.ManagedService}={event.topics=openhab/command/*, service.pid=org.openhab.enocean, component.name=org.openhab.binding.enocean.binding, component.id=182, service.id=312, service.bundleid=185, service.scope=bundle} - org.openhab.binding.enocean
11:06:43.478 [DEBUG] [org.openhab.binding.enocean ] - ServiceEvent REGISTERED - {org.openhab.model.item.binding.BindingConfigReader, org.openhab.binding.enocean.EnoceanBindingProvider}={component.name=org.openhab.binding.enocean.genericbindingprovider, component.id=183, service.id=310, service.bundleid=185, service.scope=bundle} - org.openhab.binding.enocean
11:06:43.485 [DEBUG] [org.openhab.binding.enocean ] - BundleEvent STARTED - org.openhab.binding.enocean
At the end, the switch is not working. Nothing shows up in the LOG, really nothing. I’m still wondering what I am supposed to do?
sorry to high-jack the post, i have the same issue, Raspberry PI3 with enocean pi setup and nothing in the log files when i press my switch.
the only thing i’m wondering is how did you got openhab to recognize ttyAMA0 ? 
i went through all 3 steps in openhabian-config regarding the serial ports but if i set enocen.cfg to /dev/ttyAMA0 i get an error in the log saying that only ttyACM0 and ttyS0 would be available.
if i set the .cfg to /dev/ttyS0 im getting the same issue. logs look ok but nothing if i press the switch.
ok figured out why it wasn’t working for me. as mentioned nothing was showing in the logs at all but i notice some strange errors directly on the console when i pressed the switch.
so i checked the /boot/cmdline.txt and by some reason there was still one entry like this: console=serial0,115200
removed the same and all is working.
hello,
I make my first steps with a Raspberry4 (4GB), enocean Pi and OH2. I installed the latest stable version of OH2 and opehhabian. Then I activated the enocean binding. In the “things” I added the enocean gateway; as path I added /dev/ttyAMA0 . In the paperUI / things next to the EnOceanGateway there is a grey field “offline - configuration_pending” . In the /var/log/openhab2/openhab.log there are messages: transceiver.EnoceanSerialTransceiver - EnOceanSerialTransceiver initialized transceiver.EnoceanSerialTransceiver - Transceiver shutdown
So far I don’t know any more what I make wrong. Because I am not the best in linux, please tell me also the directory if I should check files.
thank you for your help and best regards
Georg
Hi Georg @Georg1975,
to be able to access the /dev/ttyAMA0 device in openHAB you first have to prepare the serial ports in openhabianconfig:
You should also set up the permissions correctly, this can be done in openhabian config, too.
Best regards
Daniel
Hello,
I found out with the help of a friend of mine, that the EnoceanPi is still working with the ttyS0 Port and not with the ttyAMA0.
After the first success I restarted my OpenHAB2 project, because before I tried several thins in several config files and I did Not want to go on with this “crazy” config.
Thank you for your help
Best regards
Georg
Hi there,
i am total new in this topic. my setup:
raspberry pi with enocean pi and oh2, i did the instalation due too the oh-docu and i´ll get it running, know my problem, i am able to detect things by autodiscover, but it does not work when i switch it in thr oh-paper ui.
if i press the real button i can see something going on in the log-files.
hope anyone can help me.
Felix
Hi Daniel @fruggy83 ,
I really need your help. Will ask here because this is exactly my problem.
I am trying to set up a second Pi with Enocean Binding for my brother. The Hardware is the same as the other Raspi. (only newer Enocean Pi gpio board)
I can’t get the Bridge to work. I stuck at the
trying to get bridge base id…
I set up the serial port in openhabian-config like this:
The path is:
/dev/ttyAMA0
Code:
UID: enocean:bridge:248da985fc
label: EnOcean Gateway
thingTypeUID: enocean:bridge
configuration:
rs485BaseId: “00000000”
path: /dev/ttyAMA0
rs485: false
espVersion: ESP3
Could it be another port or what is wrong?
Log:
2021-02-26 18:44:27.059 [INFO ] [ernal.transceiver.EnOceanTransceiver] - EnOceanSerialTransceiver initialized
2021-02-26 18:44:27.049 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing ‘enocean:bridge:248da985fc’ changed from OFFLINE (CONFIGURATION_PENDING): trying to get bridge base id… to OFFLINE (CONFIGURATION_PENDING): opening serial port…
2021-02-26 18:44:27.066 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing ‘enocean:bridge:248da985fc’ changed from OFFLINE (CONFIGURATION_PENDING): opening serial port… to OFFLINE (CONFIGURATION_PENDING): starting rx thread…
2021-02-26 18:44:27.069 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing ‘enocean:bridge:248da985fc’ changed from OFFLINE (CONFIGURATION_PENDING): starting rx thread… to OFFLINE (CONFIGURATION_PENDING): trying to get bridge base id…
2021-02-26 18:45:27.293 [INFO ] [ernal.transceiver.EnOceanTransceiver] - Transceiver shutdown
Log debug/trace:
2021-02-26 23:13:40.485 [INFO ] [ernal.transceiver.EnOceanTransceiver] - EnOceanSerialTransceiver initialized
2021-02-26 23:13:40.492 [DEBUG] [nternal.handler.EnOceanBridgeHandler] - request base id
2021-02-26 23:13:40.493 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Enqueue new send request with ESP3 type COMMON_COMMAND with callback
2021-02-26 23:13:40.495 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Sending data, type COMMON_COMMAND, payload 08
2021-02-26 23:13:40.496 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Sending raw data: 5500010005700838
2021-02-26 23:13:40.520 [DEBUG] [nternal.handler.EnOceanBridgeHandler] - request version info
2021-02-26 23:13:40.523 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Enqueue new send request with ESP3 type COMMON_COMMAND with callback
2021-02-26 23:13:40.782 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Sending data, type COMMON_COMMAND, payload 03
2021-02-26 23:13:40.784 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Sending raw data: 5500010005700309
2021-02-26 23:13:40.446 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing ‘enocean:bridge:b4ae4c53c8’ changed from UNINITIALIZED (DISABLED) to INITIALIZING
2021-02-26 23:13:40.466 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing ‘enocean:bridge:b4ae4c53c8’ changed from INITIALIZING to OFFLINE (CONFIGURATION_PENDING): trying to connect to gateway…
2021-02-26 23:13:40.478 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing ‘enocean:bridge:b4ae4c53c8’ changed from OFFLINE (CONFIGURATION_PENDING): trying to connect to gateway… to OFFLINE (CONFIGURATION_PENDING): opening serial port…
2021-02-26 23:13:40.489 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing ‘enocean:bridge:b4ae4c53c8’ changed from OFFLINE (CONFIGURATION_PENDING): opening serial port… to OFFLINE (CONFIGURATION_PENDING): starting rx thread…
2021-02-26 23:13:40.493 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing ‘enocean:bridge:b4ae4c53c8’ changed from OFFLINE (CONFIGURATION_PENDING): starting rx thread… to OFFLINE (CONFIGURATION_PENDING): trying to get bridge base id…
When I exchange the Enocean board with the other one, the bridge comes online. So it must be the board itself I think. Is there a difference in supported boards?
Is there a way how I can check whether the board is working correct or not?
Thank you!
Best regards Dirk
Hi Dirk @dirkdirk
sorry for my late answer. Do you still have the problems or did you already solved them?
Best regards
Daniel
Hi @fruggy83 ,
The problem still exist. But I ordered a new usb stick and configured the system with this one.
So the gpio Board is still not working, but at the moment there is no need for it. It’s working fine with the enocean usb stick.
Hi there,
the last days I tried to get started with OpenHab as I got some new roller blinds speaking EnOcean. I’d like to control them via OpenHab so I got myself an EnOceanPi and installed OpenHab3.0.2 in a Docker Container on a Raspi 3B+.
When I first started it and after changing some settings for the serial console I was able to successfully bind to the EnOceanPi at “dev/ttyS0”. That was a few days ago. With hexdump on that serial port I was also able to see data coming in when controlling the roller blinds using a physical enocean wall sender.
Anyhow, as I did not know my EnOceanID of the roller blinds an did not want to unmount them to find it out I got myself a USB 300 as well to run it with DolphinView on my Laptop and get all the information I need to successfully bind to my roller blinds.
During that procedure it also happened that I restarted my Pi and since then OpenHab cannot find my EnOceanPi anymore. I still see data when running hexdump on /dey/ttyS0 but OpenHab says permanently that it is looking for the Bridge Base ID. The container definition has not changed. I also rebuild my OpenHab container deleting all the config to start all over from scratch but with the same result. Any idea where to look at?
As I am seeing data received at /dev/ttyS0 I still believe that the EnOceanPi module itself is properly mounted and recognized by the system. Any help would be much appreciated.
As I described I originally wanted to run that on a Pi3 in a containerized fashion. I set it up now on a Pi4B directly installed on the most recent version of Raspberry Pi OS and it works like a charm. The EnOceanPi was directly recognized on ttyS0.
I was wondering if I can change the direction of the GUI buttons. Clicking on the down button using the D2-05-00 profile (I actually would like to have the D2-05-02 EEP as well but that’s a different story) my blinds drive up and vice versa. Is that possible?
Are you sure your blinds are physically wired correct?
Pretty sure my blinds are correctly wired. I think the main problem here is, that my blinds support driving in both directions. There is a physical button to change the driving direction.
In the room where I am currently trialing this whole setup I do not really care as there is only a single blind. But for example in my living room there are 3 blinds. Two of them are mounted left-bound and one is mounted right-bound (based on where the wires came out of the wall). So here to use all 3 with a single simple rocker switch simulataneously I changed the driving direction of the left bound one.
So I would prefer to not change the driving direction of my blind but instead somehow change the icons in the software to represent the, in my special case, correct direction.
I am not sure about changing the icons, but you can create rules to achieve this.
triggers:
- id: "1"
configuration:
itemName: DummyRollershutterItem
command: UP
type: core.ItemCommandTrigger
conditions: []
actions:
- inputs: {}
id: "2"
configuration:
itemName: Blind1
command: UP
type: core.ItemCommandAction
- id: "3"
configuration:
itemName: Blind2
command: UP
type: core.ItemCommandAction
- id: "4"
configuration:
itemName: Blind3
command: DOWN
type: core.ItemCommandAction
Same for down and stop.