Aeotec Wallmote - Button Controller - Lutron Dimmer Problems

🚧 Developers Broken-code
1

Experiencing a couple problems (related in my use case, but likely independent).

Issue 1:

Aeotec Wallmote joined to hub. Functions as expected, detects button presses and holds. When changing preferences: turn off Enable touch and Enable vibrate. Save. Then press configure. The device does not seem to take the new preferences.

Issue 2:
while ignoring beeping, using button controller button 1 is configured to set dimmers by mode. 100% day, 50% evening, 20% night. When button 1 is pressed logging shows:

Wallmote shows: button 1 pressed.

master bedroom lights shows:
dev:3272018-03-30 18:55:48.977:errorCould not find which method setLevel() to invoke from this list: public java.lang.Object lutronDimmer#setLevel(java.lang.Object) public java.lang.Object lutronDimmer#setLevel(java.lang.Object, java.lang.Object) on line null

lutron telnet shows:
NOTHING

when I setup a rule machine rule triggered off button 2 pressed and set dimmers through rule by mode it functions correctly. It appears the set level command in button controller varies from rule machines method.

2

it has to be awake first, tap the button on the back to wake it up, then hit configure.

Tagging @bravenel on this aspect...

3

thanks on the configure. i had done that too, but turns out must hold it for 3 seconds.

5

You get the prize for finding a bug in Button Controller! Indeed, setLevel for dimmer-per-mode has a bug. Will be fixed for next release.

Thanks!

6

I really hope the prize is a pony :slight_smile:

4 Likes
7

After Secure Pairing, button presses are not detected. A (2nd) WallMote paired unsecure works as expected. I’ve put the secure one aside for now in the hopes I’ve found a bug and it gets fixed AND I can test. :slight_smile:

the following log messages are about all I can think to offer this morning:

dev:2742018-04-15 08:57:07.689:debugignore SecurityMessageEncapsulation(commandByte:[238, 0, 1], commandClassIdentifier:91, commandIdentifier:3, secondFrame:false, sequenceCounter:0, sequenced:false)
dev:2742018-04-15 08:57:07.684:debugparse: zw device: 28, command: 9881, payload: 00 5B 03 EE 00 01

deviceType: 258
zwaveSecurePairingComplete: true
inClusters: 0x5E,0x85,0x59,0x8E,0x60,0x86,0x70,0x72,0x5A,0x73,0x84,0x80,0x5B,0x71,0x98,0x7A
outClusters: 0x25,0x26
deviceId: 130
manufacturer: 134

[normal one below]

deviceType: 258
inClusters: 0x5E,0x85,0x59,0x8E,0x60,0x86,0x70,0x72,0x5A,0x73,0x84,0x80,0x5B,0x71,0x7A
outClusters: 0x25,0x26
deviceId: 130
manufacturer: 134
8

The wall mote drivers do not support secure pairing, there is a ton of overhead involved in secure communications, and no value add in using secure communication for a button controller.

1 Like
9

Thanks, and double thanks for a Sunday reply :smiley:

1 Like
10

I guess I can see the lack of value for non-relaying button controller, but I'm curious about the desire to avoid "overhead"... the secure pairing process is the same for all Z-Wave devices. Wouldn't this be encapsulated in your Z-Wave library? Why would it need support on a device by device basis? @mike.maxwell

11

Pairing is one thing, operation is another, secure operation for zwave requires three times the number of frames to get the job done, so its slower and carries more overhead.

12

Do you use telnet to login to your services, or SSH? SSH requires considerable more load on the node than telnet does... by your logic, shouldn't you be using Telnet?

I assume you use SSH because you have made an intelligent choice about the cost of SSH versus the security risk involved with not using it, right?

Hubitat is an entirely local thing, right? So these extra frames are not impacting your services, they are extra packets on the wire within my house, right? This is a cost borne only by me, within my own household, correct?

So why is Hubitat the company so invested in us running our own homes insecurely? @mike.maxwell

In particular, I have at least two individuals within Z-Wave range of my home who have the tools at their disposal to hack my Z-Wave. (We are friends and have tested each other's homes for vulnerabilities) However there are numerous others within range who I may not know, or may not be friendly to me. While it may not be a "security" problem for them to trigger my lights or anything else on and off, it's not something I want to allow. The technology exists to protect against these hacks. I don't understand why you don't want to support the Z-Wave security model.

Caveat that it ties up resources on the hub, in the air, sure. But let the person make their own choices!

13

Where did you get that impression?, no staff member has ever said that, if you want S0 security on all your devices then go for it, no one's stopping you.

14

I got that impression from your words rejecting the addition of secure pairing to a driver:

15

Based on the comments in the other S2 thread, I believe his stance is that if you don't support full S2 then it is bad/too insecure.

16

That reference was specifically regarding the wall mote...
And the version i had for development didnt support this anyway.
We include S0 support for any devices that support it.

17

That's good to hear. I apologize for misunderstanding. When you indicated that the drivers didn't support it (drivers you develop, right?) and then made a statement about no value in doing it that appeared to be a judgment call on your part about supporting it.

The device not supporting it is completely different, and not a judgment call on your part.

18

I'm fairly certain I don't lack the ability to speak for myself :rofl:

If S0 is what can be provided today I want that. It changes "can walk up to my house and unlock my door with widely available tools" to "must wait around for a key exchange to occur" which reduces the risk profile.