Programming help needed

[srjacob]

I need some advice on a program.  I have uploaded two screenshot.  PGM1 is the program that exists, but doesn't work as I intended. Yes, I am using the Elk plugin. 
 PGM2 (note the red parenthesis) is what I wanted to do, but there doesn't seem to be any way in the eisy programming language to do it.

Could some nice person tell me how to do this.

Steve

[Guy Lavoie]

In the Program content window (top window), click on "Add And (..)" at the bottom right corner. This will add two parenthesis  lines to your program. Then move the parenthesis lines up or down to where you want them.

[larryllix]

Also IoX has a nice provided feature to copy'n paste your programs to this website. It makes it much easier for posters to read and understand.

Right click on the program name in the tree, and select copy to clipboard in the falldown menu, then paste it into the code option box in your post.

[srjacob]

Copy and paste the program like this?

424Entered Copy Copy - [ID 0021][Parent 0001]

If
       -(
       |     'First Floor / Back Door' Logical Status is Violated
       |  Or 'First Floor / Kitchen Door' Logical Status is Violated
       |  Or 'First Floor / Front Door' Logical Status is Violated
       |  Or 'Basement / Basement Door' Logical Status is Violated
       -)
    And $Away_Off is 1
 
Then
        Send Notification to 'Email' content '424Entered'
 
Else
   - No Actions - (To add one, press 'Action')
 
Send "424 Entered" message if "Away Off" was triggered by garage keypad.

The parenthesis seems to work, too.

I wish there was some way to embed IF statements in the THEN block (like other programming languages).

Thank you for your help.

[Geddy]

On 8/29/2025 at 8:01 PM, srjacob said:

I wish there was some way to embed IF statements in the THEN block (like other programming languages).

While not exactly a “IF” in the “then” portion, but you can run/call another program in the “then”  which contains an “IF” statement that you would want to run/evaluate. One trick is to have that other program (the second) disabled so it is only triggered by the first program to evaluate. I do this often with trigger programs for other programs that have waits in them. Since a program would re-trigger during the wait if it was in the first program and not end if it went false. 

[srjacob]

Thanks.  I didn't know I could still run a disabled program.  That would simplify things.

[Geddy]

1 hour ago, srjacob said:

I didn't know I could still run a disabled program.

Yes. That helps having the program disabled by not allowing that "IF" condition to ever be evaluated until you call on it by another program. Just make sure it's not nested in a folder that has false folder conditions - that can keep any program in that folder from running.

Often times people use the underlying program to only run "Then" or "Else" actions, but also being able to run the "If" allows that to be evaluated in case it needs to cause another action. 

The tricky thing becomes knowing that it will only evaluate when called by the first program and not ongoing. If it's something that might happen over a period of time you might need repeats or other triggers. It's a good process, but takes a little testing for fine tuning depending on the first program.

https://wiki.universal-devices.com/ISY-99i/ISY-26_INSTEON:Add_to_Program#Action

I also like being able to enable and disable programs this way. 

[srjacob]

It would be really nice if I could write a Python (or Java) program to do the conditionals.  Any way to do this?

Regarding your comment about repeats or triggers, I use variables as flags (I am an old programmer).

 

[apostolakisl]

2 hours ago, srjacob said:

Thanks.  I didn't know I could still run a disabled program.  That would simplify things.

Disabling a program only prevents it from self-triggering.  Other programs (or manually) you can instruct it to run if and it will follow through to the then or else.  Or you can directly run then then/else clause from another program.  This effectively is an embedded "if" clause.  You organize using folders and comments so that when you come back to it in a few years, you aren't trying to figure out what you did.

[srjacob]

Is there a way to comment each line of a program?  That would be really nice.

[Guy Lavoie]

15 minutes ago, srjacob said:

Is there a way to comment each line of a program?  That would be really nice.

I've wished for that too.

[apostolakisl]

15 minutes ago, srjacob said:

Is there a way to comment each line of a program?  That would be really nice.

You can add as many comments as you want.  They show up as blocks in between each line of code.

[larryllix]

7 hours ago, srjacob said:

Is there a way to comment each line of a program?  That would be really nice.

You can comment lines between lines and also comment the whole program. These are found in different portions of the edit boxes.

[larryllix]

8 hours ago, srjacob said:

