UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[Ein ehemaliger Benutzer]

@acgua

Super, vielen Dank!
Funktioniert hier einwandfrei, sauber programmiert, nur eins wird gemeldet:

Meine den hier:

Info: fully-mqtt.0 (290320) State value to set for "fully-mqtt.0.Huawei-WZDG.Info.sensorInfo" has to be stringified but received type "object"

Spoiler

```
2023-03-09 20:46:53.540  - info: host.iobroker instance system.adapter.fully-mqtt.0 started with pid 290320
2023-03-09 20:46:54.103  - debug: fully-mqtt.0 (290320) Redis Objects: Use Redis connection: 10.1.1.4:6379
2023-03-09 20:46:54.125  - debug: fully-mqtt.0 (290320) Objects client ready ... initialize now
2023-03-09 20:46:54.126  - debug: fully-mqtt.0 (290320) Objects create System PubSub Client
2023-03-09 20:46:54.127  - debug: fully-mqtt.0 (290320) Objects create User PubSub Client
2023-03-09 20:46:54.376  - debug: fully-mqtt.0 (290320) Objects client initialize lua scripts
2023-03-09 20:46:54.381  - debug: fully-mqtt.0 (290320) Objects connected to redis: 10.1.1.4:6379
2023-03-09 20:46:54.654  - debug: fully-mqtt.0 (290320) Redis States: Use Redis connection: 10.1.1.4:6379
2023-03-09 20:46:54.657  - debug: fully-mqtt.0 (290320) States create System PubSub Client
2023-03-09 20:46:54.658  - debug: fully-mqtt.0 (290320) States create User PubSub Client
2023-03-09 20:46:54.661  - debug: fully-mqtt.0 (290320) States connected to redis: 10.1.1.4:6379
2023-03-09 20:46:55.037  - info: fully-mqtt.0 (290320) starting. Version 0.0.1-alpha (non-npm: Acgua/ioBroker.fully-mqtt#9f946a67a951d57ba770ec08be30eedb3c0d711d) in /opt/iobroker/node_modules/iobroker.fully-mqtt, node: v16.19.1, js-controller: 4.0.24
2023-03-09 20:46:55.059  - debug: fully-mqtt.0 (290320) Final Config: {"name":"Huawei-WZDG","id":"Huawei-WZDG","ip":"10.1.1.54","useMQTT":true,"restProtocol":"http","restPort":2323,"restPassword":"Winston2006","lastSeen":0,"isAlive":false}
2023-03-09 20:46:55.060  - info: fully-mqtt.0 (290320) 🗸​ Config of Huawei-WZDG (10.1.1.54) successfully verified.
2023-03-09 20:46:55.061  - debug: fully-mqtt.0 (290320) Adapter settings successfully verified and initialized.
2023-03-09 20:46:55.067  - debug: fully-mqtt.0 (290320) Start main() - Huawei-WZDG (10.1.1.54)…
2023-03-09 20:46:55.068  - info: fully-mqtt.0 (290320) [MQTT]🚀​ Server started and listening on port 1888
2023-03-09 20:46:59.959  - debug: fully-mqtt.0 (290320) [MQTT] client.conn.remoteAddress = "::ffff:10.1.1.54" - Huawei-WZDG
2023-03-09 20:46:59.961  - info: fully-mqtt.0 (290320) [MQTT] Client Huawei-WZDG (10.1.1.54) trys to authenticate...
2023-03-09 20:46:59.961  - info: fully-mqtt.0 (290320) [MQTT]🔑​ Client Huawei-WZDG (10.1.1.54) authenticated successfully.
2023-03-09 20:46:59.963  - info: fully-mqtt.0 (290320) [MQTT] Huawei-WZDG is alive.
2023-03-09 20:46:59.964  - debug: fully-mqtt.0 (290320) [MQTT] Client Huawei-WZDG (10.1.1.54) connected to broker a621d092-8b12-4b18-b371-f5bbb3e5d489
2023-03-09 20:46:59.964  - info: fully-mqtt.0 (290320) [MQTT]🔗​ Client Huawei-WZDG (10.1.1.54) successfully connected.
2023-03-09 20:47:00.146  - debug: fully-mqtt.0 (290320) [MQTT] Client Huawei-WZDG = Huawei-WZDG = 10.1.1.54
2023-03-09 20:47:00.146  - debug: fully-mqtt.0 (290320) [MQTT]📡​ Huawei-WZDG published info, topic: fully/deviceInfo/e494e50e-8038fd2e
2023-03-09 20:47:00.146  - debug: fully-mqtt.0 (290320) [MQTT] Huawei-WZDG: Creating info objects (if not yet existing)
2023-03-09 20:47:00.167  - info: fully-mqtt.0 (290320) State value to set for "fully-mqtt.0.Huawei-WZDG.Info.sensorInfo" has to be stringified but received type "object"
2023-03-09 20:47:33.794  - debug: fully-mqtt.0 (290320) [MQTT]📡​ Huawei-WZDG published info, topic: fully/deviceInfo/e494e50e-8038fd2e
2023-03-09 20:47:33.804  - info: fully-mqtt.0 (290320) State value to set for "fully-mqtt.0.Huawei-WZDG.Info.sensorInfo" has to be stringified but received type "object"
2023-03-09 20:48:19.617  - debug: fully-mqtt.0 (290320) [MQTT]📡​ Huawei-WZDG published info, topic: fully/deviceInfo/e494e50e-8038fd2e
2023-03-09 20:48:19.627  - info: fully-mqtt.0 (290320) State value to set for "fully-mqtt.0.Huawei-WZDG.Info.sensorInfo" has to be stringified but received type "object"
2023-03-09 20:49:00.217  - debug: fully-mqtt.0 (290320) [MQTT]📡​ Huawei-WZDG published info, topic: fully/deviceInfo/e494e50e-8038fd2e
2023-03-09 20:49:00.282  - info: fully-mqtt.0 (290320) State value to set for "fully-mqtt.0.Huawei-WZDG.Info.sensorInfo" has to be stringified but received type "object"
2023-03-09 20:49:33.914  - debug: fully-mqtt.0 (290320) [MQTT]📡​ Huawei-WZDG published info, topic: fully/deviceInfo/e494e50e-8038fd2e
2023-03-09 20:49:33.922  - info: fully-mqtt.0 (290320) State value to set for "fully-mqtt.0.Huawei-WZDG.Info.sensorInfo" has to be stringified but received type "object"
2023-03-09 20:50:19.720  - debug: fully-mqtt.0 (290320) [MQTT]📡​ Huawei-WZDG published info, topic: fully/deviceInfo/e494e50e-8038fd2e
2023-03-09 20:50:19.729  - info: fully-mqtt.0 (290320) State value to set for "fully-mqtt.0.Huawei-WZDG.Info.sensorInfo" has to be stringified but received type "object"
2023-03-09 20:51:00.350  - debug: fully-mqtt.0 (290320) [MQTT]📡​ Huawei-WZDG published info, topic: fully/deviceInfo/e494e50e-8038fd2e
2023-03-09 20:51:00.357  - info: fully-mqtt.0 (290320) State value to set for "fully-mqtt.0.Huawei-WZDG.Info.sensorInfo" has to be stringified but received type "object"
2023-03-09 20:51:00.350  - debug: fully-mqtt.0 (290320) [MQTT]📡​ Huawei-WZDG published info, topic: fully/deviceInfo/e494e50e-8038fd2e
2023-03-09 20:51:00.357  - info: fully-mqtt.0 (290320) State value to set for "fully-mqtt.0.Huawei-WZDG.Info.sensorInfo" has to be stringified but received type "object"
2023-03-09 20:51:33.996  - debug: fully-mqtt.0 (290320) [MQTT]📡​ Huawei-WZDG published info, topic: fully/deviceInfo/e494e50e-8038fd2e
2023-03-09 20:51:34.006  - info: fully-mqtt.0 (290320) State value to set for "fully-mqtt.0.Huawei-WZDG.Info.sensorInfo" has to be stringified but received type "object"
2023-03-09 20:51:33.996  - debug: fully-mqtt.0 (290320) [MQTT]📡​ Huawei-WZDG published info, topic: fully/deviceInfo/e494e50e-8038fd2e
2023-03-09 20:51:34.006  - info: fully-mqtt.0 (290320) State value to set for "fully-mqtt.0.Huawei-WZDG.Info.sensorInfo" has to be stringified but received type "object"

```


