Frequent trouble with EnOcean switches

[OlwinFroon]

The problem

I have a problem with my EnOcean switches (Eltako 1/2 rocker wall switch F1T65/F2T65, EEP F6-01-01/F6-02-01) not always working as intended, so I used the events and log viewers to pinpoint the issue.

Usually, those switches send a status byte "0x30" (button pressed) or "0x20" (button released) which the integration translates into "pushed: 1" or respectively "pushed: 0". If it works like that, everything is fine.

For some reason, my buttons frequently send a "0x31" or "0x21" instead, which results in "pushed: null".
I have no idea where that extra bit comes from, and it happens with all my switches regardless.

What version of Home Assistant Core has the issue?

2022.5.4

What was the last working version of Home Assistant Core?

No response

What type of installation are you running?

Home Assistant OS

Integration causing the issue

EnOcean

Link to integration documentation on our website

https://www.home-assistant.io/integrations/enocean/

Diagnostics information

No response

Example YAML snippet

No response

Anything in the logs that might be useful for us?

No response

Additional information

Like I said, I have no idea where that extra bit comes from or what it means.
Point is, it doesn't work and sometimes I have to tap a switch a dozen times until it finally decides to cooperate.

Worst case my wife will have me replace all those switches with regular old school mechanical crap again D:
Who wants that, eh?

So ... I'd appreciate any hints on how to get rid of that extra bit.

Also, I've perused the binary_sensor.py source code file of the EnOcean integration.

It'd help if somebody could "fix" it by either filtering that bit out or alternatively add 0x21 and 0x31 to the list of valid actions.

Also, it would be hugely useful to add the status byte to the button_pressed event.
Maybe even the complete received packet?

[probot-home-assistant]

enocean documentation
enocean source
_{^{(message by IssueLinks)}}

[probot-home-assistant]

Hey there @bdurrer, mind taking a look at this issue as it has been labeled with an integration (enocean) you are listed as a code owner for? Thanks!
_{^{(message by CodeOwnersMention)}}

[OlwinFroon]

Sorry to drag you in here @rhadamantys as I'm sure that's not protocol, but I noticed you worked on the EnOcean integration yesterday while the listed code owner seems to be inactive.

Could you please take a look into this?

[rhadamantys]

Hello OlwinFroon, according to the EnOcean EEP spec https://www.enocean-alliance.org/wp-content/uploads/2017/05/EnOcean_Equipment_Profiles_EEP_v2.6.7_public.pdf, page 15 & 16, the value 31 means, that there is a valid "second" action. Do you have an idea, what that second action could be? Unfortunately, I don't have that switch, so I can't test that.

Alternatively, you could only check bit DB0.4
packet.data[6] & 0x10 == 0

[OlwinFroon]

Thanks for joining!

That would be DB0.0, right?
Like I said, I have no idea where that comes from or what that ominous "2nd action" could be nor what it's supposed to do.

Those switches are not paired with anything. The idea is to just intercept the raw telegrams and let HA do all the work.

Whatever, checking DB0.4 seems right and would surely do the trick.

I'm not equipped to do it myself, so I'd ask you to add this gimmick to the code which would fix the "pressed" return value.

Pretty please with cream and a cherry on top :)

[OlwinFroon]

Oh wait, disregard, I've been reading up on that file you linked me. Thanks for that!

The telegram consists of

• 1 byte Telegram type
• 1 byte data
• 4 bytes sender address
• 1 byte status

So packet.data[1] (also called "action" in binary_sensor.py) is what EnOcean lingo refers to as "datafield", packet.data[6] is "statusfield".

Datafield contains information about the keys tapped. The script picks valid values of 0x70, 0x50, 0x30, 0x10, 0x37, 0x15 and translates them into "which" and "onoff" return values while it ignores the also valid value of 0x00 (= no key tapped = released).

Statusfield contains information about how to interpret datafield (bit 2H5=T21, bit 2H4=NU) and ... repeater count! (bits 2H3..2H0=RC, see page 11).
So
-0x?1 means the message went through a repeater -.-

The quick and easy way to make this work would be to circumvent the rather restrictive (and, in this case, useless) interpretation into "pushed", "which" and "onoff" by simply adding datafield and statusfield to the event response and let the user parse the result.

[rhadamantys]

I was thinking about that, too. there are several enumerations in DB0 (R1, EB, R2, SA). I think it makes most sense to extract the enum values and send them in the event data.

Can you post some EnOcean telegrams when you push, release and hold the different buttons?

[OlwinFroon]

Sure. F6 RPS Telegrams coming up.

I've relocated HA's EnOcean stick and disabled the repeater. As I hoped, everything works now. No more 0x21 and 0x31 statusfields.
Can't leave it like that, though, the wife wouldn't approve of a lengthy USB cable lying around ;)

Her goes: 1 rocker wall switch

