Device reagiert auf falsches subscribeReading

Begonnen von pula, 07 Februar 2018, 20:39:22

Vorheriges Thema - Nächstes Thema

pula

Hallo,

Ich hab mir grad einen Sketch für einen Mega geschrieben, um per MQTT 10 entprellte Taster zu überwachen und 24 Relais zu schalten (Ablöse von Firmata).
Soweit funktioniert alles gut, aber ich hab jetzt folgendes - für mich merkwürdiges - Problem.

Ich habe zum Testen mal folgende devices angelegt:
define uno1_02_mqtt MQTT_DEVICE
attr uno1_02_mqtt IODev mqtt
attr uno1_02_mqtt devStateIcon status:on:FS20.on status:*:FS20.off
attr uno1_02_mqtt eventMap 1:on 0:off
attr uno1_02_mqtt publishSet_reset /uno1/input/reset
attr uno1_02_mqtt publishSet_watchdog /uno1/input/watchdog
attr uno1_02_mqtt room MQTT
attr uno1_02_mqtt stateFormat status
attr uno1_02_mqtt subscribeReading_status /uno1/output/btn_02

define uno1_03_mqtt MQTT_DEVICE
attr uno1_03_mqtt IODev mqtt
attr uno1_03_mqtt devStateIcon status:1:FS20.on status:*:FS20.off
attr uno1_03_mqtt eventMap 1:on 0:off
attr uno1_03_mqtt publishSet on off /uno1/input/switch_22
attr uno1_03_mqtt room MQTT
attr uno1_03_mqtt stateFormat status
attr uno1_03_mqtt subscribeReading_status /uno1/output/rel_22

Wenn ich jetzt bei dem ersten device (uno1_02_mqtt) umschalte, schickt fhem folgendes:
/uno1/input/switch_22 0
der Sketch reagiert richtig und schickt folgende Antwort:
/uno1/output/rel_22 0

Im Event-Monitor von fhem kommt aber:
2018-02-07 20:36:11 MQTT_DEVICE uno1_03_mqtt off
2018-02-07 20:36:11 MQTT_DEVICE uno1_03_mqtt transmission-state: outgoing publish sent
2018-02-07 20:36:11 MQTT_DEVICE uno1_02_mqtt transmission-state: incoming publish received
2018-02-07 20:36:11 MQTT_DEVICE uno1_02_mqtt status: off
2018-02-07 20:36:11 MQTT_DEVICE uno1_03_mqtt transmission-state: incoming publish received
2018-02-07 20:36:11 MQTT_DEVICE uno1_03_mqtt status: off


Warum reagiert hier auch das (erste) device, das das entsprechende Topic gar nicht abonniert hat? Was verstehe ich hier nicht?
Könnte das evtl ein ähnliches Problem wie hier https://forum.fhem.de/index.php/topic,83881.0.html sein?
Ich habe allerdings zur Sicherheit das device NICHT kopiert, sondern neu angelegt....

Danke für zweckdienliche Hinweise im Voraus,
Pula
fhem (debian auf proxmox), HM-LAN und wired, MySensors, FritzBoxes, Kodi, vdr, Onkyo, squeezeplayers, nanoCUL, wifilight (Ethernet-Bridge), Heizungssteuerung (python/vncdotool), doorpi, ESP/Arduinos/MQTT, Alexa, HomeConnect, Sonoff/Tasmota, espRGBWW, esphome, Telegram

pula

#1
Das lässt mir keine Ruhe....

Hab noch einmal herumgespielt und bei verbose 5 bekomm ich im log folgendes:
2018.02.09 06:42:27 5: MQTT mqtt message sent: Publish/at-most-once /uno1/input/switch_22
  31                                               1
2018.02.09 06:42:27 5: SW: 301800152f756e6f312f696e7075742f7377697463685f323231
2018.02.09 06:42:27 5: MQTT mqtt message received: Publish/at-most-once /uno1/output/rel_22
  31                                               1