[/s]

[Homoran]

@ilovegym muss das log sooooo groß sein?
es lähmt die ganze Seite!

Wenn ja, dann ja!

[Ein ehemaliger Benutzer]

@homoran

Sorry hab ausversehen alles kopiert.. aber jetzt geändert..

[Homoran]

@ilovegym komme jetzt auch wieder auf die Seite!
Danke

[Acgua]

@ilovegym said in TEST - Adapter Fully Browser mit MQTT (0.0.1-alpha):

Super, vielen Dank!
Funktioniert hier einwandfrei, sauber programmiert, nur eins wird gemeldet:

Cool, das freut mich :-)

Info: fully-mqtt.0 (290320) State value to set for "fully-mqtt.0.Huawei-WZDG.Info.sensorInfo" has to be stringified but received type "object"

1. Kannst du bitte in den Objekten bei fully-mqtt.0.Huawei-WZDG.Info.sensorInfo rechts auf den Stift klicken und dann posten was angezeigt wird.
2. MQTT hast du aktiviert und läuft, richtig? Ich frage, weil ansonsten die Info via REST API kommt...

[Ein ehemaliger Benutzer]

@acgua

Hier die info vom Objekt und ja, mqtt ist aktiv, im Adapter und im Fully.

Spoiler

{
  "type": "state",
  "common": {
    "name": "Info: sensorInfo",
    "type": "object",
    "role": "value",
    "read": true,
    "write": false
  },
  "native": {},
  "from": "system.adapter.fully-mqtt.0",
  "user": "system.user.admin",
  "ts": 1678390504642,
  "_id": "fully-mqtt.0.Huawei-WZDG.Info.sensorInfo",
  "acl": {
    "object": 1636,
    "state": 1636,
    "owner": "system.user.admin",
    "ownerGroup": "system.group.administrator"
  }
}

