johnnyt

Updated my Polisy today, which was at latest I could get before this update, i.e. 13.2 and 5.8.4, and it worked fine. I was an early buyer of the Polisy but I went through the pain of getting updated BIOS, etc. some time ago. I made some popcorn and watched it happening in real time by opening a Putty session and typing in: sudo tail -f /var/udx/logs/log It did appear to skip some things (like OS upgrade) the first time around to do some other things first then go back to do the things it skipped, with long pauses along the way so that's why I guess it takes a while. Guessing 15 mins in my case. I saw a lot of messages about things not needed or up to date, so that helped timewise in this case.

Thanks for that bit of info. Can anyone confirm my understand that all insteon signals from both insteon networks will be repeated for all to hear? Also, do zwave repeaters (built solely for that) repeat signals from both zwave networks or just the ones they see when initially powered on? Finally, anyone actually have experience with this?

Yes, it works. Thank you!

I'd like to push the content of a variable from one eISY/IoX to a second one. I know how to push a static value, such as '1', to a variable on the second IoX using Network Resources and REST but can't find how to send the dynamic content of a variable. Is there a way to, in effect, have the contents of a variable end up where the '1' is at the end of the "Path" in the screenshot below? I didn't see a way here https://wiki.universal-devices.com/ISY_Developers:API:REST_Interface#Networking I also browsed the documentation on SOAP API, which has a Get Variable option, but I can't find info/examples of if/how I can use Network Resources to achieve my objective using SOAP API instead of REST.

