stop and start plugin

it would be really nice if one could not just RESTART/RELOAD but also a STOP and START of a plugin.

I still have issues with my indigo-DB connection. Sometimes (~ 1 every 2 weeks) it goes of the rails, likely from changing a format of a column (eg int to real)
Then the logfile gets flooded with error messages. A simple sqllogger stop, wait 30 secs and then start solves it.

A restart is too quick.

Karl

You mean from the client? Or from a script? Or Action/Schedule/Trigger?

Manually, stop/start is the same as disable/enable.

I think that starting/stopping a plugin from a script would be a pretty substantial security risk. I seem to recall Matt and Jay saying as much in the past.


Sent from my iPhone using Tapatalk

the difference I need is wait 30 secs after stop before restart , the currently available reload of a plugin is immediate.

Does anyone have a way to do this eg via applescript : tell finder xxx (or any other tool)

Karl

Does anyone have a way to do this eg via applescript : tell finder xxx (or any other tool)

If you kill or otherwise mess with the running process it acts the same way as a restart, I've been down that path myself. If you kill an active PID of a plugin then Indigo registers it as a crash and tries to instantly restart it.

The only way I could think of doing it, and it would be a hack, would be to rename the plugin file with an OS command and then restart the plugin - which will cause Indigo to error because it cannot find it, then wait 30 seconds and rename it back and restart it again. Fairly harmless way to do it and would get you what you want.

renaming the plugin .. thats a cool idea!!

renaming the plugin .. thats a cool idea!!

I have all sorts of cool ideas, now if only I had good ideas too!

... but unfortunately indigo does not stop the SQL-Logger if the plugin is gone..

so
1. make backup copy (cp -R ....)
2. deleting the plugin (rm -R ... )
3. reloading plugin

Does not stop the plugin. It first checks if the plugin exists then does the reload..

Karl

[jay (support)]

I think that starting/stopping a plugin from a script would be a pretty substantial security risk. I seem to recall Matt and Jay saying as much in the past.

Exactly.

[jay (support)]

I still have issues with my indigo-DB connection. Sometimes (~ 1 every 2 weeks) it goes of the rails, likely from changing a format of a column (eg int to real)

Seems like fixing the underlying issue is a better idea. Do you know what exactly is causing the db connection to fail? What are you connecting to exactly? If we can catch the error in the plugin, then we could likely deal with it in the plugin.

sql-logger uses postgres app . The postgres DB is about 32 GByte

These events happen when a new devices gets created and a device state changes from eg integer to real. That might take a while before it happens as not all states get modified/ updated immediately, hence the table might not be small.

I guess the postrgres app is busy updating the column from the old format to the new format. Then when indigo wants to update the next device/state indigo-postgres connection times out.
The same happens with SQLlite.

We have discussed this on and off over the last 2 years.
One solution would be to increase the indigo - sql timeout, but that idea was rejected.


Karl

[jay (support)]

32GB seems like an excessive amount of data. The easiest way to solve this issue is to trim the DB. If you really do need to keep/process 32GB of data, you might want to look for alternate solutions that are better suited to storing and processing large data sets. The SQLLogger plugin and data structure isn't really intended to be a high performance data analysis solution, so it may be that you've outgrown it in terms of what you're trying to do.

If Postgres is bogging down, then that points to a couple of areas of investigation: 1) the structure of the data isn't conducive to large storage, 2) Postgres doesn't have access to enough resources (memory, CPU), 3) the storage that the DB resides on is slow.

The solution to #1 is to use a different storage layout that's more optimized to whatever the consumer of the data needs. This would likely mean a new plugin that catches all the relevant data (like the SQLLogger plugin does) but formats/stores the data in a different way or perhaps a different data storage technology (Influx, etc). In my former life I was VP Engineering for a high-volume payment system. One thing that we learned early on is that storing the transactional data for use in, say, reporting, required a very different approach than just storing raw transactional data. The SQLLogger plugin is more for the latter.

The solution to #2 would be to give Postgres more memory and/or cpu time. I don't know if that's configurable in the Postgres app, so it might require a separate server running Postgres that can be more dedicated.

The solution to #3 would be to get faster storage to store the DB on. If you're already on a fast SSD then you may already be maxed out there.

the MAC is running at ~ 5-10% CPU
SSD is a PCIe 1 TB , not SATA


but this seems to work:

Code: Select all

activate application "Indigo 7"
delay 1
tell application "System Events"
   tell process "Indigo 7"
      tell menu bar 1
         click menu bar item "Plugins"
         tell menu bar item "Plugins"
            click menu item "SQL logger" of menu 1
            tell menu item "SQL logger" of menu 1
               click menu item "Disable" of menu 1
            end tell
         end tell
      end tell
      delay 30
      
      tell menu bar 1
         click menu bar item "Plugins"
         tell menu bar item "Plugins"
            click menu item "SQL logger" of menu 1
            tell menu item "SQL logger" of menu 1
               click menu item "Enable" of menu 1
            end tell
         end tell
      end tell
   end tell
end tell


no have to call is as osa script

You probably ought to just figure out a better solution now, since that will break as soon as AppleScripts targeting Indigo stop working. Which is 7.2 I think.

You probably ought to just figure out a better solution now, since that will break as soon as AppleScripts targeting Indigo stop working. Which is 7.2 I think.

I think that script will still work because it doesn't target the Indigo namespace but rather the app and its menu, which is generic. I'm pretty sure of that but may be on crack. It may need to be worded a little differently to be more of a generic "hey macOS, mimic this keyboard or mouse action".

The "tell process" should be the differentiator in this question, that's not the Indigo space.