ISY994 and insteon

[KlausMikalson]

I am looking at getting the ISY994 to use with homeassistant and insteon switches, etc. I am also going to be purchasing an ecobee3 thermostat to replace my insteon thermostat. My question is in the following link for the ISY it state "INSTEON/X10 REQUIRES 2413S PLM NOT INCLUDED" Do I really need to buy this? Should I buy directly from universal devices? Does anybody on here have a setup similar to this? Thanks in advance for the help showbox.bio/ tutuapp.uno/ https://vidmate.cool/.

https://www.amazon.com/Universal-Devices-IR-Automation-Controller/dp/B00MDVW7HS/ref=sr_1_1?s=grocery&ie=UTF8&qid=1475086988&sr=8-1&keywords=ISY994Zw

 

 

[kck]

Yes - you will need an Insteon "modem" for any controller that accesses Insteon switches.  (This would apply even if you wanted to use direct HA to Insteon via their integration.)  I run an ISY that also talks to my HA so it sounds like you want a configuration like mine.  There are pluses and minuses to ISY vs pure HA Insteon but since I started with the ISY that is my current setup.  ISY has greatly improved their connectivity and opened it up via Node Servers but HA has that open connectivity as a fundamental premise.  On the other hand, HA is an open source project with all the lack of commercial support that implies.  I'd say the biggest differences in actual automation is that I find ISY's programming still more obscure that it needs to be.  They essentially use only what HA would call automations - i.e., a state machine oriented programming paradigm.  This is very good for a lot of home automation activities since it corresponds to how operations happen in the real world.  However, it is far too obscure and error prone if you actually have a need for what most folks would call a sequential "program".  HA has scripts as well as automations and those operate completely as a sequential programmer would expect.  Automations can invoke scripts so you get access to which ever programming model fits you immediate need.  A nice thing about running HA with ISY is that you can use HA for the script like operations and use the ISY for the more state machine like triggers.  Your thermostat can be controlled either via an ISY Node Server or directly via and HA integration.  However, if you are already planning to run HA then I'd go that route since otherwise you wind up with 3 separate entities in the loop to maintain and keep sorted.

[oberkc]

I have not used Home Assistant as a comparison, but I can say that I have never found the programming of the ISY to be a limiting factor.  While I accept that some find it counter-intuitive, and I accept the possibility that other approaches might take less time to learn, I have simply never ran into a scenario where the programing limited my ability to do what I wanted.  I would be quite surprised if there were things I could do on other platforms that could not be replicated on the ISY.

[kck]

Just to clarify:  I was not suggesting that there were things you could not do on an ISY that you could do on HA.  What I was observing is that there are 2 fairly different approaches to doing this sort of programming.  The ISY uses the state machine one while HA provides both a state machine one and a more traditional procedural one.  Each approach has its strengths.  HA allows using the approach that makes for the most understandable solution for a given problem.  I have programmed some pretty complex stuff on the ISY side of things before I had HA running.  Some of those things just get a lot simpler with a pure procedural approach.  Heck I used to take pride in entire complex programs in 1 liner APL code but it couldn't be my choice for maintainable code.   (Some of you old timer programmer types will know what I am talking about!)

Beyond this - If you are going to run HA in any case, then it will wind up with access to all your devices, even those not under ISY control.  So in that case locating most of the automation programming there will just be a lot easier.

[lilyoyo1]

1 hour ago, kck said:

Just to clarify:  I was not suggesting that there were things you could not do on an ISY that you could do on HA.  What I was observing is that there are 2 fairly different approaches to doing this sort of programming.  The ISY uses the state machine one while HA provides both a state machine one and a more traditional procedural one.  Each approach has its strengths.  HA allows using the approach that makes for the most understandable solution for a given problem.  I have programmed some pretty complex stuff on the ISY side of things before I had HA running.  Some of those things just get a lot simpler with a pure procedural approach.  Heck I used to take pride in entire complex programs in 1 liner APL code but it couldn't be my choice for maintainable code.   (Some of you old timer programmer types will know what I am talking about!)

Beyond this - If you are going to run HA in any case, then it will wind up with access to all your devices, even those not under ISY control.  So in that case locating most of the automation programming there will just be a lot easier.

You're explaining things are different but not saying anything at all in regards to how they are different.

I think it would help others if you have an example of how their programming allows you to do things that you can't do with the isy

[kck]

Sure.  I actually didn't intend to turn this into a system comparison - I was just trying to answer the original poster's question and assure him that there was at least one other person running things they way he seemed to want to run his.  Interestingly, just today I was listening to the latest HA podcast (there is one that has a new episode for every release) and their guest said he was running an ISY as his hub linked into his home assistant configuration - so there are at least 2 of us I guess.    Be clear, I support using the ISY and continue to recommend it so I don't want to be misunderstood.

The state machine model has lots of side effects to consider that many folks find confusing.  Look at for example the tutorials on how to write conditions.  Also, the flow of a program is interrupted by anything that causes a reevaluation of the trigger condition.  This is consistent with the state machine model but often not what a user who changes a state condition in the text of a program expects to happen.  Loops are very limited; subroutines are separate programs and actually schedule independently of the invoker which can cause surprises.  Loops and embedded if/then/else are difficult.  None of this is surprising if you really understand the state machine model but it isn't what most folks who have any programming background are familiar with.

The HA model has these attributes for their automations.  However, scripts are much the same as shell scripts or programs that most folks are familiar  with.  They run to completion, have unlimited length, multiple loops, multiple if/then/else, etc.  They can call other scripts in completely synchronous manner.  The HA model for automations also has more control over multiple triggering of an automation (think ISY program) in that you can specify if it should cause and abort and restart (the ISY model), ignore the new trigger until while the current invocation is running, or create a parallel second invocation.  They also recently added an optional "cool-down" interval between triggers that can cause a dead period after a trigger to handle in a simple manner debouncing triggers and the like.  I would say that the result is that you can get by with fewer scripts in the HA model for most cases than in the ISY model but certainly you can achieve the same result in either case.  Overall, if you look at the typical questions in the forum regarding programs that don't work as expected, most of them come from folks expecting script like behaviors.

Finally, my other point was that IF you are planning to run HA in any case, then I would suggest using ISY for scenes and state triggers related to the Insteon devices and doing the rest of the automations on the HA side since there will be devices in your home that the HA side will know about that the ISY doesn't (else why use HA at all - stay with ISY and Node Servers).  The total developer community on the HA side is huge with the result that you will be hard pressed to find a home automation related device that isn't supported with an integration.  The sheer size of that community makes it impossible to keep up with given the smaller ISY community.  The caveat is that it is a volunteer community for the most part (there is a core paid development staff but it is quite small).  However, that community is extremely responsive (I've had multiple issues resolved in literally hours to a couple of days when raised on their forums) and the code itself is all open so you can always look at it yourself for a quick patch if you are so inclined.  The release schedule for HA is every 3 weeks and these are generally very meaty releases so the pace of improvement is quite rapid.

As I said - I am still a fan of ISY but I am also a realist and the UDI guys have a niche they service well but for a lot of general hobby type users HA may well be a better choice for their core platform.