ESP2 Support

[Stoney49th]

Hi,

some installations require the support for ESP2 (e.g. Eltako 14-Series Devices) since they were defined before ESP3 was out. Since these devices are still relatively new and support will last for many years on, it would be awesome to have ESP2 support. I have a whole house installation based on these devices, so I'm able to test almost any kind of 14-Series Device (at least the standard ones like switches, dimmers, shutters, etc. etc.).

What would be your preferred way of extending the codebase for ESP2 support? I would love to do so in the future and feed the result back to the project. Let me know guys what you think...

P.S: https://www.enocean.com/fileadmin/redaktion/support/dolphin-api/esp2_page.html

[xxorde]

Hi @Stoney49th,

thank you for opening this issue. I would really appreciate ESP2 support, too. I am planing to use "Eltako 14-Series Devices" as well.

If anyone who does not own any of these devices would like to help, I can make a self contained test setup available.

[Stoney49th]

Ha, nice 👍

By the way...i did some modifications to the codebase and wrote an ESP2 backend. I also included class definitions for most Eltako 14-Series devices with commonly used functions (at least in my installation). It's neither super polished, nor perfectly well coded (im a bare-metal C/C++ guy, so bare with me...). But it works pretty reliably since about 4 months now...support for auto message parsing has not been implemented yet in ESP2 since I wrote device those classes for each specific device due to some special eltako quirks.

I'll try to sort things out here and remove my installation specific stuff - followed by a fork and push. I don't want to mess up this cool project - but maybe someone willing to apply some polish might be able to get this ready for a pull request?

How about that?

[xxorde]

Fast response @Stoney49th!

I am not even a developer myself, but I would really like to look into your changes. You could upload them as a "fork" on your name space if you like. But take your time polishing first, it may take until next week, until I find time to dig deeper into this.

[kipe]

@Stoney49th Sounds great! :+1: Once you're happy to make a pull request, open one and we can then continue on commenting and polishing it through that

I've been also interested in the Eltako -products for quite a while, and it would be awesome to have support for them.

[Stoney49th]

Hey guys,

I just forked and push to a new branch. You really have to review my stuff first and maybe make some changes, because I many use this as a enocean to mqtt gateway with influx logging, so there is some mqtt stuff mixed into the classes (aka. what topic to send to...but no direct mqtt usage there) which might not be tolerable for some I guess. But hey, maybe this is the starting point for wider device support, since "standard" could also be modelled as a device. I felt the need to introduce this concept because of the state handling required to actually do something with a shutter or a dimmer - however these aspects are far too low-level to push them towards the UI sitting behind mqtt.

Pull request incoming...

[xxorde]

Hi @Stoney49th,

did you find some time to prepare your code? If you like you could just push what you have, so we can take a look as well.

[Stoney49th]

Hey,

sure, I removed the personal parts and tried to structure the commits. Just have a look at the pull request and/or my fork...I've also included my eltako<->mqtt backend and a simple mqtt to influx logger.

[xxorde]

Ah, sorry I did not see the PR or your branch stoney_ESP2_mqtt. I checked your fork from time to time but missed the branch...

[xxorde]

@Stoney49th I hat some time last night to look into your code. Now I need to get my devices working to test and extend it.

I added some debug messages to log every received packet. You can already see all status messages and all events, so it seems you have done the hard part well!

