Jump to content
  • 1

HC3 LUA vs HC2


Question

In making the transfer from HC2 to HC3 based on a cloud backup (update 4.581 Beta) it is stated that "scenes will not be moved and need to be created again". That's OK, but it would be helpful when planning the transfer to know what the differences are (in syntax and available functions) between the two LUA versions. I know that the new LUA editor is documented in https://manuals.fibaro.com/home-center-3-lua-scenes/ . What I would hope to see in addition, is a side by side comparison of all the crucial differences, to enable a pre-edit of the old LUA scenes before entering them into the new editor. Something like this:

 

If you used this in HC2 LUA:                You need to do this in HC3 LUA:

fibaro.debug("txt")                                   fibaro.debug("tag", "txt")

os.time()                                                   ??? 

etc.

 

If we all contribute to such a table as we identify all the differences, we may be able to help each other prepare for HC3. Not all differences can easily be summarized in the simple two-column format above, however. For the new definition of conditions and triggers, it seems it would be more appropriate to give a few examples of old codes (with triggers) converted to new codes. 

 

PS: I haven't even decided to buy the HC3 yet! But getting a feel for the amount of re-programming needed to convert my scene is an important factor in making that decision. 

 

The suggested table is now shown in a pdf file attached to this post, see below. It is regularly updated as new contributions are posted.

LUA HC2 vs HC3.pdf

Edited by knuth
Moved summary table to first post
  • Like 1
  • Thanks 1
Link to post
Share on other sites
  • Answers 68
  • Created
  • Last Reply

Top Posters For This Question

Top Posters For This Question

Popular Posts

On the HC3 there is only one instance running. They skipped the multiple instance model that was used in the HC2. A HC3 running instance either block a new scene or the new scene kills the runnin

Yeah, I'd like to add that on HC3 Fibaro works on an "alpha" version internally, then publishes that "alpha" to a group of end-users for feedback.   At the moment, I am not 100% sure if the

First version of summary table, including some that are not mentioned above. I am sure there is more, please post your contribution once you find other differences. The trigger section is still e

Posted Images

Recommended Posts

  • 0
17 minutes ago, vsokolov said:

