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

@jgab Your function definitions are now added to the pdf file above. Great job, thanks! Keep testing! 

@boomx Is there a difference between HC2 and HC3 in the way RGBW controllers are addressed in LUA? Those differences are the only issue for this thread.

Link to post
Share on other sites
  • 0

Hi @knuth - thanks for you good idea!

 

I had noticed that there was a difference between QA-LUA and scene-LUA.

 

Specifically in my case the command fibaro.profile:

 

QA LUA: fibaro.profile("activateProfile",1)

ScriptLUA: fibaro.profile (1, "activateProfile")

 

I hope it is a mistake on the part of fibaro and we do not have to distinguish between QA-LUA and Script-LUA....

 

Greetings!

Link to post
Share on other sites
  • 0

@kallecux I agree, it would be strange to have different syntax between LUA used in scenes and LUA in QAs. Still, I will include your observation as a note in my next update. 

Actually, I would expect the missing functions described by @jgab to be included in a future update by Fibaro, as well as obvious errors like the one you describe. But so far, we have to give users advice based on the current version. Thanks, both of you.

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

In scenes there is fibaro.setTimeout but there is no fibaro.clearTimeout, used to cancel a timer that is not yet activated. Used to be there on the HC2 and is useful.

Hopefully they will add it but there are ways to overcome the issue - a small performance penalty (memory) as timers will hang around until they expire.

do
  oldSetTimeout = fibaro.setTimeout 
  function fibaro.setTimeout(time, fun) local ref={ref=true,run=true} oldSetTimeout(function() if ref.run then fun() end end, time) return ref end
  function fibaro.clearTimeout(ref) if type(ref)=='table' and ref.ref then ref.run=false end end
end

 

There used to be a fibaro:calculateDistance in HC2 scenes - not sure how useful it is these days, but for completeness...

function fibaro.calculateDistance(position1 , position2) 
      assert(type(position1)=="string") 
      assert(type(position2)=="string") 
      local lat1,lon1=position1:match("(.*);(.*)")
      local lat2,lon2=position2:match("(.*);(.*)")
      lat1,lon1,lat2,lon2=tonumber(lat1),tonumber(lon1),tonumber(lat2),tonumber(lon2)
      _assert(lat1 and lon1 and lat2 and lon2,"Bad arguments to fibaro:calculateDistance")
      local dlat = math.rad(lat2-lat1)
      local dlon = math.rad(lon2-lon1)
      local sin_dlat = math.sin(dlat/2)
      local sin_dlon = math.sin(dlon/2)
      local a = sin_dlat * sin_dlat + math.cos(math.rad(lat1)) * math.cos(math.rad(lat2)) * sin_dlon * sin_dlon
      local c = 2 * math.atan2(math.sqrt(a), math.sqrt(1-a))
      local d = 6378 * c
      return d
end

 

Link to post
Share on other sites
  • 0

Hi!

 

Event handling by example Fibaro Button event handling:

 

HC2:

local button_source = (fibaro:getSourceTrigger()["event"]["data"]);

if (tostring(button_source["keyAttribute"]) == "Pressed")

 then fibaro:debug("Pressed 1x")

elseif (tostring(button_source["keyAttribute"]) == "Pressed2")

 then fibaro:debug("Pressed 2x")

end

 

HC3:

if (sourceTrigger.value.keyAttribute == "Pressed")
 then fibaro.trace("Scene13", "Pressed 1x")
elseif (sourceTrigger.value.keyAttribute == "Pressed2")
 then fibaro.trace("Scene13", "Pressed 2x")
end 
Link to post
Share on other sites
  • 0
23 minutes ago, Jacławiciel said:

What about fibaro:countScenes() and fibaro:abort()? Anyone found a replacement?

countScenes is not relevant as there is only one instance running.

fibaro.abort() can be avoided by structuring the code so the scene terminates.

If you absolutely need it it you could try

function fibaro.abort() fibaro.scene("kill",{sceneId}) end

See discussion here

 

Link to post
Share on other sites
  • 0
36 minutes ago, jgab said:

See discussion here

I think, that issue not in  fibaro:abort(), but in fibaro:countScenes() to know - is it exist another (parallel) running instance of the scene and make appropriate processing this case in code. In a particular case, a  fibaro:abort() call.

Edited by vsokolov
Link to post
Share on other sites
  • 0
4 minutes ago, vsokolov said:

