New openHab2 EnOcean binding

Hi Daniel, (@fruggy83)

thanks for the hint. I’ll wait for a new build in which the bug will be fixed.
Can you explain why I had to teach in the actors again and why the BaseID seems to have changed? I also had to again teach in my Eltako switch.

Just for my understanding for upcoming upgrades of OH2.

Cheers,
Jens

Hi Jens @bruxi

the BaseId is retrieved from gateway. The binding allows to chnage this with a special gateway channel. However you can do this just 10 times. The remaining changes can be seen in the gateway properties. So you could check if this number is < 10. In this case someone changed the BaseId of the gateway. However I do not know why this happened. I am also not aware that this happend to someone else.

If the number is still 10, you have maybe just use another gateway.

Best regards
Daniel

Hi Daniel @fruggy83

that’s the point. My intention was not to change anything. Just to upgrade the binding and the item definition with the new channel notation. But that didn’t work, I had to teach in the actors again.
But it seemed that the gateway changed its ID!?

Best regards,
Jens

Hi @Zeraphim,

I just analysed the ESH serial API code.The function SerialPortManagerImpl.getIdentifier(Sting name) posts the warning we see in your log. This warning is postes when the manager does not find a SerialPortProvider which can handle the given path. I do not think that this is a problem of the binding. I am not sure why the SerialPortManagerImpl cannot find the RFC2217 Provider. I just debugged the connection with your path and could get successfully the provider. Maybe you ask your question in a more generic section or create an issue in ESH repo.

Sorry that I cannot not help you.

Best regards
Daniel

Hi Jens @bruxi

did you check the remaining baseid changes? You find it in the gateway properties.

baseid

Hi Daniel @fruggy83

I didn’t change anything. I just updated from OH2 2.4 to 2.5 snapshot and recognized that the item definition changed from openocean: to enocean:.

But after only updating items definitions the switch items didn’t work anymore. Here’s the Gateway thing that I had before:

Everything seems to be the same still. But why did I have to teach in the switches again?

Best regards,
Jens

Hi Jens @bruxi,

as you can see the BaseId did not changed. Still 10 write cycles remaining.

I didn’t change anything. I just updated from OH2 2.4 to 2.5 snapshot and recognized that the item definition changed from openocean: to enocean

You also have to change the thing definition. So maybe the senderIdOffset of your things is not valid anymore. Could you please post the thing definition of one device which has to teached in again.

Best regards
Daniel

Hi @fruggy83,

again, thank you for the effort. I was thinking the same. Something goes wrong in the SerialPortProvider. I would like to check a few things myself, could you therefore share a few information?
Could you share the version output of all your SerialPortProvider featureres for reference? Also the version of of ser2net you are using could be interesting. Also the config string of it.

I would try to add it this information to the Wiki as it is really hard to find on how to configure this remote serial connection.

Thx
/Zeraphim

Daniel (@fruggy83), many many Thanks for the deep insight!!! I will do some tests on the weekend.
Thanks, Tino

I recently updated my OH 2.3 with the 2.4-SNAPSHOT of the openocean binding to the 2.4 stable release. With the documentation provided, getting my enocean devices working again was quite easy.
@fruggy83 Again kudos for the excelent work. Especially the combination of profiles of OH 2.4 it is very awesome to see I can ‘dim’ my hue bulb using an enocean rocker switch.

