Been running it all day and seems to work well so far. Though I didn't test the influxdb part. Thank you very much for fixing it!OK, so I managed to get my test system up after a few hours of bashing my head on an old problem that turned out to be caused by an ad-blocker... anyway, it's running.
I have a couple of issues though:
1. It's a VM, so I don't get CPU temps / no sensors. So I have tested it only with the options set for "$cpu_temp_control = 1" and "$cpu_fans_cool_hd = 1". Obviously that's not what others would want to do so I set those ones to 1 instead of 0. Remembering that the original script doesn't actually recommend to control the CPU FAN instead of the CPU_FAN header on most MoBos, just to control the outlet fans behind the CPU, so that's something that may not even be necessary if you have a good CPU FAN and can leave your rear case fans at an optimal speed.
2. I'm using an OpenCorsairLink device (commander pro) passed into the VM as a USB device... so can only test that option, not the other 2 options I have in the script (ASRock or Supermicro)
So if somebody wants to have a look at it and let me know how it goes, Great!
I have it set for everything to go in /root/ for now, but you could put it somewhere in a pool if you prefer and update the locations in the MASTER file.
It's currently set for linux OS (SCALE) and for supermicro fan control.
Edit the MASTER file to fill in your needed variables... I would recommend looking at these 3 and see if you want to mess with influx or not... make sure you create the DB on the influx server with a matching name.
$use_influx = 1
$influxdb_db="freenas"
$influxdb_host="192.168.1.1"
it's important that you also set your fan max speeds to numbers that your fan can actually hit:
$cpu_max_fan_speed = 2200
$hd_max_fan_speed = 1500
You should set the MASTER file to executable first, then run it.
What's eluding you? maybe there are some pointers I can share.But the dashboard (grafana) is proving headscratching
from(bucket: "truenas") |> range(start: v.timeRangeStart, stop: v.timeRangeStop) |> filter(fn: (r) => r["_measurement"] == "DiskTemp") |> filter(fn: (r) => r["_field"] == "value") |> filter(fn: (r) => r["component"] == "NewNASnvme0" or r["component"] == "NewNASnvme1" or r["component"] == "NewNASsda" or r["component"] == "NewNASsdb" or r["component"] == "NewNASsde" or r["component"] == "NewNASsdf" or r["component"] == "NewNASsdl" or r["component"] == "NewNASsdk" or r["component"] == "NewNASsdm" or r["component"] == "NewNASsdn" or r["component"] == "NewNASsdo" or r["component"] == "NewNASsdp" or r["component"] == "NewNASsdq" or r["component"] == "NewNASsdv" or r["component"] == "NewNASsdx") |> aggregateWindow(every: v.windowPeriod, fn: mean, createEmpty: false) |> yield(name: "mean")
it's this line (108):I am curious as to how the script filters out some of the SSD's. It appears to take data from sfdisk -l
next if (/Verbatim|Kingston|Elements|Enclosure|Virtual|KINGSTON|mapper/);
if (/Temperature_Celsius|Airflow_Temperature_Cel/) { $temp = (split)[9]; }
if (/Temperature_Celsius|Airflow_Temperature_Cel|Temperature_Internal/) { $temp = (split)[9]; }
I don't know if this is something you copied directly, but I'm very interested to see since I made what I thought was a typo and couldn't see it for ages as the cause for nothing working...HDD = 194 Temperature_Celcius
Something like that, but maybe also add Temperature_Celcius if some or all of your drives report it like that.So would the line be:
Code:
if (/Temperature_Celsius|Airflow_Temperature_Cel|Temperature_Internal/) { $temp = (split)[9]; }
This looks like a promising replacement for this script that I have used for years.OK, so I managed to get my test system up after a few hours of bashing my head on an old problem that turned out to be caused by an ad-blocker... anyway, it's running.
I have a couple of issues though:
1. It's a VM, so I don't get CPU temps / no sensors. So I have tested it only with the options set for "$cpu_temp_control = 1" and "$cpu_fans_cool_hd = 1". Obviously that's not what others would want to do so I set those ones to 1 instead of 0. Remembering that the original script doesn't actually recommend to control the CPU FAN instead of the CPU_FAN header on most MoBos, just to control the outlet fans behind the CPU, so that's something that may not even be necessary if you have a good CPU FAN and can leave your rear case fans at an optimal speed.
2. I'm using an OpenCorsairLink device (commander pro) passed into the VM as a USB device... so can only test that option, not the other 2 options I have in the script (ASRock or Supermicro)
So if somebody wants to have a look at it and let me know how it goes, Great!
I have it set for everything to go in /root/ for now, but you could put it somewhere in a pool if you prefer and update the locations in the MASTER file.
It's currently set for linux OS (SCALE) and for supermicro fan control.
Edit the MASTER file to fill in your needed variables... I would recommend looking at these 3 and see if you want to mess with influx or not... make sure you create the DB on the influx server with a matching name.
$use_influx = 1
$influxdb_db="freenas"
$influxdb_host="192.168.1.1"
it's important that you also set your fan max speeds to numbers that your fan can actually hit:
$cpu_max_fan_speed = 2200
$hd_max_fan_speed = 1500
You should set the MASTER file to executable first, then run it.
You could try, but I would advise having a careful look at the top section of the script in full and filling things like whether the HD fans cool the CPU and vice versa.Could I just take the values from my old script (fan zones and rpms) and slap those values in the corresponding places in your script and ignore the other options?
That's a good idea. I'll give it a shot and report how it goes.You may also be able to get it going on CORE first and just change the paths and OS when you switch to SCALE.
Just set $use_influx = 0 at the top in the variables and you don't need to mess with the rest of the influx stuff.#'d out "my @output = run_command(@influxcommand); " just in case to stop it logging rubbish (if it gets that far)
That would be really odd, as the if statement for freebsd just pushes the same code as was in the original script for CORE (so should be working).I don't think the script likes the output of camcontrol devlist as opposed to sfdisk -l
For sure some of those need changing for the thing to work.I need to check through the paths as that is I suspect the first cause of issues.
root@QNAS[/mnt/Tank/SMB/QNAS-Scripts/sretella]# ./influxtemps_SCALE.pl <HGST HUS726T4TALA6L4 VLGNW40H> at scbus0 target 0 lun 0 (ada0,pass0) <HGST HUS726T4TALA6L4 VLGNW40H> at scbus1 target 0 lun 0 (ada1,pass1) <ST4000NM0033-9ZM170 SN04> at scbus2 target 0 lun 0 (ada2,pass2) <WDC WD4000FYYZ-01UL1B2 01.01K03> at scbus3 target 0 lun 0 (ada3,pass3) <ST4000NM0033-9ZM170 SN04> at scbus6 target 0 lun 0 (ada4,pass4) <ST4000NM0033-9ZM170 SN04> at scbus7 target 0 lun 0 (ada5,pass5) <WDC WD4000FYYZ-01UL1B2 01.01K03> at scbus10 target 0 lun 0 (ada6,pass6) <HGST HDN724040ALE640 MJAOA5E0> at scbus14 target 0 lun 0 (ada7,pass7) <AMicro AM8180 NVME 1.00> at scbus18 target 0 lun 0 (da0,pass8) <JMicron Tech 0209> at scbus19 target 0 lun 0 (da1,pass9) Use of uninitialized value $disk_dev in concatenation (.) or string at ./influxtemps_SCALE.pl line 155. smartctl 7.2 2021-09-14 r5236 [FreeBSD 13.1-RELEASE-p7 amd64] (local build) Copyright (C) 2002-20, Bruce Allen, Christian Franke, www.smartmontools.org /dev/: Unable to detect device type Please specify device type with the -d option. Use smartctl -h to get a usage summary Use of uninitialized value $name_nospaces in substitution (s///) at ./influxtemps_SCALE.pl line 80. Use of uninitialized value $name_nospaces in concatenation (.) or string at ./influxtemps_SCALE.pl line 81. Use of uninitialized value $value in concatenation (.) or string at ./influxtemps_SCALE.pl line 81. % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 130 100 100 100 30 44503 13351 --:--:-- --:--:-- --:--:-- 65000 HTTP/1.1 400 Bad Request Content-Type: application/json; charset=utf-8 X-Influxdb-Build: OSS X-Influxdb-Version: v2.6.1 X-Platform-Error-Code: invalid Date: Mon, 06 Mar 2023 16:40:20 GMT Content-Length: 100