[mrjeschke]

Läuft bis jetzt bei mir auch sehr gut.
Alles wird vermutlich nicht funktionieren, da ich eine Show15 habe.
Fehlermeldungen bekomme ich noch wenn ich Datenpunkte unter Commands ändere.
Danach stet im DP ein true und es kommen die Fehler.

State value to set for "fully-mqtt.0.Show15.Commands.setAudioVolume" has to be type "number" but received type "boolean"
State value to set for "fully-mqtt.0.Show15.Commands.textToSpeech" has to be type "string" but received type "boolean"
State value to set for "fully-mqtt.0.Show15.Commands.loadURL" has to be type "string" but received type "boolean"

[arteck]

@acgua jetzt doch ein extra Adapter .. ?? dann motte ich meinen ein ..

[Ein ehemaliger Benutzer]

@arteck hmmf dachte ihr haettet euch abgesprochen.. aber sieh's mal so: da hast du weniger Support-Arbeit.. :)

Zigbee fordert doch genug nerven.. oder :-)

[Ein ehemaliger Benutzer]

@acgua

ab und zu gibts n keep alive timeout, komischerweise bei den Tablets auch, die per LAN verbunden sind.. kann ich da das Timeout irgendwo einstellen??

Spoiler

2023-03-10 11:48:30.069  - warn: fully-mqtt.0 (1061251) [MQTT] Huawei-FlurOG is not alive!
2023-03-10 11:48:30.717  - error: fully-mqtt.0 (1061251) [MQTT]🔥 Client error - keep alive timeout
2023-03-10 11:48:30.718  - warn: fully-mqtt.0 (1061251) [MQTT] Client Huawei-FlurOG disconnected.
2023-03-10 11:48:34.700  - info: lightcontrol.1 (1566) [ Controller ] Reaching, Group="Muellanzeige" Property="actualLux" NewVal="137.87", OldVal=137.87"
2023-03-10 11:48:42.252  - info: fully-mqtt.0 (1061251) [MQTT] Client Huawei-FlurOG (10.1.1.56) trys to authenticate...
2023-03-10 11:48:42.253  - info: fully-mqtt.0 (1061251) [MQTT]🔑 Client Huawei-FlurOG (10.1.1.56) authenticated successfully.
2023-03-10 11:48:42.253  - info: fully-mqtt.0 (1061251) [MQTT] Huawei-FlurOG is alive.
2023-03-10 11:48:42.253  - info: fully-mqtt.0 (1061251) [MQTT]🔗 Client Huawei-FlurOG (10.1.1.56) successfully connected.

Hier meine Config vom Adapter:

oder kann man das im Fullybrowser einstellen? Hab da nix gefunden..

[BananaJoe]

@ilovegym leck mich fett, du bist aber gut mit Anzeigen ausgestattet ... Gutes Argument wenn meine Frau mal wieder meint ich würde überteiben ...

[Ein ehemaliger Benutzer]

