Lutron OH2 binding

[russell (Russell Anderson)]

How would I add then manually? Or could you point me to some documentation on it? I’m digging through it, but its a little confusing what to follow.

[jeffsf (Jeff)]

Very strange behavior with Pico remotes is present and is showing up with trying to run rules. It appears that the state transitions related to the buttons are not followed properly.

The bridge is configured and responding. The remote in question has been set up with integration ID 30, and is not associated with any lights in the Smart Bridge Pro. Configuration of the lutron:keypad and associated items are as follows:

lutron:keypad:Test_Pico "Test Pico@Jeff Office Desk" (lutron:ipbridge:SmartBridgePro) [ integrationId=30 ]

lutron:dimmer:Jeff_Office "Jeff Office@Jeff Office" (lutron:ipbridge:SmartBridgePro) [ integrationId=24 ]

(No, the above doesn’t allow the location of the keypad to be defined, just my last-ditch attempt at guessing how to use the "description" @ "location" notation)

Group group_room_Jeff_Office

Dimmer caseta_dimmer_Jeff_Office "Dimmer Jeff Office %.0f" <dimmablelight> (group_room_Jeff_Office) { channel="lutron:dimmer:Jeff_Office:lightlevel" }

Group group_pico_Test_Pico

Switch pico_Test_Pico_on "Pico Test Pico On" <switch> (group_pico_Test_Pico) { channel="lutron:keypad:Test_Pico:button2" }

Switch pico_Test_Pico_preset "Pico Test Pico Preset" <switch> (group_pico_Test_Pico) { channel="lutron:keypad:Test_Pico:button3" }

Switch pico_Test_Pico_off "Pico Test Pico Off" <switch> (group_pico_Test_Pico) { channel="lutron:keypad:Test_Pico:button4" }

Switch pico_Test_Pico_up "Pico Test Pico Up" <switch> (group_pico_Test_Pico) { channel="lutron:keypad:Test_Pico:button5" }

Switch pico_Test_Pico_down "Pico Test Pico Down" <switch> (group_pico_Test_Pico) { channel="lutron:keypad:Test_Pico:button6" }

The only rules in play are ones that should turn on the lights when I click the top button, and turn off the lights when I click the bottom button.

rule "Test_Pico_Button_On"
when
	Item pico_Test_Pico_on changed from OFF to ON
then
	sendCommand(caseta_dimmer_Jeff_Office, ON)
end

rule "Test_Pico_Button_Off"
when
	Item pico_Test_Pico_off changed from OFF to ON
then
	sendCommand(caseta_dimmer_Jeff_Office, OFF)
end

What follows in the code blocks are the outputs of tail -F /var/log/openhab2/openhab.log and tail -F /var/log/openhab2/events.log running in the background, with the terminal session running telnet into the Smart Bridge Pro. As such there may be some skew between the three, depending on how buffering is being done.

For readers not immediately familiar with the Lutron protocol, ~DEVICE,m,n,p indicates a state change in one of the devices. 30,2 is the on button, 30,4 is the off button, ,3 is key pressed and ,4 is key released.

Light is off, press on button

2017-03-12 11:23:29.341 [ItemCommandEvent          ] - Item 'pico_Test_Pico_on' received command ON
2017-03-12 11:23:29.586 [ItemCommandEvent          ] - Item 'pico_Test_Pico_on' received command OFF
2017-03-12 11:23:29.592 [ItemStateChangedEvent     ] - pico_Test_Pico_on changed from ON to OFF
~DEVICE,30,2,3
~DEVICE,30,2,4

Nothing happens. The light is still off.

Although the keypad transitioned from off (up) to on (depressed) and back to off again, there was only a single ON to OFF state change, rather than two events, OFF to ON and ON to OFF.

Light is off, press on button

