Git Product home page Git Product logo

iobroker.mqtt's Introduction

Logo

ioBroker MQTT

Number of Installations Number of Installations NPM version

Test and Release Translation status Downloads

This adapter uses Sentry libraries to automatically report exceptions and code errors to the developers. For more details and for information how to disable the error reporting see Sentry-Plugin Documentation! Sentry reporting is used starting with js-controller 3.0.

MQ Telemetry Transport for ioBroker (MQTT).

MQTT (formerly Message Queue Telemetry Transport) is a publish-subscribe based "light weight" messaging protocol for use on top of the TCP/IP protocol. It is designed for connections with remote locations where a "small code footprint" is required and/or network bandwidth is limited. The Publish-Subscribe messaging pattern requires a message broker. The broker is responsible for distributing messages to interested clients based on the topic of a message. Historically, the 'MQ' in 'MQTT' came from IBM's MQ message queuing product line.

This adapter uses the MQTT.js library from https://github.com/adamvr/MQTT.js/

Configuration

  • Type - Select "Client" (If you want to receive and send messages to another broker) or "Server" if you want to create own MQTT broker.

Server settings

  • WebSockets - if parallel to TCP Server, the WebSocket MQTT Server should run.
  • Port - Port where the server will run (Default 1883). WebSockets will always run on port+1 (Default 1884)
  • SSL - If TCP and WebSockets should run as secure server.
  • Authentication/Username - If authentication required, you can specify the username. It is suggested to always use SSL with authentication to not send passwords over unsecure connection.
  • Authentication/Password - Password for user.
  • Mask to publish own states - Pattern to filter ioBroker states, which will be sent to clients. You can use wildcards to specify group of messages, e.g ".memRss, mqtt.0.` to get all memory states of all adapters and all states of adapter mqtt.0
  • Publish only on change - New messages will be sent to a client only if the state value changes. Every message sent by the client will be accepted, even if the value does not change.
  • Publish own states on connect - by every client connection the all known states will be sent to a client (defined by the state mask), to tell him which states the ioBroker has.
  • Prefix for all topics - if set, every sent topic will be prepended with this prefix, e.g. if prefix iobroker/ all states will have names like **iobroker**/mqtt/0/connected
  • Trace output for every message - Debug outputs.
  • Send states (ack=true) too - Normally only the states/commands with ack=false will be sent to partner. If this flag is set every state independent of ack will be sent to partner.
  • Use different topic names for set and get - if active, so every state will have two topics: adapter/instance/stateName and adapter/instance/stateName/set. In this case, a topic with /set will be used to send non acknowledged commands (ack: false) and topic without /set to receive state updates (with ack: true). The client will receive sent messages back in this mode.
  • Interval before send topics by connection - Pause between connection and when all topics will be sent to a client (if activated).
  • Send interval - Interval between packets by sending all topics (if activated). Used only by once after the connection establishment.
  • Force clean session - Overwrite the client settings and clear or keep session.
  • Publish messages without "retain" flag - Send messages to other clients without a retain flag (read more in next paragraph)
  • Ignored Topics - You can provide certain topics that will be ignored by the broker. This is useful if you want to reduce some chatty clients. You can use wildcards to specify multiple topics, e.g. test.*.

The ioBroker MQTT-Broker in server mode only simulates the behavior of real MQTT-Broker (like Mosquitto), but it is not the same. Real MQTT-Broker normally does not save the values of the topics and just forwards the message to other subscribed clients.

To force real MQTT-Broker to behave like ioBroker MQTT-Broker, all messages must be sent with "retain" flag. In this case, the values will be stored too.

ioBroker MQTT-Broker always saves the values into the States-DB, so it can be processed by other adapters. Because of that, the messages are always published with a retain flag.

If your client has problems with retained messages, you can force ioBroker MQTT-Broker to send messages without a retain flag with Publish messages without "retain" flag option. In this case, the messages will be stored in States-DB anyway.

If the option Send states (ack=true) too is not activated, so you can clear the value of the topic (state) with ack=true and the update will not be sent to subscribed clients. And when the client connects next time, it will not get the last command again.

The JS-Code should look like this:

await setStateAsync('mqtt.0.valetudo.vale.BasicControlCapability.operation.set', 'cleanStart'); // ack=false
await setStateAsync('mqtt.0.valetudo.vale.BasicControlCapability.operation.set', '', true); // ack=true to clear the command

Client settings

  • URL - name or ip address of the broker/server. Like localhost.
  • Port - Port of the MQTT broker. By default, 1883
  • Secure - If secure (SSL) connection must be used.
  • User - if broker required authentication, define here the username.
  • Password - if the username is not empty, the password must be set. It can be empty.
  • Password confirmation - repeat here the password.
  • Subscribe Patterns - Subscribe by the pattern. See chapter "Examples of using wildcards" to define the pattern. '#' to subscribe for all topics. 'mqtt/0/#,javascript/#' to subscribe for states of mqtt.0 and javascript
  • Publish only on change - Store incoming messages only if payload differs from actual stored.
  • Mask to publish own states - Mask for states, that must be published to broker. '' - to publish all states. 'io.yr.,io.hm-rpc.0.*' to publish states of yr and hm-rpc adapter.
  • Publish all states at start - Publish all states (defined by the state mask) every time by connection establishment to announce own available states and their values.
  • Prefix for topics - The prefix can be defined for own states. Like /var/ioBroker/. Name of topics will be for example published with the name /var/ioBroker/ping/192-168-1-5.
  • Test connection - Press the button to check the connection to broker. Adapter must be enabled before.
  • Send states (ack=true) too - Normally only the states/commands with ack=false will be sent to partner. If this flag is set every state independent of ack will be sent to partner.
  • Use different topic names for set and get - if active, so every state will have two topics: adapter/instance/stateName and adapter/instance/stateName/set. In this case, a topic with /set will be used to send non acknowledged commands (ack: false) and topic without /set to receive state updates (with ack: true).
  • Send state object as mqtt message - The client sends the states as parsed string JSON objects to the broker (example parsed string JSON object: {"val":true,"ack":true,"ts":1584690242021,"q":0,"from":"system.adapter.deconz.0","user":"system.user.admin","lc":1584624242021,"expire":true}); if not the values states.val is sent as a single value (example state.val as single value: true)
  • Persistent Session - When checked, the broker saves the session information of the adapter. This means it tracks which messages have been sent/received by the adapter (only QoS Level 1 and 2) and to which topics the adapter has subscribed. This information survives a disconnect and reconnect of the adapter.

Usage

How to test mqtt client:

  • Set type to Client.
  • Leave port on 1883.
  • Set URL as broker.mqttdashboard.com
  • To get absolutely all topics(messages) set pattern to #.
  • To receive all topics for /4MS set pattern to /4MS/#
  • To receive all topics for /MS and /floorish set pattern to /4MS/#, /floorish/#

Sending messages

You may send / publish messages on topics using sendTo method from your adapter via MQTT adapter, e.g.:

/*
 * @param {string}  MQTT instance     Specify MQTT instance to send message through (may be either server or client)
 * @param {string}  action            Action to use (always 'sendMessage2Client' for sending plain messages)
 * @param {object}  payload         
 * @param {string}  payload.topic     Topic to publish message on
 * @param {string}  payload.message   Message to be published on specified topic
 *
 */
adapter.sendTo('mqtt.0', 'sendMessage2Client', { topic: 'your/topic/here', message: 'your message', retain: true });

Examples of using wildcards

The following examples on the use of wildcards, builds on the example provided in topic strings.

  • Sport
  • Sport/Tennis
  • Sport/Basketball
  • Sport/Swimming
  • Sport/Tennis/Finals
  • Sport/Basketball/Finals
  • Sport/Swimming/Finals

If you want to subscribe to all Tennis topics, you can use the number sign '#', or the plus sign '+'.

  • Sport/Tennis/# (this will receive Sport/Tennis and Sport/Tennis/Finals)
  • Sport/Tennis/+ (this will receive Sport/Tennis/Finals but not Sport/Tennis)

For JMS topics, if you want to subscribe to all Finals topics, you can use the number sign '#', or the plus sign '+'.

  • Sport/#/Finals
  • Sport/+/Finals

For MQTT topics, if you want to subscribe to all Finals topics, you can use the plus sign '+'.

Sport/+/Finals

Binary messages

With version 4.x, there is a possibility to send and receive binary messages. Send works only with [email protected] or newer.

You can change manually the common.type of existing objects to file and they will be processed as binary states.

Or you can set the options All new topics will be processed as binary* in the instance settings to force all new topics will have automatically common.type="file".

Tests

The broker was tested with the following clients:

Todo

  • Implement resend of QoS 2 messages after a while. Whenever a packet gets lost on the way, the sender is responsible for resending the last message after a reasonable amount of time. This is true when the sender is a MQTT client and also when a MQTT broker sends a message.

  • queue packets with QoS 1/2 for the offline clients with the persistent session. Read here

Changelog

5.2.0 (2024-01-08)

  • (ticaki) fixed: confirm onMessage()
  • (orpheus55) Added the authentication validation to request processing
  • (theimo1221) Added an option to filter certain topics

5.1.0 (2023-10-11)

  • (bluefox) Added security check if the server is available from the internet without protection

5.0.0 (2023-09-18)

  • (klein0r) Added blockly block for custom messages (sendMessage2Client)
  • (klein0r) Added retain flag for sendMessage2Client
  • (klein0r) Removed support for Admin 4 UI (materialize)
  • (bluefox) Minimal supported node.js version is 16

4.1.1 (2023-03-22)

  • (Apollon77) Fixed the regex on subscribing of server clients to only match wanted states
  • (Apollon77) Prepare for future js-controller versions

4.0.7 (2022-06-28)

  • (Apollon77/kleinOr) Removed unneeded dependency

4.0.6 (2022-06-19)

  • (bluefox) Corrected sentry issue

4.0.4 (2022-05-30)

  • (Apollon77) lower log-level for log messages about messages with unknown message IDs to info

4.0.3 (2022-05-17)

  • (bluefox) Corrected publish states on start by client

4.0.2 (2022-05-17)

  • (bluefox) Added possibility to publish own states as a client, additionally to mqtt.x

4.0.1 (2022-05-13)

  • (Apollon77) Fixed Number detection for values

4.0.0 (2022-05-12)

  • (bluefox) BREAKING CHANGE: in client mode only "mqtt.X.*" states will be subscribed
  • (bluefox) BREAKING CHANGE: in server mode by empty "publish" setting no states will be subscribed. Early all states were subscribed
  • (bluefox) Added a new option: All new topics will be processed as binary

3.0.6 (2022-04-25)

  • (Apollon77) Allows using some special characters like # in client passwords
  • (Apollon77) Corrected handing of QoS 2 messages
  • (Apollon77) Implement resend support of pubrec
  • (Apollon77) When resending a package set the dup flag as required by specs
  • (Apollon77) Added more debug for special debug mode

3.0.5 (2022-04-07)

  • (bluefox) BREAKING CHANGE: password is now stored encrypted, and so must be set anew after update!

2.7.4 (2022-03-18)

  • (Apollon77) Updated MQTT library dependency

2.7.3 (2022-03-11)

  • (Apollon77) Further optimization of automatic folder creation

2.7.2 (2022-03-11)

  • (Apollon77) Optimized the automatic folder creation and allow to automatically overwrite these objects when needed

2.7.0 (2022-03-09)

  • (Apollon77) Prevented Client or server to overwrite the own info.connection state
  • (Apollon77) replaced # and + characters by _ when publishing a value because these characters are forbidden when publishing for most brokers

2.6.2 (2022-03-03)

  • (Apollon77) If data types of objects change during an adapter run, adjust datatype of mqtt.X.* objects to "mixed" to prevent issues

2.6.1 (2022-02-25)

  • (Apollon77) Fixed object structure sync for server usage

2.6.0 (2022-02-25)

  • (Apollon77) Updated objects if data type changes also for "client" usage
  • (Apollon77) Updated mqtt library
  • (Apollon77) Created a folder object structure if objects do not exist in the adapter namespace

2.5.0 (2022-02-24)

  • (uwesimon/Apollon77) fixed test connection with MQTTs
  • (uwesimon/Apollon77) ReconnectTimeout is now handled in seconds, so default is 10s instead of 10ms
  • (Apollon77) Corrected info.connection object default values

2.4.1 (2021-11-08)

  • (MichaelDvP) Added wildcard regex for "/#"

2.4.0 (2021-05-09)

  • (Apollon77) only remember the last message per topic for offline clients that subscribed the topics when using persistent sessions
  • (Apollon77) only remember last wills for clients that subscribed the topics
  • (Apollon77) on "disconnect" message do not send last will as defined by specs
  • (Apollon77) set a new messageId when sending remembered messages
  • (Apollon77) Added small delay after subscribe before sending out topic values
  • (Apollon77) optimized for js-controller 3.3
  • (foxriver76) prevented errors in js-controller 3.3 and detect datatype changes for objects

2.3.5 (2021-02-27)

  • (Apollon77) js-controller 2.0 is now required at least
  • (arteck) changed default subscribe to mqtt.0.*

2.3.4 (2021-01-25)

  • (Apollon77) Caught errors when setting states (Sentry IOBROKER-MQTT-1F)

2.3.3 (2021-01-21)

  • (Apollon77) Caught errors when setting states (Sentry IOBROKER-MQTT-1D)

2.3.2 (2021-01-13)

  • (Apollon77) Checked configured server port and reset to 1883 if invalid (Sentry IOBROKER-MQTT-1B)
  • (Apollon77) Caught error when server cannot be started (Sentry IOBROKER-MQTT-1C)

2.3.1 (2020-12-30)

  • (FunCyRanger) Added option to ignore SSL validation errors

