Domoticz

Posted: **Saturday 06 January 2024 19:02**

Hello all,

After 4 years running Domoticz with more than 100 devices (including virtual, tasmotas, shellies, ... almost all based on MQTT protocol and JSON API) and a relevant quantity of dzVents scripts, I'm thinking about what should be the way for the future of my installation from the reliability, management and performance point of view.

Thanks to MQTT Auto Discovery (released since 2022.2 on Nov'22) and tools like shellyteacher4domo, I learned enough about how discovery protocol works, so I would like to move as many devices as possible from (old) MQTT Client Gateway and other DIY virtual devices to different instances of MQTT-AD Hardware.

Then my questions are (maybe for the core developers):

Makes it sense considering the above mentioned reasons?

Will serveral instances of MQTT-AD hardware impact on performance?

Any feedback is appreciated.

Thanks a lot for this great piece of software

---------------------------------------
Running Domoticz Stable ...

Spoiler: show: Version: 2024.1
Build Hash: 5279c8261
Compile Date: 2024-01-01 12:59:22
dzVents Version: 3.1.8
Python Version: 3.7.3 (default, Oct 11 2023, 09:51:27) [GCC 8.3.0]

on a Debian Buster server

and Domoticz Beta ...

Spoiler: show: Version: 2024.1 (build 15805)
Build Hash: 30067cce8
Compile Date: 2024-01-05 11:51:42
dzVents Version: 3.1.8
Python Version: 3.9.2 (default, Mar 12 2021, 04:06:34) [GCC 10.2.1 20210110]

on a Rasberry PI 3B+ with Raspbian Bullseye

Posted: **Saturday 06 January 2024 21:08**

I can only answer 1 of your questions ; I noticed no impact on performance with 2 instances of MQTT AD, zigbee2mqtt and zwave-js-ui.

Posted: **Sunday 07 January 2024 11:14**

There is now also an option to specify which devices you want to send over to MQTT (setup button for the MQTT hardware)
This will decrease the CPU as well as not all devices are pushed

And there is a new pusher introducted (MQTT Pusher) that I would prefer even more against the old MQTT hardware

MQTT-AD is more designed for ZWaveJS-UI and Zigbee2MQTT and for ESP devices using this protocol
(And indeed also for the new shellyteacher protocol)

When I create external python scripts/ESP modules I favor MQTT-AD as well

Posted: **Sunday 07 January 2024 18:02**

Thanks a lot for your feedback

When I create external python scripts/ESP modules I favor MQTT-AD as well

This is the way

Posted: **Friday 16 February 2024 19:58**

Hi,

Following this topic, I'm still trying to get rid of the MQTT hardware for my external python scripts and move to great MQTT-AD.

One of the last devices to be migrated is one Alert virtual sensor/device monitoring a remote pellets stove. After several weeks playing with domoticz source code, I found a way to manage it using autodiscovery protocol.

So, in case anyone finds it useful (or inspiring for the core developers

), I'd like to share what I've changed.

Config topic and payload example:

homeassistant/sensor/123456789ABC_alert/config

Code: Select all

{
  "name":"StoveStatus",
  "stat_t":"tele/stove/STATE",
  "frc_upd":"false",
  "enabled_by_default":true,
  "uniq_id":"123456789ABC-status",
  "qos":0,
  "dev":{
    "ids": [
      "123456789ABC"
    ]
  },
  "stat_cla":"measurement",
  "unit_of_meas":"!",
  "val_tpl":"{{ value_json['alert'] }}"
}

State topic and payload examples:

tele/stove/STATE

Code: Select all

{ "alert": "4;Disconnected" }
{ "alert": "0;Off" }
{ "alert": "2;Starting" }
{ "alert": "1;On" }'
{ "alert": "3;Ending" }

Feel free to ask any further question.

: alert.png (10.34 KiB) Viewed 2206 times

PS: Once again, thanks to @lwolf (and his shellyteacher4domo) who showed me the way
PS2: Code changes were made in "trial & error" mode, so do not expect best practices coding

.

Posted: **Saturday 17 February 2024 11:40**

You are aware there is a mqtt mapper plugin that does approximately the same: mqttmapper.

There is also the shellyteacher application that scans the mqtt broker for Shelly (and in development Tasmota) devices and create Auto discovery topics for them.

Posted: **Saturday 17 February 2024 20:35**

Hi waltervl,

To be honest, I don't know how to achieve same result with your suggestions:

- MqttMapper: With following template, you can create Alert device but I didn't found how to provide both values (sValue=text + nValue=level) needed to update the sensor in "mapping" section

Code: Select all

{
    "MqttMapperStove": {
        "topic": "tele/stove/STATE",
        "type": "243", "subtype": "22", "switchtype": "0",
        "mapping": {"item": "alert"}
    }
}

and additionally, you need to install the python plugin instead of use Domoticz builtin hardware

- Shellyteacher4domo: As per my previous post, I provided both autodiscovery topic and payload as done by Shellyteacher4domo in the same way, but at the end, MQTTAutodiscover hardware needs to know how to manage an Alert Sensor payload.

Anyway, every feeback is welcome. It makes me re-think if other approach must be consider.

Thanks

Posted: **Saturday 17 February 2024 23:30**

Better ask mqtt mapper questions in the mqtt mapper topic, the author is very helpful. https://www.domoticz.com/forum/viewtopi ... 65&t=39279

Domoticz

MQTT Client Gateway vs MQTT Auto Discovery

MQTT Client Gateway vs MQTT Auto Discovery

Re: MQTT Client Gateway vs MQTT Auto Discovery

Re: MQTT Client Gateway vs MQTT Auto Discovery

Re: MQTT Client Gateway vs MQTT Auto Discovery

Re: MQTT Client Gateway vs MQTT Auto Discovery

Re: MQTT Client Gateway vs MQTT Auto Discovery

Re: MQTT Client Gateway vs MQTT Auto Discovery

Re: MQTT Client Gateway vs MQTT Auto Discovery