FlyingDiver / Indigo-radiora2

Indigo plugin for Lutron control systems. Works with Radio Ra 2, Radio Ra Select, Homeworks QS, and Caséta
MIT License
6 stars 3 forks source link

LED state not updating with Beta 3 #11

Closed rapamatic closed 6 years ago

rapamatic commented 6 years ago

For some reason the LED state of keypads (and also when the box is checked, that translating into button state) is not updating. I do see the LED status messages show up in the debugging log, but the status isn't changed in indigo, and none of my former triggers based on button presses are working...

rapamatic commented 6 years ago

I need to do some tests. This is caused by either/both:

1) the beta 3 plugin 2) LEDs (set to control button status) on tabletop keypads

When I reverted to the prior plugin code and disabled those LEDs, everything went back to normal.

I haven’t had a chance to look, but I suspect there is some implicit expectation that the LEDs will be in the range of 81-87 somewhere in the monitoring code that is causing this problem. I do note that I had these LEDs disabled in indigo before, so I suspect this issue may have been in prior releases also (so not something that changed with the latest beta)

FlyingDiver commented 6 years ago

Ok, there's two bugs here. One is in the new code, where I changed the internal key format for the keypad buttons. Keypad 25, button 3 used to be '253', now it's '25.3' to match the external address. That's an easy fix.

The second bug is in the original code, where it's converting the key for an LED (2583, for example) to the button key (253). It's doing it by just removing the 8. Which breaks a tabletop keypad because it might need to go from 2594 to 2514. I'll have that fixed soon.

rapamatic commented 6 years ago

The second bug makes sense, that's what I figured was happening as I was thinking about the problem while in the shower (where I do all my best thinking).

I don't understand the first bug - is the issue that not all of the code is expecting the new dot seperated notation? I would agree with you that it probably makes more sense to use a dot or some other separator (maybe even an array), especially as dual-repeater systems can have IDs above 100? (Is that the case? I am still only on a single repeater system)...

FlyingDiver commented 6 years ago

The external address (visible in the Indigo UI) used the dot notation for keypads, etc. Internally, it was using a non-dot version as a key in a dictionary. I changed that to always use dot notation. Just because I wanted them to match. That way I could use the external address for the key rather than building the key on the fly. But I hadn't fixed all the places it used the key yet.

Phantom buttons now have the Integration ID for the repeater prefixed to them. So you'll see buttons like 1.100, 1.101, etc. My second repeater has an Integration ID of 13, so I also have phantom buttons 13.100, 13.101, etc.

FlyingDiver commented 6 years ago

Fixed in next release.