2.1.14 (2020-11-30)

  • (Apollon77) Prevented a crash case (Sentry IOBROKER-MQTT-11)

2.1.13 (2020-11-16)

  • (Apollon77) Prevented a crash case (Sentry IOBROKER-MQTT-Q)

2.1.12 (2020-11-08)

  • (Apollon77) Crash cases prevented (Sentry IOBROKER-MQTT-M)

2.1.10 (2020-10-30)

  • (Apollon77) Crash cases prevented (Sentry IOBROKER-MQTT-G)
  • (Apollon77) prevent errors on MQTT connection test

2.1.9 (2020-09-17)

  • (Apollon77) Crash cases prevented (Sentry IOBROKER-MQTT-E, IOBROKER-MQTT-F)

2.1.8 (2020-08-24)

  • (Apollon77) Crash case prevented on unsubscribing (Sentry IOBROKER-MQTT-D)

2.1.7 (2020-08-02)

  • (Apollon77) handled invalid mqtt server settings better (Sentry IOBROKER-MQTT-9)

2.1.6 (2020-08-02)

  • (Apollon77) Try to prevent creation of objects with invalid IDs
  • (Apollon77) checked that state is set before accessing it (Sentry IOBROKER-MQTT-2)
  • (Apollon77) Better handle disconnection cases (Sentry IOBROKER-MQTT-3, IOBROKER-MQTT-6)

2.1.5 (2020-07-26)

  • (Apollon77) try to prevent crashes on not existing state values
  • (Apollon77) Sentry added for crash reporting with js-controller 3.x+

2.1.4 (2020-06-20)

  • (Apollon77) websocket does not have setTimeout method
  • (NorbGH) prevented messageID overflow

2.1.3 (2020- 05-17)

  • (bluefox) Caught some errors

2.1.2 (2020-03-02)

  • (foxriver76) removed usage of getMessage
  • (mbecker) send states as an object in client mode

2.1.1 (2019-07-27)

  • (bluefox) Added an option to overwrite the client "clean session" settings

2.1.0 (2019-05-02)

  • (Zefau) Added an option to send the message using messagebox
  • (Zefau) Fixed error with logging on pubrec

2.0.6 (2019-01-16)

  • (SchumyHao) Added Chinese support

2.0.5 (2019-01-12)

  • (simatec) Support for Compact mode

2.0.4 (2018-12-01)

  • (Apollon77) Subscribe to topics after connect

2.0.3 (2018-08-11)

  • (bluefox) Prefix in the server was corrected

2.0.2 (2018-08-09)

  • (bluefox) Behavior of "set" topics was changed

2.0.1 (2018-07-06)

  • (bluefox) Double prefix by the client was fixed

2.0.0 (2018-03-05)

  • (bluefox) broke node.js 4 support
  • (bluefox) removed mqtt-stream-server
  • (bluefox) partial mqtt5 support

1.5.0 (2018-03-05)

  • (bluefox) The patch for wifi-iot removed
  • (bluefox) the mqtt library updated
  • (bluefox) implement QoS>0

1.4.2 (2018-01-30)

  • (bluefox) Admin3 settings was corrected

1.4.1 (2018-01-13)

  • (bluefox) Converted error is caught
  • (bluefox) Ready for admin3

1.3.3 (2017-10-15)

  • (bluefox) Fixed sending of QOS=2 if server

1.3.2 (2017-02-08)

  • (bluefox) Fixed convert of UTF8 payloads
  • (bluefox) optional fix for a chunking problem

1.3.1 (2017-02-02)

  • (bluefox) Updated mqtt packages
  • (bluefox) added Interval before send topics by connection and send interval settings
  • (bluefox) reorganise configuration dialog

1.3.0 (2017-01-07)

  • (bluefox) Updated mqtt packages
  • (bluefox) configurable client ID

1.2.5 (2016-11-24)

  • (bluefox) Fixed server publishing

1.2.4 (2016-11-13)

  • (bluefox) additional debug output

1.2.1 (2016-11-06)

  • (bluefox) fixed the publish on start

1.2.0 (2016-09-27)

  • (bluefox) implementation of LWT for server
  • (bluefox) updated mqtt package version

1.1.2 (2016-09-13)

  • (bluefox) fixed authentication in server

1.1.1 (2016-09-12)

  • (bluefox) do not parse JSON states, that do not have the attribute val to support other systems

1.1.0 (2016-07-23)

  • (bluefox) added new setting: Use different topic names for a set and get

1.0.4 (2016-07-19)

  • (bluefox) converted values like +58,890 into numbers too

1.0.3 (2016-05-14)

  • (cdjm) changed client protocolID

1.0.2 (2016-04-26)

  • (bluefox) updated mqtt module

1.0.1 (2016-04-25)

  • (bluefox) Fixed translations in admin

1.0.0 (2016-04-22)

  • (bluefox) Fixed error with direct publish in server

0.5.0 (2016-03-15)

  • (bluefox) fixed web sockets
  • (bluefox) fixed SSL

0.4.2 (2016-02-10)

  • (bluefox) created the object info.connection
  • (bluefox) added reconnection tests

0.4.1 (2016-02-04)

  • (bluefox) fixed error with states creation

0.4.0 (2016-01-27)

  • (bluefox) added tests
  • (bluefox) client and server run

0.3.1 (2016-01-14)

  • (bluefox) changed creation of states by client

0.3.0 (2016-01-13)

  • (bluefox) try to fix event emitter

0.2.15 (2015-11-23)

  • (Pmant) fixed publish on subscribing

0.2.14 (2015-11-21)

  • (bluefox) fixed error with wrong variable names

0.2.13 (2015-11-20)

  • (Pmant) fixed error with wrong variable name

0.2.12 (2015-11-14)

  • (Pmant) send last known value on subscription (server)

0.2.11 (2015-10-17)

  • (bluefox) set maximal length of topic name
  • (bluefox) converted true and false to boolean values

0.2.10 (2015-09-16)

  • (bluefox) protected against empty topics

0.2.8 (2015-05-17)

  • (bluefox) do not ty to parse JSON objects

0.2.7 (2015-05-16)

  • (bluefox) fixed test button

0.2.6 (2015-05-16)

  • (bluefox) fixed names if from mqtt adapter

0.2.5 (2015-05-15)

  • (bluefox) subscribe to all states if no mask defined

0.2.4 (2015-05-14)

  • (bluefox) added state clients to server with the list of clients

0.2.3 (2015-05-14)

  • (bluefox) fixed some errors

0.2.2 (2015-05-13)

  • (bluefox) fixed some errors with sendOnStart and fix flag sendAckToo

0.2.0 (2015-05-13)

  • (bluefox) translations and rename config sendNoAck=>sendAckToo
  • (bluefox) lets create server not only on localhost

0.1.8 (2015-05-13)

  • (bluefox) fixed topic names in server mode
  • (bluefox) implemented subscribe
  • (bluefox) update mqtt package

0.1.7 (2015-03-24)

  • (bluefox) created objects if new state received
  • (bluefox) updated mqtt library

0.1.6 (2015-03-04)

  • (bluefox) just update index.html

0.1.5 (2015-01-02)

  • (bluefox) fix error if state deleted

0.1.4 (2015-01-02)

  • (bluefox) support for npm install

0.1.2 (2014-11-28)

  • (bluefox) support for npm install

0.1.1 (2014-11-22)

  • (bluefox) support for new naming concept

0.1.0 (2014-10-23)

  • (bluefox) Updated readme
  • (bluefox) Support of authentication for server and client
  • (bluefox) Support of prefix for own topics

0.0.2 (2014-10-19)

  • (bluefox) support of server (actual no authentication)

License

The MIT License (MIT)

Copyright (c) 2014-2024, bluefox [email protected]

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

iobroker.mqtt's People

Contributors

algar42 avatar apollon77 avatar arteck avatar berndmr avatar bondrogeen avatar dependabot[bot] avatar drbakterius avatar foxriver76 avatar funcyranger avatar garfonso avatar germanbluefox avatar hurdurderp avatar klein0r avatar ldittmar81 avatar lgtm-migrator avatar manuelw77 avatar mbecker avatar mcm1957 avatar michaeldvp avatar modmax avatar orpheus55 avatar paul53 avatar pmant avatar schumyhao avatar sineos avatar theimo1221 avatar unclesamswiss avatar vesler avatar weindler avatar zefau avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

iobroker.mqtt's Issues

MQTT Topic-Scheme switching sometimes

Hello,

I am using the latest github version 1.5.0 and encountered a strange behavior regarding topic names.

First of all I am using https://github.com/256dpi/arduino-mqtt

The most important part I want to discuss is this:

client.subscribe("esp8266color/0_hsv");

which sometimes results in this:

mqtt.0 | 2018-04-04 21:49:53.153 | info | publishOnSubscribe
-- | -- | -- | --
mqtt.0 | 2018-04-04 21:49:53.152 | info | Client [ESP8266Client] subscribes on "mqtt.0.esp8266color.0_hsv"
mqtt.0 | 2018-04-04 21:49:53.141 | info | Client [ESP8266Client] connected

and sometimes in this


mqtt.0 | 2018-04-04 21:47:31.182 | info | Client [ESP8266Client] subscribes on topic "esp8266color/0_hsv"
-- | -- | -- | --
mqtt.0 | 2018-04-04 21:47:30.738 | info | Client [ESP8266Client] connected

image

On the other hand if I change some stats in the iobroker admin console it (at least one time) got published to mqtt.0.esp8266color.0_hsv and not esp8266color/0_hsv

I have not fully digged into the trace-stuff but it just feels wrong. This issue might have some connection with a problem I experience with that the esp8266-client doesn't seem to recognize published messages after ~>12-24 hours of runtime of the broker but I will investigate this further tomorrow with the use of
https://github.com/JoaoLopesF/RemoteDebug

MQTT Adapter sendet keine Daten

Der Mqtt Adapter sendet keine Daten. Empfangen klappt problemlos.
Getestet mit verschiedenen Endgeräten Sonoff mit Tasmota und Espurna Firmware, MagicHome und Arilux LED Controller auch mit Tasmota und Espurna Firmware.

Um die installation des iobrokers zu prüfen. Zweiten Raspberry genommen und IObroker neu installiert. Zum Test nur den MQTT Adapter installiert. Fehler der gleiche. Nur Empfang möglich.

Laut IObroker LOG wird zwar gesendet aber wenn mann auf das Zielgerät schaut kommt nichts an.

MQTT läuft. Trotzdem Fehler.

Ich habe Probleme mit dem Adapter.
Er läuft, so weit ganz gut. Es sendet und empfängt.
Unter Instanzen habe ich nach einen Neustart immer ein gelbes Licht.
Wenn ich darauf gehe, steht unter "Verbunden mit mqtt" "falsch".

Ich habe es schon gelöscht und neu Installiert.

Gehe ich auf "Teste Verbindung zum Server" ist der Adapter komplett raus.
Starte ich diesen neu, sendet er alles. Ist Grün und geht nach ein paar Sekunden wieder auf gelb.

ioBroker: 1.3.0
MQTT: 1.5.0
Pi 3

[Feature Request]: Bind to IP Address

Hi, it would be nice to bind an mqtt instance to an ip address like a web instances. The configuration should be the same as known for other adapters.

MQTT binary data, how to get this

I am new to IOBrocker and have a question how to access the binary data of the MQTT message within a javascript. My understanding is that obj.state.val is a string but my incoming message is a binary block of 4 bytes.

Any ideas?
Thank you.

Received text via mqtt not accepted

I tried to receive owntracks values via mqtt (cloudmqtt).

The sent text looks like:

{"_type":"location","tid":"pn","acc":19,"batt":0,"lat":xx.6933686,"lon":x.422188,"t":"u","tst":1515319324}

On data point only "undefined" will be showed.

If I send an text like:

