Enocean Binding: Cannot instantiate EEP F6-02-01: null

Add-ons Bindings
1

Hello together,

since change from 3.2 → 3.3 there seems to be a bug in the support of the Eltako TF-FKE.
The EnOcean Transceiver throws an exception and there is no update of the item.

Thing is defined as (inside the corresponding enoecan bridge):

Thing contact st_EG_K_Fenster "st-EG-K-Fenster" @ "EG Kueche" [ enoceanId="FEED66BD", receivingEEPId="F6_10_00_EltakoFPE" ] //F6_10_00_EltakoFPE

Debug log:

2022-11-19 23:35:31.731 [DEBUG] [nternal.messages.ESP2PacketConverter] - Received ESP2 radio telegram: 0B05F0000000FEED66BD20

2022-11-19 23:35:31.733 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Converted to: RADIO_ERP1 with RORG RPS for FEED66BD

2022-11-19 23:35:31.734 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - RADIO_ERP1 with RORG RPS for FEED66BD payload F6F0FEED66BD20 received

2022-11-19 23:35:31.736 [ERROR] [ding.enocean.internal.eep.EEPFactory] - Cannot instantiate EEP F6-02-01: null

2022-11-19 23:35:31.737 [ERROR] [ernal.transceiver.EnOceanTransceiver] - Exception in informListeners

java.lang.IllegalArgumentException: java.lang.reflect.InvocationTargetException

	at org.openhab.binding.enocean.internal.eep.EEPFactory.buildEEP(EEPFactory.java:75) ~[bundleFile:?]

	at org.openhab.binding.enocean.internal.handler.EnOceanBaseSensorHandler.packetReceived(EnOceanBaseSensorHandler.java:150) ~[bundleFile:?]

	at org.openhab.binding.enocean.internal.transceiver.EnOceanTransceiver.lambda$0(EnOceanTransceiver.java:309) ~[bundleFile:?]

	at java.lang.Iterable.forEach(Iterable.java:75) ~[?:?]

	at org.openhab.binding.enocean.internal.transceiver.EnOceanTransceiver.informListeners(EnOceanTransceiver.java:309) [bundleFile:?]

	at org.openhab.binding.enocean.internal.transceiver.EnOceanESP2Transceiver.processMessage(EnOceanESP2Transceiver.java:112) [bundleFile:?]

	at org.openhab.binding.enocean.internal.transceiver.EnOceanTransceiver.receivePackets(EnOceanTransceiver.java:262) [bundleFile:?]

	at org.openhab.binding.enocean.internal.transceiver.EnOceanTransceiver$1.run(EnOceanTransceiver.java:197) [bundleFile:?]

	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) [?:?]

	at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]

	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304) [?:?]

	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]

	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]

	at java.lang.Thread.run(Thread.java:829) [?:?]

Caused by: java.lang.reflect.InvocationTargetException

	at jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) ~[?:?]

	at jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) ~[?:?]

	at jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) ~[?:?]

	at java.lang.reflect.Constructor.newInstance(Constructor.java:490) ~[?:?]

	at org.openhab.binding.enocean.internal.eep.EEPFactory.buildEEP(EEPFactory.java:67) ~[bundleFile:?]

	... 13 more

Caused by: java.lang.IllegalArgumentException

	at org.openhab.binding.enocean.internal.eep.EEP.setData(EEP.java:134) ~[bundleFile:?]

	at org.openhab.binding.enocean.internal.eep.EEP.<init>(EEP.java:70) ~[bundleFile:?]

	at org.openhab.binding.enocean.internal.eep.Base._RPSMessage.<init>(_RPSMessage.java:35) ~[bundleFile:?]

	at org.openhab.binding.enocean.internal.eep.F6_02.F6_02.<init>(F6_02.java:52) ~[bundleFile:?]

	at org.openhab.binding.enocean.internal.eep.F6_02.F6_02_01.<init>(F6_02_01.java:41) ~[bundleFile:?]

	at jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) ~[?:?]

	at jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) ~[?:?]

	at jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) ~[?:?]

	at java.lang.reflect.Constructor.newInstance(Constructor.java:490) ~[?:?]

	at org.openhab.binding.enocean.internal.eep.EEPFactory.buildEEP(EEPFactory.java:67) ~[bundleFile:?]

	... 13 more

Is there anyone who could support?
Anyone using the TF-FKE sucessfully with the most updated version?

2

Hi Daniel,
I do not see your configured receivingEEPId="F6_10_00_EltakoFPE" in the binding docs, only F6_10_00 / F6_10_01 seem to be valid (but only for thing-type “mechanical handle”).

For thing-type “contact” only D5_00_01, A5_14_01_ELTAKO are valid according to the binding docs.

Perhaps there was a change between 3.2 and 3.3 and 3.2 was more tolerant.
I think you should give D5_00_01 a try.

HTH,
-Markus

3

Hi Markus,

thats were it starts not being consistent.
If I take the wrong EEPId e.g. F6_10_00 I get the following during loading the new item file:

'enocean:contact:gtwy:st_EG_K_Fenster' changed from UNINITIALIZED to UNINITIALIZED (HANDLER_CONFIGURATION_PENDING): {receivingEEPId=Der Wert F6_10_00 ist nicht in den erlaubten Optionen enthalten. Erlaubte Optionen sind: [ParameterOption [value="D5_00_01", label="D5-00-01 single input"], ParameterOption [value="A5_14_01", label="A5-14-01 Single input contact, supply voltage monitor"], ParameterOption [value="A5_14_01_ELTAKO", label="Eltako battery status"], ParameterOption [value="F6_10_00_EltakoFPE", label="F6-10-00 Eltako FPE-X"]]}

So the option F6_10_00_EltakoFPE should be allowed and there comes no error during loading.
But even if I try D5_00_01 there is still the same issue with cannot instantiate.

Another try was to make a discovery. Then it is added as MechanicalHandle but the error remains the same (tried all the EEPids offered…)

The wrong instaniante leads additionally to some instability of the whole Binding, only disable/enable gets it stable again.

4

I’d recommend to try with mechanicalHandle and with F6_10_00, that is how my FTKE works. (and clean OH cache in between restarts).

The FPE is in fact supported in the code, but not mentioned in the docs. But the FPE-1/FPE-2 send different values for open/close, that would explain the NPE.

grafik

grafik

as you receive an F0 this looks more like classical F6_10_00.

Eltako screwed up the complete “TippFunk” series as they do not properly document the EEPs used, but the TF-FKE is identical to FTKE.