[ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule '....': null/2048/4096

I have some rules that once in a while start to misbehave … and never return to normal behaviour … even if potential problematic JSON-input seems to return to normal.

Instead I’m forced to restart openhab …seemingly every 2-3 days.

2020-06-02 07:19:07.585 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'Aktualisierung von Wetterdaten-Aussentemperatur': 4096
2020-06-02 07:19:12.609 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'Meter HH - Ermittle EUR fuer akt. Tag und Vortag': 4096

Sometimes the error code is 2048 instead of 4096, see logs below.

On startup the rules work like a charm for say 2-3 days … but then suddenly they spit out errors and I’m stuck tracing the problem down.

What does the error code “4096” or even “2048” tell me?

I’ve seen mainly “null” related problems in other forum posts on “ntime.internal.engine.RuleEngineImpl”. So my items seem to exist … maybe the state is corrupted?

One of the rules goes like this … the other is rather similar. The rule should fire only on changes to the item.

rule "Meter HH - Ermittle EUR fuer akt. Tag und Vortag"
when
  Item iENERGY_METER1_HH_ZAEHLER changed
then
  var Number TMP_kw_AKTUELL
  var Number TMP_kw_VORTAG     
  var Number TMP_kw_TAG        
  var Number TMP_Kosten_VORTAG 
  var Number TMP_Kosten_TAG    

  var Number TMP_APreis =   0.2553   // pro kWh
  var Number TMP_GPreis = 121.560    // pro Jahr

  TMP_kw_AKTUELL = iENERGY_METER1_HH_ZAEHLER.state as DecimalType
  TMP_kw_VORTAG  = iENERGY_METER1_HH_ZAEHLER.minimumSince(now.withTimeAtStartOfDay.minusDays(1)).state as DecimalType
  TMP_kw_TAG     = iENERGY_METER1_HH_ZAEHLER.minimumSince(now.withTimeAtStartOfDay).state as DecimalType
  TMP_kw_VORTAG = (TMP_kw_TAG     - TMP_kw_VORTAG) / 1000.0
  TMP_kw_TAG    = (TMP_kw_AKTUELL - TMP_kw_TAG)    / 1000.0
 

  iENERGY_METER1_HH_ZAEHLER_KWH_VORTAG.postUpdate(TMP_kw_VORTAG)
  iENERGY_METER1_HH_ZAEHLER_KWH_TAG.postUpdate(TMP_kw_TAG)
  TMP_Kosten_VORTAG = TMP_kw_VORTAG * TMP_APreis + (TMP_GPreis / 365)
  TMP_Kosten_TAG    = TMP_kw_TAG * TMP_APreis + (TMP_GPreis / 365)

  iENERGY_METER1_HH_KOSTEN_VORTAG.postUpdate(TMP_Kosten_VORTAG)
  iENERGY_METER1_HH_KOSTEN_TAG.postUpdate(TMP_Kosten_TAG)
end

The trigger item iENERGY_METER1_HH_ZAEHLER is fed every 10 seconds by a json-transformation via html. I suspect some problems on that side triggering the whole mess … but I’m not sure.

Number iENERGY_METER1_HH_ZAEHLER "HH Zähler [%,.1f Wh]" { http="<[http://some.internal.domain.de%3A8084:10000:JSONPATH($.data[?(@.uuid=='a8da012a-9eb4-49ed-b7f3-38c95142a901')].tuples[0][1])]" }

The complete logs, when the problem starts are like this … the 17h log entry is still fine … then after a quite phase the first sign of a problem occurs on 21:43 in the logs …

The rules acts on a “null” item-instance … the same moment some JsonSyntax errors are logged. DataFormatEx produces errors … some function expected a [0-9a-fA-F] format but got some “0xff” bytes.

2020-05-28 17:31:43.575 [INFO ] [.openhab.action.prowl.internal.Prowl] - API call succeeded. 994 api calls left.
2020-05-28 21:43:40.943 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'Meter WP - Ermittle EUR fuer akt. Tag und Vortag': null
2020-05-28 21:43:40.949 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'Meter HH - Ermittle EUR fuer akt. Tag und Vortag': com.google.gson.JsonSyntax
Exception: com.google.gson.stream.MalformedJsonException: Unterminated array at line 1 column 37331 path $.results[0].series[0].values[1232][1]
2020-05-28 21:56:45.488 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'Meter WP - Ermittle EUR fuer akt. Tag und Vortag': java.util.zip.DataFormatEx
ception: invalid distance too far back
2020-05-28 21:56:45.488 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'Meter HH - Ermittle EUR fuer akt. Tag und Vortag': Expected leading [0-9a-fA-
F] character but was 0xff
2020-05-28 22:03:27.824 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'Meter HH - Ermittle EUR fuer akt. Tag und Vortag': null
2020-05-28 22:03:27.824 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'Meter WP - Ermittle EUR fuer akt. Tag und Vortag': com.google.gson.JsonSyntax
Exception: com.google.gson.stream.MalformedJsonException: Unterminated array at line 2 column 2 path $.results[0].series[0].values[2446][1]
2020-05-28 23:39:49.720 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'Meter HH - Ermittle EUR fuer akt. Tag und Vortag': null
2020-05-28 23:39:49.720 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'Meter WP - Ermittle EUR fuer akt. Tag und Vortag': com.google.gson.JsonSyntax
Exception: com.google.gson.stream.MalformedJsonException: Unterminated array at line 1 column 34662 path $.results[0].series[0].values[1302]
2020-05-28 23:39:53.177 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'Aktualisierung von Wetterdaten-Aussentemperatur': 2048
2020-05-28 23:39:59.717 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'Meter HH - Ermittle EUR fuer akt. Tag und Vortag': 2048
2020-05-28 23:40:01.548 [ERROR] [org.influxdb.impl.BatchProcessor    ] - Batch could not be sent. Data will be lost
retrofit.RetrofitError: 2048
        at retrofit.RetrofitError.unexpectedError(RetrofitError.java:44) ~[retrofit-1.9.0.jar:?]
        at retrofit.RestAdapter$RestHandler.invokeRequest(RestAdapter.java:400) ~[retrofit-1.9.0.jar:?]
        at retrofit.RestAdapter$RestHandler.invoke(RestAdapter.java:240) ~[retrofit-1.9.0.jar:?]
        at org.influxdb.impl.$Proxy141.writePoints(Unknown Source) ~[?:?]

One related follow-up error is like this … influx is not able to persist any item any more.

2020-06-02 07:19:00.996 [ERROR] [org.influxdb.impl.BatchProcessor ] - Batch could not be sent. Data will be lost retrofit.RetrofitError: 4096

Another rrd4j persistence job seems to work and produce graphics as expected.

MfG
Peter

Welcome to the forum! What is in your event.log at the time of these errors? Specifically, the value of iENERGY_METER1_HH_ZAEHLER. If the incoming data is bogus, filtering it out in the rule may help. Also, what hardware are you running OH on?

Mhhh … sorry … because of the rolling event logs that exact moment of time when the error situation occurred just passed by … I have to wait until the problematic situation shows up again … I’ll post it then.

But what I’ve seen so far is that in the time while_the_error_persists … the postUpdate() to the derived items did not work:

iENERGY_METER1_HH_ZAEHLER_KWH_VORTAG.postUpdate(TMP_kw_VORTAG)
iENERGY_METER1_HH_ZAEHLER_KWH_TAG.postUpdate(TMP_kw_TAG)
iENERGY_METER1_HH_KOSTEN_VORTAG.postUpdate(TMP_Kosten_VORTAG)
iENERGY_METER1_HH_KOSTEN_TAG.postUpdate(TMP_Kosten_TAG)

That seemingly caused the error codes 2048 and later one even 4096 …

The original trigering item iENERGY_METER1_HH_ZAEHLER nevertheless got reasonable values …

events.log:2020-06-02 07:22:24.051 [vent.ItemStateChangedEvent] - iENERGY_METER1_HH_ZAEHLER changed from 22378928.6 to 22378929.8
events.log:2020-06-02 07:22:24.069 [vent.ItemStateChangedEvent] - iENERGY_METER1_HH_ZAEHLER changed from 22378929.8 to 22378931
events.log:2020-06-02 07:22:34.148 [vent.ItemStateChangedEvent] - iENERGY_METER1_HH_ZAEHLER changed from 22378931 to 22378932.200000003

And even another rule fired ok and updated the derived item iENERGY_METER1_HH_ZAEHLER_KWH in reasonable ways …

iENERGY_METER1_HH_ZAEHLER_KWH changed from 22378.92860000 to 22378.92980000
events.log:2020-06-02 07:22:34.137 [vent.ItemStateChangedEvent] - 
iENERGY_METER1_HH_ZAEHLER_KWH changed from 22378.92980000 to 22378.93100000
events.log:2020-06-02 07:22:44.214 [vent.ItemStateChangedEvent] - 
events.log:2020-06-02 07:22:44.234 [vent.ItemStateChangedEvent] - iENERGY_METER1_HH_ZAEHLER_KWH changed from 22378.93100000 to 22378.93220000

To me it seems that the triggering item iENERGY_METER1_HH_ZAEHLER is just fine, it’s not NULL …

Does anybody know what the rules error codes 2048 or 4096 do mean?
Do they help to understand the problem?

MfG
P

Oh … by the way it’s a Raspberry Pi 4 Model B Rev 1.1 with 4gb running on Arch Linux for arm-32bit-hf with zulu-embedded-jdk8 8.0.252-1 and openhab2 2.5.5-1 from arch user repos.

Linux openhab 5.4.42-1-ARCH #1 SMP PREEMPT Tue May 26 01:49:01 UTC 2020 armv7l GNU/Linux

P

Interesting one.
Sometimes mysterious but useless reports like this are associated with some non-obvious array based action.

I’m going to guess though, it’s the persistence action. As you’ve already noted, the JSON related disaster seems to have messed up persistence as well.
I’ll guess this is the minimumSince() call in the rule timing out, or suchlike.

Certainly I’d view it as symptom not cause.

Is your influxdb remotely hosted? Taking an overview, it all looks like a comms failure.

SD card or SSD? If SD, it may be faulty.

The error reporting from the old rule engine is typically unhelpful. It is much better with the new rule engine. Switching may resolve the issue or provide better logging for troubleshooting.

The event.log file will continuously roll over at 16MB and create a new one. These files are not deleted, so the log should still exist. Look under $OPENHAB_LOGDIR, which is usually /var/log/openhab2, for your event logs.

SD … I’d rule out that it’s already faulty …

good tip … will try when ohab3 is out …

As i said … see yourself … May 28 and before is not available any more with standard logging … “events.log.1” starts around midnight May 29 … I have a pretty decent knx installation with some traffic …
-rw-r–r-- 1 openhab openhab 16777333 29. Mai 15:58 events.log.1
-rw-r–r-- 1 openhab openhab 16777221 30. Mai 05:04 events.log.2
-rw-r–r-- 1 openhab openhab 16777225 30. Mai 15:23 events.log.3
-rw-r–r-- 1 openhab openhab 16777261 31. Mai 05:40 events.log.4
-rw-r–r-- 1 openhab openhab 16777366 31. Mai 20:57 events.log.5
-rw-r–r-- 1 openhab openhab 16777302 1. Jun 13:36 events.log.6
-rw-r–r-- 1 openhab openhab 16777303 2. Jun 07:22 events.log.7
-rw-r–r-- 1 openhab openhab 6754390 2. Jun 13:23 events.log

P

hi,

sigh … :wink:

I have set rrd4j as default persistence. minimumSince() should act on this persistence. i changed code a bit. see if it works …

InfluxDB is just a companion to get to know it a little bit better and optimize retention policies and continuous queries.

I badly miss tags in the openhab influx addon.

P

It is safer to assume that your SD card is always in a state of failing. :slight_smile:

In case you are not aware, it has been available for ~5 years now… no need to wait! Although, it will be easier to setup scripting languages in OH 3.0… or 2.5.6 if the maintainers would complete the review of my PRs!

The log be available then for the error today at 2020-06-02 07:19:07.585.

You’re right … i’ve read some of the discussions in the forum and elsewhere … nevertheless i decided to take the risk provisionally. Backup strategy exists … :wink:

Thanks for pointing out. I was already thinking about it. But I’m still shy to start a “new project” now …

Current rules are rather difficult to debug. Starters only have a chance to cope with this by copying examples … as I do a lot. These are mostly “old style rules”.

Any progress on rules is greatly appreciated!

That was the ohab restart after 5 days in error state … believe me the event log from 5 days ago is gone.

When the error occurs, the JSON recovers at sometime very soon … some minutes or so.
The triggering item then shows no extraordinary behaviour any more.

It’s just that the system is still “out of balance” … i would say it lacks “error resistance” with respect to some addons … here namely “influxdb persistence” and the “execution of certain rules”. But not all rules … some still work on the recovered triggering item!

So finally this error condition forces a reboot … it’s not a temporary problem … the JSON recovery is not enough to return to normal system behaviour.

P

I think I understand now… the rule has been erroring for 5 days.

The next time this happens, it would be interesting to see if you can get the data manually. It may be better to pull and massage the data in a rule and then update all of the Items.

yep.

What’s pretty bad is, you don’t notice the error condition immediately … no red flag or alarm sounding … knx is just working … will check more often now.

P

I got some more error codes … :wink:
They don’t mean anything in the context of the rule itself.

But let me explain, what I have changed in the meantime …

I restructured my rules and items a little bit … and finally switched to the new smartmeter addon to read my smartmeter’s values … finally abandoning the http/json/vzlogger solution that I had since the ohab 1.8.x times … I thought json was the problem, but I still got the same kind of errors with so many changes to the rules, used addons, etc … see yourselfs.

2020-06-04 21:31:25.379 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule '40 - Berechne HH Verbrauch und Kosten - aktueller Monat': java.io.EOFException
2020-06-04 21:34:56.564 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule '31 - Berechne WP Verbrauch und Kosten - heute': java.io.EOFException
2020-06-04 21:34:56.567 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule '51 - Berechne WP Verbrauch und Kosten - aktuelles Jahr': null
2020-06-04 21:34:56.568 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule '41 - Berechne WP Verbrauch und Kosten - aktueller Monat': null
2020-06-04 21:56:24.872 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule '40 - Berechne HH Verbrauch und Kosten - aktueller Monat': null
2020-06-04 21:56:24.872 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule '50 - Berechne HH Verbrauch und Kosten - aktuelles Jahr': null
2020-06-04 21:56:24.874 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule '30 - Berechne HH Verbrauch und Kosten - heute': Expected leading [0-9a-fA-F] character but was 0x99
2020-06-04 21:56:24.958 [ERROR] [org.influxdb.impl.BatchProcessor    ] - Batch could not be sent. Data will be lost
java.lang.RuntimeException: 400 Bad Request
        at org.influxdb.impl.InfluxDBErrorHandler.handleError(InfluxDBErrorHandler.java:19) ~[influxdb-java-2.2.jar:?]
        at retrofit.RestAdapter$RestHandler.invoke(RestAdapter.java:242) ~[retrofit-1.9.0.jar:?]
        at org.influxdb.impl.$Proxy142.writePoints(Unknown Source) ~[?:?]
        at org.influxdb.impl.InfluxDBImpl.write(InfluxDBImpl.java:151) ~[influxdb-java-2.2.jar:?]
        at org.influxdb.impl.BatchProcessor.write(BatchProcessor.java:171) [influxdb-java-2.2.jar:?]
        at org.influxdb.impl.BatchProcessor$1.run(BatchProcessor.java:144) [influxdb-java-2.2.jar:?]
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:1.8.0_252]
        at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) [?:1.8.0_252]
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) [?:1.8.0_252]
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) [?:1.8.0_252]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_252]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_252]
        at java.lang.Thread.run(Thread.java:748) [?:1.8.0_252]
