Planning move to IoP and next generation - have a question related to both

[johnnyt]

I've been delaying the move to IoP waiting for zwave migration functionality because I have too many zwave devices to entertain the idea of re-adding them all in one by one and fixing all the affected programs. I understand that's coming soon, and there will also be a new dongle for the Polisy that will provide better support of 700-series zwave than the Zooz dongle, including OTA firmware updates.

I'm wondering if I should get the new board before I do the migration. I did get a Zooz 700-series dongle a while back before I realized all the work that would be needed to move my stuff to IoP, so I've only been using it to do OTA firmware updates before adding a zwave device to the ISY 994i.

My IoP questions is, If I move to IoP using Zooz dongle (and the soon to come zwave migration tool), will I be able to swap in the new board relatively seamlessly? If not right away, will there be support for that coming in the not too distant future, e.g. <6 months or so?

My next gen question is, if I move to IoP on Polisy and I want to upgrade to the new eisy hardware later, will that be relatively seamless? If not right away, then in not too distant future? Will the dongle I use matter? While I don't want to wait too long to move to IoP as I've certainly outgrown the 994i's processing capacity, I do want to know the cost, if any, of not waiting for new eisy (and the MatterZ board I would get with it) given I will likely get one of those.

 

[asbril]

1 hour ago, johnnyt said:

I've been delaying the move to IoP waiting for zwave migration functionality because I have too many zwave devices to entertain the idea of re-adding them all in one by one and fixing all the affected programs. I understand that's coming soon, and there will also be a new dongle for the Polisy that will provide better support of 700-series zwave than the Zooz dongle, including OTA firmware updates.

I'm wondering if I should get the new board before I do the migration. I did get a Zooz 700-series dongle a while back before I realized all the work that would be needed to move my stuff to IoP, so I've only been using it to do OTA firmware updates before adding a zwave device to the ISY 994i.

My IoP questions is, If I move to IoP using Zooz dongle (and the soon to come zwave migration tool), will I be able to swap in the new board relatively seamlessly? If not right away, will there be support for that coming in the not too distant future, e.g. <6 months or so?

My next gen question is, if I move to IoP on Polisy and I want to upgrade to the new eisy hardware later, will that be relatively seamless? If not right away, then in not too distant future? Will the dongle I use matter? While I don't want to wait too long to move to IoP as I've certainly outgrown the 994i's processing capacity, I do want to know the cost, if any, of not waiting for new eisy (and the MatterZ board I would get with it) given I will likely get one of those.

 

My 2 cents.........   I was where you are on waiting for the Zwave migration tool as I have some 80 Zwave devices. A few weeks ago, I decided on the manual migration and it took me several days. For most of the devices the migration was quick and easy.  In some cases I was even able to do the exclude directly from IoP, followed by an inclusion. In other cases I had to do the exclusion from ISY and then the inclusion on IoP. For about 3 or 4 wall switches neither method worked and I had to physically remove the switches from the wall and do the exclusion/inclusion close to the Polisy.

I also had to redo my programs, which I actually liked as I learned a lot over the years and the new programs are more efficient.

As said the migration took me several days and creating & adjusting the new programs took some 2 weeks. I took the opportunity to replace some old pre Zwave Plus devices with new  700 series, though with some 80 devices I have a solid Zwave mesh network, even with older Zwave. One advantage was that moving everything to IoP, I was able to get everything (back) on Home Assistant which is a very nice complement to ISY/IoP, especially as a front UI. 

I am happy with result and am glad that I made the effort. Of course we now seem to be closer to the migration tool coming alive, but in your place I would seriously consider skipping Polisy and go straight to Eisy.  True, we don't yet know the xact ETA of Eisy and we don't yet know the price. As you waited with getting Polisy till now, I would wait a bit longer and skip Polisy.

[Bumbershoot]

Personally, I would just wait for the eisy.  It apparently is nearing readiness, and the ISY software shipping with it will have all new Z-Wave code/hardware that UDI licensed from a 3rd party.  Michel has stated that both the Polisy and the eisy will use FreeBSD as the host OS, so the functionality of both should be identical or close to it.  You’ll have the latest/greatest with only one migration step. 

[lilyoyo1]

15 hours ago, johnnyt said:

I've been delaying the move to IoP waiting for zwave migration functionality because I have too many zwave devices to entertain the idea of re-adding them all in one by one and fixing all the affected programs. I understand that's coming soon, and there will also be a new dongle for the Polisy that will provide better support of 700-series zwave than the Zooz dongle, including OTA firmware updates.

