1

Notifications false triggering - null to 0 help needed

Topic: Notifications false triggering - null to 0 help needed

I am in need of some help, it might be that there is a simple solution, but I have not been able to find it yet.

Issue:
We have notifications set to both states of a custom digital sensor, but when we use a command that causes the telematics unit to give a GPRS answer, the parameter value is null, so after being null the parameter changes back to the digital value, the notification triggers as if it has changed values.
To summarise: notification triggers as if a change of value has happened when the value goes from 0 to null to 0 again.

What I have tried:

  • ''Last message only' - I have used this in the sensors, and it does change the shown value to 'N/A', but the notification still triggers.
  • Not-null check - I validated against another sensor that becomes null at the same time, but the notification still triggers when it returns to the actual value which is the same before the GPRS answer.

I hope that makes sense and I can get a solution. Of course if I find one myself, I will say it here.

2

Notifications false triggering - null to 0 help needed

Re: Notifications false triggering - null to 0 help needed

I have not been able to resolve in Wialon.
I think the problem is that the sensor is a bitwise parameter of a user tag being supplied by the custom script on the unit. When the the command to change the output state is actioned on the tracker, there is a GPRS answer back with no other parameter values. The bitwise parameter triggers the sensor again when it return to 0 from the missing or error.
I have tried a lot of things, validators, and settings changes, including using '#user_d0:3' as a hidden sensor sensor to take the last value when there is an error, but then the notification does not work for a valid 0 or 1 value change.

My solution was to add a custom command to change the output state to not trigger the GPRS answer, and there is no issue any longer.
We did wish to keep the GRPS answer to act as a confirmation the command was actioned, without adding even more to the script on multiple units.

If anyone ever has an answer to this issue in Wialon, please let us know.

3

Notifications false triggering - null to 0 help needed

Re: Notifications false triggering - null to 0 help needed

Hi Alasdair Graham,

The same issue is discussed with developers here: https://forum.gurtam.com/viewtopic.php?id=18303

Still I have some temporary solution.
You need 2 notifications and 2 unit groups. Please follow the instruction below.

1. Create a group of units called "Current state is 0".

2. Create a group of units called "Current state is 1".

3. Put units in corresponding groups.
Please notice it is possible to put all units in 1 group and Wialon will automatically sort them soon, but you'll lose one notification trigger for some units.

4. Create a notification called "State changed from 0 to 1". It should work with the group "Current state is 0" only.
Trigger type — Sensor value, value from 1 to 1, trigger in range.
Action type — any you want to notify client + Modify unit groups (remove from "Current state is 0", add to "Current state is 1").
Set notification to generate when the state changes on the last settings page.

5. And vice versa. Create a notification called "State changed from 1 to 0". It should work with the group "Current state is 1" only.
Trigger type — Sensor value, value from 0 to 0, trigger in range.
Action type — any you want to notify client + Modify unit groups (remove from "Current state is 1", add to "Current state is 0").
Set notification to generate when the state changes on the last settings page.

Hope it will help you. Please share you feedback after some tests.

@ Oleg Zharkovsky
Technical Consulting / Training Team
"Timely is the best. But still better late than never."
4

Notifications false triggering - null to 0 help needed

Re: Notifications false triggering - null to 0 help needed

Hi Zark,

Unfortunately this world not be practical as we have several (4) sensors / monitored states that operate in this way, but I can see how it would work for a singular one that has the issue I asked about.