indigo utilities discussion

[roquej]

Never mind. Just so Matt's post with the test version. Tried it and worked.

JP

[aldonc]

Hi, using Utilities in Trigger or Schedule Actions works fine when you select a Device to Retrieve records and write it to a file or Indigo log. When I select Variables and write to the Indigo log I get the following error (writing to a file doesn't show an error - just fails silently):

Code: Select all

Nov 27, 2020 at 2:56:48 PM
   Trigger                         new trigger
   utilities Error                 ==================================================================================
   utilities Error                 error in querry:
Error: no such table: device_history_

   utilities Error                 ==================================================================================

It seems odd that there's a mention of device_history_ since I'm looking for a Variable.

Finally, this works ok when selecting Retrieve records from the Plugins - Utilities menu. Using SQLlite db.

Aldon

[kw123]

should be fixed in v .32 just posted.

sorry for responding so late.

Karl

[McIntoshBear]

I just downloaded and installed the "utilities" plugin.

How does one get around the macOS gatekeeper?

I think I figure out how to get around the macOS gatekeeper.

Is there a "User Manual"?

Received this error in the Event Log file when I attempted to get the temperature of my macMini.

***
Error (client) timeout waiting for plugin response from com.karlwachs.utilities for request UiAction
Error (client) received unexpected packet response UiAction (waiting for )

I tried to search the discussion but I did not have any success.

[kw123]

Is there an access limitation?

Check system setup / privacy & security


Sent from my iPhone using Tapatalk

[kw123]

Action Group test utilities temp
utilities raw data fan temp .. info (-99=not available)
temp_AMBIENT_AIR_0:-99.0
temp_AMBIENT_AIR_1:-99.0
temp_CPU_0_DIE:-99.0
temp_CPU_0_DIODE:-99.0
temp_CPU_0_HEATSINK:-99.0
temp_CPU_0_PROXIMITY:-99.0
temp_ENCLOSURE_BASE_0:-99.0
temp_ENCLOSURE_BASE_1:-99.0
temp_ENCLOSURE_BASE_2:-99.0
temp_ENCLOSURE_BASE_3:-99.0
temp_GPU_0_DIODE:-99.0
temp_GPU_0_HEATSINK:-99.0
temp_GPU_0_PROXIMITY:-99.0
temp_HDD_PROXIMITY:-99.0
temp_HEATSINK_0:-99.0
temp_HEATSINK_1:-99.0
temp_HEATSINK_2:-99.0
temp_LCD_PROXIMITY:-99.0
temp_MEM_SLOT_0:-99.0
temp_MEM_SLOTS_PROXIMITY:-99.0
temp_MISC_PROXIMITY:-99.0
temp_NORTHBRIDGE:-99.0
temp_NORTHBRIDGE_DIODE:-99.0
temp_NORTHBRIDGE_PROXIMITY:-99.0
temp_ODD_PROXIMITY:-99.0
temp_PALM_REST:-99.0
temp_PWR_SUPPLY_PROXIMITY:-99.0
temp_THUNDERBOLT_0:-99.0
temp_THUNDERBOLT_1:-99.0


the plugin is using osx-temp-fan see plugin directory :
/Library/Application Support/Perceptive Automation/Indigo 2023.1/Plugins/utilities.indigoPlugin/Contents/Server Plugin/osx-temp-fan

[kw123]

Code: Select all

Added features / changes in v2022.22.48 @ 2026-08-27
===================================================

--- print stuff -> "Plugin Names, IDs, mem, cpu, .." -------------------------------------------
1.  new column "ave_cpu" = average cpu used since the process started, in cpu seconds per 100
    seconds of run time. same unit as the CPU_usage_.. variables and the config dialog,
    100 = one full cpu core. printed for the plugins and for their sub processes.
    run time comes from "ps -eo pid=,etime="  (macOS ps has no "etimes" keyword).
2.  new column "run-time" = how long the process has been running, hh:mm:ss, hours not wrapped
    at 24. cpu-total, run-time and ave_cpu = cpu-total/run-time now sit next to each other.
3.  cpu-total is printed as hh:mm:ss as well. ps prints it as mm:ss.ff with unlimited minutes
    (3 hours of cpu = "180:00.00", never "3:00:00"), which did not match the run-time column.
    less than one second of cpu shows as 0:00:00.
4.  after the table the plugins are listed once more, sorted by cpu usage, biggest first:
    ave_cpu, ave_cpu including the plugins own sub processes (only filled in when there are
    any), and the plugin name. plugins without run time data sort to the end.
5.  2 line header, the second line gives the unit of every column (hh:mm:ss, cpu/100sec, MB ..),
    and the header is printed again at the END of the list. header and data lines now use ONE
    shared format string so the columns can not drift apart. Virtual and version columns
    widened, they overflowed and pushed the whole line right for eg 1,919,280 MB or v2026.56.445.
    sub process and openFile lines line up with the pluginName column.
6.  sub process lines showed the memory of their PARENT plugin, divided by 1024 a second time.
    now the sub process own memory, same units as the plugin lines (MB, the header said KB).

--- print stuff -> new: "detailed info for ONE plugin" ------------------------------------------
7.  select a running plugin and print everything known about it. cpu and memory are sampled
    every 2 seconds for 2 minutes first, then the report is printed. one line per process - the
    plugin itself, each sub process sorted by cpu, and a TOTAL line - so a busy plugin can be
    traced to the helper that is doing the work. cpu as ave/max in % of one core, memory as
    ave/min/max in MB. no cpu-min column: with a 2 second sample an idle moment is always found
    so it was 0.00 for everything. the TOTAL line is calculated from the summed samples, not by
    adding up the per process ave/min/max, so its min/max are the real ones.
8.  same report: DISK bytes read and written over the window, total and average per second,
    from proc_pid_rusage. exact and without a password, works for processes of the same user,
    which plugins are. root owned processes show n/a.
9.  same report: NETWORK bytes in and out, separately, total and average per second, from
    nettop. no password needed either. nettop only lists processes that had traffic while it
    sampled and it costs ~5 seconds per call, so it is read once before and once after the
    window, never in the sampling loop. permanent connections (websocket, MQTT, ssh) are
    measured well, a short request that opens and closes in between can be missed.
10. same report: the plugins devices (id / type / enabled / name, with the complete pluginProps),
    its event triggers, and the actions it offers, read from the plugins own Actions.xml.
    nothing is truncated and the names are last on the line so they can not be cut off.
11. same report: the VARIABLES the plugin creates and updates. indigo does NOT store which
    plugin owns a variable (a variable record has id, name, value, folder, readOnly - no owner,
    unlike devices and triggers), so the plugins own python files are read and searched for
    indigo.variable.create / updateValue / delete:
      - literal names are printed with their current value
      - a name kept in a plugin variable (self.var_name) is followed to where it is set,
        including config settings: VoiceReceiver does
        self.var_name = self.pluginPrefs.get("var_name", kDefaultPluginPrefs["var_name"]),
        the report prints the real name "voice_command_text" and its value
      - a name built from a prefix ("CPU_usage_"+pluginId) is printed with every live variable
        that starts with that prefix
      - calls that take the name from another object in a loop
        (indigo.variable.updateValue(var.name, ..)) are counted in one line - those are somebody
        elses variables that the plugin only writes to
12. same report: several plugins can be selected while one is still being sampled. the requests
    are queued and run one after the other, the log says how many run first. selecting the same
    plugin twice does not queue it twice. the queue does NOT use the shared taskList, so these
    jobs can not clobber or be clobbered by the other print jobs.


13. menu / action labels still pointed at the old "~/documents/indigoUtilities/" folder while
    the plugin has been writing to ~/indigo/utilities/ for a long time - all 9 corrected. the
    config label for the plugin logfile was missing the "Plugins/" part of the path. the
    "test only" label of delete-duplicate-records now names the file that is really written
    (squeezeSQLall), same for the message at the end of a test run. and the battery menu label
    said "print beteryLevels of devices to logfle" -> "print Batterylevels of devices to logfile".