MWareman

Wonderful! Thank you so much. I can confirm that NLS Strings are now showing up correctly in the REST API (as well as UDMobile where they were broken as well). The XML Crash fix appears to have fixed the same crash when substituting in email notifications. Thank you! This >Network Resources actions are queued when run from programs rather than run inline raises a quick question: Does this mean that the substitutions are fully the same as with email substitutions - processed when the event is queued? Or is the substitution still processed when the queue is processed potentially mismatching events?

Did a 'pkg update && pkg upgrade' yesterday - and got the following two build updates: Dec 18 22:42:04 polisy pkg[93471]: udx upgraded: 2.5.3_2 -> 2.5.3_4 Dec 18 22:42:29 polisy pkg[93471]: isy upgraded: 5.2.0_58 -> 5.2.0_69 (among others) @Michel Kohanim are any of the above issues resolved in this minor update - or should we wait for a dot point update? I think that the issue of the API not exposing node names correctly is also affecting how UDI Mobile displays nodes. It's displaying integers instead of names for the status of the Elk system.

Thank you!

@Michel Kohanim Last Changed Timestamp appears wrong on variables (sometimes) Here is an example I've been able to pin down.. I have 24 programs - each set to trigger on the hour: 'trigger-hourly' is also run by my 'System Startup' grogram - that is set to run on ISY startup (so the minute counter starts on system boot)... The 'trigger-hourly' program does this: So - the 'trigger-minutely' program should run every 60 seconds - and update a variable: I rebooted PolISY at 6:22am - and the 'Last Changed' appears to be 6 hours off. Even though my time offset is 6 hours - it's in the other direction (Zulu is 12:30 at the time of this screenshot). Not sure if this is related to other timezone changes made in the system recently - but thought I'd report it. Here is a screenshot taken a few minutes later - shows the minute is advancing as expected - but the hour is 6 hours off: Michael.

12 nodeservers currently configured to ISY/Polisy: Ring (PGC) has 18 nodes MyQ (PGC) has 3 nodes Push (PGC) has 13 nodes LiFX (Local) has 12 nodes WeatherflowPoly (Local) has 9 nodes Ping (Local) has 17 nodes UnifiPresence (Local) has 9 nodes ELK (Local) has 36 nodes NOAA (Local) has 1 nodes Timedata (Local) has 2 nodes Virtual (Local) has 2 nodes WirelessTag (Local) has 17 nodes Total appears to be 139 nodes via nodeservers. Thank you! Michael.

@Michel KohanimThe NR I have configured for debugging variable substitution in NRs not recognizing the # is also still not working. It wasn't called out as fixed for this release though. ${alert.event} I get: 'null null received' Michael.

@Michel Kohanim The variable substitution issue does not appear resolved. Here are the properties of the timedata NR on a physical ISY (5.3.3): <properties> <property id="GV0" value="20" formatted="20" uom="0"/> <property id="GV1" value="32" formatted="32" uom="0"/> <property id="GV10" value="2" formatted="Autumn" uom="25"/> <property id="GV11" value="0" formatted="False" uom="2"/> <property id="GV12" value="0" formatted="0" uom="0"/> <property id="GV13" value="0" formatted="False" uom="2"/> <property id="GV14" value="8108" formatted="8108" uom="0"/> <property id="GV15" value="18965" formatted="18965" uom="0"/> <property id="GV16" value="10" formatted="Debug" uom="25"/> <property id="GV2" value="4" formatted="4" uom="0"/> <property id="GV3" value="12" formatted="December" uom="25"/> <property id="GV4" value="2021" formatted="2021" uom="0"/> <property id="GV5" value="5" formatted="Saturday" uom="25"/> <property id="GV6" value="49" formatted="49" uom="0"/> <property id="GV7" value="338" formatted="338" uom="0"/> <property id="GV8" value="0" formatted="EVEN" uom="25"/> <property id="GV9" value="486512" formatted="486512" uom="0"/> <property id="ST" value="1" formatted="True" uom="2"/> </properties> Here are the properties for the exact same nodeserver when paired with Polisy/ISY running : <properties> <property id="GV0" value="14" formatted="14" uom="0"/> <property id="GV1" value="35" formatted="35" uom="0"/> <property id="GV10" value="2" formatted="2" uom="25"/> <property id="GV11" value="0" formatted="False" uom="2"/> <property id="GV12" value="-6" formatted="-6" uom="0"/> <property id="GV13" value="0" formatted="False" uom="2"/> <property id="GV14" value="8102" formatted="8102" uom="0"/> <property id="GV15" value="18965" formatted="18965" uom="0"/> <property id="GV16" value="10" formatted="10" uom="25"/> <property id="GV2" value="4" formatted="4" uom="0"/> <property id="GV3" value="12" formatted="12" uom="25"/> <property id="GV4" value="2021" formatted="2021" uom="0"/> <property id="GV5" value="5" formatted="5" uom="25"/> <property id="GV6" value="49" formatted="49" uom="0"/> <property id="GV7" value="338" formatted="338" uom="0"/> <property id="GV8" value="0" formatted="0" uom="25"/> <property id="GV9" value="486155" formatted="486155" uom="0"/> <property id="ST" value="1" formatted="True" uom="2"/> </properties> The 'formatted' value for the attribute 'GV3' (for instance) lists '12' instead of December'. The same is occurring on the ELK nodeserver. I have not tested others yet. Michael.

