wrj0

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.

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!

Hi All, and Happy New Year! I'm looking for advice on how to correct a display problem with the degree symbol in custom email notifications. The following custom notification correctly displays the degree symbol on both windows email client and iPhone prowl push: Body: WC Temp1 = ${var.2.33}° ° (Courier 0xB0) ° Times New Roman (U+00B0) However, when the body includes a Climate Module Temperature variable, the received message displays other symbols, as follows. Body: WC Temp1 = ${var.2.33}° ° (Courier 0xB0) ° Times New Roman (U+00B0) Wx Out Temp = ${mod.weather.temp.current} The above body content returns this in the windows email client: WC Temp1 = 92° ° (Courier 0xB0) ° Times New Roman (U+00B0) Wx Out Temp = 42.1 �F ...and the below image on the iPhone Prowl app. When the variable ${mod.weather.temp.current} is omitted, the degree symbol displays fine on all devices. Two different fonts have been included for the degree symbol for testing. The Body is in Text format, but HTML returns the same result. What should I do to eliminate the undesired symbol presented in place of the degree symbol when a Climate Module variable is included with other variables in the notification? Thanks.

As you suspected, Michel, Network Resource ID=116 is the one I'm trying to get to mimic the curl command. Thanks for your reply and suggestion to look further at network issues. I'll keep poking at it. Thanks. edit: Michel, I subsequently found that the curl command works only if run from the same PC that is running the application that I am trying to control. If the same curl command is run from another PC on the same subnet, it returns: curl: (7) Failed to connect to 192.168.3.105 port 1178: Timed out So, you nailed the problem. Think I'll sleep on this one and try again tomorrow. Thanks again for your advice and assistance. edit again: It turns out this was was a Windows Firewall issue on the PC running the application being controlled. Enabling a firewall rule to open port 1178 allows the curl command to return the desired response from any device on the local network, including the ISY's Network Resource. The body for the rule that is now working is: {"password":""} Thanks Michel and Xanthros for your input. I'd still be banging my head without the benefit of your comments.

Thanks, Michel. Yes, it is indeed on the same subnet. Other ISY Network Resources access other applications on that PC just fine, e.g, WCLink.

Sadly, no - it cannot.

Thanks, Xanthos. I've tried that but can't seem to properly omit the username when entering the PW in the Authorization header. I'll keep poking at it for a while. Appreciate your input!