Hi @dominikkv,
Good news, this smart ack has same logic so this should not be a problem to use this as base.
Will your developement of A5-20-04 cover the more common A5-20-01? If not then please add it to your list as these are also really cool line of devices.
Please keep me updated, I can test on different devices, I have 5 different manufacturers radiator valves with the A5-20-01 for testing.
Hi all,
sorry for being so silent in the last weeks. We had some health troubles here 
. But now I am back on track 
. I am currently working on ESP2 support and enabling some more low level features like smart ack (@Ratiomatic, I hope we do not implement it twice @dominikkv) or listening to duty cycle events to improve message sending reliability.
Best regards
Daniel
ps: Thanks a lot to all donators, I am really happy that so many make use of this project!
Hi Daniel,
Good to hear you have overcome the illness! Thanks for your efforts, the binding is really intuitive via Paper UI for even a common home user.
How to make donations? Is it straight to the user or to the binding dev group?
@dominikkv
@fruggy83
I would like to support developers that make the A5-20-01, D2-11-01 and Thermokon STC-Ethernet usable with the binding. As I will use some of them in commercial projects it is only fair to channel the funds to devs and kindle future additions to the binding.
Just found this https://nodon.fr/en/nodon/the-soft-button-enocean/ and was wondering if the binding already supported it? It’s a simple push button with a D2-03-0A profile.
I just ordered one and it would be great to use it with openhab/openocean. I’d be happy to supply any information if needed once it arrives here.
Hi @Ratiomatic,
thanks a lot for your words. I am always happy to get such a feedback 
How to make donations?
You find donation links on my github repo. I am using it as a testing playground and merge things back from there into the official openhab repo. The latest version of the binding can be found there too.
Thermokon STC-Ethernet
If I understand the docs correctly, this device receives EnOcean telegrams and forwards them to a server. When I have finished my current work on the ESP2 support, it should not be a big problem to make this device usable with the binding, as it forwards ESP2 telegrams. However I would like to understand more why you want to use this device. Would not it be easier to just use an USB300 gateway? If your server is to far away to receive stable signals you could also use a rfc2217 connection which is already supported by this binding.
Best regards
Daniel
HI Johannes,
this profile is already implemented in my working tree. I am just waiting for my button to arrive. I will use it as an outdoor switch for my garden lights. If it signal strength is good enough I will also use it as a garage door opener.
Best regards
Daniel
That’s good to know, mine is supposed to arrive this week. I look forward to when it works. Thanks for the great work on the Binding. Regards Johannes
Hi @fruggy83,
Thermokon STC-Ethernet- It has a nice antennae and professional feel to it, for larger building it can be a remote gateway with OpenHAB server in cellar/cabinet/well shielded room. Otherwise I must agree it is quite expensive. What hardware would you use with the rfc2217 - ser2com on Raspberry PI with USB300 or is there some more elegant setup?
Another suggestion is STC-DO8-1 That enables receiving directly temp sensor/thermostat signal and actuating outputs. Gateway control uses A5-20-12 and reporting state with A5-11-02. This divided with outputs has competitive pricing (compared to NOdoN DO module for example) taken into account that it is independent, has PWM output and works also when Openhab server is down.
You mentioned you are working on listening to duty cycle events to improve message sending reliability. I hope this gets resolved as I noticed sometimes the rocker->OpenHAB->actuator cycle fails to react and needs many button pushes.
Hi @Ratiomatic,
I totally agree that the STC has a professional feel. I just could not imagine an use case where this is really necessary in a non professional environment. Just a few examples I am using:
None of these solutions look professional (except for the mirror pi 
) but cost just a fraction of a STC. However I think in your case the STC is the best. I am not quite sure if you can compare the DO8 with an STC, as it does not have a RJ45 output and just sends the state of its outputs into the enocean net.
I noticed sometimes the rocker->OpenHAB->actuator cycle fails to react
Do you know where the problems occure? Is it on the rocker → OpenHAB or on the OpenHAB → actuator side? Taking the duty cycle into account should just improve the later one.
Best regards
Daniel
Hi @fruggy83,
Thanks for sharing the different setups, USB300 or FAM14 + Raspberry would come about 50% of the cost of STC, I agree this would not be the often used solution. I could see STC being used by home users that are not worried about the extra cost and go for ease of setup.
Range increase is also possible with repeaters as many relay modules have the extra functionality, but some smartACK devices dont support repeated telegrams.
The STC-8DO is not related to gateways, it was a request for EEP development, I think it should make a good server uptime independent solution for not overheating/freezing.
Do you know where the problems occure? Is it on the rocker -> OpenHAB or on the OpenHAB -> actuator side?
I looked at logs and it seems the OpenHAB system receives the rocker command and sends send command but NODon smart plug (D2-01-0E) failed to turn on in reality. The NodON fails to send the update telegram D2 04 60 E4 in this case, is OpenHAB binding not listening to the state response?
Hi Johannes @JGKK
my button arrived today. It is really small 
As I know me, it will definitely get lost some day (by me or my son) 
As it uses a CRC2032 it is really a soft button. Even my son can press it without a problem, it is huge improvement to the NodOn soft remote.
I have successfully implemented auto discovery (you have to use 5 really short presses!), a channel for each press type (single, double, long as raw button type, however I just get pressed/released telegrams for the long press) and a channel for the battery state. Through profiles it is possible to link these channels to a switch item and toggle its state.
I try to push these changes in the next days.
Best regards
Daniel
That’s great, yes mine arrived too today and I really like the Form factor. The magnetic backside is awesome as I plan on using it in the kitchen and can just stick it on the fridge or stove.
regards Johannes
Hi @Ratiomatic and @dominikkv,
just a quick update. I could finish the ESP2 implementation, tests are ongoing. I could even successfully test a smack teach in between two USB300 dongles. However as I still do not own a smack device I cannot test my implementation with real devices. Do you know any smack device other than the SR06 or the Smartdrive HX? The SR06 is to expensive just for testing and I cannot use the Smartdrive as I have a underfloor heating.
Best regards
Daniel
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