New openHab2 EnOcean binding

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

Hi Alexander @xxorde,

nice to hear you again.

How can I help you?

You could try to setup the current 2.5.0.1 version of my binding, you find the current release in my repo. Then define a new EnOcean gateway and ensure that you have set RS485 (you find this option under MORE). Next open the log and switch some of your actuators. I did not saw any log entries with my FAM14, so I did not try further, as the FAM14 is not intended for this use case. I had no time for deeper investigations. You have to set your FGW14 to position 6 => ESP3. position 5 => ESP2 is not supported by my binding and will never be.

If you see log entries coming up, I know that the receiving part is working and just have to optimize the sending part.

Best regards
Daniel

Hi Marting @Woogi,

I am not a maven expert, so do not take my explanatiosn for granted.
As far as I know, the dependencies (needed features) of any binding are declared directly in openhab in its feature file. So during startup of a binding openhab looks into this file and ensures that all features are loaded before the binding gets activated. The unofficial version of this binding has another maven id to distinguish both versions. Therefore openhab has no information about the needed features of this binding and I do not know how to tell openhab what is needed.

What we could try to do, I could change the maven id to the same id of the official binding and see what wil happen. Maybe I find some time in the next days to test this out. Or does anybody else have another idee?

Best regards
Daniel

HI Matthias @carmagician,

thanks for this hint. It seems that something during cleanup (dispose) is not working The handler should be disposed but still tries to trigger events. I will investigate this.

Best regards
Daniel

Same for me. Great that you are still so active on this topic!
I did not find too much time to work on my personal home automation last year, not to mention helping so many others.

My Setup already looks like this, except that I use “binding-enocean - 2.5.0.SNAPSHOT” from the snapshots. I double checked the the settings “rs485”: true and FGW14-USB set to 6.
lsof tells me openhab has opened “/dev/ttyUSB0”.

But even if I set the log level to DEBUG I can not see any messages related to button pushes or any other activity on the RS485 bus.

When I stop openhab2 I can verify with “xxd -p -u /dev/ttyUSB0” that there is activity on the RS485 bus.

Is the needed code only in your repo? Than I will check how to get and deploy it.
Anything else I should try, or may I have missed something?

Kind regards,
Alexander

Hello Daniel (@fruggy83) hello Alexander (@xxorde)

I did the same test some weeks ago when I asked my question.
Maybe I can tell you why your suggested test will not work:

The protocol in Eltakos RS485 actuator bus is not based on enoceans ESP3 protocol.
They are using the raw enocean radio protocol (ERP) to communicate between FGW14 and the actuators.

This ERP protocol you can see on the FGW14 and also when you connect to FAM14 USB interface.
Using WinEtel (Dolphin Software) will give you a good starting point to see what is going on at this interface.
You can find this software at Eltako download page.

Some additional work on the binding is needed to support these interfaces:

  1. Sending:
    The binding has to send the ERP packet before encapsulating it in the ESP3 packet.
    Some modifications are required (preamble, checksum…) to fit ERP.
    And you will not get an answer as you know it from you ESP3 gateway.

  2. Receiving:
    As I described we are a level below ESP3 - so the binding has to listen to ERP directly.
    Afterwords the process is the same, because the content is not different from what is encapsulated in the ESP3 telegram you receive from the currently supported gateways.

The documentation for ERP on enoceans web site is not complete. Some additional parts that are visible on the radio is missing. (Sync bytes, lenghth and telegram type)
You can see the content with WinEtel and there are some enocean documents also that are describing this protocol. Let me know if you need more details…
With WinEtel it is also possible to send messages (4BS for example) to the eltako actuator bus for testing purposes…

I will also try to support you to make this functionality available.

Best regards,
Rainer

Hi Rainer @jahnra,

The protocol in Eltakos RS485 actuator bus is not based on enoceans ESP3 protocol.

This is the needed information. The docs state that just ESP3 supports 57600 baud (Table 1 on page 9). As FAM14 and FGW14 also support this baud I thought that they would also use ESP3. However this is not the case. Both gateways use a TCM120 chip which just supports ESP2. So I guess I also have to implement ESP2 support to support wired connections :wink:

Just for clarification:

  • ERP => EnOcean RADIO Protocol used on the radio channel
  • ESP => EnOcean SERIAL Protocol used in the wired channel

So an USB300/EnOceanPi gateway and a FAM14/FGW14 gateway use the same protocol ESP in different versions. However the content of an ESP3 and an ESP2 packet is the same, it is just the packaging. I will try to implement a first draft for an ESP2 support this weekend. Thanks a lot Rainer for directing me in the right way.

Best regards
Daniel

1 Like

Hello Daniel (@fruggy83)

I’m happy to provide something helpful, even when some parts of my description are wrong:-)

