Hidden tests - @LutzDi

[mak-gitdev]

Hi @LutzDi,

Please install this preview version and have a look at the useful data shared by @fabi9163 here.
Do not hesitate if you have any questions.

[LutzDi]

Hi @mak-gitdev,

many thx for inviting me to this test. Today I got the chance to set everything up and test it. Some small things first:

I have a small warning issue in the log if I start the AddOn:

/app/venv/lib/python3.11/site-packages/bs4/builder/__init__.py:545: XMLParsedAsHTMLWarning: It looks like you're parsing an XML document using an HTML parser. If this really is an HTML document (maybe it's XHTML?), you can ignore or filter this warning. If it's XML, you should know that using an XML parser will be more reliable. To parse this document as XML, make sure you have the lxml package installed, and pass the keyword argument features="xml" into the BeautifulSoup constructor.

I just want to mention it, don't know if it's important.

Regarding my tests:

FSR14-4x

• Usage > Configuration and Pairing worked without an issue. Pairing as well as using one channel configured worked fine.
• Question > What is the idea if I use more than one channel of an FSR14-4x? How will this be configured? Do I have to make an entry for every channel in the device file, each with individual sender ID? I'm asking because the Enocean device ID will stay the same...
• Question > The other Eltako integrations are not working with the physical device ID FE-A1-C3-E5 but with the device address provided by the Enocean bus. For me, this seems a good approach as every channel of e.g. FSR14-4x gets its own device address. This decimal address can be converted to a hexadecimal address so that the device can be called by e.g. 00-00-F0-2C for the device address 44 (only the last double-digit part is important, the first three are virtual). With this config I can decide for every channel individually in the config - but perhaps your answer to my first question will solve this for me :)

FUD14 (The FUD14 is my main concern so I'm happy that it's basically running)

• Usage:
  • Pairing doesn't work with the 0.0.10. Neither EC1 (Universaltaster) nor LC1 (Richtungstaster) will pair the FUD14.
  • If I set the sender ID manually in the config with PCT14 directly to the FUD14, I can switch on/off as well as dim the light. So baseline seems to work, but pairing is an open issue

What would be open for me?

Window Handle Eltako/Hoppe FHF

• Can you give me a hint on how to configure a sensor for this window handle correctly? I would like to see if the three states CLOSE-OPEN-TILT are received correctly. Is it possible to get tested with this AddOn-Test?

If you need mehr logs/details/test, no prob, just let me know... I hope this is helpful for you... I'm looking forward to your answer.

Thx and cheers
Lutz

[mak-gitdev]

Hi @LutzDi,

Thanks for your feedback and the quite encouraging results.

FSR14-4x

I use this document from Eltako to know how to control each device.
I encourage you to have a look at it this document, but here is an excerpt regarding SERIES 14:

As soon as Series 14 actuators receive a device address, the FAM14 can request actuators for confirmation telegrams.
The confirmation telegrams are then radioed by the FAM14.
The ID of the radioed telegrams is identical to the Base ID of the TCM300 in the FAM14 plus the device address.
Multichannel actuators have consecutive device addresses corresponding to the number of channels.

If I understand this correctly, it means that you can with the current version, define 4 entries in the device file, one for each channel with each channel having a separate address formed as explained in the excerpt.
I think, and hope that this will solve both questions regarding FSR14-4x.

FUD14

Nice that everything seems OK except pairing.
What were the positions of the FUD14 rotary switches when attempting pairing.
I think it should be middle rotary=LRN and upper rotary=PCT as we emulate PCT.

Window Handle Eltako/Hoppe FHF

You can use EEP F6-10-00 for that and if you want the 3 states, then use the state_3p entity:

[my_window_handle]
address = 0xYYYYYYYY
rorg = 0xF6
func = 0x10
type = 0x00

[LutzDi]

Hi @mak-gitdev,

thx for your feedback.

FUD14
You are right, with PCT14 the paring works. What I saw during my tests:

• If I pair the FUD14 again with what is already paired over PCT14 then I had to remove the FUD14 from the config, restart the AddOn, and add the device again. Before this clean-up, the FUD14 wasn't recognized at all, with no feedback or function. It's a minor issue for me but I want to mention it.
• An open question concerns the dimming functionality at all:
  • If I switch the light on or off (hit the button), the light switches on and off immediately, but the percent-slider needs 1-3 seconds to jump to 100%. 2nd issue that happens sometimes, is, that I switch on the light and the percentage slider jumps to e.g.52%, then it takes 1-3 seconds and then the slider jumps to 100%. This double-step is not happening all the time... I made you a small video, please take a look at this for a better understanding.

aufzeichnung-2024-01-03-113743_RA9inUoQ.mp4

Do you have any idea about this time lag?

Thx and cheers
Lutz

[mak-gitdev]

Hi @LutzDi,

The status is updated when the feedback telegram is received from the FAM14.
So I think this happens because there is a delay at the FAM14 level.
And reading that same document previously mentioned, it is said:

Note: Depending on the number of actuators on the bus, there may be a time lapse of up to 10 seconds before a confirmation telegram is requested and radioed.
If fast confirmation is expected by certain actuators, a device list for confirmation telegrams must be generated via the PCT14.
The actuator must be entered several times in the device list.
The FAM14 must then be operated in operating mode 5.

So I think that tends to confirm my assumption.

I will have a look at Eltako documents but I don't think they have telegrams to handle such deep configuration so I don't think this can be done from the USB300.
Hence you may somehow have to do some tuning of your installation using PCT14 as explained in the quoted text.
The good thing is that this configuration is done once for all.

[LutzDi]

Hi @mak-gitdev,

coming back to the window handle:

Hoppe FHF

• It is configured right, I see the value state_3p
• If I switch from closed to open, the state changes to open. If I change from open to tilt, state changes to tilt. Back to open status also changes to open. After that, the status won't change anymore. I was only able to do this once, also cleaning the config and start from the scratch won't change anymore. I see that the last_seen_state only changes if the handle is moved to the open position, closed and tilt won't change the last seen state as well as the state_3p.

Do you have any idea?

Thx and cheers
Lutz

[mak-gitdev]

Hi @LutzDi,

For this one, I will need some logs to understand what is happening.
It will require to activate debug as well.

What is the RSSI of the FHF ?

[LutzDi]

Hi @mak-gitdev,

I think the distance between the window handle and the USB300 is the problem. I have to optimize this. If reduce the distance everything seems working. I will test it a bit more and if something is still open, I let you know... Thx a lot for being part of this test...

cheers
Lutz

[mak-gitdev]

Hi @LutzDi,

Thanks for your feedbacks.

I saw that you added your devices to the list of confirmed working devices.
Just for my understanding:

• Does it mean that you've been able to solve the issue with the FUD14 lag ?
• For the FSR14-4x, have you been able to pair and control all your channels ? If so, could you please give me more details so I can better understand how it works ?

Thanks