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


The device friendly name


jack.daniels
 Share

Recommended Posts

Hi @FredrikKarlsson,

 

I must agree with you that HomeTable is not that convenient as it appeals at first but only because it is not possible to use naming in scene headers. Still, I use HomeTable almost from beginning of my journey with HC2 and can say that it saved me a lot of code corrections since most of my scenes does not use devices triggering unless really necessary.

 

Also it is true that I need to have opened code of my HomeTable when writing new code. Most of it I have now in my head, but still I need to check naming for some devices. I have more than 100 scenes on my HC2 of which most don't use devices as triggers. It is much easier for me to just edit scene that creates HomeTable and several more with devices triggers than all of this 100 scenes. Not to mention virtual devices in that respect.

 

Solution you suggested is also nice and maybe even better than HomeTable, but only if you have more scenes that use devices as triggers because you have to correct scene header anyway. But what to do with code in virtual devices since that code also refers to devices?

 

I'm at the moment looking to one more solution and that is to use REST API to get certain devices by code so user don't have to do any changes in code itself. Also this kind of solution will always include all relevant devices no matter are they removed from system or added recently. Of course this solution again has some disadvantages that I'm working on since in some cases filtering of devices is not enough and then there is a question of editing scenes headers without user intervention. This is possible to achieve with LUA since it has strong support for manipulating string and table data.

 

In one thing thou I can't agree with you and that is to avoid using JSON parsing. LUA is very fast scripting language with tables as main data structure and powerful functions for manipulating strings. Most of my global variables are now containing table structures but I haven't noticed any problems so far except elevated CPU usage which is not problem in my opinion. CPU is there to work and not idle. Mostly people are happy if CPU is utilized 1% - 10% and if it jumps over 50% then immediately they think that they have a problem. I just need my system to work, to calculate all the time, to control and to give feedback.

 

 

 

 

Link to comment
Share on other sites

Naming 100+ devices typically ends up with a hierarchical naming schema looking like a "home table"...

Maybe worth the performance penalty to autogenerate one scene that have all triggers in the header and then let that scene call other scenes (fibaro:startScene with fibaro:getSourceTrigger()) through some home brewed trigger management registry? (scenes max out on 10 simultaneous invocation so that's a limit...)

Dynamically patching headers in scenes have occured to me but tricky when people add and remove devices... 

Anyway, would be helpful if devices (and virtual devices) could be assigned a reference name not being the display name and those reference names could be used in the header. 

For now I have stuffed the devices' "Device description" field with json data to help me build the table. (Virtual devices are handled elsewhere) 

Something like this:

Please login or register to see this code.

 

Link to comment
Share on other sites

Guest FredrikKarlsson
10 hours ago, Sankotronic said:

In one thing thou I can't agree with you and that is to avoid using JSON parsing. LUA is very fast scripting language with tables as main data structure and powerful functions for manipulating strings. Most of my global variables are now containing table structures but I haven't noticed any problems so far except elevated CPU usage which is not problem in my opinion. CPU is there to work and not idle. Mostly people are happy if CPU is utilized 1% - 10% and if it jumps over 50% then immediately they think that they have a problem. I just need my system to work, to calculate all the time, to control and to give feedback.

 

Sure, I agree. I don't have a problem with my HC2s performance either, but I have seen other reports. And there is a thread on the forum on how to upgrade the controllers RAM and possibly CPU so not everyone seems to agree with us.

 

10 hours ago, Sankotronic said:

Also it is true that I need to have opened code of my HomeTable when writing new code. Most of it I have now in my head, but still I need to check naming for some devices. I have more than 100 scenes on my HC2 of which most don't use devices as triggers. It is much easier for me to just edit scene that creates HomeTable and several more with devices triggers than all of this 100 scenes. Not to mention virtual devices in that respect.

 

Wow. 100 scenes is a lot. Do you have an overview somewhere of what they all do (roughly)?  It would be fun to see what scenes could be about (especially if they are not mainly device trigger handling scenes).

 

8 hours ago, jgab said:

Maybe worth the performance penalty to autogenerate one scene that have all triggers in the header and then let that scene call other scenes (fibaro:startScene with fibaro:getSourceTrigger()) through some home brewed trigger management registry? (scenes max out on 10 simultaneous invocation so that's a limit...)

 

The performance impact is an issue, I am sure, but I am thinking that the main disadvantage of a "one device scene to rule them all" approach is that maintenance of the beast may become more and more of an issue as time goes on. I agree that it would get all the code to update once you change a device id into one scene, which facilitates management. But with all possible triggers of slightly more than 60 physical devices I am visualizing scrolling through pages and pages an enormous header for a while, updating it, and then again finding the correct line in an even longer "if.. then.. else if... " structure. It would work, I am sure, but it's not for me.

 

But you could also think about the issue that we are discussing here in a different way (perhaps). The issue that HomeTable and the solution of @jgab's above  is aiming to solve is maybe not so much the hassle of updating code. I have not done this myself, but I imagine that even if I had 50 device triggered scenes and all of them were triggered by one of the devices, updating the device ID in ALL the scenes would not take that long. And, change of device ID is really a very infrequent occurrence, at least for me, so I guess it would feel like a hassle at the time, but manageable. However, if only some of the scenes are affected by the device ID change, I would still have to go through them all. And for me, that would fell more pointless and annoying.

 

I guess I am convincing myself again that the issues we are discussing here may at least to a large extent, in my system, be solved through documentation, and some structured code. For me, updating scenes takes not time if I know which ones to update, and if I don't have to go through the entire scenes hunting for the parts that need updating.

 

 

Link to comment
Share on other sites

24 minutes ago, FredrikKarlsson said:

Sure, I agree. I don't have a problem with my HC2s performance either, but I have seen other reports. And there is a thread on the forum on how to upgrade the controllers RAM and possibly CPU so not everyone seems to agree with us.

 

Hi @FredrikKarlsson,

 

I upgraded my HC2 RAM from 1Gb to 4Gb, but not because was needed. I upgraded to see difference and I can say that that there is no much improvement. CPU is not possible upgrade because it is soldered on motherboard. Also I did RAM upgrade after my warranty expired.

 

29 minutes ago, FredrikKarlsson said:

Wow. 100 scenes is a lot. Do you have an overview somewhere of what they all do (roughly)?  It would be fun to see what scenes could be about (especially if they are not mainly device trigger handling scenes).

 

You can find presentation of what I'm working on and screenshot of my entire system here:

In my configuration I have Main scene FTBE (For Time Based Events) that take care of scheduled and repeating actions and runs other scenes, presses buttons on VD's, controls z-wave devices and influences complete system by taking care of timers like TimeOfDay, Darkness, Weekday, Month, Season etc. Running of Main scene is monitored by Watchdog scene that will inform me if Main scene stop running and will try to restart it automatically since it is core (heart) of my system. BTW Main scene and  Watchdog scene are the only two scenes on my system that are running constantly all other are started only when needed and they stop running after done with action.

 

Virtual Devices (VD) which you are ignoring in this debate have much greater impact on HC resources due to their Main loop code that is always running. They are main reason for elevated use of CPU resources and I have more than 50 of them. Also, devices ID is used in their code and has to be changed if any changes is made like hard reconfiguration, exclusion and inclusion etc. So in that respect I found HomeTable very useful since I have to edit only HomeTable scene.

 

Link to comment
Share on other sites

3 minutes ago, Sankotronic said:

BTW Main scene and  Watchdog scene are the only two scenes on my system that are running constantly all other are started only when needed and they stop running after done with action.

 

Hi @Sankotronic,

 

how about the VSL scenes? Those are running also constantly in my system :-)

 

Link to comment
Share on other sites

6 minutes ago, Bodyart said:

 

Hi @Sankotronic,

 

how about the VSL scenes? Those are running also constantly in my system :-)

 

 