2020-06-04 21:56:26.612 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule '31 - Berechne WP Verbrauch und Kosten - heute': not valid as a java.net.URI: https://some.internal.domain.de:8086/query?1300584887000000
�VO?K.^R$����|�Z��I鋚��x�^ZS�P|$0�]�^D�?M�~^T=��8t�pd�^O�a?�B^X�i�}^C^@^@u=openhab&p=xxxxxxxxxx&db=openhab_db&epoch=ms&q=select%20value%20from%20%22autogen%22.%22iENERGY_WP_ZAEHLER1%
2020-06-04 21:56:26.616 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule '41 - Berechne WP Verbrauch und Kosten - aktueller Monat': not valid as a java.net.URI: https://some.internal.domain.de:8086/query?ER%20BY%20time%20DESC%20limit%201select value from "autogen"."iENERGY_WP_ZAEHLER1%u=openhab&p=xxxxxxxxxx&db=openhab_db&epoch=ms&q=select%20value%20from%20%22autogen%22.%22iENERGY_WP_ZAEHLER1%
2020-06-04 21:56:26.622 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule '51 - Berechne WP Verbrauch und Kosten - aktuelles Jahr': not valid as a java.net.URI: https://some.internal.domain.de:8086/query? "autogen"."iENERGY_WP_ZAEHLER1%uselect value from "autogen"."iENERGY_WP_ZAEHLER1%u=openhab&p=xxxxxxxx&db=openhab_db&epoch=ms&q=select%20value%20from%20%22autogen%22.%22iENERGY_WP_ZAEHLER1%
2020-06-04 21:56:26.776 [ERROR] [org.influxdb.impl.BatchProcessor    ] - Batch could not be sent. Data will be lost
retrofit.RetrofitError: Unexpected status line: value=74.8 1591300586633000000
        at retrofit.RetrofitError.networkError(RetrofitError.java:27) ~[retrofit-1.9.0.jar:?]
        at retrofit.RestAdapter$RestHandler.invokeRequest(RestAdapter.java:395) ~[retrofit-1.9.0.jar:?]
        at retrofit.RestAdapter$RestHandler.invoke(RestAdapter.java:240) ~[retrofit-1.9.0.jar:?]
        at org.influxdb.impl.$Proxy142.writePoints(Unknown Source) ~[?:?]
        at org.influxdb.impl.InfluxDBImpl.write(InfluxDBImpl.java:151) ~[influxdb-java-2.2.jar:?]
        at org.influxdb.impl.BatchProcessor.write(BatchProcessor.java:171) [influxdb-java-2.2.jar:?]
        at org.influxdb.impl.BatchProcessor$1.run(BatchProcessor.java:144) [influxdb-java-2.2.jar:?]
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:1.8.0_252]
        at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) [?:1.8.0_252]
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) [?:1.8.0_252]
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) [?:1.8.0_252]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_252]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_252]
        at java.lang.Thread.run(Thread.java:748) [?:1.8.0_252]

