but this gives me the same. I searched in the internet for a way to cut the ending spaces with regex. Found some hints but all are not working inside item definition. What do I wrong
2018-04-22 10:15:46.221 [vent.ItemStateChangedEvent] - ekeyHomeTest changed from NULL to 1_0002_6_80187242150798_1_2
2018-04-22 10:15:46.221 [vent.ItemStateChangedEvent] - ekeyHomeTest changed from 1_0002_6_80187242150798_1_2 to 1_0002_6_80187242150798_1_2
In your transform folder create a file called ekey.js
With he content:
(function(i) {
if (i == 'NULL') {return i; }
if (i == '-') {return 'Undefined'; }
return i.trim(); // Removes all spaces and beginning and end
})(input)
I checked it with wireshark. The udp packet is send only once from the remote device. But something inside of OH udp binding updates the item a lot of times.
the item is updated only from null to the string with the spaces. If I use the regex. The item is updated to the string with the spaces and then, maybe after the regex is running, to the string without the spaces. I see this double update only in the udp binding.
In the http binding the transform in the item config does not update the item twice. I get only one update not two.
I tried to fix it with reentrancelock. But the item update sometimes lasts 2 sec. I should have a 2 sec wait until unlock. Very long for a sleep. I fixed it with trigger on changed instead of update and change string to something else after command is processed. Not good but it is working.
rule "ekey message"
when
Item ekeyHomeTest changed
then
if(ekeyHomeTest.state.toString == "keineAenderung")
return;
logInfo("Tester", "ekeyHomeTest: " + ekeyHomeTest.state.toString)
ekeyHomeTest.postUpdate("keineAenderung")
end
I assume that your finger print reader send data after scanning a print and not after an OH request. In that case you don’t need updatewithresponse=true. You can comment it out or set it to false. Does that change anything?
I tried this too, with no success. I us a udp test tool to simulate udp packets. This is the same behaviour. I think something inside of the binding is wrong with the handling of received packets.
