CWL - Additional Data Points for Temporary Programs

[gkressel]

Hi,

First of all, thank you for your work on this integration.

I’m using a WOLF CWL-2 325 with the ISM8 integration, version 3.0.2. My use case involves changing the programs based on calculations of humidity differences (inside and outside). Therefore, I want to change the mode to “Zeitweiser Feuchteschutz” or “Zeitweise Intensivlüftung AN/AUS”.

I see that you already have the switches (DP ID 153 & 158) available and functional. Unfortunately, the WOLF CWL requires additional variables to control these programs. Specifically, to start such a program, you need to set the start date, start time, end date, end time, and the switch.

This is similar to what a user would do on the BM2 “frontend.”

Could you please add these additional 8 datapoints (154–157 & 159–162)?

Thank you in advance!

[marcschmiedchen]

Hmm, thats a non-trivial problem for me.... Since I do not own a CWL or any other device which has Date/Time-Datapoints, I have no way of testing the implementation of the encoding and decoding. Furthermore, the implemention has to be in the python-library (published in pypi) AND in a new Home assistant date-entity-type, both of which have to be implemented "blindly".

I will look into it, no promises though.

[gkressel]

Hi,

I’m not sure if this helps, but there is already a conversion available in the XKNX project: https://github.com/XKNX/xknx/blob/5aa408850aeef5b6e6280905c61263fd0cb6bc13/xknx/dpt/dpt_time.py https://github.com/XKNX/xknx/blob/5aa408850aeef5b6e6280905c61263fd0cb6bc13/xknx/dpt/dpt_date.py

If you need any help testing this, I’d be more than happy to assist. ;-)

[marcschmiedchen]

hmm, I don't quite understand the usage of the "DPT_TimeOfDay" type -- it incorporates a weekday and a special "no day" - encoding. How would this work in CWL? If you specify start- and end-day as dates, say 01.01.24 - 31.01.24 and then you specify the starttime and endtime as "Fr, 08:00" and stoptime "Sa, 23:30". So this translates then to: the program runs every Fr/Sa during January? From your screenshot it seems that the weekday-setting is not used all together, just the time-part....

Could you please bump the log-level of your home assistant in the configuration.yaml to "debug" by adding those lines to configuration.yaml :

logger: default: info logs: custom_components.wolf: debug custom_components.wolf.wolf_entity: debug wolf_ism8.ism8: debug

After a restart, you should get a verbose output of the data received from ISM8. Could you please report what is being received for DP154-DP157 (since it is not implemented yet, theis would be should be an integer or bytewise representation.)

[gkressel]

hi @marcschmiedchen,

In the example you gave, the CWL will start the program on January 1st at 8 AM and run until January 31st at 11:30 PM.

Your understanding of the logic is correct. Wolf doesn't consider the day of the week; it only uses hours and minutes, as they can be configured in the BM2 for these 2 programs. For more details, please seeto the WOLF documentation on this DP. home-assistant_wolf_2024-05-25T19-17-55.846Z.log

Attached is the log file. Could you please confirm if this contains the information you need?

Best G

[marcschmiedchen]

yes , the log file is great. Will try to implement it.

[marcschmiedchen]

implemented. feel free to thoroughly test the integration, because it was a major code change.

[gkressel]

hi @marcschmiedchen,

Should the update go through HACS? I updated to version 3.2 in HACS and restarted my Home Assistant, but the integration still display the old version 3.0.2. Also, I can't see any of the datetime fields. Did I miss something?

[marcschmiedchen]

Yes, through HACS worked with me. And ver.3.2. is also correct. All I can say is, that sometimes a restart from the GUI only is not sufficient.... at least not at the first try. Plesae try to restart several times and/or reboot. As a last resort, remove the integration an re-install it? I had these issues from time to time with HACS, but could not tell where the problem is...

[gkressel]

When I look in the release zip, all files have the modification date of May 21st 2024. Could something have gone wrong?

[marcschmiedchen]

haha, the merge request from the dev-branch failed and I published the old version :) should be fixed now. Please re-install 3.2. Sorry it was my fault