2018-04-27 01:02:00,312 - eno_backend - DEBUG - packet type:EVENT,   rorg:RORG.RPS, packet:00:00:00:01->FF:FF:FF:FF (0 dBm): 0x04 ['0xf6', '0x70', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x1', '0x30'] [] OrderedDict()
2018-04-27 01:02:00,375 - eno_backend - DEBUG - packet type:EVENT,   rorg:RORG.RPS, packet:00:00:00:02->FF:FF:FF:FF (0 dBm): 0x04 ['0xf6', '0x70', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x2', '0x30'] [] OrderedDict()
2018-04-27 01:02:00,424 - eno_backend - DEBUG - packet type:EVENT,   rorg:RORG.RPS, packet:00:00:00:03->FF:FF:FF:FF (0 dBm): 0x04 ['0xf6', '0x50', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x3', '0x30'] [] OrderedDict()
2018-04-27 01:02:00,487 - eno_backend - DEBUG - packet type:RESERVED,    rorg:RORG.UNDEFINED, packet:0x00 ['0xf6', '0x70', '0x0', '0x0', '0x0', '0x0', '0x0', '0x10', '0x1', '0x30'] [] OrderedDict()
2018-04-27 01:02:00,551 - eno_backend - DEBUG - packet type:EVENT,   rorg:RORG.RPS, packet:00:00:00:04->FF:FF:FF:FF (0 dBm): 0x04 ['0xf6', '0x50', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x4', '0x30'] [] OrderedDict()
2018-04-27 01:02:00,615 - eno_backend - DEBUG - packet type:RESERVED,    rorg:RORG.UNDEFINED, packet:0x00 ['0xf6', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x10', '0x1', '0x20'] [] OrderedDict()

The events from my FTS14EM rocker switches are not parseable by your class FTS14EM do you have any hints for me? I was already surprised that about type:RESERVED and rorg:RORG.UNDEFINED.

2018-04-28 13:11:09,516 - eno_backend - DEBUG - packet type:RESERVED, rorg:RORG.UNDEFINED, packet:type:0x00 data:['0xf6', '0x70', '0x0', '0x0', '0x0', '0x0', '0x0', '0x10', '0x1', '0x30'] optional:[] parsed:OrderedDict()
2018-04-28 13:11:09,516 - eno_backend - DEBUG - Eltako switch
Traceback (most recent call last):
  File "./enocean_backend.py", line 52, in eno_worker
    button = rockers.new_event(packet)
  File "/usr/local/lib/python3.6/dist-packages/enocean-0.41.0-py3.6.egg/enocean/manufacturer/eltako.py", line 60, in new_event
    if packet.sender[0:2] == [0x00, 0x00] and packet.sender[2] <= 0x19 and packet.sender[2] >= 0x10:
AttributeError: 'Packet' object has no attribute 'sender'

Update

I am now able to trigger my actors but I had to do some changes in order to send packets of type "PACKET.RESERVED", Add support to send PACKET.RESERVED packets.

@Stoney49th did you find another way to activate your FSR_FTN_14? I had a look at your function "on_message_light_toggle" but it seems not to be functional.

[xxorde]

@Stoney49th any news?

[chrysn]

@Stoney49th, are you still interested in working on this?

If not, I'd continue with xxorde's version of your branch and try to get it into a shape that could be upstreamed into the master version to get it actually usable on home-assistant.

[MalibuKoKo]

Hi @Stoney49th , @xxorde Tahnks for your work, can you explain to me how i can use it with "EnOcean to MQTT Forwarder" or "home assistant" ?

Thanks

[xxorde]

Hi @MalibuKoKo, I did not finished working on the code and I am not running it at the moment.. so I am not much of a help here. Are you only interested in MQTT, if an hass.io integration would also solve your problem you might want to have a look at the integration by @chrysn, https://gitlab.com/chrysn/home-assistant-eltako

[stv0g]

I had a look at @xxorde and consequently @Stoney49th implementation of the code.

I think we should try to reduce the duplicated code in the communicator classes. Basically only Packet.parse_msg() and Packet.build() really differ between ESP2/ESP3.

What about moving these two function into a seperate ESP2Protocol and ESP3Protocol classs which would parse and build packets. These would be used by the communicator.

[stv0g]

I have another proposal: Maybe its easier to keep the Packet class untouched. Instead we could convert ESP2 messages to ESP3 and back within the Communicator class.

[hprotzek]

Hello, any change to get the ESP2 support in? The Eltako FAM14 devices are unmatched in price for the DIN rail, would be perfect to be able to use them in Homeassistant.

[grimmpp]

Hello all,

I would be interested as well to get a converter from esp3 and esp2 and back so that I can provide USB300 support in Home Assistant Eltako Integration..

There is already a converters implemented in Java for OpenHab:

• ESP2PacketConverter

Is someone interested in backporting it to kipe/enocean and making it compatible to eltako14bus