I’m using 80 Zenner Lorawan watermeters.
Codec for values i use:
function decodeUplink(input) {
return {
data: Decode(input.fPort, input.bytes, input.variables)
};
}
function Decode(fPort, bytes, variables) {
// Decode an uplink message from a buffer
// (array) of bytes to an object of fields.
var packet = bytes[0];
var packetType = (packet >> 4) & 0x0F;
var packetSubtype = packet & 0x0F;
var dayValue=bytes[4] << 24 | bytes[3] << 16 | bytes[2] << 8 | bytes[1];
if(packetType==1 && packetSubtype == 1){
return {
value:dayValue/1000
};
}
}
I use the same codec as ABP and OTAA Profile in Device Profiles.
under device profiles → measurements → i set automatically detect measurement key
For value → is set counter → Zählerstand
Now i have a strange problem. First day everything was fine but on the next day i got wrong values.
Another device
Do i have something forgotten? Do i have to clear something (value?)
Or do i use the codec wrong?
Because on the first day everything works fine, i dont think it is a mixing problem it is a value problem … but i dont know
thx for help.
Share a photo or copy paste the JSON format of one of the uplinks (with sensitive data removed) this can be retrieved when you click into an event on the “Events” tab of the device. Are the uplinks being properly decoded? I.e is there an “object” section of the JSON string?
Hi Events messages overview:
message: “2025-01-13 03:11:48”
message: “2025-01-13 02:12:09”
message: “2025-01-13 02:12:09”
message: “2025-01-13 02:12:09”
message: “2025-01-13 02:12:08”
day before the value was:
That means there is a object with increasing values.
Wrong - graph values:
2025-01-12 0,248
2025-01-13 0,57
Can it be that i use the codec functionality in a wrong way?
I saw that in milesight codec (which i do not have written by myself) there is a point function.
This is definitely strange. Could be a bug with Chirpstack’s graphing. Have you tried the “gauge” option for uplinks instead, does that work as expected?
I don’t think the issue is with your decoder here. There are some decoder fails in the logs, but those are triggered by the uplinks that don’t have any data, which is an issue with the device not the codec (although you could adjust the decoder so it doesn’t fail when these happen to clear up the logs). Clearly the decoder does work when the device uplinks correctly as we can see the value in the “object” section. And Chirpstack has detected the reading which is why you can graph it in the first place.
What type of sensors are these, is there a chance the value comes out negative and the counter is adding that up to near zero? Or perhaps the “counter” option doesn’t work properly with decimals, although that seems unlikely to me.
To confirm, when you hover over the days the graph is not showing 0 but some small decimal place values?
If i hover the graph values they all are positive and are showing values higher than 0.
At the first moment i thought that here are coming values from another meter. Remember i have 80. Some of them are still lower than 0,5 and have their initial value.
Strange also that each device shows the correct value on day one i tried to start. Second day and so on each is wrong.
I will change and look what happens…
oh man you saved my life…
gauge works fine –
that was hopefully the mistake i have overseen… many thx.
To understand. Counter shows the difference from one day to the next day - therefore the shown graph was correct.
I’m glad gauge works, but I still don’t understand why the counter doesn’t. Certainly wasn’t a mistake on your part. Presumably you should see the value skyrocket as it increases by ~93 with each uplink, happening once an hour would be about 2400 a day so on counter you should have seen values around that. Maybe the graph just doesn’t support values that high.
EDIT:
Ahhh that makes sense, the description isn’t exactly clear. Glad you figured that out.
that’s right i missunderstood the incremental part
