Unknown zwave device: Fibaro Walli Rollershutter Switch

Hardware Home Automation
,
1

In addition to the Walli Dimmer, which seems to be known in the 2.5 snapshot binding, Fibaro has released a rollershutter switch, which I did not find on the list (https://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list/devices).

The device has been imported into my zwave network and OpenHAB discovered the Thing, but shows it as unknown - and I failed in creating a functional item by linking to the deviceID with channel “command” (still an OpenHAB rookie I am :wink: ). Commands are sent according to the log, but nothing happens.

2019-07-28 21:51:01.590 [ome.event.ItemCommandEvent] - Item ‘SchlafziRollladen’ received command DOWN

2019-07-28 21:51:01.598 [nt.ItemStatePredictedEvent] - SchlafziRollladen predicted to become NULL

I can provide all discovered information on the device, if that helps to update the device database. Or is this device already known and in the works?

To make it work meanwhile, would it possibly work by manually creating or linking the Thing to FGRM222 instead, if that is possible?

Thanks in advance and best regards
- Natanael

2

Nah I think you misunderstood that somewhat.
Assuming you aren’t the first person to have a brand new Fibaro device or new version thereof, you should be able to find your device/firmware version mentioned in the list you mention.
But all devices must properly initialize before you can see and link their channels to items.
It is very common at least for battery operated devices that it takes a couple of wakeup actions to finalize initialization but it can be the cases for mains operated devices, too.
Try clicking the B button once or three times. Have ZWave debugging enabled then you should see the messages,

3

Hi Markus,

well, more than 24 hours after first contact, the Thing is still labeled as unknown device, but all raw information is present (so it is fully initialized, I guess) - same situation as yesterday.

I did remove the thing, the node’s XML file in /var/lib/openhab/zwave and restartet the inclusion with debug logging enabled:

2019-07-29 20:10:44.111 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing ‘zwave:device:cd9cecab:node2’ to inbox.

2019-07-29 20:10:44.120 [DEBUG] [wave.discovery.ZWaveDiscoveryService] - NODE 3: Device discovery completed

2019-07-29 20:10:44.132 [WARN ] [wave.discovery.ZWaveDiscoveryService] - NODE 3: Device discovery could not resolve to a thingType! 010F:1D01:1000::5.0

==> /var/log/openhab2/events.log <==

2019-07-29 20:10:44.152 [home.event.InboxAddedEvent] - Discovery Result with UID ‘zwave:device:cd9cecab:node3’ has been added.

==> /var/log/openhab2/openhab.log <==

2019-07-29 20:10:44.151 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing ‘zwave:device:cd9cecab:node3’ to inbox.

[…]

2019-07-29 20:11:12.166 [DEBUG] [ve.internal.protocol.ZWaveController] - Incoming Message: Message: class=AddNodeToNetwork[74], type=Request[0], dest=6, callback=139, payload=8B 06 03 00

2019-07-29 20:11:12.169 [DEBUG] [ol.serialmessage.AddNodeMessageClass] - Add Node: Done.

2019-07-29 20:11:12.172 [DEBUG] [wave.discovery.ZWaveDiscoveryService] - NODE 3: Device discovered

2019-07-29 20:11:12.181 [DEBUG] [al.protocol.ZWaveInclusionController] - Inclusion event: Current state IncludeDone, new event IncludeDone

2019-07-29 20:11:12.184 [DEBUG] [ol.serialmessage.AddNodeMessageClass] - Ending INCLUSION mode.

Adding the Thing from Inbox then:

2019-07-29 20:17:38.362 [hingStatusInfoChangedEvent] - ‘zwave:device:cd9cecab:node3’ changed from UNINITIALIZED to INITIALIZING

==> /var/log/openhab2/openhab.log <==

2019-07-29 20:17:38.363 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - Initializing ZWave thing handler zwave:device:cd9cecab:node3.

2019-07-29 20:17:38.380 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: MANUFACTURER not set

==> /var/log/openhab2/events.log <==

2019-07-29 20:17:38.383 [hingStatusInfoChangedEvent] - ‘zwave:device:cd9cecab:node3’ changed from INITIALIZING to OFFLINE (BRIDGE_OFFLINE): Controller is offline

==> /var/log/openhab2/openhab.log <==

2019-07-29 20:17:38.389 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Controller status changed to ONLINE.

2019-07-29 20:17:38.393 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Controller is ONLINE. Starting device initialisation.

==> /var/log/openhab2/events.log <==

2019-07-29 20:17:38.402 [hingStatusInfoChangedEvent] - ‘zwave:device:cd9cecab:node3’ changed from OFFLINE (BRIDGE_OFFLINE): Controller is offline to ONLINE

==> /var/log/openhab2/openhab.log <==

2019-07-29 20:17:38.492 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Updating node properties.

==> /var/log/openhab2/events.log <==

2019-07-29 20:17:38.493 [me.event.ThingUpdatedEvent] - Thing ‘zwave:device:cd9cecab:node3’ has been updated.

==> /var/log/openhab2/openhab.log <==

2019-07-29 20:17:38.494 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Updating node properties. MAN=271

2019-07-29 20:17:38.496 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Updating node properties. MAN=271. SET. Was null

2019-07-29 20:17:38.499 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Properties synchronised

2019-07-29 20:17:38.558 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Configuration synchronised

==> /var/log/openhab2/events.log <==

2019-07-29 20:17:38.559 [me.event.ThingUpdatedEvent] - Thing ‘zwave:device:cd9cecab:node3’ has been updated.

==> /var/log/openhab2/openhab.log <==

2019-07-29 20:17:38.616 [DEBUG] [ve.internal.protocol.ZWaveController] - Event listener added.

==> /var/log/openhab2/events.log <==

2019-07-29 20:17:38.617 [me.event.ThingUpdatedEvent] - Thing ‘zwave:device:cd9cecab:node3’ has been updated.

==> /var/log/openhab2/openhab.log <==

2019-07-29 20:17:38.618 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Initialising Thing Node…

2019-07-29 20:17:38.620 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Polling intialised at 1800 seconds - start in 1481400 milliseconds.

2019-07-29 20:17:38.622 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Device initialisation complete.

I’m back at my initial question, I think. :wink:

4

These IDs are not in the database so will need to be added.

https://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-database-guide

ps. when posting logs, please use code fences so they are more readable :wink:

5

You didn’t mention that in the first place.
So you indeed are the first trying to use this device.
Please add it to @chris database as explained here. Get the .xml file it generated and upload it.
(I see @chris is replying, too …)

PS: and use code fences please.

6

The explicit message “could not resolve to a thingType” was new with debug logging, so that helped.

Will upload the XML.

And thanks for pointing me to code fences, I missed the pre-formatted icon right beside the quote icon I used. :roll_eyes:

7

Device has been created in @chris database, manual and image uploaded. I am not overly sure with the additional missing information (what should be put in inclusion/exclusion information?), so I stopped there.

@chris, what makes me wonder is the information I already saw in the properties in PaperUI:

Supports Security: No

While the manufacturer information says:

Supports Z-Wave network Security Modes: S0 with AES-128 encryption and S2 Authenticated with PRNG-based encryption.

The device seems to report differently than the manufacturer tells us?

8

Don’t worry about this message - if security is supported, and you have enabled it in the controller, then it will be used. This line is not really related to the use of the security command class.

1 Like
9

Hi all,

I will soon need to buy 4 roller shutter controllers and till now I was considering to get the Fibaro Rollershutter 3 that with the snapshot version of the zwave database seems to work. Now I see the Walli that could be a better option as will include controller and buttons in one. I was wondering if @natanael managed to have it working and successfully controlled your blinds.
Thanks

10

Rethink if you really want buttons. It’s rather outdated to have switches on every window. You will be prgramming the behavior in OH and only rarely use switches if at all… BTW: you can attach any traditional switch or button to the FGRM as well.

11

If I tell my wife I remove every physical button I am dead :rofl:

On a serious note, I feel better to have also physical buttons to close the blinds and the Walli looks nice. Three of the shutters are actually in front of doors to the garden and it seems handy to have the control next to it to go out.
Now that I think about it I also need to make sure I can turn off the Walli ring of light.

12

Which is another solution and it comes at no cost !:innocent:
Worth a thought though: Wallis are twice as expensive as FGRMs, and you likely have traditional buttons in place already if your wife insists on having them.
On that same serious note, you need not to abandon all buttons. You can have some to remain (one per room or per floor), and/or you can get a remote to do direct zwave to the FGRM or a group of these. Will work even if OH is down.
This is what my wife is happy with (well plus I have door sensors so if someone opens a door, the blinds in front of that are raised automatically).

1 Like
13

Thanks, you have valid reasoning. I’m still thinking but in any case I’d first need to figure out if the Walli already works with OH, otherwise the choice is easy.
This will also sound weird but I don’t know yet if there are buttons already installed: we bought the new flat on the floor plan and we asked for no blinds (cause we will install ourself) but predisposition for motors and buttons, not sure if this means just the cabling and sockets or includes the actual buttons too.
Btw I fully agree with you on using remotes, personally I use the Fibaro keyfob that I love and works like charm with OH, yet I feel that having a control next to the window can come handy; remotes have the special skill to hide very well when you need them.

14

Sorry for the delay.

With OH2.5.0 Walli works fine, thanks to someone who added it and all detail to Chris’ database. :wink:

I rarely use the button, though. It is not on par with the prior physical installation with regard to build quality as well. It looks decent, but feels cheap. If you have buttons in place, I would opt for the roller shutter 3. Got that for the next roller and kept the buttons as is. Only be sure to have enough space for installation!

15

Welcome back from the future. :wink:
As of now 2.5.0 has not yet been released. 2.5M3 is the latest testing version. What binding version works or will work based on your experience in the future?

16

you have ONE free guess :wink:
No button also means no need for a box and no extra cabling.
I’d prepare for cabling at least in bedrooms though, else it can become expensive: I recently added motorized blinds to a window of mine so I had to get power over there first. It all ended with paying the painter for redecorating the whole room :expressionless:
If you have prepared for a box next to the window you can also start with a FGRM (+remote) and no buttons, then “upgrade” to a Walli or add switches only if that gets you into danger of death.

1 Like
17

Hehe, yes, I was referring to 2.5M2, I think, which I installed by switching to the Testing repository some weeks ago. Did not check version of binding then, sorry, it just was there. If needed, I can look something up when home again, let me know.

@francesco: Regarding the ring of light of Walli: it can be fully customized through advanced parameters from within OH. So it can be disabled as well.

18

So it should still work on the latest 2.5M3.
I am glad you enjoyed my attempt at humor. :wink:

19

Thanks @natanael for the good info. It actually seems a better option to go with the RollerShutter 3, I just need to make sure it comes with the new firmware or it’s a bummer to update it.
@mstormi :rofl:

Thanks for your good ideas, I guess you guys made me save a couple of hundred euros that come handy while furnishing a flat from scratch:)
I’ll let you know how it ends.
Cheers

1 Like
20

Hello everybody,

I am having very similar issues as those posted here be Natanael, with a Fibaro Walli Switch (not the rollershutter one). The device shows up as “unknown device”, but with a tag revealing the device type id ‘1B01:1000’. Fed into Chris´ supported device database this leads to this device. According to the database this device is supported with any firmware version, mine is 5.0. According to the database the device name is FGWDSEU. My switch came with a label saying FGWDSEU-221. Not sure whether this is relevant.

I’m on openHAB 2.4.

I have already tried to exclude, factory reset and include the switch multiple times, without success. Question is, why does the switch show up as unknown device? Can anybody point me in the right direction to solve this?

This is what I get in HABmin after inclusion:

image
image.png1069×773 75.3 KB