Don't want to open this can of worms but curious about the ISY part of the PolIsy

[Bumbershoot]

21 hours ago, Michel Kohanim said:

ISY is currently running on Polisy extremely well and very fast!

I think this will be important.  My ISY gets pounded by Polyglot/Z-Wave/Insteon data, which I think will only get worse.  My hope has always been that the Polisy will chew through all the data, basically instantaneously.  Modern wired/wireless networks can handle higher speeds, the question for me is if my Insteon and Z-Wave networks can handle higher data throughput.  I hope so.

38 minutes ago, Michel Kohanim said:

As I mentioned before, we'll do our utmost to support our existing customers with existing devices (as we always have).

I've got spares of every Insteon device I have installed (save the SyncroLinc), and a couple spare PLMs.  I've never had an Insteon device fail, so I think I'm good for as long as I stay in this house.  That said, all my new devices have been either Polyglot devices or Z-Wave.  I'm not looking to grow my Insteon installation, but am hoping instead that Z-Wave and Polyglot device performance improves so I can replace Insteon if need be (though I'd miss the KPLs).  I hope/suspect that performance improvements across all device types will become realized on the Polisy platform.

[bpwwer]

I'm just going to drop this here.  

Would UDI be willing to support an open source Insteon node server development project?  With the existing group of node server developers, I'm sure there are a few of us that would be willing to contribute time/effort to developing a node server for Insteon. If UDI is willing to support the effort by providing existing nodedefs, etc. and possibly access to existing ISY Insteon code, that would provide a good starting point.

I fully understand the issue that UDI has with Insteon.  When it was new, I spent a lot of time trying to create a set of Insteon tools for Linux.  I gave up when I found the ISY because UDI's effort was much farther along and a lot more stable than what I had working at the time.

Developing for Insteon is painful, but, like others here, my house is using mostly Insteon so I'll likely devote some time/effort to supporting it, if only for my own use.

[Michel Kohanim]

@bpwwer,

Absolutely!

With kind regards,
Michel

[Whitehambone]

@Michel Kohanim, please correct me if I am wrong, but here is how I see this.  The questionable future of UDI's Polisy integration with Insteon is NOT UDI's fault, it is Insteon's.  Insteon has not defined a path to the future.  Current Insteon products will be support through Polisy directly, or worse case, from Polisy through the ISY.  Future Insteon products may or may not be supported (if they even have any future products).  I had seen another post on UDI's Forum that seemed to imply that Insteon future is questionable at best.  I had hoped Insteon's limited product availability was only due to the COVID shutdowns.  

https://forum.universal-devices.com/topic/31292-insteon-being-discontinued/

 

[Michel Kohanim]

@Whitehambone,

Precisely! And, the ever increasing rumors (form multiple sources) of no longer supporting third party integration + complete lack of APIs/Specs, are just making it very difficult for us to embark on any new INSTEON endeavors.

With kind regards,
Michel

[whywork]

Network module, please.

[Teken]

Just now, whywork said:

Network module, please.

+1

Given all of the modules I have purchased there was a reason having specifically purchased the Network Module. As stated by others there are just some products / services that aren't supported. Which leads to the whole issue at hand which is there was never any talk about NOT supporting Insteon in Polisy. That is one of the major reasons I purchased and supported the Polisy hardware at launch! 

Having waited more than ten years for a real computer to replace the ISY Series Controller was the biggest ask from the community. ☝️

Now that its here, it seems that everything just keeps getting parsed down or removed . . . ?

The reality is if the Polisy hardware didn't have a direct path to mirror a 1:1 capability of the ISY Series Controller. The whole discussion of it being the direct replacement should have never come up. It should have been left as *Add On* to enhance the ISY Series Controller even if not ideal it would have probably resulted in less development and public grief. ?‍♂️ 

[Michel Kohanim]

@Teken

Exaggerate a little? 

1. Support is different than migration
2. Please read everything above again (twice more)

With kind regards,
Michel

[Teken]

29 minutes ago, Michel Kohanim said:

@Teken

Exaggerate a little? 

1. Support is different than migration
2. Please read everything above again (twice more)

With kind regards,
Michel

I don't believe anything stated up above by me is exaggerated. ☝️ I'm unsure the distinction you're trying to make with respect to support vs migration. I could quote everything you stated up above to prove my point. But, that's not why I offered my feedback as to the current state of affairs. I wanted to add my voice to the chorus of others wanting to see Insteon, and all of the ISY Series Controller modules be present.

When the Polisy is ready for migration . . .

If Insteon isn't even supported within the Polisy there's zero possibility for the same to be migrated!

This isn't semantics or a different point of view this is the reality of where the (Polisy) platform is.

[Michel Kohanim]

@Teken,

1. As mentioned, existing INSTEON is either native or node server with preference for the latter. Migration might not be included 
2. Network resources should work with the exception of binary payload (at least initially). Preference is to get rid of these modules and make everything a node server. Perhaps a generic node server for sending packets
3. ELK is already a node server
4. Climate is already there as node server with many more options
5. Z-Wave will be a dongle

Again, please do not hold us responsible for new INSTEON devices. At the moment, and without further information from SmartHome/INSTEON, we have no plans of supporting them natively. If we go the node server route, perhaps the developer him/herself might. But, then again, the rumors and indications point to the world where third party integration is not something being offered by SmartHome/INSTEON. 

Am I missing anything?

With kind regards,
Michel
 

[Teken]

3 minutes ago, Michel Kohanim said:

@Teken,

1. As mentioned, existing INSTEON is either native or node server with preference for the latter. Migration might not be included 
2. Network resources should work with the exception of binary payload (at least initially). Preference is to get rid of these modules and make everything a node server. Perhaps a generic node server for sending packets
3. ELK is already a node server
4. Climate is already there as node server with many more options
5. Z-Wave will be a dongle

Again, please do not hold us responsible for new INSTEON devices. At the moment, and without further information from SmartHome/INSTEON, we have no plans of supporting them natively. If we go the node server route, perhaps the developer him/herself might. But, then again, the rumors and indications point to the world where third party integration is not something being offered by SmartHome/INSTEON. 

Am I missing anything?

With kind regards,
Michel
 

@Michel Kohanim

So let me reiterate what you stated up above (at some point) in time all modules will exist in a Node Server form - correct? When you say Insteon could be native does the team have a 2413S PLM connected to the Polisy for serial communications?? As stated in the past, and now, no one is going to hold you or UDI responsible for the lack luster support offered by Smarthome / Smartlabs.

I don't always agree with the direction the company is heading but know your sincerity to find a common ground for all. ? 

The one point you didn't answer was my question about Steve Lee. If this needs to be taken off line that's fine by me but thought this important resource would have assisted the team / company in bridging information to support Insteon. 

 

[tmorse305]

2 hours ago, Michel Kohanim said:

As mentioned, existing INSTEON is either native or node server with preference for the latter.

Sorry if this is a dumb question but how would a node server communicate with Insteon devices?  I think of an NS as a bridge between 2 environments.  What would the 'other' Insteon environment be?  Maybe an ISY & PLM or an Insteon Hub but I suspect there will never be a way to talk to that.

[bpwwer]

30 minutes ago, tmorse305 said:

Sorry if this is a dumb question but how would a node server communicate with Insteon devices?  I think of an NS as a bridge between 2 environments.  What would the 'other' Insteon environment be?  Maybe an ISY & PLM or an Insteon Hub but I suspect there will never be a way to talk to that.

Not a dumb question.  Today the ISY has an Insteon node server built in.  It's a large part of the ISY firmware.  The ISY also has a z-wave node server built in.   You can think of an ISY as a couple of node servers with a node server framework and rule (programs) engine. For the Polisy, the idea is to separate the z-wave and Insteon node servers from the core framework/rules engine.  

A node server for Insteon would communicate with Insteon devices using the PLM.   However, by making it a separate node server, it removes some of the restrictions imposed by the current hardware and it would be possible to use a USB PLM or maybe even the HUB for the device communication.

 

[apostolakisl]

22 minutes ago, bpwwer said:

Not a dumb question.  Today the ISY has an Insteon node server built in.  It's a large part of the ISY firmware.  The ISY also has a z-wave node server built in.   You can think of an ISY as a couple of node servers with a node server framework and rule (programs) engine. For the Polisy, the idea is to separate the z-wave and Insteon node servers from the core framework/rules engine.  

A node server for Insteon would communicate with Insteon devices using the PLM.   However, by making it a separate node server, it removes some of the restrictions imposed by the current hardware and it would be possible to use a USB PLM or maybe even the HUB for the device communication.

 

But that would require a complete redo of programs and scenes containing an Insteon device.  I think that would be VERY poorly received.

[tmorse305]

32 minutes ago, bpwwer said:

A node server for Insteon would communicate with Insteon devices using the PLM. 

Thanks for the clarification, so the PLM would hang off of Polisy but be driven by the node server instead of the ISY portion of the firmware.

[larryllix]

14 minutes ago, tmorse305 said:

Thanks for the clarification, so the PLM would hang off of Polisy but be driven by the node server instead of the ISY portion of the firmware.

Yes, USB, Ethernet, or Serial port dongle. IIRC the polisy doesn't contain a serial port though driven by a "driver". The PLM is only a protocol converter, or type of modem. With three Ethernet ports the Hub could be used also.

[jwagner010]

+1 Network Module

+1 Insteon support.  Open source NS if Smarthome doesn’t support third party integration    

[tazman]

14 hours ago, Michel Kohanim said:

@Teken,

1. As mentioned, existing INSTEON is either native or node server with preference for the latter. Migration might not be included 
2. Network resources should work with the exception of binary payload (at least initially). Preference is to get rid of these modules and make everything a node server. Perhaps a generic node server for sending packets
3. ELK is already a node server
4. Climate is already there as node server with many more options
5. Z-Wave will be a dongle

Again, please do not hold us responsible for new INSTEON devices. At the moment, and without further information from SmartHome/INSTEON, we have no plans of supporting them natively. If we go the node server route, perhaps the developer him/herself might. But, then again, the rumors and indications point to the world where third party integration is not something being offered by SmartHome/INSTEON. 

Am I missing anything?

With kind regards,
Michel
 

I vote to support Insteon in at least the capacity that is here already.

I think a generic node server is a really good idea that could hopefully be just as good as the network resources.

[Whitehambone]

I am glad to hear about the progress and can't wait to try it out!  Thanks UDI team for your work.  I hope when released it will include the ability to support the Node Server developers.  

 

[apostolakisl]

I don't understand why native Insteon control needs to go away.  The vast majority of people who have ISY have Insteon devices.  The Insteon protocol is known by UD for all or nearly all of the devices sold.  If SH chooses to go mum on future products, so be it, that would only affect future purchases, not the already present installation of dozens if not hundreds of Insteon devices so many of us have.   We would all require a complete re-work if ISY goes to a node server for Insteon.  I am already going to have to re-do my Elk which is going to stop being native as well.  But at least with the Elk I am only looking at a handful of programs and no scenes.  With Insteon, I have hundreds of scenes/programs.  It would be like my ISY crashed and my backup was corrupt.  And how would that even work?  Would I have to factory reset every Insteon device and start from scratch?  How would the NS learn all the scenes already programmed into the devices?  And even if it could, you would still have to go through and figure out what was what and name them.  It would be a huge headache that would keep on giving for months as you find the things that didn't go as expected or whatever.

[bpwwer]

33 minutes ago, apostolakisl said:

We would all require a complete re-work if ISY goes to a node server for Insteon.  I am already going to have to re-do my Elk which is going to stop being native as well.  But at least with the Elk I am only looking at a handful of programs and no scenes.  With Insteon, I have hundreds of scenes/programs.  It would be like my ISY crashed and my backup was corrupt.  And how would that even work?  Would I have to factory reset every Insteon device and start from scratch?  How would the NS learn all the scenes already programmed into the devices?  And even if it could, you would still have to go through and figure out what was what and name them.  It would be a huge headache that would keep on giving for months as you find the things that didn't go as expected or whatever.

No necessarily. There's really no reason why an Insteon node server would create nodes that are different from the nodes created by the current ISY firmware. Thus, it should be possible to use a backup of the ISY to recreate/restore the Insteon nodes using an Insteon node server.

Scenes may be problematic. An ISY scene seems to be a superset of an Insteon scene/group and I don't know how those are linked in the current ISY firmware.  I don't know if it will be easy to split them apart such that an ISY scene can be composed of components from different node servers.

In general it should be possible to provide a migration path and I would hope that's being considered. 

[apostolakisl]

30 minutes ago, bpwwer said:

No necessarily. There's really no reason why an Insteon node server would create nodes that are different from the nodes created by the current ISY firmware. Thus, it should be possible to use a backup of the ISY to recreate/restore the Insteon nodes using an Insteon node server.

Scenes may be problematic. An ISY scene seems to be a superset of an Insteon scene/group and I don't know how those are linked in the current ISY firmware.  I don't know if it will be easy to split them apart such that an ISY scene can be composed of components from different node servers.

In general it should be possible to provide a migration path and I would hope that's being considered. 

Well a painless migration procedure would be fine.  If everything could be mapped over from one to the other then I would not complain . . . provided that it actually worked.  As for Elk moving over to a node server, it is my understanding that I will have to manually manage that, and I have assumed that moving Insteon over would be the same.

[bpwwer]

The issue with ISY modules is that they were written and designed before the concept of node servers so they're not manged the same as other "nodes".  Their internal representation in the ISY firmware is different.  So, yes, migrating from old ISY modules to new replacement node servers will likely always be a manual process.  

[apostolakisl]

2 hours ago, bpwwer said:

The issue with ISY modules is that they were written and designed before the concept of node servers so they're not manged the same as other "nodes".  Their internal representation in the ISY firmware is different.  So, yes, migrating from old ISY modules to new replacement node servers will likely always be a manual process.  

Simply put, I would never do that.  It would take all day and then some.  As I said, it is no different than if your ISY crashed and your backup was corrupt.  I don't think I am alone when I say that this creates a sense of great anxiety to even think about.

[bpwwer]

12 minutes ago, apostolakisl said:

Simply put, I would never do that.  It would take all day and then some.  As I said, it is no different than if your ISY crashed and your backup was corrupt.  I don't think I am alone when I say that this creates a sense of great anxiety to even think about.

Maybe a more simple way of putting this is that everything under the 'main' and 'program' tabs of the admin console can likely be migrated.  Things under other tabs (like Elk or modules under config) will probably not be possible to migrate without manual intervention.