Philips RWL021 does not work since update to v2.27.0

[Rolf56]

Does the issue really belong here?

• I definitively want to report a bug within deCONZ or its REST-API

Is there already an existing issue for this?

• I have searched the existing issues and there is none for the bug at hand

Describe the bug

This is almost the same issue as we had with versions v2.19.0-beta and v2.19.1 what I opend under #6461. It was fixed, but with v2.27.0 it occures again!
I already tried to reconnect the devices, this works an the deveces sends battery state and so on, but no button state (for example 4002)

Steps to reproduce the behavior

by pressing a button, the LED on the Dimmschalter lights up red, somtimes green or yellow.

Expected behavior

state should change, what not happen.

Screenshots

No response

Environment

• Host system: PC
• Running method: Windows
• Firmware version: 26400500
• deCONZ version (not Home assistant Addon version!): v2.27.0
• Device: ConBee I
• Do you use an USB extension cable: no
• Is there any other USB or serial devices connected to the host system? no

deCONZ Logs

15:02:07:278 [INFO] - No button map for: RWL021, broadcast to: 0x0014, endpoint: 0x01, cluster: ONOFF (0x0006), command: ON (0x01), payload: None, zclSeq: 202
15:02:07:310 0x00158D0003CBE818: update ZCL value 0x01/0x000C/0x0055 after 0 s
15:02:07:313 [INFO] - No button map for: lumi.relay.c2acn01, unicast to: 0x0000, endpoint: 0x01, cluster: 0x000C, command: 0x0A, payload: 55003900BDE73C, zclSeq: 91
15:02:07:315 payload: 55003900bde73c
15:02:07:317 don't create binding for attribute reporting of sensor lumi.relay.c2acn01
15:02:07:319 don't create binding for attribute reporting of sensor lumi.relay.c2acn01
15:02:07:358 [INFO] - No button map for: RWL021, unicast to: 0x0000, endpoint: 0x02, cluster: 0xFC00, command: 0x00, payload: 0100003000210000, zclSeq: 201
15:02:07:470 [INFO] - No button map for: RWL021, unicast to: 0x0000, endpoint: 0x02, cluster: 0xFC00, command: 0x00, payload: 0100003002210100, zclSeq: 203
15:02:07:584 [INFO] - No button map for: lumi.relay.c2acn01, unicast to: 0x0000, endpoint: 0x01, cluster: 0x000A, command: 0x00, payload: 0000, zclSeq: 122

Additional context

No response

[Rolf56]

[Smanar]

The device have stoped to use DDF ?
This is handled by JS code in DDF, and you haven't the "DDF" in the node title.

If you make right clic then "edit DDF" do you have this one https://github.com/dresden-elektronik/deconz-rest-plugin/blob/master/devices/philips/rwl02_dimmer_switch.json on the DDF editor ?

Perhaps similar too #7775

[manup]

Hmm that's odd, I've checked with my test Hue dimmers, here the DDFs are assigned fine, on both Linux and Windows.

@Rolf56 what was the previous deCONZ version from which you have updated?

[fffe]

I have what looks like the same issue.

RWL021 working on 2.26.3, broken after update to 2.27.0, working again after rolling back to 2.26.3.

I did not attempt to debug, I just rolled back.

[Rolf56]

The file "rwl02_dimmer_switch.json" is in directory "C:\Program Files (x86)\deCONZ\devices\philips".
Previous version was 2.26.3

When trying to open file with the DDF-Editor following message is shown

When trying to edit DDF of other of my devices, by right click to Edit DDF, there all epmty.

[Smanar]

The file "rwl02_dimmer_switch.json" is in directory "C:\Program Files (x86)\deCONZ\devices\philips".

I m checking both path, but it's the same used by the editor ? (with the error message)
Can you try running deconz in admin mode ?

[Rolf56]

when opening the DDF Editor it shows the searching path "C:\Users\FHEM\AppData\Local\dresden-elektronik\deCONZ\devices"

I copied the folder "philips" to the above path and opened the file, following error message is shown