It would be really nice if I could write a Python (or Java) program to do the conditionals.  Any way to do this?

Regarding your comment about repeats or triggers, I use variables as flags (I am an old programmer).

 

I use STATE variables to trigger almost all lighting scenes, also. When I want to "borrow" a lighting setup (eg: flash lights) I only need to save the existing value, replace with another value, and then after a delay replace the original value back into the control variable.
Also, with mostly WiFi lighting, with no available feedback, I always know what the last lighting scene I left things at is.

Using STATE variables for lighting controls makes things so easy to program, from multiple sources, once the bank of drivers is created and tucked away in a folder.

[Geddy]

23 hours ago, srjacob said:

It would be really nice if I could write a Python (or Java) program to do the conditionals.  Any way to do this?

HA! Highly doubtful since ISY programming has been the same for many years. I only started with the ISY994, but some here go way back to ISY-26. To change it now would break everything that's been done since the early 2000s. But you can always ask UD directly. Use their "Contact Us" link on their website. But I doubt it will get much though (only based as a user that would be completely lost if changed to a programming language). 

Let's face it...you've even been a member here since 2009, so you go back a ways. Why change now? There's no driving force to change and what's being done works. 

[apostolakisl]

6 hours ago, Geddy said:

HA! Highly doubtful since ISY programming has been the same for many years. I only started with the ISY994, but some here go way back to ISY-26. To change it now would break everything that's been done since the early 2000s. But you can always ask UD directly. Use their "Contact Us" link on their website. But I doubt it will get much though (only based as a user that would be completely lost if changed to a programming language). 

Let's face it...you've even been a member here since 2009, so you go back a ways. Why change now? There's no driving force to change and what's being done works. 

If there were enough people using this system, someone might be able to write a compiler to translate python or whatever language to "ISY".  

[Guy Lavoie]

14 hours ago, apostolakisl said:

If there were enough people using this system, someone might be able to write a compiler to translate python or whatever language to "ISY".  

The problem with that is that the programming model is too different. There is very little conditional branching in ISY. Essentially, its just THEN and ELSE. Then there is no nested logic at all (If...then if), instead you need to create separate programs that interact through variables. Creating such a compiler would be an exercise in artificial intelligence 😉

[hart2hart]

The only update I would like in programming is synchronous execution for runif. As in wait for called program to exit/return before going to next step in current program.

[srjacob]

And yet plugins are written in a programming language (possibly Python), not the silly programming that UD has created over the years.

Another thing (one among many) that annoys me: UD has forced everyone to use DHCP instead of static IP addresses.

[Geddy]

2 minutes ago, srjacob said:

And yet plugins are written in a programming language (possibly Python), not the silly programming that UD has created over the years.

Apples & Oranges! Plugins do vastly different things than "simple" automation programming. So it has to be in a more traditional programming language. Thankfully, it pulls devices into the IoX world that the "simple" automation can be programmed with infinite variables that we all enjoy having the option to manipulate how we see fit. It's wonderful to have options outside sometimes limited apps for other "automation" systems.

 

4 minutes ago, srjacob said:

Another thing (one among many) that annoys me: UD has forced everyone to use DHCP instead of static IP addresses.

This was certainly UD driven, but as a result of "user error" in the time of the ISY994 (and maybe prior). You can find endless posts on the forums and probably even hundreds more support tickets that UD had to handle for people that set static IP in the device then changed their home router and ended up with a different DHCP table. In an effort to limit the total time and energy spent on the support tickets UD did the right thing (IMO) to force the device into automatic DHCP and then allow those that have the need/desire/skill to set a simple IP reservation in the router to achieve the same goal of a "static" IP. I don't blame UD for that one bit. It's been this way since the Polisy came out (almost 6 years ago) so really a moot point to be complaining/commenting about this far out from that change (again IMO). 

[Guy Lavoie]

43 minutes ago, srjacob said:

And yet plugins are written in a programming language (possibly Python), not the silly programming that UD has created over the years.

 

You need to understand that this programming model provides a multitasking language (not operating system). It is based on the ladder logic model that programmable logic controllers have used for decades. The interpreter loops constantly, looking for any changes in status (of devices, state variables, time of day, etc) that warrants executing a THEN or ELSE statement. It simulates being everywhere at the same time. You'll find the same programming model in other home automation devices, such as the Elk M1, Ocelot, JDS Time Commander and such. 

