Lutron Grafik Eye QS

I'm trying to get my Grafik Eye QS to work. I created a Lutron Telnet driver, put in all the required info, and created a light with integration ID 14. I then checked the "Grafik Eye QS?" button in the driver. When I try to turn the light on, it throws an error. The debug log shows that it sends the command "#output,14,1,100,1". This would be correct for RA2, but for QS Standalone it should be sending a #device command. If I type "#device,2~1,1,14,100" in the Send Msg box in the Lutron Telnet driver, and send it, it turns on. ("2~1" is the name the interface gave my GE QS when I tried to name it "2". Not sure why.) Sending "#device,2~1,1,14,0" turns it off. These commands also work when I connect to it directly via telnet.

It looks like the command is being formatted incorrectly by the driver. Can anyone help me?

-Tom

What kind of device is this with ID 14?

#output is a valid command for QS. #device is for keypad-like commands and #output is for dimmer-like commands. See pages 85 through 88: https://www.lutron.com/TechnicalDocumentLibrary/040249.pdf

You probably should create this with the Lutron Integration app, not by hand. Remove what you have, and try that. That will create the Lutron Telnet device. After you hit Done in the Lutron Integration app, open the Lutron Telnet device and select Grafik Eye QS, and be sure to hit Save Preferences.

Then test again, and report what happens.

Sorry, the integration ID of 14 was me being confused with another GE QS that I'm working with on another automation platform. But please help me understand this:

On telnet, I can get the light to turn on by issuing this command:
#device,2~1,1,14,100

According to the Lutron protocol doc you referenced, the first field (2~1) is the Integration ID of the GE QS, as created by me on the NWK interface. The second field (1) is the unit # (zone 1). The third field (14) is the command to set the level (sorry I had this confused before). The last field is the level, which could have been followed by more fields for fade-in and delay.

The output commands don't have a unit number. I think that's because RA2 automatically creates Integration IDs for every unit of every GE QS it connects to. The footnotes and my telnet experiments suggest that to turn on zones, you use #device on QS standalone (i.e., NWK) and #output on RA2. Do I have that wrong?

Also, I did delete everything, and started over with the Lutron integration app. I created a device of type Dimmer and integrationid of 1. It still doesn't work. I'll try 2~1 next.

-Tom

Are you sure it doesn't assign integration id's to the QS loads? RA2 does create a separate integration ID for each GE QS load, so I'm surprised you don't have that. Check the integration report.

In your example, you are commanding load #1 of the GE QS (1 of 24 possible). If it had an integration ID of say 22, then #output,22,1,100 would turn it on.

If it doesn't have integration IDs for each load, then our drivers won't command it. We could come up with one that would command it fairly easily. We have other QS customers, and this never came up before.

Are the other customers using the NWK interface? Probably not. But if you know of one, please connect us if you can so I can learn how to make it work. I might write to wkearney99.

QS standalone, which this interface is built for, allows you to string several devices (including multiple GE QS's) on the QS bus. Each one needs its own integration ID.

The QS bus is disabled when you use a GE QS in RA2. At least that's my understanding. My guess is that RA2 assigns IDs to every zone on each unit as they are added wirelessly, so you only need one # to specify a zone.

-Tom

OK, so without IDs per zone, we would have to do a special driver for this, and a separate integration app so that the combination of integration ID with Zone number becomes a unique device in Hubitat. Otherwise, there is no way to use zones as devices.

See PM I just sent you.

I use this integration, in the NWK you need to create output devices, this will give each output across your installation it’s own integration ID. IE the NWK will maintain a list of output devices mapped to QS devices and zones, Grafik eye, Power Savr can all be added.

It’s an integrationid command, page 21 of version AG integration protocol doc.

1 Like

Thanks to @bravenel and @barry.ward I've been able to get my GE QS non-wireless to work with Hubitat! Many thanks to both.

The only remaining niggle is that my unit appears to return the level of zones with a wierd scale - 100% is returned as 0.39. The returned value is linear; that is, 50% is 0.19 and so on. When Hubitat receives this value, it thinks the light is off since it's so close to zero, so the status returned by Hubitat is "off" even though it's on.

I've been able to work around this by using the #monitoring command. I set both event and zone monitoring to 2, which disables their monitoring. With those changes Hubitat reports the status correctly. However, it has the unfortunate side effect that changes made manually with the GE buttons or by IR remote don't cause the Hubitat to update its status.

So, I'm looking for insight and others' experiences. Have you seen the same thing? I suspect that it's due to a quirk of my GE unit.

-Tom

In the monitoring/debug logs what is your QS sending to hubitat when you control a load. You could also do this just by telnetting to the NWK and using the other user.

Unfortunately, it sends back the 0.39 that Tom describes. First it sends back 100 like it should, but then shortly later the monitoring aspect sends that wonky value. There is no way a Lutron device should send 0.39 as response to setting a light to 100.

We thought about potentially catching this in the Lutron Dimmer driver, and mapping the 0,39 to 100, using a preference to say, this is a flaky GE QS device that needs help.

Hence, Tom's post above.

Wow, I’ve never seen or heard that before. I’m guessing the units aren’t covered by warranty? Is the QS firmware reasonably current, have we tried factory resetting the NWK and starting again?

Sorry, been away for a while because...thanks to bravenel, it's working!

My non-J version Grafik Eye (that's why I can't use it with RR2, which I also own) and my QSE-CI -NWK were both purchased used, so I think warranty is out of the question. And I haven't heard of or seen any way I can DIY a firmware upgrade for either, so here we are. I'd love to upgrade the GE especially, since the firmware I have is REALLY old and doesn't support any sensor inputs other than the built-in OCC, which blew a hole in my plans to use the QSE-IO and the QS Sensor Module with it,

I'm still not sure if this 0.39 = 100 reporting is standard for that combo, or if one or both of them could be "fixed" with a firmware upgrade. But I'm happy for now. Except my Hubitat keeps hanging every few days. I've worked around it by power-cycling nightly with an automated outlet controlled by another home automation platform, but that's another thread for another subforum.

-Tom

Please don't do this; it is a recipe for database corruption. Either do an automated reboot on your hubitat using a Rule or an app, or you can use the community and Hubitat support to figure out why your hub "hangs" every few days,

1 Like

Thanks for the lead. I installed the app today and set it up to reboot at 3:00 a.m. Sundays.

When my system hangs it becomes unpingable, and therefore probably unreachable for soft rebooting or troubleshooting. The LED is solid green.

If the autoreboot works well enough, I may never put in the effort to find the root cause. I don't really have the time. Hubitat is not my primary platform. I'm using it for the Lutron features in conjunction with a nodeserver for the ISY, which is my primary platform. I have a lot of Insteon.

-Tom