FIBARO Walli Double Switch (FGWDSEU-221) does not change the color via Rule

[fd0cwp (ChrisP)]

Hi all,

I hope I give you enough information as this is my first post.

I use openHABian version 3.4.1 on a Raspberry Pi 4.

I have a problem with three (I only have three) FIBARO Walli Double Switches (FGWDSEU-221) having already the latest firmware version 5.2. In general, they work well.
I want to use the light ring to indicate the automation status for the room. Therefore, I try to change the color, and also reduce the brightness in the night. But this is not working at all or at least very late or even randomly.

I use a sendCommand and postUpdate call without an effect.

I_Lichtschalter_Schlafzimmer_LEDColor.sendCommand(LEDColorCode_Green)
I_Lichtschalter_Schlafzimmer_LEDColor.postUpdate(LEDColorCode_Green)

I_Lichtschalter_Schlafzimmer_LEDColor is a number item and is linked to the “LED frame Color ON-state (config_decimal_param11 (Number))” and to the “LED frame Color OFF-state (config_decimal_param12 (Number))” channels, so it shall always show the desired color independent on the state of the switches (relays).
LEDColorCode_Green is defined in this way:

val LEDColorCode_Green = 3

Also, when I change the switch (to hopefully force an update of the color), there is no effect:

	I_Lichtschalter_Schlafzimmer_2.postUpdate(ON)
	I_Lichtschalter_Schlafzimmer_2.sendCommand(ON)
	I_Lichtschalter_Schlafzimmer_2.postUpdate(OFF)
	I_Lichtschalter_Schlafzimmer_2.sendCommand(OFF)

Nevertheless, the logfile states that (here the brightness) was changed, even though it wasn’t visible on the device:

2023-05-19 23:18:19.920 [INFO ] [openhab.event.ItemCommandEvent ] - Item ‘I_Lichtschalter_Schlafzimmer_LEDBrightness’ received command 1
2023-05-19 23:18:19.928 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item ‘I_Lichtschalter_Schlafzimmer_LEDBrightness’ predicted to become 1
2023-05-19 23:18:19.937 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item ‘I_Lichtschalter_Schlafzimmer_LEDBrightness’ changed from 50 to 1

I also tried to “Reinitialise the device” via the openHAB UI, but this has also no effect.

In the openHAB UI of the Thing configuration, the color for ON and OFF had different values (3/0). When I changed them and Save the configuration, it has also no effect.

A re-start of the RPi does also bring no improvement.

I searched for solutions but didn’t find anything so far.
Maybe someone from the community can help me?
If you need more information or have some hints I could try out, please let me know.
Thank you in advance!

Best regards, Christoph

[anon71759204]

Welcome to the community!

At first glance, your actions and the device definition in the Z-Wave database look reasonable.

Is parameter #13 set to 100?

Rule of thumb:
If setting parameter #11-#13 via UI doesn’t work, it will not work via rules.

Please follow the debug instructions and post an unfiltered log of setting parameters #11-#13 via UI.

The manual does not specify when changed parameters take effect. Sure, the implicit assumption is “at once” - but who knows?

[fd0cwp (ChrisP)]

Thank you for your quick reply!

Parameter #13 is set to 50 and #11 and #12 to 2 (red – which I use for indicating automatic mode) which is most probably set by my rule.
But this is not reflected on the device. 50% brightness might be correct, but it shows blue (which I use to indicate the manual mode).

I will post the unfiltered log later. I have to see how to produce it.

However, do I have to obey something when I change the value from an item which is linked to a channel, but which is also available as a parameter?

[stefan.hoehn (Stefan Höhn)]

I remember that I myself actually added that channel back then and it does work on my side (I just tested it). Here is my setup and this is what I do.

I use that simple blockly rule to set the frame to red:

which relates to the following code:

events.sendCommand(‘AZEingangSwitchFrameColor’, 2);

The setup for the item is

(note that the state white is before I triggered the rule. White = 1, Red = 2, …)

You can manually set this on the thing by setting the following parameters:

(the channel is just sending the value to that param 11)

So, try setting the value manually first to see if it changes the color.

Note that you can even let it toggle between colors easily

but it takes about 1-2 seconds until the LED ring changes its color.

[anon71759204]

@fd0cwp

However, do I have to obey something when I change the value from an item which is linked to a channel, but which is also available as a parameter?

I don’t think so - see @stefan.hoehn’s post.

You could check the health of your Z-Wave network:

The last four items should be 0 (or very low in relation to the two first items).

Check the Z-Wave network map for neighbors of your DUT:

The lower the number of edges to a particular node, the lower the probability that the Z-Wave controller can reliably control the node.

[fd0cwp (ChrisP)]

Thank you both for your input!

