NodeRed fails to send image via Telegram (after NR upgrade)

I have a Node-red flow that sends me a picture from a local file when movement is detected on a sensor. (a camera creates the picture and first saves it to that local file) Then NodeRed sends it via Telegram. This has served me well for several years. Recently it stopped working after I updated NR

The NR log file shows the following error:
Unhandled rejection Error: ETELEGRAM: 400 Bad Request: invalid file HTTP URL specified: URL host is empty

Add On Version:

 You are running the latest version of this add-on.
 System: Raspbian GNU/Linux 11 (bullseye)  (armv7 / raspberrypi4)
 Home Assistant Core: 2024.1.2
 Home Assistant Supervisor: 2023.12.1

Node-Red/js versions:

Node-RED version: v3.1.3
Node.js  version: v18.19.0

I don’t know why it complains about a HTTP URL . I have always been sending a filepath, but after the upgrade from NR version 3.0.2, it seems to complain about an HTTP URL.

The message that I send to the node is:

msg : Object
payload: object
chatId: "[REDACTED]"
messageId: [REDACTED]
type: "photo"
content: "/config/www/cam_captures/camera.westcam1_20240120_114423.jpg"
camera_id: "camera.westcam1"

Anyone any thoughts ?
thank you so much,

From my limited understanding:

In recent updates to Node-RED addon package, the file structure has changed. Node-RED (addon) now has its own top level /addon_configs/a0d7b954_nodered/ folder where all the NR configuration lives.

From within NR, file nodes reading and writing to /config/ now actually refer to the new addon_config folder and not the main HA config folder.

From within NR, to read into the HA config folder /config/ you need to call it /homeassistant/ (it is still /config, just known as /homeassistant within addons).

The write access to folders has also changed, with the intention that addon programmes can no longer make changes to the main HA configuration files and directory.

You may well have to experiment with this as you appear to have two flows, one writing and one reading. Clearly they need to point to the same place, wherever that may now be.


Thank you Geoff @Biscuit
That was the root cause ! I was not aware of that breaking change

sorry the editor prevents me from posting… Unformatted Code Warning
now, on to the solution
what is this… I keeps giving me Unformatted Code Warning and prevents me from posting my text… just typing some random text here to test

trying to continue
I made a subdirectory called cam_captures under /addon_configs/a0d7b954_nodered. I then changed the path where the node saves the cam_captures, but then I run into another problem

msg : error
    "HomeAssistantError: Cannot write /addon_configs/a0d7b954_nodered/cam_captures/camera.westcam1_20240120_150213.jpg, no access to path; allowlist_external_dirs may need to be adjusted in configuration.yaml"

I added the following to my configuration.yaml:


- "/usr/share/hassio/addon_configs/a0d7b954_nodered/cam_captures/"

But that gives me:

Invalid config for 'homeassistant' at configuration.yaml, line 42: Not a directory 'allowlist_external_dirs->0', got '/usr/share/hassio/addon_configs/a0d7b954_nodered/cam_captures/'

I also tried different substrings of that directory




I DID check the documentation, but could not find a good explanation on what is expected for allowlist_external_dirs and what is the chroot of it

HomeAssistant… sigh… you have to be a genius… or rely on the goodwill of genius-es in this community… RESPECT !

Yes that ‘feature’ is not helpful.

There is a trick to saying ignore and don’t remind me again, then it goes away.

ok… the " Unformatted Code Warning seems to be triggered by any string with an underscore that is not formatted as code
I finally got posted what I wanted to post…
Now, let’s hope somebody can provide some insights on the allowlist_external_dirs


since the recent updates to Node-RED, use now :

content: "https://your_ha_url/local/cam_captures/camera.westcam1_20240120_114423.jpg"


1 Like

confusion is complete now… sorry

  1. NodeRed is still able to write my camcaptures to/usr/share/hassio/homeassistant/www/cam_captures/ …even after the upgrade… which should not be possible anymore… When I go to that directory, I do see the jpg files
    e.g.: /usr/share/hassio/homeassistant/www/cam_captures/camera.westcam1_20240120_164805.jpg
  2. I can also get to that picture from my browser by going to:
    As explained by @joeTT Thank you for that tip ! :slight_smile:

If I ask Node-Red to send an image, either from filePath, or from the URL, to Telegram, it fails with Unhandled rejection Error: ETELEGRAM: 400 Bad Request: wrong HTTP URL specified

My best way-out seems to be that I change the path where the cam_captures are written to the /addon_configs/a0d7b954_nodered/ folder as @Biscuit mentioned
Then I get stuck by not being able to add that new folder as allowlist_external_dirs

… ?

I don’t do anything as complex as writing images and then using them. However, if I understand correctly the new direction being taken, then we should not have general write access to the HA configuration folders from within an addon program (and probably not have access to the addon configuration either).

The folders with assured write access (both HA and Node-RED) are therefore now limited, and the two main ‘user’ ones are /media and /share. I have moved all my Node-RED ‘user’ data files (text files that I write and read) to /share, and I can both write and read from them without issue.

1 Like

Very good
That all makes sense.
I’m all for following standards and (new) directions… trying to remain compatible
Let me try writing to /media (and reading from it again)

thank you, one more time,Geoff @Biscuit

SOLVED ! :slight_smile:
That all made so much sense

In case anyone else is struggling with this:
in NodeRed write and read media files to /media/ e.g. /media/myfile.jpg
For me, those files get stored at: e.g. /usr/share/hassio/media/myfile.jpg

no need to add any exceptions (like allowlist_external_dirs) to configuration.yaml
this is all following the (new) H.A. standard

The world makes sense again
Smooth sailing,
Happy Days

big thank you @Biscuit for your patience
(BTW, long shot, but I know a Geoff Bas… in Ottawa, Canada… we used to work at the same company… it’s probably a different Geoff)

1 Like

I solve on my side by using “https://”…
but your solution is best that mine
I use now /media/ instead of https://
thanks a lot.