Hi Daniel, after upgrading to 2.5 snapshot the classic device is sending data
But I still struggle with all the different Ids. The physical device ID from FMS61NP is 05127F5B. I get this id back when I press the physical FT55 Rocker Switch and it is also labeled at the back of the physical device.
When I create a Classic Device, should I replace the ThingID with 05127F5B? Or where can I “link” the physical device with the classic device? Can I do everything within PaperUI or do I need to define it in config files?
great to hear, that it work now with the snapshot version.
Regarding the Ids. The ThingId does not matter any longer, you can define the ThingId like you want now. To link a Thing to the device messages, you have to use the enoceanId property now. Therefore it is possible to define more than one thing which listens to the messages of a device. Currently the only exception for this is the ClassicDevice. As this thing just combines an old virtualRockerSwitch and one or more rockerSwitches, it does not own an enoceanId. You have to use the listener channels now, to bind the classicDevice thing to a device.
Therefore your classicDevice has to look like this:
Thing classicDevice cd01 "FMS61NP " [
senderIdOffset=XXX, // set this to the right id
sendingEEPId="F6_02_01",
broadcastMessages=true,
receivingEEPId="F6_02_01",
suppressRepeating=false
] {
Type virtualSwitchA : virtualSwitchA [duration=300, switchMode="rockerSwitch"]
Type rockerswitchListenerSwitch : FMS61NPListener "FMS61NP" [enoceanId="05127F5B", channel="channelA", switchMode="rockerSwitch"]
}
As you can see, the listener gets the device Id now.
Can I do everything within PaperUI or do I need to define it in config files?
It is up to you. You can only use PaperUI or define everything in config files. However I would always recommend to use config files.
Hi Daniel, Thanks again. I defined my thing as you describes above within PaperUI.
On the Channel virtualSwitrch A and the rockerswitchListenerSwitch I created and Linked a Switch, but when I pressed the Switch Button in HABPanel I get the following output:
2018-12-19 16:10:30.553 [ome.event.ItemCommandEvent] - Item ‘FMS61NP_CD_RS_A_Upper_Left’ received command ON
2018-12-19 16:10:30.556 [nt.ItemStatePredictedEvent] - FMS61NP_CD_RS_A_Upper_Left predicted to become ON
2018-12-19 16:10:30.567 [vent.ItemStateChangedEvent] - FMS61NP_CD_RS_A_Upper_Left changed from NULL to ON
==> /var/log/openhab2/openhab.log <==
2018-12-19 16:10:30.565 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Enqueue new send request with ESP3 type RADIO_ERP1 without callback
2018-12-19 16:10:30.568 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Sending data, type RADIO_ERP1, payload F630FF8913013001FFFFFFFFFF00
2018-12-19 16:10:30.582 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received Sync Byte
2018-12-19 16:10:30.582 [TRACE] [ernal.transceiver.EnOceanTransceiver] - >> Received header, data length 1 optional length 0 packet type 2
2018-12-19 16:10:30.583 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - RESPONSE with code RET_OK payload 00 received
2018-12-19 16:10:30.583 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Response without listener
2018-12-19 16:10:30.870 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Enqueue new send request with ESP3 type RADIO_ERP1 without callback
2018-12-19 16:10:30.870 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Sending data, type RADIO_ERP1, payload F600FF8913012001FFFFFFFFFF00
2018-12-19 16:10:30.882 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received Sync Byte
2018-12-19 16:10:30.882 [TRACE] [ernal.transceiver.EnOceanTransceiver] - >> Received header, data length 1 optional length 0 packet type 2
2018-12-19 16:10:30.883 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - RESPONSE with code RET_OK payload 00 received
2018-12-19 16:10:30.883 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Response without listener
The light is not switching on
I also tried with a thing config file but with different problems.
from your log , I can see, that the PRESSED and RELEASED messages are send now. So the question is, did you already paired (teached in) your openhab thing with your FMS61NP? You are using the senderIdOffset 1 for your thing now.
Sorry if I ask it again or you already mentioned it, but did you formerly used the old openocean binding with this device or fhem?
Hi Daniel, I did not know that I had to teach-in the FMS61NP.
So I changed the switches on the FMS61NP to UT1 and LRN, so that it is in learning mode (teach-in). Then I had to press the Listener Item Switch and the virtualSwitchA button on the HABPanel. And know it is working Light is on
It wasn’t enough to press the virtualSwitchA, but I guess I can solve this with a rule.
To your other questions:
The senderIdOffset is 1, when I treid to config the thing manually in the thing file. I never tried the old openocean binding and fhem.
as promised, here is the migration guide(hints) for all the openocean users who want to change to the new official binding or the snapshot version from my repo:
Binding Id changed from openocean to enocen => replace all occurances of openocean with enocean
Thing Id has no longer to be set to the enoceanId of the device, instead each thing has a parameter enoceanId which takes this id
Enocean bridge:
combined serialbridge and tcpbridge into bridge thing
renamed repeater channel to repeaterMode
changed parameter port to path, can take rfc2217 path now for ser2net connections
renamed nextDeviceId parameter to nextSenderId
Renamed contactSwitch thing to contact
measurementSwitch
renamed eepId parameter to sendingEEPId
added receivingEEPId parameter (more than one value possible)
Renamed humidityTemperatureSensor to temperatureHumiditySensor
Replaced virtualRockerSwitch with classicDevice
combines the virtualRockerSwitch (sending part) with one or more rockerSwitches (receiving part)
does not use profiles any longer => specific channels/listeners for switch or rollershutter devices
replaced lightSwitch channel with generalSwitch
Moved rockerswitch-to-play-pause profile to esh core (system)
Teach in messages are no longer handled by things and do not mess up item states (thanks to @dominikkv)
Support for Eltako TF-FGB (or EEP A5-14-09, thanks to @dominikkv)
Although it is a 2.5.0 snapshot binding now, it can still be used withe current 2.4.0 stable openHAB version. You just have to feature:install openhab-transport-serial in the karaf console after adding the precompiled jar into your addons folder. Alternatively you can also use the marketplace to install the current version. If you want to get debug logs you have to use log:set debug org.openhab.binding.enocean
thanks for your help and also again thanks for the help with my “legacy” rocker switches,
although i have a strange Problem with the binding currently.
After a restart my Dimmer things no longer update properly.
I spend some time debugging the issue and here is what i found so far:
I have:
Fresh Install of Openhab 2.4 (openhabian, empty config)
I Create serial Bridge
I add the Dimmer
Everything working Properly, I can dimm via OpenHab and the State is properly updated when i dimm from the wall switches as well
Restart Openhab service , the below log errors appear
I can control the dimmer from OpenHab but when i control it from the wall switch the state is not updated
I remove and re-create bridge and dimmer -> Working until restart
The behaviour is obsserverd with the 2.4 release and the issue branch you provided for me.
Logs on startup:
2018-12-19 22:33:26.800 [WARN ] [erial.internal.SerialPortManagerImpl] - No SerialPortProvider found for: /dev/ttyUSB0
2018-12-19 22:33:26.808 [DEBUG] [org.openhab.binding.enocean ] - ServiceEvent REGISTERED - {org.eclipse.smarthome.config.core.status.ConfigStatusProvider}={service.id=351, service.bundleid=226, service.scope=singleton} - org.openhab.binding.enocean
==> /var/log/openhab2/events.log <==
2018-12-19 22:33:26.872 [hingStatusInfoChangedEvent] - 'enocean:centralCommand:050A7B7D' changed from UNINITIALIZED to INITIALIZING
==> /var/log/openhab2/openhab.log <==
2018-12-19 22:33:26.866 [DEBUG] [rnal.handler.EnOceanBaseThingHandler] - Initializing enocean base thing handler.
2018-12-19 22:33:26.889 [DEBUG] [rnal.handler.EnOceanBaseThingHandler] - initializeThing thing enocean:centralCommand:050A7B7D bridge status OFFLINE
2018-12-19 22:33:26.831 [DEBUG] [nternal.handler.EnOceanBridgeHandler] - error during bridge init occured
java.io.IOException: Could not find a gateway on given path '/dev/ttyUSB0', 0 ports available.
at org.openhab.binding.enocean.internal.transceiver.EnOceanSerialTransceiver.Initialize(EnOceanSerialTransceiver.java:54) ~[226:org.openhab.binding.enocean:2.4.0]
at org.openhab.binding.enocean.internal.handler.EnOceanBridgeHandler.initTransceiver(EnOceanBridgeHandler.java:197) [226:org.openhab.binding.enocean:2.4.0]
at org.openhab.binding.enocean.internal.handler.EnOceanBridgeHandler.access$2(EnOceanBridgeHandler.java:184) [226:org.openhab.binding.enocean:2.4.0]
at org.openhab.binding.enocean.internal.handler.EnOceanBridgeHandler$4.run(EnOceanBridgeHandler.java:176) [226:org.openhab.binding.enocean:2.4.0]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) [?:?]
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) [?:?]
When I push the wall switch i see:
2018-12-19 22:44:20.883 [TRACE] [ernal.transceiver.EnOceanTransceiver] - >> Received header, data length 7 optional length 7 packet type 1
2018-12-19 22:44:20.895 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - RADIO_ERP1 with RORG RPS for FEFF4BE0 payload F600FEFF4BE02001FFFFFFFF5500 received
2018-12-19 22:44:21.965 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received Sync Byte
2018-12-19 22:44:21.969 [TRACE] [ernal.transceiver.EnOceanTransceiver] - >> Received header, data length 10 optional length 7 packet type 1
2018-12-19 22:44:21.975 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - RADIO_ERP1 with RORG _4BS for 050A7B7D payload A5025C0009050A7B7D0001FFFFFFFF5000 received
2018-12-19 22:44:21.979 [DEBUG] [rnal.handler.EnOceanBaseThingHandler] - ESP Packet payload A5025C0009050A7B7D00 for 050A7B7D received
Where B7D is my Dimmer Thing So the Packet is definitely received but somehow does not update
the associated item properly anymore.
in most cases you do not need to use the ChannelB. It is mainly intended for fhem users who want to save senderIds and have already teached in their devices. An enocean gateway supports (or can control) up to 127 devices (unlimited sensors). So do not worry about your senderIds
Do I need to create a new classic device for each of the 4 buttons on FT55?
It depends. For your FMS61NP you only need one listener, as you are directly listening to your FMS61NP answers. Other devices do not send such status messages back, in this case you have to listen to the FT55 switches and add a listener for each physical rocker switch which can switch your actuator.
yes i got it working, i added a classic device with my sender ID and added a channel listening
for the return telegram and updating the state which i called a1 so my item is:
just a first quick answer regarding problem 3. It is a known bug and already solved in the snapshot version of openhab. If you want to stay at the stable version, you can use the precompiled from my repo.
PSC234 is working now with the current snapshot.
At first I tried uninstalling stable enocean addon and go with [org.openhab.binding.openocean-2.5.0-SNAPSHOT.jar] from https://github.com/fruggy83/openocean/tree/master/precompiled. But the addon did not install, even after a clear-cache. So I installed “market:binding-3984102 - 1.0”. Is there a way to determine which version is behind this number?
strange The market binding is directly linked to the master precompiled jar of my repo. So there should not be a difference. How did you downloaded the precompiled jar? You have to use the “raw” link otherwise you get a corrupted jar file.
Currently there is no easy way to determine the version of the binding through this number. I will try to add a meaningfull version number counter to the binding in the future.
funny, I ordered this NodON PIR yesterday , so the support for this device should not be far away. The big e-seller with an “A” states that it should be delivered after christmas . However if you have time for testing, I could try to implement this EEP today.
The market binding is directly linked to the master precompiled jar of my repo. So there should not be a difference. How did you downloaded the precompiled jar? You have to use the “raw” link otherwise you get a corrupted jar file.
, so the support for this device should not be far away. The big e-seller with an “A” states that it should be delivered after christmas 
. However if you have time for testing, I could try to implement this EEP today.