Der "Enable"-Button aktiviert/deaktiviert den Adapter und nicht das Logging.
Das sauberste m.E. wäre den Adapter umzuschreiben, sodass das Update-Intervall nicht von Cron kommt, sondern vom Adapter selbst gesteuert wird. Beim Squeezebox-Adapter funktionierts ja auch…
Ich möchte die Windgeschwindigkeiten und Sonnenstahlung feiner aufgelöst haben.
Habe vorhin nicht die ganze Log-Meldung kopiert:
` > host.ubuntuNUC 2018-04-19 10:20:04.520 info instance system.adapter.weatherunderground.0 terminated with code 0 (OK)
host.ubuntuNUC 2018-04-19 10:20:00.016 info instance system.adapter.weatherunderground.0 started with pid 27977 `
An dem Beispiel sieht man, dass der Eintrag nicht von Adapter selbst kommt, sondern vom Host. Somit greift der Loglevel für die einzelne Instanz nicht (das hatte ich vorher schon versucht).
Ich habe bei meiner Adapter-Instanz das Update-Interval auf 1 Minute gestellt. Habe ich eine Möglichkeit die LOG-Ausgaben:
` > info instance system.adapter.weatherunderground.0 terminated with code 0 (OK)
info instance system.adapter.weatherunderground.0 started with pid XXXXX `
zu unterbinden?
History hab ich immer aktiviert gehabt, oder meist du deaktiveren?
Habe die Option mal aktiviert, aber trotzdem werden die Daten im mqtt-client nicht sauber übernommen!
Im Log von Mosquitto sehe ich aber eindeutig, dass die Subscription mit QOS2 erfolgt ist:
1502773330: New connection from 127.0.0.1 on port 1883.
1502773330: New client connected from 127.0.0.1 as ioBrokerMQTT (c1, k10).
1502773330: Sending CONNACK to ioBrokerMQTT (0)
1502773330: Received SUBSCRIBE from ioBrokerMQTT
1502773330: blind_control/# (QoS 2)
1502773330: ioBrokerMQTT 2 blind_control/#
1502773330: Sending SUBACK to ioBrokerMQTT
Danach werden auch definitiv Daten an den Client gesendet und auch von diesem beantwortet, aber der Wert im Datenpunkt ändert sich nicht (moquitto-log):
1502773562: Received PUBLISH from blind_control (d0, q2, r0, m299, '/blind_control/system/laufzeit_s', ... (4 bytes))
1502773562: Sending PUBREC to blind_control (Mid: 299)
1502773562: Received PUBREL from blind_control (Mid: 299)
1502773562: Sending PUBCOMP to blind_control (Mid: 299)
1502773562: Sending PUBLISH to ioBrokerMQTT (d0, q2, r0, m39, '/blind_control/system/laufzeit_s', ... (4 bytes))
1502773562: Received PUBREC from ioBrokerMQTT (Mid: 39)
1502773562: Sending PUBREL to ioBrokerMQTT (Mid: 39)
1502773562: Received PUBCOMP from ioBrokerMQTT (Mid: 39)
In den Datenpunkt-Einstellung für mqtt-client.0 ist das Subscribe zwar aktiviert, aber es steht QOS0 - obwohl sich der Adapter laut mosquitto-Log mit QOS2 angemeldet hat???
Ein Neustart des Adapters hilft wiederrum.
Zum Test habe ich den Adapter nochmals neu gestartet - und plötzlich funktioniert das Subscribe wieder nicht. :?: 
Wenn ich dann händisch den einen Datenpunkt ("laufzeit_s") subscribe kriege ich wieder Werte rein. grübel
Ich habe stets parallel mit MQTT.fx mitgeschaut und die Log-Files beobachtet. Fazit: Hier läuft eindeutig noch was ordentlich schief.
Ok, der Adapter ist momentan noch als Beta markiert, aber in der Form nicht brauchbar. Ist zu erwarten, dass weiterentwickelt wird und die Fehler behoben werden?
Danke für deine Antwort. Hab jetzt mal alles umgebaut. Mit mosquitto läuft alles eindeutig besser und stabiler.
Jetzt habe ich nur noch das Problem, wenn ich Subscriptions in den Adaptereinstellung machen, ist defaultmäßig wieder Qos0 eingestellt. Ich brauche aber Qos2 - wo kann ich das umstellen (zur Not auch im Code)?!
Den client-Adapter kenne ich, hatte ich bei einem anderen Projekt schon mal getestet. Allerdings ist eben genau das ein Umweg, den ich mir gerne ersparen würde.
Falls der Broker-Adapter die Anforderungen nicht kann, wird mir vermutlich nichts anderes übrig bleiben. Kann ich mit dem client-Adapter ein subscribe auf ein Haupttopic machen (z.B. "myproject/#"), sodass im ioBroker-Objektbaum alle darunterliegenden Topics erzeugt werden, oder muss ich ein Subscribe für jeden Datenpunkt einzeln machen (ich brauche knapp 200 Topics)?
Mosquitto server recht und gut, aber wie kriege ich die Daten dann in den ioBroker (ohne gröbere Umwege machen zu müssen).
Vielleicht kann Bluefox (als Hauptentwickler?) hier ein paar aufklärende Worte über die tatsächlich implementierten Features reinschreiben!
Hallo,
ich versuche schon seit längerer Zeit mit einem STM32F4 mit ioBroker über MQTT zu kommunizieren und bin dabei möglicherweise auf einen Fehler gestoßen.
Folgendes Szenario:
MQTT-Adapter als broker konfiguriert, MQTT-Client (WolfMQTT-Library) verbindet sich -> OK
Client publish alle 5 Sekunden (System-Uptime) mit QOS0 –> OK
Client publish alle 5 Sekunden (System-Uptime) mit QOS1 oder QOS2 –> Timeout-Error
gleicher Test mit mosquitto Server: Client publish alle 5 Sekunden (System-Uptime) mit QOS1 oder QOS2 –> OK
Wenn ich mich in die WolfMQTT Stack reindebugge, dann wird vergeblich auf ein PUBREC gewartet!
Jetzt die Frage: Ist der MQTT-Broker auch QOS2 fähig, oder kann der etwa nur QOS0?
Vielen Dank,
Frost
Mich überrascht es nicht, dass ein so tolles Produkt wie ioBroker irgendwann kostenpflichtig wird. Wie Bluefox schon erwähnt hat, gibt es natürlich kommerzielles Interesse und das kann man halt nur vernünftig anbieten, wenn ein entsprechender Support dahinter steht. Sowas kannst du aber auch nicht mit freiwilligen Entwickerln machen, sondern die müssen bezahlt werden, gehen dafür aber auch eine Verpflichtung ein, dass das verkaufte System einwandfrei läuft!
Ich bin der Meinung, dass jeder ioBroker-User von diesem Schritt profitieren wird, weil die Softwarequalität nochmals steigen wird! Wenn ich zurückdenke, habe ich früher (ich benutze ioBroker produktiv seit 2 Jahren) einige Abende damit verbracht mein System nach einem Ausfall wieder auf die Beine zu kriegen. Seit ca. einem halben Jahr gehört das aber der Vergangenheit an, weil das Teil bereits jetzt sehr stabil ist! Damals hätte ich gerne (Hausnummer) 30 Euro bezahlt und mir so manchen Frust erspart und stattdessen lieber Zeit mit meiner Familie verbracht!
In diesem Sinn: Danke Bluefox und auch dem Rest des Teams!