I wouldn't want it any other way.

[srjacob]

I simply don't agree, when UD doesn't give you the option.  DHCP isn't always right for some advanced users, and you can't do IP address reservation in most cable-company supplied cable modem/routers simply because they won't give you the password because they don't want a user monkeying around with their router.  IoX was supposed to fix that problem, but (in my experience-and this is documented) sometimes IoX will not find the eisy (or 994), and if you don't know the IP address, you are out of luck.  UD could  have made DHCP the default, but give the advanced user the ability to set the IP address with some difficulty (like logging into the device using PuTTY).

And yes, plugins are not the same as simple automation programming, but as I mentioned above, give the advanced user the option of writing plugins or sophisticated automation programs (without the high developer fees).  Plugins are interesting, because they take the burden of development and support away from UD.  If I could write my automation programs in a programming language (say C or Python), I could eliminate half of them.

And speaking of plugins, support is terrible.  I have been trying to get in touch with the Elk plugin developer for a while, now.  I would dearly like to modify the code for that plugin to give the the user Id of the user that typed their code into the keypad on my gate (which the Elk controls), but the plugin won't do it.  I was considering writing a simple program for a Raspberry Pi to do this, but didn't do it.  The communication between the plugin and the Elk is well documented.

The firmware in these controllers is simply a carryover from the earlier ones (think ISY99), and everything else is simply an add-on (like PGXV3) and the plug-ins.  The entire framework needs to be re-designed and re-written.  PGX is simply silly, and they entire framework should be incorporated in the admin console, which should be written in something like Python, not Java (they probably pay huge royalties to Oracle).  Java is becoming a dead language thanks to the high fees by Oracle (who now owns Java).  Even browsers are moving away from Java (think HTML5), and even Android (I don't know much about IOS) doesn't use Java (and probably never will).

A good model (which may or may not have been designed) is Octoprint, which seems simple and straightforward to use and add plug-ins.

I never used Polisy, since my ISY994 was working great with firmware V5 and the only reason I went to eisy was for a hardware backup to the 994.  I have a spare ISY994, but with no ability to install the Elk module, I'll use it in some other application.

I have been in the IT business for over 50 years, and my last job before I retired was that I headed up the IT Architecture and Engineering Division for a major airline.  I have spend years uncovering why programs (and systems) didn't work, and once I reverse engineered the design, it became apparent why the problems were occurring.  I believe it is this way with the UD stuff.  I once taught a class in client-server computing at a major university, and since every computer class required the students to write a program pertaining to the class, I requested that the students submit the program DESIGN before coding anything.  I got a lot of blank stares, and finally someone in the back of the room raised their hand and asked "what is a design".  I spend the bulk of the class showing various design techniques, and they finally got it.  I had a former boss considering my philosophy of design "quaint".

I could go on, but I won't.

Steve

Senior Life Member of IEEE.

[srjacob]

Being used for decades doesn't mean that the model is currently correct, only that it has been used for decades.  The Elk M1 programming kinda sorta follows this model, but it's scheduler doesn't seem to work in the same way as the UD scheduler.  IMHO, the Linux scheduler works MUCH better than either of these two,  and is more logical.  The scheduler is Windows isn't bad (I don't know much about Apple).  My guess is that the OSs for these controllers was written in the days of old, slow processors.  Probably someone took Unix and took out most of the code because it wouldn't fit in the processor.  Modern (even in the days of the ISY994) weren't old and slow, and not much effort was given to rewriting them for Linux.  The best RTOS (real-time operating system) was Multics, but Unix (Linux is based on Unix) developers took out much of the code because it wouldn't fit inside a PDP-8.  UD needs to clean up their code and import it to Linux.  My ISY994 took 1/2 the time to get working as the eisy did, which included the Elk module.  What I want in a controller is bulletproof software, not some spaghetti code jobby.  The UD controllers don't even have good tracing or diagnostic capability (select the level of diagnostics you need).  Also, the documentation leaves much to be desired.  Wiki isn't the best for documentation.

I have seem too much of this type of thing in modern programming.  I am getting tired of these conversations.  So far, I have encountered 6 bad websites due to bad programming.  Perhaps AI (the real thing is in short supply) can do a better programming job .  What it can't do is documentation and design, which are sorely lacking.

Steve