wrj0

Sure enough, deleting/reinstalling Locative and then rebuilding the geofences restored the notifications for me in iOS 15.1.

@MrBill Thanks, I saw that in your earlier response. Did you have to re-create the Geofences in Locative after deleting/reinstalling?

Locative developer response to an iOS app review earlier this week:

I have to agree. Upgraded today without any problems. Another UDI Class Act.

Javi found my issue in very short order. An ampersand "&" in the name of one of my Network Resources was causing a problem during sync node parsing. I've removed the problem character and Javi has noted the issue. The UDI team is a remarkably talented group of magicians.

Will do. Thanks!

Thanks, Javi. After loading the app, entering my portal and Local Network info, and doing a Sync, the app displays "Sync UD Mobile with ISY" and displays devices and programs being sync'ed for a minute or so. Then "Getting Node Files from ISY" and a spinning spoke; and remains in that display indefinitely. I waited 20 minutes before selecting Cancel. Rebooting the iPhone, and launching the app again, it stops each time at the same point when doing a sync. Test System On Local Network returns: Connection Successful! ISY v5.3.3. Suggestions, please.

Yes, even though it was a new install.

I was indeed having some communications errors with the BE469 before upgrading to the series 500 Zwave board. After installing that board, I factory reset the locks and the other installed Zwave devices, and added two new gen 7 Aoetec repeaters. Took most of a day to get everything setup again, and had to modify several programs to use the new Zwave device ID's, but everything is working much better now, even the BE469 that previously caused frequent errors. Resetting all the Zwave devices was a real pain in the seat, but seems to have been worth the effort.

Another successful upgrade to 5.3.2 from 5.3.1 without any apparent issues. Two older Schlage locks (BE469NX and BE369) seem to be controlled, reporting and working fine.

5.3.1 along with two new Aoetec gen 7 repeaters (added to a gen 5 repeater and siren previously in place) resolved my communications problems with an old BE469.

@MWareman, Many thanks. That works like a champ. Curiously, ${sys.node.ZW006_1.BATLVL} works fine in a custom email notification sent to the same Pushover user account. But, with the same Pushover user account, I do indeed need to use ${sys.node.ZW006_1.BATLVL.raw} in the network resource to prevent the Net Module error . Again, thank you for the suggestion.

Greetings, all. I have a network resource on an ISY 994i/IR PRO running v.5.0.2 that correctly sends Zwave lock status updates via Pushover. The network resource includes the variable ${sys.node.ZW006_1.ST} This correctly shows the lock status. However, if I include ${sys.node.ZW006_1.BATLVL} in the network resource and perform a test, it returns: TCP client request failed [Net Module Rule: 207:500] From the Wiki entry, ISY-99i/ISY-26 INSTEON:Errors And Error Messages: 500 Internal Error What am I doing wrong? Thanks

Correct. After a PLM failure, a spare PLM was put into place following the Wiki PLM replacement procedure. Motion sensors and Leak Sensors showed the green Pending Changes Icon. Enabling a program like the one jerlands posted above, allows the Leak Sensors to be updated without manual intervention on the first occurrence of the Leak Sensor's heartbeat. After the program performs the Device Update, I include a 1 second wait, and then have the program disable itself. It will be re-enabled if another PLM has to be put into service. My five leak sensors, purchased at different times, are 2852-222 v.00 and 2852-222 v.41. Programs run on an ISY 994i/IR PRO v.5.0.2

This technique also works to update 2852-222 Leak Sensors. Set program to watch for the heartbeat, wait 1 second, then have the program do the Update Device. Sure beats running around to all leak sensors after a PLM update; especially for those in hard to reach places like beneath the dishwasher.

New capacitors from Mouser arrived and were installed today. The failed PLM has been restored and is now back in full operation. Whu hoo! Thanks to all who provided details on the cause of the failure and the fix - much appreciated!

Another 2+ year PLM failure to report. My PLM #2412S V1.B failed after running for 2 years and 3 months. Fortunately, I still had the pre-dual band version in the spares box and was back in operation quickly, thanks to the wiki procedure. Replacement parts listed above have been ordered from Mouser to attempt to resurrect the failed PLM. It's rather amazing how frequently these PLMs seem to fail just after operating for two years.

Years ago 'burakk' posted a program "It may snow." http://forum.universal-devices.com/topic/1793-weather-module/?do=findComment&comment=14248 Based on that post, the following has worked fairly well as a snow predictor for my system located in central NC. If Module 'Climate' Dew Point < 32 °F And Module 'Climate' Humidity > 80 % And Module 'Climate' Temperature <= 40 °F Then Run Program 'Snow Probable' (Then Path) Else - No Actions - (To add one, press 'Action') The program 'Snow Probable' provides message notifications

Sure seems like it's adding Rain Today and Rain Yesterday. My ISY shows Rain Today = 0.6" while my PWS reported 0.4" Yesterday and 0.2" Today.

It seems my Total Rain Today value is also the sum of yesterday's and today's values. My ISY is showing Total Rain Today = 1.62 inches. My PWS reported 1.57" yesterday and 0.05" today.

Thank you, sir! Station info has been sent as requested.

My PWS currently shows RainDay=0.4289 in. PWSweather shows it as 0.43. My ISY shows Total Rain Today 5 inches. My PWS currently shows Baro=29.85 Hg. PWSweather shows it as 29.86. My ISY shows Pressure 0 psi. What's up docs?

Yes, indeed. I've copied the degree symbol from Character Map and pasted it into the Custom Notification Body after the variable name. But, I'm allowing Climate Module to provide the degree symbol for the current temperature variable. Perhaps a screen shot may help with my previously poor attempt at an explanation. If I leave out the 2nd line with {mod.weather.temp.current}, the degree symbol in the 1st line of the body presents properly.

Thanks, again, Michel. I tried following your instructions with the results below - still getting the strange characters. Created new custom email notification “Char Test†with HTML option selected: Subject: @webpage:@append:myDir/testlog.htm Test4 Body: WC Temp1 = ${var.2.33}° Wx Out Temp = ${mod.weather.temp.current} Program: Send Notification to ‘wrj email’ content ‘Char Test’ When Run Then is selected, the resulting email content is: Subject: Test4 Body: WC Temp1 = 90° Wx Out Temp = 47.3 �F When sent to Prowl, the body displayed is: WC Temp1 = 90ð Wx Out Temp = 47.3 °F The ISY file /user/web/mydir.testlog.htm contains: WC Temp1 = 90° Wx Out Temp = 47.5 °F You have far more important issues to address and I have other means of getting the degree symbol in notifications, so please use your time and efforts to better advantage than on this small issue. Thanks.

Thanks for your reply, Michel. Do you *ever* take a day off? It appears that both HTML and Text content type return similar results with the à character, at least in my tests. Thanks for noting this has been logged for a possible fix in a future release. It's not really a big deal, as two separate notifications can be sent that eliminates the undesired symbol. Here's wishing you and the staff of UDI a very successful 2014!