macjeff Posted June 2 Posted June 2 I checked other NodeServers and its just this one. After reboot of EISY (twice so far) I get the message after a while that 60 is too low for 5 devices. So I raise to 120 or more (I put 150) All is fine until I reboot and then its back to 60.
Jimbo.Automates Posted June 2 Posted June 2 That is bizarre, @johnnyt has reported similar issues. But, the nodeserver itself has no control over the short/long poll values, it can only read them, not set them. Will need help from @bmercier or @bpwwer if they have a clue. I've also been discussing with @bmercier to add a custom polling that is settable by the nodeserver, so hopefully that can be implemented soon. But in the meantime we need to understand how/why PG3 is resetting the short poll value.
bpwwer Posted June 2 Posted June 2 As far as I know, the only way the poll values can be set is via the UI. The only exception is when the plug-in is installed, it will default to either what's in the plug-in store entry or shortpoll=60 and longpoll=300. However, there should always be a store entry as that's not optional. These are the initial settings before the user has a chance to modify them. There is only one place in the PG3 code where it updates the database with new poll values and that is when an update to do so comes from the UI. So the only possible way this could be happening is if: 1) the default value set at install time is 60 seconds. 2) when updated in the UI, the database update fails but PG3's internal timers are updated. If the database update fails for any reason, it should be logging and error message. I'd suggest checking the PG3 log after changing the poll value(s) for errors. Another thing you can check is to try this from the command line: sudo sqlite3 /var/polyglot/pg3/pg3.db "select shortPoll from nodeserver where profileNum=2;" The profileNum is the slot number for the plugin. This command will return the value saved in the database for short poll. And case is important (i.e. shortPoll and profileNum).
Jimbo.Automates Posted June 2 Posted June 2 Thanks @bpwwer , one other question. When it sets the values at install time, does it know not to set them for an update install?Sent from my Pixel 8 Pro using Tapatalk
bpwwer Posted June 2 Posted June 2 No. When doing an update (which is defined by installing in a slot that already has the same plug-in installed), it does a database update vs. a database add. The update does use the plug-in store entries. The exception is for custom parameters, those are not replaced/overwritten by the update. shortPoll and longPoll are not part of the custom parameters so they do get overwritten by the update. So should they be? I can make arguments for having it either way, but I'm leaning towards thinking they should not be overwritten. It would be nice if we had some "smart" control over them. Like a way for the author to control that or away to ask the user if they want them overwritten, but since we can't do anything of that, I think the user would expect them to not be overwritten. Looking over the code, what about LogLevel? That is also overwritten by the default value when re-installing. Maybe that too should be left at whatever level the user has set.
bpwwer Posted June 2 Posted June 2 The code change to preserve those values is pretty simple. I've made the changes in my tree and @bmercier is ok with it, I can push those to the main tree.
Jimbo.Automates Posted June 2 Posted June 2 Thanks! I agree, log level should also be retained.Sent from my Pixel 8 Pro using Tapatalk
Recommended Posts