Hi @Fruggy83 and @dominikkv,
I can thest the Thermokon STC-Ethernet if I get connection setup directions from you. Would it use rfc2217 or http connection address?
Has anybody successfuly added an Eltako FSUD-230V Dimmer Plug to openhab through the binding? I tried to add it the same way the Eltako FUD-14 is added but could get a teach in. Iâm not sure if the teach in message was correct @fruggy83 ? Anybody got any hints for me?
Hi Johannes @JGKK,
according to the Eltako docs the FSUD-230V has to use the teach in telegram 02000000.
Do not know why Eltako uses another telegram for this dimmer 
.
Best regards
Daniel
Hi all (esp @Windrad, @xxorde, @Ratiomatic, @Jochen86, @jahnra)
I have just released a new beta version of the enocean binding (you find a precompiled version in the release section). This version supports ESP2 devices like Eltako FAM14, FGW14 or Thermocon STC. I have connected an Pi Zero W to my FAM14 and forwarded the telegrams with ser2net. I created a rfc bridge in openhab and could successfully receive and send telegrams (incl. teach ins into a FSR14 and FSB14). It would be nice if you could test this release too, so I can merge these changes back and create a PR in the official repo.
To add an ESP2 Bridge by DSL you just have to add the new parameter espVersion="ESP2". If the device is connected directly to a RS485 bus you also have to add the parameter rs485=true.
Best regards
Daniel
Hello Daniel (@fruggy83)
At first, thank you very much for this implementation!!
I have successfully installed the binding and reconnect my Pi via a RS232 level shifter to a FGW 14.
Till now, I have made just some basic tests - here are my thoughts:
Paper UI seems to show the wrong version (2.5.0.1)
I was a bit confused for a moment:-)
While sending a simple rocker switch you add 256 to the sender ID (0x101 for the first device)
Is this correct? This is what I can see in WinEtel connected to FAM14.
I was also able to receive the status telegrams from my eltako devices. They are coming only with their bus IDĆ. (e.g. 0x00000023). I guess you were not able to see this telegrams in you configuration (USB on FAM14).
Is the âRS 485â the right description for the option?
What is the option switch really doing? I have to switch it on, but I am using a RS232 connection to FGW.
You will get more feedback during weekend.
Best Regards,
Rainer
Hi Rainer @jahnra,
thanks a lot for your testing 
Paper UI seems to show the wrong version (2.5.0.1)
I will fix this.
While sending a simple rocker switch you add 256 to the sender ID (0x101 for the first device)
Is this correct? This is what I can see in WinEtel connected to FAM14.
The SenderId should still be calculated by BaseId + SenderIdOffset. Can you please show me the telegram send by openhab?
I was also able to receive the status telegrams from my eltako devices. They are coming only with their bus IDĆ. (e.g. 0x00000023). I guess you were not able to see this telegrams in you configuration (USB on FAM14).
Yes for sure, I saw the exact same telegrams. If the source of a telegram is located in your rs485 bus, you receive a telegram with the bus id of the device. If the source is a radio telegram you get the enocean (radio) id. At least this is what I observed when I connected openhab to my FAM14. I would expect the same behaviour with your FGW14.
Is the âRS 485â the right description for the option?
What is the option switch really doing? I have to switch it on, but I am using a RS232 connection to FGW.
Sorry, I should have explained that in more detail. The RS485 option tells openhab that the physical gateway is directly connected to the RS485 bus. I does not matter how you connect openhab with your physical gateway (rs232, rfc, tcp etc). A gateway connected to the RS485 bus does not have a BaseId, as these BaseIds are just needed for radio telegrams. Bus telegrams can have any SenderId. So whenever this option is activated, I do not try to get the BaseId from the gateway and set it instead to 0x00000000 (if needed I could introduce a new option to set this BaseId to a user defined one).
You do not have to set this option when you connect to a radio ESP2 gateway like the Thermokon STC (@Ratiomatic). These devices should have a BaseId as usual.
Some more observations:
Best regards
Daniel
@fruggy83 @dominikkv Is this issue being handled in the future update? The log shows the NOD on 2ch wall module gives no answer to he command and also does not switch the output. Could the binding check this and resend the command? This basically would leave the automation into wrong state causing overheating/cooling light not switching etc.
My setup receives window contact state and then turns the output ON/OFF
Output 1 of 0582875B changes correctly from ON->OFF:
13:51:23.569 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - Enqueue new send request with ESP3 type RADIO_ERP1 without callback
13:51:23.572 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - Sending data, type RADIO_ERP1, payload D2010000FF938B8400010582875BFF00
13:51:23.571 [INFO ] [arthome.event.ItemStatePredictedEvent] - RA_TV_R202 predicted to become OFF
13:51:23.573 [INFO ] [smarthome.event.ItemStateChangedEvent] - RA_TV_R202 changed from ON to OFF
13:51:23.591 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - RESPONSE with code RET_OK payload 00 received
13:51:23.978 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - RADIO_ERP1 with RORG VLD for 0582875B payload D20460800582875B0001FFFFFFFF4600 received
13:51:23.980 [DEBUG] [ernal.handler.EnOceanBaseThingHandler] - ESP Packet payload D20460800582875B00 for 0582875B received
13:51:23.985 [INFO ] [smarthome.event.ItemStateChangedEvent] - RSSI_R201_R202 changed from Rssi 65, repeated 0 to Rssi 70, repeated 0
Output 1 of 0582875B changes from ON->OFF, real state remains ON:
13:51:27.906 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - Enqueue new send request with ESP3 type RADIO_ERP1 without callback
13:51:27.908 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - Sending data, type RADIO_ERP1, payload D2010000FF938B8400010582875BFF00
13:51:27.908 [INFO ] [smarthome.event.ItemCommandEvent ] - Item âRA_TV_R202â received command OFF
13:51:27.909 [INFO ] [arthome.event.ItemStatePredictedEvent] - RA_TV_R202 predicted to become OFF
13:51:27.909 [INFO ] [smarthome.event.ItemStateChangedEvent] - RA_TV_R202 changed from ON to OFF
13:51:27.924 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - RESPONSE with code RET_OK payload 00 received
Thank you very much for the new EnOcean Binding
I use an Eltako Rocker Switch FT55 to switch between 4 light scenes of my light panel (Hue:0210 âŠ) in my kitchen. Most of it works fine except a minor thing. When I release the rocker switch button the color temperature always changed from 100 to 87 even it should stay 100, as you can see from the log
2019-03-18 12:48:32.132 [vent.ChannelTriggeredEvent] - enocean:rockerSwitch:A60149OK:FEF8B1BF:rockerswitchA triggered DIR2_PRESSED
2019-03-18 12:48:32.143 [ome.event.ItemCommandEvent] - Item âTaster_Kueche_linksâ received command OFF
2019-03-18 12:48:32.147 [nt.ItemStatePredictedEvent] - Taster_Kueche_links predicted to become OFF
2019-03-18 12:48:32.152 [vent.ItemStateChangedEvent] - Taster_Kueche_links changed from ON to OFF
2019-03-18 12:48:32.154 [ome.event.ItemCommandEvent] - Item âLicht_EG_Panel_Kueche_KWâ received command 100
2019-03-18 12:48:32.159 [ome.event.ItemCommandEvent] - Item âLicht_EG_Panel_Kuecheâ received command 100
2019-03-18 12:48:32.166 [nt.ItemStatePredictedEvent] - Licht_EG_Panel_Kueche_KW predicted to become 100
2019-03-18 12:48:32.175 [nt.ItemStatePredictedEvent] - Licht_EG_Panel_Kueche predicted to become 100
2019-03-18 12:48:32.182 [vent.ItemStateChangedEvent] - Licht_EG_Panel_Kueche_KW changed from 87 to 100
2019-03-18 12:48:32.185 [vent.ItemStateChangedEvent] - Licht_EG_Panel_Kueche changed from 0 to 100
2019-03-18 12:48:32.383 [vent.ChannelTriggeredEvent] - enocean:rockerSwitch:A60149OK:FEF8B1BF:rockerswitchA triggered DIR2_RELEASED
2019-03-18 12:48:33.374 [vent.ItemStateChangedEvent] - Licht_EG_Panel_Kueche_KW changed from 100 to 87
I use the following item definition
Switch Taster_Kueche_links âTaster KĂŒche linksâ { channel=âenocean:rockerSwitch:A60149OK:FEF8B1BF:rockerswitchAâ }
Switch Taster_Kueche_rechts âTaster KĂŒche rechtsâ { channel=âenocean:rockerSwitch:A60149OK:FEF8B1BF:rockerswitchBâ }
and the following rules
// KĂŒchenlicht aus -AUS
rule âKuechenTaster links obenâ
when Channel âenocean:rockerSwitch:A60149OK:FEF8B1BF:rockerswitchAâ triggered âDIR1_PRESSEDâ
then
Licht_EG_Panel_Kueche_KW.sendCommand(100)
Licht_EG_Panel_Kueche.sendCommand(0)
end// KĂŒchenlicht hell warmweiĂ - Romantik
rule âKuechenTaster links untenâ
when Channel âenocean:rockerSwitch:A60149OK:FEF8B1BF:rockerswitchAâ triggered âDIR2_PRESSEDâ
then
Licht_EG_Panel_Kueche_KW.sendCommand(100)
Licht_EG_Panel_Kueche.sendCommand(100)
end// KĂŒchenlicht warmweiĂ gedimmt - Nachtlicht
rule âKuechenTaster rechts obenâ
when Channel âenocean:rockerSwitch:A60149OK:FEF8B1BF:rockerswitchBâ triggered âDIR1_PRESSEDâ
then
Licht_EG_Panel_Kueche_KW.sendCommand(100)
Licht_EG_Panel_Kueche.sendCommand(30)
end// KĂŒchenlicht hell kaltweiĂ - Arbeiten
rule âKuechenTaster rechts untenâ
when Channel âenocean:rockerSwitch:A60149OK:FEF8B1BF:rockerswitchBâ triggered âDIR2_PRESSEDâ
then
Licht_EG_Panel_Kueche_KW.sendCommand(0)
Licht_EG_Panel_Kueche.sendCommand(100)
end
Any idea how to solve this issue? Iâm not sure if the issue is EnOcean or Hue related.
⊠If I use the OH App on my tablet I can change the color temperature to 100 and it stays 100
Hi Bernhard @BG56
really strange behaviour 
. I do not think that this is related to the EnOcean binding. Could you try to create the rockerswitchA Pressed rule with a dummy switch item? I am not sure, if you can switch this dummy item in PaperUI, as it just shows linked channels. So you have to put this dummy item in a sitemap and switch it through BasicUI.
Are you sure that you have not defined a rule for the RELEASED event? The temperature change occures approx one second after RELEASED is triggered. Could you please try to activate the debug log, maybe we can see who is responsible for the color change in this way.
Best regards
Daniel
Hi Tanel @Ratiomatic,
first of all, if an actuator send its state back as a response to a switch command, I would always recommand to deactivate the autoupdate feature on the item. In this way the internal state of an item is not changed when you switch it manually in the gui. It has to be changed explicit by the binding, for example after receiving the response.
For a similiar case I am working on a retry policy. I send the command again and again until I receive a response (see here). You can use the retryInterval and retryTries properties to configure the policy. This feature should already be integrated in the current release.
Just to make sure, the NodOn switch just sometimes does not react on the switch command? Or does it never react on the OFF command?
Best regards
Daniel
By the way: Thanks a lot for the 
Hi Daniel @fruggy83,
Again thanks for all of your efforts, the binding is taking a really usable form. Some more common EEPs to implement and soon the OpenHAB is the best choice when it comes to Enocean support. It is really easy now to make your existing home pretty smart without any new cabling.
I was on snapshot build when testing the issue. It happened on both transitions ON->OFF and OFF->ON
After installing the latest beta, I disabled the autoupdate on the relay things and entered the retryInterval and it works like a charm, I can now go crazy on the window-contact and it checks out everytime.
By default the retryInterval was 0 (did not retry) does this mean no retry is set or is it done with suppressRepeating?
Can you please exlain further what the sendBroadcast option would do? I canât imagine use of broadcast with the relay module.
Hi Daniel,
thank you for your quick reply. I have no rules for the RELEASED events defined.
Iâm back home on Friday and will test what you have proposed. I just want to clarify that I understood what you mean. I should define
⊠a dummy item:
Switch Dummy_Item âDymmy Itemâ
⊠and put the dummy item into the sitemap:
Switch item=Dummy_Item
⊠and change one of the rules to test:
when Dummy_Item triggered âONâ
then
Licht_EG_Panel_Kueche_KW.sendCommand(100)
Licht_EG_Panel_Kueche.sendCommand(0)
end
Are item, sitemap and rule as you proposed for testing?
Regards,
Bernhard
HI Bernhard @BG56,
withe the exception of the rule, the proposed steps are fine. I would just replace the rule, which sets both items Licht_EG_Panel_Kueche_KW and Licht_EG_Panel_Kueche to 100, as this rule gets triggered when you press your Taster_Kueche_links.
So take the following one
when Dummy_Item triggered âONâ
then
Licht_EG_Panel_Kueche_KW.sendCommand(100)
Licht_EG_Panel_Kueche.sendCommand(100)
end
In this case you can simulate your button press without using the EnOcean binding. If it still the same behaviour, we know that it cannot be related to the EnOcean binding.
Best regards
Daniel
Hi Tanel,
the retryInterval defines after how many milliseconds without a response from the device the message is send again. The retryTries defines how many times the message is repeated (I know, the naming of these options is not the best). If one of these options is set to 0, the retry policy is deactivated.
The option suppressRepeating controls if a message is allowed to be repeated by an EnOcean repeater. @ThAO had a use case for this.
Some devices just react on messages which are directly addressed for them. Other devices just react on broadcast messages. In most cases I can detect this correct. In all other cases you have to set this option accordingly. All VLD (D2) messages must be directly addressed, so broadcast for a relay should always be deactivated. Maybe I should define this option as an advanced option and hide it for a better usability.
Best regards
Daniel
Hello Daniel @fruggy83
I have played around again the last daysâŠ
But unfortunately I was struggling with some âbeginnerâ problems.
Im still not able so see the telegram content.
log:set TRACE org.openhab.binding.openocean has no effect in my logging output.
But I can confirm when I setup 0x000001xx addresses in my actuators I am able to control my lights over FGW14. If this was different over FAM14 in your tests I wish to be able to change the Base ID.
Otherwise users has to use different actuator settings depending on their connection because FGW seems to change sender ID.
But at the moment a face a different problem:
Most of the time i get the message: No SerialPortProvider found for: /dev/ttyAMA0
When this happens, I am still able to send over this interface but I can not receive anything.
Can somebody guide me what serial feature:install I have to do on the latest snapshot.
I have added the users to dialout already over openhabian-config and I tried it manually also.
Thanks for your help!
Best Regards,
Rainer
Hi @fruggy83 @dominikkv
Please will somebody involved post a short instruction and maybe update the documentation how to utilize the Generic Thing using A5_FF_FF or D2_FF_FF. I have looked trough forums and canât get an idea how this can be done to receive numeric values, all examples are with MAP transform.
For example if I wanted to read EEP A5-09-04 how to get the raw data and divide it to 3 raw bytes (Temp, Humidity and CO2 value in this case) Should we use this with JS transform?
I think this would solve many seldom used EEPs, that neccessarily do not need full support.
Hi Rainer @jahnra,
you can enable the debug log with log:set debug org.openhab.binding.enocean
I kept the binding id of the official version, so you do not have to change your config files when you switch between the official version and openocean.
I should be sufficient to just feature:install openhab-transport-serial in the karaf console.
Could you please tell me more about your setup? Is it like RaspPi => FGW14 => BUS => FAM14 => WinEtel? Is WinEtel connected by USB or by radio with FAM14? I just checked again but I cannot image why 256 should be added to the senderId.
Best regards
Daniel
Hi Tanel @Ratiomatic,
for complex and not yet implemented EEP like D2 EEP we must use a Generic Thing in conjunction with a JS transform. A simple MAP transform would be to complicated as you have to list all different combinations in you mapping file. I have not found time yet to document a JS transformation. So if you have time, it would be great if you could create an example.
Best regards
Daniel
Hello Daniel @fruggy83,
log:set debug org.openhab.binding.enocean
instead of
log:set debug org.openhab.binding.openocean
was successful - thank you!
Yes, it is exactly like this. and FAM14 was connected over USB to WinEtel.
Sending over ttyAMA0 => FGW14 is looking like:
2019-03-26 00:00:49.167 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Enqueue new send request with ESP3 type RADIO_ERP1 without callback
2019-03-26 00:00:49.171 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Sending data, type RADIO_ERP1, payload F600000000012001FFFFFFFFFF00
But the actuator programmed to address 0x00000101 will respond. With ttyUSB0 over FAM14 this actuator does not respond.
The FGW14 is designed also to connect two series 14 buses. I guess this behaviour is normal to not have a conflict between the actuator status messages of two different buses. Iâm sure that FGW14 will modify the sender address when a address between 0 and 255 is received. Because of this, modifying the BaseId in this mode would be greatâŠ
With my serial problem I did:
sudo service openhab2 stop
sudo openhab-cli clean-cache
sudo service openhab2 start
feature:install openhab-transport-serial on Karaf
After I was able to receive over ttyAMA0, but after openhab2 restart or reboot the raspi, receiving channel is dead again!
Update:
I used a fresh installation with only openocean.
This seems to solve my problem also: New openHab2 EnOcean binding - #449 by fnu
Best Regards,
Rainer
First I need a hint how to access the raw payload, when I just assign a variable to Number there is no update. I also tried the JS transform to just return the value:
(function(inputData) {
return (inputData);
})(input)
Only thing I can get is last update timedate:
11:12:01.985 [TRACE] [ternal.transceiver.EnOceanTransceiver] - Received Sync Byte
11:12:02.002 [TRACE] [ternal.transceiver.EnOceanTransceiver] - >> Received header, data length 12 optional length 7 packet type 1
11:12:02.013 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - RADIO_ERP1 with RORG VLD for 050466FE payload D24000E00000B0050466FE0000FFFFFFFF2E00 received
11:12:02.022 [DEBUG] [ernal.handler.EnOceanBaseThingHandler] - ESP Packet payload D24000E00000B0050466FE00 for 050466FE received
11:12:02.138 [INFO ] [smarthome.event.ItemStateChangedEvent] - VM_Pressac_VU changed from 2019-03-26T11:11:31.880+0200 to 2019-03-26T11:12:02.118+0200