I found no json_encode and json_decode like in php, so in this way i need to use JsonPath Transformation Service?
There i have also not found how i can encode a string, only decoding of it.
Maybe you have an simple example or in OH it is not so simple?
Well, you have the tools to encode into one Item state.
Or you might use three String type Items. They don’t cost you anything. Just make sure to set up in some established order and trigger the “do it” rule(s) from the last one to be changed.
I have made a rule, put them in one item and then parsed them.
It seemed to be a great solution. But, if 2 or more log events comes at one time or close to each other “item” cant not deal with them and get randomly only one of them.
So it is not realy good way ((( but i do not see other. Maybe you see?
Part of the solution is to encode your logging message into a single package, so parts of one cannot get mixed up with parts of another.
An approach to getting openHAB to queue rapid-fire messages for you is not to use the Item state, but to use commands instead. So long as you trigger any processing rule from received command and use the data in that command, openHABs event bus will manage it and every event will get dealt with.
You’d probably need to lock your rule so that it processed one message at a time, otherwise you will run into the same problem with whatever services it passes messages on to.
So what do i need to do to make it work good and how to lock it?
PS
If i understood right, i changed this lines to
val botType = receivedCommand.toString.split('<>').get(0)
val prefix = receivedCommand.toString.split('<>').get(1)
val message = receivedCommand.toString.split('<>').get(2)
That’s it, do not use state when triggering from command.
Only do this if you really need to.
If your rule is really that simple, and using new variables (‘val’) at each iteration (so that nothing is shared) I do not think much harm will come if you get two triggered instances of the rule running at the same time.
If, say, telegram can’t handle messages that fast (would not surprise me), locks are not the answer for that anyway.
Locking if you really need it.
The risk with using a lock is that if you get an error (say, an unexpected NULL state) the lock can get locked forever. Well, until next reboot/reload.