I think, that issue not in  fibaro:abort(), but in fibaro:countScenes() to know - is it exist another (parallel) running instance of the scene and make appropriate processing this case in code. In a particular case, a  fibaro:abort() call.

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 running instance. 

But ok, here is a countScenes function

function fibaro.countScenes() return 1 end

;-) 

  • Like 2
  • Thanks 2
Link to post
Share on other sites
  • 0
4 minutes ago, jgab said:

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 running instance. 

Thanks for explain. Appropriate fibaro hint on this scene attribute is not so evident as for me.

Link to post
Share on other sites
  • 0
1 minutę temu, jgab napisał:

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 running instance. 

But ok, here is a countScenes function

function fibaro.countScenes() return 1 end

;-) 

 

Yeah, funny! 😁 

 

I was not aware of that. Thank's for explanation. 

 

BTW: It's my first occasion to thank you personally for your time and dedication. I'm a big fan of your "out of the box" thinking that must be based on your vast technical experience. Your solutions to many problems are based on solid foundations and I try to a handful of it with benefit to my Fibaro and professional knowledge. 

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

A HC3 running instance either block a new scene or the new scene kills the running instance. 

By default a trigger indeed kills the running instance, because new scenes on HC3 get "Allow to restart a running scene" under "Basic Configuration" set to "Yes". If you change that to "No", a trigger won't kill a running instance but also does not start a new instance, so setting it to 'No' comes close to what many scenes on HC2 did by adding "if countscenes > 1 then fibaro:abort" at the start of a scene.

Link to post
Share on other sites
  • 0
9 minutes ago, petergebruers said:

By default a trigger indeed kills the running instance, because new scenes on HC3 get "Allow to restart a running scene" under "Basic Configuration" set to "Yes". If you change that to "No", a trigger won't kill a running instance but also does not start a new instance, so setting it to 'No' comes close to what many scenes on HC2 did by adding "if countscenes > 1 then fibaro:abort" at the start of a scene.

Do we know if the scene queues up if there is a scene already running? or it's just never allowed to start and we loose the trigger/event? I guess it's lost...

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

Do we know if the scene queues up if there is a scene already running? or it's just never allowed to start and we loose the trigger/event? I guess it's lost...

iirc it is lost and there is a request to get back the HC2 behaviour of running multiple instances (up to 10). I support this request, not because it is a good idea (imo, it is not a great idea...) but because some scripts rely on the fact that you can have more than one instance... I prefer the HC3 way (one instance, either kill or leave running).

 

I know you use refreshStates too and I think that is the most flexible way and would not miss events.

Link to post
Share on other sites
  • 0
14 minutes ago, petergebruers said:

comes close

Hi @petergebruers,

could you please elaborate a bit what means come close to?

 

Link to post
Share on other sites
  • 0
Just now, Bodyart said:

could you please elaborate a bit what means come close to?

Two things come to mind. the first is, on HC2 you can do things, then check the number of instances and abort (say halfway your scene). The second thing is it does not emulate this HC2 bug: when a trigger comes very fast after another on HC2 your scene will start with countscenes 2. If your scene aborts if count is > 1 your scene won't run (because there never was an instance with count 1). I still have to double check this on my HC3 but I think this is no longer an issue.

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

I still have to double check this on my HC3 but I think this is no longer an issue.

I really hope, that that instance issue is already solved on HC3.

 

Link to post
Share on other sites
  • 0
9 minutes ago, petergebruers said:

iirc it is lost and there is a request to get back the HC2 behaviour of running multiple instances (up to 10). I support this request, not because it is a good idea (imo, it is not a great idea...) but because some scripts rely on the fact that you can have more than one instance... I prefer the HC3 way (one instance, either kill or leave running).

 

I know you use refreshStates too and I think that is the most flexible way and would not miss events.

 

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. 

 

However, it's kind of unacceptable to drop events - if they only want to run one instance they could as an option allow to queue up the events - much less memory needs for events vs scene instances.

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

I have no experience with HC2 as I directly bought an HC3 recently. My idea was to buy the newest technology as it is the best one. Going through this forum and "struggling" to develop quick apps in HC3, more and more I realize that HC3 is a "not ready to be released" product. Or let's call it a beta version of a product. 

Coming to LUA programming, Quick Apps, it's quite a challenge programming HC3 by using the documentation which is provided by Fibaro. As it was said before in this discussion, it is a lot of "try and run...". Fibaro support is also answering very hard in this matter.

I really hope that this will change soon. For now... I would not recommend to anyone to buy an HC3...

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