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


Migration support from Homecenter2 to Homecenter3


Thomasn

Recommended Posts

I suggest that the new Homecenter3 will get a function where backups from Homecenter2 can be downloaded and installed from the Fibaro Cloud and converted automatically to the new homecenter. 

Pros:

1) It is what user expects from a serious company.

2) Scenes, VDs and block scenes can be reused without further programming.

3) Users of Homecenter2 will probably want to upgrade = more units sold.

 

Cons:

N/A

  • Like 1
Link to comment
Share on other sites

Hi @Thomasn it is not that easy how you wrote. In backups HC2 we got dump of z-wave chip and that dump It is incompatible with the HC3 chip, so we can't move the devices in this way, so we plan to add a wizard which will allow us to move devices from HC2, HCL to Hc3. Unfortunately, we won't be able to keep the device ID, (the names of the rooms or the names of the devices, associations, parameters we should succeed) Transferring other settings because HC3 has a very improved layer of low OS will not be able to transfer either

 

HC3 don't have Virtual Device we have replaced them with a new better element, called by us Quick Apps. Because it uses the LUA scene engine and the individual controls are operated differently, they are not backwards compatible.

The same applies to block scenes, which now look completely different, and additionally use a new syntax, so they are also not backward compatible and have to be created again on HC3.

Link to comment
Share on other sites

@A.Socha That sounds great that you have at least some way to move existing devices!

I understand the current LUA code in scenes can't be automatically migrated, and not copy pasted either?

Will I be able to code the same logic in HC3 as in HC2? So creating a new scene in HC3 and the manually coding LUA to get the same result as I did in HC2?

Link to comment
Share on other sites

6 minut temu, relnah napisał:

@A.Socha That sounds great that you have at least some way to move existing devices!

I understand the current LUA code in scenes can't be automatically migrated, and not copy pasted either?

Will I be able to code the same logic in HC3 as in HC2? So creating a new scene in HC3 and the manually coding LUA to get the same result as I did in HC2?

Yes LUA scene will have other syntax we moved from fibaro:debug(string) to Fibaro.debug(tag, string), we killed fibaro:sleep so now to delay we will use fibaro.setTimeout

Please login or register to see this code.

We completely changed trigger blocks, management of instance

Generally yes it will have the same logic but some commands and trigers may be diffrence and you will get that same what was on Hc2 or it will offer you more with better control

Link to comment
Share on other sites

13 minutes ago, A.Socha said:

Yes LUA scene will have other syntax we moved from fibaro:debug(string) to Fibaro.debug(tag, string), we killed fibaro:sleep so now to delay we will use fibaro.setTimeout

Please login or register to see this code.

We completely changed trigger blocks, management of instance

Generally yes it will have the same logic but some commands and trigers may be diffrence and you will get that same what was on Hc2 or it will offer you more with better control

 

In Lua, how does a scene figure out what triggered it? On the HC2 it was very common to call fibaro:getSourceTrigger() to understand what triggered the scene (from triggers declared in the header) and take actions accordingly. Is there a new way to figure that out with the new scene conditions/trigger declarations?

 

Link to comment
Share on other sites

16 minut temu, jgab napisał:

 

In Lua, how does a scene figure out what triggered it? On the HC2 it was very common to call fibaro:getSourceTrigger() to understand what triggered the scene (from triggers declared in the header) and take actions accordingly. Is there a new way to figure that out with the new scene conditions/trigger declarations?

 

We will release documentation. In short there will be separate section trigers where you with logic will chose

for example for button with 1 press

Please login or register to see this code.

or when binary switch is ON

Please login or register to see this code.

or you can mix them device 25 is ON and one of (device 26 or 27 is on)

Please login or register to see this code.

 

Link to comment
Share on other sites

2 minutes ago, A.Socha said:

We will release documentation. In sort there will be separate section trigers where you with logic will chose

for example for button with 1 press

That is an example of a single trigger condition.

The new syntax supports multiple triggers as well. I think @jgab is refering to those multiple conditien cases... If I am correct there is no "fibaro:getSourceTrigger", but I may have missed something...

Link to comment
Share on other sites

4 minutes ago, petergebruers said:

That is an example of a single trigger condition.

The new syntax supports multiple triggers as well. I think @jgab is refering to those multiple conditien cases... If I am correct there is no "fibaro:getSourceTrigger", but I may have missed something...

 

Yes, I think I understand the new trigger/rule logic.

However, from my Lua code I would like to understand specifically what condition/rule triggered as we can have OR in rules/conditions.

Would be nice if the rule/conditions could set labels/vars that could be tested against in the code later on.

Link to comment
Share on other sites

in action section

Please login or register to see this code.

it working too so you can made if device 26 then show "x" when device 27 then "y"

 

The major change is let say for power metering before was

23 power

so every change was start scene, now you can crate condition when that scene should start on every change of value or only when power is bigger/ lower/excaly then 35W

 

Condition/Trigger decide when scene start, action section what you want to do

Link to comment
Share on other sites

As mentioned here, no more "sleep" on HC3. Nothing new if you have been around here for a while. But if you are new you might have not noticed "setTimeout". The replacement uses a callback style, like httpClient. I wrote a small introduction a very long time ago:

 

 

