How to switch %var% to case sensitive? (serial receive data loaded to %var)

[panciunio]

Hi,
I have a very simple connection to an ESP32 using Serial Bridge. I'm trying to use the transferred data in variables: %var1, %var2, etc. Tasmota receives everything correctly, but when I try to use the values stored in the variables, all characters are converted to uppercase. Is there a way to switch this so that the variables contain both lowercase and uppercase characters?

RULE:
rule1 ON SSerialReceived#ADeviceID DO var1 %value% ENDON ON SSerialReceived#ACommand DO var2 %value% ENDON ON SSerialReceived#Text DO var3 %value% ENDON ON SserialReceived#Execute DO %var2% %var3% ENDON rule1 1
Sent string:
{"AdeviceID":"SIO","Acommand":"DisplayText","Text":"Text caseSENSITIVE"}

Receive string:
RSL: RESULT = {"SSerialReceived":{"AdeviceID":"SIO","Acommand":"DisplayText","Text":"Test caseSENSITIVE"}

Console Log:

16:53:26.391 RSL: RESULT = {"SSerialReceived":{"AdeviceID":"SIO","Acommand":"DisplayText","Text":"Test caseSENSITIVE"}}

16:53:26.396 RUL: SSERIALRECEIVED#ADEVICEID performs 'var1 SIO'

16:53:26.398 RSL: RESULT = {"Var1":"SIO"}

16:53:26.405 RUL: SSERIALRECEIVED#ACOMMAND performs 'var2 DISPLAYTEXT'

16:53:26.406 RSL: RESULT = {"Var2":"DISPLAYTEXT"}

16:53:26.413 RUL: SSERIALRECEIVED#TEXT performs 'var3 TEST CASESENSITIVE'

16:53:26.415 RSL: RESULT = {"Var3":"TEST CASESENSITIVE"}

I need to have not converted to uppercase data because I want to send these to OLED display.. unfortunately I need sometime clear the display by using DisplayText [z] - big [Z] doesn't work.

BR,
panciunio

[sfromis]

The rule handling is designed to be case insensitive, by always folding data to upper case when evaluating rule triggers. Hence no way of retaining mixed case values when picking up values from the JSON, except:

For more flexible handling on ESP32, you have the Berry language with less such restrictions. This includes tasmota.add_rule where you can get the arguments in unmodified mixed case. And all the arguments at the same time, instead of multiple rules to pick up each.

More generally, instead of the serial bridge you also have full serial handling in Berry, even avoiding the restrictions of needing JSON in a format matching what you can do with triggers.

If you instead of serial bridge used serial console pins, you could also issue commands directly, instead of the indirection with rules to pick up parts, and then assemble a command.

[panciunio]

Thank you for your reply.

I've read about the serial port support in the Berry and even tested sending – it does seem more flexible, but it requires more knowledge and programming skills than simple rules.

I'll try to do the same in the Berry, but it'll be a challenge (I tried initializing an OLED display and failed). This is obviously a result of my lack of knowledge and experience... I need to read more :-)
A few words about why I chose the serial bridge – a client connected to Tasmota isn't able to interpret all the data sent by Tasmota. The data must be intentional, intended only for that client, because it can't analyze all messages. I don't know if it's possible for Tasmota to limit physical serial interface to generating only specific messages. Or perhaps you mean using a different physical serial interface than the basic one?

EDIT.
Just now I read that it's possible to use standard Tasmota's command like DisplayText when display was initialized by display.ini (outside Berry). It's good news for me - one less step to take :-)

BR,
panciunio

[sfromis]

Well, as posted you can still use the serial bridge with Berry tasmota.add_rule and get mixed-case data. And then you could easily use tasmota.cmd to issue commands like DisplayText from Berry. You'd still get all fields at the same time, instead of combining multiple rules to get one field at a time.

What I mentioned about the serial feature in Berry was just an additional option if you want max flexibility, without the limitations of using serial bridge.

[panciunio]

I'll try to do it like you said... some kind of wrapper may be use to catch all interested commands. My knowledge is regarding Berry is very weak, so all simple task are sometime too hard for me... Just simple example:

ser = serial(25, 23, 19200, serial.SERIAL_8N1)   #RX=25, TX=23
def read_sio()
    import string
    var msg = ser.read()
    tasmota.cmd(print(msg.asstring()))
    print(msg.asstring())
    #ser.write(5051525354)  
end

Run:
read_sio()

Result:

DisplayText Received_from_SIO
stack traceback:
	<native>: in native function
	<unknown source>: in function `cmd`
	<unknown source>: in function `read_sio`
	<unknown source>: in function `main`

So I assume, data was received because print(msg.asstring()) working fine but I can't understand why data were not transferred to tasmota.cmd as expected string ("DisplayText Received_from_SIO"). I tried with C style fprint parameter like %s e.g.: tasmota.cmd(string.format("%s", msg)) but effect is the same. Have no idea how to prepare proper data for tasmota.cmd("") function. Any hint? Please :-)

BR,
panciunio

[sfromis]

Well, to use tasmota.cmd, you should provide a string, not use print inside it, as the result from the print function call is nil.

While you don't need the step through the format function, it would have worked if you instead of the bytes object (which is what you have in msg) got the string value from it, using the msg.asstring() you were already using other places. This should do it:
tasmota.cmd(msg.asstring())

To use the approach with serial, you'd also need to poll the serial port at short intervals. If you code as a driver, you have callbacks like every_100ms which can work well for that. It can also work with tasmota.set_timer with a function doing the set_timer again for the next cycle.

Yes, it does take more to use the serial class, that's why I again mentioned that you can get the mixed-case data combining serial bridge and Berry, to have less programming details to mess with.

BTW. Using the number 5051525354 would not give you the characters PQRST. The serial write function call takes an integer as a single byte (like ser.write(80) or ser.write(0x50) for an uppercase P. Or it can use a bytes object, like this:
ser.write(bytes('5051525354'))
ser.write(bytes().fromstring('PQRST'))

[panciunio]

It works perfectly!

Thank you for your valuable feedback and help – I'd probably struggle with this for a few more days :-). Before starting this thread, I looked through a few examples to become somewhat familiar with the syntax, but apparently each case requires a different approach. It's a shame there's still so little information and examples about Berry online, but I'm glad there are people like you :-)

Yes, I basically plan to read events from the serial at certain intervals. I've also read that the minimum interval is 50ms, which complicates scripting a bit. But I'm not worried about that – the data buffer is sufficient, and I'll also use the return channel to indicate readiness for the next batch of data. That's the plan. And thanks to your help, it's slowly coming to fruition.

Working code:

ser = serial(25, 23, 19200, serial.SERIAL_8N1)   #RX=25, TX=23
def read_sio()
    import string
    var msg = ser.read()
    tasmota.cmd(msg.asstring())
    print(msg.asstring())
   # ser.write(bytes().fromstring('PQRST'))  
end

Best Regards,
panciunio

[sfromis]

When it comes to Berry code examples, I've collected a long list of publicly available Github projects including Berry code, almost all of them are with Tasmota.
http://sfromis.strangled.net/tasmota/berry/github-repositories

And there's also pretty decent docs about the Berry language and Tasmota integration.

When it comes to your point about differences, a lot comes down to knowing what object types you are working with (like strings, bytes or map), and what functions are available around each type.

[panciunio]

I've never seen this huge scripts set! Amazing! google never return me results with your page! (I'm disappointed of the quality of google regarding Berry)
Will have many work to do! :-) Thanks!