Nodeserver Migration to ISY on Polisy

[DennisC]

One other consideration is those of us running multiple ISY/Polisy, either has a production/development set up or at a main/vacation home. It's not bad at a nodeserver cost of $5, however if you are using a higher priced nodeserver or a subscription based one, it could get pricey.

Just something else to think about when pricing the nodeservers, not a complaint about having to pay for them.

[bpwwer]

17 hours ago, asbril said:

What will this mean for me as I use the following nodeservers :

• Kasa
• MyQ
• Lifx
• Notifications
• ISY-Inventory
• Time-Date
• Harmony Hub
• AVRemote
• Holidays Google

I make intensive use of most of these.

Will nodeservers,  that have not been updated to the "pay"  format, still be available in PG 3 ?

As I think I mentioned before, the goal is to have most of the existing PG2 node servers available in PG3, that's one of the gates to moving from a Beta product to a Production product.  Whether or not the PG3 version is free, is up to the node server author.

Like @Jimbostated, it's slow going because the node server authors are doing the conversion in their spare time.  

However, realize that you will be able to run both PG2 and PG3 on the Polisy (or PG2 on RPi), so you can continue using the PG2 versions for node servers that haven't been converted and switch over to PG3 versions as they become available and it makes sense to do so.

Eventually, support for the PG2 versions will disappear, and how quickly that happens, is again, dependent on the individual node server authors.  Because the production release date of PG3 is unknown, I expect to continue providing support (and bug fixes) for my PG2 node server for quite a while.  But any new node servers will be PG3 only and new features will be PG3 only.

[bpwwer]

5 hours ago, DennisC said:

One other consideration is those of us running multiple ISY/Polisy, either has a production/development set up or at a main/vacation home. It's not bad at a nodeserver cost of $5, however if you are using a higher priced nodeserver or a subscription based one, it could get pricey.

Just something else to think about when pricing the nodeservers, not a complaint about having to pay for them.

Currently, the node server license is tied to the Polisy so if you have multiple Polisys, you need multiple licenses.

However, you can run multiple copies of the same node server on the same Polisy under one license and one Polisy can manage node servers for multiple ISYs.

[hart2hart]

As I think I mentioned before, the goal is to have most of the existing PG2 node servers available in PG3, that's one of the gates to moving from a Beta product to a Production product.  Whether or not the PG3 version is free, is up to the node server author.
Like @Jimbostated, it's slow going because the node server authors are doing the conversion in their spare time.  
However, realize that you will be able to run both PG2 and PG3 on the Polisy (or PG2 on RPi), so you can continue using the PG2 versions for node servers that haven't been converted and switch over to PG3 versions as they become available and it makes sense to do so.
Eventually, support for the PG2 versions will disappear, and how quickly that happens, is again, dependent on the individual node server authors.  Because the production release date of PG3 is unknown, I expect to continue providing support (and bug fixes) for my PG2 node server for quite a while.  But any new node servers will be PG3 only and new features will be PG3 only.

It may be here somewhere but I can’t find it. What is architecturally different between PG2 and PG3 nodeservers? My old guess was that if ISY and Polygot are both on Polisy, node updates would be direct inside the box instead of via network. However, it sounds like standalone ISY can talk to PG3.

[asbril]

11 minutes ago, bpwwer said:

you will be able to run both PG2 and PG3 on the Polisy (or PG2 on RPi), so you can continue using the PG2 versions for node servers that haven't been converted and switch over to PG3 versions as they become available and it makes sense to do so.

Eventually, support for the PG2 versions will disappear, and how quickly that happens, is again, dependent on the individual node server authors.  Because the production release date of PG3 is unknown, I expect to continue providing support (and bug fixes) for my PG2 node server for quite a while.  But any new node servers will be PG3 only and new features will be PG3 only.

Thanks !!!!!!!!

[mbking]

When I'm ready to move my node servers from the ISY-994 to ISY on Polisy, do I simply change the ISY IP address and port in PG2?  Will this automatically add the nodes to the new ISY?  I can see doing this in the near term and then moving to the PG3 versions as they become available.

[randyth]

I actually think subscriptions (if reasonably priced) are OK because they keep the author interested in keeping their software functioning.

As for the current list of PG3 node servers, please ensure HarmonyHub and WirelessTag are ported over!

-Randy

 

[bpwwer]

27 minutes ago, hart2hart said:

