Set the RequestActionResponseLimit State Variable

I am querying a URL site for weather data, unstringifying the data into a table and then extracting the data I want. All is fine if I request just the current weather. When I request the 7 day forecast, the size of the data goes to +3000 bytes. In the reactor documentation it states that the RequestActionResponseLimit state variable can be changed. I am thinking 4096 should work. My questions:

  1. I do not see the state variable in question in the Reactor Device Advance->Variable tab nor do I see it in the Reactor Root Advanced->Variable tab. Where is this state variable?
  2. What is the format to create and change this variable from 2048 to 4096? Do I use the luup.variable_set? And what what is the format?

Go to the ReactorSensor’s control panel, Advanced > New service

New service: urn:toggledbits-com:serviceId:ReactorSensor

New variable: RequestActionResponseLimit

New value: 4096

Also if you look at the event log in the Logic Summary (Tools tab) of the ReactorSensor after making a request, it will tell you exactly how big a request the server was attempting to return. That takes a little guess-work out of the process.

OK, I performed the above instructions on the ReactorSensor not on the Root. I now have a variable under the ReactorSensor variable table called RequestActionResponseLimit and it is set to 4096.
I look in the log and the return data is 3621 bytes but it is still being truncated to 2048.

Did you copy-paste the service ID and variable name, or retype it…? Number one cause of problems is typos, especially in the service ID (even for me)…

One way to check if it sees the new variable: run a Logic Summary in the Tools tab of that ReactorSensor, and there will be a section called “Special Configuration”. You should find that variable there with the value you set.

Everything is now working. No laughing.
Instead of cutting and pasting from your instructions, I cut and pasted from the ReactorSensor device_type param → urn:schemas-toggledbits-com:device:ReactorSensor:1, thinking that was what you meant. This did create the variable RequestActionResponseLimit in the variable list and gave it a value of 4096, but it was not in the Special Condition section of the log.
AFTER I followed your instructions EXACTLY, I now have two variables called RequestActionResponseLimit each with a value of 4096. And it is now in the Special Condition section.

Sooooo, good lesson learned, follow your instructions exactly.

As an aside, what did I do when I used the device_type string in the New Service field? it seems to have created a variable of the correct name and value, but it doesn’t seem to do anything.

It’s so finicky that way, honestly, you have my sympathies. This is what we deal with constantly. I don’t know about the rest of the developers, but my day isn’t complete without fat-fingering a service ID or doing something else to create a variable with an incorrect service ID, and then nothing works as expected (famously when I code before the 2nd cup of morning coffee).

The key here, of course, is that variables on Vera aren’t identified by name. They are identified by service ID and name together, and that makes a unique key to the value. If either is wrong, no soup for you. This is also why it’s possible to have two or more variables listed with the same name: their services are different, and therefore they are, in the eyes of Luup, different variables.

All good. You’ve done nothing I haven’t done a million times. The miscreant variable is harmless; it will just sit there and be ignored for the life of the device, or your Vera. If, however, you choose to get rid of it (which may be a good idea just to make the variable list accurate):

luup.variable_set( "urn:schemas-toggledbits-com:device:ReactorSensor:1",
    "RequestActionResponseLimit", nil, RS-DEVICE-NUMBER)
luup.reload()

And while that’s working, do a hard refresh of your browser (very important).

Thanks and I love your reference to one of my favorite episodes of Seinfeld.

1 Like