So the json seems not to be the problem … I think the problem is not even rule related … I double checked the new rules.

rule "40 - Berechne HH Verbrauch und Kosten - aktueller Monat"
when
    Item iENERGY_HH_ZAEHLER changed
then
    //logInfo("rule-40", "iENERGY_HH_ZAEHLER.state={}.", iENERGY_HH_ZAEHLER.state)
    var DateTime     instant1 = now
    var DateTime     instant2 = now.withTimeAtStartOfDay.withDayOfMonth(1)
    var HistoricItem hitem1   = iENERGY_HH_ZAEHLER.historicState(instant1)
    var HistoricItem hitem2   = iENERGY_HH_ZAEHLER.historicState(instant2)
    if (hitem1 === null || hitem2 === null)
    {
        //logInfo("rule-40", "iENERGY_HH_ZAEHLER: Noch keine Werte für den aktuellen Monatsbeginn vorhanden (von {} bis {}).", instant2.toString("yyyy-MM-dd HH:mm:ss"), instant1.toString("yyyy-MM-dd HH:mm:ss"))
        iENERGY_HH_VERBRAUCH_AKTMON.postUpdate(-1.0)
        iENERGY_HH_KOSTEN_AKTMON.postUpdate(-1.0)
        return
    }
    var Number verbrauch = (hitem1.getState() as Number).floatValue - (hitem2.getState() as Number).floatValue
    var Number kosten    = (verbrauch * (iENERGY_HH_ARBEITSPREIS.state as DecimalType)) + 
                           ((iENERGY_HH_GRUNDPREIS.state as DecimalType) / 12.0)

    iENERGY_HH_VERBRAUCH_AKTMON.postUpdate(verbrauch)
    iENERGY_HH_KOSTEN_AKTMON.postUpdate(kosten)