@bananajoe Oehm, hat nicht alles auf den Screen gepasst, hab im Haus paarundzwanzig Tablets verstreut.. die meisten Android mit Fully, natürlich auch n paar IPads und 5x 55" TV und n 86" fuer die Dashboards

Die Tablets waren am Anfang zur Steuerung gedacht, genutzt wird ziemlich genau davon eins.. die anderen zeigen nur die Grafana-Playlist.. sorry, hab sonst kein Hobby.. :)

[Acgua]

@arteck said in TEST - Adapter Fully Browser mit MQTT (0.0.1-alpha):

jetzt doch ein extra Adapter .. ?? dann motte ich meinen ein ..

Nein, bitte nicht einmotten :-) Ich habe jetzt erst mal einen separaten Adapter gebaut, da es doch sehr umfangreich wurde wegen MQTT etc. Auch damit erst mal getestet werden kann, Fehler behoben werden können, ggf. noch paar Features einbauen falls notwendig/sinnvoll. Sobald stabil, dann am liebsten in deinen Adapter "verschmelzen" unter https://github.com/arteck/ioBroker.fullybrowser. Habe auch versucht, soweit abwärtskompatibel zu sein, lediglich fehlen noch paar Zeichen Code, um die alten Settings in die vom neuen Adapter zu überführen.

@ilovegym und @mrjeschke
Danke für eure Rückmeldungen, schaue ich mir alsbald an, nur heute komme ich nicht dazu.

[Acgua]

@mrjeschke said in TEST - Adapter Fully Browser mit MQTT (0.0.1-alpha):

Alles wird vermutlich nicht funktionieren, da ich eine Show15 habe.

Eigentlich sollte auch in Verbindung mit Show15 der Adapter korrekt laufen, sofern halt die Fully App das unterstützt... ;-)

@mrjeschke said in TEST - Adapter Fully Browser mit MQTT (0.0.1-alpha):

Fehlermeldungen bekomme ich noch wenn ich Datenpunkte unter Commands ändere.
Danach stet im DP ein true und es kommen die Fehler.