seems net.HTTPClient() not working in HC3 scenes :(
Any ideas ?

 

 

Link to post
Share on other sites
  • 0
12 hours ago, cag014 said:

In next release

Yeah, I'd like to add that on HC3 Fibaro works on an "alpha" version internally, then publishes that "alpha" to a group of end-users for feedback.

 

At the moment, I am not 100% sure if the members of that group are allowed to talk much about this test phase, maybe @A.Socha can comment on this.

 

As you may have guessed, I am part of that group so I get to see software before it gets released to the poblic and I do my best to test and and find bugs, UI issues and so on

 

I would like to have the freedom to talk about this a little more because it would fill that "long pauze" between releases, the only major problem I see is that in some rare cases a feature that is available in "alpha" version might not be ready in time for publication. And announcing a feature during alpha and then not releasing it would inevitably upset people

 

So, I can say http client is introduced in fw 5.031.7 but this fw is not ready for prime time, the test team has found issues and they are working on a new version.

 

Scene on HC3 5.031.7

local http = net.HTTPClient({ timeout = 5000 })

local function call(url)
  http:request(url, {
      options = { method = 'GET' },
      success =function() fibaro.debug("http-demo", url.." done.") end,
      error = function(errorcode) fibaro.debug("http-demo", "error=" .. errorcode) end
    })
end

call("http://www.google.com")
call("http://www.micorosoft.com")
--fibaro:sleep(5000) -- the http calls run when main ends, so this delays everything

Prints

[19.05.2020] [13:02:27] [DEBUG] [HTTP-DEMO]: http://www.google.com done.
[19.05.2020] [13:02:27] [DEBUG] [HTTP-DEMO]: http://www.micorosoft.com done.

 

  • Like 4
Link to post
Share on other sites
  • 0
On 5/12/2020 at 11:06 PM, jgab said:

I don't think the multiple instances is a good idea either. I hope they don't revert to that.

I would like to have a better way to interact with the event queue -like registering callbacks for specified event types. 

 

Ok but I have an exemple : 

 

An unique scene to switch on/off the lights in the rooms with many PIR Sensor.

So if 2 sensors trigger simultaneously, juste one room lights on !

Multi instance would be interesting !

 

I won't create 1 scene for each Sensor !

Edited by jjacques68
Link to post
Share on other sites
  • 0
8 hours ago, jjacques68 said:

Ok but I have an exemple : 

An unique scene to switch on/off the lights in the rooms with many PIR Sensor.

So if 2 sensors trigger simultaneously, juste one room lights on !

Multi instance would be interesting !

 

I won't create 1 scene for each Sensor !

Is it a block scene?

No matter Lua or block scene, it can't be that funny to have a long conditions list with "any" items of sensors, and the only thing that differs between each item/trigger is the deviceId....

I don't think we should be forced to make a scene per trigger either.

 

Spawning them in parallel probably caused some resource strain (each process needing a Lua environment). I think in most cases they could just queue up the requests and serve them one after each other. Maintaining a queue of triggers shouldn't require any resources.

The queued up requests would be slightly delayed waiting for the first to finish, but it's like in your case, happens rarely and it would be very short delays for most simple scenes... Maybe a timeout for scenes, if they are not started within x seconds after they are triggered they are removed or started up with a sourceTrigger of "timeout' ?

 

A thought, what happens when your scene is triggered, besides serving the sensor being triggered, also loop through your other sensors to see if they triggered and serve them too? Maybe you avoid losing triggers like you experience now? at least you are further minimising the possibility...

 

My thinking was that we could register a callback function for triggers (in a Scene or QA) and we would be called with new triggers. For a Scene it would mean that the scene would not terminate as long as the callback is registered - but that would be ok because it would handle all triggers coming in in the same instance. Like many scenes behaved on the HC2. Did it take too much resources? Maybe. But it would also cut down on the number of scenes needed - like in your case where you have one scene handling all the sensors turning on lights logic.

On the other hand, QAs are much more suited to handle this kind of "long running" logic as they always run and "keep state". 

 

In a QA we can loop through the event queue with the /refreshStates api and get all the triggers. The loop hangs if there are no events so we don't loop unnecessarily.  Ex.

local delay = delay or 1000
local mySensors = {
  66 = {lights = { 77, 78 }}, -- sensors and associated lights
  99 = {lights = { 101, 130}}
}
  
local function checkSensors(dev)
    if dev.newValue then 
      fibaro.call(mySensors[dev.id].lights,'turnOn') 
    end
end

local lastRefresh,http = 0,net.HTTPClient()
local function loop()
  local stat,res = http:request("http://127.0.0.1:11111/api/refreshStates?last=" .. lastRefresh,{
      success=function(res) 
        local states = json.decode(res.data)
        if states then
          lastRefresh=states.last
          for _,e in ipairs(states.events or {}) do
            if e.type == 'DevicePropertyUpdatedEvent' and e.property='value' and mySensors[e.id] then
              checkSensor(e)
            end
          end
          setTimeout(loop,delay)
        else setTimeout(loop,delay) end  
      end,
      error=function(res) print("Error: refreshStates:"..res) setTimeout(loop,2*delay) end,
    })
end
loop()

It's a pretty common pattern in my QAs these days. In fact so common that I created a QA whose only job is to poll the refreshStates event queue and send the events to other QAs that "subscribe" on events. I imagine that I save some resources by not having all my QAs poll the queue.

 

If you want to have a scene to trigger you could still have a virtual QA sensors that aggregates the states of your physical sensors. Then you let your scene trigger on that QA, and in the scene, loop over the sensors and see who you need to act on. No ideally, but one way around the issue.

Here is an aggregated QA of that type.

 

Edited by jgab
  • Like 1
Link to post
Share on other sites
  • 0

very interesting what you say ! thanks !

 

I can try a loop in a QA with the refreshState... why not...

 

and why not to check all sensor in the scene when one is active !

but I afraid with the elapsed time of the scene, it will be longer ! if I check all sensor each time...

 

I must try it...

 

 

Link to post
Share on other sites
  • 0
2 hours ago, jjacques68 said:

and why not to check all sensor in the scene when one is active !

but I afraid with the elapsed time of the scene, it will be longer ! if I check all sensor each time...

 

local sensors = {21,211,239,689,966,976,988}
function QuickApp:onInit()
    local b = false
    local t0 = os.clock()
    local n = 1000
    for i=1,n do
      b = fibaro.getValue(sensors[(i % #sensors) + 1],"value")
    end
    local t1 = os.clock()
    self:debug("Time for ",n," getValue:",(t1-t0),"s")
end 

I only rotate between 7 sensors, but 100.000 times...

[25.05.2020] [21:27:39] [DEBUG] [QUICKAPP987]: Time for 1000 getValue:  1.536284 s

 

Edited by jgab
Sorry, stupid mistake
  • Like 1
Link to post
Share on other sites
  • 0
1 minute ago, jjacques68 said:

yes ok :) 

so I know what I will do this weekend ;) 

 

thanks a lot...

 

I will return you the result !

Sorry, my first timing was way off. ~1.5s for 1000 getValues. Anyway, not bad.

  • Like 1
Link to post
Share on other sites
  • 0

another exemple :

 

I made a personal IHM, I created with an AGL(Windev).

I transmit through a socket TCP all state of all devices.

So I have a scene with all device as trigger.

and same problem, if 2 devices change simultaneously, juste one is sending on the socket.

 

I don't know if I can use the same idea (like PIR sensor)... it's too much... ??

 

what do you thing ?

Link to post
Share on other sites
  • 0
33 minutes ago, jjacques68 said:

another exemple :

 

I made a personal IHM, I created with an AGL(Windev).

I transmit through a socket TCP all state of all devices.

So I have a scene with all device as trigger.

and same problem, if 2 devices change simultaneously, juste one is sending on the socket.

 

I don't know if I can use the same idea (like PIR sensor)... it's too much... ??

 

what do you thing ?

You do something similar like the /refreshStates loop in my first example. That way you get all events in the system. You can filter out the ones you are not interested in. 

...and then you write them out to your socket...

But you need to do it in a QA (rumour  that we get net.HTTPClient() in the next fw for scenes)

  • Like 1
Link to post
Share on other sites
  • 0

yes but it will not be as instantaneous as with a scene triggered !

 

I must creat a loop with maybe 30 or 20 secondes of interval...

Link to post
Share on other sites
  • 0
2 minutes ago, jjacques68 said:

yes but it will not be as instantaneous as with a scene triggered !

 

I must creat a loop with maybe 30 or 20 secondes of interval...

You can loop every 100ms. If there are no events the http get will hang (up to 30s) and return immediately when there is an event available again. It will timeout with nil if there are no events after 30s, but then you just read again.

I don't think you will experience any delay.

7 minutes ago, jjacques68 said:

yes but it will not be as instantaneous as with a scene triggered !

 

I must creat a loop with maybe 30 or 20 secondes of interval...

Some specific reason you need to wait 20-30s? To write to the socket?

  • Like 1
Link to post
Share on other sites
  • 0
3 minutes ago, jgab said:

Some specific reason you need to wait 20-30s? To write to the socket?

 

No, I can write as fast as I want :) 

But it's for the process of HC3, it will work hard, and I think maybe it's too much... I imagine ... 

Link to post
Share on other sites
  • 0
2 minutes ago, jjacques68 said:

 

No, I can write as fast as I want :) 

But it's for the process of HC3, it will work hard, and I think maybe it's too much... I imagine ... 

You paid a lot of money for the HC3 - make sure you always give it work to do :-) 

  • Like 1
Link to post
Share on other sites
  • 0
12 hours ago, jgab said:

rumour  that we get net.HTTPClient() in the next fw for scenes

It is more than a rumour, HTTPClient is in scenes in current HC3 Alpha version. You know, Fibaro never publishes release dates but you can expect a fw release "soon" ;) You know, "soon" has been the standard designator for years and I am going to keep that tradition  😄

  • Like 1
Link to post
Share on other sites
  • 0
On 5/25/2020 at 10:50 PM, jgab said:

You do something similar like the /refreshStates loop in my first example. That way you get all events in the system. You can filter out the ones you are not interested in. 

 

it's works perfektly !!!!

 

but I must create some filters because there is to much informations !

And it can create some problems...

 

I continue to reflect with filters... 🤔

 

Thanks for the idea !!

Link to post
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
Answer this question...

×   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...