MQTT standalone

[siouxme]

Will it be possible to reuse an existing MQTT broker, rather then be depend on the internal MQTT service inside the adpater? It would be helpful to just specifiy the MQTT IP and port of the existing infrastructure....

[cimba007]

Yeah. I don't want to rely on a "client" to bring its own mqtt-server.

[gbomacfly]

Same here, I have a mosquitto server running. I wish this module could be a client instead of a server.

[steff517]

The same here

[ackerschott]

I´d also like to use my independent mosquitto server.

[LaLinea]

I can support this feature request too! I have to use a dedicated broker because sensor data has to go directly over the broker to an influx db too.

[merlin2533]

That is a great feature, how can we support that we have implementation.
e.g. Adapter MQTT Server, would be a nice adaption in this case?

[merlin2533]

there would be fine when only one server will be need for both cases

[mobilutz]

I did look into this topic a little bit just now, and it does not seem to be too easy to completely switch to an existing MQTT broker.

There is one big issue, which means that it is not enough to just change the MQTT broker:

1. mqtt messages from sonoff/tasmota do not include any client information

From what I know right now, there would be a manual change on ALL tasmota devices, to include the client inside the mqtt topic. I will not look into this further, because I don't think that this is a very good way to go, right now.

[merlin2533]

ok thats also fine, when you have the option to do a bridgeing to a other server
or the other option is, that you work with the adapter MQTT toether that he is able to get the information out of the mqtt server from sonoff.

In my infastructure, at the moment, i have to double the mqtt server, that i have one ony for the sonoff/tasmota and other for the rest

[LaLinea]

In all my setups I use a unique module host name in the MQTT topic on all tasmota devices. So there is the ‚client information‘ in the topic. It‘s also necessairy for my sensor database in influxdb.

[LaLinea]

could someone help solving this with bridging on the central mosquitto MQTT broker? So the mosquitto could bridge to the sonoff adapter on iobroker? Any help would be appreciated

[Michael-CGN]

I would also very much appreciate adding support for an external mqtt server into this module. I spent hours trying to solve the problem having a mosquitto server bridging to sonoff module. As the module relies on the name of the client connected to create the instances, it pastes everything under the client id of the mosquitto bridge instead the appropriate tasmota devices...

[kskenyon]

I'll pile on. External MQTT server as an option would be appreciated.

[debouttek]

I like this to.

[MNatzke]

I like this too.

To be honest. I think it is not the idea of the MQTT protocol to have many servers for different "vendors"/"types" of IoT devices. I have one server running and this one should handle all my use cases.

[Apollon77]

Ok, but its then the "mqtt" or "mqtt-client" adapter not suitable for you?

The thing here is that ease of use for unexperienced users ...

Also if it would connect to a different mqtt server we would need some kind of "what states to subscrube that are the sonoffs to handle by this adapter" because there will be much more data in it not handleable by this adapter.

So: How it could work from your idea? Can someone write such an idea down to discuss?

[MNatzke]

Hi Apollon,

I am not sure if we are on the same page or if I understand the architecture of the adapter (I kind of new to iobroker).
What I understand is: The Adapter sonoff is acting like a mqtt-broker. It is listening on the IP of the iobroker on Port 1883 (or something else if i change it) for MQTT-Messages. If i want that my tasmota/sonoff devices work with the adapter i have to use the iobroker (IP) with the port configured in the sonoff Adapter as an MQTT-Broker (in the tasmota-Setup).

As the Adapter is not a "real" MQTT-Broker it is not possible to listen or subscribe to it with tools like mqtt.fx (at least it does not work for me in my configuration) or other clients from different servers. In that case I can use my tasmota devices only with the iobroker adapter and with nothing else (like nodeRed on a different server).

I am not sure how the mqtt or mqtt-client adapters might help at this point. The Tasmota devices will still work only with the sonoff adapter. Or is your recommendation to use mqtt-Client instead of sonoff client?

