larryllix

Ohhh. You are using PG3? I didn't think it was ready for the wild yet.

Sounds like some self-initiated factory reset almost. Have you tried to just power cycle your polisy and retest? How about your router dropping the IP reservation for your polisy? Of course your Ethernet connections tight in their jax at both ends of the cables?

If you run Win 10, look in your Start menu under UDI folder. I find it on my desktop sometimes and other times in my start menu pullup.

I spent hours the last time attempting to get the ISY Launcher. As it also happened a few years ago, it put it into my start menu on Win 10. Took me hours and many, many trials to remember it was in my start pullup menu under UDI.

V5.3.4 fixed a few bugs from v5.2 and is the latest for ISY994i. The bugs and complaints you are likely seeing are for the polisy box, and not ISY994i. The transfer over is a much tougher transfer and has some outstanding fixes needed. V5.3.4 should drop in transparently from v5.2

Yeah, Grabs the info at bootup time.

My polisy showed LA time also and it was never set to that. It was a bug in a version of ISY on polisy that has been somewhat fixed. I still have some system times indicating incorrectly, and variables with Last Changed Values about 5 hours too early, depending on what changed them.

Write a dummy scene to your device would have rewritten the link table in the device, correcting some lost links. A simple Restore, from the admin console, would have likely done the same correction. You likely have bad comms to this device and a damaged link table inside the device. Try removing the scene and see what happens.

There isn't much call for such a thing once ISY994 fades into the background and/or polisy migration slows down. The original crowd-sourced idea behind NSs was that users could create them themselves and have some input into where ISY was going.

More power to you for the future!

For one way control you can install Network Resources to control variables, programs, scenes and devices on the other ISY box via it's REST interface. You require the IP address and the port number, and use the GET protocol style. Variable substitution can also be used inside NRs inside any part of the URL sent, so one NR can be used for many devices, if desired. You will need the NR package which can be subscribed for a very low cost per month/year. I purchased mine outright years ago and it has been the most useful tool to interface to non-Insteon devices and to my RPi software as a bridge to more WFi devices.

I just ported my NRbridge.py (MH lighting bridge software) over to polisy again (I had some infrequent problems when PG2 first came out transferred it back to my RPi again). and used "localhost:8080" for all my ISY servicing apps and they all work fine, so far. IIRC I also used "localhost:8080" on my Polyglot. I don;t know if there is any advantage to localhost. I would hope the drivers see it and circumvent some caching or other overhead.

I only have about 10-12 Aeon Energy monitoring receptacles, which are series 300 technology. I tried them a few times, forcing them to mesh (repeat anyway) and I saw no delay when operated manually from polisy manually. They actually seemed faster response than my Insteon OnOff modules, going by the sound of the clicks. I haven't actually used them as the energy reports need to be polled (washer and dryer shut-off detection) , and they would become the closest repeater point in my Zwave system. Just experimenting so far. I want to build a cleaner system and don;t want to overly pollute my polisy with poling routines.

ditto for me. The substitution of variables at send time has been a real PITA for popcorn effects on lighting items using WiFi, and probably other end devices. Imagine the appearance of a room full of blinds with individual blinds 1-2 seconds behind each other while opening. Not as impressive as simultaneous operation. I do hope this can be changed also. The polisy is much faster and should be able to do more homogeneous "scenes" using that speed. Right now the speed between successive usages of NR is very poor due to overlapping variable writes between repeated NR usages. Keep on truckin'

I f you have the PLM box still, it hides under the cardboard and most people never even knew it was there. The linked cable looks right but I couldn't say for sure and it a very expensive version from what I have seen elsewhere. Wait for others to chime in here.

The cable came with your PLM. Zwave dongles can be purchased from amazon.ca or .com. Zooz is the brand name. I bought a SiLab 7 (cheaper and reported as upgraded routinely) dongle and it works just fine.

The stop program (self) was only for trouble shooting purposes but, I found the output variables containing a -1, instead of the original 0 value. However, the same problem would apply to stopping other programs. I don't believe ISY994 Stop Program waited for an open timeslice, this way. IIRC the Stop Program was always immediate. That may be incorrect, as I never monitored or needed to test it before. Thanks.

@Michel Kohanim Found another bug in V5.3.0 Program stop does not function immediately and waits until a Wait line. GathRm.automatic.select - [ID 01D7][Parent 0004] If 'Gathering Room / PotLights over Chairs' is switched Fade Down // vocal control also Then $sGathRm.colours = $cMODE.RESET $sGathRm.colours = $cMODE.AUTOMATIC $sGathRm.whites = $cMODE.RESET $sGathRm.whites = $cMODE.AUTOMATIC // shouldn't be needed Stop program 'GathRm.automatic.select' <----- doesn't process immediately $sAutoLighting.night -= 1 $sAutoLighting.day -= 1 Wait 1 second <-------- processes STOP here. $sAutoLighting.day += 1 $sAutoLighting.night += 1 Else - No Actions - (To add one, press 'Action')

@Michel Kohanim Found another bug in polisy v5.3.0 System variable "Minutes since start of day" produces the wrong resultant. Mine seems to increment with time but appears to be based on 7:00 PM EST (EST here). eg: At 11:50 PM it produced 250. This would be 4 hr 10 minutes after 7:00 PM.

I have never had problems with bulbs if they are dimmer capable. It was always the non-dimmable types that caused me problems. I always figured the power supplies are not capable of filtering as well in a non-dimmable type. I had some problems with early Cree bulbs and Canadian Home Depot went from almost all Cree, at the beginning, to dumping them. When I return a few under warranty, the sales clerk told me they had a lot of returns on Cree bulbs until they dumped the brand. Then the sales clerk, told me to just pick one and leave the store without paperwork. Turned out the dimming curve doesn't match the other four bulbs in the chandelier. Good enough for now and I don;t notice it any more. Those four + one bulbs have worked well for the last 5-6 years now. I have a very similiar story about BR-40 bulbs from Feit, I bought at Costco years ago. When I had to buy four at a time, I had to return all four to get just one new one...but I got money back as they were now cheaper for four bulbs. Those bulbs operate at skin burning temperatures, as I found out when I returned the blinking one. Placed in a ceiling full of insulation the heat has no place to go. Burning the crap out of my hand and having to throw it onto a couch, and then run to save the leather couch from burns, surprised the heck out of me.

There are hardware buttons on the top or bottom of the MSII. I can't remember the exact functions of them but one was an enable. I have my "send off" option disabled, and program ISY to turn my lamps off. Then the On duration is set to a very short duration as it also controls the Off duration which makes the MSII non-functional until it times out. Bad design.

@Michel Kohanim Found a small bug in V5.3.0. Variable "Last Changed" time registered is incorrect from program changes but correct with manual changes. $sAutoLighting.day was edited manually to -1, then 0 and shows the correct time of the change. $sAutoLighting.night was modified by a program within the same minute and shows incorrect time. It appears to be 5 hour earlier, or still PST time? instead of EST. Refresh does not correct.

As you quoted, yes. Just click on them and save them. This can also be done placing the cursor anywhere on the parameters and hit <enter> I use about 35 WiFi bulbs that all live on 4 NRs, total. I make usage of the variable substitution to control them individually and in groups / scenes.

For my NRs, I just loaded each one, individually, and then saved them again, as if I have done an edit. It seems they were not hooked into the main engine somehow and re-saving them did so.

I find mine in various places. One of the most obscure spots is I think Windows grabs it and installs it under ISY in your Win 10 start menu. I hate "we did you a favour" stuff.