Danke für deine Rückmeldung, war ein Bug und ist sollte nun behoben sein.
Bitte Adapter noch mal neu installieren von URL (https://github.com/Acgua/ioBroker.fully-mqtt)

[Acgua]

@ilovegym said in TEST - Adapter Fully Browser mit MQTT (0.0.1-alpha):

Funktioniert hier einwandfrei, sauber programmiert, nur eins wird gemeldet:
Meine den hier:
Info: fully-mqtt.0 (290320) State value to set for "fully-mqtt.0.Huawei-WZDG.Info.sensorInfo" has to be stringified but received type "object"

Danke für die Rückmeldung. Hier beschrieben:
@paul53 said in Fehler nach update js-controller 3.3.9:

Ab Version 3.3 des js-controllers sollen keine Objekte / Arrays mehr in Datenpunkte geschrieben werden, sondern nur noch per JSON.stringify(obj) gewandelte Objekte. Diese Info-Logs sollen die Adapter-Entwickler informieren, dies anzupassen.
Wenn die Logs stören, stelle die Log-Stufe des js-controllers in der Datei /opt/iobroker/iobroker-data/iobroker.json auf "warn" (anschließend ioBroker neu starten).

Ich mache jetzt

const newVal = typeof infoObj[key] === 'object' ? JSON.stringify(infoObj[key]) : infoObj[key];

Ich verstehe zwar diese ioBroker-Einschränkung nicht wirklich, aber nun eingebaut :-)
Bitte Adapter noch mal neu installieren von URL (https://github.com/Acgua/ioBroker.fully-mqtt) und testen.

[Acgua]

@ilovegym said in TEST - Adapter Fully Browser mit MQTT (0.0.1-alpha):

ab und zu gibts n keep alive timeout, komischerweise bei den Tablets auch, die per LAN verbunden sind.. kann ich da das Timeout irgendwo einstellen??

2023-03-10 11:48:30.069  - warn: fully-mqtt.0 (1061251) [MQTT] Huawei-FlurOG is not alive!
2023-03-10 11:48:30.717  - error: fully-mqtt.0 (1061251) [MQTT]🔥 Client error - keep alive timeout
2023-03-10 11:48:30.718  - warn: fully-mqtt.0 (1061251) [MQTT] Client Huawei-FlurOG 
2023-03-10 11:48:42.253  - info: fully-mqtt.0 (1061251) [MQTT]🔑 Client Huawei-FlurOG (10.1.1.56) authenticated successfully.
2023-03-10 11:48:42.253  - info: fully-mqtt.0 (1061251) [MQTT] Huawei-FlurOG is alive.
2023-03-10 11:48:42.253  - info: fully-mqtt.0 (1061251) [MQTT]🔗 Client Huawei-FlurOG (10.1.1.56) successfully connected.

(hier stand vorher eine andere, falsche, Antwort von mir)

Hier hat sich tatsächlich der Client, also der Fully Browser und/oder das Tablet, verabschiedet.
Das kann ich nicht wirklich beeinflussen mit dem Adapter.
Kommt das öfter vor, und in welchem Abstand in Sekunden wird "is not alive" -> "is alive" angezeigt im Log (also jeweils separate Log-Zeilen), so im Durchschnitt?

[Ein ehemaliger Benutzer]

@acgua sagte in TEST - Adapter Fully Browser mit MQTT (0.0.1-alpha):

Hier hat sich tatsächlich der Client, also der Fully Browser und/oder das Tablet, verabschiedet.
Das kann ich nicht wirklich beeinflussen mit dem Adapter.
Kommt das öfter vor, und in welchem Abstand in Sekunden wird "is not alive" -> "is alive" angezeigt im Log (also jeweils separate Log-Zeilen), so im Durchschnitt?

hmm das ist komisch, denn ich komme ganz normal auf die Gui von Fullybrowser, wenn das kommt. . und dann ist er ja nach 12 Sek. auch wieder fuer den Adapter erreichbar.. hier sieht es mir nach einem timeout problem aus.. ich hab zeitgleich mal n ping durchlaufen lassen, da gibts keine breaks/interrupts und auch keine lost packets oder so..
Was mich wundert, es sind bei der Meldung immer 12sek, dann ist er wieder erreichbar..
naja, ich behalts mal im Auge.. denn:
98% meiner Tablets schalten sich um 23.00 Uhr aus, und um 5 / 7 uhr morgens wieder ein, in der zwischenzeit sind die natuerlich offline.
Auch da sollte der Adapter das abkoennen, oder das log zu zu pflastern.. kannste das vielleicht so machen, wie beim mqtt oder sonoff adapter, dass man in den Instanzen sieht, welcher client verbunden ist?

Dann hat der Adapter noch Probleme, die Datenpunkte im '/Info directory anzulegen, das geht meist erst, wenn ich mqtt im Adapter ausschalte, dann legt er alle Datenpunkte an, schalte ich dann mqtt ein, funktionierts...

Hab jetzt den alten Adapter geloscht, auch die Datenpunkte, neu von Git installiert, die Konfig importiert, und alles neu anlegen lassen.
Es kommen immer noch Warnings mit

Spoiler

2023-03-12 09:41:26.786  - warn: fully-mqtt.0 (2973073) State "fully-mqtt.0.Huawei-BadDG.Info.deviceId" has no existing object, this might lead to an error in future versions
2023-03-12 09:41:26.786  - warn: fully-mqtt.0 (2973073) State "fully-mqtt.0.Huawei-BadDG.Info.longitude" has no existing object, this might lead to an error in future versions
2023-03-12 09:41:26.786  - warn: fully-mqtt.0 (2973073) State "fully-mqtt.0.Huawei-BadDG.Info.latitude" has no existing object, this might lead to an error in future versions
2023-03-12 09:41:26.787  - warn: fully-mqtt.0 (2973073) State "fully-mqtt.0.Huawei-BadDG.Info.version" has no existing object, this might lead to an error in future versions
2023-03-12 09:41:26.787  - warn: fully-mqtt.0 (2973073) State "fully-mqtt.0.Huawei-BadDG.Info.versionCode" has no existing object, this might lead to an error in future versions
2023-03-12 09:41:26.787  - warn: fully-mqtt.0 (2973073) State "fully-mqtt.0.Huawei-BadDG.Info.model" has no existing object, this might lead to an error in future versions
2023-03-12 09:41:26.787  - warn: fully-mqtt.0 (2973073) State "fully-mqtt.0.Huawei-BadDG.Info.manufacturer" has no existing object, this might lead to an error in future versions
2023-03-12 09:41:26.787  - warn: fully-mqtt.0 (2973073) State "fully-mqtt.0.Huawei-BadDG.Info.SDK" has no existing object, this might lead to an error in future versions
2023-03-12 09:41:26.787  - warn: fully-mqtt.0 (2973073) State "fully-mqtt.0.Huawei-BadDG.Info.foreground" has no existing object, this might lead to an error in future versions
2023-03-12 09:41:26.788  - warn: fully-mqtt.0 (2973073) State "fully-mqtt.0.Huawei-BadDG.Info.appStartTime" has no existing object, this might lead to an error in future versions
2023-03-12 09:41:26.789  - warn: fully-mqtt.0 (2973073) State "fully-mqtt.0.Huawei-BadDG.Info.currentPageUrl" has no existing object, this might lead to an error in future versions

[Acgua]

@ilovegym
Nochmals vielen Dank fürs Testen!

Info-Datenpunkte

Das war ein Bug, wenn mehrere Tablets konfiguriert sind und ist nun behoben auf Github, werden nun also für alle Tablets sauber angelegt.

MQTT Keep Alive Timeout

Ich hatte zunächst mit einem Lenovo-Tablet getestet, da kam das nie. Aber beim Testen mit einem Huawei-Tablet habe ich das auch schon mal gesehen jetzt.
Was hier passiert: Der Aedes MQTT Server bekommt einen "client error" Event gemeldet vom Tablet.
Aktuell wird im Adapter bei einem solchen Client Error sofort ein Error "[MQTT] Client error - ..." ausgegeben und der Status des Tablets auf "not alive" gesetzt.
Ich überlege, hier "keep alive timeout" Error abzufangen und nicht gleich einen Error auszugeben. Meldet sich das Tablet länger nicht, geht es eh auf "not alive".
Hab bei mir auch kurzzeitig ein "Huawei: Client error - read ECONNRESET" Error, und paar Sekunden später ist das Tablet aber wieder verbunden.
Ich bleib dran und verbessere das mit Logausgaben und Fehler abfangen.

Zu "welcher Client verbunden ist"

@ilovegym said in TEST - Adapter Fully Browser mit MQTT (0.0.1-alpha):

98% meiner Tablets schalten sich um 23.00 Uhr aus, und um 5 / 7 uhr morgens wieder ein, in der zwischenzeit sind die natuerlich offline.
Auch da sollte der Adapter das abkoennen, oder das log zu zu pflastern.. kannste das vielleicht so machen, wie beim mqtt oder sonoff adapter, dass man in den Instanzen sieht, welcher client verbunden ist?

Absolut muss ein Adapter das abkönnen :)
Wie meinst du das mit den "in den Instanzen sehen"?
Derzeit wird der Status für jedes Tablet über fully-mqtt.0.Tablet-Name.alive angezeigt. Zusätzlich geht die Adapter-Instanz von gelb auf grün, wenn alle Clients verbunden sind. Ist ein Client nicht verbunden -> gelb. (über fully-mqtt.0.info.connection).

