Nestor Posted January 20, 2015 Share Posted January 20, 2015 Enjoying setup of my ISY and getting my brain into a programming frame of mind once again. Though there are no real right ways or wrong ways to get the same results, some are more efficient, maybe even faster. Do you use a certain problem-solving approach in your programming, or do you cobble something together until it works? What do you do to keep the programs as small, flexible, and efficient as possible? Link to comment
Teken Posted January 20, 2015 Share Posted January 20, 2015 Enjoying setup of my ISY and getting my brain into a programming frame of mind once again. Though there are no real right ways or wrong ways to get the same results, some are more efficient, maybe even faster. Do you use a certain problem-solving approach in your programming, or do you cobble something together until it works? What do you do to keep the programs as small, flexible, and efficient as possible? For me its all KISS . . . Only if something needs more line of code to get the expected results do I even go down that path. Link to comment
oberkc Posted January 20, 2015 Share Posted January 20, 2015 I am like teken...simple is good. Use scenes when possible. Minimize number of programs. Minimize lines of code. Don't use variables when other options are available. Consolidate programs. Spend some time thinking about what you want to accomplish. Think about unintended consequences. Plan. If your requirement is to turn off the light 2 minutes after motion is detected, dont complain when the light turns off 2 minutes after motion is detected. (..but I turned it on manually!) Link to comment
Teken Posted January 20, 2015 Share Posted January 20, 2015 I am like teken...simple is good. Use scenes when possible. Minimize number of programs. Minimize lines of code. Don't use variables when other options are available. Consolidate programs. Spend some time thinking about what you want to accomplish. Think about unintended consequences. Plan. If your requirement is to turn off the light 2 minutes after motion is detected, dont complain when the light turns off 2 minutes after motion is detected. (..but I turned it on manually!) Oberkc, I swear you're such a poet! Link to comment
larryllix Posted January 20, 2015 Share Posted January 20, 2015 I have a few programs that manipulate State variables and result in programs being triggered. As much as this simplifies programs the logic flow is very obscure. I use this with caution but it is the true spirit of event driven software. Link to comment
Nestor Posted January 20, 2015 Author Share Posted January 20, 2015 I am like teken...simple is good. Use scenes when possible. Minimize number of programs. Minimize lines of code. Don't use variables when other options are available. Consolidate programs. Spend some time thinking about what you want to accomplish. Think about unintended consequences. Plan. If your requirement is to turn off the light 2 minutes after motion is detected, dont complain when the light turns off 2 minutes after motion is detected. (..but I turned it on manually!) What is the disadvantage of variables? Link to comment
oberkc Posted January 20, 2015 Share Posted January 20, 2015 All other things being equal, they violate my KISS principles. Otherwise, nothing. Link to comment
LeeG Posted January 20, 2015 Share Posted January 20, 2015 "What is the disadvantage of variables?" Compared to what? Variables are great when a variable is needed/useful. What would you use instead? Link to comment
larryllix Posted January 20, 2015 Share Posted January 20, 2015 Well thought out, and self-documenting variable names, are important for their usage to keep things understandable. State variables can get obscure because when you change the value of one you can trigger programs based on them and there is no apparent and obvious program flow by reading the program tree. In a mostly subroutine flow system they can make program flow branches especially hidden. Link to comment
Teken Posted January 20, 2015 Share Posted January 20, 2015 I can tell you from naming convention for variables make sure you identify them using (i) for Integer vs (s) for State. This will come into play when trouble shooting, debugging, and for at a glance selection. That is the first thing I did when this little (simple) nugget was told to me! When you break over 50 variables in your system having a good naming convention / schema is very important. Many people have been hood winked in trying to figure out why a program doesn't operate because they thought that variable they assumed they would recall was a state vs integer was indeed the opposite! Link to comment
Xathros Posted January 20, 2015 Share Posted January 20, 2015 "What is the disadvantage of variables?" Compared to what? Variables are great when a variable is needed/useful. What would you use instead? The instead would be the True/False status of a program. Useful mostly for boolean functions. My preference would be a variable instead of a program but there have been a few cases where using the state of a program seemed more elegant to me. For instance, if you have a program that sets a variable to 1 in the then and 0 in the else, the true/false status of the program is identical to the variable and unless your doing math with the variable's value, makes it just extra and unnecessary. For me a variable seems more flexible. It has a current and init value, can do math, has more than 2 possible values and if named well can actually help document a program. Mostly though, it's a matter of preference. -Xathros Link to comment
randyth Posted January 20, 2015 Share Posted January 20, 2015 I can tell you from naming convention for variables make sure you identify them using (i) for Integer vs (s) for State. This will come into play when trouble shooting, debugging, and for at a glance selection. That is the first thing I did when this little (simple) nugget was told to me! When you break over 50 variables in your system having a good naming convention / schema is very important. Many people have been hood winked in trying to figure out why a program doesn't operate because they thought that variable they assumed they would recall was a state vs integer was indeed the opposite! OMG, I'm going in and renaming all my variables now with a i_ and s_ prefix. Such a great idea. Such an obvious thing to do, too... no wonder I overlooked it. Link to comment
Teken Posted January 20, 2015 Share Posted January 20, 2015 OMG, I'm going in and renaming all my variables now with a i_ and s_ prefix. Such a great idea. Such an obvious thing to do, too... no wonder I overlooked it. Ha! I always find its the small things (details) that just make the user experience so much better. Much thanks goes out to the ISY forum members for enlightening me. ️ One would think this would be a obvious thing to do while creating such variables. I had assumed the system would do this for me. It only came to play when I started crafting lots of variables with similar names and found out I was picking the wrong ones! Sent from my iPhone using Tapatalk Link to comment
416to305 Posted January 21, 2015 Share Posted January 21, 2015 The hardest part for me is dealing with all the damn variables! As in environment variables. Like especially with motion. I have motion in my kitchen after dark turn on my Hue under counter lights if the main lights are off. Works fine of course, but maybe I don't want them to turn off once I leave the room, or maybe they were already on and I don't want motion to turn them off. Maybe I want them to stay off and keep it dark, etc etc. There's always so many little things you forget, that I find the easiest is not only KISS for programming, but for deciding how you want to set something up. Otherwise it gets so complicated, a simple motion light program turns into 10 different programs to account for different times of day, different conditions, variables, etc. Then when something goes wrong a few months later it's like damn now what does this program here do again and why do I have this set like this or that? Link to comment
Teken Posted January 21, 2015 Share Posted January 21, 2015 Then when something goes wrong a few months later it's like damn now what does this program here do again and why do I have this set like this or that? For lots of programs you should be using the notes section so you know whats going on. Link to comment
larryllix Posted January 21, 2015 Share Posted January 21, 2015 The hardest part for me is dealing with all the damn variables! As in environment variables. Like especially with motion. I have motion in my kitchen after dark turn on my Hue under counter lights if the main lights are off. Works fine of course, but maybe I don't want them to turn off once I leave the room, or maybe they were already on and I don't want motion to turn them off. Maybe I want them to stay off and keep it dark, etc etc. There's always so many little things you forget, that I find the easiest is not only KISS for programming, but for deciding how you want to set something up. Otherwise it gets so complicated, a simple motion light program turns into 10 different programs to account for different times of day, different conditions, variables, etc. Then when something goes wrong a few months later it's like damn now what does this program here do again and why do I have this set like this or that? Inline comments, at the end of each program line, was requested for v5 that could definitely help this problem. We'll see. With the advancement of programming complexity coming on the ISY, this feature will become much more important, also. Link to comment
stusviews Posted January 21, 2015 Share Posted January 21, 2015 A REMark would be very welcome Link to comment
Michel Kohanim Posted January 22, 2015 Share Posted January 22, 2015 Hi all, We already have that feature in our list. With kind regards, Michel Link to comment
Recommended Posts
Archived
This topic is now archived and is closed to further replies.