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

36 minutes ago, jgab said:

 

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

 

you can, but you don't have to, it is just an example
 

Quote

If I want to trigger at 06:00 or sunrise, whatever comes first, how do I express that in a condition?

 

afaik that should do the trick, every day at 6 or sunrise (here + 180min as example for delay)

Please login or register to see this code.

 

 

Quote

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.

 

afaik the lua engine is checking all conditions and triggering only these which match, so at 15:00 is at 15:00, why do i have to do os.time to check it twice?

 

Quote

Second example - what minute was I triggered?

 

every, but why you need to know the time here? For log? debug? so do debug or send message or  emit event. Isn't better to have "VD" to see Events instead of check all the Scenes debug boxes or even worse to run another Scene collecting thousands of variables changed somewhere, like on HC2?

 

Quote

Third example - what day was I triggered?

 

same as above

 

Quote

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

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

 

to be very honest, this is b****, why on earth you need os.time each every second? Again, feel free to notify you when it got triggered, see above

 

Quote

 

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?

 

to allow better triggering? to stop *abuse* scenes blocking HC2?

 

Quote

 

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. But obviously someone at fibaro thought it was worth it...

 

in last two years, and you have to know i'm responsible for Fibaro Support in Germany/Austria, we got "lot of" tickets with such scenes. I know Sankotronic spend lot of time, to debug and code,m and that was fine for HC2 - but ppl who using his work simply "adding something here and there" .

 

I have tons of Scenes which Need to be re-coded, that will be no fun. But i hope to re-think here and make them for HC3, to use Features included on HC3, instead of Fighting with all the old Things.

 

Btw, your Event Handler can be now coded with 10-20 lines of code, that's great, isn't?

 

Edited by tinman
Link to comment
Share on other sites

6 minutes ago, tinman said:

you can, but you don't have to, it is just an example

afaik that should do the trick, every day at 6 or sunrise (here + 180min as example for delay)

Please login or register to see this code.

 

It will trigger both at 06:00 and at sunset+180 I assume?

 

6 minutes ago, tinman said:

afaik the lua engine is checking all conditions and triggering only these which match, so at 15:00 is at 15:00, why do i have to do os.time to check it twice?

every, but why you need to know the time here? For log? debug? so do debug or send message or  emit event. Isn't better to have "VD" to see Events instead of check all the Scenes debug boxes or even worse to run another Scene collecting thousands of variables changed somewhere, like on HC2?

 

When it triggers at 15:00 I want to turn on a lamp. But when it triggers on 15:00 on Mondays I want to have the light on for 1 hour, on Wednesdays I want to have the light on for 2 hours.

How to tell the day? Well I have to split into two scenes... one for Mondays and one for Wednesday.

 

6 minutes ago, tinman said:

to be very honest, this is b****, why on earth you need os.time each every second? Again, feel free to notify you when it got triggered, see above

 

That's unnecessary language. There are many applications where one wants to do date and time calculations... 

 

6 minutes ago, tinman said:

to allow better triggering? to stop *abuse* scenes blocking HC2?

in last two years, and you have to know i'm responsible for Fibaro Support in Germany/Austria, we got "lot of" tickets with such scenes. I know Sankotronic spend lot of time, to debug and code,m and that was fine for HC2 - but ppl who using his work simply "adding something here and there" .

I have tons of Scenes which Need to be re-coded, that will be no fun. But i hope to re-think here and make them for HC3, to use Features included on HC3, instead of Fighting with all the old Things.

So that is the real issue? People pasting & cutting code they don't understand so it generates support issues? os.time() as such were never the issue, people that didn't know how to code were forced to do it. You're new event system conditions may solve that for them and they will use it - but why don't support os.time in addition?

People will do the same stuff in VDs now, a small victory. I believe that Sankotronics scene made the HC2 useful for far more people than it caused trouble. That statement feels a bit disrespectful both towards Sankotronic and the people having had it as the only guide to make something useful out of the HC2. 

 

