Domoticz

Running Raspi Buster, Domoticz 2023.2
I have 15 Shelly 2PM roller shutter devices installed using Shelly Teacher and MQTTad.
All working perfectly via Python URL commands to open close etc.
Each Shelly device has a bunch of "variables" like input 0/1 Relay 0/1 Online, Input, Energy, Volts, Power on the Domoticz pages.
I have no interest in all of this and just want the switch status with % open displayed.
Every time I delete all these unwanted variables they automatically come back after a while!
How can I stop this?

Also is there a better way to install Shelly devices which stops this?

Lastly I just received some Shelly Flood devices. As these are battery powered devices which don't communicate all the time, is the installation with Domoticz any different?
Thanks.

Mosquito remembers (retained) the discovery mqtt topic so you have to delete it from mosquito too. See wiki page https://www.domoticz.com/wiki/MQTT#Dele ... ined_topic

paul402 wrote: ↑Saturday 30 December 2023 21:27 Each Shelly device has a bunch of "variables" like input 0/1 Relay 0/1 Online, Input, Energy, Volts, Power on the Domoticz pages.
I have no interest in all of this and just want the switch status with % open displayed.

You can remove unwanted devices from mqtt_templates.txt (Gen1) or mqtt_templates_gen2.txt (Gen2) BEFORE starting the teaching process. These are simple text files, can be opened and edited by any simple text editor, which do not change format or coding.

However the simplest solution is to mark as "Unused" the devices in Domoticz you do not need and they wont be displayed. This is what is do in my system. It works the same way in zigbee2mqtt if you use MQTT-AD method.

Or after the teaching process...

paul402 wrote: ↑Saturday 30 December 2023 21:27 Every time I delete all these unwanted variables they automatically come back after a while!
How can I stop this?

This is by design, as descriptors are stored on the MQTT broker as retained.
You can delete unwanted device descriptors with MQTT Explorer, they are located under homeassistant/ as default. You can find the devices by the deviceID and type. After you delete the descriptor from the MQTT broker, the device can be also deleted from Domoticz and it wont reapper.
(MQTT Explorer deletes entries by sending empty payload to the selected topic)

This is what waltervl suggested.

paul402 wrote: ↑Saturday 30 December 2023 21:27 Lastly I just received some Shelly Flood devices. As these are battery powered devices which don't communicate all the time, is the installation with Domoticz any different?

Any battery operated device can be configured to use MQTT, but you has to find a way to make it awake until you configure and when you Teach the device, the Flood in this example. (they usually have a button on them to wake)
After its teached, there is no more special actions needed.

Well thanks for very, very helpful feedback but...this sounds like horrible s/w design.
If Domoticz works like this in the future it will never be mainstream as non techie people just will not accept fumbling around like this.

paul402 wrote: ↑Tuesday 02 January 2024 22:16 Well thanks for very, very helpful feedback but...this sounds like horrible s/w design.
If Domoticz works like this in the future it will never be mainstream as non techie people just will not accept fumbling around like this.

This has nothing to do with Domoticz, this is how MQTT retained messages work.

Next to this, It does not matter if it is in the devices table, 'you' decide to add them to your system by pressing the 'add' button, or you press the 'remove' button

paul402 wrote: ↑Tuesday 02 January 2024 22:16 Well thanks for very, very helpful feedback but...this sounds like horrible s/w design.

Don't know if "horrible" is the right word, but that's for sure now "scattered": In front of domoticz event system that manage devices data/states, there's a duplicate inside the MQTT broker that may feed other subscribers than domoticz (thus no "delete" from subscriber(s)).

Maybe a MQTT broker built inside Domoticz could allow this, being able to manage subscribers from the same place (& keep device list coherency) not relying on an external component?

OK I'll settle for scattered. To have one program to add devices, another to remove them and a third one uses them. Come on!
I'm retired but I used to do marketing for an embedded systems company and if this approach had been suggested by anyone he/she would be laughed out of the building.
Don't get me wrong, I like Domoticz.

paul402 wrote: ↑Friday 05 January 2024 12:16 OK I'll settle for scattered. To have one program to add devices, another to remove them and a third one uses them.

ShellyTeacher is an option. Which I provided for free. You are welcome.
(But of course as it is open source it is possible to integrate it into Domoticz if anyone has a lots of free time and C knowledge.)

As i said earlier, there are no reason to actually delete an automatically added sensor, they can be set as "Unused" in Domoticz device list. This is the preferred solution and does not require other program.
The MQTT Explorer way is for "techie peoples".

By the way i think "non techie people" will not use Domoticz as its installation requires minimum Level 0 IT knowledge... instead they will use the Cloud provided by the manufacturer, which does not require IT knowledge.

lwolf wrote: ↑Friday 05 January 2024 20:16 As i said earlier, there are no reason to actually delete an automatically added sensor, they can be set as "Unused" in Domoticz device list. This is the preferred solution and does not require other program.

I don't agree that setting it to unused is the right way to handle a removed device. It should also be removed from Domoticz. Other integrations including the python plugin ones can do it.

But Domoticz MQTT AD gateway cannot send a remove device command to MQTT. So for a MQTT AD device you officially have to also remove it from the MQTT broker. Setting it to unused in Domoticz is a poor man's workaround.

Zigbee2MQTT and Zwave-JS-UI will have the same issue when they use retained MQTT discovery topics so ShellyTeacher is not allone. Perhaps you can request for a remove MQTT AD function but I think it is the responsibility of the gateway (Zigbee2MQTT, Zwave-JS-UI, ShellyTeacher etc) to clear the memory of the mqtt broker when a device is removed.

Maybe the author of ShellyTeacher could remove all configs at startup before scanning/creating new once?