Maybe I was too fast. My admin console went to 'Ready' - but knowing Java I figured it disconnected. So - exited the admin console and re-opened it. And - back to this: Edit: I guess I was impatient. This one only lasted a few mins.

Wow - I stepped away for a few hours - and came back to the same busy dialog. Seems to have been repeating and repeating. The 'sudo service isy restart' solved the issue where a full Polisy reboot did not appear to. Thank you!

I backed up (of course!) I was on 5.1.1. "Admin Console | Help | Automatically Upgrade" I was offered '5.2.1' - and I selected to upgrade. After about a minute - I restarted the ISY finder - and if found Polisy version 5.2.0 Connecting - I have this dialog. It's making progress - but *very* slow. I'm going to let that complete. Meanwhile - some programs are reporting 'Out of memory': I have another reboot to go (to test zwave) but I'm going to wait for the 'System Busy' to complete before continuing... Edit: almost 15 mins of the above dialog - it got to 100% - then this dialog appeared: Edit2: 15 minutes the above is at 99% and iminent. Meanwhile, my location is 'unknown' after the upgrade: Tried changing it to the correct location - and I got this: Meanwhile - the 'System Busy' dialog dissappeared for a couple of seconds - and was replaced... with a new one:

Thank you so much!

Thank you Sir! Please do let me know if there is any additional help I can provide in terms of identifying the root cause.

nls/en_us.txt exists. In nls/en_us.txt - it all appears in upper case: WEEKDAY-0 = Monday WEEKDAY-1 = Tuesday WEEKDAY-2 = Wednesday WEEKDAY-3 = Thursday WEEKDAY-4 = Friday WEEKDAY-5 = Saturday WEEKDAY-6 = Sunday LOGLEVEL-0 = None LOGLEVEL-10 = Debug LOGLEVEL-20 = Info LOGLEVEL-30 = Error LOGLEVEL-40 = Warning LOGLEVEL-50 = Critical MONTH-1 = January MONTH-2 = February MONTH-3 = March MONTH-4 = April MONTH-5 = May MONTH-6 = June MONTH-7 = July MONTH-8 = August MONTH-9 = September MONTH-10 = October MONTH-11 = November MONTH-12 = December SEASON-0 = Spring SEASON-1 = Summer SEASON-2 = Autumn SEASON-3 = Winter editors.xml (in part) contains this: [root@polisy /var/isy/FILES/CONF/DEF/f10/i10]# vi editor/editors.xml <editors> <editor id="I_NONE"> <range uom="0" min="0" max="999999"/> </editor> <editor id="ODDEVEN"> <range uom="25" subset="1,2" nls="ODDEVEN"/> </editor> <editor id="SEASON"> <range uom="25" subset="0-3" nls="SEASON"/> </editor> <editor id="I_STATE"> <range uom="25" subset="0,1" nls="STATE" /> </editor> <editor id="I_WEEKDAY"> <range uom="25" subset="0-6" nls="WEEKDAY" /> </editor> CaSe all looks correct and consistent to me... Thank you! Michael.

The ISY process running on the Polisy has been restarted several times. I'll try it again to confirm though since I hate second-guessing myself...... Edit: Confirmed. I restarted the Polisy completely - and the numeric values were still there. I then tried just restarting the ISY daemon - and the numeric values stayed.

