peterathans

I'm curious, is this an issue with the Z-Wave standard (Z-Wave products are not supposed to publish controls, therefore UDI will have to find a way to work around that), or is it an issue with some specific Z-Wave vendors not implementing the standard correctly?

Precisely - hence the reason I started this thread. This sounds like good news. I've never used an eisy, but imagine it's faster than a Polisy. So for 6.x to run slower on Polisy than it does on an eisy is pretty much expected. And it sounds like (due to the way the admin console loads) 6.1 on Polisy may actually perform faster than 5.9.1 does on Polisy.

This is something I'm particularly interested in - if it were really true that this update is all good stuff, why didn't UDI make it possible to automatically update from 5.9.x? What's the reason for needing to do a manual update? I saw mention of Polisy running on slower hardware and therefore 6.x.x might seem sluggish, is this true? If so, has anyone who has done the update noticed? Is it "minor annoyance" sluggish or "almost unusable"?

@Javi Is the issue mentioned above (ID: /udi-tasks/issues/12) something that we can view, or is it internal to UDI?

I've got a Polisy running IoX 5.9.1 (FreeBSD 14.1-RELEASE-p6). It's got maybe 50 programs and 50 devices. I'm seeing lots of posts about 6.x.x versions, and that they're primarily meant for eisy products, but also that a Polisy update is "possible". I'm wondering if it's worth it to update. Honestly my system is running fine, but it would be nice to get rid of the Java interface. Aside from that, I'm wondering what other benefits 6.x.x would give me -- and, what other possible hiccups I could encounter with a newer version.

I had always assumed that Scene control was meant to be peer-to-peer (for example, ZWave devices both using basic association 2 to talk to each other) - this would imply that you can't do scene control between different technologies, such as Insteon <-> ZWave, since they don't speak the same language.

I've got a simple program looking at some values to trigger the Then, but it's not triggering: If $ShadeLowerDesiredHour is $Hour And $ShadeLowerDesiredMin is $Minute And $AnybodyHome is 0 Then...All values on the first two lines are Integer variables, and $AnybodyHome is a State variable. I can watch the values as the desired time approaches, and they do match at the appropriate time - but nothing happens. Is the fact that the first two lines don't include State variables causing the program to never evaluate as true?

I think I just ran into the same problem - at home on wifi, did a sync. Half of my favorites disappeared and if I go to devices under the Home tab it will show the devices but I can't control them. Do I need to drop wifi and re-sync using cellular? UD Mobile 4.4.25, IoX 5.9.1 Update... Rebooted controller, turned off wifi, and synchronized. Favorites are still missing but I regained control over my devices.

I'm trying to use a short event pulse to trigger a program and self-latch it so that the Then condition will keep running for several seconds (the Then events have a series of Wait statements that cause it to take this long). I assume the IF condition needs to remain true for this entire duration to allow all of the Then commands to run, so I'm looking for a simple and elegant way to have the IF remain true until all the Then events have completed. I tried adding an "OR Program is True" to the IF and a "Stop program" as the last Then command, but I think the IF program condition remains true forever. I need the IF conditions to go false at the end so the program can be re-triggered in the future. I'm sure I'm not the only one to come across this scenario, any ideas?

I have a Zen17 and use it to monitor a N/C contact in a rain sensor, never had any issues over several years now. I don't recall if I changed any config parameters, but I definitely did not exclude/include the device - maybe just did an Interview after? Anyway, not sure what's going on with yours, but is it possible to get back to square 1 and start over (factory reset)?

@hart2hart I've got some follow up questions - you mentioned "I had to run it many times to get mine sorted", can you expand on this? What made you discover that you had to do this multiple times? What were your metrics for success? Did you have some specific performance issues that you were trying to correct? How did you measure or check that each Heal process was making an improvement or change? I followed my process by watching the Level 3 event viewer, but you can also see each device's link table in the X-Ray viewer (although keeping track of these tables for all devices can get very cumbersome). Did you have cases where the Heal process just didn't work for specific devices, and if so, how did you fix those? Sorry to pester with so many questions, thanks for any help you can provide!

Remember, the time officially changes at 2am, so any sunrise/sunset calculations made at midnight (if this is how the controller works) will be off by an hour that day. Not trying to excuse this behavior, just pointing out one possibility. I'm also in the camp of "this has been going on for years, why can't the controller take it into account?".

Here are the nodes that show up when the device is added:

Yes it pairs no problem. I have hardwired and interconnected First Alert smoke and CO detectors in my house, and the ZEN55 outputs signals for both types of alarm.

Yes I have one, it works very well. Any specific questions?