How about making a distinction between developers and end-users?  The solution to your support tickets is not to break backwards compatibility on purpose to force everyone to re-start from a clean slate - but to provide better tools for end-user so they can move to easier ways to achieve their tasks. Provide tools for end-users like a good calendar/day scheduler for actions with a GUI that most other platform have? (with a better VD GUI Sankotronic could have made more of the Lua configurations being GUI click&select instead... but I digress). A more expressive block scene model where people can express things like "if condition X has been true for Y time do action Z". "true for"  turns out to be a very common criteria in home automation and in scenes people struggle to code.... A floorpan dashboard so they can place their devices and link them graphically ? They shouldn't need to see code in the first place. 

If that's a lot of stuff to do,  another approach is to provide better tools for developers to allow them to build these tools for end-users ... and it may attract new very skilled developers to the community.

 

Trying to convince people, that without compensation spend a lot of time and effort to provide functionality and support the community how to solve tasks that has been difficult to understand how to do on a HC2 (and HC3 in the future) - trying to convince them that limiting what they can do is good for them, is just... a bad strategy.

 

But maybe I'm just in the wrong place and  my expectations were unrealistic for this platform (and I did spend some 7 years hoping).

 

  • Like 1
Link to comment
Share on other sites

24 minutes ago, jgab said:

How to tell the day? Well I have to split into two scenes... one for Mondays and one for Wednesday.

 

get HC3 and find it out, or wait till Fibaro posted docs, but i think one scene can handle it 

 

24 minutes ago, jgab said:

I believe that Sankotronics scene made the HC2 useful for far more people than it caused trouble. That statement feels a bit disrespectful both towards Sankotronic and the people having had it as the only guide to make something useful out of the HC2. 

 

lot of people believe in lot of things, i don't mind. I can tell you - from support of view, it is disaster to explain over and over again why a Scene x or y stopped to work (e.g. because the developer forgot to check for HC Firmware Version in the Scene, or the user misunderstood some Settings). 
As Fibaro Trainer is already not easy to teach/prevent installers from such code mistakes, with typical (let say 90%?) customers even worse.

There are lot of mistakes one can made, i give you my top 5:

- no version check -> update and "smarthome" is gone
- thousands of always enabled debug messages
- dynamic Icons everywhere, playlist with even more icons

- timers for timers for timers ...
- hard coded things (e.g. IP, username/pwd) 

 

24 minutes ago, jgab said:

 

How about making a distinction between developers and end-users?  

 

24 minutes ago, jgab said:

They shouldn't need to see code in the first place. 

 

that's why HC3 is different, it is for users. Developer can make use of VD or much better trigger handling

 

24 minutes ago, jgab said:

But maybe I'm just in the wrong place and  my expectations were unrealistic for this platform (and I did spend some 7 years hoping).

 

no, you not. I developed some plugins and they got never implemented. I created custom firmwares for customers, and Fibaro closed backdors. I found new bakdoors and created new ways, Fibaro played "master" again. I did fighted since years to get Fibaro Mock Plugin for everybody enabled (a plugin which act/create real devices, pure fun), and wow Fibaro implemented (more or less similar solution) into HC3.

 

Now let's hope together: with HC3 we all have to start from scratch, BUT we will need less time/tools to make customers/installers happy.

  • Like 1
Link to comment
Share on other sites

Is Tinman JOKING????????????

" Now let's hope together: with HC3 we all have to start from scratch, BUT we will need less time/tools to make customers/installers happy"

After one year my house is automated and the most things are working good.

Does he think that I will start this job again?

Easy thinking.

If this job has to be done again why not open source?

As long as HC2 will  run I am happy.

Perhaps when its finished there will/can be other solutions to choose.

Question will be how long Fibaro will support HC2 ( I think not long)

Succes all

  • Like 1
Link to comment
Share on other sites

27 minutes ago, Sjakie said:

Is Tinman JOKING????????????

 

no, never.

 