2018.02.09 06:42:27 5: publish received for /uno1/output/rel_22, 1
2018.02.09 06:42:27 5: [b]calling readingsSingleUpdate(uno1_02_mqtt,status,1,1)[/b]
2018.02.09 06:42:27 5: publish received for /uno1/output/rel_22, 1
2018.02.09 06:42:27 5: [b]calling readingsSingleUpdate(uno1_03_mqtt,status,1,1)[/b]
2018.02.09 06:42:50 5: MQTT mqtt message sent: PingReq/at-most-once

Das topic rel_22 ist definitiv NICHT in uno01_02...
Allerdings HATTE ich einmal ein device uno01_02, in dem das topic subscribed war, das device habe ich aber gelöscht (per fhemweb) und dann völlig neu angelegt (per fhemweb).
Kann das sein, daß hier beim Löschen eines _ganzen_ MQTT-Devices vielleicht nicht alles sauber läuft und im Speicher noch sachen vorhanden sind, die in der fhem.cfg nicht mehr sind?

Was meine Vermutung untermauert: Nach einem Neustart von fhem reagiert plötzlich nur noch das uno1_03 device, was das richtige Verhalten ist (wie es auch in der cfg definiert ist).

Cheers,

Pula
fhem (debian auf proxmox), HM-LAN und wired, MySensors, FritzBoxes, Kodi, vdr, Onkyo, squeezeplayers, nanoCUL, wifilight (Ethernet-Bridge), Heizungssteuerung (python/vncdotool), doorpi, ESP/Arduinos/MQTT, Alexa, HomeConnect, Sonoff/Tasmota, espRGBWW, esphome, Telegram

pula

@eisler: Würdest Du bitte so nett sein und Dir das mal ansehen? Mir fehlt leider das Know-How dazu...
Cheers,
Pula
fhem (debian auf proxmox), HM-LAN und wired, MySensors, FritzBoxes, Kodi, vdr, Onkyo, squeezeplayers, nanoCUL, wifilight (Ethernet-Bridge), Heizungssteuerung (python/vncdotool), doorpi, ESP/Arduinos/MQTT, Alexa, HomeConnect, Sonoff/Tasmota, espRGBWW, esphome, Telegram

pula

Ich versuche, das Thema noch mal anzuschneiden. Vielleicht kennt ja jemand das Verhalten?

Cheers,
Pula
fhem (debian auf proxmox), HM-LAN und wired, MySensors, FritzBoxes, Kodi, vdr, Onkyo, squeezeplayers, nanoCUL, wifilight (Ethernet-Bridge), Heizungssteuerung (python/vncdotool), doorpi, ESP/Arduinos/MQTT, Alexa, HomeConnect, Sonoff/Tasmota, espRGBWW, esphome, Telegram

gadget

Hallo,

ich kann das Verhalten bestätigen. Wenn ich bei einem MQTT_DEVICE ein subscribeReading_reading lösche und neu anlege reagiert das Device reproduzierbar nicht mehr auf das Topic. Löschen und Neu Anlegen des gesamten geänderten MQTT_DEVICE führt zum Erfolg. Das kann sehr frustriend sein.

Grüße, gadget

pula

Hallo Gadget,

ich bin in der Zwischezeit auf mqtt2 umgestiegen. Die Umstiegshürde war bei mir zwar relativ hoch, aber unterm Strich hat sich das gelohnt.
Das würde ich mir evtl auch überlegen...

Cheers,
Pula
fhem (debian auf proxmox), HM-LAN und wired, MySensors, FritzBoxes, Kodi, vdr, Onkyo, squeezeplayers, nanoCUL, wifilight (Ethernet-Bridge), Heizungssteuerung (python/vncdotool), doorpi, ESP/Arduinos/MQTT, Alexa, HomeConnect, Sonoff/Tasmota, espRGBWW, esphome, Telegram