It may be here somewhere but I can’t find it. What is architecturally different between PG2 and PG3 nodeservers? My old guess was that if ISY and Polygot are both on Polisy, node updates would be direct inside the box instead of via network. However, it sounds like standalone ISY can talk to PG3.

Good question!

At a high level, the ISY (standalone or running on Polisy) has an API that node servers use to interact with the ISY.  That API hasn't changed and is used by PG2, PG3, and NodeLink (and maybe some other stand alone node servers).

PG2, PG3, and NodeLink are all node server managers.  They sit between the ISY and node servers.  They provide some extra capabilities and handle some of the common tasks that node servers have to do.  For example, when a node server is installed, there are some files that describe the nodes that the node server will create. Those files need to be uploaded to the ISY.  The node server manager does that so each individual node server doesn't have to have the code to upload it's files.

From a high level architecture, PG2 and PG3 are very similar.  Both communicate with the ISY in the same way, both have similar user interfaces, and both provide a similar API to interact with the node servers.   PG3 supports all the same basic core functionality that PG2 does.  

The main differences are some new core functionality in PG3, a  lot of minor fixes and improvements and an improved API to interact with node servers.  Probably the biggest user visible change was adding support for licensed/purchased node servers.  A lot of the changes have to do with the internal structure of node servers with the goal to make them easier to write, easier to maintain, and more stable.   

There were internal design choices in PG2 that made it hard to improve and maintain compatibility. Some of that was tried when PGC was created but we just ended up with bunch of "if running on PGC do this, else do that" code in node servers. Given the scope of the changes, PG3 seemed like the right time to break compatibility to make node servers better going forward.

 

[hart2hart]

Good question!
At a high level, the ISY (standalone or running on Polisy) has an API that node servers use to interact with the ISY.  That API hasn't changed and is used by PG2, PG3, and NodeLink (and maybe some other stand alone node servers).
PG2, PG3, and NodeLink are all node server managers.  They sit between the ISY and node servers.  They provide some extra capabilities and handle some of the common tasks that node servers have to do.  For example, when a node server is installed, there are some files that describe the nodes that the node server will create. Those files need to be uploaded to the ISY.  The node server manager does that so each individual node server doesn't have to have the code to upload it's files.
From a high level architecture, PG2 and PG3 are very similar.  Both communicate with the ISY in the same way, both have similar user interfaces, and both provide a similar API to interact with the node servers.   PG3 supports all the same basic core functionality that PG2 does.  
The main differences are some new core functionality in PG3, a  lot of minor fixes and improvements and an improved API to interact with node servers.  Probably the biggest user visible change was adding support for licensed/purchased node servers.  A lot of the changes have to do with the internal structure of node servers with the goal to make them easier to write, easier to maintain, and more stable.   
There were internal design choices in PG2 that made it hard to improve and maintain compatibility. Some of that was tried when PGC was created but we just ended up with bunch of "if running on PGC do this, else do that" code in node servers. Given the scope of the changes, PG3 seemed like the right time to break compatibility to make node servers better going forward.
 

Thanks for great explanation!

[Goose66]

15 hours ago, randyth said:

I actually think subscriptions (if reasonably priced) are OK because they keep the author interested in keeping their software functioning.

Here's where I differentiate the pricing model. As others have posted, typically if I buy a device, I don't want to have pay monthly to control it. So I generally favor fixed pricing.

Looking at my nodeservers, Autelis Pool Control, Venstar Thermostats, Sony AVR, Bond, EnvisaLink, etc., I would likely charge a one-time fee of $15 or so and then you would get updates when I felt they were warranted, e.g., when new features were added to the device APIs.

But for MyQ and iAquaLink, these two take a certain amount of vigilance to keep running, because they used unauthorized APIs that the vendors play hot and fast with it to prevent access (or maybe just because they only have to support their own app). In these cases, there is more of a support role here, and a need for me, as a part-time hobbyist developer, to be "on call" to keep the nodeservers running. I would think a monthly or annual subscription would be a better case here because you can just about guarantee that there will be updates required, and you don't want the author disappearing for months until they can get around to updating the nodeserver for API changes (as is sometimes the case now ?).

[Goose66]

19 hours ago, hart2hart said:

It may be here somewhere but I can’t find it. What is architecturally different between PG2 and PG3 nodeservers? My old guess was that if ISY and Polygot are both on Polisy, node updates would be direct inside the box instead of via network. However, it sounds like standalone ISY can talk to PG3.

