wmcneil

I have been running ISY Firmware and UI version 5.3.0 at two different locations for many months. The google smtp server settings I have been using for a very long time are no longer working. I am getting the following message when I press the Test button in the AC Configuration > Emails/Notifications > Settings/Groups dialog: The ISY Network Settings (in AC Configuration > System) are set to "Automatic (DHCP)", and a valid local IP is assigned which I am using (without issue) to access the AC I am using these SMTP settings: SMTP Server: smtp.googlemail.com SMTP Port: 587 Use TLS checked

The first post in this thread applies. If you have a zwave card, you need to ensure it is the 500 series, else you should not update to 5.2.0

I have upgraded from 5.0.16c and 300 zwave module to 5.2.0 and 500 zwave module. Some items which will be helpful to anyone else making this transition: The directions for updating from 300 to 500 zwave module here state that you need to be running 5.0.13 or newer. I was forced to upgrade to 5.2.0 in order to get the zwave restore to work. This step failed when attempted with 5.0.16c, with "Dongle contains unsupported Z-Wave version and/or library" and "Failed to Restore Z-Wave dongle using backup..." messages present in the event viewer. After I upgraded to 5.2.0, and the zwave restore completed sucessfully, I was presented with the following window: I did not perform the zwave synchronize all. Most of my zwave devices (which are almost all gen5) were present and not showing errors in the admin console (AC). For those devices that were showing errors (exclamation point in front of the name in the AC), after I did a right click / zwave / show information in event viewer / all, the exclamation point went away, and the association and neighbors information in the viewer looked correct. The only possible remaining issue I have is that the device status under my Roomba and BlueIris node servers in the AC seem to be very sluggish about updating. I have rebooted both my ISY and my POLISY, and the sluggishness persists. Some of the status fields are updating, but not all of them. I'm going to give it some more time and see if it resolves on its own.

I was referring to the migration from 5.0.16C and 300 series zwave module to newest 5.x firmware and 500 series zwave module.

I'm a long time ISY user, have lots of gen5 devices and a few gen3 devices. Thank you to blueman2 and others that have reported their issues with moving to 5.2.0 . I still have the gen3 zwave module. I haven't upgraded to gen5, because I was waiting to see if polisy as a replacement platform for ISY would be a better place to move forward on zwave. It now looks like polisy replacing ISY could be quite a long way off in the future, and now we see that UD is moving to "500 module required" for firmware updates as part of getting zwave certification closed. Also, I see 500 modules are out of stock again currently. It seems likely to me, based on the experiences posted here, that 5.2.0 may require a lot of heavy lifting for users who haven't previously moved to the 500 module, and/or have gen3 zwave devices. So I'm waiting until the 500 modules are available again, and also to see if we get fixes or improvements beyond 5.2.0 that reduce the amount of heavy lifting.

I haven't yet found any chart that is displaying correct data. Thanks, Bill

I am running v5.0.14. Charts are not displaying correct data. For example, plotting status of a light switch shows no data points on the x axis, and shows a y axis of "0 to 1.05", with a label of "%". Plotting temperature of my zwave thermostat shows no data points, and also has a y axis range from 0 to 1.05, with a label of "current temperature F". Charts have actually not been working right for me for some time now, and I keep hoping that new versions of the firmware/UI will fix the problem. Any pointers on what I might try would be appreciated.

Thanks....Does anyone know where one can find a list of all the supported connected home v2 commands?

I have had this issue with both of my ISYs. I am certain one scenario was a PLM that had gone bad. The point is that the PLM is not a high-reliability device, so for the remote user, it is very important that the ISY have a mechanism to detect failure of communication with the PLM, and provide notification of that failure. If the only way the ISY detects/reports that PLM communication has stopped is upon reboot, then there is no way for the remote user to know that the problem has occurred.

Michel, I would not normally have many power outages, and I am using a UPS, but in both cases, due to construction, it is certainly possible that entering safe mode occurred after a reboot of the ISY. That said, my point remains. Part of the reason I am using the ISY is to provide remote management of my houses, and for that function, it is important that notification be available, even when the event is rare. Another point is that PLMs go bad after a few years, and that is another rare event that also requires remote notification for the remote use model. So I would ask that you consider adding email notification of loss of communication with the PLM as a optional feature. I would think that the event would need to be triggered by loss of communication with the PLM over some time interval, maybe 15 minutes. The duration of the persistence of the outage could be made a parameter that the user specifies. Bill

Is it possible to get an email notification when the isy994 enters safe mode? I have two isy994 in two different houses, and both will occasionally go into safe mode with a message that they can't communicate with the plm. Rebooting the isy always solves the problem (so far). While this is an infrequent occurrence, it is essential that I be able to be made aware of it remotely.