I want to separate my workload (~1400 programs, 751 total nodes, 328 Zwave, 179 Insteon) from one eISY to two eISY's, one for lighting, one for HVAC. Lighting is mostly Insteon with some zwave, while HVAC is mostly Zwave with some Insteon. I don't have any ZMatter or Zigbee at this point but may want to add some in the future. While I've seen Insteon and Zwave co-exist with a couple of test devices using a separate Polisy I have for testing and as a backup in case my eISY fails, I'm wondering if it will scale, particularly for Zwave and Zmatter/Zigbee when devices are spread out further away from their respective controllers, and particularly if there are only a few devices on the 2nd controller For Insteon, I believe all devices repeat all insteon signals no matter which controller/PLM is sending/receiving, meaning both Insteon networks will help each other. (Please correct me if I'm wrong) - Can the same be said about Zwave? As I understand it, I would end up with two separate Zwave networks that will NOT help each other. - What about with Zigbee/ZMatter? Also, worse than not helping each other if that's the case, could/will devices from separate networks actually interfere with each other? Any info would be appreciated.

the CL command to change the log size does not work using SSH lowercase either

Not surprised. So how do I increase the log size in eISY? My log file rotates after about a day and a half and getting at and reading the old files for days past is a PIA.

Am trying to increase my log file file size using the CL command outlined here https://wiki.universal-devices.com/ISY-99i/ISY-26_INSTEON:Advanced_Configuration_Guide by telnet'ing into eISY following the instructions here https://wiki.universal-devices.com/ISY-99i/ISY-26_INSTEON:Quick_Start_Guide#Connecting_to_the_ISY_Shell but I get a message "Could not open connection..." Is this an outdated way of doing it? Is there a way to do this using Putty/SSH (which is working fine)?

I make *extensive* use of this capability. I don't know how people troubleshoot anything more than simple problems with just the log and error log. (Full disclosure: I have over 1300 programs) I just wish I didn't have to click every small '+' sign to get to the folder where the files are each time I go to the web server tab. I also wish there was a better folder view with last changed date/time, file size, and files sortable by those various columns. Be aware that the data is NOT backed up as part of the backup function. You need to go pull the files manually and it's a bit of a process because they are in a folder with restricted access.

I removed an airthings device by deleting it using the plug-in config page and after that the following error kept happening every short poll: 2024-09-22 13:24:04.648 Thread-107 (handler_poll) udi_interface ERROR pgSession:response: Not Found: https://ext-api.airthings.com/v1//devices/3220001054/latest-samples: text: {"error":"NOT_FOUND","error_description":"segment for user <myapikey> does not exist"} 2024-09-22 13:24:04.648 Thread-107 (handler_poll) udi_interface ERROR Controller:api_get: failed to parse res={'code': 404, 'data': {'error': 'NOT_FOUND', 'error_description': 'segment for user <myapikey> does not exist'}} Traceback (most recent call last): File "/var/polyglot/pg3/ns/<myeisy>_8/nodes/Controller.py", line 251, in api_get LOGGER.warning(f"Service returned code {code} {res['data']['message']}") ~~~~~~~~~~~^^^^^^^^^^^ This caused the "server status" in IoX to become false and it triggered a program to notify me of that every short poll. I didn't notice until I checked my email later to see an inbox full of notifications. It's like the polling temporarily changes the status to something other than false but then back to false, causing the program to trigger each time. IMO, I should have only received one notification when it went false the first time. The problem stopped after I restarted the plug-in but I'd suggest that, if possible, some cleaning up could be done within the plug-in when one deletes a node so one does not have to restart to avoid this error. Alternatively the plug-in could restart itself (if that's possible) or a message to restart the plug-in could be provided, although these are less elegant solutions. The problem with restarts is that they reset the polling timer to zero, which causes the API limit to be reached. Of course this is not critical. Just something to maybe consider the next time the plug-in is opened up for changes. Thanks for all the good work you've done on this plug-in to make using these devices in my automation possible.

The other error has not re-occurred. Maybe I just needed to reboot/restart PG3. (I did a reboot)

It happened again the night after I installed 1.2.2 so I went in and turned on debug log level (because the reinstall returned log level to warning only) but it hasn't happened since. Maybe I needed to restart PG3, which I think I did later the next day. Anyway, all is good now. Thanks

Hold on publishing that change. I got a ton of these errors last night again, which you suggested was fixed in 1.2.2: Have turned on debug level for logs - hopefully it happens again soon. Could be tonight because it's been happening almost daily since I reported it. It requires a restart, which then causes API limit to be reached not long after the restart. I wish there was a way to stop/start plug-in from IoX so I could heal things programmatically instead of manually.

Well the long poll does matter because if user picks a short poll that's longer than the long poll using the GUI, it won't stick. I'm not sure what the heartbeat is all about for this, anyway. Is the number important for something, i.e. could I set it to 10000 or something ridiculous? Is it something one can use for anything? Thanks.

I did notice today that if I change short poll using the GUI and the long poll is the same or shorter than the number I set, it changes it back (or changes it to long poll - not sure. It was the same in my case). So I had to go into plug-in config to first change long poll to something longer. There was no message about this in the GUI. I just knew the issue from having gotten the message doing that in plug-in config. You may need to add long poll to GUI and have a message pop-up there if the numbers don't work if you want to keep things this way.

ok, i now see the option to set auto short poll in Admin Console. Did not notice that before. A good place for that would be on config page for plug-in right below the poll config info. When I reinstalled plug-in to get 1.2.2, it set the values too low for all three of my instances. Correct me if I'm wrong but I'm now having to choose between always having to change polling every update vs. having the plug-in change it for me to the minimum it calculates and overwriting any change I make the next time it reads data. Could the plug-in not just leave any existing short poll setting alone at restart and during data updates? Or at least during data updates? The latter is the bigger flaw in this. I understand if a timestamp solution is too complicated. Yes, there are more beneficial things to work on if it's not an easy thing. As long as Airthings continues to only temporarily block things when over the limit, it's not major issue. Thanks

I upgraded to 1.2.1 and it sets short poll to the minimum for devices, which is good, but it keeps resetting it to that minimum over again after I change it to something longer. I suspect it's during the next polling cycle because It doesn't happen right away. Part of my reason for setting it longer is that it helps prevent hitting API rate limit for those times when I have to restart the plug-in or reboot. (I have 8 devices.) While this isn't a daily thing, of course, it often comes in clumps with more than one restart, which ends up blowing the limit. With this in mind, in addition to letting people be able to set their own short poll, could the plug-in save a timestamp of the last time it did a poll such that it lives through restarts?

No problem. I noticed the messages started before midnight so I went to grab yesterday's log file from the archive and PM'ed that file too. There appears to have been some successful updates before 2AM but then things got stuck repeating the error. Thanks.

@Jimbo.Automates, it happened again overnight only this time there was no sign of API limit or any other problem. At least not to me. I had to restart the plug-in to get data updates to resume. After last time I changed log level to Debug and will send you today's log via PM.

I noticed that my ISY nodes for Airthings weren't getting updated today so I checked logs and found a boat load of these sequences: 2024-07-16 03:02:30.244 Thread-867 (handler_poll) udi_interface ERROR Controller:_query_all: Previous query still running 2024-07-16 03:02:30.244 Thread-867 (handler_poll) udi_interface INFO Controller:shortPoll: exit 2024-07-16 03:07:00.248 Thread-869 (handler_poll) udi_interface INFO Controller:shortPoll: enter 2024-07-16 03:07:00.248 Thread-869 (handler_poll) udi_interface INFO Controller:_query_all: enter 2024-07-16 03:07:00.248 Thread-869 (handler_poll) udi_interface ERROR Controller:_query_all: Previous query still running 2024-07-16 03:07:00.248 Thread-869 (handler_poll) udi_interface INFO Controller:shortPoll: exit 2024-07-16 03:11:30.249 Thread-870 (handler_poll) udi_interface INFO Controller:shortPoll: enter 2024-07-16 03:11:30.249 Thread-870 (handler_poll) udi_interface INFO Controller:_query_all: enter 2024-07-16 03:11:30.250 Thread-870 (handler_poll) udi_interface ERROR Controller:_query_all: Previous query still running 2024-07-16 03:11:30.250 Thread-870 (handler_poll) udi_interface INFO Controller:shortPoll: exit 2024-07-16 03:16:00.259 Thread-872 (handler_poll) udi_interface INFO Controller:shortPoll: enter 2024-07-16 03:16:00.259 Thread-872 (handler_poll) udi_interface INFO Controller:_query_all: enter While there appears to have been an update made around 2AM early this morning, the log before and after that update is just full of the above messages I did make some tweaks yesterday that included changing short poll time and doing a restart. This did result in reaching the API limit but only once, which I blamed on the restart causing some short shifting. Maybe, though, reaching the API limit (even only once) caused the problem? I've had API limit messages in the past but things always sorted themselves out assuming short poll is reasonable (I always set it above 30 X number of devices). A restart of the plug-in did fix the problem - at least for now. Airthings-C_7-16-2024_113452_AM.zip

Smooth upgrade, although lots of stuff to upgrade so need to give it time. Thanks SO MUCH for fixing the backup process! Went from > 10 mins (with, remarkably, the Java Launcher consuming > 80% of CPU throughout) down to about a second. Will no longer be hesitant/strategic about doing them when I'm making lots of changes. Can anything be done to improve program loading speed too? Well before I reached 1000 (now at 1200), it's also been a start-and-go-grab-a-coffee kind of process. Thanks again.

Should eisy be able to see a Hue motion sensor connected to the Hue bridge? I see the hue bridge and a hue bulb no problem in eisy. I can also see the motion sensor (and its activity) in the Hue app but it doesn't come up as a node in PG3x or Admin Console.

Thanks for the alternatives. Question about "init". I do init my counters at regular intervals throughout the day, or when they are infrequently updated. I'm under the impression (from my early 994i days with 512MB SD Card) that "init" wears the SD card and needs to be done with some care. With probably >50 counters, many of them being incremented every minute or every time there's motion, I didn't want to init them each time I incremented them. Is that an old concern now that storage is abundant with, I think, wear leveling happening? I may just init everytime I change a counter.

Thanks @Geddy I can get eisy/Polisy to commit suicide using my Digital Loggers Webswitch or by configuring one of a few zwave outlets that has auto-ON-after-OFF capability but, like you, worry about the risk/cost of doing that. An important cost for me is that whenever I do a reboot or IoX restart, I first run a program that saves a bunch of variables that I use as usage counters and to control some devices. I do the latter so that when I replace a device I only need to change one program - the one that changes the variable. I lose a lot if/when there's a hard stop. If no one knows of a way to do a graceful OS and/or PG3 restart from IoX program, I guess I'll submit a feature request. I would actually like to see the ability to configure a program (using AC) to run before IoX does a restart of itself or reboots the hardware. Kind of like a "Run At Shutdown" feature.

I've read in a few posts related to the plug-in that a power outage requires that eISY/Polisy be rebooted to get the plug-in to talk to Hue bridge again. And, apparently, it "has been like this for a long time". I also see the plug-in hasn't been touched in 2 years. While needing a full system reboot is far less than ideal (my eISY is on a UPS and I can't think of a time it ever went out due to a power outage), perhaps if there was a command I could send from IoX to gracefully reboot the hardware or PG3, I could program around a power outage. I know about the relatively new command to restart IoX but I don't think there's one to restart PG3 or reboot the hardware. Is there an IoX command to reboot eISY/Polisy, or perhaps a way using network resources to send "shutdown -r now" to the eISY OS?