The decision to run on Polisy only is another architectural change in PG3. This is really going to take out a lot of complexity on managing dependencies and supporting different versions of languages. I can foresee a time when ISY and PG3 are both running on Polisy for the vast majority of users and the REST-based Node Server API is deprecated in favor of direct MQTT between the ISY and the "nodeserver manager" (call it Polyglot if you like). At that point, it would seem that the Polyglot Dashboard would be rolled into ISY Admin Console, as well.

[Jimbo.Automates]

I've also asked for the ability to only charge for big updates, instead of having to pay every month or year when fixes are not needed.

Sent from my Pixel 6 Pro using Tapatalk

[bpwwer]

3 hours ago, Goose66 said:

The decision to run on Polisy only is another architectural change in PG3. This is really going to take out a lot of complexity on managing dependencies and supporting different versions of languages. I can foresee a time when ISY and PG3 are both running on Polisy for the vast majority of users and the REST-based Node Server API is deprecated in favor of direct MQTT between the ISY and the "nodeserver manager" (call it Polyglot if you like). At that point, it would seem that the Polyglot Dashboard would be rolled into ISY Admin Console, as well.

True.

I believe the very long term plan is to combine ISY and Polyglot so it's just one piece of software and one user interface.

[randyth]

4 hours ago, Goose66 said:

Here's where I differentiate the pricing model. As others have posted, typically if I buy a device, I don't want to have pay monthly to control it. So I generally favor fixed pricing.

Looking at my nodeservers, Autelis Pool Control, Venstar Thermostats, Sony AVR, Bond, EnvisaLink, etc., I would likely charge a one-time fee of $15 or so and then you would get updates when I felt they were warranted, e.g., when new features were added to the device APIs.

But for MyQ and iAquaLink, these two take a certain amount of vigilance to keep running, because they used unauthorized APIs that the vendors play hot and fast with it to prevent access (or maybe just because they only have to support their own app). In these cases, there is more of a support role here, and a need for me, as a part-time hobbyist developer, to be "on call" to keep the nodeservers running. I would think a monthly or annual subscription would be a better case here because you can just about guarantee that there will be updates required, and you don't want the author disappearing for months until they can get around to updating the nodeserver for API changes (as is sometimes the case now ?).

I agree with the way you differentiate when you prefer one pricing model over the other. It makes good sense and, like anyone, I prefer the simplicity and (usually) lower long-term costs of paying only once. That said, even authorized APIs change/break and a ~$5 annual "insurance payment" to encourage timely fixes is not unpalatable to me.

[larryllix]

42 minutes ago, randyth said:

I agree with the way you differentiate when you prefer one pricing model over the other. It makes good sense and, like anyone, I prefer the simplicity and (usually) lower long-term costs of paying only once. That said, even authorized APIs change/break and a ~$5 annual "insurance payment" to encourage timely fixes is not unpalatable to me.

I prefer the pay once and done format. Small bugs fixes should be included in that once 'n done payment. v1.05 --> v1.09

However, when a new feature(s) is/are added, and a major revision digit would be increased,  a new sale should be completed. v1.05 --> v2.01  Some discount for previous version owners could be incorporated but may get  too complicated as devs would need to keeptrack of purchase history etc.

I don't like and avoid subscriptions with a passion and want the money done and know what I got for that money. If I don't pay my subscription, I don't want my system to stop working. IMHO, my purchased software product should continue to function at it's purchased capabilities.  Cloud services may be considered differently to compensate for server maintenance costs.

Edited October 30, 2021 by larryllix

[randyth]

1 hour ago, larryllix said:

If I don't pay my subscription, I don't want my system to stop working. IMHO, my purchased software product should continue to function at it's purchased capabilities. 

That is an excellent point.

But, what if your purchased node server stops functioning three years later due the manufacturer changing their firmware and/or API? Technically, one might argue that your purchased product still functions as well as it did on day one; it is the device that stopped working as it used to, due to no fault of the node server developer.

So, is a developer with no formal ties to the device manufacturer (and therefore no direct income from the sale of the devices) obligated to fix your one-and-done purchase of their node server so it continues to function at its "purchased capabilities?"

 

[larryllix]

That is an excellent point.
But, what if your purchased node server stops functioning three years later due the manufacturer changing their firmware and/or API? Technically, one might argue that your purchased product still functions as well as it did on day one; it is the device that stopped working as it used to, due to no fault of the node server developer.
So, is a developer with no formal ties to the device manufacturer (and therefore no direct income from the sale of the devices) obligated to fix your one-and-done purchase of their node server so it continues to function at its "purchased capabilities?"
 

