I’m looking for a way to permanently store information in deCONZ addon (addon_core_deconz).
Originally the file is stored at /usr/share/deCONZ/devices.
I have SSH access as hassio user (using docker exec -it addon_core_deconz /bin/bash).
Which part of the container is not wiped when updating OR RESTARTING the addon?
All parts except mount points are recreated with a new version of the container, this is by design. So basically you want to create mount points for this container.
I don’t know how that works for integrated containers.
OK so I’ll ask the deCONZ experts if mount points are suitable for storing DDF files.
Anyway:
how to create a mount point from inside addon_core_deconz (/usr/share/deCONZ/devices/custom_ddf) to e. g. the SAMBA folder “share”?
@mhoogenbosch what would it be like if it’s not an integrated container? Your sentence implicates you basically know how to 
My apologies, volumes they are called. My compose file looks like this:
deconz:
image: deconzcommunity/deconz:latest
mem_limit: 1g
hostname: deconz
cap_add:
- NET_ADMIN
container_name: deconz
logging:
driver: json-file
options:
max-file: ${DOCKERLOGGING_MAXFILE}
max-size: ${DOCKERLOGGING_MAXSIZE}
restart: unless-stopped
volumes:
- /etc/localtime:/etc/localtime:ro
- ${DOCKERCONFDIR}/phoscon/data:/opt/deCONZ
- ${DOCKERCONFDIR}/phoscon/firmware:/root/otau
environment:
- DECONZ_DEVICE=/dev/ttyACM0
- DECONZ_VNC_MODE=1
- DECONZ_VNC_PASSWORD=password
- DECONZ_UPNP=0
- TZ=${TZ}
- PGID=${PGID}
- PUID=${PUID}
logging:
driver: "json-file"
options:
max-size: "50m"
devices:
- /dev/ttyACM0
networks:
composemacvlan:
ipv4_address: 192.168.10.11
As you can see with volumes everything is getting redirected, so my local dockerconfdir/phoscon/data and firmware get mapped into the container this making storage persistent.
I don’t want to hack the whole deconz addon / container that much.
I only want one additional mount point, so a minimal change. Thinking of using ✔️🏃Run On Startup.d for this.
This is not hacking or anything like that, I’m running pretty much default. If your approach is easier just do it by all means. I just don’t know how that works. Hopefully it’ll work for you.
/data is a volume in the container of every addon. It’s where addons store private data they need to persist across restarts. So put it in there.
Indeed I meanwhile found the folder I was looking for in /data/.local/share/dresden-elektronik/deCONZ/devices before I read your post.
Thanks for confirming 
, will test it by restarting the addon asap and see if the changes made persist.
Does someone know…
a) if there’s a text editor inside a docker container (on the CLI)? Couldn’t find neither nano nor vi…
b) how to transfer data between the host and a docker container? Doesn’t matter which way. Ideally the docker container could access a samba share like /share.
Addons specify whether they need access to share, config, ssl, etc in their config under map. Deconz doesn’t need anything from users other then the config options so it doesn’t list any of those.
Also /share isn’t a samba share by default? It’s just a folder. Its name is because it’s shared among addons and HA, at least ones that request it.
Looking at its build.yaml the container is debian. So apt-get stuff if you need it.
Massive thanks for all that very helpful information! Few things to pick up:
For me it always was: HA OS, SAMBA share addon, default. See also https://github.com/home-assistant/addons/blob/8d194b2446402ea1602172dcd7f00bf0698d567f/samba/DOCS.md#connection.
Nice. After apt update a apt install nano worked. I expect all those changes to be reverted after addon restart/update, right?
Yea if you install that addon then it makes them samba shares. All the folders listed there, not just /share. I guess my point was /share has nothing to do with samba by default, it’s really about sharing among addons. But the samba addon can make all your folders also available over samba.
For addons - yes. You added it to the container but the container is rebuilt from the image every restart for addons so it’ll be gone.
The core and supervisor containers survive a bit longer, they are generally only rebuilt on update. Unless there is some issue making the system think they are unhealthy, then they are also rebuilt from the image.
Assumptions confirmed after doing a HA deCONZ addon restart:
/usr/share/deCONZ/devices/blitzwolf/bw_shp13_smart_plug.json) is overwritten/reset to default 
/data/.local/share/dresden-elektronik/deCONZ/devices/bw_shp13_smart_plug_MyCustomConfig.json) still exists and is untouched (timestamp unchanged)
Additional confirmation:
Therefore I’m fine for the moment, will test/check if all this behaves the same when updating the deCONZ addon.
docker exec -it addon_core_deconz bash
apt update; apt install nano (note: this will be undone once the container is restarted or updated)nano /usr/share/deCONZ/devices/blitzwolf/bw_shp13_smart_plug.json
Notes:
I would like to mark @CentralCommands posts as solution as those were VERY helpful on the initial and many additional questions that came up. As there’s not just one post but solution information spread over few topics, I’ll mark this one as solution and give once again big thanks to @CentralCommand for all the CLI and docker environment knowledge shared in this topic.