It is all the same , when I start deConz as Administrator. I also checked all permissions for the deCONZ folders and files. Everthing looks good.

[manup]

Oha opening a DDF JSON in the editor is a regression in v2.27.0 will be fixed soon.
However the DDFs should be loaded on startup anyway and assigned to matching devices.

Do any of your devices show the "DDF" label on the top right of the node?

I installed deCONZ as user and also as admin on my Windows setup to check if the paths could be a problem, but here it works just fine. I don't really understand what is the difference to your setup yet 🤔

[fffe]

I don't think this is Windows-specific or a permission issue, I'm seeing the same thing on Linux in the "deconz-community" docker container.

[Rolf56]

there are no DDF labels at all

I thinks issue #7775 has the same problem! It uses a Raspberry system.

[Rolf56]

There is no difference after installation of v2.27.1.

Still no DDF labels on devices.

and still the same INFO_L2

but by starting DDF editor, there are values in there now!

[manup]

Hi @Rolf56 after some testing another bug was found which hopefully is also the cause of trouble in your setup (but unclear since in your setup no DDFs at all were loaded).

Can you please try version v2.27.2-beta http://deconz.dresden-elektronik.de/win/deCONZ_Setup_Win32_V2_27_02.exe

[Rolf56]

Hi Manuel, thank you for your support. I have installed version v2.27.2-beta but I see no difference.
Is there a way to start debug view at program start and could the load of the DDF made shown there?

[manup]

Damn hoped that would also catch your issue.

• In Windows Explorer navigate to the directory containing deCONZ.exe
• Here Shift-Right click on the empty space
• From the context menu select Open Powershell
• Enter the following command

./deCONZ.exe --dbg-info --dbg-ddf=1

The Debug view should then show logs from the start.

[Rolf56]

The loading phase is not in the log, here the result from logs:

