Hallo zusammen,
ich habe in den letzten 2 Tagen mein FHEM von MQTT auf MQTT2 (MQTT2_Server + MQTT2_DEVICE) umgestellt und seitdem nur noch Probleme
mit meinen TASMOTA-Geräten.
Situation vor Umstellung auf MQTT2:
Ich habe auf meinem Raspi MOSQUITTO installiert und meine TASMOTA-Geräte mit dem externen TASMOTA_DEVICE von haus-automatisierung.com
integriert. Nebenbei habe ich noch XIAOMI-Zigbee-Geräte (über zigbee2mqtt) implementiert.
>> Das hat bis vorgestern einwandfrei funktioniert
Situation nach Umstellung auf MQTT2:
1) Ich habe MOSQUITTO deinstalliert
2) MQTT2_Server definiert
3) Geräte per Autocreate und entsprechenden Templates eingebunden
Nun habe ich allerdings folgendes Problem:
MQTT2 scheint völlig auszusteigen, womit ich kein Gerät mehr schalten kann. Ich sehe am state der Geräte entweder set_on oder set_off.
Das DevStateIcon geht auf Lampe mit Ausrufezeichen. Die Geräte lassen sich nicht mehr steuern.
>> Ich habe dazu ein Screenshot angehangen
Ich muss dann jedes Mal FHEM: shutdown+restart machen und kann danach wieder schalten.
Ich bin absolut nicht der Spezialist in FHEM und lebe vom Forum mit seinen diversen Anleitungen. Was kann ich tun, um dem Problem
auf die Schliche zu kommen?
Als einzigen Ausweg sehe ich momentan die Rückumstellung auf MQTT mit TASMOTA_DEVICE, da das System aktuell unzuverlässig ist.
Vielen Dank im Voraus für eure Hilfe und weiterhin eine schöne gesunde Vorweihnachtszeit.
MFG
KN
Bitte "attr global verbose 5" setzen, das Problem reproduzieren, und danach das FHEM-Log (gerne komprimiert) als Anhang hier hochladen.
Zitat von: rudolfkoenig am 23 Dezember 2020, 12:21:49
Bitte "attr global verbose 5" setzen, das Problem reproduzieren, und danach das FHEM-Log (gerne komprimiert) als Anhang hier hochladen.
Guten Morgen,
ich habe das Attribut gesetzt und sofort der erste Schaltvorgang an einer Steckdose hat nicht geklappt. Das nenne ich mal Glück, nachdem
gestern einige Schaltvorgänge geklappt hatten. Ich habe das LOG entsprechend eingekürzt, damit man die betroffene Stelle direkt sieht.
Ich habe gerade versucht das Gerät SonOff_4CH_AZ_B_4 zu schalten (LOG im Anhang als txt-datei).
In der Web-Oberfläche sehe ich als Schaltzustand die Lampe mit Ausrufezeichen. Wenn ich nun auf die TASMOTA-Web-Oberfläche des Gerät
gehe und dort den Schaltvorgang auslöse, ändert sich das DevStateIcon wieder in das korrekte in FHEM.
Schalte ich nun aber wieder per FHEM, dann kommt wieder die Lampe mit Ausrufezeichen.
Nun hilft nur noch ein Neustart von FHEM.
Wenn noch was an Informationen fehlt, bitte kurze Rückmeldung.
MFG
KN
Irritierend ist z.B. das hier:
2020.12.24 04:48:39 5: No IO device or WriteFn found for SonOff_4CH_AZ_B_4
Zeig uns bitte mal das Ergebnis von
list MQTT.* TYPE
und
list SonOff_4CH_AZ_B_4
Zitat von: Beta-User am 24 Dezember 2020, 07:21:30
Irritierend ist z.B. das hier:
2020.12.24 04:48:39 5: No IO device or WriteFn found for SonOff_4CH_AZ_B_4
Zeig uns bitte mal das Ergebnis von
list MQTT.* TYPE
und
list SonOff_4CH_AZ_B_4
Anbei das Ergebnis von "list MQTT.* TYPE":
MQTT2 MQTT2_SERVER
MQTT2_192.168.0.115_46600 MQTT2_SERVER
MQTT2_192.168.0.20_53400 MQTT2_SERVER
MQTT2_192.168.0.21_59521 MQTT2_SERVER
MQTT2_192.168.0.22_56724 MQTT2_SERVER
MQTT2_192.168.0.23_53479 MQTT2_SERVER
MQTT2_192.168.0.24_61132 MQTT2_SERVER
MQTT2_192.168.0.25_52338 MQTT2_SERVER
MQTT2_192.168.0.26_54762 MQTT2_SERVER
MQTT2_192.168.0.27_50001 MQTT2_SERVER
MQTT2_192.168.0.33_64991 MQTT2_SERVER
MQTT2_192.168.0.34_56216 MQTT2_SERVER
MQTT2_192.168.0.35_62566 MQTT2_SERVER
MQTT2_192.168.0.36_63993 MQTT2_SERVER
MQTT2_zigbee_0x00158d0002a35762 MQTT2_DEVICE
MQTT2_zigbee_0x00158d0002a35845 MQTT2_DEVICE
MQTT2_zigbee_0x00158d00045c8d0a MQTT2_DEVICE
MQTT2_zigbee_0x00158d00047b3193 MQTT2_DEVICE
MQTT2_zigbee_0x00158d0004865bd2 MQTT2_DEVICE
MQTT2_zigbee_0x04cf8cdf3c77ba0d MQTT2_DEVICE
MQTT2_zigbee_0x04cf8cdf3c77ba46 MQTT2_DEVICE
Hinweis meinerseits: Über diese ganzen MQTT_SERVER habe ich mich auch schon gewundert. Diese wurden von FHEM automatisch angelegt.
Dann noch das Ergebnis von "list SonOff_4CH_AZ_B_4":
>> Das ist übrigens ein 4-Kanal-SonOff <<
Internals:
CID DVES_B1478E
DEF DVES_B1478E
DEVICETOPIC SonOff_4CH_AZ_B_4
FUUID 5fe1a974-f33f-9a71-1aa9-6e6d9d3bc94c1bce
IODev MQTT2
LASTInputDev MQTT2
MQTT2_MSGCNT 2
MQTT2_TIME 2020-12-24 06:01:11
MSGCNT 2
NAME SonOff_4CH_AZ_B_4
NR 123
STATE off
TYPE MQTT2_DEVICE
JSONMAP:
ANALOG_A0 0
Dimmer pct
Heap 0
LedTable 0
LoadAvg 0
MqttCount 0
POWER1 0
POWER2 0
SaveData 0
Scheme 0
SetOption26 0
Sleep 0
SleepMode 0
Speed 0
StateText1 0
StateText2 0
StateText3 0
StateText4 0
Time 0
Uptime 0
UptimeSec 0
Wifi_AP 0
Wifi_BSSId 0
Wifi_Channel 0
Wifi_Downtime 0
Wifi_LinkCount 0
Wifi_RSSI 0
Wifi_SSId 0
READINGS:
2020-12-24 06:01:11 state off
2020-12-24 05:57:19 subscriptions /Steckdose/SonOff_4CH_AZ_B/SonOff_4CH_AZ_B/cmnd/# /Steckdose/SonOff_4CH_AZ_B/sonoffs/cmnd/# cmnd/DVES_B1478E_fb/#
Attributes:
IODev MQTT2
alias AZ_B_4
autocreate 0
comment Channel 4 for SonOff_4CH_AZ_B_1, see also SonOff_4CH_AZ_B_1, SonOff_4CH_AZ_B_2 and SonOff_4CH_AZ_B_3
devStateIcon on:ios-on-green off:ios-off
icon it_network
jsonMap POWER2:0 Dimmer:pct POWER1:0 Heap:0 LedTable:0 LoadAvg:0 MqttCount:0 SaveData:0 Scheme:0 SetOption26:0 Sleep:0 SleepMode:0 Speed:0 StateText1:0 StateText2:0 StateText3:0 StateText4:0 Time:0 Uptime:0 UptimeSec:0 Wifi_SSId:0 Wifi_RSSI:0 Wifi_LinkCount:0 Wifi_Downtime:0 Wifi_Channel:0 Wifi_BSSId:0 Wifi_AP:0 ANALOG_A0:0 SetOption26:0 Sleep:0 SleepMode:0 Speed:0 StateText1:0 StateText2:0 StateText3:0 StateText4:0 Time:0 Uptime:0 UptimeSec:0 Wifi_SSId:0 Wifi_RSSI:0 Wifi_LinkCount:0 Wifi_Downtime:0 Wifi_Channel:0 Wifi_BSSId:0 Wifi_AP:0
model tasmota_4channel_split
readingList /Steckdose/SonOff_4CH_AZ_B/SonOff_4CH_AZ_B/stat/POWER4:.* state
room Steckdosen
setList off:noArg /Steckdose/SonOff_4CH_AZ_B/SonOff_4CH_AZ_B/cmnd/POWER4 0
on:noArg /Steckdose/SonOff_4CH_AZ_B/SonOff_4CH_AZ_B/cmnd/POWER4 1
toggle:noArg /Steckdose/SonOff_4CH_AZ_B/SonOff_4CH_AZ_B/cmnd/POWER4 2
setStateList on off toggle
webCmd on:off
Nachtrag:
Das ist der eigentliche MQTT2_Server mit der IP von meinem Raspi
MQTT2_192.168.0.115_46600 MQTT2_SERVER
Alle anderen MQTT2_Server wurde als "hidden" also "room hidden" angelegt.
Momentan funktioniert das Schalten der Steckdosen wieder, aber das ist nur eine Frage der Zeit.
Anmerkungen:
- die temporären Instanzen des "MQTT2" (das ist mit einiger Sicherheit die eigentliche Hauptinstanz) kannst du ignorieren, daran kannst du hächstens erkennen, wie viele Clients grade "online" sind (ist wie z.B. bei FHEMWEB auch);
- Beiträge werden lesbarer, wenn du Code-Tags benutzt (#-Button);
- Deine Liste der MQTT2_DEVICE kann nicht vollständig gewesen sein, es ist nicht nachvollziehbar, warum da das später gezeigte "SonOff_4CH_AZ_B_4" fehlt...
- FHEM ist aktuell, oder? V.a. die MQTT2-Module?
Ansonsten sind die Geräte einfach im Netz nicht gut erreichbar, das kann schon mal vorkommen, v.a., wenn ein Consumer-Router wie eine FritzBox das Netzwerk managt und (v.a.) als AP eingesetzt ist?
(Dass das Web-Interface der Geräte ggf. erreichbar ist, bedeutet nicht, dass es keine Verbindungsabbrüche auf der MQTT-Ebene gibt...).
Zusaetzlich zu den Anmerkungen von Beta-User:
- die unmittelbare Ursache des Problems ist die von Beta-User bemerkte Fehlermeldung "No IO Device or WriteFn found".
- die Listings _nach dem Neustart_ schauen richtig aus, interessanter ist "list MQTT2" und "list SonOff_4CH_AZ_B_4" im Problemfall.
- der Haken am Log-Kuerzen ist, dass damit die eigentliche Ursache (wieso ist IODev weg?) vmtl. auch gekuerzt ist, und wir jetzt weitere Runden drehen muessen. Interessant waere das Log vom letzten funktionierenden Befehl bis zum ersten, der nicht tut.
- ich tippe mit den bekannten Daten auf was Banales, wie "delete MQTT2".
Zitat von: Beta-User am 24 Dezember 2020, 10:11:28
Anmerkungen:
- die temporären Instanzen des "MQTT2" (das ist mit einiger Sicherheit die eigentliche Hauptinstanz) kannst du ignorieren, daran kannst du hächstens erkennen, wie viele Clients grade "online" sind (ist wie z.B. bei FHEMWEB auch);
- Beiträge werden lesbarer, wenn du Code-Tags benutzt (#-Button);
- Deine Liste der MQTT2_DEVICE kann nicht vollständig gewesen sein, es ist nicht nachvollziehbar, warum da das später gezeigte "SonOff_4CH_AZ_B_4" fehlt...
- FHEM ist aktuell, oder? V.a. die MQTT2-Module?
Ansonsten sind die Geräte einfach im Netz nicht gut erreichbar, das kann schon mal vorkommen, v.a., wenn ein Consumer-Router wie eine FritzBox das Netzwerk managt und (v.a.) als AP eingesetzt ist?
(Dass das Web-Interface der Geräte ggf. erreichbar ist, bedeutet nicht, dass es keine Verbindungsabbrüche auf der MQTT-Ebene gibt...).
Die Liste mit den MQTT2-Devices war tatsächlich nicht komplett, aber das ist das Ergebnis des vorgegebenen Befehls.
Ich habe den Befehl auf "list SonOff.* TYPE" abgeändert und bekomme dann:
SonOff_4CH_AZ_A_1 MQTT2_DEVICE
SonOff_4CH_AZ_A_2 MQTT2_DEVICE
SonOff_4CH_AZ_A_3 MQTT2_DEVICE
SonOff_4CH_AZ_A_4 MQTT2_DEVICE
SonOff_4CH_AZ_B_1 MQTT2_DEVICE
SonOff_4CH_AZ_B_2 MQTT2_DEVICE
SonOff_4CH_AZ_B_3 MQTT2_DEVICE
SonOff_4CH_AZ_B_4 MQTT2_DEVICE
SonOff_4CH_WZ_A_1 MQTT2_DEVICE
SonOff_4CH_WZ_A_2 MQTT2_DEVICE
SonOff_4CH_WZ_A_3 MQTT2_DEVICE
SonOff_4CH_WZ_A_4 MQTT2_DEVICE
SonOff_4CH_WZ_B_1 MQTT2_DEVICE
SonOff_4CH_WZ_B_2 MQTT2_DEVICE
SonOff_4CH_WZ_B_3 MQTT2_DEVICE
SonOff_4CH_WZ_B_4 MQTT2_DEVICE
SonOff_4CH_WZ_C_1 MQTT2_DEVICE
SonOff_4CH_WZ_C_2 MQTT2_DEVICE
SonOff_4CH_WZ_C_3 MQTT2_DEVICE
SonOff_4CH_WZ_C_4 MQTT2_DEVICE
SonOff_4CH_WZ_D_1 MQTT2_DEVICE
SonOff_4CH_WZ_D_2 MQTT2_DEVICE
SonOff_4CH_WZ_D_3 MQTT2_DEVICE
SonOff_4CH_WZ_D_4 MQTT2_DEVICE>> Das sind aber immer noch nicht alle MQTT2-Devices. Meine 4-Kanal-Switches laufen alle mit dem Namen SonOff*
FHEM ist aktuell. Bedingt durch die aktuellen Probleme habe ich sogar mehrmals täglich das Update durchgeführt.
Ich arbeite mit einem TP-Link Archer C7 (OpenWRT) als Router in Zusammenarbeit mit 2 XIAOMI R3Pro Routern, welche als WLAN-Access-Points
bzw. Repeater dienen. Vor der Umstellung auf MQTT2 hatte ich diese Probleme nicht, insofern möchte ich dies als Fehlerursache ausklammern.
>> Mein Netzwerk
Zitat von: rudolfkoenig am 24 Dezember 2020, 10:27:52
Zusaetzlich zu den Anmerkungen von Beta-User:
- die unmittelbare Ursache des Problems ist die von Beta-User bemerkte Fehlermeldung "No IO Device or WriteFn found".
- die Listings _nach dem Neustart_ schauen richtig aus, interessanter ist "list MQTT2" und "list SonOff_4CH_AZ_B_4" im Problemfall.
- der Haken am Log-Kuerzen ist, dass damit die eigentliche Ursache (wieso ist IODev weg?) vmtl. auch gekuerzt ist, und wir jetzt weitere Runden drehen muessen. Interessant waere das Log vom letzten funktionierenden Befehl bis zum ersten, der nicht tut.
- ich tippe mit den bekannten Daten auf was Banales, wie "delete MQTT2".
Ich habe gerade nochmal "attr global verbose 5" gesetzt.
Wollte dann mal wieder die Steckdose testen und siehe da, geht nicht ... Habe nun einen Neustart von FHEM durchgeführt und warte bis zum nächsten Auftreten des Fehlers.
Mich wundert aber schon, dass nach dem Setzen des Attribut "attr global verbose 5" direkt der Fehler auftritt.
Der Fehler tritt übrigens nicht nur an dem Gerät "SonOff_4CH_AZ_B_4". Alle anderen SonOff's steigen dann auch aus.
Was bedeutet das?
was Banales, wie "delete MQTT2"
Sorry, mein Fehler bei der devspec, gemeint gewesen war
list TYPE=MQTT.* TYPE
Meine Spekulationen: Da spuken noch Reste von der alten MQTT-Implementierung rum, und evtl. versucht auch mosquitto noch im Hintergrund, sich Port 1883 zu schnappen. Aber den hast du ausdrücklich als "deinstalliert" bezeichnet, und üblicherweise ist der auch schneller da wie FHEM, das dann afaik auch gar nicht startet...
Komisch ist auf alle Fälle, dass das IO lt. der Fehlermeldung nicht zu finden war, was "eigentlich" nur sein dürfte, wenn die SERVER-Instanz durch irgendwas aktiv aus der Konfiguration gelöscht wird. Und es ist logisch, dass dann keines der MQTT2_DEVICEs mehr ein IO hat...
Vielleicht loggst du auch mal "global"-Events? (v.a. das vermutete "delete")?
Kurzer Zwischenstand nach Weihnachten:
Das System läuft momentan stabil. Es gab keinen weiteren Ausfall.
Entschuldigt bitte, das ich folgendes schreibe, aber ich muss es gerade los werden.
Ich lese in der letzten Zeit immer mehr "hat sich erledigt läuft wieder"
Aber ohne eine Lösung zu präsentieren.
Solche Treads ärgern mich immer persönlich, weil wenn man evtl. den gleichen Fehler hatte und Stunden mit suchen verbracht hat,
Endet es dann im nichts/nicht gelöst/hat sich erledigt.
Eine kurze oder auch lange Info, was die Lösung war, wäre für Nachfolger echt hilfreich
Danke und sorry
Intruder
Zitat von: Intruder1956 am 27 Dezember 2020, 09:33:28
Entschuldigt bitte, das ich folgendes schreibe, aber ich muss es gerade los werden.
Ich lese in der letzten Zeit immer mehr "hat sich erledigt läuft wieder"
Aber ohne eine Lösung zu präsentieren.
Solche Treads ärgern mich immer persönlich, weil wenn man evtl. den gleichen Fehler hatte und Stunden mit suchen verbracht hat,
Endet es dann im nichts/nicht gelöst/hat sich erledigt.
Eine kurze oder auch lange Info, was die Lösung war, wäre für Nachfolger echt hilfreich
Danke und sorry
Intruder
Hallo,
leider gibt es keine Lösung, da das Problem aus unerklärlichen Gründen anscheinend verschwunden ist. Im Log gab es den Eintrag, dass das IODev nicht vorhanden war.
Ein weiterer Langzeitversuch mit verbose 5 brachte allerdings keine neuen Erkenntnisse.
Mittlerweile läuft das System weiter stabil, keine weiteren Aussetzer, was soll man dann als Lösung präsentieren?!
Ich wünsche allen einen "Guten Rutsch".
MFG
KN