So you think open source will migrate your - as you said - working HC2 to not yet available HC3 and fix all potential problems?

Ok, please start coding now, and let me know when you have something on github

 

Link to comment
Share on other sites

Sorry I expressed myself wrong.

Am I a customer from Fibaro? Answer should be >>yes.

Support HC2 5 -10 years? is normal after introducing new device.

 

If not I dont feel myself customer but abandon by Fibaro!!!

 

If that happens bye bye Fibaro and move to something else Zwave in open source orso Homey.

Now you can comment they are not on the same level but that I will accept (in the hope they will not go the same route as Fibaro)

Perhaps I am not alone with this way of thinking.

 

  • Like 1
Link to comment
Share on other sites

I'm not sure you are the right person to have this dialogue with, but on the other hand I don't know who is - so I'll carry on.

8 hours ago, tinman said:

get HC3 and find it out, or wait till Fibaro posted docs, but i think one scene can handle it 

I have access to HC3, you have access to HC3, it takes 1 minute to verify that this doesn't work. Not very supportive.

Do they have some unknown operator you can throw into the condition section to solve it? I don't know, but I'm telling you it doesn't solve the underlying problem. 

And I don't understand the completely unnecessary defensive position?

I tried to be constructive and suggest a solution (remember the event that made the condition true) and let developers retrieve that event (let's call the function fibaro.getConditionEvent()) in the action section. (and then give back os.time/date). Keep end-users happy with the new blocks scenes and provide something a little bit more useful for developers. win-win-win.

The scene Lua environment has been stripped down to the bare minimum now needed to compile block scenes. In the future if they want to extend the block model with more interesting actions they will realise that my suggestions above are actually quite handy... trust me.

 

8 hours ago, tinman said:

that's why HC3 is different, it is for users. Developer can make use of VD or much better trigger handling

No, it's not much better trigger handling. It's just different, different in a way that supports blocks and limiting in a way it supports Lua coders. There are some new type of events, but everything that can be expressed with this condition structure could be done in the "action sections" by Lua coder in the past. The condition "throws a net" to catch events - but we would like to know what specific fish/event we got in the net. That's a reasonable request from developers and it's not helpful to call our wishes b*****

All the "problems" will just move into VDs... (VDs, or should we call them QuickApp Devices, QDs ?)They  are an improvement as they are now first class citizens in the framework. However there are some other issues I will come back to in another post. For now, when Lua developers can't code scenes anymore they will move that functionality into QDs and be a "device category" and have a device number which doesn't make any sense at all unless you really are a device. And there will be customers that will cut and paste "QuickApp code" because they couldn't achieve what they wanted with block scenes - rinse and repeat.

 

8 hours ago, tinman said:

lot of people believe in lot of things, i don't mind. I can tell you - from support of view, it is disaster to explain over and over again why a Scene x or y stopped to work (e.g. because the developer forgot to check for HC Firmware Version in the Scene, or the user misunderstood some Settings). 
As Fibaro Trainer is already not easy to teach/prevent installers from such code mistakes, with typical (let say 90%?) customers even worse.

We customers/community are really a nuisance to you installers/support people, aren't we? 

These are all issues that could have been mitigated by better communication and support to the community.

Nothing I see in the HC3 is changing this if you hope your support task will be easier. Problems are just swiped under the carpet.

It's never easy to support customers, but is even worse to be the support person that have to say to the customer that she must re-boot, re-install the operating system, and go out and buy new apps - no love there (haven't seen this since the 80's)

 

8 hours ago, tinman said:

There are lot of mistakes one can made, i give you my top 5:

- no version check -> update and "smarthome" is gone
- thousands of always enabled debug messages
- dynamic Icons everywhere, playlist with even more icons

- timers for timers for timers ...
- hard coded things (e.g. IP, username/pwd) 

All these issues fall on fibaro's side - customers are not to blame. Could have been fixed under the surface + better communication to community and better high level tools.

Why isn't there a best practices and recommendations sections in the forum the educate the community on these points and other - you had 7+ years to do it.

Supporting the same customer issues over and over again and hope for an improvement is the definition of insanity (Einstein).

And what of this is alleviated with HC3 environment?? Nada.

As I have seen the main complaint when people upgrade their box is that all their devices disappears or get new device numbers (never happened to me) - I've not seen any of the "widely " used scripts making nearly as much havoc after an upgrade.

8 hours ago, tinman said:

no, you not. I developed some plugins and they got never implemented. I created custom firmwares for customers, and Fibaro closed backdors. I found new bakdoors and created new ways, Fibaro played "master" again. I did fighted since years to get Fibaro Mock Plugin for everybody enabled (a plugin which act/create real devices, pure fun), and wow Fibaro implemented (more or less similar solution) into HC3.

And your point being? Because you are "chosen" and can play with undocumented APIs that we mere mortal can only dream about - we should sympathise? 

8 hours ago, tinman said:

Now let's hope together: with HC3 we all have to start from scratch, BUT we will need less time/tools to make customers/installers happy.

You wish... there will be no "less" of anything...

38 minutes ago, Sjakie said:

Is Tinman JOKING????????????

No, but I don't think he's representative for fibaro in general... he's just sitting on the support side and probably had a rough couple of years as it sounds. The problem with support is that their easy solution is always to remove features that cause trouble.

  • Like 3
Link to comment
Share on other sites

49 minutes ago, jgab said:

All these issues fall on fibaro's side - customers are not to blame. 

 

i think there will be no way to have any constructive discussion with you ?

 

 

49 minutes ago, jgab said:

you are "chosen" and can play with undocumented APIs that we mere mortal can only dream about - we should sympathise? 

 

probably? sure? it is up to you. But hey, there is a way for you as well to be "chosen one", just start reading / digging, not just complaining 

 

Link to comment
Share on other sites

 

 

I just bought intensis air conditioning control devices. If I buy the hc3, will I have to wait to develop new QDs for it? Since there were no more DVs?

Link to comment
Share on other sites

@jgab
Keep fighting even if it blows against the wind sometimes.
If Fibaro had had a product developer with your capacity and knowledge then HC2 would also have become a game changer.
Your creation "EventRunner 3" made my and many others' home automation so much easier and safer.

  • Like 5
  • Thanks 1
Link to comment
Share on other sites

6 hours ago, RH_Dreambox said:

@jgab
Keep fighting even if it blows against the wind sometimes.
If Fibaro had had a product developer with your capacity and knowledge then HC2 would also have become a game changer.
Your creation "EventRunner 3" made my and many others' home automation so much easier and safer.

Completely true!

  • Like 2
Link to comment
Share on other sites

Easy, gentlemen.
First the fibaro.getSourceTrigger this function exists and will appear in 5.021

os.time() will be there

Link to comment
Share on other sites

W dniu 22.01.2020 o 10:18, Sjakie napisał:

After one year my house is automated and the most things are working good.

Does he think that I will start this job again?

Easy thinking.

If this job has to be done again why not open source?

As long as HC2 will  run I am happy.

Perhaps when its finished there will/can be other solutions to choose.

Question will be how long Fibaro will support HC2 ( I think not long)

Succes all

 

 

Sorry I expressed myself wrong.

Am I a customer from Fibaro? Answer should be >>yes.

Support HC2 5 -10 years? is normal after introducing new device.

 

If not I dont feel myself customer but abandon by Fibaro!!!

 

If that happens bye bye Fibaro and move to something else Zwave in open source orso Homey.

Now you can comment they are not on the same level but that I will accept (in the hope they will not go the same route as Fibaro)

Perhaps I am not alone with this way of thinking.

 

HC2 has been on the market for 8 years, during this time we have improved the hardware several times, I think it is not a bad result.
Does the start of HC3 mean that HC2 will not receive any more updates? No, it is not a true

Link to comment
Share on other sites

On 1/21/2020 at 1:20 PM, A.Socha said:

for example for button with 1 press

Please login or register to see this code.

 

@A.Socha

Is there a way to update these conditions on the fly (via api or some other method )

Link to comment
Share on other sites

Godzinę temu, AutoFrank napisał:

 

@A.Socha

Is there a way to update these conditions on the fly (via api or some other method )

There is always option to send put on scene, but why you want to do that? chengeing self scene from the scene it will never be good solution? maybe we can achieve what you want in another way

 

Check conditions from more devices and later check by getsourcetrigger 

Link to comment
Share on other sites

@Socha,

HC2 has been on the market for 8 years, during this time we have improved the hardware several times, I think it is not a bad result.
Does the start of HC3 mean that HC2 will not receive any more updates? No, it is not a true

 

I am looking forward to receive updates for HC2 (for many years) and Iwill be a happy customer!

Thanks

Link to comment
Share on other sites

Thanks @A.Socha

I was looking at @tinman post 

 

-----------------

you can, but you don't have to, it is just an example

afaik that should do the trick, every day at 6 or sunrise (here + 180min as example for delay)

Please login or register to see this code.

 

It will trigger both at 06:00 and at sunset+180 I assume?

------------

and was thinking it may be handy to be able to change the trigger time/date 

 

only use case I can thing of at the moment and I could probably accomplish this other ways in the HC3 ....

HC2

I have a Alarm Clock (VD) and a wakeup routine (scene) I use the Alarm Clock (VD) to set and store the next wakeup time in a global

I then use @Sankotronic scheduler to trigger the wakeup routine the next morning based in the global

 

HC3

I was thinking I could update the trigger in the wakeup scene directly from an equivalent "Alarm Clock" QuickApp and cut out some of the middemen

 

 

 

 

Link to comment
Share on other sites

1 hour ago, AutoFrank said:

Thanks @A.Socha

I was looking at @tinman post 

 

-----------------

Please login or register to see this code.

 

------------

and was thinking it may be handy to be able to change the trigger time/date 

only use case I can thing of at the moment and I could probably accomplish this other ways in the HC3 ....

HC2

I have a Alarm Clock (VD) and a wakeup routine (scene) I use the Alarm Clock (VD) to set and store the next wakeup time in a global

I then use @Sankotronic scheduler to trigger the wakeup routine the next morning based in the global

HC3

I was thinking I could update the trigger in the wakeup scene directly from an equivalent "Alarm Clock" QuickApp and cut out some of the middemen

 

Allowing in substituting in globals with json expressions in conditions? Ex. fibaro.setGlobalVariable("myTime",json.encode({"00", "6", "*", "*", "*", "*" }))

Please login or register to see this code.

Added complexity is that they need to re-parse the condition to understand what triggers the condition every time a global involved changes value (like what I do in my %% time scene).

Users will probably come up with more and more complex requirements on the conditions section... Is there a way to express a condition that if a sensor is safe for a certain amount of time, then trigger?  (or a general sub-condition has been true for a certain amount of time)

Probably not a good idea to extend the condition expressiveness as it will be difficult to capture all kind of use-cases.  Better then to do additional tests in the action section of the scene using Lua.

Link to comment
Share on other sites

  • 1 year later...
On 1/23/2020 at 11:08 PM, A.Socha said:

Easy, gentlemen.
First the fibaro.getSourceTrigger this function exists and will appear in 5.021

os.time() will be there

I have 5.050 , still no getSourceTrigger  or GetSourceTrigger.

 

The problem isnt that everything has changed, its also that its not documented.  How about grabbing a standardized scene with all the old commands and convert it to HC3 and publish it.  Then there will be no more bitching.  I am busy converting my scenes and I keep hitting walls that takes days to resolve  !!!!!

Link to comment
Share on other sites

Well, it's a variable these days and called 'sourceTrigger'

From the Fibaro scene manual 

Please login or register to see this link.

Please login or register to see this code.

 

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