Well that depend on your settings and if you leave in country with everlasting cloudy weather ;-)

Link to comment
Share on other sites

It doesn't rain often in NL, but when it rains it can rain for weeks :-)

 

Link to comment
Share on other sites

Guest FredrikKarlsson
34 minutes ago, Sankotronic said:

Virtual Devices (VD) which you are ignoring in this debate have much greater impact on HC resources due to their Main loop code that is always running. They are main reason for elevated use of CPU resources and I have more than 50 of them. Also, devices ID is used in their code and has to be changed if any changes is made like hard reconfiguration, exclusion and inclusion etc. So in that respect I found HomeTable very useful since I have to edit only HomeTable scene.

 

Yes, sorry about that. I admit that I tend to ignore VDs as I don't usually use them for much myself, and especially not main loop. I have a couple of VDs that lets me manually edit the content of globals in one way or the other from the app for instance but no main loop. Or manually start scenes under very special circumstances.

I have been looking into installing the Unifi controller VD though. Then I'll have a main loop :-).

 

The UHAS looks very comprehensive. Congratulations on some nice work!

Link to comment
Share on other sites

2 hours ago, FredrikKarlsson said:

 

Sure, I agree. I don't have a problem with my HC2s performance either, but I have seen other reports. And there is a thread on the forum on how to upgrade the controllers RAM and possibly CPU so not everyone seems to agree with us.

 

 

Wow. 100 scenes is a lot. Do you have an overview somewhere of what they all do (roughly)?  It would be fun to see what scenes could be about (especially if they are not mainly device trigger handling scenes).

 

 

The performance impact is an issue, I am sure, but I am thinking that the main disadvantage of a "one device scene to rule them all" approach is that maintenance of the beast may become more and more of an issue as time goes on. I agree that it would get all the code to update once you change a device id into one scene, which facilitates management. But with all possible triggers of slightly more than 60 physical devices I am visualizing scrolling through pages and pages an enormous header for a while, updating it, and then again finding the correct line in an even longer "if.. then.. else if... " structure. It would work, I am sure, but it's not for me.

 

But you could also think about the issue that we are discussing here in a different way (perhaps). The issue that HomeTable and the solution of @jgab's above  is aiming to solve is maybe not so much the hassle of updating code. I have not done this myself, but I imagine that even if I had 50 device triggered scenes and all of them were triggered by one of the devices, updating the device ID in ALL the scenes would not take that long. And, change of device ID is really a very infrequent occurrence, at least for me, so I guess it would feel like a hassle at the time, but manageable. However, if only some of the scenes are affected by the device ID change, I would still have to go through them all. And for me, that would fell more pointless and annoying.

 

I guess I am convincing myself again that the issues we are discussing here may at least to a large extent, in my system, be solved through documentation, and some structured code. For me, updating scenes takes not time if I know which ones to update, and if I don't have to go through the entire scenes hunting for the parts that need updating.

 

 

Well, the point was not to have one scene to rule them all... The idea was to have a scene that builds the "home table" and also creates another "proxy" scene at the same time (dynamically creating scenes through the web API has been described in other hreads). That proxy scene would have all the triggers in the header and dispatch the incoming events to other scenes according to a table maintained in the proxy (or a global var). Thus other scenes would not need to have triggers declared in their headers, they would just register with (ask) the proxy scene when they start up to get trigger events of certain types.... 

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.

 Share

×
×
  • Create New...