[Acgua]

@ilovegym said in TEST - Adapter Fully Browser mit MQTT (0.0.1-alpha):

kannste das vielleicht so machen, wie beim mqtt oder sonoff adapter, dass man in den Instanzen sieht, welcher client verbunden ist?

Du meinst sowas, oder?

Ist jetzt drin.
Ebenso diese MQTT-Option. Wenn aktiviert, werden die client errors etc. nur noch als Info ausgegeben. Wenn nach einer Weile (60s + 10s) der Fully sich gar nicht mehr meldet per MQTT, wird einmalig ein "[MQTT] Tablet-Name is not alive!" ausgegeben als Warn ausgegeben, mehr nicht.

Ansonsten noch paar Fixes.

0.0.3-alpha (2023-03-12)

• (Acgua) Fix: various issues
• (Acgua) Encrypt MQTT password (#11)
• (Acgua) New: MQTT option to log client and connection errors as info and not error
• (Acgua) New: Online status for each device is now displayed in objects: e.g. 'fully-mqtt.0.Tablet-Hallway' is green with a connection icon if it is alive

[Ein ehemaliger Benutzer]

@acgua

guten Morgen,
super, die Warnings sind weg, das Log sieht jetzt sehr sauber aus, in allen Konfigurationen ( also Client and Connection enabled und auch disabled), die verschiedenen Logstufen funktionieren auch.

Was nicht geht, ist die Anzeige
https://forum.iobroker.net/assets/uploads/files/1678650418308-28617329-ad62-4cfd-8258-3e17aced1ede-image.png

bei mir sieht das im Chrome und Firefox so aus:

brauchst Du ein debug-log?