I was setting up the Elk nodeserver on Polisy (when connected to ISY on Polisy in this thread). To investigate further - I have looked at the Time Data nodeserver (https://github.com/ve7gel/Timedata) as it is installed on both Polyglot (RPI) connected to my physical ISY - and Polisy with the ISY process. I used the REST API to pull the node data for the nodeserver from each install. I would expect the results to be the same (since the time and location is configured identically): Physical ISY: http://192.168.1.2/rest/nodes/n013_timedata ISY process on Polisy: http://192.168.1.3:8080/rest/nodes/n010_timedata For example, GV10 (Season) shows 'Autumn' in the formatted output - but on Polisy the API formatted attribute returns '2'. This appears to be the root of the issue I have at the moment moving things over - the 'ST' value is coming out correctly - but the GV* values are not. I'm guessing this is a bug in ISY 5.1.1. on Polisy. Thank you, Michael.

Thanks! I'll disable the notification (the ISY process crashed every time it tried sending it today) look out for the update that fixes it..

I've been able to reproduce a coredump in the main ISY process on Polisy. This appears to occur during senmding an email notification with the body set to HTML. This is what is logged to /var/log/messages: Nov 24 14:01:04 polisy kernel: pid 32698 (isy-freebsd-x64), jid 0, uid 346: exited on signal 11 (core dumped) If the body of the customization is: ....then the process crashes. Adding the substitution for the ELK nodeserver causes the entire ISY process to crash. If the body of the customization is: It does not crash when tested. I suspect the something about the characters in the html is not being escaped correctly. I am testing with the notification is a program with no triggers - and a manual 'Run Then'. Michael.

Awesome! Thank you @Michel Kohanim. Having the lat/long set separately from the timezone is most definitely a needed feature as some timezones are huge. I'm quite sure this is better than adding hundreds of locations just to account for sunrise/sunset times. Looking forward to the SNI and Z-Wave support - these two will help me complete my own migration. Only one final bugfix to confirm - triggering device substitution for # in NRs.

Tested another external API - this time the Google Chat API. It also worked fine from ISY/Polisy.

Yes - without issue. Here is an example. Also - you were correct on the quotes - adding them allows the curl to work well.

From a browser (Chrome) - the URL works fine and returns JSON From 'curl' on Polisy - I get "Error Message": "the parameter apikey is invalid or missing. Please claim your free API key on (https://www.alphavantage.co/support/#api-key). It should take less than 20 seconds." With WGET on a regular Ubuntu host, I am seeing the process 'hang' and keep waiting for content. I see this in the log when I kill the process: --2021-11-15 17:11:21-- https://www.alphavantage.co/query?function=SYMBOL_SEARCH Resolving www.alphavantage.co (www.alphavantage.co)... 104.22.70.209, 172.67.23.2, 104.22.71.209 Connecting to www.alphavantage.co (www.alphavantage.co)|104.22.70.209|:443... connected. HTTP request sent, awaiting response... 200 OK Length: unspecified [application/json] (it times out waiting here) Seems the 'unspecified' length being returned from the API may be messing with the test. Can I ask - what are you trying to do with this? ISY cannot process the JSON response. NRs are normally used to trigger external events to occur and cannot be used to receive data. To pull data into ISY - you have to run a script on an external host that will pull the data, parse it then send it to ISY variables via it's REST API (or write a poly to do this work for you). To answer your question - I am getting the same error when running your rule on my ISY/Polisy. I have a lot of other NRs configured - all without this issue. Perhaps @Michel Kohanim knows more than I about any issues with responses with an 'unspecified' length? The other possibility - I note that the site is behind Cloudflare's WAF. I run this at work - and I tested a NR against my own API that is protected by Cloudflares WAF - and hit the exact same issue. In my test case - the API did return a length. So - in all likelihood there is an issue connecting to APIs that are behind Cloudflare. Maybe Polisy is hitting it's bot detection protection and getting blocked by them?

140002 indicates 'HTTP_CLIENT_CONNECTION_TIMED_OUT'. See https://wiki.universal-devices.com/index.php?title=ISY-99i/ISY-26_INSTEON:Errors_And_Error_Messages for most of the error definitions. Could POLISY be trying to use the IPv6 IP address where ISY never does that - causing the timeout? What are you using for DNS?

Indeed they were - I believe I may have been one of the early heavy users of NRs at the time - and discovered that substitutions did not work with # for NRs like they did with email. I confirmed with @Michel Kohanim and got hooked up with a Wiki account to add the note to the documentation. I'm quite looking forward to modifying my prior words when # is confirmed to work within NRs on ISY/Polisy after 6 years of waiting for it..

This is a new feature for ISY running on Polisy. Please see this post from @Michel Kohanim on the announcement thread: I've been able to get it to work yet though - here is my thread where @Chris Jahn is looking into why it's not yet working as intended: https://forum.universal-devices.com/topic/34061-trigger-device-substitution-on-network-rules

Not self triggering (to my knowledge). Instead of having many NRs each with a different device address and/or device name being substituted - we will be able to have a single rule with ${sys.node.#.name} (for the name of the device that triggered the program that called the NR) or ${sys.node.#.addr} for the address of the device that triggered the program that called the NR, or ${sys.node.#.st} (for the formatted status) or ${sys.node.#.st.raw} (for the raw numeric status). For me - this is a 90% reduction of NRs. Very significant for me as I am reimplementing all rules on the ISY/POLISY.