This is happening because, sometimes, the router will report this value as 0 or -90. I don’t know why. But I also don’t really care, so I don’t want this alert to trigger if it is a RouterOS wifi sensor that is under/over threshold.
So you can either exclude routeros from the rule directly && %devices.os != "routeros" or create a group called No RouterOS and use that single item in the entity and map the alert rule to that new group
I tried to add the != logic to stop it alerting on this OID, but it seems that each device has a slightly different one, probably based on the interfaces on it.
Ah, I understand it now! .1.3.6.1.4.1.14988.1.1.1.2.1.3 is a table.
It’s basically a table of all the wireless clients connected to a specific WLAN interface. The all the other octets are referencing a specific value for a specific row on the table.
So the above is the perceived TX/RX value of a single client device.
So to avoid alerting on it I need what you suggested @laf, but I can ignore anything after the .3. && %sensors.sensor_oid !~ ".1.3.6.1.4.1.14988.1.1.1.2.1.3.@"
I’m not sure that this is a useful value as it is right now. That graph basically shows a single client’s RX/TX info, but I’m not sure how it chooses which client, or even if it use data from the same client each time?
If we’re going to use this info, it needs to be presented in a table as intended.
Thank you both for solving this for me. After enabling 802.11ac on my Mikrotik hAP it’s been alerting me for weeks now about poor signal and these alerts are spamming my every move on my Slack notifier.