I however still have 2 issues:

  1. The teach in (VLD) with m PEHA worked ok, but communication via profile D2-01-08 is not working as expected. I did not read the complete discussion on this topic, but it might be a solved bug. For know, the A5 profiles at work.
  2. I do have one issue regarding the reliability of the enocean communication. I’m not sure what the cause is, but my actuator is not switching with 100% reliability.
    Here is a part of the logs:
    2019-01-16 21:04:15.477 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Enqueue new send request with ESP3 type RADIO_ERP1 without callback
    2019-01-16 21:04:15.485 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Sending data, type RADIO_ERP1, payload A501000009FFA7EF840001FFD3E302FF00
    2019-01-16 21:04:15.525 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - RESPONSE with code RET_OK payload 00 received
    2019-01-16 21:04:15.802 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - RADIO_ERP1 with RORG VLD for FFD3E303 payload D20461E4FFD3E3030001FFFFFFFF3700 received
    2019-01-16 21:04:15.817 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - RADIO_ERP1 with RORG _4BS for FFD3E302 payload A5FF001749FFD3E3020001FFFFFFFF3600 received
    2019-01-16 21:04:15.820 [DEBUG] [rnal.handler.EnOceanBaseThingHandler] - ESP Packet payload A5FF001749FFD3E30200 for FFD3E302 received
    2019-01-16 21:04:34.144 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Enqueue new send request with ESP3 type RADIO_ERP1 without callback
    2019-01-16 21:04:34.149 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Sending data, type RADIO_ERP1, payload A501000008FFA7EF840001FFD3E302FF00
    2019-01-16 21:04:34.168 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - RESPONSE with code RET_OK payload 00 received
    2019-01-16 21:04:34.456 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - RADIO_ERP1 with RORG VLD for FFD3E303 payload D2046180FFD3E3030001FFFFFFFF3700 received
    2019-01-16 21:04:34.471 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - RADIO_ERP1 with RORG _4BS for FFD3E302 payload A500001748FFD3E3020001FFFFFFFF3600 received
    2019-01-16 21:04:34.473 [DEBUG] [rnal.handler.EnOceanBaseThingHandler] - ESP Packet payload A500001748FFD3E30200 for FFD3E302 received
    2019-01-16 21:04:49.270 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Enqueue new send request with ESP3 type RADIO_ERP1 without callback
    2019-01-16 21:04:49.275 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Sending data, type RADIO_ERP1, payload A501000009FFA7EF840001FFD3E302FF00
    2019-01-16 21:04:49.287 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - RESPONSE with code RET_OK payload 00 received
    2019-01-16 21:05:04.480 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Enqueue new send request with ESP3 type RADIO_ERP1 without callback
    2019-01-16 21:05:04.487 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Sending data, type RADIO_ERP1, payload A501000008FFA7EF840001FFD3E302FF00
    2019-01-16 21:05:04.508 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - RESPONSE with code RET_OK payload 00 received
    2019-01-16 21:05:04.712 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - RADIO_ERP1 with RORG VLD for FFD3E303 payload D2046180FFD3E3030001FFFFFFFF3700 received
    2019-01-16 21:05:04.718 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - RADIO_ERP1 with RORG _4BS for FFD3E302 payload A500001748FFD3E3020001FFFFFFFF3600 received
    2019-01-16 21:05:04.722 [DEBUG] [rnal.handler.EnOceanBaseThingHandler] - ESP Packet payload A500001748FFD3E30200 for FFD3E302 received
    2019-01-16 21:05:12.564 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Enqueue new send request with ESP3 type RADIO_ERP1 without callback
    2019-01-16 21:05:12.569 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Sending data, type RADIO_ERP1, payload A501000009FFA7EF840001FFD3E302FF00
    2019-01-16 21:05:12.592 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - RESPONSE with code RET_OK payload 00 received
    2019-01-16 21:05:15.563 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Enqueue new send request with ESP3 type RADIO_ERP1 without callback
    2019-01-16 21:05:15.566 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Sending data, type RADIO_ERP1, payload A501000008FFA7EF840001FFD3E302FF00
    2019-01-16 21:05:15.593 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - RESPONSE with code RET_OK payload 00 received
    2019-01-16 21:05:15.887 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - RADIO_ERP1 with RORG VLD for FFD3E303 payload D2046180FFD3E3030001FFFFFFFF3C00 received
    2019-01-16 21:05:15.902 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - RADIO_ERP1 with RORG _4BS for FFD3E302 payload A500001748FFD3E3020001FFFFFFFF3700 received
    2019-01-16 21:05:15.910 [DEBUG] [rnal.handler.EnOceanBaseThingHandler] - ESP Packet payload A500001748FFD3E30200 for FFD3E302 received
    2019-01-16 21:05:16.515 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Enqueue new send request with ESP3 type RADIO_ERP1 without callback
    2019-01-16 21:05:16.520 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Sending data, type RADIO_ERP1, payload A501000009FFA7EF840001FFD3E302FF00
    2019-01-16 21:05:16.544 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - RESPONSE with code RET_OK payload 00 received
    2019-01-16 21:05:16.844 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - RADIO_ERP1 with RORG VLD for FFD3E303 payload D20461E4FFD3E3030001FFFFFFFF3900 received
    2019-01-16 21:05:16.859 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - RADIO_ERP1 with RORG _4BS for FFD3E302 payload A5FF001749FFD3E3020001FFFFFFFF3600 received
    2019-01-16 21:05:16.861 [DEBUG] [rnal.handler.EnOceanBaseThingHandler] - ESP Packet payload A5FF001749FFD3E30200 for FFD3E302 received
    2019-01-16 21:05:17.067 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Enqueue new send request with ESP3 type RADIO_ERP1 without callback
    2019-01-16 21:05:17.070 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Sending data, type RADIO_ERP1, payload A501000008FFA7EF840001FFD3E302FF00
    2019-01-16 21:05:17.097 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - RESPONSE with code RET_OK payload 00 received
    2019-01-16 21:05:17.389 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - RADIO_ERP1 with RORG VLD for FFD3E303 payload D2046180FFD3E3030001FFFFFFFF3700 received
    2019-01-16 21:05:17.405 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - RADIO_ERP1 with RORG _4BS for FFD3E302 payload A500001748FFD3E3020001FFFFFFFF3900 received
    2019-01-16 21:05:17.408 [DEBUG] [rnal.handler.EnOceanBaseThingHandler] - ESP Packet payload A500001748FFD3E30200 for FFD3E302 received
    2019-01-16 21:05:19.354 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Enqueue new send request with ESP3 type RADIO_ERP1 without callback
    2019-01-16 21:05:19.359 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Sending data, type RADIO_ERP1, payload A501000009FFA7EF840001FFD3E302FF00
    2019-01-16 21:05:19.385 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - RESPONSE with code RET_OK payload 00 received
    2019-01-16 21:05:19.673 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - RADIO_ERP1 with RORG VLD for FFD3E303 payload D20461E4FFD3E3030001FFFFFFFF3600 received
    2019-01-16 21:05:19.689 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - RADIO_ERP1 with RORG _4BS for FFD3E302 payload A5FF001749FFD3E3020001FFFFFFFF3600 received
    2019-01-16 21:05:19.691 [DEBUG] [rnal.handler.EnOceanBaseThingHandler] - ESP Packet payload A5FF001749FFD3E30200 for FFD3E302 received
    2019-01-16 21:05:26.098 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Enqueue new send request with ESP3 type RADIO_ERP1 without callback
    2019-01-16 21:05:26.108 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Sending data, type RADIO_ERP1, payload A501000008FFA7EF840001FFD3E302FF00
    2019-01-16 21:05:26.130 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - RESPONSE with code RET_OK payload 00 received