{"_type":"location","tid":"pn","acc":19,"batt":0,"lat":xx.6933686,"lon":x.422188,"t":"u","tst":1515319324

without curly bracket "}" at the end, then it works.

Adapter läuft nicht stabiel

Hallo
Mein Adapter verbindet sich in einer Sekunde mehrmals neu.

mqtt.0 2018-09-22 18:54:53.055 info Connected to 192.168.2.106
mqtt.0 2018-09-22 18:54:53.031 info Disconnected from 192.168.2.106
mqtt.0 2018-09-22 18:54:53.009 info Connected to 192.168.2.106
mqtt.0 2018-09-22 18:54:52.985 info Disconnected from 192.168.2.106
mqtt.0 2018-09-22 18:54:52.963 info Connected to 192.168.2.106
mqtt.0 2018-09-22 18:54:52.941 info Disconnected from 192.168.2.106
mqtt.0 2018-09-22 18:54:52.919 info Connected to 192.168.2.106
mqtt.0 2018-09-22 18:54:52.897 info Disconnected from 192.168.2.106
mqtt.0 2018-09-22 18:54:52.875 info Connected to 192.168.2.106
mqtt.0 2018-09-22 18:54:52.853 info Disconnected from 192.168.2.106
mqtt.0 2018-09-22 18:54:52.832 info Connected to 192.168.2.106
mqtt.0 2018-09-22 18:54:52.810 info Disconnected from 192.168.2.106
mqtt.0 2018-09-22 18:54:52.788 info Connected to 192.168.2.106
mqtt.0 2018-09-22 18:54:52.766 info Disconnected from 192.168.2.106

und das ständig

Habe schon ein neues System aufgesetzt und auch ältere Versionen probiert.

Was kann ich tun?

Danke schon mal für hilfe

2.1.0 Error

Ich bekomme folgenden Fehler. Adapter wird aber wie es aussieht weiterhin ausgeführt.

host.ioBroker 2019-06-06 18:01:20.714 error instance system.adapter.mqtt.0 terminated with code 0 (OK)
Caught 2019-06-06 18:01:20.714 error by controller[0]: at Connection.emit (events.js:211:7)
Caught 2019-06-06 18:01:20.714 error by controller[0]: at emitOne (events.js:116:13)
Caught 2019-06-06 18:01:20.714 error by controller[0]: at Object.onceWrapper (events.js:315:30)
Caught 2019-06-06 18:01:20.714 error by controller[0]: at Connection. (/opt/iobroker/node_modules/iobroker.mqtt/node_modules/mqtt-connection/connection.js:53:12)
Caught 2019-06-06 18:01:20.714 error by controller[0]: at Connection.emit (events.js:211:7)
Caught 2019-06-06 18:01:20.714 error by controller[0]: at emitOne (events.js:116:13)
Caught 2019-06-06 18:01:20.714 error by controller[0]: at Connection.emitPacket (/opt/iobroker/node_modules/iobroker.mqtt/node_modules/mqtt-connection/connection.js:10:8)
Caught 2019-06-06 18:01:20.714 error by controller[0]: at Connection.emit (events.js:211:7)
Caught 2019-06-06 18:01:20.714 error by controller[0]: at emitOne (events.js:116:13)
Caught 2019-06-06 18:01:20.714 error by controller[0]: at Connection.client.on.packet (/opt/iobroker/node_modules/iobroker.mqtt/lib/server.js:803:34)
Caught 2019-06-06 18:01:20.714 error by controller[0]: TypeError: Cannot read property 'find' of undefined
mqtt.0 2019-06-06 18:01:20.686 info terminating
mqtt.0 2019-06-06 18:01:20.184 error at Connection.emit (events.js:211:7)
mqtt.0 2019-06-06 18:01:20.184 error at emitOne (events.js:116:13)
mqtt.0 2019-06-06 18:01:20.184 error at Object.onceWrapper (events.js:315:30)
mqtt.0 2019-06-06 18:01:20.184 error at Connection. (/opt/iobroker/node_modules/iobroker.mqtt/node_modules/mqtt-connection/connection.js:53:12)
mqtt.0 2019-06-06 18:01:20.184 error at Connection.emit (events.js:211:7)
mqtt.0 2019-06-06 18:01:20.184 error at emitOne (events.js:116:13)
mqtt.0 2019-06-06 18:01:20.184 error at Connection.emitPacket (/opt/iobroker/node_modules/iobroker.mqtt/node_modules/mqtt-connection/connection.js:10:8)
mqtt.0 2019-06-06 18:01:20.184 error at Connection.emit (events.js:211:7)
mqtt.0 2019-06-06 18:01:20.184 error at emitOne (events.js:116:13)
mqtt.0 2019-06-06 18:01:20.184 error at Connection.client.on.packet (/opt/iobroker/node_modules/iobroker.mqtt/lib/server.js:803:34)
mqtt.0 2019-06-06 18:01:20.184 error TypeError: Cannot read property 'find' of undefined
mqtt.0 2019-06-06 18:01:20.184 error uncaught exception: Cannot read property 'find' of undefined

Server setting "Trace output for every message" has no function

The server setting "Trace output for every message" seems to have no function. I use a door sensor as MQTT client and see only the common "info" output in the Log window:

2018-02-23 11:42:05.529  - info: mqtt.0 starting. Version 1.4.2 in /opt/iobroker/node_modules/iobroker.mqtt, node: v6.13.0
2018-02-23 11:42:05.823  - info: mqtt.0 Starting MQTT  server on port 1883
2018-02-23 11:42:27.991  - info: mqtt.0 Client [doorsensor1] connected

The client publish messages arrives the broker as I can see in the "Objects" window, but I would expect some debug output as well.

Background is, that I want to investigate missing PUBACK messages for publish messages (QoS>0).
For more details please see ioBroker forum thread or heise forum thread (both in German).

Environment:

  • ioBroker 1.2.3
  • MQTT 1.4.2 (same with 1.4.1)
  • Admin 3.2.0 (same with 2.0.9)
  • Firefox 52.6.0

Greetings,
endym

MQTT Server/broker startet nicht

Hallo,

ich möchte für die Kommunikation mit einer NodeMCU einen MQTT Server auf meiner ioBroker Raspberry betreiben. Jetzt habe ich den Adapter MQTT Server/broker installiert und die Instanz als Server/broker und Standardeinstellungen versucht zu starten.

Jedoch spuckt der Log immer die gleichen fehler aus:

host.ioBroker-Pi 2018-08-23 22:44:48.129 info Restart adapter system.adapter.mqtt.0 because enabled
host.ioBroker-Pi 2018-08-23 22:44:48.128 error instance system.adapter.mqtt.0 terminated with code 0 (OK)
Caught 2018-08-23 22:44:48.128 error by controller[0]: at Connection.emit (events.js:211:7)
Caught 2018-08-23 22:44:48.128 error by controller[0]: at emitOne (events.js:116:13)
Caught 2018-08-23 22:44:48.128 error by controller[0]: at Object.onceWrapper (events.js:315:30)
Caught 2018-08-23 22:44:48.128 error by controller[0]: at Connection. (/opt/iobroker/node_modules/mqtt-connection/connection.js:53:12)
Caught 2018-08-23 22:44:48.128 error by controller[0]: at Connection.emit (events.js:211:7)
Caught 2018-08-23 22:44:48.128 error by controller[0]: at emitOne (events.js:116:13)
Caught 2018-08-23 22:44:48.127 error by controller[0]: at Connection.emitPacket (/opt/iobroker/node_modules/mqtt-connection/connection.js:10:8)
Caught 2018-08-23 22:44:48.127 error by controller[0]: at Connection.emit (events.js:211:7)
Caught 2018-08-23 22:44:48.127 error by controller[0]: at emitOne (events.js:116:13)
Caught 2018-08-23 22:44:48.127 error by controller[0]: at Connection.client.on.packet (/opt/iobroker/node_modules/iobroker.mqtt/lib/server.js:839:34)
Caught 2018-08-23 22:44:48.126 error by controller[0]: TypeError: Cannot read property 'forEach' of undefined
mqtt.0 2018-08-23 22:44:48.087 info terminating
mqtt.0 2018-08-23 22:44:47.576 error at Connection.emit (events.js:211:7)
mqtt.0 2018-08-23 22:44:47.576 error at emitOne (events.js:116:13)
mqtt.0 2018-08-23 22:44:47.576 error at Object.onceWrapper (events.js:315:30)
mqtt.0 2018-08-23 22:44:47.576 error at Connection. (/opt/iobroker/node_modules/mqtt-connection/connection.js:53:12)
mqtt.0 2018-08-23 22:44:47.576 error at Connection.emit (events.js:211:7)
mqtt.0 2018-08-23 22:44:47.576 error at emitOne (events.js:116:13)
mqtt.0 2018-08-23 22:44:47.576 error at Connection.emitPacket (/opt/iobroker/node_modules/mqtt-connection/connection.js:10:8)
mqtt.0 2018-08-23 22:44:47.576 error at Connection.emit (events.js:211:7)
mqtt.0 2018-08-23 22:44:47.576 error at emitOne (events.js:116:13)
mqtt.0 2018-08-23 22:44:47.576 error at Connection.client.on.packet (/opt/iobroker/node_modules/iobroker.mqtt/lib/server.js:839:34)
mqtt.0 2018-08-23 22:44:47.576 error TypeError: Cannot read property 'forEach' of undefined
mqtt.0 2018-08-23 22:44:47.574 error uncaught exception: Cannot read property 'forEach' of undefined

Habe es jetzt schon mehrfach mit neustart, neuinstallation (auch direkt von GitHub) und allen möglichen verschiedenen Einstellungen in der Instanz probiert leider ohne Erfolg.

Ich hoffe ihr könnt mir weiter Helfen und ich sage schon mal Danke für alle Antworten,

Gruß,
DeSpo0108

MQTT client Passwort Issue

I have found a Bug that I can not solve myself. If I use the MQTT client with a "#" in my password, the connection will not work. This does not happen with the MQTT server" Only with the MQTT client!

Error Log:

2019-10-10 13:51:21.446 | error | instance system.adapter.mqtt.2 terminated with code 0 (OK)
-- | -- | -- | --
Caught | 2019-10-10 13:51:21.446 | error | by controller[0]: at addChunk (_stream_readable.js:288:12) code: 5 }
Caught | 2019-10-10 13:51:21.446 | error | by controller[0]: at Socket.emit (events.js:198:13)
Caught | 2019-10-10 13:51:21.446 | error | by controller[0]: at Socket.ondata (_stream_readable.js:709:20)
Caught | 2019-10-10 13:51:21.446 | error | by controller[0]: at Writable.write (/opt/iobroker/node_modules/iobroker.mqtt/node_modules/readable-stream/lib/_stream_writable.js:334:11)
Caught | 2019-10-10 13:51:21.446 | error | by controller[0]: at writeOrBuffer (/opt/iobroker/node_modules/iobroker.mqtt/node_modules/readable-stream/lib/_stream_writable.js:417:5)
Caught | 2019-10-10 13:51:21.446 | error | by controller[0]: at doWrite (/opt/iobroker/node_modules/iobroker.mqtt/node_modules/readable-stream/lib/_stream_writable.js:428:64)
Caught | 2019-10-10 13:51:21.446 | error | by controller[0]: at Writable.writable._write (/opt/iobroker/node_modules/iobroker.mqtt/node_modules/mqtt/lib/client.js:302:5)
Caught | 2019-10-10 13:51:21.446 | error | by controller[0]: at work (/opt/iobroker/node_modules/iobroker.mqtt/node_modules/mqtt/lib/client.js:292:12)
Caught | 2019-10-10 13:51:21.446 | error | by controller[0]: at MqttClient._handlePacket (/opt/iobroker/node_modules/iobroker.mqtt/node_modules/mqtt/lib/client.js:350:12)
Caught | 2019-10-10 13:51:21.446 | error | by controller[0]: at MqttClient._handleConnack (/opt/iobroker/node_modules/iobroker.mqtt/node_modules/mqtt/lib/client.js:920:15)
Caught | 2019-10-10 13:51:21.446 | error | by controller[0]: { Error: Connection refused: Not authorized

MQTT Adapter "Invalid messageId" (possible reason inside)

Hey,
In the german iobroker forum, several people have complained about a bug in the mqtt adapter:
https://forum.iobroker.net/viewtopic.php?f=20&t=16349

The bug basicly renders the adapter useless and only a new start of the adapter fixes this problem.

I tried to find the root of the problem. Here is my debug enabled output:

2018-12-31 01:47:03.286  - info: mqtt.0 Client [DVES_6B3BFF] connected with secret 1546217223283_4092
2018-12-31 01:47:03.290  - debug: mqtt.0 stateChange mqtt.0.info.connection: {"val":"DVES_9C67D9,DVES_6B3BFF","ack":true,"ts":1546217223287,"q":0,"from":"system.adapter.mqtt.0","lc":1546217223287}
2018-12-31 01:47:03.297  - debug: mqtt.0 stateChange mqtt.0.tele.sonoff3.LWT: {"val":"Online","ack":true,"ts":1546217223296,"q":0,"from":"system.adapter.mqtt.0","lc":1546217223296}
2018-12-31 01:47:03.343  - info: mqtt.0 Client [DVES_6B3BFF] subscribes on "cmnd/sonoff3/#" with regex /^cmnd\.sonoff3\..*/
2018-12-31 01:47:03.343  - info: mqtt.0 Client [DVES_6B3BFF] subscribes on "cmnd/sonoff3/#"  with regex /^mqtt\.0\.cmnd\.sonoff3\..*/
2018-12-31 01:47:03.343  - info: mqtt.0 Client [DVES_6B3BFF] publishOnSubscribe send all known states
2018-12-31 01:47:03.343  - info: mqtt.0 Client [DVES_6B3BFF] subscribes on "cmnd/sonoffs/#" with regex /^cmnd\.sonoffs\..*/
2018-12-31 01:47:03.344  - info: mqtt.0 Client [DVES_6B3BFF] subscribes on "cmnd/sonoffs/#"  with regex /^mqtt\.0\.cmnd\.sonoffs\..*/
2018-12-31 01:47:03.344  - info: mqtt.0 Client [DVES_6B3BFF] publishOnSubscribe send all known states
2018-12-31 01:47:03.344  - info: mqtt.0 Client [DVES_6B3BFF] subscribes on "cmnd/DVES_6B3BFF_fb/#" with regex /^cmnd\.DVES_6B3BFF_fb\..*/
2018-12-31 01:47:03.344  - info: mqtt.0 Client [DVES_6B3BFF] subscribes on "cmnd/DVES_6B3BFF_fb/#"  with regex /^mqtt\.0\.cmnd\.DVES_6B3BFF_fb\..*/
2018-12-31 01:47:03.344  - info: mqtt.0 Client [DVES_6B3BFF] publishOnSubscribe send all known states
2018-12-31 01:47:03.344  - debug: mqtt.0 stateChange mqtt.0.cmnd.sonoff3.POWER: {"val":"","ack":true,"ts":1546217223342,"q":0,"from":"system.adapter.mqtt.0","lc":1546211354064}
2018-12-31 01:47:03.371  - debug: mqtt.0 stateChange mqtt.0.stat.sonoff3.RESULT: {"val":"{\"POWER\":\"ON\"}","ack":true,"ts":1546217223370,"q":0,"from":"system.adapter.mqtt.0","lc":1546183229931}
2018-12-31 01:47:03.389  - debug: mqtt.0 Client [DVES_6B3BFF] Resend messages on connect: tele/sonoff1/LWT = [object Object]
2018-12-31 01:47:03.389  - info: mqtt.0 Client [DVES_6B3BFF] connection closed: Error: Invalid messageId
2018-12-31 01:47:03.397  - debug: mqtt.0 stateChange mqtt.0.info.connection: {"val":"DVES_9C67D9","ack":true,"ts":1546217223390,"q":0,"from":"system.adapter.mqtt.0","lc":1546217223390}
2018-12-31 01:47:03.399  - debug: mqtt.0 stateChange mqtt.0.tele.sonoff3.LWT: {"val":"[object Object]","ack":true,"ts":1546217223398,"q":0,"from":"system.adapter.mqtt.0","lc":1546217223398}
2018-12-31 01:47:03.407  - debug: mqtt.0 Client [DVES_6B3BFF] Resend messages on connect: tele/sonoff2/LWT = [object Object]
2018-12-31 01:47:03.417  - debug: mqtt.0 Client [DVES_6B3BFF] Resend messages on connect: tele/sonoff1/LWT = [object Object]
2018-12-31 01:47:03.427  - debug: mqtt.0 Client [DVES_6B3BFF] Resend messages on connect: tele/sonoff2/LWT = [object Object]

Here is a more detailed log with more debug output:
I renamed the error from "invalid messageId" to "Bad Paket" for my debug purposes.

2018-12-31 18:05:37.020  - �[34mdebug�[39m: mqtt.0 Client [DVES_6B3BFF] Resend message topic: tele/sonoff2/LWT, payload: [object Object]
2018-12-31 18:05:37.020  - �[32minfo�[39m: mqtt.0 Client [DVES_6B3BFF] connection closed: Error: Bad Paket: {"topic":"tele/sonoff2/LWT","qos":1,"retain":true,"ts":1546275937020,"payload":"[object Object]","count":1,"cmd":"publish"}

The error "Invalid messageId" comes from function publish (packet, stream, opts) in the file node_modules/mqtt-connection/node_modules/mqtt-packet/writeToStream.js .

Maybe there are better way and maybe I didn't even understand the real problem here but it seems to me that the mqtt adapter cannot handle LWT messages with an object payload.
Even though this might not be MQTT adapters fault, it should just disregard bad formated messages and not "crash" on them IMHO.

Adpter remains yellow

Hi,

since 3 days the adapter stays in yellow state. The config is standard, as MQTT-broker. The log is inconspicuous

Is there any problem known?

Debug output:

2018-12-16 11:49:10.246 - debug: mqtt.0 objectDB connected 2018-12-16 11:49:10.292 - debug: mqtt.0 statesDB connected 2018-12-16 11:49:10.403 - info: mqtt.0 starting. Version 2.0.4 in /opt/iobroker/node_modules/iobroker.mqtt, node: v6.14.4 2018-12-16 11:49:10.635 - info: mqtt.0 Starting MQTT ' server on port 1883 2018-12-16 11:49:10.641 - debug: mqtt.0 stateChange mqtt.0.info.connection: {"val":"","ack":true,"ts":1544957350638,"q":0,"from":"system.adapter.mqtt.0","lc":1544957210800} 2018-12-16 11:49:11.434 - debug: mqtt.0 stateChange system.adapter.terminal.0.alive: {"val":true,"ack":true,"ts":1544957351430,"q":0,"from":"system.adapter.terminal.0","lc":1544916032061} 2018-12-16 11:49:11.441 - debug: mqtt.0 stateChange system.adapter.terminal.0.connected: {"val":true,"ack":true,"ts":1544957351433,"q":0,"from":"system.adapter.terminal.0","lc":1544725402531} 2018-12-16 11:49:11.442 - debug: mqtt.0 stateChange system.adapter.terminal.0.memRss: {"val":16.05,"ack":true,"ts":1544957351433,"q":0,"from":"system.adapter.terminal.0","lc":1544957336432} 2018-12-16 11:49:11.442 - debug: mqtt.0 stateChange system.adapter.terminal.0.memHeapTotal: {"val":23.08,"ack":true,"ts":1544957351434,"q":0,"from":"system.adapter.terminal.0","lc":1544725597642} 2018-12-16 11:49:11.442 - debug: mqtt.0 stateChange system.adapter.terminal.0.memHeapUsed: {"val":17.18,"ack":true,"ts":1544957351434,"q":0,"from":"system.adapter.terminal.0","lc":1544957351434} 2018-12-16 11:49:11.442 - debug: mqtt.0 stateChange system.adapter.terminal.0.uptime: {"val":231950,"ack":true,"ts":1544957351434,"q":0,"from":"system.adapter.terminal.0","lc":1544957351434} 2018-12-16 11:49:11.442 - debug: mqtt.0 stateChange system.adapter.terminal.0.inputCount: {"val":1,"ack":true,"ts":1544957351435,"q":0,"from":"system.adapter.terminal.0","lc":1544957336433} 2018-12-16 11:49:11.442 - debug: mqtt.0 stateChange system.adapter.terminal.0.outputCount: {"val":8,"ack":true,"ts":1544957351435,"q":0,"from":"system.adapter.terminal.0","lc":1538082780035} 2018-12-16 11:49:11.500 - info: host.ioBroker object change system.adapter.mihome-vacuum.0 2018-12-16 11:49:11.500 - info: host.ioBroker stopInstance system.adapter.mihome-vacuum.0 2018-12-16 11:49:11.500 - info: host.ioBroker stopInstance system.adapter.mihome-vacuum.0 killing pid 16892 2018-12-16 11:49:11.507 - debug: mqtt.0 stateChange mihome-vacuum.0.info.connection: {"val":false,"ack":true,"ts":1544957351503,"q":0,"from":"system.adapter.mihome-vacuum.0","lc":1544878020162} 2018-12-16 11:49:11.512 - debug: mqtt.0 stateChange system.adapter.mihome-vacuum.0.alive: {"val":false,"ack":true,"ts":1544957351510,"q":0,"from":"system.adapter.mihome-vacuum.0","lc":1544957351510} 2018-12-16 11:49:11.513 - info: mihome-vacuum.0 terminating 2018-12-16 11:49:11.519 - debug: mqtt.0 stateChange mihome-vacuum.0.info.connection: {"val":false,"ack":true,"ts":1544957351515,"q":0,"from":"system.adapter.mihome-vacuum.0","lc":1544878020162} 2018-12-16 11:49:11.525 - debug: mqtt.0 stateChange system.adapter.mihome-vacuum.0.alive: {"val":false,"ack":true,"ts":1544957351523,"q":0,"from":"system.host.ioBroker","lc":1544957351510} 2018-12-16 11:49:11.528 - info: host.ioBroker instance system.adapter.mihome-vacuum.0 terminated with code 0 (OK) 2018-12-16 11:49:11.529 - debug: mqtt.0 stateChange system.adapter.mihome-vacuum.0.connected: {"val":false,"ack":true,"ts":1544957351526,"q":0,"from":"system.host.ioBroker","lc":1544957351526} 2018-12-16 11:49:12.285 - debug: mqtt.0 stateChange system.adapter.telegram.0.alive: {"val":true,"ack":true,"ts":1544957352282,"q":0,"from":"system.adapter.telegram.0","lc":1544933046092} 2018-12-16 11:49:12.291 - debug: mqtt.0 stateChange system.adapter.telegram.0.connected: {"val":true,"ack":true,"ts":1544957352286,"q":0,"from":"system.adapter.telegram.0","lc":1544933046093} 2018-12-16 11:49:12.292 - debug: mqtt.0 stateChange system.adapter.telegram.0.memRss: {"val":59.85,"ack":true,"ts":1544957352287,"q":0,"from":"system.adapter.telegram.0","lc":1544957337197} 2018-12-16 11:49:12.293 - debug: mqtt.0 stateChange system.adapter.telegram.0.memHeapTotal: {"val":33.03,"ack":true,"ts":1544957352287,"q":0,"from":"system.adapter.telegram.0","lc":1544956887077} 2018-12-16 11:49:12.295 - debug: mqtt.0 stateChange system.adapter.telegram.0.memHeapUsed: {"val":28.18,"ack":true,"ts":1544957352288,"q":0,"from":"system.adapter.telegram.0","lc":1544957352288} 2018-12-16 11:49:12.296 - debug: mqtt.0 stateChange system.adapter.telegram.0.uptime: {"val":24311,"ack":true,"ts":1544957352288,"q":0,"from":"system.adapter.telegram.0","lc":1544957352288} 2018-12-16 11:49:12.297 - debug: mqtt.0 stateChange system.adapter.telegram.0.inputCount: {"val":1,"ack":true,"ts":1544957352288,"q":0,"from":"system.adapter.telegram.0","lc":1544957337199} 2018-12-16 11:49:12.298 - debug: mqtt.0 stateChange system.adapter.telegram.0.outputCount: {"val":8,"ack":true,"ts":1544957352288,"q":0,"from":"system.adapter.telegram.0","lc":1544954666483} 2018-12-16 11:49:12.762 - debug: mqtt.0 stateChange system.adapter.pushover.0.alive: {"val":true,"ack":true,"ts":1544957352759,"q":0,"from":"system.adapter.pushover.0","lc":1544945855977} 2018-12-16 11:49:12.765 - debug: mqtt.0 stateChange system.adapter.pushover.0.connected: {"val":true,"ack":true,"ts":1544957352762,"q":0,"from":"system.adapter.pushover.0","lc":1544725418090} 2018-12-16 11:49:12.769 - debug: mqtt.0 stateChange system.adapter.pushover.0.memRss: {"val":15.33,"ack":true,"ts":1544957352765,"q":0,"from":"system.adapter.pushover.0","lc":1544957307747} 2018-12-16 11:49:12.770 - debug: mqtt.0 stateChange system.adapter.pushover.0.memHeapTotal: {"val":15.03,"ack":true,"ts":1544957352766,"q":0,"from":"system.adapter.pushover.0","lc":1544726543703} 2018-12-16 11:49:12.772 - debug: mqtt.0 stateChange system.adapter.pushover.0.memHeapUsed: {"val":10.26,"ack":true,"ts":1544957352766,"q":0,"from":"system.adapter.pushover.0","lc":1544957352766} 2018-12-16 11:49:12.773 - debug: mqtt.0 stateChange system.adapter.pushover.0.uptime: {"val":231935,"ack":true,"ts":1544957352766,"q":0,"from":"system.adapter.pushover.0","lc":1544957352766} 2018-12-16 11:49:12.775 - debug: mqtt.0 stateChange system.adapter.pushover.0.inputCount: {"val":1,"ack":true,"ts":1544957352767,"q":0,"from":"system.adapter.pushover.0","lc":1544957337760} 2018-12-16 11:49:12.776 - debug: mqtt.0 stateChange system.adapter.pushover.0.outputCount: {"val":8,"ack":true,"ts":1544957352767,"q":0,"from":"system.adapter.pushover.0","lc":1538160046656} 2018-12-16 11:49:13.147 - debug: mqtt.0 stateChange system.adapter.shelly.0.alive: {"val":true,"ack":true,"ts":1544957353144,"q":0,"from":"system.adapter.shelly.0","lc":1544779283337} 2018-12-16 11:49:13.150 - debug: mqtt.0 stateChange system.adapter.shelly.0.connected: {"val":true,"ack":true,"ts":1544957353147,"q":0,"from":"system.adapter.shelly.0","lc":1544725442861} 2018-12-16 11:49:13.154 - debug: mqtt.0 stateChange system.adapter.shelly.0.memRss: {"val":32.05,"ack":true,"ts":1544957353148,"q":0,"from":"system.adapter.shelly.0","lc":1544957338143} 2018-12-16 11:49:13.154 - debug: mqtt.0 stateChange system.adapter.shelly.0.memHeapTotal: {"val":17.03,"ack":true,"ts":1544957353149,"q":0,"from":"system.adapter.shelly.0","lc":1544955942968} 2018-12-16 11:49:13.155 - debug: mqtt.0 stateChange system.adapter.shelly.0.memHeapUsed: {"val":14.42,"ack":true,"ts":1544957353149,"q":0,"from":"system.adapter.shelly.0","lc":1544957353149} 2018-12-16 11:49:13.155 - debug: mqtt.0 stateChange system.adapter.shelly.0.uptime: {"val":231912,"ack":true,"ts":1544957353149,"q":0,"from":"system.adapter.shelly.0","lc":1544957353149} 2018-12-16 11:49:13.156 - debug: mqtt.0 stateChange system.adapter.shelly.0.inputCount: {"val":1,"ack":true,"ts":1544957353150,"q":0,"from":"system.adapter.shelly.0","lc":1544957338144} 2018-12-16 11:49:13.156 - debug: mqtt.0 stateChange system.adapter.shelly.0.outputCount: {"val":8,"ack":true,"ts":1544957353150,"q":0,"from":"system.adapter.shelly.0","lc":1544956783059} 2018-12-16 11:49:13.952 - debug: mqtt.0 stateChange system.adapter.hm-rega.0.alive: {"val":true,"ack":true,"ts":1544957353946,"q":0,"from":"system.adapter.hm-rega.0","lc":1544739900040} 2018-12-16 11:49:13.955 - debug: mqtt.0 stateChange system.adapter.hm-rega.0.connected: {"val":true,"ack":true,"ts":1544957353948,"q":0,"from":"system.adapter.hm-rega.0","lc":1544725450606} 2018-12-16 11:49:13.956 - debug: mqtt.0 stateChange system.adapter.hm-rega.0.memRss: {"val":34.2,"ack":true,"ts":1544957353950,"q":0,"from":"system.adapter.hm-rega.0","lc":1544957353950} 2018-12-16 11:49:13.957 - debug: mqtt.0 stateChange system.adapter.hm-rega.0.memHeapTotal: {"val":21.03,"ack":true,"ts":1544957353951,"q":0,"from":"system.adapter.hm-rega.0","lc":1544957338945} 2018-12-16 11:49:13.958 - debug: mqtt.0 stateChange system.adapter.hm-rega.0.memHeapUsed: {"val":14.72,"ack":true,"ts":1544957353951,"q":0,"from":"system.adapter.hm-rega.0","lc":1544957353951} 2018-12-16 11:49:13.958 - debug: mqtt.0 stateChange system.adapter.hm-rega.0.uptime: {"val":231905,"ack":true,"ts":1544957353952,"q":0,"from":"system.adapter.hm-rega.0","lc":1544957353952} 2018-12-16 11:49:13.959 - debug: mqtt.0 stateChange system.adapter.hm-rega.0.inputCount: {"val":1,"ack":true,"ts":1544957353952,"q":0,"from":"system.adapter.hm-rega.0","lc":1544957338949} 2018-12-16 11:49:13.959 - debug: mqtt.0 stateChange system.adapter.hm-rega.0.outputCount: {"val":8,"ack":true,"ts":1544957353952,"q":0,"from":"system.adapter.hm-rega.0","lc":1544957083876} 2018-12-16 11:49:14.010 - info: host.ioBroker instance system.adapter.mihome-vacuum.0 started with pid 16932 2018-12-16 11:49:14.435 - debug: mqtt.0 stateChange system.adapter.hm-rpc.0.alive: {"val":true,"ack":true,"ts":1544957354428,"q":0,"from":"system.adapter.hm-rpc.0","lc":1544957054311} 2018-12-16 11:49:14.436 - debug: mqtt.0 stateChange system.adapter.hm-rpc.0.connected: {"val":true,"ack":true,"ts":1544957354432,"q":0,"from":"system.adapter.hm-rpc.0","lc":1544725446514} 2018-12-16 11:49:14.444 - debug: mqtt.0 stateChange system.adapter.hm-rpc.0.memRss: {"val":32.87,"ack":true,"ts":1544957354434,"q":0,"from":"system.adapter.hm-rpc.0","lc":1544957354434} 2018-12-16 11:49:14.444 - debug: mqtt.0 stateChange system.adapter.hm-rpc.0.memHeapTotal: {"val":18.03,"ack":true,"ts":1544957354435,"q":0,"from":"system.adapter.hm-rpc.0","lc":1544956544129} 2018-12-16 11:49:14.445 - debug: mqtt.0 stateChange system.adapter.hm-rpc.0.memHeapUsed: {"val":13.77,"ack":true,"ts":1544957354435,"q":0,"from":"system.adapter.hm-rpc.0","lc":1544957354435} 2018-12-16 11:49:14.445 - debug: mqtt.0 stateChange system.adapter.hm-rpc.0.uptime: {"val":231909,"ack":true,"ts":1544957354435,"q":0,"from":"system.adapter.hm-rpc.0","lc":1544957354435} 2018-12-16 11:49:14.445 - debug: mqtt.0 stateChange system.adapter.hm-rpc.0.inputCount: {"val":23,"ack":true,"ts":1544957354436,"q":0,"from":"system.adapter.hm-rpc.0","lc":1544957354436} 2018-12-16 11:49:14.445 - debug: mqtt.0 stateChange system.adapter.hm-rpc.0.outputCount: {"val":30,"ack":true,"ts":1544957354436,"q":0,"from":"system.adapter.hm-rpc.0","lc":1544957354436} 2018-12-16 11:49:14.563 - debug: mihome-vacuum.0 objectDB connected 2018-12-16 11:49:14.609 - debug: mihome-vacuum.0 statesDB connected 2018-12-16 11:49:14.784 - info: mihome-vacuum.0 starting. Version 1.1.5 in /opt/iobroker/node_modules/iobroker.mihome-vacuum, node: v6.14.4 2018-12-16 11:49:14.791 - info: mihome-vacuum.0 Expert mode disabled, states deleded 2018-12-16 11:49:14.791 - info: mihome-vacuum.0 Create state clean_home for controlling by cloud adapter 2018-12-16 11:49:14.802 - debug: mihome-vacuum.0 server started on 0.0.0.0:53421 2018-12-16 11:49:14.812 - debug: mqtt.0 stateChange system.adapter.mihome-vacuum.0.alive: {"val":true,"ack":true,"ts":1544957354809,"q":0,"from":"system.adapter.mihome-vacuum.0","lc":1544957354809} 2018-12-16 11:49:14.825 - debug: mqtt.0 stateChange system.adapter.mihome-vacuum.0.connected: {"val":true,"ack":true,"ts":1544957354811,"q":0,"from":"system.adapter.mihome-vacuum.0","lc":1544957354811} 2018-12-16 11:49:14.826 - debug: mqtt.0 stateChange system.adapter.mihome-vacuum.0.memRss: {"val":37.16,"ack":true,"ts":1544957354812,"q":0,"from":"system.adapter.mihome-vacuum.0","lc":1544957354812} 2018-12-16 11:49:14.827 - debug: mqtt.0 stateChange system.adapter.mihome-vacuum.0.memHeapTotal: {"val":20.03,"ack":true,"ts":1544957354812,"q":0,"from":"system.adapter.mihome-vacuum.0","lc":1544957354812} 2018-12-16 11:49:14.828 - debug: mqtt.0 stateChange system.adapter.mihome-vacuum.0.memHeapUsed: {"val":12.56,"ack":true,"ts":1544957354812,"q":0,"from":"system.adapter.mihome-vacuum.0","lc":1544957354812} 2018-12-16 11:49:14.829 - debug: mqtt.0 stateChange system.adapter.mihome-vacuum.0.uptime: {"val":1,"ack":true,"ts":1544957354813,"q":0,"from":"system.adapter.mihome-vacuum.0","lc":1544957354813} 2018-12-16 11:49:14.829 - debug: mqtt.0 stateChange system.adapter.mihome-vacuum.0.inputCount: {"val":0,"ack":true,"ts":1544957354813,"q":0,"from":"system.adapter.mihome-vacuum.0","lc":1544957354813} 2018-12-16 11:49:14.829 - debug: mqtt.0 stateChange system.adapter.mihome-vacuum.0.outputCount: {"val":8,"ack":true,"ts":1544957354814,"q":0,"from":"system.adapter.mihome-vacuum.0","lc":1544957172594} 2018-12-16 11:49:14.829 - debug: mqtt.0 stateChange mihome-vacuum.0.info.connection: {"val":false,"ack":true,"ts":1544957354814,"q":0,"from":"system.adapter.mihome-vacuum.0","lc":1544878020162} 2018-12-16 11:49:14.883 - debug: mqtt.0 stateChange system.adapter.alexa2.0.alive: {"val":true,"ack":true,"ts":1544957354879,"q":0,"from":"system.adapter.alexa2.0","lc":1544938308847} 2018-12-16 11:49:14.886 - debug: mqtt.0 stateChange system.adapter.alexa2.0.connected: {"val":true,"ack":true,"ts":1544957354884,"q":0,"from":"system.adapter.alexa2.0","lc":1544725411020} 2018-12-16 11:49:14.898 - debug: mqtt.0 stateChange system.adapter.alexa2.0.memRss: {"val":34.62,"ack":true,"ts":1544957354886,"q":0,"from":"system.adapter.alexa2.0","lc":1544957324873} 2018-12-16 11:49:14.898 - debug: mqtt.0 stateChange system.adapter.alexa2.0.memHeapTotal: {"val":20.03,"ack":true,"ts":1544957354886,"q":0,"from":"system.adapter.alexa2.0","lc":1544878409242} 2018-12-16 11:49:14.899 - debug: mqtt.0 stateChange system.adapter.alexa2.0.memHeapUsed: {"val":16.35,"ack":true,"ts":1544957354886,"q":0,"from":"system.adapter.alexa2.0","lc":1544957354886} 2018-12-16 11:49:14.899 - debug: mqtt.0 stateChange system.adapter.alexa2.0.uptime: {"val":231945,"ack":true,"ts":1544957354887,"q":0,"from":"system.adapter.alexa2.0","lc":1544957354887} 2018-12-16 11:49:14.899 - debug: mqtt.0 stateChange system.adapter.alexa2.0.inputCount: {"val":1,"ack":true,"ts":1544957354888,"q":0,"from":"system.adapter.alexa2.0","lc":1544957339878} 2018-12-16 11:49:14.899 - debug: mqtt.0 stateChange system.adapter.alexa2.0.outputCount: {"val":8,"ack":true,"ts":1544957354888,"q":0,"from":"system.adapter.alexa2.0","lc":1544951066139} 2018-12-16 11:49:15.235 - debug: mqtt.0 stateChange system.adapter.discovery.0.alive: {"val":true,"ack":true,"ts":1544957355232,"q":0,"from":"system.adapter.discovery.0","lc":1544954503475} 2018-12-16 11:49:15.238 - debug: mqtt.0 stateChange system.adapter.discovery.0.connected: {"val":true,"ack":true,"ts":1544957355236,"q":0,"from":"system.adapter.discovery.0","lc":1544725390099} 2018-12-16 11:49:15.246 - debug: mqtt.0 stateChange system.adapter.discovery.0.memRss: {"val":14.74,"ack":true,"ts":1544957355238,"q":0,"from":"system.adapter.discovery.0","lc":1544957325227} 2018-12-16 11:49:15.250 - debug: mqtt.0 stateChange system.adapter.discovery.0.memHeapTotal: {"val":15.03,"ack":true,"ts":1544957355239,"q":0,"from":"system.adapter.discovery.0","lc":1544762147295} 2018-12-16 11:49:15.250 - debug: mqtt.0 stateChange system.adapter.discovery.0.memHeapUsed: {"val":10.25,"ack":true,"ts":1544957355239,"q":0,"from":"system.adapter.discovery.0","lc":1544957355239} 2018-12-16 11:49:15.250 - debug: mqtt.0 stateChange system.adapter.discovery.0.uptime: {"val":231966,"ack":true,"ts":1544957355239,"q":0,"from":"system.adapter.discovery.0","lc":1544957355239} 2018-12-16 11:49:15.250 - debug: mqtt.0 stateChange system.adapter.discovery.0.inputCount: {"val":1,"ack":true,"ts":1544957355240,"q":0,"from":"system.adapter.discovery.0","lc":1544957340231} 2018-12-16 11:49:15.251 - debug: mqtt.0 stateChange system.adapter.discovery.0.outputCount: {"val":8,"ack":true,"ts":1544957355240,"q":0,"from":"system.adapter.discovery.0","lc":1544725420104} 2018-12-16 11:49:17.276 - debug: zigbee.0 system.adapter.admin.0: logging true 2018-12-16 11:49:17.281 - debug: mqtt.0 system.adapter.admin.0: logging true 2018-12-16 11:49:17.283 - debug: mihome-vacuum.0 system.adapter.admin.0: logging true 2018-12-16 11:49:17.750 - debug: mqtt.0 stateChange system.adapter.javascript.0.alive: {"val":true,"ack":true,"ts":1544957357747,"q":0,"from":"system.adapter.javascript.0","lc":1544949767166} 2018-12-16 11:49:17.755 - debug: mqtt.0 stateChange system.adapter.javascript.0.connected: {"val":true,"ack":true,"ts":1544957357749,"q":0,"from":"system.adapter.javascript.0","lc":1544725409810} 2018-12-16 11:49:17.758 - debug: mqtt.0 stateChange system.adapter.javascript.0.memRss: {"val":51.9,"ack":true,"ts":1544957357749,"q":0,"from":"system.adapter.javascript.0","lc":1544957357749} 2018-12-16 11:49:17.758 - debug: mqtt.0 stateChange system.adapter.javascript.0.memHeapTotal: {"val":51.96,"ack":true,"ts":1544957357750,"q":0,"from":"system.adapter.javascript.0","lc":1544957087706} 2018-12-16 11:49:17.758 - debug: mqtt.0 stateChange system.adapter.javascript.0.memHeapUsed: {"val":47.23,"ack":true,"ts":1544957357750,"q":0,"from":"system.adapter.javascript.0","lc":1544957357750} 2018-12-16 11:49:17.758 - debug: mqtt.0 stateChange system.adapter.javascript.0.uptime: {"val":231952,"ack":true,"ts":1544957357750,"q":0,"from":"system.adapter.javascript.0","lc":1544957357750} 2018-12-16 11:49:17.758 - debug: mqtt.0 stateChange system.adapter.javascript.0.inputCount: {"val":166,"ack":true,"ts":1544957357750,"q":0,"from":"system.adapter.javascript.0","lc":1544957357750} 2018-12-16 11:49:17.759 - debug: mqtt.0 stateChange system.adapter.javascript.0.outputCount: {"val":8,"ack":true,"ts":1544957357751,"q":0,"from":"system.adapter.javascript.0","lc":1544956817686} 2018-12-16 11:49:18.381 - debug: mqtt.0 stateChange system.adapter.text2command.0.alive: {"val":true,"ack":true,"ts":1544957358374,"q":0,"from":"system.adapter.text2command.0","lc":1544943655373} 2018-12-16 11:49:18.384 - debug: mqtt.0 stateChange system.adapter.text2command.0.connected: {"val":true,"ack":true,"ts":1544957358377,"q":0,"from":"system.adapter.text2command.0","lc":1544725438243} 2018-12-16 11:49:18.388 - debug: mqtt.0 stateChange system.adapter.text2command.0.memRss: {"val":16.48,"ack":true,"ts":1544957358378,"q":0,"from":"system.adapter.text2command.0","lc":1544957358378} 2018-12-16 11:49:18.391 - debug: mqtt.0 stateChange system.adapter.text2command.0.memHeapTotal: {"val":15.03,"ack":true,"ts":1544957358378,"q":0,"from":"system.adapter.text2command.0","lc":1544725573273} 2018-12-16 11:49:18.391 - debug: mqtt.0 stateChange system.adapter.text2command.0.memHeapUsed: {"val":10.49,"ack":true,"ts":1544957358379,"q":0,"from":"system.adapter.text2command.0","lc":1544957358379} 2018-12-16 11:49:18.391 - debug: mqtt.0 stateChange system.adapter.text2command.0.uptime: {"val":231921,"ack":true,"ts":1544957358379,"q":0,"from":"system.adapter.text2command.0","lc":1544957358379} 2018-12-16 11:49:18.392 - debug: mqtt.0 stateChange system.adapter.text2command.0.inputCount: {"val":2,"ack":true,"ts":1544957358379,"q":0,"from":"system.adapter.text2command.0","lc":1544957358379} 2018-12-16 11:49:18.392 - debug: mqtt.0 stateChange system.adapter.text2command.0.outputCount: {"val":8,"ack":true,"ts":1544957358380,"q":0,"from":"system.adapter.text2command.0","lc":1538919719548} 2018-12-16 11:49:19.425 - debug: mqtt.0 stateChange system.host.ioBroker.alive: {"val":true,"ack":true,"ts":1544957359423,"q":0,"from":"system.host.ioBroker","lc":1544725385324} 2018-12-16 11:49:19.433 - debug: mqtt.0 stateChange system.host.ioBroker.load: {"val":0.19,"ack":true,"ts":1544957359425,"q":0,"from":"system.host.ioBroker","lc":1544957359425} 2018-12-16 11:49:19.437 - debug: mqtt.0 stateChange system.host.ioBroker.mem: {"val":16,"ack":true,"ts":1544957359425,"q":0,"from":"system.host.ioBroker","lc":1544957359425} 2018-12-16 11:49:19.437 - debug: mqtt.0 stateChange system.host.ioBroker.memRss: {"val":78.86,"ack":true,"ts":1544957359425,"q":0,"from":"system.host.ioBroker","lc":1544957359425} 2018-12-16 11:49:19.437 - debug: mqtt.0 stateChange system.host.ioBroker.memHeapTotal: {"val":45.34,"ack":true,"ts":1544957359426,"q":0,"from":"system.host.ioBroker","lc":1544957359426} 2018-12-16 11:49:19.437 - debug: mqtt.0 stateChange system.host.ioBroker.memHeapUsed: {"val":29.35,"ack":true,"ts":1544957359426,"q":0,"from":"system.host.ioBroker","lc":1544957359426} 2018-12-16 11:49:19.437 - debug: mqtt.0 stateChange system.host.ioBroker.uptime: {"val":231975,"ack":true,"ts":1544957359426,"q":0,"from":"system.host.ioBroker","lc":1544957359426} 2018-12-16 11:49:19.437 - debug: mqtt.0 stateChange system.host.ioBroker.freemem: {"val":293,"ack":true,"ts":1544957359426,"q":0,"from":"system.host.ioBroker","lc":1544957359426} 2018-12-16 11:49:19.437 - debug: mqtt.0 stateChange system.host.ioBroker.inputCount: {"val":25,"ack":true,"ts":1544957359426,"q":0,"from":"system.host.ioBroker","lc":1544957359426} 2018-12-16 11:49:19.438 - debug: mqtt.0 stateChange system.host.ioBroker.outputCount: {"val":14,"ack":true,"ts":1544957359427,"q":0,"from":"system.host.ioBroker","lc":1544957359427}

Gibt es einen Timeout, sodass ein Sender die Verbindung zum MQTT-Adapter verliert?!

Folgendes Szenario:
Ich habe einen ESP8266, der eine Verbindung zum MQTT-Adapter im IOBroker aufbaut.
Dies funktioniert auch problemlos.

Drücke ich einen Knopf (der ESP8266 ist entsprechend verkabelt), sowird eine (entprellte) Methode aufgerufen, die einmalig eine Nachricht (mit client.publish("...")) an den MQTT-Server sendet.
Diese Nachricht wird auch problemlos empfangen und ich kann sie in IO-Broker sehen.
Blöderweise verliert der ESP8266 jedoch sehr schnell (und wirklich reproduzierbar regelmäßig) die Verbindung zum MQTT-Server, sodass er sich dann automatisch reconnected.

Das verückte ist, dass ich dieses Verhalten unterbinden kann, in dem ich dauern (in 2 Sekunden-Abständen) eine Nachricht an den MQTT-Server schicken kann. Dann ist es auch egal, wann ich den Knop drücke: Die Nachricht kommt ebenfalls an. Das läuft hier jetzt bei mir ohne Verbindungsabruch seit ca. 6 Stunden durch.

Lasse ich allerdings dieses ständige Senden in 2-Sekunden-Abständen weg, so verliert der ESP8266 innerhalb von 5 Minuten sofort mindestens einmal die Verbindung (und braucht dann manchmal auch ewig, bis er sich wieder verbunden hat). Im logfile des IOBroker steht dann übrigens einfach nur "mqtt.0 Client [ESP8266Client-4bf0] connection closed: closed" und (leider) keine Fehlermeldung oder sowas.

Ich habe im ESP8266 auch keinen deepsleep oder sowas programmiert, daher verstehe ich überhaupt nicht, warum er ständig die Verbindung sofort verliert.

Meine Frage ist, ob es von Seiten des MQTT-Adapters vielleicht irgendwie einen Timeout gibt, zu dem der Server die Verbindung schließt, wenn er eine bestimmte Zeit lang keine Nachricht erhalten hat?!

Adapter tries to send topic conntaining '#' with Alexa2 enabled

Hey,

I recently had to debug my mqtt client because it spammed the Broker and keept crashing.

As soon as I enable sending data of the Alexa adapter to mqtt it crashed and restarts in a loop.

Output from vernemq:

vernemq     | 09:07:30.204 [warning] stopped connected session, due to unexpected frame type {error,'no_#_allowed_in_word'}
vernemq     | 09:07:30.204 [warning] session stopped abnormally due to '{error,unexpected_message,{error,'no_#_allowed_in_word'}}'

Alexa got some objects named "#trigger" and so on.

A fix would prop. be just to filter those out. That again would probably destroy the ability to control stuff.

Verify Compact mode for your adapter

We have detected that your adapter supports the compact mode. Please use the latest js-controller 2.0 and verify that everything works.

Some more information what is important to check can be found at ioBroker/ioBroker.js-controller#512

On questions please answer to the linked issue. Please close this issue after your test and add the version number that you have tested please as a comment.

Thank you for your support.

In Version 2.0.0 "Secret Warnings"

Ich bekomme mit der 2.0.0 follgende Warnings:
``
`
mqtt.0 2018-06-19 14:18:00.855 warn Old client ESPClient0 with secret 1529410641752_6519 sends publish. Ignore! Actual secret is 1529410680003_8852

mqtt.0 2018-06-19 14:18:00.854 warn Old client ESPClient0 with secret 1529410641752_6519 sends publish. Ignore! Actual secret is 1529410680003_8852

mqtt.0 2018-06-19 14:18:00.811 warn Old client ESPClient0 with secret 1529410641752_6519 sends publish. Ignore! Actual secret is 1529410680003_8852

mqtt.0 2018-06-19 14:18:00.013 info Client [ESPClient0] subscribes on "/thermometer/#" with regex /^mqtt.0.thermometer..*/

mqtt.0 2018-06-19 14:18:00.013 info Client [ESPClient0] subscribes on "/thermometer/#" with regex /^thermometer..*/

mqtt.0 2018-06-19 14:18:00.004 info Client [ESPClient0] reconnected. Old secret 1529410641752_6519. New secret 1529410680003_8852
`
Als MQTT client nutze ich eine NodeMCU mit ESP Easy und als MQTT Protocoll "OpenHAB MQTT"

v2.04 - 2.05 Server will sich als client anmelden?

Habe nur Shellys im Netzwerk aber meldet sich irgendwas wenn ich kein pass und usr drin habe
client [mqtt_ef44a4fd.e35848] connected with secret 1548273404162_6047

und mit pass und usr
mqtt.0 | 2019-01-23 20:37:28.904 | warn | Client [mqtt_ef44a4fd.e35848] has invalid password(undefined) or username(undefined)

Ist dieser vom Adapter selber?

Shellys haben den pass und Usr hinterlegt beim anmelden, aber melden sich trotzdem an wenn Auth deaktiviert.
Ist das so gewollt?

Kein Fehler sondern Anfrage wegen MQTT state

Zuerst: Kein Fehler, sondern eine Frage!!
Da ich nicht wusste wie ich das nachfragen kann.
Ich lasse im IOBroker VIS mir den Status verschiedener Wichtiger Adapter anzeigen, ob diese laufen.
Bei den meisten gibt es einen State "connection ---- > true/false". Beim MQTT hab ich aber nur
mqtt.0.@ ---> connected bzw nichts wenn nicht connected. Wäre "schöner" wenn es direkt einen status
z.B. mqtt.0.connected ---> true bzw false. Dann kann man damit besser in VIS umgehen.

Danke.
Gruß Peter

connection closed: Error: read ECONNRESET

https://forum.iobroker.net/viewtopic.php?f=22&t=15325&p=207999#p207999
mqtt.0 2018-07-08 16:09:28.515 info Client [ESP32Client] connection closed: Error: read ECONNRESET
mqtt.0 2018-07-08 16:09:23.081 warn Client [ESP32Client] Message 22 deleted after 11 retries
mqtt.0 2018-07-08 16:09:00.964 warn Client [ESPClient_B4:E6:2D:29:29:F2] Message 2 deleted after 11 retries
"Mit der von Bluefox erwähnten Chunking Option funktioniert es" finde diese option nicht
mfg
mikewolf

MQTT Server does not start

mqtt.0 does not start; on the webui the instance remains yellow
On the OS side, a port is opened for websocket and mqtt socket only on tcpv6, not on v4. The issue occured after reininstalling iobroker on the same Raspi on a new SDcard.

Versions

iobroker version 1.4.2

Adapter    "admin"         : 3.5.10   , installed 3.5.10
Adapter    "cloud"         : 2.6.2    , installed 2.6.2
Adapter    "discovery"     : 1.2.4    , installed 1.2.4
Adapter    "flot"          : 1.9.1    , installed 1.9.1
Adapter    "history"       : 1.8.5    , installed 1.8.5
Adapter    "hm-rega"       : 2.0.0    , installed 2.0.0
Adapter    "hm-rpc"        : 1.8.0    , installed 1.8.0
Adapter    "javascript"    : 3.6.4    , installed 3.6.4
Controller "js-controller" : 1.4.2    , installed 1.4.2
Adapter    "luftdaten"     : 0.0.5    , installed 0.0.6
Adapter    "mobile"        : 0.4.11   , installed 0.4.11
Adapter    "mqtt"          : 2.0.3    , installed 2.0.4
Adapter    "rpi2"          : 0.3.2    , installed 0.3.2
Adapter    "simple-api"    : 2.0.0    , installed 2.0.0
Adapter    "socketio"      : 2.1.1    , installed 2.1.1
Adapter    "sonoff"        : 2.2.2    , installed 2.2.2
Adapter    "telegram"      : 1.2.4    , installed 1.3.6
Adapter    "tr-064"        : 0.4.14   , installed 0.4.18
Adapter    "vis"           : 1.1.7    , installed 1.1.7
Adapter    "web"           : 2.4.1    , installed 2.4.1

Tried:

  • using ioBroker.sonoff --> starts successfully, but ONLY with IPv4 sockets
  • restarting ioBroker
  • rebooting the Raspi
  • reinstalling ioBroker.mqtt

ioBroker Log:

   mqtt.0 | 2019-01-03 13:33:39.869 | info | Starting MQTT -WebSocket (Secure)' authenticated  server on port 1884
   mqtt.0 | 2019-01-03 13:33:39.868 | info | Starting MQTT  (Secure)' authenticated  server on port 1883
   mqtt.0 | 2019-01-03 13:33:38.699 | info | starting. Version 2.0.4 in /opt/iobroker/node_modules/iobroker.mqtt, node: v8.15.0
   mqtt.0 | 2019-01-03 13:33:38.541 | info | States connected to redis: 127.0.0.1:6379

netstat --listen

pi@ioBroker:~ $ netstat --listen
Aktive Internetverbindungen (Nur Server)
Proto Recv-Q Send-Q Local Address           Foreign Address         State      
tcp        0      0 ioBroker.fritz.bo:12001 0.0.0.0:*               LISTEN     
tcp        0      0 localhost:9001          0.0.0.0:*               LISTEN     
tcp        0      0 ioBroker.fritz.bo:12010 0.0.0.0:*               LISTEN     
tcp        0      0 localhost:6379          0.0.0.0:*               LISTEN     
tcp        0      0 ioBroker.fritz.bo:18701 0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:ssh             0.0.0.0:*               LISTEN     
tcp6       0      0 localhost:6379          [::]:*                  LISTEN     
tcp6       0      0 [::]:tproxy             [::]:*                  LISTEN     
tcp6       0      0 [::]:8082               [::]:*                  LISTEN     
tcp6       0      0 [::]:8084               [::]:*                  LISTEN     
tcp6       0      0 [::]:ssh                [::]:*                  LISTEN     
tcp6       0      0 [::]:1883               [::]:*                  LISTEN     
tcp6       0      0 [::]:1884               [::]:*                  LISTEN     
udp        0      0 0.0.0.0:bootpc          0.0.0.0:*                          
udp        0      0 0.0.0.0:34425           0.0.0.0:*                          
udp        0      0 0.0.0.0:mdns            0.0.0.0:*                          
udp6       0      0 [::]:dhcpv6-client      [::]:*                             
udp6       0      0 [::]:54827              [::]:*                             
udp6       0      0 [::]:mdns               [::]:*                             
raw6       0      0 [::]:ipv6-icmp          [::]:*                  7

Issue seems not to be connected to MQTT Server/broker startet nicht #22
How can I instruct iobroker.mqtt to also open a v4 port?

Feature request MQTT retain

hey guys,

I would kindly like to ask if you could add the retain feature to the mqtt broker.
Don't like to host a separate mosquitto server :/

at the moment after connection to a known topic this is the answer
test/topic (null)

Or is there a reason why not to do that?

mqtt verstümmelte Datensätze Prüfsumme

der ioBroker empfängt manchmal verstümmelte Datensätze.
Im Topic steht z.B. "mqtt.0.haus.kell1_]" statt "keller".
In den Daten steht statt der Temperatur "atus/letzter FehlerR" usw..

Bei mqtt ist ja eine Prüfsumme z.B. MD5 vorgesehen bzw. möglich.
Wie kann man die im Broker bzw. im ESP8266 PubSubClient.cpp aktivieren?

v. 2.0.4 uncaught exception: Cannot read property 'topic' of undefined

2019-01-09 11:20:03.928  - �[31merror�[39m: mqtt.0 uncaught exception: Cannot read property 'topic' of undefined
2019-01-09 11:20:03.952  - �[31merror�[39m: mqtt.0 TypeError: Cannot read property 'topic' of undefined
    at receivedTopic (C:\ioBroker\node_modules\iobroker.mqtt\lib\server.js:406:31)
    at Connection.client.on.packet (C:\ioBroker\node_modules\iobroker.mqtt\lib\server.js:820:21)
    at emitOne (events.js:96:13)
    at Connection.emit (events.js:188:7)
    at Connection.emitPacket (C:\ioBroker\node_modules\iobroker.mqtt\node_modules\mqtt-connection\connection.js:10:8)
    at emitOne (events.js:96:13)
    at Connection.emit (events.js:188:7)
    at addChunk (C:\ioBroker\node_modules\iobroker.mqtt\node_modules\readable-stream\lib\_stream_readable.js:291:12)
    at readableAddChunk (C:\ioBroker\node_modules\iobroker.mqtt\node_modules\readable-stream\lib\_stream_readable.js:278:11)
    at Connection.Duplexify._forward (C:\ioBroker\node_modules\iobroker.mqtt\node_modules\duplexify\index.js:170:26)
    at DestroyableTransform.onreadable (C:\ioBroker\node_modules\iobroker.mqtt\node_modules\duplexify\index.js:134:10)
2019-01-09 11:20:04.495  - �[32minfo�[39m: mqtt.0 terminating
2019-01-09 11:20:05.384  - �[31merror�[39m: Caught by controller[0]: TypeError: Cannot read property 'topic' of undefined
2019-01-09 11:20:05.393  - �[31merror�[39m: Caught by controller[0]:     at receivedTopic (C:\ioBroker\node_modules\iobroker.mqtt\lib\server.js:406:31)
2019-01-09 11:20:05.394  - �[31merror�[39m: Caught by controller[0]:     at Connection.client.on.packet (C:\ioBroker\node_modules\iobroker.mqtt\lib\server.js:820:21)
2019-01-09 11:20:05.394  - �[31merror�[39m: Caught by controller[0]:     at emitOne (events.js:96:13)
2019-01-09 11:20:05.395  - �[31merror�[39m: Caught by controller[0]:     at Connection.emit (events.js:188:7)
2019-01-09 11:20:05.395  - �[31merror�[39m: Caught by controller[0]:     at Connection.emitPacket (C:\ioBroker\node_modules\iobroker.mqtt\node_modules\mqtt-connection\connection.js:10:8)
2019-01-09 11:20:05.396  - �[31merror�[39m: Caught by controller[0]:     at emitOne (events.js:96:13)
2019-01-09 11:20:05.396  - �[31merror�[39m: Caught by controller[0]:     at Connection.emit (events.js:188:7)
2019-01-09 11:20:05.397  - �[31merror�[39m: Caught by controller[0]:     at addChunk (C:\ioBroker\node_modules\iobroker.mqtt\node_modules\readable-stream\lib\_stream_readable.js:291:12)
2019-01-09 11:20:05.398  - �[31merror�[39m: Caught by controller[0]:     at readableAddChunk (C:\ioBroker\node_modules\iobroker.mqtt\node_modules\readable-stream\lib\_stream_readable.js:278:11)
2019-01-09 11:20:05.398  - �[31merror�[39m: Caught by controller[0]:     at Connection.Duplexify._forward (C:\ioBroker\node_modules\iobroker.mqtt\node_modules\duplexify\index.js:170:26)
2019-01-09 11:20:05.399  - �[31merror�[39m: Caught by controller[0]:     at DestroyableTransform.onreadable (C:\ioBroker\node_modules\iobroker.mqtt\node_modules\duplexify\index.js:134:10)
2019-01-09 11:20:05.399  - �[31merror�[39m: Caught by controller[1]: 2019-01-09 11:20:03.949  -  mqtt.0 uncaught exception: Cannot read property 'topic' of undefined

2019-01-09 11:20:05.400  - �[31merror�[39m: Caught by controller[2]: 2019-01-09 11:20:03.953  -  mqtt.0 TypeError: Cannot read property 'topic' of undefined
2019-01-09 11:20:05.401  - �[31merror�[39m: Caught by controller[2]:     at receivedTopic (C:\ioBroker\node_modules\iobroker.mqtt\lib\server.js:406:31)
2019-01-09 11:20:05.401  - �[31merror�[39m: Caught by controller[2]:     at Connection.client.on.packet (C:\ioBroker\node_modules\iobroker.mqtt\lib\server.js:820:21)
2019-01-09 11:20:05.402  - �[31merror�[39m: Caught by controller[2]:     at emitOne (events.js:96:13)
2019-01-09 11:20:05.402  - �[31merror�[39m: Caught by controller[2]:     at Connection.emit (events.js:188:7)
2019-01-09 11:20:05.403  - �[31merror�[39m: Caught by controller[2]:     at Connection.emitPacket (C:\ioBroker\node_modules\iobroker.mqtt\node_modules\mqtt-connection\connection.js:10:8)
2019-01-09 11:20:05.403  - �[31merror�[39m: Caught by controller[2]:     at emitOne (events.js:96:13)
2019-01-09 11:20:05.404  - �[31merror�[39m: Caught by controller[2]:     at Connection.emit (events.js:188:7)
2019-01-09 11:20:05.404  - �[31merror�[39m: Caught by controller[2]:     at addChunk (C:\ioBroker\node_modules\iobroker.mqtt\node_modules\readable-stream\lib\_stream_readable.js:291:12)
2019-01-09 11:20:05.405  - �[31merror�[39m: Caught by controller[2]:     at readableAddChunk (C:\ioBroker\node_modules\iobroker.mqtt\node_modules\readable-stream\lib\_stream_readable.js:278:11)
2019-01-09 11:20:05.405  - �[31merror�[39m: Caught by controller[2]:     at Connection.Duplexify._forward (C:\ioBroker\node_modules\iobroker.mqtt\node_modules\duplexify\index.js:170:26)
2019-01-09 11:20:05.406  - �[31merror�[39m: Caught by controller[2]:     at DestroyableTransform.onreadable (C:\ioBroker\node_modules\iobroker.mqtt\node_modules\duplexify\index.js:134:10)

2019-01-09 11:20:05.407  - �[31merror�[39m: host.SERVER instance system.adapter.mqtt.0 terminated with code 0 (OK)
2019-01-09 11:20:05.407  - �[32minfo�[39m: host.SERVER Restart adapter system.adapter.mqtt.0 because enabled

Bug?

Ich nutzte mehrere Iobroker in einem Netzwerk.
Diese tauschen die Daten über mqtt mit einem übergeordneten System.

Wenn ich auf iobroker1 den mqtt.1 installiere funktioniert alles

Wenn ich nun auf der iobroker2 ebenfalls eine Instanz des mqtt installiere bekomme ich in der 2.04 und 2.10 Abbruchsfehler.

Installiere ich aber einen 2te Instanz also den mqtt.2 und lösche danach den mqtt.1 geht alles.

Aktuell bin ich bei iobroker4 und muss damit auch 4 mqtt Instanzen installieren, dass es funktioniert.

Gibt es hier eine andere Lösung`?

commands are not transmitted

after my update to 1.5.11 mqtt does not react anymore. The adapter connects perfectly, but switching process are not transmitted. Does anyone have an idea or the same problem?

Adapter is not able to send state twice even if the state has been changed by a third party application

Adapter is not able to send state twice even if the state has been changed by a third party application.

Scenario:
IOBroker send state /Light=On with ack=false
Third party appl send state /Light=Off
IOBroker receive state /Light=Off sent by third party appl with ack=true
IOBroker send again state /Light=On with ack=false -> And here no message is send anymore

I think the saving of the old state is wrongly placed. It should be done before the if statement, see below.
This guarantees that even states with ack=true are recorded and in the following old state is different to the new state and the message is send again.

Original Code in main.js:
adapter.on('stateChange', ...)
...
if ((adapter.config.sendAckToo || !state.ack) && !messageboxRegex.test(id)) {
const oldVal = states[id] ? states[id].val : null;
const oldAck = states[id] ? states[id].ack : null;
states[id] = state;
...

Fix, works for me:
adapter.on('stateChange', ...)
...
var oldVal = states[id] ? states[id].val : null;
var oldAck = states[id] ? states[id].ack : null;
states[id] = state;
if ((adapter.config.sendAckToo || !state.ack) && !messageboxRegex.test(id)) {
...

Websocket-Verbindung mit PAHO (mqttws31.js) crasht Adapter Version 2.1.0

Eine Verbindung über Javascript-Websocket per PAHO von einer Webseite aus:

client = new Paho.MQTT.Client("192.168.178.101", Number(1884), "/ws", "LABHTML");
crasht den Adapter ab Version 2.1.0 mit folgenden Fehlermeldungen:

iobroker:

mqtt.0 2019-07-16 19:13:20.566 info Starting MQTT -WebSocket' server on port 1884
mqtt.0 2019-07-16 19:13:20.564 info Starting MQTT ' server on port 1883
mqtt.0 2019-07-16 19:13:19.588 info starting. Version 2.1.0 in /opt/iobroker/node_modules/iobroker.mqtt, node: v8.16.0
host.ioBroker-RasPi 2019-07-16 19:13:18.220 info instance system.adapter.mqtt.0 started with pid 2957
host.ioBroker-RasPi 2019-07-16 19:12:48.208 info Restart adapter system.adapter.mqtt.0 because enabled
host.ioBroker-RasPi 2019-07-16 19:12:48.208 error instance system.adapter.mqtt.0 terminated with code 0 (OK)
host.ioBroker-RasPi 2019-07-16 19:12:48.207 error Caught by controller[0]: at Connection.emit (events.js:211:7)
host.ioBroker-RasPi 2019-07-16 19:12:48.207 error Caught by controller[0]: at emitOne (events.js:116:13)
host.ioBroker-RasPi 2019-07-16 19:12:48.207 error Caught by controller[0]: at Object.onceWrapper (events.js:315:30)
host.ioBroker-RasPi 2019-07-16 19:12:48.207 error Caught by controller[0]: at Connection. (/opt/iobroker/node_modules/iobroker.mqtt/node_modules/mqtt-connection/connection.js:53:12)
host.ioBroker-RasPi 2019-07-16 19:12:48.206 error Caught by controller[0]: at Connection.emit (events.js:211:7)
host.ioBroker-RasPi 2019-07-16 19:12:48.206 error Caught by controller[0]: at emitOne (events.js:116:13)
host.ioBroker-RasPi 2019-07-16 19:12:48.206 error Caught by controller[0]: at Connection.emitPacket (/opt/iobroker/node_modules/iobroker.mqtt/node_modules/mqtt-connection/connection.js:10:8)
host.ioBroker-RasPi 2019-07-16 19:12:48.206 error Caught by controller[0]: at Connection.emit (events.js:211:7)
host.ioBroker-RasPi 2019-07-16 19:12:48.205 error Caught by controller[0]: at emitOne (events.js:116:13)
host.ioBroker-RasPi 2019-07-16 19:12:48.204 error Caught by controller[0]: at Connection.client.on.options (/opt/iobroker/node_modules/iobroker.mqtt/lib/server.js:750:30)
host.ioBroker-RasPi 2019-07-16 19:12:48.199 error Caught by controller[0]: TypeError: stream.setTimeout is not a function
mqtt.0 2019-07-16 19:12:47.641 error TypeError: stream.setTimeout is not a function at Connection.client.on.options (/opt/iobroker/node_modules/iobroker.mqtt/lib/server.js:750:30) at emitOne (events.js:116:13) at Connection.e
mqtt.0 2019-07-16 19:12:47.640 error uncaught exception: stream.setTimeout is not a function
mqtt.0 2019-07-16 19:12:47.639 info Client [MQTTTEST] connected with secret 1563297167353_5931
mqtt.0 2019-07-16 19:12:20.580 info Starting MQTT -WebSocket' server on port 1884
mqtt.0 2019-07-16 19:12:20.578 info Starting MQTT ' server on port 1883
mqtt.0 2019-07-16 19:12:19.496 info starting. Version 2.1.0 in /opt/iobroker/node_modules/iobroker.mqtt, node: v8.16.0
host.ioBroker-RasPi 2019-07-16 19:12:18.236 info instance system.adapter.mqtt.0 started with pid 1758

Fehlermeldung des Browsers:

onConnectionLost:AMQJS0008I Socket closed.

Per pubsubclient auf einem ESP8266 läuft alles probelmlos.

Mit den MQTT-Adaptern Version 1.5 - 2.04 funktioniert ebenfalls alles reibungslos.

Nur mit Version 2.1.0 scheint es bei paho.js/mqttws311.js und Websockets zum Absturz des Adapters zu kommen.

TEST: In das fiddle-Beispiel (http://jsfiddle.net/gLBsu/3/) oben lokale MQTT-Broker IP eingeben und auf Run und dann den Button "1. CONNECT" drücken. iobroker mit 2.1.0 MQTT Broker meldet im Log obigen Fehler und verwährt Verbindung.

Mehr Infos und Verifikation hier: https://forum.iobroker.net/topic/23791/mqtt-1-5-funktioniert-bei-mir-nicht-mehr

Wäre für Hilfe dankbar.

Hoffe, ich habe keine wichtigen Infos ausgelassen.

Interface

I have ioBroker running on a Pi which is connected via LAN (eth0 - 192.168.1.0) as well as WLAN (wlan0 - 192.168.3.0). If I establish an MQTT connection to the ioBroker via 'ESP Easy', this only works via the LAN network. But I want to set the ESP to 192.168.3.0. And this network has no access to 192.168.1.0.

I suspect that the MQTT adapter will automatically use eth0 if present and will not pay attention to the other interfaces. I ask for configuration or monitor all interfaces. See also https://forum.iobroker.net/viewtopic.php?f=20&t=18957


Ich habe ioBroker auf einem Pi laufen der sowohl per LAN (eth0 - 192.168.1.0) als auch über WLAN (wlan0 - 192.168.3.0) angebunden ist. Wenn ich nun mittels 'ESP Easy' eine MQTT-Verbindung zum ioBroker herstelle, dann funktioniert das nur über das LAN-Netz. Ich möchte aber die ESP ins 192.168.3.0 setzen. Und dieses Netz hat keinen Zugriff auf 192.168.1.0.

Ich vermute, dass der MQTT-Adapter automatisch eth0 verwendet wenn vorhanden und nicht mehr auf die anderen Interfaces achtet. Bitte um Konfigurationsmöglichkeit oder alle Interfaces überwachen. Siehe auch https://forum.iobroker.net/viewtopic.php?f=20&t=18957

MQTT Adapter crash

Moin mein MQTT Adapter bekommt ein crash wenn sich ein bestimmter controller anmeldet:

host.ioBroker | 2017-12-05 18:57:16.429 | info | Restart adapter system.adapter.mqtt.0 because enabled
-- | -- | -- | --
host.ioBroker | 2017-12-05 18:57:16.429 | error | instance system.adapter.mqtt.0 terminated with code 0 (OK)
host.ioBroker | 2017-12-05 18:57:16.429 | error | Caught by controller[0]: at DestroyableTransform.onreadable (/opt/iobroker/node_modules/duplexify/index.js:127:10)
host.ioBroker | 2017-12-05 18:57:16.429 | error | Caught by controller[0]: at Connection.Duplexify._forward (/opt/iobroker/node_modules/duplexify/index.js:163:26)
host.ioBroker | 2017-12-05 18:57:16.429 | error | Caught by controller[0]: at Connection.Readable.push (/opt/iobroker/node_modules/readable-stream/lib/_stream_readable.js:157:10)
host.ioBroker | 2017-12-05 18:57:16.429 | error | Caught by controller[0]: at readableAddChunk (/opt/iobroker/node_modules/readable-stream/lib/_stream_readable.js:198:18)
host.ioBroker | 2017-12-05 18:57:16.429 | error | Caught by controller[0]: at Connection.emit (events.js:188:7)
host.ioBroker | 2017-12-05 18:57:16.429 | error | Caught by controller[0]: at emitOne (events.js:96:13)
host.ioBroker | 2017-12-05 18:57:16.429 | error | Caught by controller[0]: at Connection.emitPacket (/opt/iobroker/node_modules/mqtt-connection/connection.js:10:8)
host.ioBroker | 2017-12-05 18:57:16.429 | error | Caught by controller[0]: at Connection.emit (events.js:188:7)
host.ioBroker | 2017-12-05 18:57:16.429 | error | Caught by controller[0]: at emitOne (events.js:96:13)
host.ioBroker | 2017-12-05 18:57:16.429 | error | Caught by controller[0]: at Connection. (/opt/iobroker/node_modules/iobroker.mqtt/lib/server.js:383:57)
host.ioBroker | 2017-12-05 18:57:16.428 | error | Caught by controller[0]: TypeError: Cannot read property 'toString' of undefined
mqtt.0 | 2017-12-05 18:57:15.919 | debug | onStateChange mqtt.0.info.connection: {"val":"","ack":true,"ts":1512496635917,"q":0,"from":"system.adapter.mqtt.0","lc":1512496635917}
mqtt.0 | 2017-12-05 18:57:15.919 | debug | stateChange mqtt.0.info.connection: {"val":"","ack":true,"ts":1512496635917,"q":0,"from":"system.adapter.mqtt.0","lc":1512496635917}
mqtt.0 | 2017-12-05 18:57:15.919 | debug | stateChange mqtt.0.last.will: {"val":"[object Object]","ack":true,"ts":1512496635917,"q":0,"from":"system.adapter.mqtt.0","lc":1512322544172}
mqtt.0 | 2017-12-05 18:57:15.918 | debug | onStateChange mqtt.0.info.connection: {"val":"Kueche1","ack":true,"ts":1512496635916,"q":0,"from":"system.adapter.mqtt.0","lc":1512496635916}
mqtt.0 | 2017-12-05 18:57:15.918 | debug | stateChange mqtt.0.info.connection: {"val":"Kueche1","ack":true,"ts":1512496635916,"q":0,"from":"system.adapter.mqtt.0","lc":1512496635916}
mqtt.0 | 2017-12-05 18:57:15.917 | debug | stateChange mqtt.0.last.will: {"val":"[object Object]","ack":true,"ts":1512496635915,"q":0,"from":"system.adapter.mqtt.0","lc":1512322544172}
mqtt.0 | 2017-12-05 18:57:15.916 | info | Client [Kueche1] closed
mqtt.0 | 2017-12-05 18:57:15.916 | info | Client [Kueche2] closed
mqtt.0 | 2017-12-05 18:57:15.916 | info | Client [Controller_4] closed
mqtt.0 | 2017-12-05 18:57:15.916 | error | TypeError: Cannot read property 'toString' of undefined at Connection. (/opt/iobroker/node_modules/iobroker.mqtt/lib/server.js:383:57) at emitOne (events.js:96:13) at Connection
mqtt.0 | 2017-12-05 18:57:15.916 | error | uncaught exception: Cannot read property 'toString' of undefined
mqtt.0 | 2017-12-05 18:57:04.838 | debug | onStateChange mqtt.0.info.connection: {"val":"Kueche1,Kueche2","ack":true,"ts":1512496624835,"q":0,"from":"system.adapter.mqtt.0","lc":1512496624835}
mqtt.0 | 2017-12-05 18:57:04.838 | debug | stateChange mqtt.0.info.connection: {"val":"Kueche1,Kueche2","ack":true,"ts":1512496624835,"q":0,"from":"system.adapter.mqtt.0","lc":1512496624835}
mqtt.0 | 2017-12-05 18:57:04.837 | debug | onStateChange mqtt.0.info.connection: {"val":"Kueche1","ack":true,"ts":1512496624832,"q":0,"from":"system.adapter.mqtt.0","lc":1512496624832}
mqtt.0 | 2017-12-05 18:57:04.837 | debug | stateChange mqtt.0.info.connection: {"val":"Kueche1","ack":true,"ts":1512496624832,"q":0,"from":"system.adapter.mqtt.0","lc":1512496624832}


Please check ioBroker.mqtt with js-controller 2.0

Hi,

the new js-controller 2.0 will come into latest repository in the next days and we want to make sure that all adapters are working well. We already did a 2 weeks Beta test and so some adapter were aleady checked and some needed slight adjustments.

You can find more information in ioBroker/ioBroker.js-controller#482 and in the ioBroker Forum. If you have more technical questions please write in the referenced issue or in the Developer thread please. General questions are best in the genral thread.

Please update your systems to js-controller 2.0 and check your adapter.

Please close this issue once you have checked your adapter or received successfull reports from users.

Thank you very much for your support. Please contact us in the other Threads or Forum on any question.

Neuinitialisierung MQTT-Objekte

Nach einem Neustart vom MQTT Adapter werden die Objekte neu angelegt. Dies führt dazu, dass Konfigurationen hinsichtlich Archivierung mit den Default-Werten überschrieben werden.

No PUBACK for Publish messages with QoS>0

I use a MQTT client from this project which uses QoS=1. The door sensor hardware is battery powered and therefore the PUBACK message from server is used to enter the MCU suspend mode. Unfortunately the ioBroker MQTT server does not send the PUBACK reply (reported by someone else as well).
With the mosquitto broker it works.

I've have looked into the MQTT server code and didn't find the PUBACK answer handling for Publish messages with QoS>0. I would expect this handling in server.js, function receivedTopic() or any sub-function.
The only PUBACK code is in writeToStream.js, but if I understand it right, the task of this file is only "data conversion", not "logical" message handling.

Environment:

  • ioBroker 1.2.3
  • MQTT 1.4.2 (same with 1.4.1)
  • Admin 3.2.0 (same with 2.0.9)

Greetings,
endym

Subscribe Patterns does not work

Description

Adapter version: 2.0.3

Using the adapter as Client / Subscriber. The Subscribe Patterns is either set to empty or to a not existing topic.
MQTT Server is Mosquitto on a remote host.

Actual behavior:

The adapter subscribes to every topic published by Mosquitto.

Expected behavior

Do not subscribe to any topic.

Invalid protocol "ioBroker.mqtt.0"

Hallo,

im ioBroker.mqtt Clientmodus (aktuell 1.0.2) gibt es anscheinend eine Inkompatibilität zu mosquitto.
Bei mosquitto 1.3.4 und mosquitto 1.4.8 wird das Log mit den folgenden Meldungen geflutet:

Invalid protocol "ioBroker.mqtt.0" in CONNECT from 192.168.1.88.
Socket error on client <unknown>, disconnecting.

Alle anderen MQTT-clients in meinem Netzwerk (Node-RED, homegear, OpenHAB, domoticz) funktionieren ohne Probleme.

Die master-Version habe ich noch nicht getestet, da mein BananaPi keine Entwicklertools installiert hat.

Gruß

Christian

MQTT uses up all memory

ioBroker Admin 3.6.0
js-Controller 1.4.2
MQTT Broker 2.0.4

ioBroker runs on a Odroid C2 with 2GB RAM. There are three MQTT clients who send their telemetry to the broker, 2 ESP8266 with MQTT client and 1 Raspberry Pi 3B+ with Mosquitto.

After a few hours the broker sucks up all memory - it grows from around 35.5MB after restart to about 920MB. I have to restart the adapter to get back to 35.5MB. Is this normal behauviour or a memory leak/bug?

Edit:

The data packets from each client are between 20-200 bytes long and are send every 120 seconds.

MQTT Topic wird unterschiedlich gesendet

Ich hab MQTT Broker/Client als Client installiert und bei den "MQTT Einstellungen" unter "Prefix für alle Topics" iobroker/ eingestellt. "Publish nur bei Änderung" hab ich nicht ausgewählt, "Bekanntgeben eigene States beim Verbinden" schon.

Als MQTT-Server hab ich Mosquitto auf einem anderen Linuxrecher laufen und schaue dort mit "mosquitto_sub -v -t +/#" mit, was so alles an Topics daher kommt.

Nach einem Start oder Neustart werden die Topics dann in der Form "iobroker/xxx/yyy" ausgegeben, bei einem Update des zugehörigen Objects dann aber als "iobroker/iobroker/xxx/yyy".
Der Prefix wird also 2x vorgesetzt!

Wenn ich Prefix leer lasse wird übrigens immer nur "xxx/yyy" gesendet. Schaut für mich also danach aus, dass beim Posten eines Updates der Prefix 2x vorgesetzt wird, beim Bekanntgeben der States beim Verbinden aber nur 1x.

Ich hab mir mal im Verzeichnis /opt/iobroker/node_modules/iobroker.mqtt/lib die beiden Programme client.js und common.js angeschaut.

In client.js in der function send2Server wird u.a.:
convertID2topic(obj._id, null, adapter.config.prefix, adapter.namespace); aufgerufen
und später dann:
client.publish(adapter.config.prefix + topic, null);

In der function publishAllStates wird aber:
client.publish(config.prefix + id.replace(/./g, '/'), state2string(states[id].val), function (err)
verwendet.

In common.js kommt in der function convertID2topic u.a. dann:
topic = prefix + id; vor.

D.h. bei send2Server wird erst durch convertID2topic der prefix vorgesetzt und dann beim publish nochmals.
Beim publishAllStates wird aber beim client.publish die id selber verwendet.

lg, Sabine

Mqtt Clients empfangen Nachrichten von Broker ohne Subscribe pattern

Hi

Ist es normal das der Mqtt Broker Nachrichten an die Clients schickt ohne irgendwelche Subscribe pattern eingestellt zu haben. Bei einen Start des Adapters(Client) bekommen ich diese Meldung Subscribe on: "#", das Feld in den Settings ist dabei aber Leer.

Bei den Client Settings habe ich diese Einstellungen aktiviert

  • Sende auch Zustände (ack=true)
  • Bekanntgeben eigene States beim Verbinden

Am Broker ist garnichts aktivert und auch alle Felder Leer

LG

Client [...] Received pubrec on ... for unknown messageId

I'm receiving a lot of the error message stated in the title. Looking at the source code I identified

let frame = client._messages.forEach(e => e.messageId === packet.messageId);
which expects a return from forEach, which does not return anything (see
MDN web docs: Array​.prototype​.for​Each()
).

You may also see https://jsfiddle.net/bxsnp7hq/, which reproduces the current implementation.

I will pull request the change.

Cheers,
Zefau

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.