Temperature monitoring script stoped working after v7 upgrade

can you pleas help me my script stop work after upgrade


:global tempstatus
:global templaststatus
:global systemtemp [/system/health/print value-name=temperature as-value]

:if ($systemtemp < 33) do={
    :set tempstatus "System temp is within spec"
} else={
    :if ($systemtemp > 42) do={
        :set tempstatus "System temp is ntek ekhetna"
    } else={
        :if ($systemtemp > 40) do={
            :set tempstatus "System temp is m2ayra ktiiiiiiir"
        } else={
            :if ($systemtemp > 37) do={
                :set tempstatus "System temp is critical"
            } else={
                :if ($systemtemp > 35) do={
                    :set tempstatus "System temp is too high"
                }
            }
        }
    }
}

:if ($tempstatus != $templaststatus) do={
    /tool e-mail send to="**ELIDED**" subject=("Router 1100-Tall Temperature Alert - $[/system/clock/get date]") body=("This router 1100-Tall has a temperature alert. Date: $[/system/clock/get date] Status: $tempstatus - $systemtemp °C")
    :log info "Email sent about system $tempstatus status"
    :set templaststatus $tempstatus
}

You mean that it worked on v6 and it doesn’t work on v7?

Things have changed in /system/health/, maybe this is the issue, see:
http://forum.mikrotik.com/t/health-readings-with-v7/153394/1

thanks for replay

/ system health print
Columns: NAME, VALUE, TYPE

NAME VALUE TYPE

0 voltage 23.7 V
1 temperature 26 C
2 power-consumption 10.8 W
3 current 0.4 A
4 psu1-voltage 0 V
5 psu2-voltage 24.8 V

Please don’t cross-post, @mmdelhajj. I just deleted a duplicate of your post above in the linked thread. If you want this post merged into the other thread, you can ask and have the matter considered, but don’t open the same topic in multiple locations.

Also, in case you’re wondering how you ended up with a dedicated topic, it’s because you originally necroposted this question to a nearly-unrelated 2022 thread.

Your script:
:global systemtemp [/system/health/print value-name=temperature as-value]

On v7 it should become:
:global systemtemp ([/system health get [find where name=“temperature”]]->“value”

To assign the value to the variable.

Some other parts of your script may also need changes, cannot say.

i have this error at all script

executing script script1 from winbox failed, please check it manually

This is the temperature monitoring script I am using on some switches and it works with 7.15.2

:local DesiredTemp 70
:local MonitoredSensor "phy-temperature"
:local NotifyTo "notify@to.com"
:local NotifyFrom "RouterOS-Monitor<noreply@domain.com>"
:local DeviceName [/system identity get name];
:local CurrentTemp [/system/health get [find name=$MonitoredSensor] value]
:local LogMessage ""
:global IsNotifiedAbove;
:global IsNotifiedBelow;
{
:if ($CurrentTemp>$DesiredTemp) do={
      :if ($IsNotifiedAbove !=1) do= {
      :set LogMessage "Temperature for $MonitoredSensor is over the limit: $CurrentTemp Celsius"
      :log warning $LogMessage;
      
/tool e-mail 
      set from="$NotifyFrom" 
      send to="$NotifyTo" \
      subject="Temperature warning on $DeviceName" body="The current temperature for $MonitoredSensor of $CurrentTemp Celsius is over the set limit of $DesiredTemp Celsius" ;
      :set IsNotifiedAbove 1;
      :set IsNotifiedBelow 0;
      } 
}
:if ($CurrentTemp<$DesiredTemp) do={
      :if ($IsNotifiedBelow !=1) do= {
      :set LogMessage "Temperature for $MonitoredSensor is now back to normal: $CurrentTemp Celsius"
      :log warning $LogMessage;
      
/tool e-mail 
      set from="$NotifyFrom" 
      send to="$NotifyTo" \
      subject="Temperature warning on $DeviceName" body="The current temperature for $MonitoredSensor of $CurrentTemp Celsius is now under the set limit of $DesiredTemp Celsius" ;
     :set IsNotifiedAbove 0; 
     :set IsNotifiedBelow 1;
      } 
}
}

If work, why change???..

Why change without read all changelogs between versions???..

To be fair, a large part of the posts by forum members do advise to upgrade to the latest-bestest version.
The good ol' concept of "if it ain't broke don't fix it";
https://en.wiktionary.org/wiki/if_it_ain't_broke,_don't_fix_it
seems to be rare.

IF things are NOT working.
I doubt anyone will suggest to upgrade just for the act of upgrading when everything is already working as expected ...

Yep, but a decalogue roughly similar to the following should be made sticky:

DO NOT EVEN THINK OF UPGRADING
to a later, more recent RoS version than the one you are currently running, UNLESS:

  1. you have reviewed line by line EACH and EVERY change listed in EACH and EVERY ROS release published after your current one and up to the one you wish to upgrade to

  2. you have BOTH:
    2.a. a backup of the current configuration
    2.b. an export of the current configuration

  3. you are already familiar with both the reset and the netinstall procedures and can use Winbox and SSH

  4. you are sure, double sure and triple sure that the release you want to upgrade to:
    4.a. has an added feature that you really-really need
    4.b. has NOT reported bugs that may affect your configuration

  5. you have physical access to the device (NO remote upgrade)

  6. you are prepared to the common need to correct/rewrite/modify your scripts (if any) to make them work with the new version (syntax often changes, in some cases in very subtle ways)

  7. you have the possibility and time to troubleshoot possible issues created by either your old configuration (that is working by sheer luck on the older version, due to this or that quirk of the ROS) or by (documented or undocumented) possible changes in the way the new ROS version interprets your settings

  8. you really know what you are doing or you were suggested to upgrade by an expert member of the forum (providing a valid reason why the upgrade is advised)

  9. you have something that is currently not working as it should in your device and you are reasonably convinced that the new version may solve the problem

  10. you have faith in your abilities and experience with the tools and procedures mentioned and with ROS

If you miss even one of the points in the above decalogue, wait before upgrading and ask for advice.

In a nutshell, if it ain’t broke don’t fix it.