Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ESP2 Support #72

Open
Stoney49th opened this issue Jan 11, 2018 · 17 comments
Open

ESP2 Support #72

Stoney49th opened this issue Jan 11, 2018 · 17 comments

Comments

@Stoney49th
Copy link

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
Copy link

xxorde commented Apr 9, 2018

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.
eltako-test

@Stoney49th
Copy link
Author

Stoney49th commented Apr 9, 2018

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
Copy link

xxorde commented Apr 9, 2018

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
Copy link
Owner

kipe commented Apr 10, 2018

@Stoney49th Sounds great! 👍
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
Copy link
Author

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
Copy link

xxorde commented Apr 21, 2018

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
Copy link
Author

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
Copy link

xxorde commented Apr 22, 2018

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
Copy link

xxorde commented Apr 27, 2018

@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
Copy link

xxorde commented May 27, 2018

@Stoney49th any news?

@chrysn
Copy link

chrysn commented Sep 7, 2018

@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
Copy link

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
Copy link

xxorde commented Feb 11, 2019

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
Copy link
Contributor

stv0g commented Mar 3, 2019

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
Copy link
Contributor

stv0g commented Mar 4, 2019

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
Copy link

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
Copy link

grimmpp commented Nov 14, 2023

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:

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

8 participants