Yes, this is clear, but my mistake is coming from the other side:
I never thought about, that Elatko is using ESP2 in their own bus because of the wrong baud rate.
Because of this, I never had a detailed look to ESP2 and thought this must be raw radio information…
But I think you are right.

BTW: The FGW14 is not using any TCMxx chip. There is only a PIC inside to switch the baud rate and do some filtering. It also hides all the remote management stuff between FAM14 and the slaves from the outside.

I’m looking forward to do the first tests with this implementation.

Thanks again for your work!!

Best regards,
Rainer

Hi @jahnra and @xxorde,

just finished a first draft for ESP2 support. You can find the current implementation in my repo issue13_ESP2 branch. Receiving ESP2 messages is already working and tested, converting them into ESP3 messages so that they can be used by my EEP classes needs to be tested (@jahnra you have got an email, @xxorde if you want, just send me a pm and I can send you a compiled version too). Maybe I can finish the work next weekend or in two.

Best regards
Daniel

Hi Daniel (@fruggy83),

unfortunately I did not get the openocean binding on a Windows openHab installation running. I will be happy to test your PushButton fix when it goes into a dev version of the enocean binding. But I hesitate to go back to openocean on my Raspberry because the last time I did not manage to switch to enocean without reinstalling openHab.

Best regards,
Thorsten

Hi Daniel (@fruggy83 ),

I have a question regarding genericThings. I have a window contact from Eltako this one. The EEP is not supported directly by your binding. The EEP is A5-14-0A. So I use this:

Bridge enocean:bridge:020b40e9 “EnOcean Gateway” [ path="/dev/ttyAMA0" ] {
Thing genericThing Win_Con_WoZi “Kontakt Terrassentür (EEP A5_14_0A)” @ “Wohnzimmer” [
enoceanId=“05114172”,
sendingEEPId=“A5_FF_FF”,
broadcastMessages=false,
receivingEEPId=“A5_FF_FF”,
suppressRepeating=false]
}
to create my Things.

The Bridge and the Sensor appears as online in PaperUI and in the debug Log I can see the messages that were received. But unfornatly I can not transform it to an OpenHab Status.

Here is an Log extract:

Received header, data length 10 optional length 7 packet type 1

2019-02-10 12:43:10.615 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - RADIO_ERP1 with RORG _4BS for 05114172 payload A593000008051141720000FFFFFFFF4100 received

2019-02-10 12:43:10.619 [DEBUG] [rnal.handler.EnOceanBaseThingHandler] - ESP Packet payload A5930000080511417200 for 05114172 received

2019-02-10 12:43:19.520 [WARN ] [rm.AbstractFileTransformationService] - Could not transform ‘-’ with the file ‘enocean.map’ : Target value not found in map for ‘-’

“-” is not the expected value for me. The Status is given with the “08” in the payload above. So how can I access these bytes to do a transformation?

The Data is the same like this one from @shotte

Continuing the discussion from New openHab2 EnOcean binding:

Hi Daniel (@fruggy83)

I did some additional testing. I installed the actuall snapshot 2.5.0.2 and declard my thing as an contact with the EEPId=A5_14_01_ELTAKO. I get the Voltage of the Battery and the receiveStatus (RSSI) but not the Status OPEN/CLOSE. Will you add this channel? By the way I think “batteryStorage” and “batteryVoltage” are reversed.

Hi @AlexKid,

what do you mean with ‘reversed’?

EEP A5-14-01 does not carry any information about the open/closed state. You have to combine this with a apropriate EEP like this:

Thing contact 11223344 "Fenster" @ "Schlafzimmer" [ enoceanId="11223344", receivingEEPId="D5_00_01,A5_14_01_ELTAKO" ]

And, be warned, batteryStorage is renamed to energyStorage :slight_smile:

Cheers
Dominik

Hi @dominikkv

blame on me. I linked to the post from @shotte and didn’t use that EEP. I had a look at github and saw that you already implemented A5_14_09. The Data is the same like A5_14_0A. So I get all my information that I need from my contact.

by the way

is not the right syntax. It have to look like this:
receivingEEPId=“D5_00_01”,“A5_14_01_ELTAKO”

1 Like

I have OpenHAB installed via package repository. Tried on raspberry PI3B and linux PC- stable 2.4 and beta version. Using PaperUI to install enocean binding, as it is the openenocean now.
I have two USB300 sticks and none of them are auto discovered.
On manual add I get following errors:
20:05:37.462 [DEBUG] [internal.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) ~[206:org.openhab.binding.enocean:2.4.0]

TTY info:
[ 865.902036] usb 1-1.1.3: FTDI USB Serial Device converter now attached to ttyUSB0

USB ownership:
root@raspberrypi:/# ls -al /dev/ttyUSB0
crw-rw---- 1 root dialout 188, 0 veebr 20 19:39 /dev/ttyUSB0

[Edit] It was related to ownership. Adding dialout to openhab user fixed the issue
sudo usermod -a -G dialout openhab

1 Like