Link to comment
Share on other sites

20 minutes ago, A.Socha said:

in action section

Please login or register to see this code.

it working too so you can made if device 26 then show "x" when device 27 then "y"

 

The major change is let say for power metering before was

23 power

so every change was start scene, now you can crate condition when that scene should start on every change of value or only when power is bigger/ lower/excaly then 35W

 

Condition/Trigger decide when scene start, action section what you want to do

 

So if I have a rule/condition that triggers the scene if any of sensors s1,...sn is breached, I have to loop through all the sensors in my action section to see what sensor triggered last, to get what specific sensor triggered the scene. This can get very difficult with complex rules combining many different types of triggers (time, timespans, devices, weather, custom events etc)...

With getSourceTrigger you could get the specific event that caused the scene to be triggered. And as I understand there is no fibaro:getSourceTrigger anymore.

 

Link to comment
Share on other sites

1 hour ago, petergebruers said:

As mentioned here, no more "sleep" on HC3. Nothing new if you have been around here for a while. But if you are new you might have not noticed "setTimeout". The replacement uses a callback style, like httpClient. I wrote a small introduction a very long time ago:

 


Yes, but no clearTimout() that turns out to be quite useful. Then I’m missing os.time() to calculate time intervals so we don’t start to drift when doing setTimeout loops... but maybe that will come.

Maybe time to open a separate HC3 section in the forum?

Edited by jgab
Link to comment
Share on other sites

3 hours ago, A.Socha said:

We will release documentation. In short there will be separate section trigers where you with logic will chose

for example for button with 1 press

Please login or register to see this code.

or when binary switch is ON

Please login or register to see this code.

or you can mix them device 25 is ON and one of (device 26 or 27 is on)

Please login or register to see this code.

 


So in your last example. If I want to know in the Lua action section if it was Id 25, 26, or 27 that finally made the rule trigger - how do I know that? Do I have to check all the devices again? You should be able to save away the event that made the rule true and have a function that could retrieve the event - like fibaro:getSourceTrigger() used to do.

Link to comment
Share on other sites

@A.Socha out of curiosity … just reading readme.md from CPKG285-29  ?, i assume the lua engine is the same as on HC3?

 

 

Edited by tinman
Link to comment
Share on other sites

5 hours ago, jgab said:


Yes, but no clearTimout() that turns out to be quite useful. Then I’m missing os.time() to calculate time intervals so we don’t start to drift when doing setTimeout loops... but maybe that will come.

Maybe time to open a separate HC3 section in the forum?

Please login or register to see this code.

Please login or register to see this code.

Please login or register to see this code.

Not very pretty...

Some volunteer to code os.date() ? :-) 

Edited by jgab
Link to comment
Share on other sites

the question is for what os.time is being used, to get some delay to sunset?

 

Please login or register to see this code.

 

to run something every minute?

 

Please login or register to see this code.

to run at specific time?

 

Please login or register to see this code.

 

once true you can emit custom Event ( fibaro.emitCustomEvent) to your (previously)time-based scenes, where you evaluate the Event as trigger condition (e.g. as sum of counted events). 

 

Link to comment
Share on other sites

Please login or register to see this image.

@jgab that's what I took after reading your pice of code, 20 one shot ?

Edited by Tony270570
Link to comment
Share on other sites

1 hour ago, tinman said:

the question is for what os.time is being used, to get some delay to sunset?

 

Please login or register to see this code.

 

to run something every minute?

 

Please login or register to see this code.

to run at specific time?

 

Please login or register to see this code.

 

once true you can emit custom Event ( fibaro.emitCustomEvent) to your (previously)time-based scenes, where you evaluate the Event as trigger condition (e.g. as sum of counted events). 

 

 

Isn't that as "unpretty" - counting sum of events to keep track of time? (if I understod your last remark correctly) 

If I want to trigger at 06:00 or sunrise, whatever comes first, how do I express that in a condition? Maybe they support more complex expressions over time? But why invent a "conditions-language" that becomes complex and idiosyncratic - when we have Lua?

The problem with the other examples are that I can get triggered at intervals but I can't tell in the action when that interval/time was.

Second example - what minute was I triggered?

Third example - what day was I triggered?

Ugly solution is to start to split into several scenes to have simple triggers so you know when/what triggered...

...another minor issue is that cron only have minute resolution...

 

My simple question is why? why not just add os.time,os.date,os.difftime and the other functions we had in scenes in the HC2? Instead it destroys backward compatibility for scenes like Sankotronic's Main scene FTBE with 1700 downloads, and he will be forced to jump through hoops re-implement it and the users of the scene that (finally) have something that works for them needs to start all over over. But obviously someone at fibaro thought it was worth it...

 

Now people will start to misuse VDs instead. "Where should I put the code for my scheduler? Well, I make it a binary sensor..." ?

Edited by jgab
  • Like 2
Link to comment
Share on other sites

49 minutes ago, Tony270570 said:

 

@jgab that's what I took after reading your pice of code, 20 one shot ?

Well, the code was (half) a joke - point was that I think that they should put back the missing functions or people will start to write terrible code to try to get around the new limitations imposed.

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