sendHttpGetRequest and base64

hi everyone

(I know, probably a stupid question, and already given answers, but I cant find…)

I would like to getrive an png-image with an sendHttpGetRequest, convert it to base64 and send it to telegram

actions.sendTelegram("Es gibt Probleme mit dem System.")
            var String chart = sendHttpGetRequest("http://openhab:8080/rrdchart.png?items=LocalComputer_Swap_Used,LocalComputer_Storage_Used,LocalComputer_Memory_Used&period=D&h=350&w=800")

    var String b64img = "data:image/png;base64," + java.util.Base64.encoder.encode(chart.getBytes())
actions.sendTelegramPhoto(base64Image, "Sysparams-Chart")

in the error-log I see taht the getBytes() does not work.

how should this be done correctly?

thanks in advance

This will not work with the new Telegram 2.5 Binding:

var String b64img = “data:image/png;base64,” + java.util.Base64.encoder.encode(chart.getBytes())
actions.sendTelegramPhoto(base64Image, “Sysparams-Chart”)

The new binding cannot handle the header of base64 Images

You could send a Picture via Telegram directly via the link:

“sent from openHAB”)

1 Like

well: yes and no :wink:

I am able to send the base64 imag as shown in the example (of the binding) correctly.

It won’t help sending the URL, because its not reachable from “outside” (already tested)

the encoder works, but: I get [12,34,22,…] as the output and not the expected ABGF-like base64-string

What exactly is the error?

Probably you need to use the correct encode method.

encodeToString(byte[] src)

Encodes the specified byte array into a String using the Base64 encoding scheme.

encode returns a byte[] which is why you see “[12,34,22,…]” as the output.

Probably you need to use the correct encode method.

I am 100% with you :wink:

2019-12-19 09:31:27.877 [INFO ] [e.model.script.TelegramBot- - b64img] - data:image/png;base64,77-9UE5HDQoaCgAAAA1JSERSAAAB77-9AAAA77-9CAIAAADMhmLvv70AABvvv71JREFUeO-_ve-_vX1MW--_ve-_vUnvv70t77-977-977-977-9Nhvvv73Jsu-_ve-_vSnvv73vv73vv71277-9NnVr77-9TFvvv70xbe-_vXPvv73vv70pXe-_ve-_vWvvv71V0ZQq77-9H0l777-9de-_vS7vv71WKi1tVkHvv700WgYJ77-9Jncj77-977-9NjdQZ--_ve-_vQAhECAv77-9EO-_vQzvv71u77-9P9yffRrvv73vv70YMATvv71j77-977-977-9I3R877-9Y--_ve-_vX_vv73vv73vv73vv73vv71J77-9H0IIIe-_vcubb--_ve-_vQQFQgjRoO-_vT8W77-9EEI077-9OBHvv73vv701a3gsCSEIWu-_vXZWGg8nISQWMzw877-977-977-977-977-977-9IX9lGUETQu-_vSbvv73vv73vv70n77-977-977-977-977-977-977-9eO-_vWJdXe-_ve-_ve-_vRNB77-97YyjCSHvv70Y77-977-9OTQ077-9KO-_ve-_vWgETQgh0Y_vv73vv70YGxvvv73vv70zZ--_vShr77-977-977-977-9Qe-_vUF277-90YTvv73vv71Lb2_vv73vv[....shortened for here....]
2019-12-19 09:31:27.899 [WARN ] [] - Malformed base64 string: Illegal base64 character -1

so, if I compare my base64 string with those used in several examples, I see there are “special characters” like “+_” or in other words the examples use a Base62-like character-table.

As @Vradatta already said: the API expects simply the plain Base64 text without any additional headers. So I thing, you should just omit

"data:image/png;base64," + 

when you build your string.

sorry, already tried with no success (invalid base64 string)

“+” is a valid Base64 character. “" is not though but I often see "” use with base64 encoded stuff as a divider between a custom header/footer. But that’s not occurring here either.

This is all pure Java stuff so at this point I’d search around to see how to do this using Java. What ever you find will apply to your Rule too.

rick: let’s not discuss, what valid base64 chars are, thats not the point.
(maybe Telegram expects base62…)

I am using a QAD work-arround with wget and a tmp. local file …very ugly…