The setup I prefere is to have a sonoff adapter with all the sonoff specific setup (topic etc.) is acting as a client and can subscribe to any mqtt Broker in the network. When i got your issue correct the problem is that you need to know if the messages are sent by a tasmota or sonoff device to know that the messages are relevant. If you use the command "Status 2" you will be able to see that a device is a tasmota device.
Another option would be to configure the "groupTopic" of the Tasmota devices (default: tasmotas or sonoffs) in the adapter. The adapter cab perform a status request for the configured group to collect all devices.

[mstuebner]

One more vote for using an existing mqtt server. Especially because I do not understand the difference whether this sonoff adapter get the tasmota data by acting as a broker or by acting as a client. The data is the same.

Would be great if mobilutz could add some more information what he ment with "mqtt messages from sonoff/tasmota do not include any client information", because all data comes from the /STATE channel?

[klein0r]

+1 for an option to connect to an external broker (instead of hosting an additional one with this adapter).

[TheHaf]

I second that, +1 for the option to use an external server like mosquitto.

[GermanBluefox]

I second that, +1 for the option to use an external server like mosquitto.

No one is stopping you to implement it.

[TheHaf]

I would if I could. 😄 I currently lack the time and knowledge.

[jwiesel]

great discussion! Also a +1 from my side.
I've been using mosquitto + iobroker.node-red so far with the drawback, that I need to connect every new tasmota device to sync state/sensor in a flow in Node-RED to store & update values in IOBroker objects.
A great feature I'd like to use is the "automatic object creation and sync" this adapter seems to provide (I couldn't test it, yet).

From the comments I guess what would be needed to be implemented:

• dropdown to choose between "inbuilt MQTT broker" or "external MQTT broker"
• Field to enter external MQTT broker's IP address
• (optionally) extra field to enter port of external MQTT broker - maybe existing port field could be reused
• Application logic to start and connect MQTT client instead of MQTT broker, if new option is selected

The first three points should not be a big deal, but I am not sure about the critical last one (application logic).

Regarding the message handling (MQTT topics) I guess there would not be a big change, as the device name of each tasmota would be different.

[Apollon77]

There was also an other discussion with the idea to better start a new "tasmota" adapter which works as generic as mqtt but is able to "handle JSONs ina generic way" ... In fact this would mean that roles and datatypes and such will not be that perfectly set , but the maintenance effort to update all these json structures (that are not standardized at all ) would be gone

[jwiesel]

If I got your comment right, the issue is, that tasmota messages e.g. tele/deviceName/STATE contain a json structure.
Transferring that standardized JSON structure to separate objects/states in ioBroker from my point of view is a beautiful feature as the data is automatically accessible for all tasmota devices.
If users decide to publish custom MQTT messages via rules in Tasmota that's a different story, but maybe not a core feature for standard users.

[Apollon77]

In fact I (personally) understood that adapter to try to transform the "a bit standardized messages from sonoff devices" into clean ioBroker structures ... but over time anything became Tasmota and got very divers ... so question is if it makes sens to continue here or to continue clean as new adapter with a more generic purpose ... with the downside that "roles" and such details gets lost ...

[smischke]

I have many tasmota smart plugs and also came to the requirement to connect them to a separate mqtt broker (mosquitto) since I'm trying to run iobroker and home assistant in parallel. I've configured mosquitto to connect a bridge to ioBroker.sonoff now listening on port 1884:

listener 1883 0.0.0.0
allow_anonymous false
password_file /etc/mosquitto/pwfile

connection sonoff
address 127.0.0.1:1884
topic # out
cleansession false
notifications false
remote_clientid bridge
remote_username tasmota
remote_password tasmota
start_type automatic
bridge_insecure false

Since ioBroker.sonoff currently recognizes devices by clientId (which is "bridge" for all devices) and not by topic, I've made a quick and dirty hack as a proof of concept:

Now it looks like this in iobroker:

I'm sure this hack won't work in every situation and maybe there is a better way. Ideally, switching to "bridge mode" should be absolutely transparent and use the existing states. And since I'm not so experienced in javascript and iobroker, I'd like this comment to be understood as a feature request "support bridge mode" and handled by the authors of this adapter or someone more experienced. Thanks!