Datensparsamkeit ist ein Argument, aber wie bereits von digi303 angemerkt werden sämtliche anderen Daten gesendet.
Ich gebe zu bedenken, dass je nach Retained- und QoS-Einstellungen Nachrichten verloren gehen können. Wenn man schon die Energie investiert um das WLAN-Modul zu aktivieren, dann sollte man einen vollständigen Status-Update senden.
Ich sehe das als Bug. Da sich auch mit Firmware 1.9.1 nichts an diesem Verhalten geändert hat, werde ich den Shelly-Support kontaktieren.
Moin,
schöne Idee per tcpdump die Verzögerung zu messen.
Leider sehe ich bei mir überhaupt keine CoAP Pakete.
Muss ich dafür etwas im Shelly konfigurieren?
Andererseits sniffe ich mich einem Laptop und bin mir nicht sicher wie es sich mit Multicast-Paketen bei mir im WLAN verhält.
Muss sich erst eine CoAP-Anwendung beim Shelly registrieren?
Device: Shelly Door Sensor 2
Firmware: "20200612-144015/master@a3eeb1a1+"
Wenn einer der Sensoren (Tilt, Lux, Temp) eine Übertragung auslöst,
wird der Status des Türkontaktes nicht über MQTT übertragen.
Ändert sich der Status des Türkontaktes wird dieser korrekt übertragen.
Nichts desto trotz, ist das Fehlen des Kontaktstatus ein Bug.
Ich habe ein entsprechendes Log angehängt.
Die MQTT-Nachrichten die um 10:22:05 empfangen wurden sind "retained" und wurden daher beim subcriben des MQTT-Topics empfangen.
Um 10:36:37 hat ein Sensor ausgelöst. Wie sich zeigt fehlt hier das Topic "state" mit dem Status des Türkontaktes.
Ich bitte um einen Fix.
Ich werde ein entsprechendes Ticket erzeugen...
Danke,
TriCX
