MWareman

Michel, I'm having the problem with most programs using this NR - but it manifests slightly differently on differing devices. I'm really hesitant to go down the road of recreating all the NRs to test. I've done a test though by changing the main NR to a static string. The symptom remains (It's not to do with the substitution). My 'Family Room Floor' light is not triggering the NR at all - and it's the same NR. Here is where I tested: I modified 'Pushover - Notify Light status' to send a fixed string (no substitutions). I modified 'Broadcast Device Status' to send a fixed string (no substitutions). I manually tested both fixed-string NRs - and both worked fine. When I switched the light - the status in the admin console changed, the statue and integer variables changed (so I know the program triggered) - but neither of the NRs fired at all. If I 'Run Then' the program - the NR does not fire either. Michael.

A bit more experimentation. The program is triggering (I have some variable assignments immediately following the network resource - and these are being updated). However - the NR is never run. So far - I have not found anything in the logs. This is a multicast NR just to broadcast the device status. I tried changing it to a unicast udp with the same result. A manual 'test' of the NR works though. This is something about how it's triggered in a program and the fact that the NR contains '#' to represent the triggering device.

Thank you. At what point are the substitutions performed? Is it as or before the event is queued - or as events are pulled off the queue and delivered? IMO as long as substitutions are performed when the events are queued it really shouldn't matter. I'm trying to determine if the # in a substitution is reliable - or could be a different device ID by the time an event comes out of the queue. My main current issue is that I'm having many, many other issues seemingly caused by status not updating. I have this: The 'Pushover - Notify Light Status' contains this payload (as the 'message' for a Pushover message): ${sys.node.#.name}+-+(${sys.node.#.addr})+${sys.node.#.ST} I get a message correctly substituted when I turn the light off - but not when turning it on (should be triggering on 'Status is not Off'). No event is delivered at all. This used to work to trigger every time the status changed at all (by on, off, dimming, remote or local control). I have tried a 'Restore Device' (just in case the link table got corrupted) but it's behaving the same. Did something change here - or is there a better way to have a program trigger every time the status updates? (I cannot use 'switched' as sometimes the light is adjusted by API - and I need the program to trigger when this occurs as well).

Another odd caveat - may be related. Insteon dimmer switch. I have this program triggering condition: This used to trigger whenever the status changes. Now - it's only triggering when the status goes 'Off'.

Seems to confirm my symptoms. Devices do not appear to have their status updated at all unless manually queried. In my case this does appear to be affecting zwave as well as Insteon. For instance, I turned 'Off' a HomeSeer HS-WD100+ device. I got 'DON 0' in the log - but the status stayed at '100%'. Right/click and 'Query' - the status then changes to 0%.

The issue with the program triggering appears related to something core. If I manually query a device to get a statues - then the program triggers. It just does not trigger when a device updates. It seems the ISY/Polisy is not processing organic status updates properly. @sjenkins - I think you are having the same issue with your PLM communication.

I am noticing that with this version most of my programs are not triggering on the state change of Insteon nodes (at least): This does not trigger anymore (used to). This still does for local device changes: Since I need most programs to trigger for both remote and local changes to the device - this is problematic.

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?

For me, bottom line is if I have to go to a specialist dealer to get support or devices - I'm not going to buy into the tech without a really compelling reason. I just had my basement finished out - and need 12 new switches. These would have been Insteon - but since I cannot get them I'm getting this Leviton device instead: https://www.leviton.com/en/products/dz6hd-1bz. This is easy for me because I already have a decent zwave mesh. To me - there does not appear to be a significant functionality difference between zwave and what RA3 offers to make the added expense and constraints worth it. I would love to know though - what are the compelling reasons to look at RA3 over zwave for all of us ISY/Polisy enthusiasts?

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.