Unfortunately, I cannot provide the debug log as I am struggeling logging into the console:

C:\Users\Chris>ssh openhab@openhabian -p 8101
Password authentication
Password:
Password authentication
Password:
Password authentication
Password:
openhab@openhabian’s password:
Permission denied, please try again.
openhab@openhabian’s password:
Permission denied, please try again.
openhab@openhabian’s password:
openhab@openhabian: Permission denied (keyboard-interactive,password,publickey).

I am trying the default password (habopen), and the one I set. No success.

When I am using

C:\Users\Chris>ssh openhabian@openhabian
openhabian@openhabian:~ $ openhab-cli console
Logging in as openhab
Password:
Password:
No more authentication methods available

It also does not work.
Also these versions do not succeed:

openhab-cli console -u openhabian
sudo openhab-cli console -u openhabian
sudo openhab-cli console

I am a Windows user, so I might miss basic knowledge here.

As I only now added items for the Z-Wave-Status, most of the ones which shall be low are still NULL. But I will keep an eye on it:

I think the network map looks quite good in general:

The device I am testing on is #31. But according to the map, it has only a direct connection to the controller, not from the controller to the Walli:

The other Walli (#3) has no direct connection to the controller, even it is nearer to the controller than other devices:

And the third Walli (#32) is not shown at all.

So it might be again an issue with my Z-Wave-Network instead of the Walli devices?
I have a heal time active at 1AM. I heard this might also make troubles sometimes.

Tomorrow, I will check how I can set the log level in another way.

[Wolfgang_S]

@fd0cwp

I am trying the default password (habopen), and the one I set. No success.

How did you change the password for the openhab karaf console ?
What does the command

grep openhab /var/lib/openhab/etc/users.properties

exeuted on the Pi in a linux shell return ?

[apella12 (Bob Eckhoff)]

@fd0cwp

I am struggeling logging into the console

I use putty, but tried what I think you were doing from a windows command window
SSH 192.168.0.156 -l openhabian -p 22 Substitute your Rpi IP

seemed to work. Then enter you openhabian password. You can get to the console from there

[fd0cwp (ChrisP)]

I used the config tool (sudo openhabian-config) :

In the following dialog, I changed the given password.

The command call you provided returns the standard password:

openhabian@openhabian:~ $ grep openhab /var/lib/openhab/etc/users.properties
openhab = habopen,g:admingroup

So, I tried to login once more from the Windows cmd using ssh openhab@openhabian -p 8101and the default password, but as before without success.

[fd0cwp (ChrisP)]

For me, using SSH 192.168.0.156 -l openhabian -p 22 is the same as using ssh openhabian@openhabian. Logging in into this console is no problem.
But how can I open the (other/Karaf?) console via port 8101? Using openhab-cli console asks for a password and neither of mine (also not the default habopen) works.

If this is all the same console (what I do not think to be the case), I have maybe another problem because the command cannot be found:

openhabian@openhabian:~ $ log:set DEBUG org.openhab.binding.zwave
-bash: log:set: Kommando nicht gefunden.

I know that one can also edit the log4j2.xml file directly. I found it in my Windows file explorer at \\openhabian\openHAB-userdata\etc\log4j2.xml, but I am not allowed to edit it from my Windows system.
On the Pi, I do not find the file at all. This shows again my missing understanding of the Linux / Unix / whatever system.

Edit:
OK, now I found the file with the find command and edited the file with the nano editor. Sometimes, ChatGPT tells the truth and is helpful.
I will try to provide the debug log soon.

Edit 2:
OK, I managed to create a debug log file.
OMG! I thought there are only a few messages sent. But it seems that there is so much traffic.
Because of the size, you can find the log file here: openhab_abDebug.log - Google Drive
Short description what I did:

• brightness was set to 100 according to the openHAB configuration page (probably it was set by a rule which I do e.g. when the day starts)
• but no light was visible on the Walli (probably it was at 1 which I set by a rule e.g. for the night)
• I set the brightness (parameter #13) to 99 on the configuration page and saved it at about 12:52
• in the log file, it starts at 12:52:01.704
• the configuration update starts at 12:52:01.723
• I let the debug mode active for some more minutes
• in this time frame, the light was not visible

Is there anything else you need for the analyzation?

Thank you all for your help so far! That’s very great!

Edit 3:
I had another look at the network map. Now, all three Wallis are shown, but all of them only show a direct connection to the controller, not from the controller to the Wallis.

[apella12 (Bob Eckhoff)]

A couple of things to consider

1. Is a change from 100 to 99 going to be noticeable?
2. I think the activity on your network is a contributing factor. Note this set of messages at the time of your change.

2023-05-21 12:52:01.726 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 31: Command Class COMMAND_CLASS_CONFIGURATION is NOT required to be secured
2023-05-21 12:52:01.727 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 31: Adding to device queue
2023-05-21 12:52:01.728 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 31: Added 155642 to queue - size 54
2023-05-21 12:52:01.729 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 1 out at start. Holdoff false.
2023-05-21 12:52:01.730 [DEBUG] [class.ZWaveConfigurationCommandClass] - NODE 31: Creating new message for application command CONFIGURATIONCMD_GET
2023-05-21 12:52:01.731 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 31: SECURITY NOT required on COMMAND_CLASS_CONFIGURATION
2023-05-21 12:52:01.732 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 31: Command Class COMMAND_CLASS_CONFIGURATION is NOT required to be secured
2023-05-21 12:52:01.732 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 31: Adding to device queue
2023-05-21 12:52:01.733 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 31: Transaction already in queue - removed original
2023-05-21 12:52:01.734 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 31: Added 155643 to queue - size 54
2023-05-21 12:52:01.735 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 1 out at start. Holdoff false.
2023-05-21 12:52:01.735 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 31: Configuration pending added for config_13_1

a) your change is added to the queue with 54 waiting messages
b) config changes are low priority. I could not find in the rest of the log where the message was sent (Could be wrong, only did a quick drive-by)

3. I’d say your network is holding up well under the stress, but do you really needed to poll your blinds every minute? Also it looks like node 31, as well as other nodes report electric use every thirty seconds (and mostly report 0 watts). How are you using that data. Bottom line I think if you reduce all this, the queue will get under control and the configuration change will happen quickly and be observable.

[Wolfgang_S]

You may try the verbose mode to check if there is debug output that gives an indication why you cannot connect:

ssh -vvv openhab@openhabian -p 8101

[anon71759204]

@apella12

Could be wrong, only did a quick drive-by

No, you aren’t wrong - not a single transmission from the Z-Wave controller to node 31 within the timespan covered by the log.

@fd0cwp

1. As @apella12 pointed out: reduce polling.
2. Use the openHAB log viewer (default port 9001) and filter for Node 31: Sending to make sure that there is any communication at all from the Z-Wave controller to node 31.

[fd0cwp (ChrisP)]

According to @apella12 and @anon71759204 I went through all Z-Wave things and set the polling time to 600 were it was set to a lower value. The default value of 86400 seems VERY high for me. But maybe I shall even increase the number of 600?

I also disabled Reporting to Controller (paramter #80 set to 0) for the blinds controls for now.
Edit: The shutter went down half way but I received only 98% as an update. So I activate parameter #80 again.

I have to observe it a little bit, but on a first glance, the issues with the Wallis seem to be gone.
Thank you all for your great help!

I most probably set the polling time to a low value because I had issues with getting the correct values for the temperature and shutter position in time. So I have to see if I have to enable parameter #80 of the roller blinds controls again. Or if I have to solve those issues in another way. At least, setting the polling time to a low value is obviously not the way to go.

@Wolfgang_S: Please find the logfile attached:
Karaf Console Login Error.txt (12.9 KB)
There are a lot of errors but I assume this is just because those methods are not used. For the password issue, I do not see any problems.

[apella12 (Bob Eckhoff)]

@fd0cwp

The default value of 86400 seems VERY high for me. But maybe I shall even increase the number of 600?

86400 should be fine. What you are probably running into is the Command poll at 1500 msec. You could search the forum for “autoupdate”. Say you set the blinds to 50%. Autoupdate will update the state briefly to 50% in OH, but in 1.5 seconds the command poll will run. For slow moving things like dimmers and blinds, the device will report where it is at the 1.5 second mark (likely not yet to 50%). There are two options; raise the command poll time (by trial and error) until it is long enough to report the “right” value after a command or disable the command poll and let the autoupdate value stick. Polling every 10 minutes is a problematic way to get the “right” value because the value isn’t going to change unless you issue another command, so there is a lot of extra traffic to bog things down.

Glad the wallis appear better.

[fd0cwp (ChrisP)]

After reducing the polling frequency of all Z-Wave devices (I now use at least 3600 seconds), I faced an issue with the QUBINO Flush 1 Relay (ZMNHAD1). I use this device like the Wallis as some kind of light switch.
Switching the light on or off took ages unless it was reflected in openHAB. Okay, probably it took only some minutes until the polling took place. So, I enabled the debugging log again and had a look at the output. There, I realized that I used the wrong channel. Instead of switch_binary, I have to use switch_binary1. After updating the item link to the correct channel, it works excellent.

The debugging log is really a great help!

I still have to observe if the roller blinds work as desired. If not, I will check what @apella12 wrote regarding autoupdate.

Thank you all again for your great support!