[gkressel]

thx @marcschmiedchen

I mdade a few tests with these new features. I can view the values, but when I attempt to set a date for the program "Zeitw. Feuchteschutz," I receive a brief error message.

Here is the relevant log entry I found: 2024-06-18 21:07:39.094 ERROR (MainThread) [homeassistant.components.websocket_api.http.connection] [140065020658160] Unexpected exception Traceback (most recent call last): File "/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py", line 241, in handle_call_service response = await hass.services.async_call( ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/src/homeassistant/homeassistant/core.py", line 2741, in async_call response_data = await coro ^^^^^^^^^^ File "/usr/src/homeassistant/homeassistant/core.py", line 2784, in _execute_service return await target(service_call) ^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 977, in entity_service_call single_response = await _handle_entity_call( ^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 1049, in _handle_entity_call result = await task ^^^^^^^^^^ File "/usr/src/homeassistant/homeassistant/components/date/init.py", line 37, in _async_set_value return await entity.async_set_value(service_call.data[ATTR_DATE]) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/config/custom_components/wolf/date.py", line 39, in async_set_value _LOGGER.debug(f"send date {date} to ISM8") ^^^^^^^ NameError: name '_LOGGER' is not defined 2024-06-18 21:08:53.855 DEBUG (MainThread) [custom_components.wolf.select] send dp 158: <class 'int'> 1

When I try to set a time, I see there isn't a button (such as "OK") to save my entries. As expected, there is nothing related to this issue in the log.

[marcschmiedchen]

Hi , in setting the date there is a small bug, will fix it very fast. The time setting SHOULD go through, I just forgot to implement a log-message for tracking. But when you check the CWL, the time should have changed. Time Entities do not provide a "OK" button, they just send the value once you leave the field. A minor update will be published today to adress these issues.

[marcschmiedchen]

Added more log-output to verify write operations go through. Also fixed the logging-error which caused time-datapoint-updates to fail.

[pacco81]

Hi !

Has somebody succesfully started a "Zeitweise Intensivlüftung" now ?

I have an CWL2, BM2 and ism8i. Data is coming in.

I set End and Startdate and Time and Enabled the mode with 1.

The log says: 2024-06-23 19:42:39.978 DEBUG (MainThread) [custom_components.wolf.time] send time 19:43:00 to ISM8 2024-06-23 19:42:42.817 DEBUG (MainThread) [custom_components.wolf.time] send time 19:15:00 to ISM8 2024-06-23 19:42:44.635 DEBUG (MainThread) [custom_components.wolf.time] send time 19:45:00 to ISM8 2024-06-23 19:42:53.146 DEBUG (MainThread) [custom_components.wolf.select] send dp 153: <class 'int'> 1

The Stoßlüftung Data is incoming and can be seen in the Menu on the BM-2

But nothing is happening ?

Is there anything else to do ?

[gkressel]

hi @marcschmiedchen,

Sorry for my late feedback, but I've been quite busy the last few days.

I've tested the changes to send the time/dates for the temp programs. Interestingly, I found the "Datenabruf" button, much quicker to check 😉

From my perspective, it seems there is an issue with the date format.

For example, I set the end date to June 27th, 2024, but iSM8 stores it as 2027-06-24. The same issue occurs with dates like the 28th and so on.

Could you please check that?

[marcschmiedchen]

will look into it.

[marcschmiedchen]

fixed bug, hopefully

[gkressel]

hi @marcschmiedchen ,

yes, that fixed the issue—thank you!

I ran some quick spot checks, and the date conversion worked fine. However, it seems we also have a problem with the time. The logs show the time is being sent correctly, but I'm not sure about the actual payload. The iSM8 is returning a time of 00:00.

I'll prepare some tests to check the possible combinations.

[marcschmiedchen]

Was the same problem as with the date entities. Hope everything works now....

[gkressel]

Hi @marcschmiedchen

Thank you for all your work on this.

I can confirm that the time-dependent programs “Zeitw. Intensivlüftung” and “Zeitw. Feuchteschutz” can be controlled by the integration as expected.