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


  • 1

HC3 LUA vs HC2


knuth

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 

Please login or register to see this link.

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

Please login or register to see this attachment.

Edited by knuth
Moved summary table to first post
  • Like 1
Link to comment
Share on other sites

Recommended Posts

  • 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 comment
Share on other sites

  • 0

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

 

Link to comment
Share on other sites

  • 0
17 minutes ago, vsokolov said:

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

 

 

Link to comment
Share on other sites

  • 0

In next release

Link to comment
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

Please login or register to see this code.

Prints

Please login or register to see this code.

 

  • Like 4
Link to comment
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 comment
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.

Please login or register to see this code.

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

 

Please login or register to see this code.

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

Please login or register to see this code.

 

Edited by jgab
Sorry, stupid mistake
  • Like 1
Link to comment
Share on other sites

  • 0

yes ok :) 

so I know what I will do this weekend ;) 

 

thanks a lot...

 

I will return you the result !

Link to comment
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 comment
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 comment
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 comment
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 comment
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 comment
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 comment
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 comment
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 comment
Share on other sites

  • 0

:) like @petergebruers said, it is in Alpha stage, so it will not take much time :P (I know other word then "soon" :P)

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