Domoticz Community Forum - Support & Discussion

Hi everyone,

I am currently exploring the possibility of using an agentic coding assistant (such as an AI coding agent) to help me manage and write scripts, event logic, and automations within my Domoticz installation.

To give such an agent a complete and accurate understanding of the system, providing it with context (or read access) to the database structure and configuration seems very helpful. However, as we know, the domoticz.db SQLite file currently stores several sensitive secrets in plain text (such as hardware API keys, passwords, SMTP credentials, etc.).

This raises a few security concerns for my AI workflow, and I wanted to ask the community and developers about this:

Current status: Are there any plans or mechanisms already in place to encrypt sensitive fields within domoticz.db?

Workarounds / Best practices: For those of you who use external tools, scripts, or AI assistants alongside Domoticz, how do you handle or mitigate the risk of exposing these secrets?

Roadmap: Is implementing database-level encryption or obfuscation for sensitive credentials something that could be considered for a future roadmap?

Looking forward to your thoughts and security insights!

Best regards,

You should not need this encrypted data for an AI agent to script something in eg dzvents so it seems you are fishing for something else here?

Btw, there is a mcp connector: https://wiki.domoticz.com/MCP_model_con ... otocol_LLM

Exactly, you can do everything you want with the MCP and you should not need to do this.

You also need to learn how to prompt, and that includes statements to not transmit sensitive information to Claude or the cloud as well.

So try the MCP

Hi,

Thanks for pointing out the MCP connector (domoticz-mcp), that's a very interesting development.

However, I have a few follow-up questions and concerns regarding security and specific cleanup use cases:

1/Prompt-based security vs. Architectural security:
Relying on system prompts to prevent an AI model from handling or transmitting sensitive data is probabilistic and non-deterministic (it remains vulnerable to prompt injection, context leakage, or accidental behavior changes). A robust security setup requires proper architectural defense-in-depth (least privilege, server-side redaction, or encryption) rather than trusting that the LLM will strictly follow instructions not to look at or leak secrets.
-> that's what I want to acheive.


2/ MCP Read-Only Mode & Version 2024 compatibility:
Since I am currently still on Domoticz version 2024 and haven't migrated yet, I cannot test the MCP server right now.

- Is it possible to configure the MCP server in a strict read-only mode (disabling all write/control tools entirely)?

- What does the resource domoticz://settings (Key system configuration values ) return? Does it expose any sensitive settings or credentials?

- Device-to-script mapping (The main technical hurdle):
My biggest issue right now is managing legacy scripts. Some scripts appear completely unused by the central Lua/dzVents engine, but are actually bound or mapped directly to specific devices (on and off script). I want to identify and clean up these direct device-script bindings to avoid hidden logic.

- Can the MCP server query or list which devices have direct scripts attached to them?

- Alternatively, if I query the domoticz.db SQLite database directly, where can I find this mapping information so I can clean it up safely?

Thanks again for your help and insights!

A few concrete answers.

Secrets in domoticz.db: there is no per-field encryption of credentials, and it is not on the roadmap. Domoticz is a local application whose threat model treats the host and the database file as trusted; protecting them is a matter of host and filesystem security (file permissions, disk encryption, private backups). If the host is exposed, the stored secrets are the smaller part of the problem.

You do not need any of those secrets for an assistant to write dzVents, Lua or Blockly logic. That is exactly what the MCP connector is for, and it is the right boundary:

- Read-only: bind the MCP OAuth2 client to a Viewer account. Viewer is read-only, so every control or write tool is refused server side and the client can only read values and status. The rights model already gives you least privilege, so no separate switch is needed.
- domoticz://settings returns a small curated subset: title, location, language, unit scales, sensor timeout, battery threshold, active timer plan and the Energy Dashboard device selection. It contains no passwords, API keys or SMTP credentials. The get_users tool likewise returns no password data.

Device-bound scripts: the on/off actions attached to a device are the "On Action" and "Off Action" fields in the device edit dialog (the script:// entries). They are separate from the dzVents/Lua event engine, which is why they look unused from the event side. Go through the device edit dialogs, or read the devices over the API, to find and clean up those script:// actions.

MCP also works against 2024, but to test the current connector and tools you will want to try 2026.x.