2017-03-12 11:23:58.098 [ItemCommandEvent          ] - Item 'pico_Test_Pico_on' received command ON
~DEVICE,30,2,3
2017-03-12 11:23:58.104 [ItemStateChangedEvent     ] - pico_Test_Pico_on changed from OFF to ON
2017-03-12 11:23:58.127 [ItemCommandEvent          ] - Item 'caseta_dimmer_Jeff_Office' received command ON
2017-03-12 11:23:58.136 [GroupItemStateChangedEvent] - group_room_Jeff_Office changed from 0.00 to 100 through caseta_dimmer_Jeff_Office
2017-03-12 11:23:58.140 [ItemStateChangedEvent     ] - caseta_dimmer_Jeff_Office changed from 0.00 to 100
2017-03-12 11:23:58.167 [INFO ] [nding.lutron.handler.IPBridgeHandler] - Ignoring message GNET> ~OUTPUT,24,1,100.00
~OUTPUT,24,1,100.00
~DEVICE,30,2,4
2017-03-12 11:23:58.353 [ItemCommandEvent          ] - Item 'pico_Test_Pico_on' received command OFF
2017-03-12 11:23:58.356 [ItemStateChangedEvent     ] - pico_Test_Pico_on changed from ON to OFF

This time transition is seen and the dimmer is commanded to turn on, as expected.

This time, both state change events occurred, as expected, OFF to ON and ON to OFF.

Light is on, press off button

~DEVICE,30,4,3
2017-03-12 11:24:18.764 [ItemCommandEvent          ] - Item 'pico_Test_Pico_off' received command ON
~DEVICE,30,4,4
2017-03-12 11:24:18.985 [ItemCommandEvent          ] - Item 'pico_Test_Pico_off' received command OFF
2017-03-12 11:24:18.990 [ItemStateChangedEvent     ] - pico_Test_Pico_off changed from ON to OFF

Once again, nothing happens, the light is still on.

Again, there was only a single ON to OFF state change, rather than two events, OFF to ON and ON to OFF.

Light is on, press off button

2017-03-12 11:24:34.434 [ItemCommandEvent          ] - Item 'pico_Test_Pico_off' received command ON
2017-03-12 11:24:34.440 [ItemStateChangedEvent     ] - pico_Test_Pico_off changed from OFF to ON
2017-03-12 11:24:34.465 [ItemCommandEvent          ] - Item 'caseta_dimmer_Jeff_Office' received command OFF
2017-03-12 11:24:34.471 [ItemStateChangedEvent     ] - caseta_dimmer_Jeff_Office changed from 100 to 0
2017-03-12 11:24:34.471 [GroupItemStateChangedEvent] - group_room_Jeff_Office changed from 100 to 0 through caseta_dimmer_Jeff_Office
~DEVICE,30,4,3
~OUTPUT,24,1,0.00
~DEVICE,30,4,4
2017-03-12 11:24:34.678 [INFO ] [nding.lutron.handler.IPBridgeHandler] - Ignoring message GNET> ~DEVICE,30,4,4

Again, the second time, the transition is seen and the light changes state, to off.

This time, only a single state change events occurred, OFF to ON, and the binding ignored the message from the Smart Bridge Pro indicating that key-up event.

OK, so maybe the initialization of state isn’t right. By now, I’ve cycled both the dimmer and the remote and both should arguably be “in sync” with the devices, right? No, it still requires two pushes of the on or off button to see one change in state.

Maybe I’m missing something here, but this binding doesn’t appear tracking keypad button events properly at all.

[jeffsf (Jeff)]

Thanks to @actong88 and the maintainers, this has been resolved in the master branch.

Issue: [Lutron] Fails to track keypad key state and/or state-change events

This binding definitely is not functioning in a way that keypad events can be used to moderate lighting levels, at least with a Smart Bridge Pro. It might be different with the $1000 Lutron controllers, but given that they use the same protocol, I would be surprised if this the same issues did not exist there as well.

Edit – PR submitted, and there appears to be another PR on this topic (which has been accepted)

[Lutron] Ignore "extra" GNET> prompts

[Lutron] Added "GNET> " to STATUS_REGEX pattern

[actong88 (Allan Tong)]

In Paper UI, you can add things from the Inbox or from Configuration->Things. I don’t have it in front of me, but there should be a plus (+) button you click on. This may trigger an automatic search, but you can click the Add Thing Manually link, at which point you’ll be directed through a wizard to select the binding and thing type to add.