21:05:47:398 update ddf lumi.switch.n2aeu1 index 3
21:05:48:507 update ddf lumi.switch.n2aeu1 index 3
21:05:57:445 update ddf HK-ZD-RGB-A index 12
21:05:57:445 update ddf HK-ZD-RGB-A index 12
21:05:57:445 update ddf HK-ZD-RGB-A index 12
21:05:57:742 update ddf HK-ZD-RGB-A index 12
21:06:12:445 update ddf lumi.switch.n2aeu1 index 3
21:06:13:179 update ddf lumi.switch.n2aeu1 index 3
21:06:17:445 update ddf TRADFRI control outlet index 15
21:06:17:445 update ddf TRADFRI control outlet index 15
21:06:17:445 update ddf TRADFRI control outlet index 15
21:06:18:414 update ddf TRADFRI control outlet index 15
21:06:19:866 update ddf TRADFRI control outlet index 15
21:06:29:476 update ddf TRADFRI bulb E27 W opal 1000lm index 13
21:06:29:476 update ddf TRADFRI bulb E27 W opal 1000lm index 13
21:06:29:476 update ddf TRADFRI bulb E27 W opal 1000lm index 13
21:06:33:179 update ddf TRADFRI control outlet index 15
21:06:35:414 update ddf TRADFRI bulb E27 W opal 1000lm index 13
21:06:38:632 update ddf TRADFRI bulb E27 W opal 1000lm index 13
21:06:40:086 update ddf TRADFRI bulb E27 W opal 1000lm index 13
21:06:50:570 update ddf TRADFRI Driver 30W index 17
21:06:50:570 update ddf TRADFRI Driver 30W index 17
21:06:50:570 update ddf TRADFRI Driver 30W index 17
21:06:51:414 update ddf TRADFRI Driver 30W index 17
21:06:55:570 update ddf CCT Lighting index 19
21:06:55:570 update ddf CCT Lighting index 19
21:06:55:570 update ddf CCT Lighting index 19
21:06:55:742 update ddf TRADFRI Driver 30W index 17
21:07:00:210 update ddf TRADFRI Driver 30W index 17
21:07:00:601 update ddf TRADFRI bulb E27 W opal 1000lm index 13
21:07:00:601 update ddf TRADFRI bulb E27 W opal 1000lm index 13
21:07:00:601 update ddf TRADFRI bulb E27 W opal 1000lm index 13
21:07:02:492 update ddf CCT Lighting index 19
21:07:11:695 update ddf CCT Lighting index 19
21:07:13:929 update ddf CCT Lighting index 19
21:07:17:195 update ddf TRADFRI bulb E27 W opal 1000lm index 13
21:07:17:851 update ddf TRADFRI bulb E27 W opal 1000lm index 13
21:07:35:695 update ddf TRADFRI bulb E27 W opal 1000lm index 13
21:07:35:695 update ddf TRADFRI bulb E27 W opal 1000lm index 13
21:07:35:695 update ddf TRADFRI bulb E27 W opal 1000lm index 13
21:07:35:851 update ddf TRADFRI bulb E27 W opal 1000lm index 13
21:07:36:195 update ddf TRADFRI bulb E27 W opal 1000lm index 13
21:07:50:726 update ddf lumi.switch.n2aeu1 index 3
21:07:51:523 update ddf lumi.switch.n2aeu1 index 3
21:08:05:726 update ddf J1 (5502) index 2
21:08:25:726 update ddf TRADFRI transformer 30W index 18
21:08:25:726 update ddf TRADFRI transformer 30W index 18
21:08:25:726 update ddf TRADFRI transformer 30W index 18
21:08:25:882 update ddf TRADFRI transformer 30W index 18
21:08:26:258 update ddf TRADFRI transformer 30W index 18
21:08:26:601 update ddf TRADFRI transformer 30W index 18
21:08:35:726 update ddf TRADFRI control outlet index 15
21:08:35:726 update ddf TRADFRI control outlet index 15
21:08:35:726 update ddf TRADFRI control outlet index 15
21:08:36:711 update ddf TRADFRI control outlet index 15
21:08:43:898 update ddf TRADFRI control outlet index 15
21:08:45:242 update ddf TRADFRI control outlet index 15
21:08:45:726 update ddf J1 (5502) index 2
21:08:47:523 update ddf J1 (5502) index 2
21:08:50:726 update ddf lumi.switch.n2aeu1 index 3
21:08:51:601 update ddf lumi.switch.n2aeu1 index 3
21:09:09:226 DDF power_configuration.cpp:206: b4:e3:f9:ff:fe:af:13:c6-01-1000 updated ZCL function cl: 0x0001, at: 0x0021, eval: Item.val = Attr.val

[manup]

Hmm that looks like only the Draft DDFs are updated which are created when the existing ones aren't found. 🤔
Also unfortunately the log is cut off, perhaps the Widget doesn't show as many lines.

To get the full log can you please download and start DebugView from Microsoft, it's a small log viewer utility showing everything deCONZ prints out.

https://learn.microsoft.com/de-de/sysinternals/downloads/debugview

Then please try the following:

Open a Powershell Window in C:\Program Files (x86)\deCONZ\bin

./deCONZ.exe --dbg-info=1 --dbg-ddf=1 --dbg-error=1 --ddf-root="C:/Program Files (x86)/deCONZ/devices"

The DebugView tool should now show a whole bunch more lines.

Note I appended --ddf-root parameter to force deCONZ loading DDFs from there (which is normally done automatically).

[Rolf56]

Here the output file of DebugView

FHEM.LOG

[manup]

Thanks a lot, this gives much more insight now.
So the logs show that the actual DDFs are found on disk and parsed. However they aren't assigned to the devices

00000025 18.77589035 [7212] 08:50:12:431 DDF identifier pair: LUMI | lumi.weather
...
00014071 18.81687737 [7212] 08:50:26:097 DDF manufacturername: $MF_LUMI
00014072 18.81687737 [7212] 08:50:26:097 DDF modelid: lumi.weather
00014073 18.81687737 [7212] 08:50:26:097 DDF product: Aqara Temperature and Humidity Sensor WSDCGQ11LM
...
00015374 18.82062912 [7212] 08:50:26:777 loaded 1 DDFs
...
00015441 18.94724083 [7212] 08:50:28:943 DEV no DDF for 0x00158D000273A352, modelId: lumi.weather
00015442 18.94724083 [7212] 08:50:28:944 DEV create on-the-fly DDF for 0x00158D000273A352
...