I'm wondering if I should get the new board before I do the migration. I did get a Zooz 700-series dongle a while back before I realized all the work that would be needed to move my stuff to IoP, so I've only been using it to do OTA firmware updates before adding a zwave device to the ISY 994i.

My IoP questions is, If I move to IoP using Zooz dongle (and the soon to come zwave migration tool), will I be able to swap in the new board relatively seamlessly? If not right away, will there be support for that coming in the not too distant future, e.g. <6 months or so?

My next gen question is, if I move to IoP on Polisy and I want to upgrade to the new eisy hardware later, will that be relatively seamless? If not right away, then in not too distant future? Will the dongle I use matter? While I don't want to wait too long to move to IoP as I've certainly outgrown the 994i's processing capacity, I do want to know the cost, if any, of not waiting for new eisy (and the MatterZ board I would get with it) given I will likely get one of those.

 

Since no one has migrated with zwave yet, I think it would be hard for anyone to answer your question with any certainty in regards to the cost of things. 

I would say that the more times you migrate, the greater the chance of something going wrong. If you're planning on getting eisy- wait for it and then migrate. If you're ok with sticking with polisy; get the matter board and migrate to that. 

While Michel has stated September being the release month, I'd assume December as a time frame due to delays and demand (no guarantee they wouldn't sell out quickly). 

[Michel Kohanim]

With regard to migration of Z-Wave, both 500 series and Zooz have been thoroughly tested and they work perfectly. This said, the new code supports many features that the previous code didn't support such as S2 and scenes. So, there will probably be some minor manual intervention.

With kind regards,
Michel

[johnnyt]

On 9/6/2022 at 10:36 AM, Michel Kohanim said:

With regard to migration of Z-Wave, both 500 series and Zooz have been thoroughly tested and they work perfectly. This said, the new code supports many features that the previous code didn't support such as S2 and scenes. So, there will probably be some minor manual intervention.

With kind regards,
Michel

Thanks @Michel Kohanim. Will I have to exclude/include devices after migration to take advantage of the new features, e.g. S2, scenes, or anything else? I'm guessing yes for S2 as I understand it to be a comms security setup feature, although I'm not quite sure if I should care about it - should I if I'm not worried about my neighbors turning my stuff on/off?

I do care about scenes, though. And other stuff. I have a lot of problems with zwave devices that the vendor blames on ISY 994i (lack of) support for it, and others I have that will just take so much effort to document that I haven't bothered asking vendor because I suspect it may be either an ISY 994 issue,  a zwave 500 issue, a zwave 500 to 700 issue, or an 994i processing overload issue.

Any info would be appreciated.

 

[Michel Kohanim]

@johnnyt,

You might have to Exclude/Include S2 devices but if and only if the interview fails. But, as with anything Z-Wave, pretty much a lot of things are left to manufacturers and thus there's literally no guarantee unless we test each and every Z-Wave device.

This is a completely new implementation for Z-Wave so a lot of things have been improved. 

With kind regards,
Michel

[asbril]

18 minutes ago, Michel Kohanim said:

This is a completely new implementation for Z-Wave so a lot of things have been improved. 

Exciting !!!!!!!!!!!!!!!!!!!!! 

[lilyoyo1]

14 hours ago, johnnyt said:

Thanks @Michel Kohanim. Will I have to exclude/include devices after migration to take advantage of the new features, e.g. S2, scenes, or anything else? I'm guessing yes for S2 as I understand it to be a comms security setup feature, although I'm not quite sure if I should care about it - should I if I'm not worried about my neighbors turning my stuff on/off?

I do care about scenes, though. And other stuff. I have a lot of problems with zwave devices that the vendor blames on ISY 994i (lack of) support for it, and others I have that will just take so much effort to document that I haven't bothered asking vendor because I suspect it may be either an ISY 994 issue,  a zwave 500 issue, a zwave 500 to 700 issue, or an 994i processing overload issue.

Any info would be appreciated.

 

Zwave doesn't handle scenes the way insteon does so if you're used to insteon you'll be sorely disappointed. Theirs is a convoluted mess which the Isy doesn't handle well but from what I'm hearing has been redone to work better with the new board (still a mess though). Depending on your issues, the new way still may not fix it due to how different zwave devices work. 

 

[peterathans]

1 hour ago, lilyoyo1 said:

Zwave doesn't handle scenes the way insteon does so if you're used to insteon you'll be sorely disappointed