[actong88 (Allan Tong)]

@jeffsf

• Usability when trying to enter a non-trivial number of devices. With 20 dimmers and a dozen remotes, that’s over 120 individual entries that need to be made. With a one-by-one UI, that is infeasible

Besides implementing autodiscovery, I’m not sure what the binding can do about that. I’d love to implement autodiscovery for Caseta, but I don’t know of a way to do that.

@jeffsf

• Auto-naming results in unrecognizable device names for rules or UI development. Since it is the colon-notation name that needs to be used and not a human-readable name, having a “random” string in not acceptable for anything but the most trivial tasks. Even if the parent is named in Paper UI, “Button2” is not anywhere near as useful and readable as “ButtonOn” or the like.

The colon-separated names are the thing IDs, but it’s the item names that you use in rules, not the thing IDs. Items can be named whatever you want if you create the items manually, which presumably you’d have to do if you don’t want auto-generated names.

@jeffsf

• Auto-named items cannot be renamed. Goes along with the above. No way in Paper UI to be able to change the unique identifier for anything, once generated.

• Perhaps most importantly, internally managed devices can’t be accessed by Designer to create rules. Believing that a graphical UI for rules generation is usable for anything more than the simplest rules with a trivial number of devices is questionable, at best.

What documentation is missing?

• There is nothing that I can find about even the high-level syntax of the files, not to mention lower-level things like the acceptable character set and length for a given field. Archived Projects | The Eclipse Foundation describes some of how to write a binding, but not how to use one. While not specifically a problem with this binding, the lack of information about the file syntax makes it very difficult to use any binding.

These sound like issues with Paper UI and/or OpenHAB in general. The only thing I can suggest is to open issues for the appropriate subsystems. For renaming auto-generated items, I believe the usual recourse is to unlink and delete the item and recreate it manually; obviously not ideal.

@jeffsf

• I believe that it is possible to specify the channels in the same block as the thing itself. I can’t find any documentation for this, nor is there an example in the Lutron OH2 binding documentation. Being able to keep everything related with a single, physical device in one place in a single file is a key tenet of maintainability. _Note: Found again what I recalled seeing, Archived Projects | The Eclipse Foundation

The Lutron binding won’t use these custom-defined channels.

@jeffsf

• The Lutron OH2 binding does not show how to specify location, label, tag,… and there is no way that I know of to “export” internally managed devices to the file-based format to gain insight.

You can specify item location in Paper UI, but the binding doesn’t really have anything to do with that. As far as exporting things from the Paper UI database, I’m not really sure how to do that. I’d suggest opening another thread to pose that question.

@jeffsf

• There is no documentation of how to respond to or generate events for the SmartBridge Pro itself (IntegrationId 1), which generates events when a preset is “matched” and accepts events to activate a preset (represented as a button)

This is something the binding currently doesn’t handle, for Caseta or any other system.

@jeffsf

Edit – As I try again to decipher the inconsistent documentation across the OpenHAB project, I find that http://docs.openhab.org/addons/bindings/lutron/readme.html appears to “steal” the group notation from Items for a configuration parameter:

Thing lutron:dimmer:livingroom (lutron:ipbridge:radiora2) [ integrationId=8, fadeInTime=0.5, fadeOutTime=5 ]

and is inconsistent with the syntax given for a Thing on http://docs.openhab.org/configuration/things.html

Thing <binding_id>:<type_id>:<thing_id> "Label" @ "Location" [ <parameters> ]

That associates the thing to a bridge and is not anything specific to the Lutron binding. I do remember having to hunt that syntax down because its documentation does seem hard to come by.

@jeffsf

