New openHab2 EnOcean binding

openhab2-addons
enocean
binding
Tags: #<Tag:0x00007f0148719620> #<Tag:0x00007f01487194e0> #<Tag:0x00007f0148719210>

(Daniel Weber) #382

Hi Tino (@flynux),

I really would like to support the FMS61NP as an actuator natively. However I could not found any documentation that it supports the A5-38 EEP or any other “Switching EEP”. Do you have more information about this? I just found out, that the FMS61NP sends a Rocker Switch message with its enoceanId whenever it gets switched. So you are able to use a classicDevice with just a single RockerSwitch listener. No need to define a listener for each of your physical switches which can switch your FMS61NP.

Best regards
Daniel


(Tino) #383

Same for me, I could not find any information on the EEP for the FMS61NP. It send back his enoceanId when I press the buttons on my FT55 (Rocker Switch).
I will try with the ClassicDevice again and a Listener on it.
Thanks, Tino


(Tino) #384

Hi Daniel, after upgrading to 2.5 snapshot the classic device is sending data :slight_smile:

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?

Many Thanks, Tino


(Daniel Weber) #385

Hi Tino (@flynux),

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.

Best regards
Daniel


(Tino) #386

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 :frowning:

I also tried with a thing config file but with different problems.

Thanks, Tino


(Daniel Weber) #387

Hi Tino (@flynux),

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?

Best regards
Daniel


(Tino) #388

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 :slight_smile: Light is on :slight_smile:

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.

Many Thanks again!!!
Cheers, Tino


(Tino) #389

Daniel, one more. I tried to teach-in ChannelB, but this is whithin PaperUI a String and not a Switch. So teach-in is not working.

Do I need to create a new classic device for each of the 4 buttons on FT55? Do I need to create a new Listener on each classic device?

Thanks, Tino


(Cmowgli) #390

Hi,

OK Thx.

Best regards
Carsten


(Daniel Weber) #391

Hi all,

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)

I hope I have not forget anything.

Best regards
Daniel


(Daniel Weber) #392

Hi all,

I have just updated the openocean version.

Changes:

  • D2_01 switches can be switch to ON
  • rfc2217 connections can be used
  • classicDevices can switch ON/OFF
  • 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

Best regards
Daniel


(Martin Klein) #393

Hi @fruggy83,

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.

As always greatfull for every tip you might have

Thanks

Martin


(Daniel Weber) #394

Hi Tino (@flynux),

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 :wink:

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.

Best regards
Daniel


(Martin Klein) #395

Hi @flynux,

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:

Switch   azDecke   "Arbeitszimmer"         <light>   (Office)  [ "Lighting" ]    {channel="enocean:classicDevice:01840526:virtualSwitchA", channel="enocean:classicDevice:01840526:a1"}

This lets me control my switches and get updates when they get switched externally as well.

Hope This helps

Martin


(Tino) #396

Hi Martin, Thanks for coming back. Daniel helped me a lot in the meanwhile and I got it working (not perfect yet) with his help :slight_smile:
Thanks, Tino


(Tino) #397

Hi Daniel (@fruggy83), Thanks for your explanation.

I will give it a try tomorrow.
Thanks, Tino


(Daniel Weber) #398

Hi @sepp99,

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.

I will investigate the other problem tomorrow.

Best regards
Daniel


(Markus) #399

Are there any plans to support NodOn PIR-2-1-01 Motion Sensor (EEP A5-07-03)? It shows up as genericThing after pairing.


(Sepp99) #400

Good Morning Daniel (@fruggy83),

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?

Thanks,
Christoph


(Daniel Weber) #401

Good morning Christoph (@sepp99),

strange :thinking: 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.

Best regards
Daniel