wrj0

That was it! Restarting the ISY fixed the variable substitution; today, both report "Wednesday". Apologies for bugging you on this one, but many thanks for both your support and for your work on the node servers.

@bpwwerI'm running both WeatherBit and ClimaCell node servers in PG3 and notice a difference in the way they report the GV19 node (day of week forecast is for) in email variable substitutions. WeatherBit NS ${sys.node.n001_forecast_0.GV19} returns "Tuesday" ClimaCell NS ${sys.node.n006_forecast_0.GV19} returns "1" Yet, both Node Servers show 'Tuesday" in the Admin Console Day field on their respective Forecast 0 screen. Am I missing something in how to properly use GV19 in the ClimaCell NS? Thanks.

Is there a way to search for something in the list of Configuration>Emails/Notifications>Customizations? For example, can I search for a specific substitution variable in the list of Customizations without having to open and manually read each of the entries in the list? It seems there should be a way to export the list into an XML or TXT file for search purposes.

Once the storms passed, I spent a couple of hours looking at the configs of ISY, Polisy, and PG3, and restarting them a few times, trying to get my first Notification NS to show up in PG3. Finally realized that after purchasing the NS (trial version), I still had to go to back to the store and select Install. After doing that the NS showed up fine in PG3 Dashboard and populates properly in my ISY994. Got too lost in the configuration details to see what was likely clearly obvious to others. To borrow an expression from another knucklehead: Doh!

@apostolakisl Thanks. My first NS install on PG3 as well. I’ll try deleting/re-installing the ISY from PG3 as you suggested, once the local thunderstorms have subsided.

@apostolakisl I have a similar problem with installation of a NS on PG3, that I can't get to show up on my ISY (PG2 node servers are running fine). May I ask what you deleted and reinstalled? (the node server, the ISY entry on PG3?, something else?)

Successfully upgraded from 5.4.0 to 5.4.1 using Polisy front panel push button. AC and PG2 appear to be functioning without any issues. Log shows bios ver: 1.1.3, after successful installation of UEFI.

Geofence was sporadic for me in iOS 15.2 but has been functioning consistently in iOS 15.3.

After updating to iOS 15.3, Locative detected boundary crossings (both in and out) for the single test I made. Pushover received the boundary crossing info from Locative and properly reported to my iPhone 13. Hopefully, it will continue to function properly.

For the past two days Locative has properly reported entering and exiting my current location's geofence. Seems to have started working again after upgrading from iOS 15.1 to 15.1.1. Fingers crossed it will continue to work.

After the reinstall, it turns out Locative only worked the first time exiting one of my geofences and the first time entering another geofence at a distant location. Subsequent crossing either boundary no longer triggers Locative. It seems an update to iOS 15.1 is indeed needed to correct this problem.

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