No. If a manufacturer changes something that removes capabilities then it is the fault of the device mfg.

If the NS dev releases a new NS version to support the changes then it would be a fresh NS sale, at the dev's discression. I think that would be fair. If the dev has no interest or disappears then the users are SOL at the hands If the device mfg. Again, the NS dev could offer sympathy prices for previous owners.

Sent from my SM-G781W using Tapatalk

[Goose66]

3 hours ago, larryllix said:

No. If a manufacturer changes something that removes capabilities then it is the fault of the device mfg.

If the NS dev releases a new NS version to support the changes then it would be a fresh NS sale, at the dev's discression. I think that would be fair. If the dev has no interest or disappears then the users are SOL at the hands If the device mfg. Again, the NS dev could offer sympathy prices for previous owners.
 

So something like EnvisaLink you pay $15 once and your done and you might get bug fixes/minor improvements. If a new EnvisaLink comes out with more functionality, you can get a new nodeserver. But something like Ring or MyQ or Ecobee you could be looking at $15 every year or two for basically the same nodeserver if the manuf. changes the API.

[larryllix]

1 hour ago, Goose66 said:

So something like EnvisaLink you pay $15 once and your done and you might get bug fixes/minor improvements. If a new EnvisaLink comes out with more functionality, you can get a new nodeserver. But something like Ring or MyQ or Ecobee you could be looking at $15 every year or two for basically the same nodeserver if the manuf. changes the API.

Some manufacturers can upgrade their firmware and there is nothing you can do about it. That would be unfortunate. People should have a choice of staying where they are or upgrading to new features.
A really unfortunate example of this is Android phones and iPads. When they want you to but new hardware they just force obsolescence on our device and the things you paid for quit working so you have to buy new hardware.

[Goose66]

12 hours ago, larryllix said:

Some manufacturers can upgrade their firmware and there is nothing you can do about it. That would be unfortunate. People should have a choice of staying where they are or upgrading to new features.
A really unfortunate example of this is Android phones and iPads. When they want you to but new hardware they just force obsolescence on our device and the things you paid for quit working so you have to buy new hardware.

I am agreeing with you - just laying out what expectations would be.

[bpwwer]

I believe that most of the devices that @Goose66is talking about never publish an official API.  They have an internal API that works with their apps(s) and the node server (or library it uses) has reverse engineered the API.

In this case, the manufacturer isn't under any obligation to notify customers when the API changes so the changes do cause a support problem for the node server.  I'm not sure what the "right" or "best" answer is for this.  Creating node servers using unofficial API's is potentially a headache for the developer and more expensive for the customer.  This is probably something we should do a better job of documenting.  Knowing the node server uses an unofficial API may deter people from buying that equipment in favor of supporting a different manufacturer that does publish an official API.

[MWareman]

… and one Polisy can manage node servers for multiple ISYs.

Does this require pg3 as well - or is it possible under pg2?

Currently, pg2 on my Polisy is connected to my physical ISY. However, I’m moving my Insteon devices to ISY running on Polisy and trying to figure out how to move the nodeservers over. I’d rather do one at a time.

[Goose66]

1 hour ago, MWareman said:

Does this require pg3 as well - or is it possible under pg2?
 

 

Multiple ISYs is a PG3 thing.

[MWareman]

Multiple ISYs is a PG3 thing.

This is what I thought. It’s a shame as it presents a very difficult migration for any pg2 nodeservers reporting to a physical ISY.

[Adam Ant]

On 10/28/2021 at 2:47 PM, MrBill said:

I agree on mobilinc, I wouldn't send anyone that direction anymore.

as far as UD mobile, it's great, and I do use it for one off issues that I haven't built controls for in my HA dashboard.  I think for the most part HA will remain my mobile interface, but its absolutely awesome to have UD mobile and be able to reach devices, programs, NR's etc that I don't have controls built for.  On thing I love about HA is that I can use my laptop to "develop" the dashboard and then it can be used from mobile, wheras with UD mobile I have to hold my phone to "develop" or 'create all the favorites' and scaled down controls... I probably will just never get around to that, especially if I have to do it on the phone and not build it for use via the laptop.

I don't know what the case would be tho had UD mobile existed first.....

@MrBill I have just begun moving to Polisy after my now irreplaceable PLM went out on me.  While making the move I am now reconsidering my usage of MobiLinc.   I have been a loyal user for years.  What is  “home automation dashboard” you are referencing? Your not talking about the ISY dashboard, correct?