What you see happening is that you see the switch commands is sent and RET_OK is returned. (I’m not sure what this ack means btw). Sometimes, the actuactor responds with a new state, i.e. the package is received and processed by the actuator.
However, this is not always the case (also shown in the logs by the missing state change being reported by the actuator). Possible cause can ofcourse be that the packet could not reach the actuator. However, the distance is more or less one meter and a rocker switched attached to my wall with approximately the same distance is 100% reliable. Anybody any clue what this can be? Or how I can debug this further?

Lastly, could it be an option the binding solves the lack of ‘ack’. In Z-Wave, a command is acked by a node. I’m not familiar with enocean, but I guess this kind of ack is not build in in the protocol. However, in the things that are defined in OH (by providing/teaching the used profiles) we know what kind of response should come from the actuator. So if a switch-on is sent, we could build in a retry-policy until the switch is confirmed by the actuator. @fruggy83: how difficult would this be?

Hi Vincent @vince2k,

I see what you mean. However I have not seen this in my setup, and I am sending an UP/DOWN message to each of my roller shutters on my first floor (9 roller shutters). As EnOcean implemented a low energy protocol, acks are not send by default. Acks are just possible between sensors and a controler if the sensor supports the Smart Ack protocol. However I have not found such a sensor yet.

Your suggested retry-policy workaround should not be so complicated to implement. I will try to implement this on this weekend.

Best regards
Daniel

Hi @Zeraphim,

as I updated the binding version on my productive system, I saw the same messages in my log. SerialProvider for dev/ttyAMA0 is missing. However after some seconds the gateway started as usual.

