Jump to content

Welcome to Smart Home Forum by FIBARO

Dear Guest,

 

as you can notice parts of Smart Home Forum by FIBARO is not available for you. You have to register in order to view all content and post in our community. Don't worry! Registration is a simple free process that requires minimal information for you to sign up. Become a part of of Smart Home Forum by FIBARO by creating an account.

 

As a member you can:

  •     Start new topics and reply to others
  •     Follow topics and users to get email updates
  •     Get your own profile page and make new friends
  •     Send personal messages
  •     ... and learn a lot about our system!

 

Regards,

Smart Home Forum by FIBARO Team


SDK for remote and offline HC3 development


jgab

Recommended Posts

  • Topic Author
  • I thought it may be an issue with the path name "Backup(...)

    but this works for me

    Please login or register to see this code.

     

    Link to comment
    Share on other sites

    @jgab

    While trying to get refresh state I receive constantly same response

    Please login or register to see this spoiler.

     

     

    Link to comment
    Share on other sites

  • Topic Author
  • 1 hour ago, cag014 said:

    @jgab

    While trying to get refresh state I receive constantly same response

    Please login or register to see this spoiler.

     

    Because if there are no events you may get a response with no events. In that case last is not updated.

    It's consistent with the behaviour on the HC3 - but it depends on the timeout setting. The HC3 has a longer timeout, in the emulator you get the response immediately. 

    See the recent discussion in the French forum here 

    Please login or register to see this link.

    If there is no state.events or #state.events==0 you just ignore the result and make another refreshStates request.

    Something like:

     

    Please login or register to see this code.

     

    Edited by jgab
    Link to comment
    Share on other sites

    That's exactly what I'm doing... but no proper response received.

    The only difference that I use IP

    Please login or register to see this code.

     

    Edited by cag014
    Link to comment
    Share on other sites

  • Topic Author
  • 14 minutes ago, cag014 said:

    That's exactly what I'm doing... but no proper response received.

    The only difference that I use IP

    Please login or register to see this code.

     

    What is 10.0.0.198 ?

    In any case,  the emulator let that request through so what you see is the response from 10.0.0.198...

    If you call 127.0.0.1 it's intercepted by the emulator.

    Link to comment
    Share on other sites

    10.0.0.198 is the IP of HC3

    Yet, i don't receive any response. Same code works with HTTPAsyncClient in v0.158

    Any suggestions?

     

    Link to comment
    Share on other sites

  • Topic Author
  • 14 minutes ago, cag014 said:

    10.0.0.198 is the IP of HC3

    Yet, i don't receive any response. Same code works with HTTPAsyncClient in v0.158

    Any suggestions?

     

    Can you show more of your code?

    Link to comment
    Share on other sites

    Have tried to set http debug - nothing happened

    Please login or register to see this code.

    Have strange feeling that something wrong with self.xxx usage between your and mine codes

    Link to comment
    Share on other sites

    here the HTTP - since the idea to be able to scan several controllers jSlave table in use with same parameters as your credentials.

      net.HTTPClient({timeout=600,sync=false}):request('http://'..jSlave[i].ip..'/api/refreshStates?last=' .. jSlave[i].last.."&logs=false",

            {options={method = 'GET',

              headers={["Content-Type"]="application/json;charset=UTF-8",["Accept"]="application/json",

                 ["Authorization"]="Basic "..jSlave[i].access}},

            success = function(response)

              print(json.encode(response))

    ...

     

    Edited by cag014
    Link to comment
    Share on other sites

    Found the cause, while

    poll=false

    No response at all and no http debug data.

    Setting poll to true everything works including http debug data

    How I can define not to poll the HC3 for triggers?

     

    Edited by cag014
    Link to comment
    Share on other sites

    Sorry, my bad.

    Still no response , I just see incoming triggers as recorded by you

    Link to comment
    Share on other sites

  • Topic Author
  • 18 minutes ago, cag014 said:

    Sorry, my bad.

    Still no response , I just see incoming triggers as recorded by you

    My bad. Try v.0.302 that I just pushed.

    Edited by jgab
    • Thanks 1
    Link to comment
    Share on other sites

    5 hours ago, jgab said:

    My bad. Try v.0.302 that I just pushed.

    Great... it's working

    Thank you

    Link to comment
    Share on other sites

    Have something strange... will try to explain best I can

    Since AOR designed to support several controllers, I'm querying for refreshState with timeout  (600 mSec), so in case if no activity the query should be stopped and no data should be received.

    Currently the HTTPClient query stopped after 600 mSec and another (same) query executed. Once the controller respond I receive data from all previous queries also where the data is completely identical.

    Looks like somehow the timeout doesn't close the http request and it works in background and when data received it sends response of all of them.

    It creates situation like I receive same data for same device several times and it's triggering same action several times, while in reality it should be ONE trigger.

    As you can see below, 5 requests executed and 5 identical responses received  when only one response of the last query should  be received.

    Please login or register to see this spoiler.

     

    Exactly same function executed on HC2/HC3/HC3L and indeed only one response received.

    I hope you can understand what I mean.

     

     

     

     

     

     

     

    Edited by cag014
    Link to comment
    Share on other sites

  • Topic Author
  • 3 hours ago, cag014 said:

    Have something strange... will try to explain in bets way I can

    Since AOR designed to support several controllers, I'm querying for refreshState with timeout  (600 mSec), so in case if no activity the query should be stopped and no data should be received.

    Currently the HTTPClient query stopped after 600 mSec and another (same) query executed. Once the controller respond I receive data from all previous queries also where the data is completely identical.

    Looks like somehow the timeout doesn't close the http request and it works in background and when data received it sends response of all of them.

    It creates situation like I receive same data for same device several times and it's triggering same action several times, while in reality it should be ONE trigger.

    As you can see below, 5 requests executed and 5 identical responses received  when only one response of the last query should  be received.

    Please login or register to see this spoiler.

     

    If you add hc3_emulator.debug.http=true you see the requests and how long they took.

    I have QAs that run multiple http requests in "parallel" that work well,  but there could still be a problem.

    -I looked in the code and net.HTTPclient({timeout=....}) was not used, only the timeout in the options structure (I'm going to push a version with the fix soon)

    -timeouts in general is on seconds granularity for LuaSocket, even if the timeout seems to be specified in ms.

    -The earlier version all net I/O was synchronous. In the new version it's all asynchronous. I expect that the identical results you get are the asynchronous answers to several outstanding requests to the same server.

     

    Do you run the http:request sync=true?

    Do you run them from multiple setTimeout loops?

    Do you get any warnings that timers are delayed?

     

    ...and can you share the refresh poll code with me? maybe a PM to not bore people in the thread.

    Link to comment
    Share on other sites

    2 hours ago, jgab said:

    Do you run the http:request sync=true?

    Do you run them from multiple setTimeout loops?

    Do you get any warnings that timers are delayed?

     

    ...and can you share the refresh poll code with me? maybe a PM to not bore people in the thread.

    1. No. I use sync=false. When it sets to true it waits for the response

    2. No. Using setInterval

    3. No warnings seen..

     

    Here how these functions work
     

    Please login or register to see this code.

     

    By the way see below whenhc3_emulator.debug.http=true

    Please login or register to see this spoiler.

     

    It's actually shows that all previous requests (which should be flushed by timeout) continue to run.

     

    Link to comment
    Share on other sites

  • Topic Author
  • Yes, as you see the refreshStates call can take some time as they hang if there are no events available - In your log I see completion times of 16, 17, 14s

    which is not strange.

    This means that when you run a setInterval every. 600ms the call will not complete in that time and they will start to pile up. Eventually some. calls may complete and you get this repeated sequence of return values (sometimes from the same server).

    In the old emulator that was synchronous they run one after echoer and didn't show this behaviour. However, I would expect that if you run it on the HC3 it would look similar.

     

    A good rule of thumb is to never drive http requests with setInterval, unless the intervals are so long that the response is guaranteed in the interval specified.

     

    The way to solve it is to start each slave as its own setTimeout loop that run independent of the others - unless it's a problem that they may run at different paces.

     

    If you need them sequential I would recommend either to have a single setTimeout with sync requests, or a threaded setTimeout going through all slaves. 

    The former would look like something like (haven't run it but it looks ok)

    (and 600ms is a bit fast, but it will runs fast as it can:

    Please login or register to see this code.

     

    Running each slave in its own setTimeout loop is probably the most efficient as each loop can run as fast as it can and the overall loop will not be limited by the slowest server to respond.

    Edited by jgab
    Link to comment
    Share on other sites

    59 minutes ago, jgab said:

    Yes, as you see the refreshStates call can take some time as they hang if there are no events available - In your log I see completion times of 16, 17, 14s

    which is not strange.

    This means that when you run a setInterval every. 600ms the call will not complete in that time and they will start to pile up. Eventually some. calls may complete and you get this repeated sequence of return values (sometimes from the same server).

    In the old emulator that was synchronous they run one after echoer and didn't show this behaviour. However, I would expect that if you run it on the HC3 it would look similar.

     

    A good rule of thumb is to never drive http requests with setInterval, unless the intervals are so long that the response is guaranteed in the interval specified.

     

    The way to solve it is to start each slave as its own setTimeout loop that run independent of the others - unless it's a problem that they may run at different paces.

     

    If you need them sequential I would recommend either to have a single setTimeout with sync requests, or a threaded setTimeout going through all slaves. 

    The former would look like something like (haven't run it but it looks ok)

    (and 600ms is a bit fast, but it will runs fast as it can:

    Please login or register to see this code.

     

    Running each slave in its own setTimeout loop is probably the most efficient as each loop can run as fast as it can and the overall loop will not be limited by the slowest server to respond.

    Correct, but this is the idea to use timeout=600mS, doesn't matter how slow any server is.

    Link to comment
    Share on other sites

  • Topic Author
  • 7 hours ago, cag014 said:

    Correct, but this is the idea to use timeout=600mS, doesn't matter how slow any server is.

    It's a not efficient to poll the servers every 600ms even if they don't have any events. You create a lot of http requests and load completely unnecessary both on the machine you run it on as well as the other HC2/HC3 systems - it doesn't scale.

     

    They way to do it is something like this - then you leverage that the requests hangs waiting for events from the HC2/HC3 system you are polling.

    Please login or register to see this code.

     

    I think you can remove the logic for identical responses - you got that because the setInterval overrun the http responses.

     

    I don't know how you display the results, but I would let the stateLoops just update the slave structure with the events and then have a separate thread that every second (or less) loops through the slave's data and render it - your display refresh rate that's independent of how often you get data fro the slaves.

    Link to comment
    Share on other sites

  • Topic Author
  • In any case I have pushed a version (v0.303) where http timeout is specified in ms, like on the HC3. However, I'm pretty sure that the real resolution is seconds... It now also uses net.HTTPClient({timeout=...}) if set.

    Edited by jgab
    Link to comment
    Share on other sites

    Join the conversation

    You can post now and register later. If you have an account, sign in now to post with your account.

    Guest
    Reply to this topic...

    ×   Pasted as rich text.   Paste as plain text instead

      Only 75 emoji are allowed.

    ×   Your link has been automatically embedded.   Display as a link instead

    ×   Your previous content has been restored.   Clear editor

    ×   You cannot paste images directly. Upload or insert images from URL.

    ×
    ×
    • Create New...