end

To me it seems it’s either a performance or a concurrency issue or both, eventually triggered by high load on that poor raspi4.

E.g. like this … one rule is already reading from persistence sameItem.historicState(now), when the other rule’s persistence service did not yet finish writing to disk that sameItem.postUpdate(value) … all happening nearly at the same time.

I will try to read at now.minusMinutes(1) instead of instant1 = now and see if that alleviates the problem.

P

Well, while on the face of it is it a bit daft to try to fetch historicState() for “now” -because now is not history - I would expect it to work in the sense of returning some result. When seeking any historicState(), you should get the last recorded state from before the given instant.
So “now” should happen to give the most recent record.
You can check what you get by examining the timestamp of the returned object.

postUpdate() is asynchronous of course, no rule stops and waits for that.
So even myItem.state in the same rule would give the “old” answer.
Attempting to retrieve from persist in the same rule certainly would not take into account the most recent update.
Attempting to retrieve from persist in some other rule triggered from the update will be the same, because the persist cycle almost certainly hasn’t happened yet.

Hard to see why you want to do any of that - you know what you postUpdated to the Item, after all.

Whether any of that is at all relevant to your new rules, who can say. We can’t see them, or the relationship between them.

I can’t see any immediate problem with the one rule you posted.

Rules can be a bit odd about - signs when it doesn’t know to expect a number.
Fortunately postUpdate will always parse a string.
I would use a safer version
iENERGY_HH_VERBRAUCH_AKTMON.postUpdate("-1.0")
but your code probably isn’t even going there.

Who knows, though. Add some logging so you can see progress and intermediate values.

The error logs are produced by the rules. Thyat might be because they get rubbish data. Investigate and find out. It’s quicker to diagnose a problem than keep changing the game and hoping something works.