Wonder where this information comes from -- all of the research and posts I've seen in this forum show that the Zwave standard does support "scenes" in the way we're used to from Insteon (ie, linked devices directly so they can work without support from a central controller), but the problem right now is that the Polisy controller doesn't give us a convenient way of setting these up.

Here's hoping that the upcoming eisy will address this shortcoming!

[lilyoyo1]

2 hours ago, peterathans said:

Wonder where this information comes from -- all of the research and posts I've seen in this forum show that the Zwave standard does support "scenes" in the way we're used to from Insteon (ie, linked devices directly so they can work without support from a central controller), but the problem right now is that the Polisy controller doesn't give us a convenient way of setting these up.

Here's hoping that the upcoming eisy will address this shortcoming!

Where does it say that?

Insteon scenes reside in each device regardless of device type...ie: any insteon device can control any other insteon device regardless of what it is. Just had to be in range of the signal

With zwave you have 3 ways to control other devices.

1) controller is the middleman for scenes (most common)

2) direct association: device to device communication. Limited to 5 other devices. Must be in direct range of the controlling device and all devices must support that association and the controlling device must be scene capable. (2nd most common)

3)assigned association. Same thing applies except you are able to talk to devices not in direct communication with the controlling device. With that said, the controlling device must support this capability as it sets its own path separate from the controller. (Least common).

In addition, instruction devices can all have different ramp rates and levels. Not so much with zwave. 

Where is it that insteon is similar to this?

Edited September 8, 2022 by lilyoyo1

[asbril]

10 minutes ago, lilyoyo1 said:

With zwave you have 3 ways to control other devices.

1) controller is the middleman for scenes (most common)

2) direct association: device to device communication. Limited to 5 other devices. Must be in direct range of the controlling device and all devices must support that association and the controlling device must be scene capable. (2nd most common)

3)assigned association. Same thing applies except you are able to talk to devices not in direct communication with the controlling device. With that said, the controlling device must support this capability as it sets its own path separate from the controller. (Least common).

In addition, instruction devices can all have different ramp rates and levels. Not so much with zwave. 

I have only succeeded with option 1 (ISY as middleman). Will this change with upcoming Eisy upgrade ?

[lilyoyo1]

Just now, asbril said:

I have only succeeded with option 1 (ISY as middleman). Will this change with upcoming Eisy upgrade ?

I'd assume associations work properly with eisy but with the limitations of it, you'd probably be better off with the ISy doing the routing unless speed is of the essence such as using a sensor to turn in a light. 

[asbril]

2 hours ago, lilyoyo1 said:

I'd assume associations work properly with eisy but with the limitations of it, you'd probably be better off with the ISy doing the routing unless speed is of the essence such as using a sensor to turn in a light. 

Because Zwave Scenes are really not working faster than Programs, I almost exclusively use Programs. However I have a few sensors that should activate lights and, as you have pointed out many times, Zwave is much slower than Insteon in these cases. That is why I'd love to have direct association. A few months ago there was an active conversation on this topic in this forum, but there was not really a conclusion. Michel wrote yesterday that UD has totally redone Zwave and for that reason I am wondering whether direct association will be part of it.

[peterathans]

Yes there was a discussion on this forum a few months back (started by me - I'm particularly interested in this feature so I can replace my Insteon "virtual 3-way" switches with an equivalent Z-wave setup).

See this thread:

My takeaway from this conversation is that the Z-wave standard (and some/many of the Z-wave products) can support an Insteon-like "scene" grouping where the response is almost instant and is independent of any central controller or programming.

I'm interested in the limitations discussed above ("must be in direct range") but only as a curiosity as my installation will only use Zen71 switches (which supports Group 2 associations) and they're close together.

[lilyoyo1]

9 minutes ago, peterathans said:

Yes there was a discussion on this forum a few months back (started by me - I'm particularly interested in this feature so I can replace my Insteon "virtual 3-way" switches with an equivalent Z-wave setup).

See this thread:

My takeaway from this conversation is that the Z-wave standard (and some/many of the Z-wave products) can support an Insteon-like "scene" grouping where the response is almost instant and is independent of any central controller or programming.

I'm interested in the limitations discussed above ("must be in direct range") but only as a curiosity as my installation will only use Zen71 switches (which supports Group 2 associations) and they're close together.

It's faster direct but limited to 5 devices within range (has to be direct device to device communication). Unlike insteon, you wouldn't be able to use direct association if a repeater is required to be in communication with another device. These groupings are good for on/off control of like devices.