requested information

  • ser2net version 2.10.1
  • config string: 3335:telnet:600:/dev/ttyUSB0:57600 8DATABITS NONE 1STOPBIT remctl
  • esh-io-transport-serial: 0.10.0.oh240
  • esh-io-transport-serial-javacomm: 0.10.0.oh240
  • esh-io-transport-serial-rxtx: 0.10.0.oh240
  • esh-io-transport-serial-rfc2217: 0.10.0.oh240
  • openhab-transport-serial: 2.4.0

I will also investigate this issue further.

Best regards
Daniel

Hi all,

I just want to inform you that I have changed some things in my repo. From now on I will publish from time to time a new release in my repo. Therefore the precomplied folder is no more longer necessary. A link to the latest release can be found on top of the readme. Furthermore I have added a version number to my binding. So you can now identify the biinding version a lot easier.

The new release contains the following new features (full changelog can be found in my repo):

  • Added ramping time parameter for dimmers (thanks to @dominikkv)
  • Improved FSB14 message handling, position is determined a lot more exactly (@wiss911). Do not use autoupdate for rollershutter items otherwise the position cannot be calculated correct (see also next point).
  • I am no longer storing the item states in my binding, instead I determine it from the items directly. Therefore you can persist the states now a lot more easier. Last state of ToggleButtons can be recovered after openhab restart now (@flynux this should help you with your Toggles).

If you like my binding you can spend me a coffe :coffee: now :wink:

Best regards
Daniel

2 Likes

Hi Frank (@fnu),

thank for the hint. I already tried this last week and have redone it now with the Yamaha binding but unfortunately without success (on Windows). I will see if I find a solution.

Thanks,
Thorsten

Daniel (@fruggy83), great stuff, many Thanks!!!

Hi @fruggy83
thanks for the information. Both, the shared versions and the info that you see the same output in your system. This sounds a bit like a timing issue. The serial transport is opened before it has all protocols in it’s list. But that would only cause a problem on the fist try. It looks like your binding tries it several times and on the second try it is working.

Therefore we could come to the conclusion that in the current state this warning can always happen during start. But it does only postpone the gateway init. Which could mean that there is a different problem on my system.

What I did not mention yet: After some time the Enocean gateway turns green in the UI. Afterwards it is either working or not. The binding does not retry to connect to the receiver after this. So it looks like the binding thinks everything is allright although it isn’t.

I spend several hours this weekend to try different things and read myself through the source code of the serial transport but did not come to any solution. Maybe I have to setup a debug system so I can attach to the process.

/Zeraphim

Try it with Z-Wave/Zigbee Binding. That worked for me yesterday. Even if i´m not on windows, same problem arised for me suddenly yesterday, when i removed the binding from snapshot version and used the one from Github.

Hello.

When I use my EnOcean-switches I get some errors in the log-file. Deleting and rebinding the switches did not work.
When I take a completely new switch, I don‘t get these errors unless binding them to some actions.

[WARN ] 
[.core.thing.binding.BaseThingHandler] 
Handler EnOceanBaseSensorHandler of thing enocean:rockerSwitch:FT2PVJS5:FEF73B6E tried triggering channel rockerswitchA although the handler was already disposed.

[vent.ChannelTriggeredEvent] enocean:rockerSwitch:FT2PVJS5:FEF73B6E:rockerswitchA triggered DIR2_PRESSED

[vent.ItemStateChangedEvent] enocean_rockerSwitch_FT2PVJS5_FEF73B6E_receivingState changed from Rssi 77, repeated 0 to Rssi 64, repeated 0

[WARN ] 
[.core.thing.binding.BaseThingHandler]
Handler EnOceanBaseSensorHandler of thing enocean:rockerSwitch:FT2PVJS5:FEF73B6E tried triggering channel rockerswitchA although the handler was already disposed.

I was having the same issue after updaten to 2.5.0.2 jar file. Thanks to Frank (@fnu) saved my night :slight_smile:

Maybee it is possible to integrate this installation somehow into the binding/jar Daniel@fruggy83? Would that be possible? Else it is required each time after clearing cache and changing to latest build to install the feature. Without cache clearing issue does not exists.

Kindly,
Woogi

Hi Daniel (@fruggy83),

I saw Rainers (@jahnra) question and I am interested as well.

You told me some time ago that you are interested in supporting the FGW14-USB and that I should post here if I want to support you (Can i use eltako enocean actors?) .

How can I help you? (Without getting deeply into Java first :wink:

Thanks for all your work so far,
Alexander