['0xf6', '0x50', '0xXX', '0xXX', '0xXX', '0xXX', '0x30'] tapped "down" (light on)
['0xf6', '0x70', '0xXX', '0xXX', '0xXX', '0xXX', '0x30'] tapped "up" (light on)
['0xf6', '0x00', '0xXX', '0xXX', '0xXX', '0xXX', '0x20'] released
"Released" always looks the same.

2-rocker wall switch:
['0xf6', '0x10', '0xXX', '0xXX', '0xXX', '0xXX', '0x30'] tapped "left down"
['0xf6', '0x30', '0xXX', '0xXX', '0xXX', '0xXX', '0x30'] tapped "left up"
['0xf6', '0x50', '0xXX', '0xXX', '0xXX', '0xXX', '0x30'] tapped "right down"
['0xf6', '0x70', '0xXX', '0xXX', '0xXX', '0xXX', '0x30'] tapped "right up"
['0xf6', '0x37', '0xXX', '0xXX', '0xXX', '0xXX', '0x30'] tapped "left up and right up" at the same time
['0xf6', '0x35', '0xXX', '0xXX', '0xXX', '0xXX', '0x30'] tapped "left up and right down"
['0xf6', '0x17', '0xXX', '0xXX', '0xXX', '0xXX', '0x30'] tapped "left down and right up"
['0xf6', '0x15', '0xXX', '0xXX', '0xXX', '0xXX', '0x30'] tapped "left down and right down"

There is no hold telegram for those.

[OlwinFroon]

I also have a NodOn Soft Button which triggers button_event messages.
It only works because of that, I can't use the advanced capabilities of this button but use it to toggle a lamp.

EEP D2-03-0A, sends VLD telegrams with 2 bytes payload.
Parsing those certainly is a major PITA,
I don't see a way to identify the D2 variant actually used, the telegram only includes "D2".

['0xd2', '0x58', '0x1', '0xXX', '0XX', '0xXX', '0xXX', '0x0'] single tap
['0xd2', '0x58', '0x2', '0xXX', '0XX', '0xXX', '0xXX', '0x0'] double tap
['0xd2', '0x58', '0x3', '0xXX', '0XX', '0xXX', '0xXX', '0x0'] hold
['0xd2', '0x58', '0x4', '0xXX', '0XX', '0xXX', '0xXX', '0x0'] release after hold

Byte 1 (0x58) is the current battery level in percent.

[rhadamantys]

Thanks for the data. It looks to me like we should convert the d2 Sensor to make it compatible to f6.

[OlwinFroon]

Heh, possibly. I wouldn't want to open THAT can of worms right now, though.

I would be more than happy with F6' "datafield" and "statusfield" added to the event and the repeater count filtered out.

That would be a 5 minute fix and allow to integrate all kinds of F6 switches on the event handling end of HA, without changing much of the integration.

[rhadamantys]

I have a problem. Even if I did the change, I have no possibility to test it. So how should we proceed?

[OlwinFroon]

I'd be interested enough to set up a test environment involving an own server and enocean stick, but I need to get my hands on the required hardware, first. I guess it'd be a plain vanilla setup except I'd check the beta channel box? But the main problem: I slipped a disk and won't be able to do anything useful for the next 2 or 3 weeks ... Am 27. Mai 2022 20:08:28 MESZ schrieb rhadamantys ***@***.***>:

I have a problem. Even if I did the change, I have no possibility to test it. So how should we proceed? -- Reply to this email directly or view it on GitHub: #71935 (comment) You are receiving this because you authored the thread. Message ID: ***@***.***>

-- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

[rhadamantys]

I hope you feel better soon! Anyway, whenever you are ready, I could commit a fix on my fork that you could test...

[jgralfs]

@rhadamantys sorry to hijack the thread but I am starting to build my home automation with home assistant and enocean. Do you plan to integrate rollershutter actuators like the FSB14 or may be able to help with this?

[OlwinFroon]

Back on deck. Ish, at least.

I've prepped a Raspberry for the test environment and expect my EnOcean test stick to be delivered within 48 hrs.
A repeater and a wall switch are standing by already.

I'm not entirely sure how to set this up, though, since this test system won't use the official HA release but rather your github version.
Never did that before, I'm gonna need a walkthrough here, please.

[OlwinFroon]

@rhadamantys ready-ish when you are :)

[rhadamantys]

@OlwinFroon: I haven't forgotten you. I am still busy with another issue, that I am fixing. I would like to finish that PR first.

[OlwinFroon]

Of course, no hurry. Thank you! Am 1. August 2022 04:22:41 MESZ schrieb rhadamantys ***@***.***>: ***@***.***: I haven't forgotten you. I am still busy with another issue, that I am fixing. I would like to finish that PR first.

-- Reply to this email directly or view it on GitHub: #71935 (comment) You are receiving this because you were mentioned. Message ID: ***@***.***>

-- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

[issue-triage-workflows]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.
Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍
This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.