QuickApp (http:get read value)

[moltos 4]

Hi Guys,

 

getting crazy and i dont find the solution for that.
I want to read a value via HTTP and write it to a value in my script to use it in other functions.

But i don´t get the value out of my HTTP request or as return out of my function. Maybe someone can help.

 

    dPower = http:request("http://10.1.1.123/meter/0/power", {

                options={

                headers = {Accept = "application/json"},

                checkCertificate = true,

                method = 'GET'

                        },

            success = function(response) 

                local data = json.decode(response.data)

                local power = data.power

                self:debug(data.power)

            end,

            error = function(error)

            self:debug('error: ' .. json.encode(error))

            end

    })

 

The value is received and extracted to power, but i cannot use is outside of my http request. Additional to that "dPower" is emopty.

 

Thanks for lighten me up.

[tinman 1,028]

you trying to decode it directly, try vice very json.encode and check the the debug output, just to ensure you really getting something useful back

[moltos 4]

Within the http request i receive the data as expect, but the received data is not available outside.

self:debug print the value as expected, but the local power does not contain a value outside of the request.

 

[tinman 1,028]

8 minutes ago, moltos said:

Within the http request i receive the data as expect, but the received data is not available outside.

self:debug print the value as expected, but the local power does not contain a value outside of the request.

 

 

sure, the local power is within the success, in which you can call another function as callback or continue with whatever you wish, within the "success" part of your code. 

[SmartHomeEddy 888]

In my P1 Monitor QuickApp I publish the power consumption in a unused device. That way I can use the standard Fibaro functions to do whatever I want. You could also use a child device if you don’t have a unused device. 

[moltos 4]

8 minutes ago, tinman said:

 

sure, the local power is within the success, in which you can call another function as callback or continue with whatever you wish, within the "success" part of your code. 

 

Hmm, 
means i can trigger a function and handover the value to that, but it is not possible to give back a value to the http:request itself.

I wondering all the time why everything feels blown up in complexity for more or less simple tasks.

 

These nesting of functions i normally try to prevent.

 

In my case it will be then:

 

checkState -> getPower -> checkState

 

2 functions get will receive the HTTP data and send over to checkState then to work with and compare the values.

I will give it a try, but .... you know ... all this work to compare ONE value.

 

 

[tinman 1,028]

i think you misunderstood something, check the examples 

Please login or register to see this link.

 

[jgab 2,122]

Yes, http:request() doesn't return the value (dPower) in your case. ( It seems to be a recurring issue on this forum )

Instead when the request has succeeded (sometimes a http request can take some time to complete - depending on how busy the server is), it will call your 'success' function if everything worked out and your 'error' function if not.

The reason for this is that the rest of the QA shouldn't need to stop and wait for the http requests to complete. When the QA stops and waits, pressing buttons etc doesn't work for your QA. Now the QA can continue to do what it needs to do and when the http request is finished it will call your callback functions.

 

This means that you need to structure your program differently.

Please login or register to see this code.

 

[moltos 4]

16 hours ago, jgab said:

Yes, http:request() doesn't return the value (dPower) in your case. ( It seems to be a recurring issue on this forum )

Instead when the request has succeeded (sometimes a http request can take some time to complete - depending on how busy the server is), it will call your 'success' function if everything worked out and your 'error' function if not.

The reason for this is that the rest of the QA shouldn't need to stop and wait for the http requests to complete. When the QA stops and waits, pressing buttons etc doesn't work for your QA. Now the QA can continue to do what it needs to do and when the http request is finished it will call your callback functions.

 

 

Thanks for this insights.