I just changed the rxtx lib to the one used by your other bindings. Furthermore I also implemented the A5-02 EEP group. I would be glad if you could test these changes.
I have tested the new version of this binding with USB300 and enocean pi on my PI3. Everything seems to work usually.
2018-02-26 22:18:00.913 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception
java.lang.NullPointerException: null
at org.openhab.binding.openocean.internal.transceiver.OpenOceanTransceiver.receivePackets(OpenOceanTransceiver.java:131) [200:org.openhab.binding.openocean:2.3.0.201802250921]
at org.openhab.binding.openocean.internal.transceiver.OpenOceanTransceiver.access$0(OpenOceanTransceiver.java:116) [200:org.openhab.binding.openocean:2.3.0.201802250921]
at org.openhab.binding.openocean.internal.transceiver.OpenOceanTransceiver$1.run(OpenOceanTransceiver.java:88) [200:org.openhab.binding.openocean:2.3.0.201802250921]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
at java.lang.Thread.run(Thread.java:748) [?:?]
really strange. I am just checking if I have to receive enocean messages any longer on this line. Do you still know, what you have done just before this error happend? Thanks a lot for this error log, I will see what I can do to make this binding more stable.
Today I deleted tmp and cache but it happened again. After a second restart it works again, without a problem. Iâwill observe it within the next day.
I am sorry for these problems. I improved the startup and shutdown of the binding in its last version. So you should not get these problems any longer during a restart. I even implemented a reconnection to the serial port after one minute, if something goes wrong.
Furthermore sending a large amount of messages (close all rollershutters during sunset) is also more reliable now.
Please empty your cache folder before you use the new version of the binding.
I released a big update for this binding. The main feature is profile support. Rocker switches use the system:rawrocker channeltype now, to use the system profiles for On/Off and dimmer items. So you do not need to define rules anymore to switch items on or off. Instead link your rocker switches directly to the corresponding items. Furthermore I implemented a Play/Pause profile, to control (Play/Pause and volume up/down) your Sonos devices with a rocker switch.
However to be able to use this feature you have to redefine your rocker switches. The rocker switches still emit trigger events (DIR1/2_PRESSED/RELEASED), so you can still use them in rules for advanced features. You just have to update the events in your already defined rules (@peter.boehm, @Pezzi42).
To be able to use your rocker switches with profiles in the right way, I seperated the F6_02_01/02 EEP in two different EEPs. F6_02_01 emits DIR1 on the upper rocker, F6_02_01 emits DIR2 on the upper rocker. So maybe you have to switch the EEP of your rocker switches.
If you own an enocean device whose EEP is not implemented yet, you can now define a GenericThing. These things can receive and send any enocean message. However the conversion of these messages into openhab state updates or the conversion from openhab commands has to be defined with transformation functions by yourself. A mapping example can be found on github.
first let me thank you for your awesome work.
Yesterday i installed your binding. My cul works fine and the rockers are getting discovers. But i can´t get my actuators to work. My actuators are pretty old: Opus GN-A-R12V-SR-4 (idetical to Eltako FSA12). So i tried the generic option. But here is my problem: I have no idea which eep i should use with my generic switch, what ON / OFF Code i have to use in my mapping file and how to teach-in my virtual switch. I tried so many things, but i can´t solve it by myself. I hope you can help me.
thanks a lot
I read the specifications of your Opus actuator. As this actuator (and all other actuators of the 12 series of eltako) is only a unidirectional actuator (it does not send a message back after switching its relay) you can use a rocker switch to control your actuators. Just follow these steps:
Add a F6-02 rocker switch
Thing Id does not matter, EEP = F6-02-01, sender Id must be set by you (*)
Link its actuator channels to a switch item
Set your actuator into learn mode as explained here. âUse the lower rotary switch, select the
required channel 1 to 4. Set the middle rotary switch to LRNâ
Activate/Switch your openhab item. Your item should now be paired with your actuator. âAfter teaching-in, set the middle and lower rotary switches to AUTOâ
A drawback of your unidirectional actuators is, that if you switch your actuator with a physical rocker switch, the state of your openhab item will get out of sync with the current actuator switch. To solve this problem you could add another rocker switch (sensor), which syncs the item state with a rule. You have to use postUpdate in your rule to just update the state of the item and not send a command.
I hope this works for you setup. If you need more help or if you have more questions, feel free to ask any question.
Best regards
Daniel
(*) sender Ids must be unique! As each rocker switch has two channels A/B, you can control two actuator channels with one rocker switch. You can also teach in one rocker switch into more than one actuator channel to control them together.
thank you so much for your fast and very detailed answer.
I tried to link it to the channel, but the â+â does not work in this case. Here is a screenshot: https://i.imgur.com/x53e9HP.png. Nothing happens, when i click on it. No idea why.
thats interessting. I also observed such a behaviour for rocker switches on my productive system. However as I can link my rockers in my development system without any problems and I use rocker switches just as sensors, I did not analysed it further. Maybe I find time today to look at it.
Meanwhile you could activate the simple mode for item linking in system configuration. Do the item linking and deactivate it afterwards.The drawback of this solution is, that you cannot define a nice name for your iitem. Instead you get something like this âopenocean_rockerSwitch_b006d36e_generalSwitchA.â.
Just another few words about the teach in process:
After activating the learn in mode of your actuator pay attention that no other enocean message is send. Otherwise this device will get paired.
If your actuator switches on when you switch off your item, you can change the EEP of your rocker switch to F6-02-02. It sends the same messages as F6-02-01 but with inverted buttons (Up => On vs Down => On)
thank you. The item-linking did now work But sadly the teach-in did not.
Here are screenshots from my settings + debug-log: https://imgur.com/a/G2CoI
Everything should work fine, but the LRN light on the actuator just keeps on blinking, when i flip the virtual switch.
A few years back i tried myself on fhem. You needed to send a teach command in order to teach-in the virtual rocker. Just flipping it on, did nothing like in this case. Could this be the problem ?
when fhem needs to send an explicit teach in command, the actuator listens to other EEPs, too. A rocker switch does know something like a teach in command. It can only send On/Off. Some actuator reduce their receiving power (Empfangsstärke) during a learn in to ignore other weakly commands. So you could try to position your CUL nearer to your actuator.
However mentioning fhem was a good point. I found a discussion on their forum in which they describe the commands for a FSA12. So you could also try the follwing:
Install the new binding version I added a genericTeachIn channel
If not already done, install the mapping transformation to your addons
Add a new generic thing, thing Id does not matter, use the sender id of your rocker switch after deleting it, EEP: Generic 4BS
Edit the switch and teach in channel, set type of transformation = âMAPâ, function = filename of your mapping file eg âswitch.mapâ
Link switch and teach in channel to items, you can keep the advanced linking mode here
create a mapping file in your transformation folder with the following content
thank you so much for your constant efforts. Sadly, it still does not work. No outgoing signal gets registered by the actuator
Here is exactly what i did:
Delete old âorg.openhab.binding.openocean-2.3.0-SNAPSHOT.jarâ from â/usr/share/openhab2/addonsâ and replaced it with new one.
Reboot openhabianpi
Delete all old ITEMS and THINGS
Create new OpenOcean Generic-Thing
Leave the default Thing-ID, put in Sender-ID â2â, change EEP to â4BSâ
Create switch.map file and put it in to â/etc/openhab2/transformâ. (Map Transformation Addon was installed)
Edit the switch and teach in channel, set type of transformation = âMAPâ, function = âswitch.mapâ
Link switch and teach in channel to items
I tried:
genericTeachInCMD|ON=E047FF80
and
genericTeachInCMD|ON=01000000
Both did not work.
I cleared the actuator - did not help. When i click on the now unteached wall-rocker, the upper LED on the actuator blinks. So it registers that there is a viable signal. When i switch the virtual openhab one, there is no blinking.
I also put my cul ~5cm next to the actuator. Nothing
Maybe we can do the following: As I told you, rocker switches do not know teach in telegrams. So when you click on your unteached wall-rocker, it sends a normal telegram. If you set the log level of the binding to trace, you can see every enocean telegram which is send by your devices. I would like to know what your wall-rocker sends and try to imitate this telegram.
Could you please perform these steps?
thanks a lot. I think my release messages are wrong. If you compare these messages with your first log, you will see that there is no f600 message. Give me a second to fix this.
I updated the binding. Now I get the same f670senderid30 and f600senderid20 messages with EEP f6-02-01 for channel B⌠So add again a rocker switch and try to teach this in your actuator.