larryllix

NRs can be a subscription paid service. Have yours expired? Maybe contact UDI with your UUID and check to see if the account is enabled correctly.

Change your Themes|Fonts setting to something other than 13. This is a bug in the GUI where some programming selection is based on a screen or box size. Doing some programming myself. this is a very hard thing to line up for some font sizes or styles. The boxes end up being too small for the number of characters needed and show '...'.. You may also try changing your Windows screen magnification back to 100% but that may make things really hard to see for you. You can try changing your Windows mag setting to 100% while the admin console is running, temporarily to prove it for yourself. Oh yeah....if you are running a ISY994 then upgrade to v5.3.4. They fixed a lot of quirky bugs.

Bash script should end with instruction sudo shutdown -r now Without sudo it never complies.

I don't know all the nuances of python2 to python3 but there wasn't that many unless you did some uncommon code things. AFAIK you should be able to just delete the spaces behind the print statement and it should work on polisy. Since print() is a function in python3 it should look like this print("xxxxxx") If you are not familiar with python you should likely stay away from your polisy and use a RPi as your "proving grounds" first. After you are confident the code works and understand some of the basics hen port it over.

polisy is a small CPU box hardware that can replace ISY994i and simultaneously hold polyglot and node servers in the same box. ISY994i could only house ISY software. Polyglot is a piece of software that works as a "sidekick" or extension to ISY software. There are various versions of polyglot. PG1 was the original. PG2 is the current running version. Polyglot cloud (PGc) is an option for some. PG3 is the coming version of polyglot (being developed) that can manage compensations for NS writers. Polyglots are basic software that services the node servers that users write.

I run several python3 scripts on my polisy. I had them running with PG1 but when PG2 was released they began to fail about once per month or so. I switched them back to a RPi for a time and now they are back on my polisy again, running without problems, so far. Time will tell. My ~25 WiFi RGBCW bulbs and strips run off this software on polisy, as a bridge between ISY NR and WiFi signals. You may need to upgrade your script to python3 syntax. I don't know much about python2 code but I doubt the print statements will run without losing the space between print and "(".

I looked at the time/date nodeserver but one thing that seems to be missed is a combination Month and day combination variable. However two conditions would suffice to accomplish any date with a yearless condition. I use a few programs to use the ISY internal system variables that already have that information. When we had to rely on connections, routers and cables to connect with polyglot the one box solution seemed much more reliable, at that time. Now, with a single box polisy that argument becomes somewhat moot. Have a look at this technique. I use it for most holiday lighting scenes and many other functions. It only uses one trigger variable for triggering other programs.

@asbril would be the best source I know for that subject. (note I flagged him)

Basically the same here. However I only have one X10 module left and I only monitor and turn it off with the middle of the night complete shutdown every night. It's connected to a heavy duty contactor that runs my shop dust collector, always run from an X10 remote pushbutton that sits on the chop saw. Michel told me X10 was working so I assumed it was my USB PLM on my polisy that doesn't support X10, anymore.

I never use in wall receptacles since my X10 days. Too much wiring when you move or they burn out. Never had a plug-in burnout...well except the X10 appliance module I tried to control my 2 HP dust collector motor with. LOL

I purchased the SiLabs dongle (cheaper $ and regularly updated firmware) and from my trials with 2 series 300 Aeon receptacle/energy monitors, it (SiLabs dongle) worked fine with polisy. They need to be polled so I don't want then to be installed permanently in my polisy.

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'