Contrary to documentation (http://docs.openhab.org/configuration/items.html for example) that states

When you install a binding through PaperUI it will automatically create a .cfg file in conf/services/ for the appropriate binding.

there is no “conf” directory to be found anywhere that has anything to do with OpenHAB:
$ sudo find / -type d -name conf
/proc/sys/net/ipv4/conf
/proc/sys/net/ipv6/conf

nor is there anything named lutron.cfg or close in or under /var/lib/openhab2

I wasn’t aware of this, and I’m not sure if that’s a binding issue, a Paper UI issue, or a stale documentation issue, but in any case, there is no binding-level configuration for the Lutron binding, so there would be nothing to configure in a .cfg file.

@jeffsf

Edit 2 - Archived Projects | The Eclipse Foundation states that

Bridges that are defined somewhere else can also be referenced in the DSL:

Thing hue:0210:mybridge:bulb (hue:bridge:mybridge) [lightId="3"]

The referenced bridge is specified in the parentheses. Please notice that the UID of the thing also contains the bridge ID as third segment. For the contained notation of things the UID will be inherited and the bridge ID is automatically taken as part of the resulting thing UID.

This, however, is also contradictory to the documentation of the Lutron binding.

Looks like you found the documentation about linking things to their bridge . I guess you’re referring to the fact that the hue thing has the bridge name in its thing ID, but that’s not present in the sample Lutron configuration? I think that’s just a convention and not strictly necessary, but I could update the documentation if it confuses things.

@jeffsf

Past this, there appears to be a parser problem with the "description" @ "location" syntax, causing the file parsing to halt without giving any error or warning in the logs. I had at first thought it a problem with the Eclipse Designer 0.8.0, as the example from http://docs.openhab.org/configuration/things.html

Thing network:device:webcam "Webcam" @ "Living Room" [ hostname="192.168.0.2", timeout="5000", ... ]

gives the reasonably meaningless error message “missing EOF at ‘@’” but I have confirmed that the "description" @ "location" notation causes failure to parse at run time.

I’d suggest opening an issue for this. This does not look like a binding issue.

[jeffsf (Jeff)]

Thanks to @steve1 in

Current and Correct Documentation of Syntax for Things and Items Needed

Go to the GitHub page for eclipse/smarthome and use the following search string: filename:.xtext That query will find all the Xtext syntax specifications for Items, Rules, Things, etc.

I’ve been able to update my scripts to output syntactically correct Things and Items for the Lutron OH2 binding. While there are gaps in the documentation, @actong88 is correct that this is not a binding issue. From what I can tell, the binding does not parse the file at all. It just “takes” the configuration values that the parser populates and uses them.

I’ve written simple Bash scripts that take tab-separated value input of the integration ID, “friendly” name, and room for the (Caseta) dimmers and remotes and create the .things and .items files from them. PM me if you’d like them.

I haven’t delved into “tags” yet, but the referenced syntax specifications make it clear how they would be added. I’m poking around with defining “phantom” channels on the dimmers to hold state information to be able to emulate the increase/decrease functionality of the dimmers and remotes. To be clear, these channels are outside of the binding’s prevue and will be managed by rules/scripts.

Here are some examples from my current configuration.

##things

###bridge

lutron:ipbridge:SmartBridgePro "Smart Bridge Pro" @ "Home" [ ipAddress="smartbridgepro.example.com", user="lutron", password="integration" ]

###dimmer

lutron:dimmer:Bedroom_East_Cans "Bedroom East Cans" (lutron:ipbridge:SmartBridgePro) @ "Bedroom" [ integrationId=2 ]

###keypad

lutron:keypad:Bedroom "Bedroom" (lutron:ipbridge:SmartBridgePro) @ "Bedroom" [ integrationId=3 ]

##items

###dimmer

Dimmer caseta_dimmer_Bedroom_East_Cans "Dimmer Bedroom East Cans [%.0f]" <dimmablelight> (group_room_Bedroom) { channel="lutron:dimmer:Bedroom_East_Cans:lightlevel" }

###switches

Group group_pico_Bedroom

Switch pico_Bedroom_on "Pico Bedroom On" <switch> (group_pico_Bedroom) { channel="lutron:keypad:Bedroom:button2" }

Switch pico_Bedroom_preset "Pico Bedroom Preset" <switch> (group_pico_Bedroom) { channel="lutron:keypad:Bedroom:button3" }

Switch pico_Bedroom_off "Pico Bedroom Off" <switch> (group_pico_Bedroom) { channel="lutron:keypad:Bedroom:button4" }

Switch pico_Bedroom_up "Pico Bedroom Up" <switch> (group_pico_Bedroom) { channel="lutron:keypad:Bedroom:button5" }

Switch pico_Bedroom_down "Pico Bedroom Down" <switch> (group_pico_Bedroom) { channel="lutron:keypad:Bedroom:button6" }

[jeffsf (Jeff)]

A Smart Bridge PRO has 100 “buttons” which correspond to the preset scenes set through the Lutron app. “Pressing” one sets the associated dimmers to their preset levels. I believe that if the Smart Bridge PRO detects that the dimmers associated with a scene have the same level as one or more scenes, then it notifies that the button(s) has (have) been “pressed” (though I’ll have to confirm that).

I’m going to try to modify the binding to make these accessible within openHAB2.

Is there a preference for 100 channels, or one channel with, for example, a set of strings that correspond to the scene names? It appears that the Lutron app won’t let you set duplicate names. The names can be changed through the app, so they are not an invariant identifier for rules, and the like.

[jeffsf (Jeff)]

If you’ve wanted to implement the up/down functionality of Pico remotes and/or Caseta/maestro dimmers, there is a patch and a PR to make the changes to support INCREASE/DECREASE/STOP for dimmers under this binding.

Tying INCREASE (or DECREASE) to button-down and STOP to button-release events mimics the behavior of Pico remote quite nicely.

[Lutron] Implement INCREASE/DECREASE/STOP for dimmers

[actong88 (Allan Tong)]

This appears related to a previous attempt to try and add support for phantom buttons (PR #1670). Note, however, that if you’re planning on simulating button pushes from within OH, that has met with resistance in the past. See the discussion here (open up the hidden comments that say Show 11 comments).

I think the gist of it is that the binding should expose scenes rather than buttons, but scenes are going to vary from installation to installation; some phantom buttons may trigger a preset scene (always set loads to preset levels), while other phantom buttons may act like a toggle (“press” once to turn a set of loads on, “press” again to turn them off). It was suggested that this be handled through custom ad-hoc channels instead of predefining channels as part of the thing-type.

[dicksteel (Rick Stahl)]

Hey Allan, thanks for your work on this binding. My RadioRA2 system is the heart of my home automation, so I’m well acquainted with the Lutron Integration protocol. However, I’m just diving into OpenHAB, so I have some pretty basic questions.

1. Is there anyway to simulate a button press through the OpenHab Keypad switch item? When I add a keypad button in the Paper UI, it correctly updates the LED status when I press the physical button, but when I press the virtual button in Paper UI, it doesn’t do anything. Is there something I can define in a .map file or .rules file to send the Lutron command to press, for example, button 1 on integration ID 27 (#DEVICE,27,1,3)?

2. Could individual keypad buttons be added as things using both the Integration ID and component - ie Integration ID 27, button1 for the top button on a keypad with ID=27? I have a Grafik Eye in my Radio RA2 system, which basically just works as a large keypad with non standard button numbers. Instead of buttons 1-6, the range is, in my system, 38-83. Or perhaps the best way to do this is in a .items file - would Switch GrafikEye38 { channel=“lutron:keypad:GrafikEye:button38” } define a valid item/ channel? This would also allow me to use the phantom buttons on my main Repeater (Integration ID=1, components = 1 to 100, plus LEDs 101-200).

As you noted above, there appears to be some resistance to simulating button presses, but as I’ve already defined all of my scenes using the RadioRA2 software, it makes more sense to keep it that way, and use OpenHab to press phantom/ physical buttons.

[jeffsf (Jeff)]

I’m using a Smart Bridge PRO, but at least there when I use Switch Items (see my previous post for my file-based config) for Pico remotes an openHAB event is generated on both press and release. Where the Pico is configured with the Lutron app, the corresponding action is taken without openHAB intervention. I can also trigger openHAB actions through rules, either or both on button-down and -up.

openHAB, for better or worse, abstracts things to a very fine-grained level. That your bridge’s configuration or innate behavior is apparently to update the LEDs, openHAB sees them as independent. You can emulate the behavior in rules.

I’m not sure what you’re trying to achieve in (2). In openHAB you need a Thing to represent the physical device, then one or more Items to access the state and/or send commands to the predefined Channels of the Thing. Sounds wacky at first, OK, still, but you need a Thing for a keypad that creates individual Channels for all its buttons and LED. Then you need Items for each button or LED you what state information from or to command. I generate all of these with some shell scripts as the “simple mode” creates opaque Item names, making rules close to unreadable.

There isn’t a great way to improve this naming, especially when the friendly name of “ID 27” can be changed through consumer apps and a Thing or Item name needs to be a unique identifier in openHAB. It’s further complicated in that I’m not aware of an officially documented way to get the mapping from integration ID to friendly name from the Smart Bridge series through direct access to the bridge.

[actong88 (Allan Tong)]

@dicksteel

1. Is there anyway to simulate a button press through the OpenHab Keypad switch item? When I add a keypad button in the Paper UI, it correctly updates the LED status when I press the physical button, but when I press the virtual button in Paper UI, it doesn’t do anything. Is there something I can define in a .map file or .rules file to send the Lutron command to press, for example, button 1 on integration ID 27 (device,27,1,3)?

Unfortunately no. A workaround might be to have an OH rule do everything that the native keypad button does (assuming OH can do everything that the keypad button is doing), but of course this means defining and maintaining your scene twice.

Edit: just saw Jeff’s reply. With (1), I was assuming you’re trying to have OH “send” a button press to RadioRA2. The binding should be able to respond to physical button presses coming from RadioRA2.

@dicksteel

2. Could individual keypad buttons be added as things using both the Integration ID and component - ie Integration ID 27, button1 for the top button on a keypad with ID=27? I have a Grafik Eye in my Radio RA2 system, which basically just works as a large keypad with non standard button numbers. Instead of buttons 1-6, the range is, in my system, 38-83. Or perhaps the best way to do this is in a .items file - would Switch GrafikEye38 { channel=“lutron:keypad:GrafikEye:button38” } define a valid item/ channel? This would also allow me to use the phantom buttons on my main Repeater (Integration ID=1, components = 1 to 100, plus LEDs 101-200).

It doesn’t work that way. The current keypad handler has a fixed set of buttons it handles. We probably need to define a new thing type for the Grafik Eye.

[jeffsf (Jeff)]

Thanks for the reference to the discussion. I tend to agree that the action should be “activate scene” and not “push button” and perhaps a “query scene” action as well.

I looked at both the LIP and LEAP interfaces on my Smart Bridge PRO and neither reported that a “matching” scene had also been activated. (They both reported that the requested scene was activated.) As can’t see what the app queries or received over what I believe to be secure MQTT, I can only guess that it queries to update itself and its widget.

Scenes are certainly lower on my priority list than emulating the up/down action across groups, but I’ll keep thinking about it.

[dicksteel (Rick Stahl)]

Ultimately what I’m trying to achieve in (2) is to activate a fan that is controlled with a contact closure on a VCRX (Visor Control Receiver). I have my RadioRA2 system set up with two toggle buttons on my GrafikEye, one for on/off (Integration ID 27, Component Number 77), the second for speed high/low (Integration ID 27, Component Number 83).

In my current automation software, I define a ‘Thing’ with Integration ID 27, Component Number 77 that sends the Button Press Command. When I press the button on my virtual remote, it sends (#DEVICE,27,3) to the Main Repeater.

[jeffsf (Jeff)]

It sounds from @actong88 that the current GrafikEye binding Thing doesn’t support the buttons that you need to attach an Item to. openHAB, for many bindings hides away the communication layer, so you can’t just “attach to ID 27, component 77” unless the binding already knows about that button and has crated a Channel connected to it.

If you need it immediately, you might be able to use one of the TCP bindings to directly communicate with the bridge. I’m only as familiar with the GrafikEye as reading the Lutron Integration Protocol document provided. With what looks like 150 or so DEVICE targets it might need a subtly different strategy.

[dicksteel (Rick Stahl)]

Thanks for the fast reply Allan.

@actong88

Unfortunately no. A workaround might be to have an OH rule do everything that the native keypad button does (assuming OH can do everything that the keypad button is doing), but of course this means defining and maintaining your scene twice.

I’d prefer to keep my scenes on the RadioRA2 main repeater - it has gone 5 years without a crash and just works. I worry that if all of my scenes live in OpenHab on my Raspberry Pi, I will come home to dead keypads if the Pi crashes and be unable to turn my lights on. I’m also not a big fan of duplication; rebuilding all the scenes already in my RA2 repeater in OpenHab seems wasteful.

Perhaps talking about simulating a button press is the wrong way to sell this functionality - the physical button simply sends a device command. It would be nice to have a switch in OpenHab that could also send this command, no different than how a Maestro Dimmer Thing in your binding sends a output command to the main repeater.

@actong88

It doesn’t work that way. The current keypad handler has a fixed set of buttons it handles. We probably need to define a new thing type for the Grafik Eye.

I can provide my RR2 integration report if that would help. I’m in the process of teaching myself Java, but am very new to object oriented programming. When I get up to speed I would like to help contribute or maintain - as I know that my specific RR2 installation with a GrafikEye and a VCRX is not common.

If I may make an observation and suggestion for ‘custom’ keypads - it appears in your current keypad handler the only variable the user (or DbXmlInfo.xml used during autodiscovery) provides is the Integration ID, while

1. the number of channels
2. channel ID
3. channel names
   are constants that are assumed to be Component = Button1, Component Number =1, etc. Perhaps if these were variables you could have a dynamic keypad that could cover any and all RA2 keypads?

I know the button names aren’t easily accessible if you download DbXmlInfo.xml from the main repeater, but if the user has the integration report csv, it would be easy to use this file to generate keypads and buttons in a .things and .items file with meaningful names, as @jeffsf has already done with Bash scripts.

[dicksteel (Rick Stahl)]

@jeffsf

If you need it immediately, you might be able to use one of the TCP bindings to directly communicate with the bridge.

That’s a great suggestion Jeff. I’ll give that a try.

As an aside, I can’t figure out how to send a PM - I’d like to use your Bash script to parse my integration report. Though it appears the RR2 report is a csv, vs the SmartBridgePro outputting tab-seperated values.

[jeffsf (Jeff)]

I wish it parsed the JSON integration report, or the LEAP version, which is even more extensive. Alas, it’s eyeball-and-finger parsing.

The whole Item vs. Thing thing is a bit confusing at first, and I still mix the two up. Where you likely want the human-readable stuff is on the Item – that’s what the rules and UI render, not the Things that represent the physical devices.

As soon as I get some things going here, I’m going to poke around with ways to trigger and query scenes on the bridge. I’m with you on having the reliability of a commercial or semi-commercial unit maintaining the presets and able to control them when something happens to openHAB or its host. I also like the ability to set and control the scenes through the app. It seems much better than having 20 Items per scene to hold the preset levels, then all the UI around setting it, and…

[jeffsf (Jeff)]

Binding and/or Smart Bridge PRO hangs, associated with high command rate

Anyone else seen anything like this?

I’ve got a Pico that has a pair of rules that sends one command to a group of dimmers on depress, and another when the same button is released.

If I use the dimmer_group_name.sendCommand() approach, the button-up event isn’t seen for 10-20 seconds after it physically occurs (which was likely ~250 ms after it was pressed, based on other logging). Watching the openHAB event log and using ngrep (or tcpdump) to monitor the telnet connection, they are at least all self-consistent.

If I iterate through the group members myself and put a 100-ms delay between commands (as suggested by the LIP documentation), things work as expected.

[actong88 (Allan Tong)]

I haven’t noticed any significant delays (I have both RadioRA2 and a Smart Bridge PRO), but then again I’m not using OH groups.