johnnyt

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?

Thanks, @Javi Do motion sensors work following same process? What about Festavia String Lights? It doesn't say it but I assume they communicate with the Hue hub via Zigbee, as I assume every Hue device does - is that right?

Can anyone help with this? I'm also looking at getting Hue lights and motion sensors. Do I need the Philips hub if I have eISY with zMatter? Should I get the hub anyway, e.g. for more features and/or best results while IoX support for Zigbee matures? Do I need the plug-in? If so, does it work with latest hub? (last update of plug=in was 2 years ago now) Browsing forum I found some reasonably recent posts saying it doesn't work, others saying it should work but not confirming it does. One post said the motion sensor was the best one he tried, although not being specific as to whether it works great with eISY (either direct or via plug-in) or just in general with the Hue app... Many of the posts I found are ancient in IT-years. Any info would be appreciated

I learned the offending instance of the plug-in has 2 sets of profile files, one in lowercase and one in uppercase. It looks like a previous version of the plugin was using uppercase, and the latest version - with new data fields - is using lowercase. IoX will use the uppercase first, then lowercase if uppercase not found. http://192.168.100.249:8080/rest/profiles/ns/8/files/ <profiles> <profile family="10" id="8"> <files dir="nls"> <file name="EN_US.TXT"/> <file name="en_us.txt"/> </files> <files dir="nodedef"> <file name="nodedefs.xml"/> <file name="NODEDEFS.XML"/> </files> <files dir="editor"> <file name="editors.xml"/> <file name="EDITORS.XML"/> </files> </profile> </profiles> I thought it strange that I was only having issues with one instance but this was the initial instance I installed and was the only one running for a while - so probably an issue that's been there since the first version of the plug-in. The only fix I'm been offered is to delete the plug-in and install it fresh. This worries me as I do have a lot of dependent programs. I went to try deleting an instance that has the fewest programs to see if/how deleting then installing (back in same slot) will restore all programs. I get this worrisome message that could mean all three instances will be gone if I click "Confirm". @Jimbo.Automates, have you ever tested deleting just one instance of the plug-in when you had a couple more running? Does it uninstall all instances or just the one for which you clicked the Delete button? Does installing back in the same slot restore all the program dependencies? Any info would be appreciated.

It might have helped if the re-install hadn't changed the short poll from 320 down to 60 and, better yet, kept the polling cycle the same, which it does not show any sign of doing (and might be hard thing to do, I presume). Most restarts of my 8 device controller instance will cause api rate limit to be exceeded, especially since it had to be restarted twice - once for the reinstall and again after I returned config to what it was supposed to be to avoid the api rate limit. It's a bit strange that the other controllers reported that too. They only have 2 and 3 devices, respectively. But then again I had to change their config back too. So just came too quickly, I guess. I have to say I've never seen this message before now.

After upgrading to 1.1.2 the instance that was not working - and still doesn't work - after the first upgrade, it no longer worked at all. I changed the config, which got reset by the reinstall, and, after no polling was done for > 20 mins, I did a restart of the plug-in. Got the message that it will try to rediscover on next poll. Waited 20 mins, did another restart - same message and no data updates for any of the sensors. I understand that you view this as a PG3x problem and I have a ticket open about it with UDI but it is happening to your plug-in so I thought you should know. I also am pointing to this forum thread so this will hopefully inform @bmercierand/or anyone else looking into it. Did a "Discover" and things came back (though still no new 1.1.x data fields in AC). While this is not a major problem, things are not restarting properly by themselves and, given they're supposed to, I thought this would be important to know.

sorry could not infer that from release notes. thought it could be different than the 16 devices when there are only 7. Very different numbers and also a totally different manifestation. Did not see the second problem shown at all when I reported the first one

ok, so a reinstall does reset config. here's a screenshot before re-install and after. short poll went from 320 to 60 and long poll from 360 to 240

maybe this is fixed in v 1.1.2 but today one of my instances reports an extra polling sensor. wasn't like this yesterday. don't think I did anything to make it happen. will try new version shortly

ok, it's not counting all devices for all instances. i just did a "discover" on instance with 3 sensors, and it reports 7 (not 13+)

I've reported to @bmercier, who asked me to open a support ticket so I did and sent all info I have I think I know why I thought the config had been overwritten. I got a message that my short poll was too low, which I then changed but had been configured adequately all the time. It's because the error message over counts the devices being polled by an instance. I added a device, did a "Discover" and, even though the total number of airthings wave devices is now 8 (9 nodes when you count controller), the message said I had 15 polled sensors when I first did it, then said I had 16 polled devices when I did it again (just to capture warning message for you). See screenshot below. Maybe, partly, it counts all devices controlled by all instances instead of just the ones for which the short poll applies? However that still doesn't quite explain things because I have 13 devices, not 15 or 16. Perhaps it counts the controller as a polled sensor? but why 15 the first time then 16? The good news is that the new device did show up in the Admin Console though not without a restart of of the AC. After this I still, though, don't see in the AC any of the new data fields that were added in v 1.1.1 of the plug-in - including no new data for the new device that was just added.

Got this reply to a query I submitted at openoeathermap.org about using the professional API I already have with a service built using OneCall 2.5

I noticed re-installing this plug-in overwrites the config. Got message about short poll. Change the poll values then nothing. it stopped updating. Had to restart plug-in to get polling working again. Maybe the restart is needed always after re-install. If so, could that be added to the documentation next time you're updating that? And could any existing configuration not get overwritten? Thanks for considering these things.