Sorry I have to bother you a bit more with creating logs since your setup is the only remaining one showing the load issue.
I have cleaned up and enhanced the DDF load logging to see better what is going.

Can you please repeat the DebugView step for a new log with attached version

deCONZ_Setup_Win32_V2_27_02_3e93eb.zip

[Rolf56]

here the log file for above version

FHEM.LOG

[manup]

17:10:07:438 DDF failed to create SHA-256 hash of DDF

Oh that's interesting, your system might not have MS vcruntime140 installed.
(Since the hash function fails, that indicates that the OpenSSL library can't be loaded, which depends on this Windows runtime)

It can be downloaded from: https://www.microsoft.com/de-de/download/details.aspx?id=48145

[Rolf56]

installing of MS vcruntime140 did not help. I tried it with a newer version found in: https://learn.microsoft.com/de-de/cpp/windows/latest-supported-vc-redist?view=msvc-170 file: https://aka.ms/vs/17/release/vc_redist.x64.exe but this does not help too.
I also restarted the PC.

FHEM.LOG

Do you have any ideas how to test the environment to see OpenSSL works?
When I start openssl in powershell I get an answer:

but don't know how to carry on

[manup]

In deCONZ you can see if the library can be loaded via Help → About deCONZ

If it loads ok it should display OpenSSL: 1.1.1

I'll prepare a Version tomorrow which doesn't depend on OpenSSL for the hashing, but it's still strange.

[aryelevin]

I have the same issue on macOS with v2.27.2 (since 2.27.0) and when I restart the app it work for a while and then later it stops.
I do see DDF emblem on the remotes devices on the GUI.
I have additional deCONZ (on the same machine - macOS and same version) instance which I have few remotes as well and no issues at all, weird.

[manup]

I do see DDF emblem on the remotes devices on the GUI.

In that case it is different from the problem here, in @Rolf56 setup DDFs aren't loaded at all since somehow the SHA-256 hashing function used internally from OpenSSL doesn't load. Here a workaround is being made currently to not depend on OpenSSL for this.

[manup]

@Rolf56 here is a version which doesn't depend on OpenSSL for loading DDFs.

Can you please give it a try: deCONZ_Setup_Win32_V2_27_02_5f8d1d.zip

[Rolf56]

In deCONZ you can see if the library can be loaded via Help → About deCONZ

If it loads ok it should display OpenSSL: 1.1.1

I'll prepare a Version tomorrow which doesn't depend on OpenSSL for the hashing, but it's still strange.

looks like the OpenSSL files can't be opend. I test the new version, without OpenSSL now.

[Rolf56]

This version looks pretty good! I got some DDF labels as expcted

and both Philips RWL021 are functioning!

I took a log again, maybe you want to check if everithing works as designed.
FHEM.LOG

Mani thanks for your support!

[manup]

Ha nice thanks again for testing, this was a tricky one to debug.
I still need to track down why OpenSSL dooesn't load correctly, but that's for another issue.

@aryelevin I'm closing this issue for now, and suggest to make a new one for the macOS case to not mix up too many things.

[Mimiix]

Ha nice thanks again for testing, this was a tricky one to debug. I still need to track down why OpenSSL dooesn't load correctly, but that's for another issue.

@aryelevin I'm closing this issue for now, and suggest to make a new one for the macOS case to not mix up too many things.

Is there a PR comming after this to get it in the codebase?

[manup]

Ha nice thanks again for testing, this was a tricky one to debug. I still need to track down why OpenSSL dooesn't load correctly, but that's for another issue.
@aryelevin I'm closing this issue for now, and suggest to make a new one for the macOS case to not mix up too many things.

Is there a PR comming after this to get it in the codebase?

The code for the test versions above is already merged in dresden-elektronik/deconz-lib@aedf77f and will be available in v2.27.3-beta